The hidden dangers of switching payment gateways, and a safe way to do it

A switch moves four things, not one

Changing payment provider looks like a settings change. New API keys, a new logo on the checkout, a lower fee. Underneath, four separate things have to move, and each one breaks in its own way.

The first is stored payment details: the saved cards and bank details that let you charge a customer again without asking. The second is the agreements behind repeat payments: card subscriptions and SEPA Direct Debit mandates. The third is money in flight: takings the old provider still holds, and the new provider's rules about when it pays you. The fourth is history: refunds, disputes and webhooks that keep arriving for payments the old provider took.

A shop with no saved cards mostly worries about the last two. A subscription shop or a SaaS product worries about all four, and the first two do the real damage.

I learned this the hard way years ago, moving a subscription shop between platforms. The saved cards sat in the old platform's built in payments, there was no route to get them out, and a painful share of subscribers had to type their card in again. Most did. Some never came back. Everything below is what I now check before anyone touches a key.

Worked example: what Harbourlight Coffee has to move

Throughout I use one invented business. Harbourlight Coffee roasts in Cork and sells at harbourlightcoffee.example. Clodagh runs it. Nobody real, and every number is made up so I can show every step.

Clodagh's shop has 2,200 subscribers paying €18 a month by saved card. It has 380 cafés buying wholesale beans, paying an average of €240 a month by SEPA Direct Debit. On top of that come one off orders. All card takings together average €1,600 a day.

So her four things are: 2,200 saved cards, 2,200 card subscriptions plus 380 Direct Debit mandates, about €1,600 a day of money in flight, and a good few months of orders that can still be refunded or disputed. Each gets its own plan below.

Saved cards cannot simply be copied

When a customer saves a card, your shop does not keep the card number. The provider keeps it and hands you a token, a stand in reference that only that provider can turn back into a card. The token is useless anywhere else. That is the point of it, and it is why a switch is hard.

To move the cards, the old provider has to send the real card numbers to the new provider, directly, encrypted. You never see them. Stripe, for example, will only send card data to a processor that is PCI DSS Level 1 compliant (the top tier of the card industry's security standard), and asks for that processor's attestation of compliance and a PGP encryption key of at least 4,096 bits.¹ Braintree asks for a PCI attestation from the receiving provider too, and allows no more than two exports: one for most customers and one for the customers created during the switchover.²

One thing never moves: the three digit security code. PCI DSS does not allow anyone to keep it once the payment it was collected for has been authorised, even encrypted, even with the customer's consent.³ You do not need it to charge a saved card, so this is fine, but it means "we'll just export everything" is never literally true.

The slow part is rarely the import. Stripe says imports usually complete within 10 business days of receiving correct data, but warns that the old processor can take anywhere from a few days to several months to produce the export.⁴ Some charge a fee, some want their own forms.⁴ And Stripe's export covers cards, emails and metadata, not payment history or subscriptions.¹

Worked example: Clodagh's export timeline

Clodagh asks her old provider for the export on 1 September. It asks for a signed form and the new provider's attestation. The paperwork goes back and forth, and the encrypted file lands on 20 October, seven weeks later. The new provider validates it, asks her to confirm the last four digits of two cards she knows, and finishes the import on 3 November.⁴

What she gets back is a mapping file: each old customer ID and card ID next to its new one.⁴ Her shop has to update every subscriber's record with the new references before the first renewal on the new provider. If she had planned the switch for 1 October, she would have been charging nobody.

Asking every customer again is the expensive path

If the old provider will not export, or you skip the export, every subscriber has to enter their card again. Some will. Some will not, and you lose them along with everything they would have paid.

The expected loss is easy to estimate:

$$L = N \times (1 - q) \times v \times T$$

Here $L$ is the expected revenue lost, $N$ is the number of subscribers whose card has to move, $q$ is the share who successfully carry on, so $(1 - q)$ is the share you lose, $v$ is the monthly price and $T$ is the number of months a subscriber would otherwise have stayed. It is an expected value, a probability times an amount: Foundations: expected value. How long a customer stays is the same idea as in Foundations: lifetime value.

Worked example: three paths for 2,200 subscribers

Clodagh compares three paths. The shares are my own planning assumptions, not industry figures.

Path one, ask everyone again. Say 70% enter their card, so $q = 0.7$. With $N = 2{,}200$, $v = 18$ and $T = 8$ months: $2{,}200 \times 0.3 \times 18 \times 8 = 95{,}040$. That is €95,040 of expected revenue gone.

Path two, import the cards but without proof of earlier authentication (more on that below). Say 15% of cards get an authentication request on the first renewal and 30% of those customers never complete it. That is $0.15 \times 0.3 = 0.045$ lost: $2{,}200 \times 0.045 \times 18 \times 8 = 14{,}256$, so €14,256.

Path three, import the cards with that proof and move subscribers in batches. Say 1% are lost to stubborn declines: $2{,}200 \times 0.01 \times 18 \times 8 = 3{,}168$, so €3,168.

Each bar is one migration path. The height is the expected revenue lost over eight months, in euro. The takeaway is the gap: asking everyone again costs roughly 30 times more than a careful import, which is why a provider's export process belongs in the decision before you sign, not after.

A new account looks like a stranger to the banks

Even a perfect import does not make the cards behave as before. Your new provider gives you a new merchant identifier. Card issuers have never seen it charge these cards, so some will decline at first. Stripe warns of a temporary rise in declines after a migration for exactly this reason, and recommends ramping up volume rather than switching everything at once: customer initiated and one off payments before recurring ones, domestic cards before international.⁴

That turns the switch into a dial instead of a cliff.

Worked example: Clodagh's ramp

Clodagh points new checkouts and one off orders at the new provider on 3 November. For two weeks she watches declines on those payments, which are her easiest traffic. They settle at her usual rate. On 17 November she moves the 200 Irish subscribers whose renewal falls that week. Declines on that batch run a little high, so she holds the next batch three days, then moves 500, then the rest. Her worst week costs 11 renewals that needed a friendly email, not 660.

Strong Customer Authentication follows the agreement

Strong Customer Authentication (SCA) is the EU rule that most online card payments need two of three checks: something the customer knows, has or is.⁵ In practice, that is the banking app prompt or the text message code during checkout. The Central Bank of Ireland notes that PSD2, the EU directive behind it, became law here on 13 January 2018 through the European Union (Payment Services) Regulations 2018 (S.I. No. 6 of 2018), with the detailed SCA rules in Commission Delegated Regulation (EU) 2018/389.⁶ The directive applies SCA where the payer initiates an electronic payment, or does anything through a remote channel that may carry a risk of fraud.⁷

The rule has an important gap for subscriptions. The European Banking Authority has answered that payments initiated by the payee only are not subject to SCA, as long as they happen without any involvement of the payer. That covers merchant initiated transactions, where the customer has given a mandate allowing you to charge them.⁸ Setting up that mandate online does need SCA.⁸ The same logic runs through the technical standards: SCA applies when a payer creates or amends a series of recurring payments, and the later payments in the series can go without it.⁵ So if you raise the price beyond what the original agreement covers, you need the customer to agree to a changed mandate, and doing that online brings SCA back in.

So the authentication belongs to the customer's agreement with you. The proof of it sits with the provider that took the first payment, as a network transaction ID. Stripe asks for these IDs in a card import, calls them mandatory for merchants affected by SCA, and explains that they let it apply for exemptions so customers do not have to authenticate again.⁹ Without them, the issuer may treat your next renewal as a new payment and ask the customer to authenticate. Customers who are not at their screen at 6am when the renewal runs will not do that. Stripe says plainly that exemptions are never guaranteed and that the bank can still ask.¹⁰

Worked example: do not raise the price in the same month

Clodagh had planned to raise the subscription from €18 to €20 in November, the same month as the switch. Her terms said the price was €18, with no clause about changes. The €20 renewals would no longer be payments made under the agreement without her customers' involvement. Each subscriber would need to agree to a changed mandate, and agreeing online is the kind of remote action that needs SCA.⁸ Combined with the move to a new merchant identifier, that would put almost every subscriber in front of an authentication request at once.

She splits them. The switch happens in November on the old price. In January she emails subscribers about the new price, asks them to confirm, and renews at €20 only once they have. One risky change at a time.

Direct Debit has its own road: SEPA mandates keep their references

Direct Debit works differently from cards. In Ireland it runs on the SEPA Direct Debit Core scheme, under the European Payments Council's rulebook. There are no card numbers. There is a mandate, the payer's signed authorisation, and in SEPA it is the creditor (you) who receives and stores it, not the payer's bank.¹¹ Each mandate carries a unique mandate reference, which must be unique in combination with your creditor identifier.¹¹ The creditor identifier names you in the scheme. In Ireland your own bank issues it, and an Irish one looks like IE19ZZZ123456, with the old six digit originator number inside it.¹² Direct Debits are initiated by the payee without the payer doing anything, which is why they sit outside SCA, by the same reasoning as above.⁸

Because the mandate is an agreement between you and the payer, it can move to a new provider without a new signature. Stripe's import creates a new mandate object that uses the same mandate reference and represents the same agreement, and says no new information is needed from the customer.⁹ Where something on the mandate does change, the rulebook treats it as an amendment, sent with the next collection, not as a new mandate. The amendments it names include a new mandate reference, a new creditor identifier and a new creditor name.¹¹ One more housekeeping rule: a mandate with no collection for 36 months must be cancelled, so a dormant café account cannot simply be revived on the new provider.¹¹

The creditor identifier is the part to watch. Stripe uses its own creditor identifier by default, recommends that businesses in the EU use their own, and says you cannot change it in the Dashboard once live SEPA payments have been collected.¹³ If your old provider collected under its own identifier, the switch changes the name and identifier on every payer's bank statement. If you collect under your own, issued through your bank, it stays the same on both sides of the switch.

Payers must be told. Stripe asks you to inform customers before the migration, says they do not need to give permission again, and lists what to point out: a changed creditor identifier or creditor name, and the receiving IBAN.⁹ Separately, every debit needs a pre notification. The rulebook says it must reach the payer at least 14 calendar days before the due date, unless you agree another timeline with them.¹¹ Stripe's list of what it must contain includes the amount, the mandate reference and your creditor identifier.¹³

The timing is short compared with cards, but rigid. The collection must reach the payer's bank at least one interbank business day before the due date.¹¹ Stripe then makes the money available six business days after submission.¹³ And a new account starts small: Stripe sets a weekly SEPA Direct Debit limit of €10,000 for new users, which rises as you collect more, and asks you to contact support if you need more from the start.¹³

Worked example: 380 cafés

Clodagh's wholesale cafés pay on the first business day of the month, €91,200 in total ($380 \times 240$). In November that is Monday 2 November. Years ago her bank issued her own creditor identifier, and every café's mandate carries it. That one detail makes her switch quiet: nothing on the cafés' statements changes except the collecting account.

She asks for the mandate file in the same request as the cards, on 1 September, and asks the new provider in writing to raise her SEPA limit before any café moves. In early October a short letter tells the cafés the mandates stay valid and nothing needs signing. On 19 October her usual pre notification for November goes out, 14 days before the due date, with the same creditor identifier and the same mandate references as always. On 20 October the mandates are imported with their original references, and she stops the café collections on the old provider from the same list that afternoon.

The November collection is submitted on 28 October, well inside the one business day rule, and the €91,200 is in her new balance around 5 November. Had she skipped the limit request, a €10,000 weekly cap would have stopped about €81,200 of it going out that week. She picks the dates around her collection day, not around the provider's diary.

Your customers can claim Direct Debits back for months

Card disputes come up again below. Direct Debit has its own refund rights, and they are generous to the payer. Within eight weeks of a debit, the payer's bank refunds it on a no questions asked basis. For a debit the payer says was unauthorised, the claim can come up to 13 months after the debit date.¹¹ These rights are EU law, not only scheme rules: PSD2 gives a payer an unconditional right to a refund of a direct debit for eight weeks (Articles 76 and 77), and an unauthorised payment must be reported within 13 months and refunded straight away (Articles 71 and 73).⁷ The Central Bank of Ireland describes the eight week refund as a right SEPA already gave consumers, now written into EU law.⁶

The refund is recovered from the creditor's provider, which recovers it from you.¹¹ For a debit the old provider collected, that means the old provider and the old account. Unlike a card dispute, a SEPA Direct Debit refund is final, and Stripe notes there is no appeal.¹³

Money in flight: payouts and reserves

A new provider does not pay you on the old provider's timetable. Stripe, for instance, typically schedules a new account's first payout to complete within 7 to 14 days of the first live payment, depending on industry, country and risk level.¹⁴ A provider may also hold back part of your takings as a reserve. Stripe describes a reserve as a temporary hold on a portion of a business's funds, uses fixed and rolling reserves, and sizes them on industry conditions, payment activity, dispute rate, refund rate and financial stability.¹⁵

Meanwhile, the old provider pays out what it still holds on its own schedule. For a few weeks, money arrives from two places, later than usual, and some of it is parked. That is a cash flow problem, and it is easy to size:

$$G = R \times d + \rho \times R \times w$$

Here $G$ is the cash gap in euro, $R$ is the average daily card takings, $d$ is the number of extra days before the first payout compared with your current timing, $\rho$ is the reserve share, and $w$ is the number of days each payment sits in a rolling reserve. The first term is the delay, the second is the money that sits in the reserve at any time once it is running. Both are rates multiplied by time: Foundations: ratios and rates.

Worked example: Clodagh's cash gap

Clodagh's takings are $R = 1{,}600$ a day. Her old provider pays out two days after each payment. The new one's first payout arrives on day seven, so $d = 5$. The new provider sets a 10% rolling reserve for 30 days, so $\rho = 0.1$ and $w = 30$.

The delay: $1{,}600 \times 5 = 8{,}000$. The reserve: $0.1 \times 1{,}600 \times 30 = 4{,}800$. Together, $G = 12{,}800$. Clodagh needs €12,800 of cash or credit to cover the switch, before she pays a single coffee farmer. So she agrees the reserve terms in writing before signing, not after.

The old account keeps working after you leave

The day you stop taking payments with the old provider is not the day you are finished with it. Two things keep pointing back at it.

Disputes first. Card networks typically allow cardholders to dispute a payment within 120 days, sometimes longer. You then usually have 7 to 21 days to respond, and the issuer usually has 60 to 75 days to decide.¹⁶ A dispute pulls the money and a fee from the balance of the account that took the payment.¹⁶ On the old provider, that means the old account. Direct Debit refunds on its old collections land there too, for the eight weeks and the 13 months above.

Then refunds you give yourself. A refund can only go back to the original payment method used in the charge, never to another card.¹⁷ The new provider cannot refund a payment it never took. The old one does, from its balance, and Stripe holds card refunds as pending if that balance cannot cover them.¹⁷ Stripe also notes that you keep access to your data after you stop processing, as long as you do not close or delete the account.¹

Worked example: one refund, one dispute

Clodagh switches on 3 November. On 28 October, a customer bought a €129 grinder on the old provider. It arrives broken and the customer asks for a refund on 12 November. The refund must go through the old provider, back to that card. Her old balance is zero, because the final payout on 6 November swept it. The refund sits as pending until she tops the account up.

Then, on 20 February, someone disputes a €54 gift box from 2 December, 80 days after the payment and still inside the window. The old provider debits €54 plus its fee. If she had closed the account in January, she would have been chasing it by email instead of answering it in the dashboard.

Her rule now, and mine: keep the old account open, with a small float in it, for at least six months after the last card payment it took. For the cafés, the last old collection was on 1 October, so an unauthorised claim could still reach that account until November of next year. She keeps it open until then.

Webhooks and reconciliation need both providers

A webhook is a message the provider sends to your shop when something happens: a payment succeeded, a refund failed, a dispute opened. During a switch you have two senders, and both need a working address.

Stripe retries an undelivered webhook for up to three days in live mode, does not guarantee the order events arrive in, and can occasionally send the same event twice. It recommends recording the event IDs you have processed and ignoring repeats.¹⁸ Delete the old provider's endpoint on switch day and you silently lose the late refund failures and disputes from the section above.

A small table does most of the work. One row per processed event, with a unique index on provider and event ID:

class ProcessedEvent < ApplicationRecord
  # One row per webhook event already handled, from either provider.
  # Migration: add_index :processed_events, [:provider, :event_id], unique: true
  validates :provider, :event_id, presence: true
end

def handle_once(provider, event_id)
  ProcessedEvent.create!(provider: provider, event_id: event_id)
  yield
rescue ActiveRecord::RecordNotUnique
  # Already handled. A duplicate delivery is not an error.
end

In a real shop the create! and the work inside yield belong in one database transaction, so a failure halfway does not mark the event as handled.

Reconciliation, matching payouts in the bank to orders in the shop, needs the same discipline. Every payment record should say which provider took it, and every payout line should carry the provider's payout reference.

Worked example: the two payouts on 6 November

On 6 November Clodagh's bank shows two credits. One is €3,140 from the old provider: the final payout for 1 and 2 November, which leaves that account at zero. The other is €1,412 from the new provider, its first payout, less the reserve. Her bookkeeper matches each to orders by provider and payout reference. Without the provider stored on each order, the two would have looked like one muddled day.

Subscriptions must move exactly once

If your subscriptions are run by the provider's billing system, the schedules have to move too, and the card import does not carry them. Stripe imports cards and billing addresses, not subscriptions or invoices, which move through a separate toolkit, and it warns that you must cancel the old subscriptions as soon as the new ones are active or you will bill your customers twice.⁴

Double billing turns a quiet migration into a pile of disputes. So for each subscriber, one system owns the next renewal date, and the handover happens at a known moment.

Worked example: one batch, one owner

Clodagh's subscribers renew on different days through the month. Her first batch is the 200 who renew in the week of 17 November. On 14 November she imports their schedules on the new provider and cancels the old schedules for the same 200 that afternoon, from the same list. Her check the next morning is a simple count: 200 active schedules on the new provider for that batch, zero on the old one. She repeats it for every batch.

Had she left both running, those 200 would each have paid €18 twice, €3,600 taken that she would have had to refund. Across all 2,200 subscribers, the same slip costs €39,600 and a month of apologetic emails.

Where the shop software helps: Solidus keeps payment methods apart

How painful all of this is also depends on your shop software. In Solidus, the open source Rails shop framework I build on, the shop talks to a payment method, not directly to a gateway, and the gateway is a helper class wrapping one provider's API.¹⁹ Each payment links an order, a payment source and a payment method, and a refund is processed through the original payment's payment method.¹⁹ In the code, a refund calls the original payment's method with the original transaction ID.²⁰

Payment methods also carry separate switches for being active, available to customers and available to the admin.²¹ That fits the switch nicely. The new method goes live for customers at checkout. The old one stays active for the admin, so refunds on old orders still go back through it, without customers ever seeing it.

Worked example: old and new methods side by side

Clodagh's shop has the old provider as one payment method and the new provider as another. On 3 November she makes the new one available to customers and switches the old one off for customers but leaves it available to the admin. The broken grinder from 28 October is refunded from the order screen, and Solidus sends it through the old method automatically, because that is the payment's method. Nobody has to remember which provider took which order.

A safe plan runs both providers in parallel

Put together, the safe plan is not one switch day. It is a few weeks of running both, moving one group at a time, with the old account kept alive long after.

Read it from the top. The export request comes first because it is the slowest step and you do not control it. Each batch is checked before the next, so a problem costs one batch, not the whole base. The old account closes last, after the dispute and refund windows.

Worked example: Clodagh's calendar

1 September: card and mandate export requested, higher SEPA limit requested. Early October: letter to the cafés. 19 October: November pre notification sent. 20 October: SEPA mandates imported under her own creditor identifier. 3 November: cards imported, new checkouts live. 17 November onwards: subscribers moved in three batches, 200, then 500, then the rest, each with its old schedules cancelled the same day. Early December: every subscriber renewing on the new provider. June: the card side of the old account goes quiet, six months after its last card payment. November next year: old account closed, 13 months after its last café collection. Three months for what looked like a settings change, and nobody charged twice.

What I ask a provider before anyone signs

Most of this is decided before the first payment, in the contract and in the documentation. I ask every provider the same questions, and I want the answers in writing:

1. How do I export saved cards to another PCI DSS Level 1 provider, how long does it take, and is there a fee?
2. Do you include network transaction IDs in an export, and can you import them?
3. How do you import and export SEPA mandates with their original references, can I collect under my own creditor identifier, and what is my Direct Debit limit in the first weeks?
4. When is the first payout, what is the normal schedule, and will you hold a reserve?
5. How long can I keep the account open after I stop processing, to handle refunds and disputes?

A provider with a published export process, like the ones I cited above, is a provider you can leave. That is worth more than a lower fee, because a provider you cannot leave can set the fee later. It belongs in the same checklist as the data protection questions in vetting vendors before they undermine your compliance, and in the cost model when you move a shop to Solidus. If you are weighing whether a switch is worth it at all, expected value for founders is the honest way to compare the saving with the risk.

The switch itself is not dangerous. Doing it in one day is.

Footnotes

1. Stripe, Request a payment data export, Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-export

2. Braintree (PayPal), Data Migration: Exports, Braintree developer documentation, 2026, https://developer.paypal.com/braintree/articles/get-started/data-migration/exports

3. PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions?, PCI SSC, 2026, https://www.pcisecuritystandards.org/faqs/1280/

4. Stripe, Import payment data to Stripe, Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-import

5. European Commission, Commission Delegated Regulation (EU) 2018/389, regulatory technical standards for strong customer authentication and common and secure open standards of communication, Articles 4 and 14, EUR-Lex, 2018, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018R0389

6. Central Bank of Ireland, PSD2, Central Bank of Ireland, 2026, https://www.centralbank.ie/regulation/psd2-overview

7. European Parliament and Council, Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Articles 71, 73, 76, 77 and 97, EUR-Lex, 2015, https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32015L2366

8. European Banking Authority, Single Rulebook Q&A 2018_4031: card payments initiated by the payee on the basis of a mandate, EBA, 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031

9. Stripe, Import payment method data (cards: migrate proof of Strong Customer Authentication; SEPA), Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/payment-method-imports

10. Stripe, Strong Customer Authentication readiness, Stripe documentation, 2026, https://docs.stripe.com/strong-customer-authentication

11. European Payments Council, SEPA Direct Debit Core Scheme Rulebook, EPC016-06, 2025 version 1.2, sections 3.1, 4.2, 4.3, 4.6.2 and 4.8, EPC, 2026, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2026-09/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.2.pdf

12. Bank of Ireland, SEPA Frequently Asked Questions, Bank of Ireland Business Banking, 2013, https://businessbanking.bankofireland.com/app/uploads/2016/07/SEPA-Frequently-Asked-Questions-PDF.pdf

13. Stripe, SEPA Direct Debit payments, Stripe documentation, 2026, https://docs.stripe.com/payments/sepa-debit

14. Stripe, Receive payouts, Stripe documentation, 2026, https://docs.stripe.com/payouts

15. Stripe, Reserves: frequently asked questions, Stripe Support, 2026, https://support.stripe.com/questions/reserves-frequently-asked-questions

16. Stripe, How disputes work, Stripe documentation, 2026, https://docs.stripe.com/disputes/how-disputes-work

17. Stripe, Refund and cancel payments, Stripe documentation, 2026, https://docs.stripe.com/refunds

18. Stripe, Receive Stripe events in your webhook endpoint, Stripe documentation, 2026, https://docs.stripe.com/webhooks

19. Solidus, Payments and refunds, Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds

20. Solidus, core/app/models/spree/refund.rb, solidusio/solidus on GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/refund.rb

21. Solidus, core/app/models/spree/payment_method.rb, solidusio/solidus on GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/payment_method.rb