Designing an Agnostic Card Token Vault
The gravest architectural mistake a global enterprise can make is allowing their primary acquirer to trap their customer credit card data. Relying exclusively on a PSP-specific token binds you to their pricing API. To achieve a true multi-acquirer stack, you must engineer or leverage an Agnostic Token Vault.
FPAN vs DPAN Data Mapping
A modern vault does not simply store a credit card number encrypted. It acts as a massive graph database correlating different representations of a single payment instrument:
- FPAN (Funding Primary Account Number): The raw 16-digit card number. Storing this brings an immense PCI-DSS compliance burden.
- Proprietary Tokens: The unique string (e.g.,
cus_123_tok_abc) returned by Acquirer A, Acquirer B, and Acquirer C for that exact same FPAN. - Network Tokens (DPAN - Device PAN): Multi-use cryptograms provided directly by Visa and Mastercard via the TR (Token Requestor) API, completely independent of the acquirer.
The Forward Proxy Mechanism
When generating a payment through Acquirer B, the merchant system passes the Agnostic Vault Token (e.g., rv_tok_8f902...) to the RiyadaVenture Forward Proxy. The proxy intercepts the request, dynamically detokenizes it back to the FPAN (or Network Token DPAN), injects it into the JSON payload, and hits Acquirer B's API. The merchant never touches the raw data.
PCI-DSS Descoped by Default
Building a secure vault internally requires isolated subnetworks, strict HSM (Hardware Security Module) utilization for symmetric key encryption, and rigorous continuous monitoring under PCI DSS v4.0. Leveraging a managed agnostic vault removes this burden entirely, replacing it with a secure iFrame or Drop-in elements that capture the raw data straight from the client's browser securely connecting to the Vault API.
Agnostic Tokenization is the foundation of Payment Orchestration and is natively integrated into RiyadaVenture's routing architecture.