When a customer pays through a processor, their card details are tokenized into a credential scoped to that PSP account. If you try to route a retry, fallback, or recurring charge through a different processor, that token is unreadable. The second PSP has no context for it, and the transaction fails before it even reaches the network.
The way you solve this problem determines how much flexibility and control you actually have over your payment stack.
Why PSP-scoped tokens create fragility
The business impact is straightforward. If your primary processor declines a transaction or goes down, and your fallback requires the same token that was issued by the primary, you have no fallback. The retry fails, the customer sees a declined payment, and the revenue is lost.
The same problem surfaces in recurring billing. A customer whose card was originally tokenized through PSP A cannot be charged through PSP B during a retry window without access to the underlying card data or a portable token. For subscription businesses or any platform with high card-on-file volume, that fragility compounds at scale.
The fix requires stepping back from PSP-native tokenization entirely and owning the token layer yourself, or working with a provider that does it for you.
Using Primer to route card payments across multiple PSP accounts
Primer's Agnostic Vault is built to solve exactly this problem. Rather than storing card data as a PSP-specific token, Primer's agnostic tokenization service and centralized vault enable you to handle recurring payments, fallbacks, and retries across processors without compromising the customer experience. As Primer puts it directly: no more PSP-specific tokens — you own your payment data.
The practical result for payments ops teams is significant. You configure your PSP connections in Primer once. From that point, card data is stored centrally in Primer's PCI DSS Level 1 certified vault, independent of any individual processor. When a transaction needs to be retried through a different PSP, Primer resolves the right credential for that processor and routes accordingly, without any manual intervention and without the customer needing to re-enter their details.
For teams using network tokens, Primer's vault's agnostic nature means that tokens are not linked to any specific payment processor, allowing merchants to collaborate with their preferred providers without limitations. If a PSP encounters downtime or certain card types in specific regions, see payment rejections, Primer enables quick transaction retries using tokens with alternative processors. Merchants using network tokenization with Primer have seen as much as a 5% increase in authorisation rates with specific processors.
The routing logic itself requires no engineering once configured. Primer's no-code workflow builder uses drag-and-drop logic to define which processor receives which transaction, under what conditions, and in what order. You can build sophisticated payment routing rules based on over 100 conditions, including card type, customer ID, and issuer country. When a primary processor fails, the fallback fires automatically based on the rules you have set, and the transaction continues without the customer seeing anything.
With Primer's Observability dashboard, getting the full picture from one dashboard just takes a few clicks, with access to 100-plus visualisations and 30-plus filters to analyse payment data across all processors. For finance and ops teams, that means you are not logging into multiple PSP portals to understand why a retry rate is up or why a particular card type is declining at a higher rate. Everything is in one place, sliceable by processor, region, payment method, and more.
To see how Primer's vault and workflow tooling would work for your specific PSP setup, book a call
FAQ
1. How do you cascade card payments between multiple PSPs?
To cascade payments between processors, you must store card credentials independently of any single PSP. A PSP-agnostic vault tokenises the card once and provisions the correct credentials for each processor at the time of routing. This allows retries, failover, and smart routing without asking the customer to re-enter their card details.
2. Do network tokens solve multi-PSP routing on their own?
Not necessarily. While network tokens improve authorisation rates and lifecycle management, they can still be provisioned within a specific PSP context. To enable true multi-PSP routing and failover, network tokens must sit within an agnostic vault that can provision them across different processors.
.png)
