PSP Migration Runbook: 90 to 180 Day Cutover Without Token Loss

A clean PSP migration on an iGaming book runs 90 days from notice to closeout. The realistic median runs 180 days. Operators planning a four-week cutover, the timeline most generic SERP runbooks describe, miss three contractual constraints and one regulator-audit constraint that no general payments-industry guide flags. Notice period to the outgoing PSP runs 60 to 90 days as standard. Reserve release runs 180 days post-cutover. Chargeback-tail liability stays with the old MID for 120 to 180 days. And on a UKGC- or MGA-licensed book, the deposit-limit history and fund-segregation arrangements that the cutover touches sit inside the licence-condition reporting perimeter, with hard windows that do not pause for a vendor change.

The iGaming-specific parts of the runbook are what no published SERP result covers. The general-purpose guides from Gr4vy, Basis Theory, NORBr, Paybyrd, and Payrails do the token-portability layer well and the contract layer at a generic level. They do not address the BIN re-issue cliff that breaks PAN-tokenized stacks at cutover, the licence-condition notification timing that constrains the parallel-run window, or the deposit-limit reproducibility obligation that lands on the operator regardless of which PSP processed which deposit. The article below is the iGaming-specific cutover map.

The 90 to 180 day window: where the math comes from

Three contractual constraints set the floor, and one regulatory constraint sets the realistic median.

The first constraint is the termination notice. Standard merchant processing agreements run a 60 to 90 day written-notice period before either party can exit at end-of-term, per CardFellow's survey of early-termination provisions. On an iGaming MID specifically, 90 days is closer to the operator-side floor than 60, because the underwriting committee at the new PSP wants to see a clean exit timeline before approving the merchant. Books that try to switch on 30 days notice, on the assumption that the contract is unenforceable, end up paying early-termination fees calculated as monthly volume times months remaining, plus a reserve-clawback risk on top.

The second constraint is the rolling reserve. Card acquirers underwriting iGaming MIDs at production volume hold 5 to 10 percent of trailing volume as rolling reserve, with a six-month release window as the contractual default. The reserve schedule does not move when the operator gives notice. The acquirer holds the float for 180 days after the last new transaction, per the Paybyrd migration playbook on reserve-release timing. An operator that flips traffic to the new PSP on day 60 of the notice period still has reserve held at the old PSP through day 240. Cutover is not the end of the relationship.

The third constraint is the chargeback tail. Card-network rules give cardholders 120 days from transaction date to file most CNP chargebacks, and certain dispute reasons stretch the window to 540 days. The operator's exposure to disputes on transactions processed pre-cutover stays with the old MID, and the old PSP retains the operational obligation to handle representments, second presentments, and arbitration on those disputes. The realistic chargeback tail across which the old PSP needs to keep dispute-portal access running is 90 to 180 days post-cutover, per the same Paybyrd source.

The regulator-audit constraint sits on top. UKGC LCCP 4.1.1 on segregation of customer funds requires the operator to inform customers of any change to fund-protection arrangements before implementing it, with customer acknowledgement before further deposits land under the new arrangement, per the UKGC's LCCP 4.1.1 page. Significant changes to fund-protection arrangements are reportable as key events under LCCP 15.2.1 within five working days. From 30 June 2026, RTS 12B requires the operator to reproduce gross deposit-limit history on demand for any audit window, and the reproducibility obligation does not pause for a PSP migration.

The math: 60 to 90 days notice plus a 30-day parallel-run window before cutover gives a 90-day floor on a clean migration. Reserve release plus chargeback tail plus regulator-facing post-cutover monitoring stretches the realistic window to 180 days. Operators planning shorter than 90 days are skipping a constraint, and the cost shows up later in early-termination fees, absorbed disputes, or a key-event report filed on the wrong side of the five-day clock.

Network tokens, PSP tokens, and the BIN re-issue cliff

Token portability decides whether the cutover is invisible to the player or visible to every cardholder on file. The answer turns on which kind of token sits in the operator's vault.

Network tokens (Visa Token Service, Mastercard MDES, Amex Token Service) are issued by the card network, not by the PSP. They reference the underlying PAN through the network's tokenization service, carry per-transaction cryptograms that the issuer's risk model recognizes, and can be referenced by any PSP that holds the right token-requestor credentials, per Gr4vy's comparison of PSP tokens versus network tokens. A network-tokenized card on the old PSP can be re-referenced by the new PSP without the player re-entering details, provided both PSPs are token-requestor enabled and the card network supports the inter-PSP transfer pattern.

PSP tokens (also called proprietary or gateway tokens) reference an internal database mapping inside the PSP. They are not portable. Switching providers means losing access to those tokens unless the current PSP supports an explicit export, and the old PSP has every commercial reason to make the export expensive or slow, per Gr4vy's migration writeup. The export path that does work is a PSP-to-PSP transfer under PCI scope: the old PSP encrypts the PAN file inside its own CDE, the new PSP decrypts inside its own CDE, the operator never touches plaintext card data. The transfer requires both PSPs to agree on the encryption, the algorithm, the secure transport, the credentials exchange, and the schedule, per the NORBr token-migration writeup, which is the part where the old PSP can stall for weeks.

The third option is a merchant-owned vault. An operator that stores card data in an independent PCI vault holds the canonical card record and provisions tokens to whichever PSP is currently active. The migration becomes a configuration change rather than a card-data transfer, per Payrails on merchant-owned vaults versus PSP tokenization. This is the cleanest portability pattern. It is also the rarest in regulated iGaming, because operators that grew up on direct PSP relationships rarely stood up an independent vault before they hit the migration moment, and adding one mid-migration does not help.

Now the BIN reality, which the standard runbooks miss.

A network token follows the cardholder, not the issuer's BIN. When an issuer reissues a card (because the original was lost, stolen, expired, or the BIN range was reassigned during a portfolio acquisition), the network token gets remapped to the new PAN automatically through Visa Token Service or Mastercard MDES lifecycle management, per Frisbii's reading of Visa Token Service auto-update behavior. The token expiry is set longer than the underlying PAN expiry on purpose, so the card can be reissued without breaking the token. The operator's stored credential stays valid through a routine reissue.

A PSP token does not carry that property. A PSP token references the original PAN, and a card replacement at the issuer side breaks the link unless the PSP's account-updater service catches the new PAN and re-stamps the token. Visa Account Updater and Mastercard Automatic Billing Updater handle this in the steady state, but the lookups run on a batch schedule that is not real-time, and the migration moment is exactly when an operator does not want to add another async dependency.

This matters for the cutover math because issuer adoption of network tokens is incomplete. Industry references put adoption at around 80 to 90 percent of issuers across the U.S., Europe, and Australia, with roughly 85 percent of CNP transactions tokenizable, per the IXOPAY analysis of network-token adoption. The remaining 10 to 20 percent of cards on file are PAN-tokenized at the PSP layer, and those break on cutover unless the new PSP can either pull a network token from the network at first transaction or re-tokenize from the encrypted PAN file the old PSP exported. Both work. Both require the technical contract between the two PSPs to be in writing, not assumed.

The auth-rate uplift from network tokens is the second-order benefit of fixing this layer at migration time. Visa reports a 4.6 percent lift in CNP authorization rates on tokenized traffic; Mastercard reports 2.1 percent; Solidgate reports up to 15 percentage points on tokenized cohorts on its own books, per Solidgate's network-tokenization writeup. Operators that exit a migration without converting the card-on-file cohort to network tokens have walked past the cleanest opportunity to fix auth rate they will get for the duration of the next contract.

Six clauses to lock on the outgoing PSP before you sign the new one

The contract patterns that decide whether the migration succeeds are the ones the operator negotiates with the OUTGOING PSP, not the incoming one. By the time the operator is ready to sign the new contract, the old contract is already written, and the only opening to renegotiate is the renewal cycle. Operators who sign new PSP contracts without first re-papering the exit-clause language on the old one find out at cutover that the clauses they need are not in the contract.

Six clauses to lock at the renewal of the outgoing PSP, each carrying a recoverable value the operator does not see until the cutover moment.

First, network-token export at no fee, with delivery inside 30 days. The clause names Visa Token Service and Mastercard MDES specifically, lists the export format (typically a manifest of token references and PAN references mapped to the merchant-customer IDs), and commits a maximum delivery window. Without the clause, the old PSP can charge per-token export fees that compound on a large card-on-file book, or stall delivery past the 90-day notice window so the operator either extends the contract or eats the loss.

Second, encrypted PAN export to the new PSP's CDE under documented PCI scope. The clause names the receiving PSP, the encryption algorithm and key-exchange procedure, the verification step (a small-volume token-to-token roundtrip transaction test before bulk transfer, per the Paybyrd playbook on token portability), and confirms the operator never receives plaintext card data. This keeps the operator out of expanded PCI scope through the migration window.

Third, the chargeback-tail responsibilities. The departing PSP retains the operational obligation for representments, second presentments, and arbitration on transactions processed pre-cutover for 120 to 180 days. The clause specifies the response-cooperation SLA, the dispute-portal access window, and the data the old PSP will continue to surface (chargeback packets, second-presentment filings, retrieval requests). Without this, the operator faces a representment-deadline miss during the cutover transition because the old PSP sees them as a former client.

Fourth, the rolling-reserve release schedule. Reserves at 5 to 10 percent for a 180-day hold are the default starting point. The clause locks the calendar in writing: monthly release of one-sixth of the held balance starting 30 days post-cutover, with the final tranche released by day 210 post-cutover. The PSP settlement statement field guide is the companion read for spotting discretionary holds disguised as exception-hold journal entries during the same window. Without a fixed calendar, "at acquirer discretion" becomes 12 months on a contested termination, and the held capital is the operator's working-capital problem until the dispute resolves.

Fifth, no clawback on previously-released reserve unless the old PSP demonstrates a specific dispute-cost shortfall against a documented threshold. Departing operators sometimes find clawback notices arriving 90 days post-final-release on disputes the operator considered closed, and absent specific contractual language the dispute is the operator's to litigate.

Sixth, data-export obligations on transaction history. The new PSP needs at least 90 days of historical transaction data to train its risk model on the operator's traffic, and 12 months for fraud-pattern analysis. The export should include declined attempts, not just settled transactions, because the decline pattern is what the new acquirer reads to price the merchant on the renewal cycle. Without the clause, the new PSP starts cold and the auth-rate dip in the first weeks post-cutover is larger than it needs to be.

The opening for each of these is the renewal moment on the existing PSP contract. Operators who treat renewal as a rate-sheet exercise miss the contract layer; operators who insist on these six clauses at renewal pay a slightly higher rate for a year in exchange for a clean exit the next time around. The math runs in the operator's favor at any production-tier volume.

Parallel onboarding from underwriting to traffic split

New PSP onboarding does not happen in series after the old PSP is shut down. It runs in parallel, starting before the old PSP is even notified, because iGaming MID underwriting at the new PSP runs 30 to 60 days minimum and the operator cannot afford to be without a card rail at any point in the window.

The parallel-onboarding sequence collapses to seven dated milestones inside the 90 to 180 day window, sequenced so that approval at the new PSP precedes notice at the old PSP. The full underwriting kit the new PSP reads is in the acquirer underwriting cheat sheet.

The parallel sequence collapses on operators that try to compress it. A 60-day total window means underwriting starts after notice, which means the operator either runs without a card rail for 30 days or pays the old PSP an extension fee at a worse rate sheet. A 30-day total window is impossible in regulated iGaming because the new PSP's underwriting committee will not approve a high-risk MID inside 30 days.

The sequence assumes one card acquirer changing. Operators running a multi-acquirer stack through an orchestrator Adyen, IXOPAY, Solidgate, Primer can stage the migration acquirer-by-acquirer without ever flipping 100 percent of traffic at once. The orchestration layer becomes the cushion that absorbs the cutover risk, and the operator chooses which acquirer to migrate at which renewal cycle. Books on a single direct acquirer relationship do not have that cushion and run the full Day 0 to Day 180 sequence on every migration.

Deposit-limit history continuity for UKGC and MGA reporting

The runbook layer no SERP guide covers is the regulator-audit continuity for an iGaming operator. The cutover touches the deposit ledger, the limit-set events, and the deposit-rejection events that a UKGC or MGA audit reads. If the migration breaks the lineage, the audit fails. The migration plan needs an explicit data-continuity layer separate from the PSP transaction store.

UKGC LCCP 4.1.1 requires the operator to notify customers of changes to fund-protection arrangements before implementing them, per the LCCP 4.1.1 page. A change of card acquirer or PSP that touches the segregation arrangement triggers this. The customer-notification text must reach customers before cutover, and customers must acknowledge before they deposit under the new arrangement. LCCP 15.2.1 on key-event reporting requires the operator to notify the Commission of significant changes to fund-protection arrangements within five working days of the change taking effect.

The harder layer is the deposit-limit history. From 30 June 2026, RTS 12B requires the operator to reproduce on demand, for any audit window, the period a deposit fell into, the gross used at deposit time, the active limits at deposit time, and the cooling-off status of any limit changes during the period, per the UKGC consultation response on RTS 12B Proposal 1. The reproducibility obligation does not pause during the migration. A regulator query landing during the parallel-run window must return consistent answers regardless of which PSP processed which deposit.

The operator-side fix is to keep the deposit-limit history outside the PSP transaction store, in the operator's own platform database, with the PSP transaction reference as a foreign-key column rather than as the row's identity. The PSP store owns the payment record; the operator store owns the regulatory-event record. The migration touches the PSP store and leaves the regulatory store untouched.

The minimum continuity contract on the operator side:

• Deposit events get a stable operator-side ID at insert time, independent of the PSP-issued reference. The PSP reference is a column on the row, not the row's primary key.
• Limit-set events, limit-change events, the 24-hour cooling-off audit trail, and the deposit-rejection events live in operator-owned tables and reference the player ID, not the PSP-customer ID.
• The deposit-limit query in production reads from operator tables only, and joins to the PSP store only when payment-side metadata is needed for an audit reply.
• During the parallel-run window, both PSPs write transaction events but the operator-side ID is canonical for the regulator audit. Reconciliation across the two PSP records into the operator events table runs daily, with mismatches logged and resolved before the next reconciliation cycle.

For MGA-licensed books the obligation is structurally similar. The MGA Player Protection Directive requires monitoring of deposit frequency, multiple-payment-method use, and the reversal-of-withdrawal pattern as markers of harm, per the MGA's published Player Protection Directive. A migration that breaks the deposit-frequency continuity by losing transactions during the cutover window breaks the markers-of-harm computation. The fix is the same shape: the markers-of-harm event log lives on the operator side, with PSP references as columns rather than as primary identity.

The customer-notification timing layers on top. UKGC operators serve the LCCP 4.1.1 notification at the cashier on the first deposit attempt under the new arrangement, requiring acknowledgement before the deposit is processed. The notification cannot be batched into a marketing email and treated as served; the acknowledgement is a per-customer transactional event. Operators running this through a generic customer-comms system rather than the cashier flow find the acknowledgement rate stalls below their unique-customer count for weeks, and the cashier traffic from non-acknowledged accounts blocks until login. Build the acknowledgement into the cashier flow itself, not into the marketing CRM.

The cutover day and the 90 days after

The cutover day is the easy part. Traffic flips from old PSP routing to new PSP routing inside a controlled maintenance window, the orchestrator updates the routing table, and the new PSP processes the next deposit. The 90 days after is where most operators find the work they did not plan for.

The auth-rate dip is the first surprise. New PSP auth rates can run materially below the old PSP's baseline for the first one to two weeks because the new acquirer's fraud model has no history on the operator's traffic. The dip recovers over 30 to 60 days as the model trains on real volume, per the Basis Theory analysis of post-migration auth-rate behavior. Operators that did not export historical decline data to the new PSP face a longer dip than operators that did. The operator-side mitigation is to flag the new PSP's risk team daily through the first 14 days with the false-positive-decline pattern, and to keep the orchestrator able to route specific BIN-level declines from the new PSP back through the old PSP while the chargeback-tail window is still open. This is not a permanent failover; it is a 30-day stabilization pattern.

The decline-pattern shift is the second. The new PSP routes through different acquirer relationships, which means different issuer-BIN level decline patterns. A BIN that approved cleanly on the old PSP can decline more often on the new PSP because of acquirer-issuer relationship history rather than any merchant-side change. The fix is BIN-level monitoring through the first 30 days, with the new PSP's risk team able to pre-authorize specific BIN ranges if the decline distribution misaligns with the old baseline.

The chargeback management split is the third. Pre-cutover transactions chargeback on the old PSP. Post-cutover transactions chargeback on the new PSP. For the first 120 days of the post-cutover window, the operator runs two dispute portals, two response workflows, and two reporting paths. Operators that did not lock the cooperation SLA in the exit clauses discover the old PSP's dispute portal goes read-only before the chargeback tail closes, and late-arriving disputes on transactions from the last week before cutover land without a representment opportunity.

The regulator-audit window is the fourth. UKGC and MGA audits run on a scheduled cycle, and the migration window is the kind of operational change that surfaces in the next audit. Operators with the operator-side regulatory event store from the previous section hand over a query result. Operators without it spend the audit reconstructing deposit-limit history from two PSP transaction stores with different schemas, different ID formats, and different timezone conventions. That reconstruction is exactly the kind of evidence problem that turns an audit into an investigation.

The clean migration ends at day 180 with the reserve fully released, the chargeback tail closed, the network-token cohort fully provisioned at the new PSP, and the new PSP running at the operator's pre-migration auth rate or above. The unclean migration runs longer, and the cost shows up in held capital, absorbed disputes, an auth-rate baseline that took the wrong shape, and a regulator query that took weeks to resolve when it should have been a query result. The contract clauses, the parallel onboarding, and the operator-side regulatory-event store are the three pieces that decide which version the operator gets. None of them is set at the cutover moment. All three are set six months earlier, on the renewal cycle of the outgoing PSP, before the new PSP contract is on the desk.