Storing your customer billing data with your processor can kill your cash flow when something like this happens. You not only need a new payment processor, you need to get every customer to put their credit card numbers in again. If you're in a high-risk business, or simply want to be safe, check out https://spreedly.com. You code once against their API and can switch between 80+ different processors with no code changes, and take your customers with you. I recommend them whenever I can, as I've gone through that pain before, but never worry about it now.
This is really interesting, thanks for posting. I've been idly concerned about tying customer data in with the payment processor, but I accepted it as a given.
The people I’ve known who tried to transfer customer billing information into or out of Stripe all had pretty good experience. The process might take a week or two, but Stripe should be able to coordinate with your new payment processor to securely transfer that information.
(Most of the new-ish trendy payment companies are similarly customer friendly; some older payment companies will refuse to transfer data or will demand outrageous fees for it.)
Forgive me for playing along the line of the devil's advocate - doesn't that then make Spreedly your single point of failure? Are there any more guarantees that Spreedly will continue doing business with you in a situation where Stripe wouldn't?
Taking the current story for example, it looks like it would also violate Spreedly's terms of service. At a quick skim (IANAL) it looks like their ToS is pretty much identical to Stripe's
Situations where Spreedly will continue doing business with you where a processor wouldn't: You get a string of unexpected chargebacks. You crowdsource funds for something that doesn't exist yet. You sell pre-orders or event tickets. Your choice of processor does delayed underwriting and you just hit a volume trigger (e.g. "a PayPal horror story"). The nature of your business changes. You have to issue a lot of refunds due to an unexpected situation. A PCI audit turns up that you shouldn't be touching credit card numbers in the first place. The processor goes out of business -- happens more often than you think.
There are lots of reasons businesses lose their payment processing accounts. Most of those reasons have something to do with underwriting and payment network rules: your actual or predicted chargeback/refund rate going above 1%, or otherwise putting the processor at risk with Visa/MC, or their underwriting bank. Businesses often want to change their payment processor voluntarily, to get more features or better rates, but can't because their customer info is locked in their vault and the won't transfer it.
Your account with Spreedly isn't at risk in any of those situations because they're not a payment processor. They're just an API. They don't care whether your charges are declined, how many refunds you issue, or how many chargebacks you get. Inexperience of new ventures at navigating these issues will get you in trouble with PayPal/Stripe/etc, but not with Spreedly. And Spreedly does data portability amazingly, so there's no lock-in, unlike using a processor's vault: they'll give you your data if you want, or you can use their API to securely move it into the vault at a supported gateway.
The PCIDSS benefits are pretty huge too. With Spreedly billing info can be entered on your website but never touch your server (iframe or transparent redirect). Even under PCIDSS v3 (January 2015), you qualify for SAQ A, a short questionnaire, instead of SAQ A-EP or SAQ C most small sites taking cards directly fall under, which would require quarterly security scans and pen testing of your entire hosting and IT environment. Spreedly not only tokenizes and stores your customer billing info for you to charge, but can act as a proxy to pass it to 3rd parties like fraud screening systems, again without it ever touching your environment.
The issue I see with Spreedly is it would be a good thing to use from the beginning of the project, but it's not affordable when your first starting out.
Maybe a free package with the ability to store 20 cards? I don't want to pay $99 a month to basically hook up to your API and test it with my first few customers.
Yep. It's awesome that Dan mentions us and has a very valid use case with Spreedly. That said the use case we primarily solve for is marketplaces and platforms working across multiple gateways or third party API's (Expedia, StubHub etc) simultaneously. So I can see why you'd feel $99 was too high in your case. (Spreedly CEO)
Do you think there's enough interest to do a "low usage" (i.e. cheaper/free) option where you aren't hopping gateways and just want to use Spreedly as a processor abstraction layer? I'd love to investigate this for some little side projects that aren't tied to a processor, but $99/mo would be prohibitive.
Hey vcarl when we launched 2 years ago we actually had a $10 per month plan for the first 90 - 100 days after launch specifically to address this type of market. It didn't take. And honestly it wasn't really needed with Stripe and Braintree now in the market. Worse we had some perception problems from larger prospects around a service that was just $10 per month. So we moved up market to a higher price point to service marketplaces and platforms where our story really did resonate.
Agreed that it's too steep for people who want to use it as a hedge against negative payment processor action. We're Balanced customers and working on moving to Stripe now in time for the June 11 deadline, and I considered Spreedly to make it more cost-effective next time we have to switch, but it's just too pricey as a middleman for the small-ish volume we have. Most cart systems already make it somewhat easy to switch to a different payment processor.
Thanks cookiecaper. I would not disagree with you in general but I would say that in our experience most cart systems don't make it easy to switch payment processors _unless_ you don't care about storing or retaining cards for additional purchases or subscriptions. Most carts, for PCI reasons, pass your cards directly into the gateway so you're still stuck looking at export/import if you want to move.
