Automatic Renewal System with Billing

rsmith

Not looking for code, more advice than anything else.

For those of you running websites that generate income through selling products or services; what methodologies are you using to:

a) handle payments
b) process automatic renewals with subscriptions (charging of CC's etc)
c) monitor subscriptions - including notifying users if they choose not to auto-renew
d) monitor thresholds - if a user selects plan a, but reaches its threshold, accommodating a user for overages without interrupting service.

Thanks for any and all advice.

Ashley_Sheridan

I've used a few payment systems before, and all have various pros and cons:

PayPal - popular and accepts payments in a lot of countries, but support from them is awful and they freeze money if you are getting paid too much too quickly, such as for an event
HSBC - complicated and requires you to install software on your server, but it does accept payments anywhere
Google Checkout - very easy to set up and use, but not available in many countries

rsmith

Thanks for the input. I don't see this project going worldwide any time soon, unless Google wants to buy me out 😉 but support in major countries is definitely a big draw. I could care less about getting a payment from the one guy in Micronesia that has a 9800 baud and a credit card.

sneakyimp

I know that authorize.net offers CIM. Using this service, authorize.net stores the credit card information safely and you create payment profiles which you can use to charge your customers at any time. It's useful for building convenient payment profiles for your users.

They also offer ARB which is automated recurring billing.

As for determining who gets charged what and when, I have never seen a one-size-fits-all solution that can offer you uniquely what you want. I've seen things built on top of Joomla and osCommerce but most of them are crap in my opinion -- i.e., not secure and poorly written.

rsmith

Lots of choices and good info, thanks everyone.

Bonesnap

My company has used Authorize.net a few times in the past when making e-commerce websites.

rsmith

Easy to setup and customize? I saw the lightbox demos in the CIM API. The idea of not storing the CC info on my own hardware is a huge draw for sure. If I don't use the ARB I would have to manually run the charges and that's a drag.

Derokorian

rsmith;11000279 wrote:
If I don't use the ARB I would have to manually run the charges and that's a drag.

What do you mean by "manually run the charges?" If you mean that your server would need to be involved, then it should be anyway so you can confirm if people's accounts are up-to-date or not. Without ARB, you could create a cron job that would run every morning and charge the accounts that would be due that day.

Ashley_Sheridan

Also, it's worth bearing in mind that storing credit information on your own servers can get extremely complicated. In most countries there's a minimum set of security requirements, such as encrypting all the data with a one-way hash. If you don't meet those requirements, you could be breaking laws in your country, so generally I'd say it's just not worth the hassle!

rsmith

Derokorian wrote:
What do you mean by "manually run the charges?" If you mean that your server would need to be involved, then it should be anyway so you can confirm if people's accounts are up-to-date or not. Without ARB, you could create a cron job that would run every morning and charge the accounts that would be due that day.

So, for example, just run the query to extract the accounts that have billing dates for that day and iterate through them with calls to the API for the merchant services solution I use?

Ashley Sheridan wrote:
Also, it's worth bearing in mind that storing credit information on your own servers can get extremely complicated. In most countries there's a minimum set of security requirements, such as encrypting all the data with a one-way hash. If you don't meet those requirements, you could be breaking laws in your country, so generally I'd say it's just not worth the hassle!

I completely agree. As this is my first actual ecommerce application I'm doing as much research as I can and trying to get down on paper the full blown process before even beginning to code this portion.

Derokorian

rsmith;11000313 wrote:
So, for example, just run the query to extract the accounts that have billing dates for that day and iterate through them with calls to the API for the merchant services solution I use?

Exactly. If the API reports a successful charge, update the DB with the last payment date. Possibly also send a charge confirmation every time its charged. This would also allow you to do different pay periods as well (say monthly, quarterly, and annually) by incorporating this into your table and query. Say you had your table like:

CREATE TABLE `subscriptions` (
   `id` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `cust_id` INT UNSIGNED NOT NULL,
  `freq` ENUM('monthly','quarterly','yearly') --Maybe?
  `last_payment` DATE NOT NULL,
  PRIMARY KEY (`id`)
)

You could then write queries to fetch them like such (simplified):

-- Monthly
SELECT * 
  FROM `subscriptions` as s 
  INNER JOIN `customers` as c
    ON c.id = s.cust_id
WHERE
  s.freq = 'monthly'
AND
  s.last_payment < DATESUB(NOW(),INTERVAL 1 MONTH)

You would in reality need more information than this in the subscription table I imagine. I'm not exactly sure what it is your doing, but I hope I helped illustrate what you are looking for. If not ignore me 😉

rsmith

It definitely makes sense, I think the most difficult thing for me to do is deal with the API I choose to use and make sure proper variables are posted back to indicate a successful charge. Thanks for the example. Once I start coding it I'll post for critique and insight.

bradgrafelman

rsmith;11000320 wrote:
I think the most difficult thing for me to do is deal with the API I choose to use and make sure proper variables are posted back to indicate a successful charge.

I personally don't have any experience dealing with external payment gateways, but I would think that many/most of them would offer some sort of sandbox environment (I'm thinking of PayPal as an example) that would allow you to perform real queries against a real model of the real gateway and try to process real responses... without costing anyone real money. 🙂

rsmith;11000320 wrote:
Once I start coding it I'll post for critique and insight.

This is probably going to be one of the more helpful tools you can use - other programmers. Feel free to start threads in the Code Critique forum as often as you'd like; it's easier to receive feedback often and incorporate changes as necessary rather than waiting until you've done a bunch of work, only to be educated in a better way you could have done it (but would mean throwing away or severely refactoring the work you've already done).

sneakyimp

I've implemented some Paypal stuff and I'm doing my second Authorize.net implementation right now. I would encourage you to also consult the authorize.net forums -- there's a guy named TJ over there who is enormously helpful.

I too am setting up a subscription situation and have been using their PHP library. The library seems pretty solid, but is not especially well documented. I frequently find myself wondering what kind of object a function returns and what methods I may use on that object.

The basic setup is that you should create a sandbox account at http://test.authorize.net and use that while you are developing. You can create customer profiles, customer payment profiles (i.e., a profile that represents a single payment method), and transactions on the sandbox account and no money will change hands. This should let you test out your implementation. When you go live, I would try to make sure you get notified of any transactions that return errors as you will likely encounter situations that you did not encounter during sandbox development (i.e., network timeouts, declined cards, held funds, etc.). If you get notified when an error condition happens, you should be aware of when your customers are encountering problems. Make sure you write a log file (database table or flat file on the file system) so that you can go back and see what sort of error condition caused the problem -- but make sure it is outside the web root and does not contain any sensitive info!

The most helpful sample code you will find for this is in the 'markdown' files distributed with the PHP library. They're in the docs folder. They are by no means complete -- and bizarrely they do not address error handling -- but they will help you get started. You should be prepared to run a bunch of transactions and do a var_dump on the results and check for isOk, isError, getResultCode, and all that stuff on the responses you get.

Weedpacket

Ashley Sheridan wrote:
Also, it's worth bearing in mind that storing credit information on your own servers can get extremely complicated. In most countries there's a minimum set of security requirements, such as encrypting all the data with a one-way hash. If you don't meet those requirements, you could be breaking laws in your country, so generally I'd say it's just not worth the hassle!

Regardless of the laws covering storage of credit card information, the credit card companies (who own that information, and are liable for breaches of security) themselves have requirements that they insist vendors comply with. https://www.pcisecuritystandards.org/merchants/