Migrating subscriptions and recurring payments

The one lock in that can end a business

Most of what a shop holds will move. Products, customers, orders, even saved cards will move with patience and the right paperwork. I say so in the pillar on what moves and what does not. Active subscriptions are the exception that can stop a move before it starts, and once in a while they can stop the business with it.

The reason is simple to state and hard to solve. Every other data type is, in the end, a record you copy. A live subscription is not a record. It is a running machine with money attached, and the machine has to keep running through the move without charging anyone twice, missing a charge, or losing the customer's agreement to be charged at all. This is the article the rest of the migration series builds towards, because it is the one place where getting it wrong is not a tidy up job afterwards. It is a closed shop.

So I will be blunt where it matters. Subscriptions can move. Sometimes they cannot, and you must find out which it is before you commit to anything, not after.

A subscription is a bundle, not a record

When someone says "move the subscriptions", they picture one table. In practice a single live subscription is a bundle of six things that must all arrive together and stay in step. Break any one and the billing breaks.

Part of the bundle	What it is	What breaks if it is lost
Plan and price	What the customer pays and for what	Wrong amount charged, or the wrong product
Schedule and next charge date	When the next payment runs, and the cadence	A missed charge or a charge on the wrong day
Billing history	Past invoices and payments	Tax records, refunds and disputes lose their anchor
Dunning state	Where a failing payment sits in the retry cycle	A customer already in trouble gets charged wrongly or cut off
Mandate or agreement	The customer's permission to be charged on a schedule	The charge becomes unauthorised
Payment token	The usable reference to the card or bank details	There is nothing to charge against

The payment token problem is hard on its own. I cover it in full in the spoke on payment tokens and saved cards, because saved cards belong to the processor, not to the shop, and only move processor to processor under strict rules. A subscription stacks a stateful billing engine on top of that token problem. You are not moving a card. You are moving a card, plus the agreement behind it, plus the clock that decides when it is charged, plus the memory of every charge so far. That is why it is the hardest thing in the whole migration.

The mandate and the token are two different things

This is the distinction most people miss, and it is the one that decides whether a move is even possible. A recurring charge needs two separate things to be valid, and they travel on different roads.

The first is the mandate: the customer's agreement to be charged on a schedule. For a SEPA Direct Debit this is a formal document with a Unique Mandate Reference and a Creditor Identifier, both mandatory elements of the mandate under the European Payments Council's rules.¹ For a card it is the stored credential plus the agreement that you may charge it when the customer is not present. The second is the token: the usable reference to the actual card or bank account.

You can have one without the other, and then nothing works. A card token with no valid agreement behind it is an unauthorised charge waiting to happen. A perfect mandate with no usable token has nothing to charge. Both have to survive the move.

The card schemes are strict about the agreement. Under the stored credential frameworks, the very first payment is treated as cardholder initiated, and the merchant must keep the transaction identifier from that first payment and send it with every later merchant initiated charge in the series.² Mastercard runs the same model: a merchant initiated transaction is a follow on to an initial cardholder action, and it has to reference the original stored credential.³ Move to a new processor and that chain of identifiers can break, because the proof of the original agreement sat with the old processor. When it breaks, the customer's bank may treat the next renewal as brand new and ask them to authenticate.

That matters because of Strong Customer Authentication. Under PSD2, the European Banking Authority confirmed that payments initiated by the payee alone, without the payer doing anything to trigger them, are not subject to SCA. Merchant initiated subscription charges fall into that category.⁴ But two parts still need authentication. Setting up the mandate through a remote channel is subject to SCA.⁴ And a card on file payment where the payer triggers each charge stays in scope.⁴ So the authentication belongs to the agreement, not to the token, and if you lose the proof of the original agreement you can push a whole subscriber base back into authentication prompts at the worst possible moment.

One thing never moves, ever: the card security code. PCI DSS prohibits storing it once the first payment is authorised, and that holds for card on file and recurring payments even with the customer's consent.⁵ I set out the standard and what it means for a shop in PCI DSS explained. You do not need the security code to charge a saved card, so this is fine, but it is a useful reminder that "just export everything" is never literally true.

What SEPA says about moving a mandate

Direct Debit is where the rules are kindest, if you follow them. A SEPA mandate is not tied to a single payment processor the way a card token is. It is an agreement between the creditor and the debtor, carried by a Unique Mandate Reference and a Creditor Identifier.¹

The European Payments Council has been clear that a change on the creditor's side does not automatically destroy the mandate. A change of the creditor reference party does not affect the validity of the mandate and needs no new mandate. A change of creditor itself is governed by the law of the relationship between creditor and debtor, and is handled through an amendment rather than by asking every customer to sign again.⁶ In the message flow, the amendment indicator is set and the original reference is carried alongside the new one, so the chain is preserved rather than cut.⁶

In plain terms: if the business keeps collecting under its own Creditor Identifier, or carries the mandates across with a proper amendment, the direct debits can continue without re papering every customer. The debtor still has to be told, and the Direct Debit scheme's notice rules apply, but the agreement itself can survive. That is a genuine advantage of Direct Debit over cards for a recurring business, and it is one reason I build DACH shops to lean on it where it fits, as I describe in DACH payments in Solidus. For a UK business the domestic equivalent is Bacs, which moves through its own bulk change process, covered in the hidden dangers of switching payment gateways.

The guillotine: when the platform or the app owns the schedule

Now the hard case, and the reason I treat this article as a warning as much as a guide.

Many rented platforms do not let you run subscriptions however you like. They run recurring billing only through their own payments product, or through one named gateway, and the vaulted tokens behind every subscription sit with that gateway, not with the merchant. Third party subscription apps do the same thing one level up: the schedule, the dunning state and sometimes the token live inside the app's own systems, not in your shop's database. While everything stays put, this is invisible. The day you try to leave is the day you find out who actually holds the keys.

I will tell this next part the way it deserves to be told, as a real and anonymised cautionary example. I will not name the business, and I will keep the gateway generic, because the point is the shape of the trap, not the brand.

A subscription business had grown to a healthy base of monthly subscribers. Its platform restricted subscriptions to its own payments product, which in turn was tied to one gateway. The vaulted card tokens were held by that gateway. The owner found a less expensive gateway with better terms and wanted to switch. That should have been a pricing decision. It was not, because the tokens could not be released to the new gateway, and the subscription schedules lived inside the platform's billing, not the owner's. Moving meant every subscriber would have to enter their card again.

The owner did what felt like the cautious thing and moved in halves. New subscribers went to the new, less expensive gateway. Existing subscribers were asked, in batches, to re enter their card on the old one. Predictably, a painful share never did. Now the business ran two billing systems, two reconciliations, two sets of dunning, and a shrinking base on the old side that it could not consolidate without triggering the same churn again. The half move was the worst of both worlds: all of the cost of running two stacks, none of the clean break. It did not survive the year.

The lesson is not "never switch". The lesson is that the token and the schedule are the whole ball game, and if the platform or the app owns them, you must know that before you sign anything, because by the time you are halfway across it is too late to change your mind without a painful loss.

What a clean subscription migration actually requires

Set against that, here is the honest list of what has to be true for subscriptions to move without forcing every customer to re enter a card. All four, not three.

First, the source releases the vaulted tokens to the destination processor through a PCI compliant, processor to processor migration. This is the card token problem the payment tokens article covers in full: the old processor sends the real card data directly to a processor certified at PCI DSS Level 1, encrypted, under an export that explicitly excludes subscriptions and billing history, so those have to be rebuilt separately.⁷ Ask for the scheme transaction identifiers in that export, so the proof of the original agreement travels with the token and customers are not thrown back into authentication.²

Second, the mandates are carried or set up again. SEPA mandates can be carried under the amendment rules above.⁶ Card agreements are carried by those transaction identifiers. Where neither is possible, you are into the fallback, and the fallback has a cost.

Third, the new store rebuilds each subscription's state faithfully: the plan, the next charge date, the remaining term, the dunning position. The card import does not carry any of this. Stripe, for one, imports saved cards and billing addresses but not subscriptions or invoices, and warns in plain words that you must cancel the old subscriptions as soon as the new ones are active or you will bill every customer twice.⁸ One owner of the next charge date per subscriber, at a known moment, or people pay twice.

Fourth, a parallel run and reconciliation before the first live charge. You rebuild the schedules, let both systems sit side by side, and compare what each one would charge, to the penny, before any real money moves. The first live charge on the new processor should be boring because you already proved it on paper.

If the first or the second of these is impossible, you are not migrating the subscriptions. You are re acquiring them. The honest name for the fallback is staged re authorisation: a communicated campaign that asks each subscriber to confirm their card on the new system, with real churn attached. It is sometimes the right call. It is never a detail to discover in the last week.

The churn is easy to size, which is the point of sizing it before you decide. The expected revenue lost to a forced re authorisation is a probability times an amount, an expected value (Foundations: expected value):

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

Here $L$ is the expected revenue lost, $N$ is the number of subscribers who must act, $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 an average subscriber would otherwise have stayed.

Worked example: a coffee box in Leeds

Let me put real shape on it with an invented business. Harlow Roasters is a coffee subscription in Leeds, trading at harlowroasters.example, run by Dani. It has 3,000 active subscribers paying £22 a month by saved card, and about 400 who pay by Direct Debit. Dani is on a rented platform whose subscriptions run only through its bundled payments product, and the agency bill plus the platform percentage has made a custom Solidus store look sensible. Nobody real, and every figure is invented so I can show the whole decision.

The move hinges on one question asked first, not last: can the tokens and the mandates come across? Dani's first task is not design. It is two emails and a contract read. One email to the current platform and gateway asking, in writing, whether the vaulted card tokens can be exported to another PCI DSS Level 1 processor, with the scheme transaction identifiers included. One reading of the Direct Debit setup to confirm the mandates sit under Harlow's own Creditor Identifier and can be carried by amendment.⁶

Say the answer on the cards is yes: the gateway has a documented export and will release the tokens with their identifiers. Then the Direct Debit side is carried by amendment, and the cards are rebuilt with their agreements intact. Dani rebuilds all 3,400 schedules on the new Solidus store, runs both systems in parallel for a full billing cycle, and reconciles every single next charge before a penny moves.

Now say the answer on the cards is no, as it was for the business in the cautionary example. Dani sizes the damage with the formula. With $N = 3{,}000$, a hopeful $q = 0.7$, $v = 22$ and $T = 9$ months, the expected loss is $3{,}000 \times (1 - 0.7) \times 22 \times 9 = 178{,}200$, so about £178,200 of expected revenue is at risk from a forced re authorisation of the card base alone. Against that number, a migration fee to a cooperative processor, or even staying put, looks very different. This is exactly the sum the owner in the cautionary example never put on paper before moving. The honest recommendation when the tokens cannot move is often to leave the subscriptions where they are and fix the lock in first, and I would rather say that than preside over a half move.

Here is the go or no go as a flow. Read it from the top. The first decision is the whole decision.

Dunning and failed payments through the move

Even a clean migration meets a wall of small failures, and a subscription business lives or dies on how it handles them. A card expires. A bank declines a renewal because it does not yet recognise the new merchant identifier. A customer's balance is short on the first of the month.

Two things keep the churn down. The first is good dunning: sensible retries on a schedule, not hammering a card the moment it fails, and a clear message to the customer when their card genuinely needs updating. The second is keeping the tokens fresh. Card account updater services and network tokens quietly replace expiring and reissued card numbers behind the scenes, so a renewal does not fail just because a customer got a new card in the post. These optimisations ride on the payment token layer, which is why the tokens spoke and this one are a pair, and Stripe among others offers card account updater and network tokens specifically to lift authorisation rates on migrated cards.⁷

The trap to avoid is the one from the earlier example: a new merchant identifier looks like a stranger to the card issuers, so declines rise at first. Move the easiest payments first, in batches, domestic cards before international, one off payments before recurring ones, and watch the decline rate on each batch before you move the next.⁷ That turns the switch into a dial you can turn down, not a cliff you fall off.

Doing it on Solidus, owned

Here is the resolution, and the reason the hard work is worth it. Once the subscriptions are on a custom Solidus store, they run on your own store and your own processor account. You are never again locked to a platform's payments product or to one named gateway. The schedule lives in your database, the dunning logic is yours to tune, and the processor is a choice you can change on your terms rather than a cage you discovered too late.

Solidus is the open source Rails commerce framework I build on. Recurring orders are handled by a subscriptions extension that creates a subscription for each group of subscribable items in an order and processes due installments on a schedule, with failed installments retried on later runs.⁹ Payments themselves go through a payment method that wraps a processor, and a refund is always processed back through the original payment's method, so old and new processors can sit side by side during the move.¹⁰ That is exactly the shape a careful migration needs: the new processor live for new charges, the old one still reachable for refunds and disputes, and nobody charged twice because each subscription has one owner of its next charge date.

The positive version of the cautionary example is almost dull. The tokens move because you chose a processor that releases them. The mandates carry because you kept your own Creditor Identifier. The schedules are rebuilt and proven in a parallel run. The first live charge is correct because you already reconciled it. And from that day on, the pricing decision the owner in the cautionary example wanted to make, choosing a better value processor, is yours to make whenever you like, because you own the store and the processor relationship both.

The one thing to confirm before you commit

So here is the whole article in two sentences. Subscriptions can move when the tokens can be released to your new processor and the mandates can be carried or set up again, and when each subscription's state is rebuilt and proven before the first live charge. This is the one thing in a migration you must confirm before you commit, never after, because a half moved subscription base is the worst of both worlds and sometimes the end of the business.

If you are weighing a move and your revenue runs on recurring payments, start with the two emails and the contract read, not the redesign. Find out who holds your tokens and your schedules. If the answer is "you do not", that is not a reason to despair, but it is a reason to solve the lock in first and move second.

Footnotes

1. European Payments Council, SDD mandate layout guidelines (Unique Mandate Reference and Creditor Identifier as mandatory mandate elements), EPC392-08 version 11.0, October 2025, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC392-08%20v11.0%20SDD%20Mandate%20Layout%20Guidelines_0.pdf ↩ ↩²

2. Visa Acceptance Solutions, Support for merchant initiated transactions and credential on file for Visa, Mastercard and Discover (initial cardholder initiated transaction, stored credential framework, transaction identifier carried on later merchant initiated transactions), 2026, https://support.visaacceptance.com/s/article/Support-for-Merchant-Initiated-Transactions-and-Credential-on-File-for-Visa-Mastercard-and-Discover ↩ ↩²

3. Mastercard, Credential on file transactions (gateway integration guidelines), Mastercard Gateway documentation, 2026, https://na.gateway.mastercard.com/api/documentation/integrationGuidelines/supportedFeatures/pickAdditionalFunctionality/storedCredentials.html ↩

4. European Banking Authority, Single Rulebook Q&A 2018_4031 (payee initiated transactions not subject to SCA, setting up a mandate through a remote channel is subject to SCA, card on file payments triggered by the payer remain in scope), final answer 1 March 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031 ↩ ↩² ↩³

5. PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions? (no, prohibited even with consent), 2026, https://www.pcisecuritystandards.org/faqs/1280/ ↩

6. European Payments Council, Clarification paper for the SEPA Direct Debit Core and SEPA Direct Debit B2B rulebooks (change of creditor reference party does not affect mandate validity, change of creditor handled by amendment with the original reference carried), 2026, https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/clarification-paper-sepa-direct-debit-core-and-sepa-direct ↩ ↩² ↩³ ↩⁴

7. Stripe, Import payment data to Stripe (export to a PCI DSS Level 1 processor, subscriptions, invoices and the security code not imported, new merchant identifier causes a temporary rise in declines so ramp up highest quality traffic first, card account updater and network tokens to lift authorisation on migrated cards), Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-import ↩ ↩² ↩³

8. Stripe, Migrate subscriptions to Stripe Billing (import subscriptions through the billing migration toolkit or the API, cancel your previous subscriptions as soon as the new ones are active or you will bill customers twice), Stripe documentation, 2026, https://docs.stripe.com/billing/subscriptions/migrate-subscriptions ↩

9. Solidus, solidus_subscriptions extension (subscriptions created per group of subscribable line items, due installments processed on a schedule, failed installments retried), solidusio on GitHub, 2026, https://github.com/solidusio/solidus_subscriptions ↩

10. Solidus, Payments and refunds (a payment is tied to its payment method and a refund is processed through the original payment's method), Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds ↩