Reviewed October 17, 2026. This operational guide replaces an earlier general overview. The original publication date and URL are retained.
A payment token answers a credential question, while a customer profile answers an account question. Keep those records separate when combining guest purchases, loyalty accounts or shared business buyers.
Define three separate identifiers
Record the order identifier, the business’s customer identifier and the provider’s permitted payment reference as separate fields. EMVCo describes payment tokenisation as replacing card account data with payment tokens that can be constrained to particular uses. That does not make a token a universal customer identifier. Ask the provider how its reference behaves across devices, merchant accounts and credential changes before designing any matching logic.
Rehearse a shared-card purchase
In an illustrative business account, two authorized employees buy supplies using an approved company payment arrangement. The payment relationship does not establish that their delivery contacts or personal loyalty profiles should merge. In the reverse case, one customer may use several supported devices or credentials. Treat matching results as evidence to review under the account policy rather than a command to overwrite customer records.
Keep a profile correction from changing payment authority
If support merges duplicate profiles, specify which order histories move, which contact data remains and how the action is reviewed. Do not silently transfer saved-payment permissions or recurring agreements with a profile merge. Those decisions need the applicable customer authorization and provider-supported workflow. Test that staff can still locate the original sale through its order reference after a corrected profile name.
Measure incorrect associations before automating
Build a small approved test set with guest checkout, shared business buyers, changed credentials and duplicate profile names. The pass criterion is correct order retrieval without exposing another account’s saved-payment options or history. Keep real credentials out of the test worksheet. The output should be a field map, merge boundaries and a reversible correction procedure. It is a data-quality control, not an identity-verification service.
Sources and next steps
Primary reference: EMVCo’s payment tokenisation overview. Examples are illustrative analysis, not client results or provider quotes.
Continue with the payment-vault migration guide and the AMS New York merchant reading path.
Use the merchant technology decision worksheet to document the expected output, responsible person and acceptance evidence.
