Most payment integrations start the same way. You pick a PSP, follow the docs, get to a working checkout, and ship. It's the default for a reason — the integration is well-documented, the SDK handles the complexity, and payments work.
Now, single-PSP architecture isn't wrong, but it's coupled in ways that only become visible when something breaks, and by then, the cost is already running.
What single-PSP dependency actually looks like in a codebase
When you integrate directly with a single processor, payment logic tends to get distributed across your application. Checkout flows, retry handling, webhook processing, subscription billing: each of these ends up with processor-specific logic baked in.
There's no abstraction layer. Your application talks directly to the PSP. Which means:
- Routing decisions live in application code, not in a dedicated layer
- Adding a second processor isn't a config change, it's a new integration
- Your card vault is owned by the PSP, not by you, and migrating it later is painful
- A processor outage has no programmatic fallback
None of this feels like a problem when you're building it, but it becomes a problem when you're scaling.
The failure modes you don't anticipate
Processor outages with no fallback
A single-PSP architecture has one response to processor downtime:sit and wait. There's no routing layer to detect degradation and shift volume. For a merchant processing at meaningful volume, even a short outage represents significant lost revenue, and there's nothing in the stack to catch it.
Suboptimal cross-border routing
Without a routing layer, every transaction goes to the same processor regardless of where the customer is. International transactions routed through a non-local acquirer carry structurally higher failure rates and cross-border fees. The authorization rate difference between domestic and cross-border routing is measurable: but only recoverable if your architecture supports routing decisions.
Silent card-on-file failures
For subscription businesses, card-on-file transactions fail when credentials become stale: expiration, reissuance, account changes. Without network tokenization (tokens issued by the card networks that auto-update), these failures are silent. The charge just fails. By the time it surfaces as churn, the customer is already gone. Up to 12% of card-on-file transactions fail for exactly this reason.
The fraud filter problem
Every PSP has its own fraud rules. A transaction flagged by one processor might sail through another. When your stack has no routing layer, there's no mechanism to recover from a false decline — the transaction fails, the customer leaves, and you have actually paid an acquisition cost to then lose them.
The cost that doesn't show up in your monitoring
Authorization fees are charged on failed transactions as well as successful ones. Every declined transaction carries a direct processing cost on top of the lost sale. At scale, you're paying to lose customers.
The engineering cost compounds this. Adding a second PSP without an abstraction layer means rebuilding routing logic, webhook handling, reconciliation, and vault management for a new provider. That's months of engineering time: and it has to repeat for every new market or payment method.
PCI DSS scope also tends to expand with every direct integration. Without a centralized vault abstracting card data, each new processor potentially increases your compliance surface.
What an abstraction layer actually buys you
Payment orchestration introduces a layer between your application and your processors. Your integration point is the orchestration layer, not the PSPs directly.
What this changes architecturally:
- Routing logic lives outside application code. Rules can be updated without deploys. New processors can be added without new integrations.
- Vault portability. Credentials are stored once and usable across all connected processors. Retries through a secondary processor don't require re-authentication.
- Programmatic fallback. When a primary processor degrades or goes down, the orchestration layer detects it and reroutes — before the customer sees a failure.
- A single observability surface. Authorization rates, decline reason codes, and cost-per-transaction across all processors in one place, segmented by BIN range, region, and card type.
The architectural shift is from tight coupling to an abstraction layer with defined interfaces. It's the same principle you'd apply anywhere else in a distributed system.
When to think about this
The earlier the better, but the inflection points that tend to force the conversation are:
- Expanding into international markets where local acquiring matters
- Adding subscription billing where card-on-file failure rates compound
- Reaching a transaction volume where authorization rate improvements have measurable revenue impact
- A processor outage that surfaces the single point of failure
By the time most engineering teams are asked to retrofit orchestration, the vault migration alone is a significant project. Building toward an abstraction layer earlier is the lower-cost path.
For the full business case — including the cost of false declines, the vendor comparison, and what to look for when evaluating platforms — the complete guide is here: Why Payment Orchestration Is the Infrastructure Fix Most Merchants Are Overdue For
Top comments (1)
the idempotency angle is worth calling out specifically here. when you add a routing layer that can retry across PSPs, you need idempotency keys to be scoped correctly at the orchestration layer, not just per-processor. if a charge attempt reaches Stripe, times out, and you retry via Adyen, you could end up with the customer charged twice unless the vault abstraction tracks intent state independently. most teams discover this the hard way in production rather than in design.