Damon Cortesi ( @dacort ) over at Untitled Startup recently wrote up a summary of recurring payment services provided for startups. It's a decent analysis of current payment services that offer a hosted recurring billing solution, if you don't have a merchant account or want to handle your own e-commerce. If you're writing a software-as-a-service platform from the ground up, and would like to outsource the payment side of things, these are good options.
But what if you already have a merchant account, or a retail offering, or an e-commerce site? What if you want to have a subscription product, or store a customer's credit cart for repeat business?
The first thing to consider is security. If you're going to repeat a transaction, your customer's credit card number needs to be stored somewhere. If that's on your web site, you become a target for attack. As a company that hosts e-commerce systems for our clients, we would just as soon not have to protect thousands of credit card numbers. Fortunately there are quite a few payment gateways that can store the sensitive information for us, and all we need is a unique transaction number to use for future charges.
In Ubercart, the recurring payments module has been removed from the core e-commerce system and put in its own module. This work is incomplete, but we are using it (carefully) in production. It's going to take time for the modules for various payment processors to catch up, but here's a quick run-down of a few gateways we've looked at, which features they can support, and which features work today. But first, a little lay of the land.
Industry
Very Helpful
Thanks, John. This was a very helpful write-up. I've just been doing some research on recurring billing for a very specific type of implementation, and information like this helps add some background as I try to determine the most efficient strategy. I was looking at UC Recurring to see if it will make the most sense to use that given a potential need to code support for an additional payment processor and integration with some other functionality for the site.
I've been trying to get a feel for general experience using the module, CIM vs. ARB vs. WP, and status on some of the payment processor integration. You mentioned you're using it "carefully". Has anything crept up in the last few weeks that has been a concern or challenge?
- Matt Winters
Kinaba / WebNewCastle
Use CIM if you can...
Hi,
Our epn module seems to be working great with recurring payments! The one quirky thing is that if you want to charge the first payment after a period of time (instead of immediately) you need to set the product price to zero, and set the recurring price in the feature. A little bit odd...
I would recommend doing a CIM-style connection if you have a choice -- store the credit card info at the gateway, and get a handle Ubercart can use for future payments. Though not all gateways support that. Just digging into FirstData for a client, and it looks like we'll be adding support to that for an ARB-style connection.
Cheers,
- John
Thanks, John. I'm still
Thanks, John. I'm still trying to get a full understanding of the differences between CIM and ARB. It sounds like the CIM option is better developed and tested with UC Recurring.
CIM = Store card details, ARB = store transaction
CIM is "Customer Information Manager", and basically allows you to put the customer's card info on file. You then get a handle that's unique to your store that you can use for arbitrary transactions... basically you have the credit card "on file" in a secure way.
So it's possible to change the payment amount, skip a payment, delay a payment, etc. Ubercart doesn't necessarily support these features (yet) but it's at least possible.
uc_recurring initiates the recurring payment, using the customer details stored in CIM.
ARB is "Automatic Recurring Billing." With ARB, Ubercart (or other shopping cart) tells Authorize.net to charge on a schedule. Authorize.net provides a transaction id that can be used to cancel it in the future, but otherwise once it's set up, you can't necessarily change it.
With ARB, Ubercart/uc_recurring is far more passive--it may enter a new order, but it doesn't do anything further with ARB. If your site disappears entirely, ARB would continue to make charges on the customer's card.
CIM is new, and is what the new uc_recurring is targeting. ARB has been around a while, and is supported in older uc_recurring.
Nice summary
I always been concerned with taking credit cards on my websites (those where it's needed) but except for the recurring billing issue, it may be less of a hassel that I thought. Thanks for the info.
CIM and ARB?
Is there any point to having both CIM and ARB with Drupal and Ubercart? I currently have CIM setup with recurring fees, and everything seems to be working. Except for one thing - I can't figure out how to send a notification email to a customer prior to their card expiration date (so they can update their expiration date prior to renewal). I can only notify them in the event of a failed renewal.
From what I can tell, ARB allows me to do this, but I'm not sure it's worth paying an extra $10/ month just for this feature. Anyone know of a way to do this with just CIM? If not, is Ubercart stable enough to run both CIM and ARB?
Finally, I haven't yet actually encountered a failed renewal event (and can't find a way to test it), but when I do, it seems that the email sent to the customer will contain a [recurring-link] element, which they can supposedly click on to update their card details. Does this work without them logging in to my site? Or do I need to add their login details to the email?
Great article, thanks for taking the time to read my questions!
recurring payments - a puzzle indeed
My e-commerce store is using the Authorize.net payment gateway and there are many opinions around the campfire on how to store and make recurring payments. 3 developers = 5 opinions!! We currently store credit card numbers on a 'secure server' (I put in quotes for obvious reasons) database and run the charges on the first of the month. (#1) One idea was to store the expiration dates on another 'secure server' database to spread the risk off just one server. (#2) Another idea was to not store the exp date / 3-digit code in a database at all and run the payments by hand through our voip phone systems. (#3) And then we have the purists who want zero risk and wish to have an employee run them by hand every month through our online payment gateway UI.
I have a problem with #3 because, thinking as a businessman, this solution is not scalable. I consider anything that involves human input on a regular basis not scalable. It's easy to poke holes in #1 and #2 considering the risk of storing credit card information online.
the puzzle continues...
Add new comment