need to write member subscription routine

[progman1010]

i'm building a website will bill its members by subscription. i need to write the Renewal routine so we can collect the money on an ongoing basis. I'm wondering if you know of any resources to help me write a good program to do this, as this is the first time i have done this.

the routine will need to include the foregoing premeses:
- it will automatically charge valid credit cards
- it will email the customer a receipt
- it will email the customer when their card didn't go through and prompt them to update the card online
- there are numerous subscription options such as annual, semi-annual, quarterly, AND there are limited and full versions in each frequency. There may be more options in the future.

I thought about using a 3rd-party to handle this whole component, but I'd rather try my hand at writing one, plus I need to have this running locally just in case the provider disappears!

Any thoughts?

 

[jpadie]

what's the difficulty that you are facing?

i see this as a simple cron job that is run each day. in pseudo code:

1. lookup all subscriptions that expire today or that have previously expired and on which payment is pending
2. loop through the results (a) obtaining payment details; (b) processing payment; and (c) logging the payment results
3. if the payment result is positive, email subscriber informing him that his sub has been renewed for X period of time
4. if the payment result is negative, do the same but tell him payment has failed
5. make sure that your login routine checks username, pwd and that subscription is valid.

the slight blackhole is item 2(b) and (c) as different payment providers provide different information. However they should all provide a success/error code. Equally some merchant acquirers do not permit merchants to retain card data for longer than is required for a single payment. you will (obviously) not be able to accept these card-types for subscription payment.

 

[progman1010]

I guess my question is more about data organization. Since I need the subscription types to be flexible in amount, features and frequency, I want to be sure i'm making something that can grow through time without having to rewrite when we change up something.

One thing that has come up that I want to add is a free trial period that then automatically charges after say, 60 days.

I actually started on it, and created a few tables, and I could continue on this, but the difficulty I keep running into is that it's not flexible enough.

Here's an idea I had...

Build in the ability to make certain subscription types turn into "legacy" subscriptions. i.e. Create a self-contained module for one subtype and its corresponding processing routine. If at some point this is replaced or upgraded at some point in the future, I could write a new self-contained module to replace it and then migrate any old-fashioned users when it's all tested and ready to go....

 

[jpadie]

this is a rating question really. i would maintain flexibility by defining subscription products simply as a function of whether they auto-renew and what their end date were.

 

[vacunita]

You have a table that has the subscriptions types and an identifier. then you have another table that links users to subscriptions types.

If you need to add a new type of subscription, you add it to the subcriptions table. And when you add users that have this subscription type you reference it by the ID.

You are basically only adding rows to a table if you need more subscription types.
The subscriptions table contains the period they are valid, or if they should change after a period of time. The cost etc...
Now if a subscription type is going to be removed, and those with that type moved to another type, you can set that too in the table.







----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[progman1010]

vacunita- that's what i started with, but the subscription options are more complicated than that.

i think i'm going to go with my thought to create a module for each subscription group- then if i upgrade, i'll change modules. That way I can go with your suggestions to simplify individual subtypes while leaving it open for later expansion into other products/subtypes.

 

[jpadie]

I would still go with my model.

One thing that has come up that I want to add is a free trial period that then automatically charges after say, 60 days.

just register two products: a two month subscription term, with no renewal at zero price; and a 10 month subscription term starting at a future date for X price with monthly billing.

 

[progman1010]

oooh- that's a good idea! eureka. now it all makes sense. That's what i'll do then.

Thanks!