Vendor agnostic payments: What merchants need to know
Payments 101
Updated 24 Jun 2026
11 min
Andrii Kononenko
Head of Merchant Operations, Solidgate
Your payment stack works – until scale, new markets, or a contract renewal exposes how much control one provider actually has. Here’s what vendor-agnostic payments look like in practice.
Your PSP () works fine until it doesn't. Authorization rates plateau. A new market needs a local acquirer your provider doesn't support. Your subscription renewal rate drops, and you can't tell whether it's a routing problem, a retry timing problem, or a card credential problem. This happens because all of that logic lives inside one system you don't control.
9 in 10 merchants now work with two or more payment providers, . But adding a second provider doesn't make your stack vendor-agnostic. If card tokens stay locked in one vault and routing logic lives inside one system, the lock-in persists – it's just less visible.
A PSP-agnostic stack means no single provider holds the critical components – tokens, routing logic, market access – so switching or adding providers doesn't require starting from scratch.
This article covers:
- What vendor agnostic payments mean
- What PSP lock-in actually costs
- How vendor-agnostic architectures are structured
- When the approach pays off
- What to look for in a platform that supports it
TL;DR
- Vendor-agnostic payments means your stack can connect to and switch between providers without re-integrating or losing stored payment credentials.
- PSP lock-in becomes a cost problem at scale: pricing leverage disappears, approval rate gaps widen by corridor, and stored card tokens are locked to the provider.
- Three architecture types exist: orchestration layer, independent vault with multi-PSP routing, and full multi-acquirer build. Each has a different complexity-to-benefit trade-off.
- Single-vendor setups still make sense for early-stage merchants or those in a single market with stable authorization rates – the switch to vendor-agnostic architecture is a scale decision.
- Payment orchestration is the most common path to a PSP-agnostic stack – it adds a routing and vault layer on top of existing providers without a full rebuild.
What does vendor agnostic mean in payments?
Vendor agnostic means your payment infrastructure doesn't depend on any single provider to function. You can route transactions to different acquirers, store card tokens outside of any PSP's vault, and add or remove providers without re-integrating your checkout or losing stored credentials.
In payments, a vendor-agnostic architecture has three components:
➡️Token vault portability – stored card credentials live in a vault you own, not your PSP's. Tokens route to any connected acquirer without re-collection.
➡️Routing control – you set the rules for which provider processes which transaction, by market, card type, BIN range, cost, or risk profile.
➡️Unified API – one integration covers all connected providers. Adding acquirers or new (APMs) is a configuration change, not a new direct integration.
The difference between vendor-agnostic vs. multi-acquirer
Multi-provider means you process through more than one PSP or acquirer.
Vendor-agnostic means no single provider controls your vault, your routing logic, or your path to new markets.
A merchant with Stripe and Adyen connected but tokens stored in Stripe's vault is multi-provider – and still locked in at the credential layer. Adding a second provider doesn't change who owns the data.
The hidden cost of PSP lock-in
Payment vendor lock-in costs money in ways that don't show up in a single line item.
Stored credentials are locked to one provider
When a merchant tokenizes cards through their PSP, those tokens are stored in that PSP's vault. The token format is provider-specific – it can't be imported to another provider without re-tokenization, which requires the cardholder to re-enter their details.
For subscription businesses or any merchant using card-on-file, this creates a hard dependency. Moving to a better-priced or better-performing provider means losing stored payment credentials.
Your authorization rate is capped by one provider's network
A single PSP routes transactions through its own acquirer relationships, negotiated on behalf of all its merchants. Your on a given card brand in a given corridor reflects that provider's network – not the best possible outcome for your volume and risk profile.
At scale, the difference between a 91% and a 94% auth rate on $2M in monthly volume is $60,000 in recovered revenue – to illustrate the math.
A vendor-agnostic payments stack lets you test and replace the underperforming route.
Limited pricing leverage at contract renewal
When tokens are locked and migration would cost months of engineering work plus subscriber re-collection, your provider knows it. Annual pricing negotiations happen with that context on both sides of the table.
Merchants with a credible multi-provider setup negotiate from a different position – they can move volume, and their provider knows that too.
PSP downtime means checkout downtime
PSP outages happen. Most major providers offer 99.9% uptime SLAs – which still allows 8.7 hours of downtime per year. At $3M in monthly volume, that's roughly $4,200 per hour of unavailable , as an illustration of the cost.
A second provider in the routing stack means a failed transaction routes to a backup.
Core insight: PSP lock-in is a compounding cost – stored credential dependency raises switching costs, auth rate gaps narrow margin, and pricing leverage deteriorates as the dependency deepens.
Types of vendor-agnostic payment architectures
Three architecture patterns exist for achieving vendor-agnostic payments. They differ in how they handle routing logic, vault ownership, and provider connectivity.
Payment orchestration layer
The most common approach. A – like Solidgate – sits between the merchant's checkout and multiple providers. The merchant integrates once to the orchestration platform via a single API.
Routing rules, failover logic, vault management, and provider connectivity all run through that layer. Adding a new acquirer or APM means enabling in the platform – not building a new direct integration.
Check out our guide on and how it works.
Tokenization-as-a-service (TaaS)
A standalone independent vault, separate from any acquirer or payment platform. Payment credentials go directly to a neutral vault, which issues tokens that work across any connected processor. The merchant brings their own acquirer relationships and routing logic – the TaaS layer handles only credential storage and token portability.
This architecture solves vault lock-in without requiring a full orchestration platform. It suits merchants who already have routing infrastructure in place and need only to detach stored credentials from a single provider. It doesn't solve routing control or the operational overhead of managing multiple direct acquirer integrations.
Full in-house multi-acquirer build
The merchant holds direct contracts with each acquirer, builds routing and failover logic internally, and maintains each integration independently. across providers requires custom reporting infrastructure. This path gives maximum control and no dependency on an orchestration platform or TaaS vendor.
The operational cost is significant. Each new acquirer requires a separate integration and contract. Routing logic requires ongoing engineering. Reconciliation across providers is a persistent maintenance burden.
This architecture makes commercial sense for merchants with dedicated payments engineering teams and processing volume large enough to justify the overhead.
| Architecture | How it works | Best for | Complexity |
| Payment orchestration layer | Single API to platform; platform handles routing, vault, and provider connectivity | Digital businesses adding multi-acquirer capability without rebuilding checkout | Low – medium |
| Tokenization-as-a-service | Independent vault issues portable tokens; merchant manages routing and acquirer relationships separately | Merchants with existing routing infrastructure who need only vault portability | Medium |
| Full in-house build | Direct acquirer contracts, internal routing logic, custom reconciliation | High-volume merchants with dedicated payments engineering teams | High |
Core insight: All three architectures can achieve processor-agnostic payments. The right choice depends on whether you have existing routing infrastructure and an internal engineering team to maintain direct integrations. And whether vault portability alone solves your lock-in problem or whether routing control is also required.
When does vendor-agnostic actually pay off (and when does single-vendor win)?
Vendor-agnostic architecture adds infrastructure complexity. That complexity is worth it at a certain scale and payment profile – and genuinely isn't worth it before that point.
| Single-vendor wins | Vendor-agnostic pays off |
| Early-stage, below $100k/month | $500k+/month with approval rate gaps by corridor |
| Single market, stable auth rates | Expanding into markets your PSP doesn't cover well |
| No recurring billing dependency | Subscription billing with no cross-provider fallback |
When single-vendor wins
Early-stage merchants processing below $100k per month typically don't have the volume to justify multi-acquirer overhead. A single well-integrated PSP is faster to launch and easier to operate. Authorization rates at that volume are dominated by product and pricing decisions, not acquirer selection.
Merchants in a single market with stable authorization rates, low chargeback exposure, and no recurring billing dependency don't face the constraints that make vendor-agnostic architecture valuable. The orchestration overhead – additional integration, additional vendor management – doesn't pay off without a specific problem to solve.
When vendor-agnostic pays off
Three conditions signal the switch makes commercial sense:
Approval rate differences between providers start costing real money. Different providers have different issuer relationships – the same transaction routed through provider A may be approved at 91%, while provider B approves it at 94%. At $500k+ in monthly volume, that 3-point difference is $15k in recovered revenue per month.
With a single provider, you have no way to test whether a better-performing route exists for your traffic.
You're expanding into markets your current provider doesn't cover well. Cross-border payments carry higher FX costs, lower approval rates, and stronger 3DS friction – because local issuers treat foreign acquirers differently than domestic ones. Selling in Poland means your customers expect BLIK. Selling in the Netherlands means iDEAL.
Local acquiring lifts LTV by an average of 17.9% compared to cross-border processing through a single provider, per Solidgate's merchant data.
A vendor-agnostic stack lets you connect the right provider for each market without a new PSP contract per market. in local currency reduces the FX cost layer further.
You run subscription billing and renewal failures have no fallback. For merchants with card-on-file or , a decline on the only provider is a lost subscriber – there's no second route to retry the charge.
Payment cascades across multiple providers recover an average of 14.8% additional LTV compared to single-provider billing, per Solidgate's merchant data. Smart retry logic across providers adds a further 11.6% LTV improvement.
Cascades and retry logic both require multi-vendor payment orchestration – neither is available in a single-provider setup.
Core insight: A single PSP is the right default for early-stage, single-market businesses. Vendor-agnostic architecture pays off when approval rate gaps, market coverage limits, or subscription renewal failures start costing more.
How payment orchestration enables vendor-agnostic stacks
Payment orchestration is the practical layer that makes vendor-agnostic architecture work at mid-market scale. It handles routing, vault portability, and provider connectivity through a single integration – which is what makes multi-acquirer operation manageable without a dedicated payments engineering team.
Solidgate – one of the – connects merchants to 100+ providers, acquirers and alternative payment methods through one API. It enables vendor-agnostic payments via:
Portable token vault
Solidgate's stores card tokens outside any single provider. Credentials import and export without re-tokenization – when you add a new provider, you don't re-collect card data from subscribers. When you replace an underperforming one, recurring billing continues without interruption.
Solidgate's vault enables via Visa Token Service and Mastercard Digital Enablement Service. Network tokens live at the scheme level – when a card is reissued, the token stays valid without any action from the merchant or cardholder. Expired or replaced cards are handled automatically through Visa and Mastercard credential update services. The result: 27% fewer failed payments.
When one of Zeely's tier-2 acquirers closed, all tokens stayed on Solidgate's side. The entire recurring payment tail transferred to new providers with near-zero subscriber impact.
→See the.
Smart routing across multiple providers
gives merchants control over which provider processes which transaction, based on rules they set and own. The rules run by market, card brand, BIN range, cost, and real-time provider performance.
When a provider underperforms on a specific corridor or card type, routing shifts to a better-performing one automatically. Adding a provider or replacing one doesn't require changes to the checkout.
Solidgate merchants see an average 7% revenue uplift and 10% processing cost reduction from intelligent routing.
MEGOGO's approval rates varied by market as it expanded into Poland – a single routing path couldn't serve every corridor equally, and per-payment transaction costs were eating into subscription unit economics.
Solidgate offered multi-acquirer orchestration, routing transactions to providers with stronger local performance and lower cost per scenario, with BLIK enabled for Polish subscribers. The result: +3.5% payment conversion and €100K in annual cost savings.
→ See the.
Direct acquiring access across markets
Processing cross-border – routing a Polish transaction through a non-Polish acquirer – means higher FX costs, lower approval rates, and missing local payment methods.
Solidgate gives merchants access to across markets through the platform relationship – one onboarding process, not one per country. Local payment methods – BLIK, iDEAL, PayPal – are enabled through the same integration.
For example, Nova Post launched payment acceptance across 15+ markets in 19 months through a single Solidgate integration. Each EU market took an average of two weeks to onboard, vs. the industry-typical several months per country, with 95%+ approval rates from launch.
→ See the.
Unified view across all providers
Managing multiple providers without a unified view means reconciling separate reports, fee structures, and approval rate data per provider. For a business processing across three providers and four markets, that's a persistent operational overhead.
Solidgate's Hub gives merchants a single view of payment performance across all connected providers – without switching between systems or reconciling separate provider reports.
Core insight: A vendor-agnostic stack is only as strong as the infrastructure running it. Portable tokens, merchant-controlled routing, local acquiring access, and unified reporting are what make multi-provider architecture operationally manageable.
What to look for in a vendor-agnostic payment platform
Not all orchestration platforms deliver genuine vendor independence. Before committing, consider the following questions:
1️⃣ Can you export your full token inventory without re-tokenization? If tokens can't leave the platform, you've traded PSP lock-in for orchestrator lock-in. Full import and export without re-tokenization is the baseline.
2️⃣ Does the platform cover the providers and payment methods you need in your specific markets? A narrow connector list means the platform's gaps become your gaps. BLIK in Poland, iDEAL in the Netherlands, PIX in Brazil – these require live acquirer relationships, not roadmap commitments. Ask which connectors are live in the specific markets you're entering.
3️⃣ Can you change routing rules without a development sprint? Routing logic that requires engineering effort to modify puts your operational team in a permanent queue. Rule-based routing configurable without code, real-time performance visibility by provider, and A/B testing across providers should all be available without opening a ticket.
4️⃣ Can you access local acquiring in new markets without a separate KYB and bank contract per market? Each new market with a new acquirer means a full Know Your Business (KYB) process – business verification, compliance documentation, contract negotiation – before a single transaction processes. The platform should provide access to local acquiring infrastructure through its existing acquirer relationships, so the merchant's onboarding covers multiple markets without repeating KYB per country.
5️⃣ Do all providers reconcile from one dashboard? A platform that generates separate reports per provider shifts the reconciliation burden back to the merchant. Settlement data, fees, and approval rates across all connected providers should be visible and reconcilable from one place.
Core insight: A vendor-agnostic platform gives merchants control over their tokens, routing logic, provider mix, and reporting.
Build a vendor-agnostic stack with Solidgate
Vendor-agnostic payments means your auth rates, your stored credentials, and your path to a new market aren't controlled by one provider's performance or terms. For a subscription business, it means renewal failures have a fallback. For a cross-border digital business, it means the next market is a routing and connector decision – not a lengthy PSP onboarding project.
Solidgate's connects merchants to multiple providers and through a single integration, with an independent portable token vault, intelligent routing that adapts per transaction, and acquiring access across markets without separate bank contracts.
If you're evaluating a vendor-agnostic stack for your business, to review your current architecture and identify where the gaps are.
Frequently asked questions
Vendor-neutral payments means no single provider controls the critical components of your stack – your token vault, your logic, or your access to new markets. You can add, replace, or route between providers without rebuilding your checkout or losing stored credentials. Multi-provider alone doesn't guarantee this – vault portability is the key distinction.
Not exactly. Platform agnostic refers to software that runs across different operating environments – it's about technical compatibility, not provider independence. Vendor agnostic in payments means your stack doesn't depend on any single provider for data ownership, routing control, or market access. A merchant using one orchestration platform can still be vendor-agnostic – as long as that platform provides full token portability and merchant-controlled routing.
No. A PSP processes transactions through its own acquiring relationships, with routing logic and token storage tied to that provider. Vendor-agnostic architecture sits above the PSP layer. An orchestration platform connects multiple providers without depending on any one of them. The PSP becomes one connector in the stack, not the stack itself.
Multi-provider means you process through more than one PSP or acquirer. Vendor-agnostic means no single provider controls your vault, routing logic, or path to new markets – even across a multi-provider setup.
It depends on how it's built. A full in-house multi-acquirer build – direct contracts per acquirer, internal routing logic, custom reconciliation – adds significant operational complexity. An orchestration platform – like Solidgate – reduces it. One integration covers all connected providers, routing rules are configurable without code, and reporting reconciles from one dashboard.
Recent articles
