Can an outgoing processor refuse to migrate tokens?

It can delay the migration and, in some cases, refuse it. The outgoing processor has to accept the request, check the receiving side's PCI DSS compliance and agree on the transfer procedure. That is why the first item on the checklist is the contract: what the agreement says about data portability, notice periods and export fees, before the operator commits to a new processor.

What the outgoing processor controls

Tokens issued by a processor point to card numbers stored in its vault. Moving them means the processor exports the underlying card data to the new provider, under PCI DSS rules. The processor has to accept the request, verify that the receiving vault is validated, agree on the encryption and transfer procedure, and schedule the export. Each step is a place where it can slow down or say no.

What decides the outcome

• The contract: clauses on data portability, notice periods, export fees and the format delivered.
• The relationship: a processor losing volume has little incentive to hurry.
• Compliance: the processor can legitimately refuse a transfer to a vault without a valid attestation.

How operators protect themselves

Read the portability clause before signing, not before leaving. Ask for the export format and fee in writing. Store new cards as network tokens, which belong to the scheme rather than the processor and move more easily. And keep a universal token on the platform, so new customers and subscriptions can go to the new provider while the old tokens are still being billed on the old one. The migration then becomes a background task rather than a cutover.