Tokenised payments
Proprietary payment references can trap returning-customer transactions within one provider. Cross-acquirer tokenisation replaces raw card numbers with portable gateway references, mapped by Cardflo’s orchestration token proxy to the selected acquirer partner.
- Category
- Security
- Capabilities
- 10
- Available on
- All plans
Protect sensitive cardholder data and simplify PCI compliance with Cardflo's tokenised payments. By replacing actual card numbers with unique, non-sensitive tokens, you can process transactions securely without storing raw card data.
This reduces your PCI DSS scope and enhances data security.
Cardflo’s tokenisation secures raw card data by replacing sensitive information with a unique identifier, considerably reducing PCI DSS scope for merchants. This allows for safe recurring and one-click payments across diverse acquirer partners, streamlining transaction flows.
Tokenised payments overview
Tokenisation is a security process that substitutes sensitive primary account numbers (PANs) with non-sensitive digital identifiers known as tokens. Within the payment stack, this mechanism typically occurs at the gateway or PSP level, ensuring that raw cardholder data is not stored on the merchant server.
By decoupling the transaction identifier from the original financial credentials, businesses can reduce their pci-dss compliance scope to simpler self-assessment questionnaires. These tokens can be restricted to specific merchants, device types, or transaction classes, providing a granular layer of control that regular pan data lacks.
When a transaction is initiated, the token is transmitted to the vault where the corresponding pan is retrieved for authorisation with the acquirer and issuer.
This architecture ensures that even in the event of a database breach, the captured data remains useless to unauthorised parties, as the tokens cannot be reverse-engineered to reveal the original card details.
How tokenised payments works
Data capture and vaulting
When a customer enters their card details during checkout, the sensitive data is sent directly to a secure vault. The system validates the credentials and stores the pan behind multiple layers of encryption. A randomly generated alphanumeric string, or token, is created to represent this specific card record for all future processing.
Token issuance and mapping
The vault returns the token to the merchant or orchestrator, who stores it in their database instead of the raw card number. This token acts as a pointer, allowing the business to reference the payment method for recurring billing or one-click purchases without handling prohibited sensitive authentication data directly.
Authorisation and routing
For subsequent transactions, the merchant sends the token to the payment gateway. The gateway or vault provider swaps the token for the original pan and forwards the request to the acquirer. The issuer then authorises the transaction based on the decrypted credentials, maintaining standard authorisation flows without compromising security.
Token lifecycle management
Tokens can be updated, suspended, or deleted without affecting the underlying card account. If a merchant-specific token is compromised, it cannot be used at other businesses. Furthermore, account updater services can refresh the vaulted pan data while keeping the merchant-held token static, ensuring continuous billing cycles.
Why tokenised payments matters
Enhanced data breach resilience
If a merchant database is compromised, traditional card data is immediately exploitable for fraudulent transactions. Tokens, however, are architecturally distinct and typically restricted to the specific merchant who requested them. A stolen token is valueless to a secondary party because the payment processor will only honour the token when presented by the authorised merchant, effectively neutralising the impact of data theft on cardholders.
Customer friction reduction
Modern commerce relies on returning customer convenience, such as one-click checkouts and subscription models. Tokenisation facilitates these experiences by allowing merchants to store a representative identifier of the payment method safely. This eliminates the need for the customer to re-enter their card details for each purchase, which is proven to reduce cart abandonment rates and support higher customer lifetime value through simplified renewals.
Tokenised payments use cases
Processor migration token handoff
A merchant moving transaction traffic between providers needs existing customer payment references to remain usable without exporting PANs or rebuilding its database. Cardflo maps gateway-generated tokens to the selected acquirer connection, allowing staged MID migration while PCI proxying keeps sensitive card data outside the merchant environment.
Marketplace tokens across acquirer partners
An online retailer routing card-not-present transactions needs the same payment reference to work when a timeout requires traffic to move to another acquirer. Cardflo resolves an acquirer-agnostic token against the fallback connection, preserving PCI DSS scope controls without exposing PANs to the retailer’s routing application.
Token portability for digital goods
A call centre taking mail order and telephone order payments needs agents to retrieve customer payment methods without displaying or storing PANs in its CRM. Cardflo tokenises card details through a PCI proxy and returns portable references that authorised workflows can submit through different acquirer mappings.
Shared tokens across retail brands
A retailer operating web, mobile and in-store ordering needs one customer payment reference across channels connected to different acquirers and MIDs. Cardflo provides a gateway token layer that maps each reference to the appropriate endpoint, while merchant systems retain only non-sensitive identifiers for subsequent cardholder-initiated transactions.
Tokenised payments by the numbers
Typical reduction in the number of security controls a merchant must manage when adopting a vault-based tokenisation strategy compared to storing raw pan data.
Observed industry ranges for authorisation improvements when using network tokens, as issuers often place higher trust in these secured credentials.
The relative financial impact of a database breach when only tokens are exposed, as the lack of usable card data prevents direct fraudulent losses and related liability.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Tokenised payments
- Minimise pci-dss audit scope by removing sensitive cardholder data from internal merchant environments.
- Eliminate the requirement to store sixteen-digit primary account numbers within local database structures.
- Facilitate merchant initiated transactions for automated subscription renewals and recurring billing cycles.
- Support one-click checkout experiences for returning customers to reduce payment friction at checkout.
- Protect against fraudulent use of stolen data by using merchant-specific non-reversible digital tokens.
- Enable account updater integration to maintain valid payment credentials without manual customer intervention.
- Provide a secure method for processing refunds and partial captures using historical token references.
- Secure customer payment profiles for use across multiple platforms and various digital sales channels.
- Maintain high authorisation rates by ensuring tokens remain synchronised with the underlying issuer data.
- Reduce the risk of heavy fines and reputational damage resulting from potential data breaches.
A short scoping call, then a written plan for your MIDs.
Questions about Tokenised payments
How does tokenisation differ from standard data encryption?
Encryption uses an algorithm to transform card data into ciphered text, which can theoretically be decrypted if the key is stolen. Tokenisation replaces the data entirely with a randomised identifier that has no mathematical relationship to the original pan.
A token cannot be reversed; it can only be mapped back to the original data by the authorised vault provider. This makes tokenisation generally more secure for merchant storage as the internal environment never holds the decryption keys or the raw data itself.
How does cross-acquirer tokenisation keep merchant payment references consistent?
Cardflo generates a stable gateway token that merchants can retain as the payment reference in their systems. Behind that reference, the orchestration layer maps provider-specific credentials and formats required by each connected acquirer partner.
When routing changes, the merchant continues submitting the same token rather than rebuilding integrations around a new provider reference. Raw PAN data is proxied within the controlled payment environment, helping reduce exposure across merchant applications and databases.
How are cross-acquirer tokens isolated between merchant systems and environments?
Cross-acquirer tokens are scoped to the relevant merchant configuration, preventing one organisation from using another merchant’s references. Production and test environments maintain separate token namespaces, so sandbox references cannot be submitted against live acquirer connections.
Access is governed through authenticated API credentials and merchant-level permissions, while token-to-provider mappings remain inside Cardflo’s orchestration environment. This separation supports multi-brand or multi-entity architectures without exposing raw PAN data to merchant databases.
Will using tokens affect my transaction authorisation rates?
In most cases, tokenisation has a neutral or positive effect on authorisation rates. When using network tokens, which are issued by the card schemes like visa or mastercard, issuers can see that the transaction is backed by a secure credential.
This often leads to higher trust scores and fewer false declines compared to traditional pans, which may be flagged if the stored data is outdated or if the transaction looks suspicious.
Is a token the same as a digital wallet token like Apple Pay?
While both use the concept of tokenisation, they serve different purposes. Digital wallets use network tokens that are stored on a device and are specific to the hardware.
Merchant tokens, or vault tokens, are generated by a gateway or PSP to be stored in a merchant's database for recurring use.
Both methods aim to protect the pan, but the merchant token is designed for server-side persistence whereas the wallet token is designed for consumer-side transaction security.
What happens to the tokens if I change my payment service provider?
This depends on whether you use a provider-specific vault or an independent vault. If the tokens are proprietary to a single PSP, migrating them to a new provider can be complex and requires a secure data export and import process.
Using an independent tokenisation service or an orchestration layer can provide greater flexibility, allowing you to move between different acquirers and gateways without needing to re-tokenise your entire customer database.
Does tokenisation work with international payment methods and APMs?
Tokenisation is predominantly used for credit and debit card schemes, but the concept is increasingly being applied to alternative payment methods (APMs) and open banking.
Many modern gateways provide the ability to tokenise direct debit mandates or digital wallet identifiers, allowing for a consistent management experience across various payment types within the merchant's customer profile system.
Related features.
Related guides.
See how Cardflo compares.
From the blog
A merchant acquirer is a licensed bank that holds your account, takes liability for transactions, and settles funds. The payment processor is the technology layer routing data between the checkout, card networks, and issuing banks. Every card payment requires both components to manage technical encryption and financial liability. They are often separate entities with distinct fee structures.
Read articleA merchant acquirer is a financial institution that processes card transactions and verifies funds. The payment gateway acts as the technological bridge, encrypting sensitive data between the website and the acquirer. Merchants need both components to ensure that electronic payments are accepted, authorised, and settled. Together, they create a seamless and secure payment experience for customers.
Read articleA merchant account is a specialised business account used to accept electronic payments like Apple Pay and Google Pay. It acts as a bridge between the business and the customer bank. Funds are held here for verification and compliance before being transferred to a main bank account. This process ensures that all transactions are secure and reduces the risk of fraud for the merchant and the customer.
Read articleReady to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.