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.
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.