The Cards You Keep: Preserving Repeat Revenue Through an Offshore Acquirer Switch

When a UK merchant has spent years building a card-on-file base, those stored credentials are an asset in all but name. Moving them to a new offshore acquirer is therefore less a rerouting exercise than a custody arrangement: the merchant must demonstrate to the scheme, to the Information Commissioner's Office if asked, and to its own board that recurring revenue will survive the transition. The commercial risk is asymmetric. A poorly handled switch can lose a cohort of subscribers in a fortnight, and no improvement in headline pricing will recover them.

Two Kinds of Credential, Two Very Different Exit Routes

The first distinction to grasp is between network tokens and acquirer tokens. A network token is issued by the scheme, through Visa Token Service or Mastercard's Digital Enablement Service, and is tied to a token requestor identifier. In principle it is portable, because the underlying reference belongs to the scheme rather than to any single processor. In practice, portability depends on whether the new acquirer can be enrolled as a token requestor against the merchant's existing arrangement, and on whether the scheme will permit the token to be reassigned rather than reissued.

An acquirer token, by contrast, is a local construct. It is generated by the processor, meaningful only within that processor's environment, and generally worthless once the relationship ends. Contracts that describe stored credentials as 'the merchant's data' while holding them in acquirer-token form are offering a comfort that the technology does not deliver. A merchant that signs on that basis may discover, at exit, that it holds a right to data it cannot practically use.

Terms Worth Settling Before Signature

Portability is easier to negotiate at onboarding than at termination. Before committing to a new offshore acquirer, a UK merchant should secure an explicit clause covering the export of stored credentials in a scheme-aligned format, ideally as portable network tokens with the token requestor identifier transferred or co-registered. Where that is impossible, the contract should at least specify the format, the timeline, the cost and the cooperation obligations that will apply on exit.

Three further points merit attention. First, the notice period and the treatment of any holdback during migration should be aligned so that reserve funds are not trapped while the merchant is funding a parallel acquiring arrangement. Second, the contract should confirm that the acquirer will not block or degrade transaction processing during a good-faith migration window. Third, merchants with several brands or trading entities should confirm that portability applies across the whole portfolio rather than to a single merchant account.

The Compliance Perimeter

Moving credentials is a change to a data flow, and data flows attract scrutiny. Under UK GDPR, the merchant is normally the controller of cardholder data and the acquirer or gateway is a processor. Article 28 requires a written processor agreement, and any transfer of data outside the UK needs a valid transfer mechanism, typically the international data transfer agreement or the addendum. Retention periods should be mapped before migration, not after, and the merchant should be able to show that only the minimum data necessary has been moved.

PCI DSS adds a second layer. Tokenisation can reduce the scope of a merchant's assessment, but a migration is precisely the moment when scope tends to expand quietly. The migration should be documented as a change to the cardholder data environment, with updated evidence for the Attestation of Compliance, a defined secure transfer channel, key-management controls that satisfy PCI DSS version 4.0.1, and a documented destruction process for any legacy records that are not required. Credentials should never travel by email, spreadsheet or removable media.

Testing Without Provoking a Decline Cascade

Issuers respond to unfamiliar acquiring arrangements with caution, and a migration that goes live across the entire base in one weekend invites a wave of declines that is difficult to reverse. A staged approach is more prudent. Begin with a small cohort, ideally low-value subscriptions in a single card brand, and monitor authorisation response codes rather than aggregate approval rates alone. Distinguish soft declines, which may respond to retry logic, from hard declines and issuer blocks that indicate a credential problem.

Merchant-initiated transaction indicators, Strong Customer Authentication exemptions and transaction risk analysis thresholds should be configured and tested before the cohort is widened. Account updater services should be enabled so that stale credentials are refreshed rather than simply declined. A rollback plan, with a defined trigger point and a pre-agreed route back to the incumbent acquirer, is not a sign of weak conviction; it is the minimum standard for a change of this kind.

Sequencing the Cutover

Timing matters more than many merchants expect. Cutover should avoid month-end billing peaks, major promotional periods and the weeks around card expiry cycles. A useful sequence is to migrate by card brand, then by billing date, then by product line, widening only when decline patterns are stable for a full billing cycle. Customer communications should be prepared for the minority of cases where re-authorisation is required, and support teams briefed on the decline language they may encounter.

After the Switch

Reconciliation does not end at go-live. The merchant should compare settlement timing, scheme fee lines and chargeback ratios for at least two billing cycles against the pre-migration baseline. Any drift in approval rates should be traced to a specific decline reason rather than attributed to the acquirer in general. Records of the migration, including testing evidence, transfer logs and processor agreements, should be retained to support both scheme queries and any later regulatory enquiry.

Stored credentials are only as portable as the contract and the architecture allow. A merchant that treats the token question as a technical footnote risks discovering, at the worst possible moment, that the cards it thought it kept were never really its to move.