Can I reuse tokens with different payment service providers?

With gateway tokenisation, tokens are tied to a single PSP. If you switch providers, you must re-collect card data. PCI Proxy tokenisation is PSP-agnostic - the same token can be de-tokenised and forwarded to any payment processor. This gives you full portability and eliminates vendor lock-in.

Technical Guide

Card Tokenisation: Deep Dive

Q: What is the difference between tokenisation and encryption?

Encryption transforms data using a mathematical algorithm and a key - the original data can be recovered with the correct key. Tokenisation replaces data with a randomly generated substitute (the token) that has no mathematical relationship to the original. Tokens cannot be reversed without access to the token vault. For PCI DSS scope reduction, tokenisation is generally more effective because encrypted data is still considered cardholder data under PCI DSS, whereas correctly implemented tokens are not.

Q: How does the token vault protect stored card data?

The token vault uses multiple layers of protection: AES-256 encryption for data at rest, Hardware Security Modules (HSMs) for key management, strict role-based access controls, network segmentation and comprehensive audit logging. The vault operates within a PCI DSS Level 1 certified environment and is monitored 24/7. De-tokenisation requests require authenticated API calls with IP whitelisting and time-limited access windows.

Tokenisation replaces sensitive card data with non-sensitive equivalents. Explore the different types, understand how the token vault works and learn why PSP-agnostic tokenisation gives you a lasting competitive advantage.

Core Concept

What is Card Tokenisation?

Tokenisation replaces a PAN (Primary Account Number) with a non-sensitive token. The token resembles a card number, passes validation checks, but has no exploitable value if stolen. The real data remains in an isolated vault.

Substitution, Not Encryption

Unlike encryption, tokenisation replaces data with a random value. There is no key to "decrypt" a token - the mapping exists only inside the secure vault.

Outside PCI DSS Scope

Correctly generated tokens are not considered card data under PCI DSS. Systems that handle only tokens fall outside the compliance perimeter, dramatically reducing audit scope.

Cross-PSP Reusable

A single token can be used for recurring billing, refunds, multi-PSP routing and loyalty lookups - decoupling business logic from raw card data.

tokenization-flow.json

// 1. Input: raw customer PAN

4111 1111 1111 1234

PCI Proxy Vault · AES-256 + HSM

// 2. Output: secure token in your systems

tok_eu_9f8e7d6c5b4a1234

// 3. Original PAN: never on your servers

Encrypted Vault · EU Only · FIPS 140-2 HSM

PCI DSS

Level 1 Certified

AES-256

Encryption at Rest

100% EU

European Data Residency

< 50ms

Average API Latency

Comparison

Tokenisation Types Compared

Network tokens, gateway tokens and PCI Proxy tokens serve different purposes - with different implications for portability, architecture and vendor lock-in.

Feature	Network Token	Gateway Token	PCI Proxy Token RECOMMENDED
Issued by	Schemes (Visa, Mastercard)	Your PSP / gateway	PCI Proxy (independent)
PSP Portability	Scheme only	No, vendor lock-in	Any PSP
Automatic card updates	Yes (VAU/ABU)	Gateway dependent	Yes
PCI scope reduction	Moderate	Moderate	Maximum
Cross-channel support	E-commerce	E-commerce	E-comm, MOTO, API

Token Formats

Token Formats and Standards

The token format determines how it integrates with your existing systems, validation logic and database schemas.

format-preserving

// Original PAN

"4111 xxxx xxxx 1234"

// Token output

"4111 8273 6540 1234"

↑ BIN + last4 preserved

Format-Preserving

Same length and charset as the PAN. Passes Luhn checks and stores in existing DB columns without schema changes.

random-opaque

// Original PAN

"5412 7512 3456 7890"

// Token output

"tok_eu_a3f9b2c14d8e"

↑ Prefix + random string

Random / Opaque

Prefixed alphanumeric strings (tok_eu_) with no relation to the PAN. More resistant to pattern analysis.

bin-retention

// Original PAN (19 digits)

"3714 496353 98431"

// BIN (8 digits) preserved

"3714 4963 7f2a 9c1b 8e4d"

↑ Routing + brand ID safe

BIN Retention

Retain the first 6–8 digits for routing and brand identification. PCI DSS v4.0 permits this if the remaining digits are random.

Vault Architecture

Inside the Token Vault

The vault stores the token/PAN mapping, manages cryptographic keys and enforces access control - all within a PCI DSS Level 1 certified perimeter.

PCI DSS Level 1 Certified Environment

EU Only · FIPS 140-2

Layer 1

Network Segmentation

Isolated VLAN with no direct internet access. WAF + IDS/IPS at every tier. Micro-segmentation limits lateral movement between vault components.

Layer 2

Encryption at Rest (AES-256)

All PANs encrypted with AES-256 before storage. Keys generated, stored and rotated inside FIPS 140-2 Level 3 HSMs. Never in plaintext outside the HSM perimeter.

Layer 3

HSM Key Management

Dual-control, split-knowledge key ceremonies. Automatic key rotation. Separate KEK and DEK to prevent single-point compromise.

Layer 4

Access Control and Audit

RBAC with least-privilege principle. Every tokenisation and de-tokenisation logged with timestamp, IP, merchant ID. Immutable logs for QSA compliance.

100% Guaranteed European Data Residency

The entire infrastructure operates in certified EU data centres. Cardholder data never leaves European jurisdiction - satisfying GDPR and European acquiring bank requirements.

GDPR ISO 27001

PSP-Agnostic Portability

Token Reuse Across PSPs

PCI Proxy tokens are not tied to any payment provider. Same tokenisation, any PSP, at any time.

1 Token

Single tokenisation, unlimited processors

∞

PSPs supported

Re-enrollment

100%

Portability

Switch PSP Without Re-Collection

Zero Downtime

Switch processor for better rates - tokens remain valid. No card-on-file loss.

Intelligent Multi-PSP Routing

Smart Routing

Route by card brand, region or approval rates. Each PSP receives the PAN only at execution.

Subscriptions and Recurring Payments

Auto Card Update

Store once, charge forever. The token stays stable even when the card is reissued.

Cross-PSP Refunds and Chargebacks

Full Audit Trail

Same token for refunds even on a different PSP from the original. Full history for audits and disputes.

Security

De-Tokenisation Controls

4 overlapping layers ensure that only authorised systems can access raw PANs - and only when strictly necessary.

Active layers

Unauthorised access

RBAC - Roles and Permissions

Zero Trust

Only API keys with explicit permissions can retrieve raw PANs. Least-privilege principle enforced by design.

IP Whitelisting

Network Layer

Requests restricted to pre-approved IPs. Unrecognised sources rejected instantly with real-time alerts.

Time Window

Time-Bound

Permissions with 60-second windows. On expiry the token does not resolve until a new authenticated session starts.

Immutable Audit Logs

Full Trace

Every event records merchant ID, API key, IP, timestamp, destination PSP. Tamper-proof, retained ≥ 12 months for QSA audit.

Direct Comparison

Network Tokenisation vs PCI Proxy Tokens

Not all tokens are equal. This distinction determines PCI scope, portability and provider independence.

Scope reduced - Network Token

~30%

PCI PROXY

Scope reduced

up to 95%

PSP Portability

∞ PSPs

Dimension	Network Token (Visa/MC)	PCI Proxy Token RECOMMENDED
Issued by	Payment schemes (Visa, Mastercard)	PCI Proxy provider
Scope	Replaces PAN in network transactions	Replaces PAN in your infrastructure
PSP Portability	Scheme-dependent	PSP-agnostic
Reduces PCI scope	Partially	Completely
Works for MOTO	No	Yes
Storage	Scheme vault	Your chosen vault (EU)

FAQ

Frequently Asked Questions about PCI Proxy and Tokenisation

From the comparison with encryption to cross-PSP reuse: the answers you were looking for.

01 What is the difference between tokenisation and encryption?

Encryption transforms data with a reversible mathematical algorithm - with the right key you recover the original data. Tokenisation replaces the PAN with a random value that has no mathematical relationship to the original - it is not reversible without vault access. For PCI DSS, encrypted data is still "card data"; correct tokens are not.

02 Can I reuse tokens with different PSPs?

With gateway tokenisation, tokens are tied to a single PSP - if you change provider, you must re-collect card data. PCI Proxy is PSP-agnostic: the same token is de-tokenised and forwarded to any processor. Full portability, zero vendor lock-in, advanced multi-PSP routing.

03 How does the token vault protect stored card data?

The vault uses multi-layer protection: AES-256 for data at rest, FIPS 140-2 Level 3 HSM for key management, RBAC, network segmentation and immutable audit logs for every operation. Operates in a PCI DSS Level 1 certified environment, monitored 24/7. De-tokenisation requests require API authentication + IP whitelisting + time windows.

PCI DSS Level 1 AES-256 + HSM FIPS 140-2 PSP-agnostic EU data residency

Ready to Tokenise with Confidence?

Discover how PCI Proxy tokenisation integrates into your architecture, or dive deeper into how it reduces your compliance scope.