Token portability: moving the card is only part of the job

Your new payment provider confirms that the import is complete. The cards are in the new vault. The next subscription run starts, and payments fail.

The credentials moved. The customer mappings, recurring-payment references, or billing instructions did not.

For a payment operations manager, portability means being able to use a saved payment method where the business needs it, with the context required to collect successfully. An export file is one part of that job.

A contract gives you an exit path. Your architecture determines how you can use it.

First establish what portable means to your business. Do you need to leave a provider eventually, use a second processor for selected transactions, or route saved payment methods across several processors every day?

Contractual portability is the right to have your current provider transfer eligible payment data under agreed conditions. Check the scope, fees, notice period, delivery timetable, destination requirements, exclusions, and assistance available. A right to export does not establish that another provider can immediately process the exported data.

Technical portability is the operational ability to use the credential through another processing route. There are two common architectures:

• PSP-led, without an independent vault. One PSP collects and stores the first copy. You maintain payment-method references in your system and use supported export, forwarding, or replication capabilities to make selected credentials available elsewhere. This is sometimes called a vaultless model, but a provider still holds a vault. A copy of an opaque token in your database does not itself enable another gateway to charge it.
• An independent vault upstream of the gateways. The vault stores the credential and gives your system a stable reference. Through supported integrations, it supplies usable credentials or creates destination-specific payment methods at downstream processors. Switching a processing route can then be separate from moving the primary vault.

An upstream vault can support routing by performance, cost, or settlement and liquidity needs. It can also support retries of eligible soft declines through another gateway. Those capabilities still depend on the vault's integrations, the destination's acceptance rules, network retry rules, and controls against duplicate charges.

The boundary is becoming less rigid. Some PSPs now offer vaulting, forwarding, and orchestration services beyond their own processing route. Evaluate the actual export and execution capabilities, rather than assuming that a PSP vault is always closed or an independent token is universally accepted.

Know what your token represents

There are two broad layers: provider-issued vault references and network-issued payment tokens. Within the first layer, distinguish a gateway reference from an independent-vault reference.

Token	Where it sits	What portability means
Gateway or PSP token	Issued and controlled by the provider; the underlying credential sits in its vault.	The token normally works within that provider's ecosystem. Migration usually transfers the underlying credential and creates a new destination token.
Independent-vault or orchestration token	A reference to a credential stored upstream of processing gateways.	The vault can resolve and forward credentials through supported integrations. Another processor does not automatically accept the vault's token string.
Network token	Issued through a card network's token service and managed through an approved requester and service arrangement.	Use across processors depends on token scope, destination support, cryptogram access, and lifecycle-management arrangements.

These layers can coexist. Your application may hold a vault token that resolves to a network token. The reference your team sees in a dashboard may therefore be different from the credential used in authorization.

Providers issue, store, and control their proprietary tokens. Ownership rights, export rights, and permitted uses of the underlying data are contractual questions. Keep those separate from the technical meaning of a token.

Most migrations start with two support tickets

Open an import ticket with the receiving PSP or vault, then an export ticket with the outgoing provider. Put their migration teams in contact. Your operations team coordinates scope, dates, mappings, and acceptance; the providers handle the credential transfer between their approved environments.

For a typical batch migration, the outgoing provider encrypts an agreed export for the receiving provider and delivers it through an approved secure channel. The receiver imports the credentials, creates its own payment-method references, and returns a mapping and exception report.

Agree these items before the export starts:

• The merchant accounts, payment types, and record population included, with explicit exclusions.
• The file schema, secure transfer channel, encryption key verification, and a sample import.
• The customer and payment-method identifiers returned in the mapping report.
• The treatment of new and updated records between the initial export and cutover.
• Fees, delivery dates, support ownership, and the process for rejected records.

Some providers also support API-to-API migration or a forwarding proxy. The outgoing vault resolves a token and sends credential data directly to an approved destination endpoint. Confirm whether that operation creates a reusable stored payment method or merely executes a payment. Check destination allowlisting, rate limits, per-call charges, idempotency, and retry behavior.

A support-managed move is often the practical route. It avoids introducing raw card data into your ordinary operations systems, but it does not remove your responsibilities for provider due diligence and your own PCI scope. See the PCI SSC guidance on outsourced processing.

Preserve your customer ID through the move

The most useful migration key is a stable customer ID that your business controls. You may store it in your own application, in a billing platform, or as a reference inside the PSP. Carry it through the export and import, together with an identifier for each payment method.

Merchant customer ID → source payment-method ID → destination payment-method ID.

Merchant customer ID	Source payment method	Destination payment method	Result
customer_1042	old_method_01	new_method_87	Imported; default method
customer_1042	old_method_02	new_method_88	Imported; backup method

These are illustrative identifiers. One customer can have several payment methods, and one payment method can be referenced by several subscriptions. Preserve those relationships rather than mapping only at customer level.

Ask whether the source returns the first six digits and last four digits, or equivalent permitted card metadata, alongside its tokens. Some tokens preserve recognizable digits; others are opaque. Visibility can make investigation and reconciliation easier, but first six plus last four is not a unique customer or card identifier. Collisions, card replacements, and network tokens make digit-only matching unreliable.

If the existing mapping is incomplete, agree how to retrieve customer references and metadata before migration. Ask whether administrative API access, bulk lookups, or a reconciliation export carries an additional fee. Do not discover that dependency during cutover.

Agree the export contents before cutover

The following is a generic field checklist, not a universal import schema. The source and destination teams must agree names, formats, required fields, and supported values. Card and bank-account credentials travel only through their approved transfer process.

Record group	Generic fields to agree
Identity and mapping	merchant_customer_id, source_customer_id if needed, source_payment_method_id, merchant_account_id, payment_method_type
Card credential	card_number or supported transferable credential, expiry_month, expiry_year, cardholder_name where available
Bank account / ACH	account_number, routing_number, account_type, account_holder_name, holder_type, supported verification and authorization references
Billing and preferences	billing_address fields, default_method indicator, relevant customer or subscription references
Recurring and network context	card_network, network_transaction_reference, applicable stored-credential context; network-token and requester details in a separately agreed schema
Import result	merchant_customer_id, source_payment_method_id, destination_payment_method_id, import_status, error_code, error_description

Keep identifiers and account numbers as text so leading zeros and long values survive processing. Do not put full account numbers in the operations reconciliation report when references and permitted metadata will do.

ACH authorization and verification status need separate review. Moving bank details does not automatically establish that the destination can rely on the existing authorization or verification evidence. Preserve the supporting records and confirm acceptance with the receiving provider.

NTID deserves its own migration check

A Network Transaction ID, or the applicable network transaction reference, can connect a later merchant-initiated payment to an earlier transaction. In a subscription migration, that context may be just as important as the stored card.

Imagine a customer authorizes the initial subscription payment through provider A. Next month's renewal runs through provider B. Provider B needs the appropriate credential, stored-credential indicators, and transaction reference for its supported recurring-payment flow. A successful card import alone does not demonstrate that those fields are available or passed correctly.

An NTID is not a vault token, a network token, or an internal gateway transaction ID. Ask the source which network-issued value it exports, whether the value is raw or transformed, and how it relates to each stored method or payment agreement. Ask the destination which reference it accepts for each network and how it carries that reference into subsequent transactions.

For an NMI-to-Stripe migration, for example, do not assume similarly named fields are interchangeable. NMI's Payment API documentation describes initial_transaction_id as an original gateway transaction ID. The receiving provider's payment-method import requirements separately address network transaction IDs. Have both teams identify and validate the actual network reference in the export. Those documents do not establish a blanket claim that every NMI export contains an incompatible or normalized NTID.

Missing or incorrectly mapped references can affect subsequent recurring transactions. The destination's requirements vary by network, region, and flow; recurring-payment import documentation illustrates why these references need explicit treatment.

An NTID is neither proof of consent on its own nor a guarantee of approval or exemption from authentication. It is also not a CVV bypass. CVV must not be retained after authorization and is not part of a saved-card migration. See the PCI SSC guidance on card verification codes.

For more context, read the Atlas NTID field guide.

Network-token migration is a management handover

Network tokens are issued through network token services, such as those operated by Visa and Mastercard. They can support use beyond a single processor, but processor independence is not unconditional portability.

The Token Requestor ID (TRID) identifies the requester in the relevant network's token program. It is different from a merchant acquiring ID, or MID. The arrangement may involve a merchant, PSP, platform, or payment facilitator, depending on the implementation. Do not assume every merchant has its own TRID, that one TRID covers all networks, or that multiple MIDs necessarily require multiple TRIDs.

Establish who controls provisioning, cryptogram requests, token updates, suspension, and deletion. A provider's relationship or enrollment identifier may also form part of that arrangement; the name and transfer process are specific to the network and service provider.

Change	What to establish
Change processor; retain token manager	Can the existing manager supply the token and required transaction data to the new processor?
Change token manager; retain eligible token arrangement	Do the network and both providers support reassignment, and which registrations, permissions, and lifecycle responsibilities must change?
Move from an incompatible requester or platform arrangement	Must tokens be provisioned again? Which underlying credentials, consent, and customer actions are required?

A retained TRID does not by itself complete the handover. Obtain written confirmation of the supported transition, then test cryptogram generation where required and lifecycle updates after the move. Include network-token import and export in the migration scope explicitly.

Move the billing instructions too

The vault holds a payment method. A billing system decides when and how much to charge. If the outgoing PSP also runs billing, moving credentials does not move the subscription engine.

Reconcile amounts, currencies, next charge dates, time zones, default methods, trials, discounts, credits, balances, paused or canceled subscriptions, and retry state. If you run your own billing system, update the payment-method references it uses. If billing is moving too, plan a separate subscription-data migration.

Test representative cases: a customer with multiple cards, a recently updated credential, a paused subscription, a renewal already in retry, a network-token payment, and an ACH payment with its authorization records. Confirm which system owns each scheduled collection during the transition.

Close the migration after collections work

Start with an agreed population and reconcile it:

Eligible source records = successfully imported records + documented exceptions.

Track duplicate and excluded records separately so an inflated import count cannot hide missing customers. Assign every exception an owner and resolution path.

• Validate customer, payment-method, and default-method mappings.
• Confirm the required network transaction references and stored-credential context survived the move.
• Import the final changes made since the first export.
• Verify network-token management and updates on the receiving setup.
• Run an agreed pilot and compare authorization results with a suitable baseline.
• Ensure only one system owns each collection, including retries already in progress.
• Retain access needed for historical refunds, disputes, reconciliation, and required records.
• Define rollback triggers and reconcile transactions before switching routes back.

Monitor the first renewal cycles by provider, network, region, and payment type. Investigate changed decline patterns and customer-level exceptions. A rollback that repeats already successful charges creates a second problem.

The completion criterion is straightforward: customers are mapped correctly, scheduled collections work, exceptions are controlled, and the team can explain every record left behind.

How to request a payment-method export

First open an import ticket with the receiving vault or PSP. Obtain its migration contact, current PCI compliance documentation, public encryption key, accepted schema, and secure-transfer instructions. Then use the request below with the outgoing provider.

Share the public key through a verified process. Private keys and raw payment credentials do not belong in ordinary support-ticket attachments.

Download the generic export-request letter