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.
Do the credit card numbers ever travel via your server? Even temporarily in memory? If so you are liable for PCI-DSS section C, which is a LOT of hoops to jump through.
It took us a couple hours to be in compliance with section C. If memory serves, we dealt with a vendor who did a scan, made us install AV software on our Linux boxes, and one or two other minor process adjustments. It wasn't a big deal.
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 need a written security policy, but that was pretty close to pro forma. The compliance firm wrote us one which we disseminated appropriately.
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.
The only situation where I can imagine it being a pain is if you aren't already following good security procedures.
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.
I don't understand how Spreedly is somehow providing you a "return". They sit on top of your payment gateway so you pay everything you would've paid withluan in-house integration, plus Spreedly's fees. Coding your own subscription billing is a one-time thing as well. Where are you saving money?
It may be a one-off cost but writing a billing system is still a few weeks work. Pro-rataing on upgrades/downgrades, support for one-off overage fees, refunds, credits. Plus dealing with the fallout when you get a decimal place wrong in a tax calculation and accidentally charge a customer a hundred times what you were supposed to (guilty).
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.
Maybe the math works out like that when you bill four weeks for a two day job. Startups can and do find programmers that write robust billing code with those features in a day or two. I've done it more than once. I run both ecommerce sites and subscription web apps -- the billing code handles upgrades, downgrades, pro-rating, one-off overage fees, refunds and credits. Once you've done it once, doing it again and testing for another site is a few hours work.
Perhaps point values should be shown for your post and all of your children, so you can see what people think of the responses to your post (and the submission author can see points for everything since he's the essentially the root node).
This may have been recommended in the other thread, but I don't recall it.
