A substitute credential
Payment tokenisation replaces a primary account number with another value used within a payment arrangement. The useful idea is controlled substitution: systems can transact with a credential whose permitted context differs from the original card number, rather than exposing that number everywhere.
Not all tokens match
An EMV payment token and an application database identifier are not interchangeable concepts. Ask who issued the token, where it can be used, what lifecycle events it supports, and which systems can relate it to an underlying payment account when legitimately needed.
A support example
A customer replaces a card and later sees a subscription continue. Do not infer that the merchant necessarily stored the replacement card number. Investigate the credential and lifecycle arrangement. Conversely, a new token alone does not prove that a genuinely new customer has appeared.
Build careful identity links
Separate customer identity, funding account, physical card and token in your data model. A single person can legitimately use several tokens, and a token may have restricted use. Keep linkage permissions and access controls explicit; tokenisation does not make every associated customer datum harmless.