Payment token portability: what to confirm before switching processors

Before changing processors, determine what your application has actually saved. A customer identifier, a processor payment-method token, a wallet credential, and a subscription record are different things. An export of names and token strings does not establish that the new processor can charge those customers.

Stripe describes a coordinated payment-data migration that includes provider involvement and identifier remapping. Braintree supports customer and card-data portability but documents restrictions: its migration service does not move subscription or transaction information, and Apple Pay and Google Pay payment methods are excluded from its exports. Treat portability as a scoped migration project, not a checkbox on a sales comparison.

Count active customers by payment method, processor account, legal seller, currency, and billing arrangement. Distinguish customers with a saved method from those who have only historical transactions. Include subscriptions on hold, customers with more than one method, and accounts whose next bill is imminent.

For a fictional population of 5,000 subscribers, 4,000 may use saved cards, 600 may use wallets, and 400 may use bank debit. Do not call the project 5,000 card migrations. Each population needs a confirmed route, and some customers may need to provide fresh details or authorize a new arrangement.

Give both providers the relevant population summary without sending raw card data through ordinary email or spreadsheets. Use their approved secure migration process for sensitive payment information. The business's implementation team should coordinate the work while the authorized providers handle the protected transfer in the agreed manner.

A successful credential transfer does not recreate the subscription's price, quantity, renewal date, trial, discount, credit balance, or collection status. Braintree explicitly distinguishes its customer and card-data migration from subscription and transaction records. Stripe's migration overview also calls for subscription remapping where relevant.

Build a separate billing migration plan with expected results. For each active subscription, define the first amount and date the destination should bill. Preserve evidence for negotiated terms and pending amendments. A customer should not receive a second annual charge because the new system interpreted a migrated customer as a new sale.

Keep historical payment records accessible for refunds, disputes, support, and accounting. They may continue to be handled through the original provider even after new collections move. Ask how long the old account needs to remain available and what responsibilities survive termination under the agreement.

The new provider, existing provider, billing owner, and application team should agree this scope before fixing a public cutover date.

Stripe describes returning a mapping file for updating the merchant's database. Whatever the providers' specific format, the business needs to prove that the right customer points to the right new payment record. A transferred record count is necessary evidence, but it is not enough on its own.

Reconcile the expected population, records accepted, records rejected, and customers needing action. Investigate duplicates and missing mappings before enabling automatic billing. Use provider-approved verification or test procedures; do not create unnecessary real charges solely to check whether migration worked.

Define one owner for the cutover switch. Old and new systems should not independently run the same renewal population. Include a procedure for payments in flight and records changed after the initial export. A controlled final update is often needed so the migration does not lose a card update or cancellation made during the project.

Tell affected customers what they need to do, when they need to do it, and how to recognize a legitimate request. The message depends on the actual method and legal arrangement; do not promise that no action is required until the providers have confirmed the scope. Give support a list of unresolved cases and a clear escalation route.

Finance should reconcile the final old-provider collections and first new-provider collections by customer, period, and currency. Track migration-related refunds or corrections separately so they are not mistaken for ordinary churn or new revenue. Keep both payout streams visible until their residual balances are explained.

Choose a processor change only with a realistic migration and exception plan in the proposal. The best portability promise is a documented route for your actual payment population, supported by mappings, billing checks, and a plan for customers whose credentials or authorizations cannot simply carry over.