Tokenisation is the reason a modern store can offer one click reordering without ever holding a card number. It is also the most misunderstood part of a payment stack, because the word is used for two different things.
Two kinds of token
Gateway tokens are issued by your gateway when a card is captured. They are meaningless outside that gateway account. Your store keeps a reference, and any future charge sends the reference rather than the card.
Network tokens are issued by Visa or Mastercard and are tied to the card itself. They survive a card being reissued, which is why a wallet payment keeps working after the plastic is replaced.
Most WooCommerce stores use gateway tokens, and receive the benefit of network tokens indirectly through wallets and account updater services.
What happens at the checkout
- The card fields on your checkout are served by the gateway, not by your theme, and run inside an iframe.
- The shopper types the number into a field your JavaScript cannot read.
- The gateway returns a one time payment token to the browser.
- Your server receives that token and asks the gateway to authorise against it.
- If the shopper chose to save the card, the gateway stores it in a vault and returns a permanent customer token.
At no point does the card number reach your server, your database, your logs or your backups. That is the design goal, and it is what keeps a store inside the shortest PCI questionnaire.
What a token can and cannot do
- It can be charged again, refunded, and used for a subscription renewal.
- It cannot be used at another merchant, because it is scoped to your gateway account.
- It carries no CVV, because storing the code is prohibited. Do not build a flow that expects one on a repeat charge.
- It usually carries the brand, last four digits and expiry, which is what lets you show a card on a My Account page.
- It survives a database dump. A stolen token is worthless without your gateway credentials.
Initiated by whom, and why the flag matters
The networks distinguish a charge the customer is present for from one your system starts on a schedule. Getting the flag wrong on a stored card is a common cause of unexplained declines on renewals: the issuer sees a card not present transaction with no cardholder and no agreement reference, and refuses it.
The first charge should be flagged as customer initiated and should store the agreement. Every later renewal should be flagged as merchant initiated and should reference that first transaction. Any plugin that handles subscriptions properly does this for you, and any plugin that does not will look like a mysterious decline problem.
Housekeeping that is easy to forget
- Delete tokens when a customer deletes their account, in the vault as well as in your database.
- Handle the expiry date, and prompt before it passes rather than after a failed renewal.
- Never show more than the last four digits, anywhere, including admin screens and emails.
- Keep the mapping between customer and token in one place, so a support agent can answer which card is on file without opening the gateway.
The saved cards page shows what this looks like once it is wired into WooCommerce.