Card tokenisation explained: how saved cards stay secure

Card tokenisation replaces a customer's real card number with a random substitute value, called a token, that is useless to anyone who steals it. Your payment gateway keeps the real card details in its own secure vault and gives you only the token, so you can charge the card again later (for a subscription, a top-up or a one-click repeat order) without ever storing the card number yourself.

That's the short answer. The rest of this guide covers the different kinds of tokens, what tokenisation does and doesn't do for your PCI DSS obligations, and the practical rules for billing saved cards in South Africa.

How card tokenisation works, step by step

A typical first payment with tokenisation looks like this:

1. The customer enters their card on the gateway's page or field. This is a hosted payment page, a redirect, or an embedded iframe supplied by the gateway. The card number never touches your server.
2. The customer authenticates. Online card payments in South Africa normally go through 3D Secure, where the customer approves the payment in their banking app or with a one-time PIN.
3. The gateway authorises the payment and stores the card in its vault. It links the card to your merchant account and your customer.
4. The gateway returns a token. It's a string such as tok_8f3a... or a gateway-specific reference, often alongside safe display data like the card brand, last four digits and expiry month.
5. You store the token against the customer record. Later, you send the token and an amount to the gateway's API and it charges the card.

The token only works for your merchant account on that gateway. If a criminal copied your whole customer table, the tokens would be worthless to them anywhere else.

Tokens versus encryption

People often mix these up, so it helps to be precise.

Encryption is still essential (all card data travels over TLS, for example), but if you encrypt card numbers and store them yourself, you still hold card data and all the obligations that come with it. Tokenisation moves that data out of your systems altogether.

Gateway tokens and network tokens

There are two layers of tokenisation you'll hear about.

Gateway (vault) tokens

This is what most South African merchants use day to day. Gateways that support saved cards issue their own tokens (or reusable authorisation references) for cards stored in their vaults. Payfast, for instance, markets a tokenization feature for accepting repeat once-off payments without asking the customer to authorise each one (Payfast features, as of September 2026). The catch is portability: a token from one gateway can't be used on another. If you move gateways, you usually need customers to re-enter their cards, unless both providers support a secure card-data migration between them.

Network tokens

Card schemes such as Visa and Mastercard also issue tokens that replace the card number across the payment network itself. The practical benefits are that the token can be updated automatically when the bank reissues a card (new expiry date or new number after a loss), and issuers see a more trusted credential. Whether you get network tokens depends on your gateway and acquirer, and often happens behind the gateway token without you seeing it. Ask your provider whether they use them.

What card tokenisation does for PCI DSS

PCI DSS (the Payment Card Industry Data Security Standard, currently version 4.0.1) applies to anyone who stores, processes or transmits card data. The less card data your systems touch, the smaller your compliance burden.

If card details are entered only on your gateway's hosted page or iframe, and you only keep tokens, you are usually eligible for one of the shorter self-assessment questionnaires rather than a full assessment. Note the January 2025 update to SAQ A, effective 31 March 2025: it removed two script-related requirements but added an eligibility condition that your site isn't susceptible to script attacks. Merchants using an embedded iframe need to confirm their protections, while full-redirect merchants are less affected. Confirm your level with your acquirer and the PCI Security Standards Council. For the trade-offs between redirect and iframe, see hosted vs embedded checkout.

Tokenisation reduces scope. It doesn't remove your responsibilities entirely: you still need secure access to your gateway dashboard, protected API keys, and sensible handling of customer personal information under POPIA.

Rules for charging a saved card

Holding a token doesn't give you the right to charge whenever you like. Good practice, and in most cases your gateway's terms, expects the following.

• Get clear consent at the first payment. Tell the customer you'll store their card and when you'll charge it: "R349.00 on the 1st of each month until you cancel."
• Distinguish customer-present and merchant-initiated charges. When the customer clicks "pay now" with a saved card, they may be asked to authenticate again. When you charge them on a schedule, your gateway flags it as a merchant-initiated charge that relies on the original consent.
• Charge only what was agreed. Changing the amount (a price increase or plan change) needs notice and, depending on your terms, fresh consent.
• Make cancellation easy. A self-service way to remove a card or cancel a subscription reduces disputes and chargebacks.
• Plan for failures. Saved cards expire, get replaced or hit limits. You need a retry schedule and a way for customers to update their card. Our guide to recurring card payments in South Africa covers this in more depth.

A worked example

Say you run a meal-kit business charging R649.50 a week. At sign-up, the customer pays the first box through your gateway's hosted page and approves 3D Secure. The gateway returns a token plus "Visa ending 4821, expires 11/28". Every Monday your billing system sends the token and R649.50 to the gateway. In week 14 the charge is declined with "insufficient funds". Your system retries on Wednesday and succeeds. In week 60 the card expires; if network tokens are in play the gateway may already have the new details, otherwise the customer gets an email with a link to update their card. At no point did the card number sit in your database.

Common questions from finance and tech teams

Can we export tokens to our accounting system? You can store the token reference, but there's little point: it only works through the gateway API. Your accounting system needs the payment result, not the token.

What happens to tokens if we change gateway? Plan for customers to re-enter cards unless your old and new providers support a secure migration. Running multiple payment gateways can soften this by letting you move customers gradually.

Should developers ever see raw card numbers in logs? No. If card numbers are appearing in logs, something is wrong with the integration.

How CentraPoint uses tokenisation

CentraPoint never stores card numbers. When a customer pays through a connected gateway such as PayFast, Paystack or Peach Payments, the gateway holds the card and CentraPoint keeps only the gateway token, which it uses to collect subscription renewals automatically, with dunning retries and past-due handling when a charge fails. Customers can manage their plans through the self-service portal, and gateway credentials are encrypted at rest with AES-256-GCM. You can read more on our security page.

Frequently asked questions

Is card tokenisation the same as encryption?

No. Encrypted card data can be decrypted by anyone with the key, whereas a token is a random substitute that only the issuing vault can map back to the card. Tokenisation means you don't hold card data at all.

Do I still need PCI DSS compliance if I use tokens?

Yes, but usually at a lighter level. If cards are captured only on your gateway's hosted page or iframe and you store only tokens, you typically qualify for a shorter self-assessment questionnaire; confirm with your acquirer.

Can I use a PayFast token on Paystack, or the other way round?

No. Gateway tokens only work with the vault that issued them. Moving gateways normally means customers re-enter their card details, unless both providers support a secure migration.

Does a token expire when the card expires?

The token may stay valid, but charges will fail once the underlying card expires unless the gateway receives updated details, for example through network tokens. Build in a way for customers to update their card.