What a Payment Token Is, and Why It Locks You to Your Provider

A token is an identifier that replaces a card number. The customer enters the card once, the payment provider stores it in a secure environment and returns a meaningless identifier, and from then on you charge using that identifier. This is what makes recurring charging possible without card details living in your systems - and it is also what turns switching provider into a project.

How it works, without the jargon

1. The customer enters card details on the provider's payment page, not on yours.
2. The provider stores the details in an environment meeting the card data security standard.
3. The provider returns an identifier - a token - plus the last four digits and expiry, for display.
4. You store the token in your system, next to the customer.
5. On the next charge you send the token and the amount, not the card number.

The first step is what removes most of your risk. Once the number never passes through your servers, you do not have to protect it there either. That is why hosted payment pages and iframes are so common: they shrink what you have to secure.

The three ways a token gets created

It matters which way your tokens were created, because that decides what you can do with them later:

1. From the payment page. The customer signs up themselves, enters a card, and the token is created with the subscription. This is the cleanest route and also the one that produces the best consent record.
2. From a virtual terminal. An employee keys the card while on the phone with the customer. Excellent for phone collection, and it demands controls - who keyed it, who is authorised, and what was recorded about consent.
3. Through the API from inside your system. Suits sign-up that is part of a wider process. Here you must make sure the token is stored against the right customer, because a token saved on the wrong record will charge the wrong person.

The second route needs the most control, and it is also the common one in businesses that collect by phone.

What to do when the last four digits are all you have

When you need to ask a customer to update their payment method, you cannot tell them which card is stored - you do not have it. What you do have: the last four digits, the expiry, and sometimes the card type. That is enough to write a clear request:

• State the last four digits and the expiry so the customer recognises what this is about.
• Send an update link rather than asking them to reply with details. Card details should not travel in messages.
• Say what happens if they do not update, and when.
• Make sure the update creates a new token and attaches it to the same subscription rather than opening a second one.

That last point is a common bug: a customer updating a card through a fresh page sometimes creates a parallel subscription, and is then charged twice or not at all.

Why keep the last four digits and the expiry yourself

It sounds redundant - the provider holds the card - but without those two fields in your own copy you are blind in two practical situations:

• When you want to know what is about to expire. A report of subscriptions whose card expires next month lets you reach out before the failure rather than after. That is the difference between a reminder and a collection.
• When a customer calls and does not recognise a charge. Being able to read them the last four digits ends the call in a minute.

Neither field is sensitive the way a full number is, so holding them is usually permitted. Make sure they appear in the export the provider allows, because they are also what you will need if you change provider.

Why does the token not move to another provider?

Because it does not contain the card - it points to it inside that provider's vault. A token without the vault that created it is a meaningless number. So when you switch providers, the tokens you hold are worth nothing at the new one.

What sometimes does exist is an arranged migration process between providers, run with the card companies rather than between you and the provider. It is not always available, it needs the outgoing provider's cooperation, and it has a timeline. That is why you ask about it on signing day rather than on the day you want to leave. The practical detail is in switching payment provider with active subscriptions.

What to require in the agreement, because of tokens

The fourth row is the one nobody reads before signing and everybody wants afterwards.

What a token does not do

• It does not prevent declines. A credit limit, a block or an expired card will decline the charge even with a valid token.
• It is not consent. The customer's authorisation for recurring charging is a separate record, and you need to hold it.
• It does not replace an invoice. A successful charge still requires a document for the customer.
• It does not renew itself. An expired card needs an update mechanism, which is a separate system capability - see the non-negotiables in a recurring-charge system.

Sources

• PayBox - payment security and token system explanation, business page
• Cardcom - payment solutions
• Shva - the Israeli card clearing infrastructure