"If I were you, no matter who you choose to integrate, I'd encapsulate it behind your own payment "service" so that even if you have to switch or you need to add more then one (highly recommended), then you can."

This is the best advice in the comments. I've seen my own code and others become overly coupled to a specific provider's terminology, mechanisms, and expectations - leading it to be exceptionally painful when you inevitably have to migrate away to a new provider (or support more than one).

For those in the ruby/rails world, there's a gem which does this (make it easy to switch between payment vendors) for you: Active Merchant (http://activemerchant.org/).

Yeah, but is there a gem for allowing me to switch payment abstraction gems?

ActiveActiveMerchant.

Awesome gem, thanks for that!

Dumb question, wouldn't rolling a wrapper over existing payment service also require me to store credit cards myself somewhere so I can easily switch integration later? If so, isn't that risky.

It is not unacceptable to ask for updated payment details every so often, so users don't generally have issues with this and it saves you from having to store the actual card details. You just have to store the token as others pointed out.

Also, if you do integrate multiple providers early on, you can break users up over them so that again your risk is minimized. This does come with some accounting pain, but it mitigates some risk so it is worth it. So essentially if you had to move away from one vendor it isn't your entire customer base all at once.

gentle plug - spreedly is a service that handles this for you. one of the guys in our coworking space uses this for his service, and it allows his customers to be able to swap processors relatively easily, as spreedly acts as a middle-man secure vault to hold that info away from any one particular service.

there may be other services that do something similar, but if you're concerned about switching services, and don't want to have all your customers reinput billing info, spreedly (or similar) would probably be worth investigating.

So you are spending a few $100 to a few $1000 a month in case you need to switch payment gateways down the road? I am not getting the business model.

Or... you need to support multiple, and they might change?

They support something like 90+ gateways around the world. Not everyone will necessarily need that flexibility.

But on the topic of switching....

How much is it worth to you to be able to switch without losing any recurring revenue? If you're OK with a potentially large portion of your recurring billing going away because you want or need to switch gateways, DIY is fine.

Again, not a direct user (though I've tested their API for a project), but I have colleagues using it, and for one in particular, the value it brings both in breadth of processors and potential for switching is extremely valuable to him (and his clients).

Ya this is tricky.

You can switch providers in a over time fashion by sending all new people to a new provider, and maybe sending out an "update your details" to existing people. If any existing users take action, move them over. If not keep billing on the old platform.

How often do you honestly need to switch gateways though? Most companies do it 0-1 times in the first 10 years of business I would expect.

No, not at all, as long as you aren't afraid to ask for someone's credit card again. You should also be able to transfer credit card information between services (which usually takes weeks and costs thousands, though).

In my experience, transferring between services didn't cost us a dime.

I know that transferring out of Zuora costs $5,000 per export.

As other said it's usually not a problem to ask again for the credit card, and when you switch payment services the users might actually see different details in their bank transactions, get billed with different delays or otherwise have billing problems.

Having a transition step where the users know something is changing can be helpful to cover the edge cases.

Generally, payment processors give you a token once a client gives them a credit card. You just need to abstract away the processor-specific code that uses that token.

You can use something like https://spreedly.com/

You could just ask your users to input their billing details again.

If you do a capture for say recurring monthly charges, not sure you can (legally and easily) capture card numbers to easily switch down the road? For one off charges it is easy to switch, but not for recurring, which is where I think these platforms "get you" by being sticky.