🚚 Switching payment providers: how to run a PSP migration

What to negotiate before signing

Exit provisions are the contract clauses under which a payment service provider agrees to hand over the data a merchant needs to keep doing business with a competitor. They exist only in the contract. No card network rule and no PCI DSS requirement obliges a provider to return the card vault it holds for a merchant. A merchant that raises the issue on the way out has no leverage outside the contract, and the outgoing provider has no interest in arranging its own replacement. That is why the negotiation belongs at onboarding, while the provider is still competing with other bidders and the clause costs it almost nothing to concede.

The initial contract settles several points that no later document will. The vault export format comes first, because a file delivered in an undocumented proprietary structure is a refusal in disguise. Next comes the deadline, counted from the merchant’s written request rather than from a termination date. The recipient is never the merchant itself but a certified provider the merchant names in its request. The export fee is set at zero. That leaves the fate of technical identifiers, including the token requestor ID, and the schedule for releasing the reserve after the last transaction processed.

Three EU regulations bear on switching providers, with different reach. Regulation (EU) 2016/679 (GDPR) gives a portability right to the data subject, not to a merchant that entrusted a card file to its provider. A merchant invoking it therefore gets nothing back from its vault. Regulation (EU) 2022/2554, known as DORA, which has applied since January 17, 2025, requires an exit strategy for IT services that support a critical or important function. Its Articles 28 and 30 make a transition period a mandatory contract clause. That regime binds only EU financial entities. A retailer falls outside its scope while its provider falls within it, which gives the retailer negotiating leverage but no legal right. Regulation (EU) 2023/2854 on data governs switching between data processing service providers and abolishes switching charges as of January 12, 2027. Whether it applies to a payment gateway is not settled, and no exit plan should depend on it.

The card vault moves without passing through the merchant

A merchant must never receive card numbers, which is why the vault transfer is arranged between the two providers. A PAN file dropped on a merchant server brings that server into PCI DSS scope and moves the business from the SAQ A self-assessment questionnaire to SAQ D. The exchange therefore happens directly between environments. Both the outgoing and incoming providers are assessed as service providers. The merchant orders the transfer in writing and names the recipient, without handling the data itself. Keeping the data away from the merchant sets next year’s compliance cost, since the merchant’s assessment scope stays unchanged.

Vault exports follow a well-established sequence from one provider to the next. The merchant sends the outgoing provider a signed request that names the incoming provider and attaches its attestation of compliance. The outgoing provider checks the attestation, then produces an encrypted file with the card numbers, expiration dates, and internal linking IDs. The public key comes from the incoming provider. The decryption key never travels over the channel that carries the file. The incoming provider imports the file, re-tokenizes the numbers in its own vault, and returns a mapping table between its IDs and the outgoing provider’s. The whole export is unusable without that table: the merchant would hold cards it can no longer match to each subscriber.

• A single written request that names the incoming provider, attaches its attestation of compliance, and sets the expected delivery date.
• A channel agreed in advance, with a public key supplied by the incoming provider and a file hash sent through a separate channel.
• A mapping table between outgoing and incoming IDs, without which the link to each customer is lost.
• A test sample, tokenized and then authorized for a small amount before cutover, to measure the provisioning failure rate.
• A dated attestation of destruction, covering the vault but not legally required archives, delivered after sign-off.

The export covers only part of the payment data. Sensitive authentication data, including the card security code, may not be stored after authorization under PCI DSS Requirement 3.3.1. The security code is therefore never in an export. Any flow that needs one at the new provider must go back to the customer. The file also excludes dispute history, fraud scores, and blocklists built at the outgoing provider. Those must be requested separately and in writing, because no market practice transfers them with the vault.

Purging the account data closes the operation. Treat it like a deliverable, with a date and proof. PCI DSS requires a policy for retaining and deleting account data. The standard adds at least a quarterly check of what is stored beyond business need, and destruction of electronic media once the data is no longer needed. It does not, however, define any certificate of destruction. The document the merchant wants is therefore contractual, and the merchant has to draft it. It must separate two things the outgoing provider has an interest in blurring: the card vault on one side, transaction and compliance archives on the other. The vault is deleted after sign-off; the archives are kept, because anti-money laundering rules and dispute handling still require them.

Tokens, and what doesn’t transfer

A payment token is a substitute number issued in place of the card number for a specific requestor. The EMVCo tokenization specification binds each token to that identified requestor, the token requestor, to which the token service provider assigns its own ID. The token is issued for that requestor and restricted in how it can be used. It works for no one else. The requestor’s identity therefore decides what happens to the tokens when a merchant changes providers. If the requestor is the provider, the tokens stay with it when the merchant leaves. If the requestor is the merchant, enrolled network by network under its own ID, the tokens follow the merchant, and the migration no longer has to reprovision the whole portfolio at the new provider.

Reprovisioning happens without the customer, from the exported numbers. The new provider requests a token from each network under its own requestor ID and receives a new token for each card. There is no visible friction, as long as the exported numbers are accurate and the new provider is enrolled with the same networks. But it is billed. Network fee schedules include provisioning and lifecycle line items, which will be charged a second time for a portfolio that was already tokenized. Those fees appear on the first month’s invoice, and a migration budget that leaves them out understates the cost.

The Payment Account Reference (PAR) is an EMVCo-defined identifier that stays the same for a given account across all its tokens. It shows that a new token refers to the same cardholder as an old one, without ever revealing a card number. A merchant that requires the PAR in its data feeds and reports can audit its migration line by line, even when the mapping table is missing or incomplete. Automatic card updater services work differently: the enrollment belongs to the acquirer and doesn’t carry over. Request re-enrollment as soon as the account opens at the new provider; the history of updates already received stays with the outgoing one.

Recurring payments: card transaction chaining and SEPA mandates

Recurring card payments rely on linking the first transaction to the installments that follow. The first transaction is customer-initiated and authenticated, and the network assigns it a transaction ID. Subsequent installments are merchant-initiated, without the customer present, and must carry two data elements to be processed as such. They carry the stored credential indicator, which tells the network that the card was stored with the cardholder’s consent. They also carry the reference of the initial transaction, which ties the installment to an authentication already completed. Both elements come from the provider that processed the first transaction, and no new provider can generate them.

When the reference is lost, only one option remains: run a new customer-initiated transaction. The merchant brings the subscriber back through an authenticated flow, obtains a new chaining reference, and resumes the billing cycle. This restores the chain, but it exposes the merchant to churn, since the request puts the customer back in front of a decision to resubscribe. The churn rate depends on the sector, price, and channel, and no public data can reliably predict it. A careful merchant starts with low-value cohorts, measures the actual churn, and then sets the order for the rest.

SEPA Direct Debit relies on a mandate signed between a debtor and a creditor, which names the creditor along with its identifier. The mandate itself therefore shows who owns it. If the name on it is the merchant’s, the mandates belong to the merchant, and switching providers changes only the technical chain that submits the collections. If it is the provider’s, the provider is collecting on the merchant’s behalf under its own creditor identifier, and the mandates leave with it.

A mandate amendment keeps an existing mandate in force while changing one of its elements, without a new signature from the debtor. The European Payments Council rulebooks provide for it within the collection file itself. The direct debit message then carries an amendment block restating the original creditor identifier, the original unique mandate reference (UMR), and, if applicable, the previous bank details. The debtor must be notified beforehand. The mandate survives with its original signature date. That matters, because if a mandate cannot be produced, the debtor has 13 months to claim a refund.

<MndtRltdInf>
  <MndtId>UMR-2019-004871</MndtId>
  <DtOfSgntr>2019-03-14</DtOfSgntr>
  <AmdmntInd>true</AmdmntInd>
  <AmdmntInfDtls>
    <OrgnlMndtId>UMR-2019-004871</OrgnlMndtId>
    <OrgnlCdtrSchmeId>
      <Nm>Former creditor</Nm>
      <Id><PrvtId><Othr>
        <Id>FR72ZZZ123456</Id>
        <SchmeNm><Prtry>SEPA</Prtry></SchmeNm>
      </Othr></PrvtId></Id>
    </OrgnlCdtrSchmeId>
  </AmdmntInfDtls>
</MndtRltdInf>

The creditor identifier designates the creditor in every mandate and every direct debit collection file. Getting one takes time, and that lead time drives the migration schedule. The issuing body and the application channel vary by country. In France, the Banque de France (France’s central bank) keeps the register, and the application goes through the creditor’s bank, which also checks that the applicant can manage its mandates. In Germany, the creditor applies directly to the Deutsche Bundesbank, online and without going through a bank. A merchant moving away from a model in which a provider collects on its behalf must therefore file this application before negotiating anything else. Without an identifier, no collection can be submitted. The migration timeline is set by that lead time, not by commercial plans.

Cutover in cohorts, with a parallel run

Cutover is the point at which payment processing actually moves from one provider to the other. It is done in successive cohorts. Both providers stay live for several weeks in a period of parallel processing known as a parallel run (or double run), and the routing rule between the two stacks sits on the merchant’s side. The first cohort is small and deliberately ordinary: low-value recurring customers in a single country, on a single payment method. It proves that the stack works end to end, from token provisioning to payout and the reconciliation entry. Later cohorts expand one variable at a time, because expanding several at once makes it impossible to trace an anomaly to its cause.

From the issuers’ point of view, changing acquirers creates a merchant with no track record. The merchant ID changes, the acquirer BIN changes, and the descriptor on the cardholder’s statement almost always changes. Issuers and their fraud vendors score a transaction partly on the merchant’s history with that acquirer, and that history starts again from zero after cutover. An empty history is not the same as a good one. The size of the effect is not published. Providers that quote a figure measure it on their own portfolios, with no independent verification.

The statement descriptor is the text that identifies the merchant on the cardholder’s bank statement. Changing it triggers disputes with no underlying fraud. A cardholder who doesn’t recognize the line calls the bank, and the dispute is filed under a fraud reason code. The merchant then sees its dispute rate rise without any attack. Two steps limit the effect: the descriptor uses the brand name customers know, and it includes a way to get in touch. A third helps even more: warning subscribers about the change before the first charge under the new descriptor, a heads-up that costs one email.

Cardholder authentication also becomes the new provider’s job. It enrolls under its own IDs with the networks’ directory servers, and the quality of the data sent in the authentication request is tested all over again. A field populated correctly at the outgoing provider can end up empty at the new one, with no message to flag it. In the European Economic Area, the transaction risk analysis exemption depends on the fraud rate of the provider applying it. Article 18 of Delegated Regulation (EU) 2018/389 creates this exemption, and its annex sets thresholds of €100, €250, and €500 for successively lower fraud bands. The fraud rate is a pricing asset. The exemption threshold a merchant can use therefore follows its provider’s fraud rate, so ask each bidder for that rate before signing.

• Compare matched cohorts: same country, same payment method, same card type, and same amount band. An overall average mixes populations and hides the drop.
• Separate recurring from everything else, because chaining breaks only on recurring payments and an overall rate dilutes the effect.
• Read the raw decline codes, not the provider’s translation, to tell an insufficient funds decline from an authentication decline.
• Keep the routing rule on the merchant’s side; otherwise, rolling back depends on the provider you are trying to leave.
• Write the stop criterion before starting, in authorization-rate points and in duration; otherwise, the decision will be made under commercial pressure.

Run-off and final shutdown

Run-off covers the transactions the outgoing provider keeps handling after payment processing has moved. It continues long after the last transaction that provider processed. The governing principle is that the acquirer of a transaction remains its acquirer until the rights attached to it expire, and only that acquirer can handle it. A dispute received six months after cutover therefore goes to the outgoing provider, which passes it on to the merchant, debits the amount, and waits for a response. The new provider cannot step in, since it has neither the original authorization nor the evidence file. Visa and Mastercard rules generally allow 120 days, counted from the transaction or the expected delivery date, and up to 540 days in the listed cases of delayed delivery.

A refund is linked to the authorization of the original purchase, and that authorization stays with the outgoing provider. Refunding through the new provider creates an unlinked credit, which many acquirers restrict and card networks regulate separately. The customer gets the money back. But the record never links back to the purchase, and any later dispute is hard to defend. The practical rule fits in one sentence: for the full length of its return policy, the merchant keeps enough of a balance or provision at the outgoing provider to cover refunds.

The reserve is the share of funds the acquirer withholds from payouts owed to the merchant. It is not released on termination, and how long it is held is set by contract. It covers a risk that outlives the contract: disputes and refunds on transactions already processed. Providers’ standard terms commonly include a holding period after the relationship ends, and no card network rule sets its length. The figure is therefore found in the contract and nowhere else. A merchant that did not get a written release schedule at signing ends up negotiating it after termination, when the provider no longer depends on its business.

• Export before terminating: transaction history, closed dispute files, and mandates, because the portal closes with the contract.
• Obtain the attestation of destruction for the vault, dated and separate from the legally required archives the provider must keep maintaining.
• Revoke API keys and notification endpoints at the outgoing provider, after the last dispute has been handled and not before.
• Close out the settlement account, naming in writing the contact who will handle residual payouts and the release of the reserve.
• Cancel the mandates held by the outgoing provider once the new mandates are active, to avoid collecting twice from the same debtor.
• Keep an offline copy of the ID mapping tables, the only way to read an old transaction once access is closed.