Discuss Home · Bootstrapped Podcast · Scribbleton Personal Wiki · HelpSpot Customer Service Software

Changing payment processors - Subscriptions


Hi guys,
I am trying to figure out how hard or easy it is to switch payment processors once you start using them and have some recurring payments customers. Eg. FastSpring to Stripe or Stripe to FastSpring

I am assuming once a new customer is entered in the payment processor’s system a new customer record ( with data like name, address, credit card details etc) must be getting saved .

So if you decide to switch provider you might have to download all the customer records and move them to a new provider and this I heard is tricky . The PCI DSS rules or something makes it difficult ?

Has anyone have had any experience with switching payment processors ?



Ah found the link where I read about PCI stuff -

7: Don’t try to change your payment provider

Your credit card payment processing provider (credit card clearing) will lock you in. At the time we have started, Stripe was not available in Europe. So we settled with WireCard. Stripe is here now and we considered to switch. But — being PCI compliant — you don’t store your clients credit card credentials yourself. So switching payment gateway means that your clients need to re-enter their credit card credentials. No way.

source: https://www.reddit.com/r/startups/comments/42xl1x/9_billing_mistakes_to_avoid/?ref=share&ref_source=link


We migrated from Authorize.net to Stripe several years ago. We worked with Authorize.net and Stripe together to transfer payment details from one payment provider to the other. It wasn’t click-and-done easy, but it also wasn’t much more than wrangling people from both companies to perform the transfer. Here’s the blog post I wrote up when we made the switch: https://blog.dnsimple.com/2014/07/switching-from-authorize-net-to-stripe/


Great info, thanks for the detailed post !
Coordinating between the providers must have been a daunting task. Good that support folks Charigify and Stripe agreed to talk to each other directly.

But since 2014 till date Stripe has grown enormously , wonder if their support is still good ?


I worked for Stripe for about a year on ‘Developer Support’ (basically helping people integrate, fix issues, etc) and that team is also responsible for data migrations. While doing that I even moved my (now defunct, for the most part) side project Bugrocket from Braintree to Stripe.

So, from the export-from and import-to Stripe perspective, I can give you a pretty detailed breakdown. IMO it’s really very simple and smooth.

Let’s assume you want to move to Stripe:

  1. Contact your current payment provider and discuss your intent to move. Provide them with (an HTTPS link to) Stripe’s Data Migration PGP key. Also contact Stripe and discuss your intent to move. They’ll basically just say cool either have your current provider let us know when the export is ready or let you know and then tell us.
  2. Your current provider should be essentially creating a CSV or similar file with all of your customer data (not subscription info) and then encrypting it with Stripe’s key. Most providers have their own similar keys and so this should generally be true going Stripe->somewhere else (eg here is Braintree’s). Once ready, ideally, they should encrypt credentials which Stripe will use to retrieve the export, from someplace like perhaps an FTP server, also with the data migration key. Sometimes they’ll just provide these (encrypted) credentials to you to avoid having to contact Stripe and have them figure out for whose data these credentials are for.
  3. Once Stripe has your data they decrypt and just go ahead and create customers in your account as closely matching the data from the export as possible given Stripe’s customer schema. Then they’ll provide you with a mapping of your previous provider IDs to new Stripe customer and/or card IDs.
  4. Take that mapping, and write some kind of script on your end to look at your customers and re-create their current subscription state in your app on Stripe. I put a payment_provider field on my accounts and set it to braintree and then I just went through each one and made new subscriptions for them on Stripe etc, and set it to stripe. Once everyone is set to stripe you’re done.

The biggest effort on your part would be step 4 of course. But really it wasn’t that complex to do that myself with my app. The trickiest part was figuring out any mismatches between how Stripe works and the other provider works. Definitely spend some time in the docs before attempting it. You may also want to start using Stripe for new customers before the migration so that you can leisurely convert your old ones over without having to worry about another migration for people who were new between the last one and when you’re ready to switch people over.

Also worth noting that not all providers are created equal, so sometimes they dig in their heels on some of the stuff in the list above. Like Authorize.net, they refuse(d?) to use Stripe’s GPG key and instead have just some kinda password protected archive. I forget the name but we had quite a few imports from some antiquated provider that insisted on mailing Stripe a CD :scream:. PayPal just ignores all attempts at communication for the most part, of course. And so on.

Still, 99% of the time it’s just a few days long process of coordination, and then a bit of a dev project for you once the card info you need is in your new account.

I hope that’s useful, and if you have any other questions about data migrations - I’d be happy to help out. As, I’m certain, would the helpful folks over in the Stripe IRC channel (#stripe on Freenode).


A few months ago we migrated from Braintree to Stripe with no issues. As @rfunduk said, the biggest effort is to map all your current subscriptions in Stripe. But we can do it easily in one day.

Take into account that FastSpring is not a payment provider like Stripe or Braintree. They are a reseller. You need to check out what payment processor they’re using and how easy is to migrate customers’ records to another processor.


When we changed payment processors we mainly did it organically. We had both processors running in parallel and if someones credit card expired or some other reason that required them to re-enter their credit card details they would be registered with the new provider. This is of course slower, but transparent to the users. Some of them we did nudge by asking them to re-enter their details when not really required.


This also has an extra benefit of lower risk. If you screw up mapping the subscriptions to the new provider, you can deal with that problem one subscriber at a time instead of finding your whole user base has an issue.