Migrating Card Vaults to a Second Processor Without Losing Rebills

Adding a second processor lives or dies in the vault migration. Here is how to move PANs, network tokens, transaction IDs, and account updater coverage without your rebills declining as strangers.

Every routing playbook tells subscription merchants to add a second processor. Almost none mentions where the project dies: inside the card vault. You cannot always export the stored card numbers (PANs). The network tokens cannot leave. And the transaction IDs must travel, or issuers treat every migrated rebill as a stranger's first charge.

Payment vault migration moves stored card credentials from one processor's vault to another without interrupting recurring billing. The credentials include PANs, tokens, transaction IDs, and consent flags. Done right, the migration is an encrypted vault-to-vault transfer, plus re-provisioning of network tokens and updater enrollment. Done wrong, rebills decline as unrecognized first-time charges.

This guide treats the vault migration as the prerequisite that decides whether a second-processor project ships at all. We cover the export mechanics, the token portability trap, the transaction-ID chain, and the account updater reset. We then cover the measurement layer that proves the credentials arrived intact before your next billing run finds out the hard way.

Why can't you just point your existing rebills at a second processor?

The credentials those rebills run on are not yours to move. The PANs sit in the incumbent's vault. The tokens are scoped to its systems. The transaction IDs that prove billing consent can be absent from every export file. Routing is the easy part of a second-processor project. The card file is the project.

The asymmetry catches teams off guard. About seven in ten subscription businesses assume their card-on-file data is portable. A compliant PAN migration between processors typically runs 14 to 45 business days. If the file is lost or mangled instead, re-engagement campaigns recover only about 40 to 60% of affected subscribers over a 30 to 90 day effort. The rest of the card-on-file portfolio is gone permanently. That makes the vault export the highest-stakes step of the whole routing initiative.

The payoff on the other side is real. A second acquirer unlocks failover, issuer-level routing, and negotiating power. We cover all three in our multi-acquirer strategy guide and our breakdown of running multiple payment gateways. But the credential-migration phase alone takes 4 to 12 weeks of coordinated work between the merchant, the incumbent payment service provider (PSP), and the destination vault. Enterprise books run 12 to 20 weeks. Plan it as a project with its own failure modes, not a config change.

• The PANs themselves, exported vault-to-vault under PCI controls
• The network transaction IDs (Visa Transaction Identifier, Mastercard Trace ID) that keep rebills classified as compliant MITs
• The stored-credential flags that mark each charge as a continuation, not a first use
• A fresh account updater enrollment on the new acquiring rail, started weeks before the first migrated billing run

What actually lives in a card vault, and who owns the tokens?

A card vault holds the encrypted PAN, the expiry, the billing details, and the token references built on top of them. Ownership splits by layer. You generally own the raw card data. Your PSP owns its proprietary tokens outright. Network tokens belong to whoever holds the Token Requestor ID (TRID), the registered identity the tokens were provisioned under.

The card industry's data security standard (PCI DSS) shapes what a vault can contain. Wherever a vault stores the PAN, it must render the number unreadable through strong cryptography, truncation, or index tokens. Requirement 3.3.1 bars retaining the card security code (CVV) after authorization entirely. The PCI Council's own FAQ states that CVV storage for card-on-file or recurring billing is prohibited, not merely discouraged. Cardholder consent does not change that. For migrations, this means no export file will ever contain CVVs. That does not matter, because rebills never need them.

Portability is decided layer by layer, which is why the token audit comes before the contract, not after the export request.

Major processors concede the base layer. Stripe states in its documentation that merchants own the card data in its vault. Stripe will transfer the file to a new processor on request. The bad news is everything above that layer. Gateway tokens are surrogate values that work only inside the issuing system. They become nonfunctional the moment the account closes. The most important diligence question for any vault is not about the PANs at all. It is whose TRID the network tokens sit under.

How do you get PANs out of an incumbent processor without breaking PCI scope?

The card data moves through a vault-to-vault transfer. The incumbent encrypts the card file to the receiving processor's PGP key (a public encryption key) and sends it directly. Readable card numbers never touch your systems, so your PCI scope does not change. The gate is compliance paperwork, not technology. It is slower than most teams budget.

The mechanics explain the timeline. Stripe will only release card data to a PCI DSS Level 1-compliant processor. Stripe verifies that status through a current Attestation of Compliance (AOC) or a listing on Visa's Global Registry of Service Providers. The receiving processor must also host a 4096-bit PGP public key over HTTPS, on a domain named in that AOC. The encrypted file moves provider to provider. At no point does the merchant hold, decrypt, or even see the PANs. That is exactly what keeps the merchant out of PCI scope.

Know what actually arrives, because it is less than most teams expect. The export contains card data only: customers, PANs, expiry dates, billing addresses, emails, and metadata. Payment history and subscription objects do not travel. In Stripe's case, the export schema carries no network transaction IDs (NTIDs), the identifiers that link each charge to the original authorization. You must reconstruct the NTIDs via API pulls before you lose account access. Treat the export file as the skeleton. Treat the consent chain as a separate deliverable you have to chase explicitly.

• Link-saved credentials: excluded from Stripe PAN exports entirely, structurally non-portable
• Google Pay DPANs: cannot migrate at all, because the wallet (not the PSP) tokenizes them
• Apple Pay DPANs: move only if the old processor exports DPAN, expiry, and NTID together
• Some commercial and co-branded cards: cannot be network-tokenized at the destination

Then there is the calendar. The exporting processor can take a few days to several weeks to hand over the file. The import itself typically lands within 10 business days once the data is clean. The incumbent's active cooperation is a hard dependency throughout: it must agree to decrypt and transmit card numbers on your behalf. Cooperative transfers recover 40 to 65% of stored cards in typical cases. Hostile terminations recover 0 to 15%. Check the export clause when you sign with a provider, not when you are leaving.

Are network tokens portable between processors, and what do you lose when they aren't?

The answer is mostly no. A network token provisioned under your PSP's TRID cannot follow you to a second processor. The card networks must re-issue new tokens against the underlying PANs. Portability exists only when the tokens sit under a TRID that you, or a neutral vault, control.

This is the lock-in nobody mentions at signup. The networks register each token under a TRID. When the PSP holds that TRID, the tokens are genuine and lift approval rates, but they belong to the provider's identity, not yours. Moving them requires the network to re-issue new tokens against the underlying PANs. That re-issue needs either PAN access or customer re-enrollment. The lock-in is architectural, not contractual. No exit clause can make TRID-scoped tokens move, and most PSPs provision under a shared TRID by default.

Even when you can technically export the token strings, they arrive inert. The provisioning PSP acts as the token requestor's token service provider (TSP), the system that operates the tokens. The TSP owns the two functions a token is useless without: fetching cryptograms per transaction and receiving card-reissue lifecycle updates. A receiving processor cannot do either for tokens it did not provision. The practical path is PAN export plus full re-provisioning at the destination. At card-file scale, that re-provisioning is a recognized authorization-performance event. One migration runbook documents the worst case: 80,000 customers whose tokens failed to import, which produced 80,000 re-authentication emails over two weeks.

The upside once re-provisioning completes justifies the pain. Vendors cite a 2 to 7% authorization lift for PSP-token-to-network-token migrations, and 80 to 90% of a typical credential book is eligible. The structural escape hatch is provisioning under a neutral token requestor. That is an independent vault that holds its own TSP ID and can present the same tokens to any downstream PSP. Before committing, get network-token import support confirmed in writing, and validate against a sample. One hotel-group migration proved token porting for 200,000 card-on-file records against a 50-row sample before switching a single rebill.

What happens to MIT flags and initial transaction IDs after a move?

The stored-credential identifiers must travel, or every migrated rebill presents to issuers as a first-time charge. Visa and Mastercard require each merchant-initiated transaction (MIT), a charge you start without the customer present, to reference the NTID from the original cardholder-initiated transaction (CIT). A card file that arrives without those IDs produces declines no retry logic can fix.

The mechanics are concrete fields, not abstractions. Visa's Transaction Identifier from the initial auth must be populated in field DE 62.2 of every related MIT. DE means data element, a numbered field in the authorization message. Mastercard's Trace ID rides in DE 48, sub-element 63. When an MIT cannot establish traceability to the prior authorization, issuers can decline it and demand fresh authentication. The issuer then re-rates the rebill as a new customer-present transaction. The classic vault-migration failure is exactly this: the PAN file arrives but the NTIDs do not. They were never in the export, never documented, or never mentioned by the departing PSP.

The grace periods that used to paper over this are gone. Visa stopped accepting a static placeholder in place of the real initial Transaction ID after 31 October 2022. Mastercard stopped supporting the dummy Trace ID after 19 October 2024. Migrations without the genuine IDs now face soft declines plus scheme non-compliance fees. The rules keep tightening. Since 2 June 2026, Mastercard permits issuers to decline any MIT whose linkage cannot be established. By 23 October 2026, every recurring payment must carry both the Trace ID and the new Transaction Link ID.

On the receiving side, you must also label the import correctly. Flag migrated cards as off-session cards-on-file. Mislabeling re-rates rebills as fresh customer-present charges, invites declines for unconfirmed consent, and makes the credentials ineligible for account updater and network tokens. Watch the semantics too. Gateways disagree on whether they want the original CIT's NTID or the most recent transaction's, so verify the mapping per receiving gateway. For merchants in the European Economic Area (EEA) and the UK, the stakes double. Imported NTIDs prove prior strong customer authentication (SCA) and let the new processor claim exemptions instead of forcing every subscriber to re-authenticate.

How do you keep account updater coverage running through the cutover?

Account updater coverage does not migrate. Enrollment is a property of the acquiring relationship. The new processor starts with zero updater history while refreshed card numbers keep landing at the old one. Re-enroll early. Keep the incumbent's coverage live through the transition. Reconcile the delta before each batch bills.

Visa Account Updater enrollment runs through the acquirer, form by form per merchant. That is why coverage binds to the rail rather than to you. The decay math makes the gap expensive fast: roughly 30% of enrolled card accounts change number, change expiration date, or close every year. About 40% of cardholders get replacement cards annually. A working updater service refreshes 20 to 35% of a newly enrolled card file in the first month alone. A migrated file starts going stale the day someone takes the export snapshot.

Three timing rules keep the gap survivable. First, updater enrollment on a new acquirer takes 12 to 14 business days, so start it well before the first migrated billing run. Second, schedule the updater harvest 3 to 5 days before each recurring billing run, so refreshed credentials land ahead of the charge attempt. Visa also requires you to apply returned updates within 5 business days. Third, build a delta catch-up. Card updates made on the old processor between the export snapshot and import completion vanish silently unless you reconcile them explicitly.

Skip this and the damage has a known shape: a two-to-four-month spike in declines after cutover. The spike lasts while the new merchant account's updater rebuilds its view of the portfolio. One analysis ties updater participation to the merchant account itself: a new account means new participation and a new sync window. One sharp edge case exists: an updater refresh changes a card's brand. The processor then bars further MITs on that card until you collect a new cardholder agreement. For how the updater layer interacts with tokenization, see our comparison of network tokenization vs account updater.

How do you sequence the cutover and prove the credentials moved intact?

Sequence the migration around your billing calendar, not a percentage rule of thumb. New sign-ups move first. The back-book moves in reconciled batches. No cohort cuts over inside its own renewal window. Then prove the credentials arrived: compare approval rate by issuer and by bank identification number (BIN) against a pre-cutover baseline, batch by batch. A BIN is the card-number prefix that identifies the issuing bank.

Processor runbooks agree on the sequencing. Route 100% of new customers to the new processor first. That proves the integration on fresh traffic while the incumbent keeps charging existing customers in parallel. Rebills should never depend on an in-flight file transfer. Move the back-book in batches of about 10% of the credential book per week, with reconciliation between batches. Ramp only when the approval data stays clean. Lead with the cleanest cohorts (active, domestic cards) to establish healthy authorization history. Push any customer whose renewal falls near the window to migrate after that cycle completes. Run a dual-write period where new cards land in both vaults, so the window creates no orphans.

Testing is per-credential, not per-file. The acceptance proof for each batch has three parts. Every source credential produced a destination token. That token passes a $0 verification with the issuer. Your customer records point at the new token. Two discipline rules protect the first cycle. First, do not blast the migrated book with mass retries or verification runs. High-volume attempts on a freshly moved file pattern-match to card testing at the issuer. Second, confirm the old processor has stopped billing each migrated cohort, or cycle one double-charges them.

• Audit token types and TRID ownership before anything else: it decides how much of the book can move
• Get the incumbent's export commitment, field list (NTIDs included), and timeline in writing
• Verify the receiving processor's PCI Level 1 AOC and the PGP vault-to-vault handoff
• Pull NTIDs and billing state via API before losing dashboard access
• Start account updater re-enrollment at least three weeks before the first migrated billing run
• Run $0 verifications on every imported credential before relying on it for a rebill
• Baseline approval rate by BIN, issuer, and MID before cutover; diff daily after
• Confirm the old processor stopped billing each migrated cohort before its next cycle

Measurement is the actual acceptance test. Capture a segmented baseline in the first 48 hours of live traffic on the new provider. Break it down by provider, country, card brand, and payment method. Then alert on a 2-percentage-point approval drop within any 30-minute window. Aggregate approval rate will not catch a broken migration. Healthy top-line numbers hide segment damage. Only BIN-level views expose which issuer cohorts are declining migrated rebills. The same instrumentation powers healthy rebill approval rates and any serious payment orchestration setup, applied here to a one-time event.

A failed migration has a recognizable signature. The earliest signal is a daily-tracked drop of more than 3 to 5 percentage points on charges against cards with no prior decline history. Clean cards suddenly declining means the credential broke, not the customer. Decline codes like transaction-not-allowed and authentication-required point at missing initial-transaction evidence rather than stale card data. Expect some elevation from the new merchant ID (MID) alone. One documented software-as-a-service (SaaS) case saw declines double from 3% to 6% purely from acquiring-BIN history. Set a hard remediation trigger: re-tokenize an affected cohort within 7 to 14 days. Merchants who let it stretch past 30 days saw 2 to 3 times higher churn.

Frequently Asked Questions

Can I transfer my stored credit card tokens to a new payment processor?

Usually not the tokens themselves. Gateway and PSP tokens are valid only inside the system that issued them, so a real migration moves the underlying PANs vault-to-vault and the new processor issues fresh tokens. What you can carry over are the card numbers, expiry dates, and the network transaction IDs that keep rebills compliant.

Who owns the payment tokens, me or my PSP?

It depends on the layer. Major processors like Stripe state that merchants own the underlying card data and will export it to a qualified receiving processor. But proprietary PSP tokens belong to the PSP outright, and network tokens belong to whoever holds the Token Requestor ID they were provisioned under, which for most merchants is the PSP.

Are network tokens portable between processors?

Not by default. Network tokens are provisioned under a Token Requestor ID, and when your PSP holds that ID the tokens cannot move; the card networks must re-issue them against the underlying PANs at the new processor. They become portable only when provisioned under a merchant-controlled or neutral-vault TRID.

How long does a payment token migration take?

Plan for 14 to 45 business days for a typical compliant migration, and 12 to 20 weeks in total for an enterprise credential book. The data transfer itself is fast; compliance verification, export queues, account updater re-enrollment, and batch-by-batch reconciliation are what consume the calendar.

Will customers have to re-enter their card details if I switch providers?

Most will not, if the migration is done properly: PANs and expiry dates move vault-to-vault and rebills continue silently. There are exceptions. Google Pay credentials cannot migrate at all, some PSP-wallet cards are excluded from exports, and any cohort whose consent chain breaks needs a fresh cardholder-initiated transaction to re-establish billing.

Does migrating a card vault put me back in PCI scope?

No, not when it is run as a compliant vault-to-vault transfer. The incumbent encrypts the card file to the receiving processor's PGP key and sends it directly between the two PCI DSS Level 1 parties, so readable PANs never enter your environment and your PCI posture is unchanged.