This strongly suggests that I should not be writing billing code, ever.
You need a bunch of pieces to do billing. I use Paypal Website Payments Pro to physically charge people's credit cards, and Spreedly to tell them when to do it. I interact with Spreedly through a REST API that is wrapped with a Ruby gem. My entire interaction with them is one form, three model actions (which handle account creation, status change, and expiry), and a callback for when customer status changes. This took me a few hours to implement, once. Aside from a bug on my side (not charging Mastercards because I am illiterate and failed to read their documentation correctly), it has been pretty flawless.
This seems to come up way, way too often. Would anybody be interested in a blog post about how to do it in a practical, pain-minimizing manner?
You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.
I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.
I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.
Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.
I read a few posts on forums that if the customer financial data is ever on a page you wrote, you come under the realm of at least some PCI compliance because of a possible XSS attack getting that information out of your forms.
That made the hosted "checkout" pages seem a lot more attractive to me... curious how you handled this.
Thing is, everything PCIDSS says you have to do when payment data passes through your servers is security 101. If you're not already doing 90% of these things, you're just waiting to be hacked anyway. Instead of thinking of it as a burden for payment processing, think of it as something every professional online business should have been doing anyway.
Lots of bark, absolutely no bite. There is not a single case where a bank will shut you off and stop getting your processing fees.
I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.
As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.
Spreedly saves you from that.
Given Spreedly's current prices of the lesser of $0.20/transaction or 2%/transaction, this minute quantity of work is currently providing us with a return of approximately $12,000/mo. (We had over 60,000 transactions in March.)
Cost: approximately 3 man-days.
Benefit: currently sitting at approximately 1 man-year/year and growing.
It's true that if we'd gone of business within 25,000 transactions, we would've been better off with Spreedly, but given the time, energy and money that we were committing to the business, optimizing for that case seemed absurd. As such we made a small bet that we'd succeed, and that bet is currently generating enough savings (as compared to using Spreedly) to cover an FTE. Some people might say it's a rounding error on the revenue (and I suppose that's true) but I view it as a small bet that is paying off at an enormous multiple.
You basically just need to follow some reasonable security standards. Firewalls, ssh/ssl admin terminals, no shared credentials, and then follow a basic security policy.
If your ops/DevOps guys are experienced pros, they're probably going to be pretty close to compliant, just out of habit. That said I guess it's not terribly hard to envision a scenario where there's no firewall, bad user access controls, and a host of other crap that could be painful to fix if you only have junior-level ops talent.
One of my clients paid $700 for Spreedly kickstart plus their percentage transaction fees, plus a couple of hours for me to integrate it. Significantly less money then three or four weeks of my time to write a billing app from scratch.
This may have been recommended in the other thread, but I don't recall it.
Doing the charges yourself is exactly the same, except you have a nightly cronjob to find the accounts that expire today and rebill them. I don't think there's enough material in this to warrant a post.