What a Braintree to Stripe migration actually costs

Moving a large e-commerce platform from Braintree to Stripe took four to five months. Much of that was preparation and testing rather than writing code. After the switch there were another two or three months of watching it and fixing things nobody had predicted.

Braintree and Stripe both do the whole job: they take the card details in the browser and they move the money. People call that a gateway or a processor depending on who they learned the words from, and the two are different things in a strict reading. I call them providers here, because what this post is about is the relationship with the company, not its position in the chain.

This was before any of the work was helped by AI tooling, so a part of it would be faster today. The part that would not be faster is the reason the project was long: both providers were live through all of it, and every order had its own answer to which one held the money.

You do not swap a payment provider. You run two of them for a while, and everything downstream has to know that.

You support both, and that is most of the work

The new integration goes in and the old one stays, and both have to keep working until the last order that started on the old provider has finished its life. That includes orders still open, subscriptions that renew next month, and anything a customer might come back and ask about six weeks later.

Nobody budgets for that period properly. The estimate people give is the cost of the new integration. The actual cost is that, plus however long both are alive, plus the work of deciding per request which one to talk to. For us the dual period was a problem during the migration and for months after it, not a transitional inconvenience that cleared up on switchover day.

The tokens are the part you cannot do yourself

Saved cards are the reason most companies never migrate. You do not hold the card numbers, and you should not want to. So the move is a transfer between two providers, arranged by the business but executed by them.

How it went in that migration: the old provider produced the list of stored tokens and the data attached to them, the business passed it to the new one, and the new one re-imported it on their side. What made it workable was the metadata that came with the list. It let us match the imported records back to our own customers and subscriptions, so both providers could be wired up at the same time and the old one could stay as a fallback for a while.

The import ran in two passes. Registered users first, guests afterwards. A registered account gives you an identity to hang the imported token on and a way to reach the person if something about their record comes out wrong. A guest purchase has neither, so it is matched through the order and there is nobody to email if the match is bad. Doing the harder group second meant the first pass had already shown what the import gets wrong.

That fallback matters more than it sounds. If the import turns out wrong in some way nobody anticipated, the alternative to a rollback path is asking a large number of customers to enter their card again, and a share of them will not.

Which is also the answer to whether lock-in is real. It is real, and both providers will still help you, because losing a merchant cleanly is better for them than being the reason that merchant is stuck and telling people about it.

Payment becomes a property of the order, not of the system

Before the migration the provider was effectively a system-level setting. One integration, one answer.

The moment real transactions exist in both, that stops being true. Each order has to carry which provider it belongs to, and every operation after checkout has to follow that instead of a config value. Refunds, partial refunds, subscription changes, retries, reconciliation with finance.

Most of the code that hurts is not in checkout. Checkout is the visible part and it is one path. The rest is spread through admin tools, reports, support screens and batch jobs written years earlier by people who had no reason to imagine two providers, and you find them one at a time. That is what those two or three months after the switch were mostly about.

The choice gets made on the front end

The two providers do not look the same in the browser either. Different SDK, different hosted card fields, a different flow for the customer. So this was never only a question of which server call to make.

The decision about which provider a given customer goes through was made on the front end, and the backend checked it again on the way in. A value that arrives from a browser is not a value you trust with money, even when your own code put it there.

What made that period manageable was running the split through a feature flag tool, in our case GrowthBook. The share of traffic going to the new provider was a setting that could be changed live, without a deploy. Start at a small percentage, watch the failures and the support queue, move it up. If something looks wrong at three in the afternoon, you turn it back down at three in the afternoon rather than preparing a release. For a change where the failure mode is a customer not being able to pay, that difference matters more than anything in the integration code.

PayPal does not move with you in the US

This one is nobody's engineering decision. PayPal through Stripe is only available to Stripe accounts based in the EU (except Hungary), Liechtenstein, Norway, the UK and Switzerland. A US-based account cannot turn it on. I checked that this is still true as of September 2026, and it is exactly the kind of thing that changes, so check it yourself before planning around it.

If you take PayPal in the US and you are moving to Stripe, you keep a second relationship regardless. Either the old provider stays alive for that one payment method, or PayPal gets integrated directly.

The tail nobody estimates

Refunds and chargebacks keep working during the migration, and both of them now have two homes.

The return policy sets how long this lasts, and the return policy is a business document, not an engineering one. An order paid through the old provider today can still come back for a refund in thirty or sixty days, whatever the company promises its customers. So the last day you can turn the old integration off is at least a return window after the last order that went through it, and usually later than that, because somebody will have an open case.

A chargeback is the same shape and worse, because the window is not yours at all. One arrives against a transaction on the old provider six weeks after everyone thought it was finished. A refund has to go back through the provider that took the payment, which sounds obvious and is a real branch in code somebody has to write. Finance reconciles two sets of statements and two payout schedules.

Fraud scoring was the one piece that did not move. It already sat with a separate vendor, above both providers, so changing the provider underneath it was not its problem. That is the clearest argument I have for keeping a decision like this outside the provider in the first place: the parts you separated earlier are the parts that cost nothing when the provider changes. Where exactly to draw that line is a question I come back to in a separate post about AI providers, where the switching cost is much lower than it is here and people worry about it much more.

None of the rest is hard in a technical sense. It is just long, and it lands on people who did not choose the migration.

Was it worth it

Yes, though not for any reason to do with the new API being nicer. And I would not call the result freedom from the vendor. The platform got out of one relationship by taking on a temporary second one, with help from both sides, and by accepting that it stays permanently a bit more complicated afterwards, because it now knows that a provider is a thing that can change.

The system became harder to reason about and possible to move. For a platform that size I think that was the right exchange. For a shop doing a few hundred orders a month I am not sure it is.

When I would not do it

If you have no stored cards and no subscriptions, the whole problem shrinks to rewriting one integration and you can move more or less whenever you like. That is most small businesses, and in my experience they worry about lock-in more than the situation deserves.

What makes the migration expensive is how much history the provider holds for you. If that history is small, move. If it is large, the question is not really how to avoid lock-in. It is what you are buying with the months it takes to undo it.