The two most common paths to accepting payments solve different problems and create different constraints. Direct PSP integration gives you a tight, vendor-specific connection. A third-party gateway puts an abstraction layer between your application and one or more processors. Picking the wrong one costs sprint capacity, compliance overhead, or both.
Here is the comparison by the numbers.
Direct PSP integration: what it actually means
A direct PSP integration connects your application straight to a payment processor’s API. Your engineering team writes against Stripe’s API, or Adyen’s, or Braintree’s, handling their authentication scheme, error codes, webhook formats, and testing environment. The processor routes transactions directly from your system.
You own the full request path: payment data flows from your front end, through your servers, to the processor. That control comes with obligation. Your team maintains the integration, absorbs breaking API changes, and takes on the PCI compliance scope that comes with handling payment data directly.
The model works well when you have one processor and no near-term plans for a second. It gets expensive when that changes.
Third-party payment gateways: where they fit
A third-party gateway sits between your application and one or more payment processors. Instead of calling Stripe directly, you call the gateway, which translates your request and routes it onward. Chase Orbital, Authorize.Net, and similar providers operate this way.
Gateways reduce initial integration effort:
- A shared interface across processors
- Pre-built UI components for card entry
- Partial handling of PCI compliance scope
The trade-off: the gateway owns the processor relationship. You accept:
- Their routing logic
- Their pricing
- Their contract terms
To add a second processor later, you can only add processors the gateway supports, at whatever pricing the gateway negotiates on your behalf.
Payment orchestration is distinct from both. A gateway typically connects to a single processor it owns or resells. An orchestration platform connects to many independent processors through one integration, leaving routing decisions and processor contracts in your hands.
Integration time and engineering cost, compared
| Direct integration | Third-party gateway | |
|---|---|---|
| Initial timeline | 4–12 weeks per market | 2–6 weeks |
| Engineering cost | £10,000–£16,000 per integration | $8,000–$30,000 |
| Adding a second processor | Full integration cost repeats | Restart if gateway doesn’t support the new PSP |
A direct integration with a major processor ships in 4-12 weeks per market, including error handling, webhook reconciliation, and testing. For markets requiring separate acquiring relationships, add 2-6 months to establish the banking integration (SPD Technology, “Typical Timeline to Implement a Fintech Payment Integration,” 2026).
Third-party gateway integrations run 2-6 weeks and $8,000-$30,000 in engineering cost (SPD Technology, 2026). That is faster, but the cost structure repeats differently: once you need a second gateway or a processor the first gateway does not support, you start over.
The subtler number is ongoing maintenance. At a market rate of £500-800/day for a payments engineer, a four-week direct integration costs £10,000-£16,000 before a single transaction processes (Basis Theory, “The Costs of Payment Service Provider Lock-In”). That investment repeats for each additional processor, and software maintenance typically runs 15-20% of initial build cost per year.
For teams evaluating what adding each new PSP actually costs in practice, the full breakdown is here. If you want a direct timeline comparison between a direct integration and an Orchestra integration, PSP integration under two weeks covers the mechanics.
PCI scope: who carries the compliance burden
PCI DSS scope depends on how card data flows, not on who processes it.
Tier When it applies Requirements under PCI DSS v4.0 SAQ D Your server receives and transmits raw cardholder data 328 SAQ A Card data never touches your servers; provider handles collection and your server receives only a token 31
Both gateways and orchestration platforms can reduce scope to SAQ A when they handle card collection client-side. The mechanism: the payment UI sends card data directly to the provider, and your server receives only a token.
Where the gateway model creates a constraint: tokenization is usually bound to the gateway’s processor. If you later want to route through a different processor, your tokens may not transfer. You could be forced to re-collect card data from cardholders, which involves re-engagement campaigns, support overhead, and measurable conversion loss.
Orchestra’s compliance outsourcing model keeps SAQ A scope in place even as you add or swap processors, because the token vault is not bound to any single processor.
Reliability and failover: single point vs. redundant paths
Key figures from the BR-DGE 2025 Merchant Survey:
- 92% of enterprise e-commerce merchants experienced a payment outage or disruption in the past two years, with half reporting losses of £1.1M–£10M per incident
- 71% of enterprise merchants still route most transaction volume through a single primary provider
- Only 32% have automated failover to a backup processor; 68% are re-routing manually during an incident
A direct integration with a single processor gives you one path. When that processor has an outage, payment flow stops until you manually intervene or the outage clears. $44.4 billion in annual US retail and hospitality sales is at risk from payment outages; the average incident lasts two hours, and consumers abandon purchases after roughly seven minutes of payment trouble (FreedomPay, “Payment Resilience in an Uncertain World,” January 2026).
Third-party gateways add some protection by abstracting the processor relationship, but the protection only extends as far as the gateway can route. If the gateway itself is unavailable, you are down regardless.
For teams managing volume across multiple processors, multiple payment gateways covers authorization-rate recovery in more detail. The failure-mode taxonomy for gateway architecture lives at the payment gateway failover service page.
Vendor lock-in and the cost of switching later
Lock-in in the direct integration model is technical: your code is written against a specific processor’s API. Switching requires a rewrite.
Gateway lock-in works differently. Your code is written against the gateway, and the gateway owns:
- Your processor relationships
- Pricing terms
- Your token vault
Of merchants using tokenization, only 12% have a fully interoperable, independent vault, meaning 88% of merchants with tokenized cards have data bound to a specific processor (BR-DGE 2025 Merchant Survey).
If your tokenized card data lives in a processor-bound vault and you want to move to a different processor, you cannot simply point your integration at the new one. You need to re-collect card data from cardholders. That cost does not appear on the integration time estimate; it appears later, when the business wants to switch processors and the engineering team explains why it is a multi-month project.
When direct integration still makes sense
Direct integration is the right call when you have one processor, no near-term plans for a second, and the transaction volume does not justify the operational cost of an outage. The engineering investment is bounded, the architecture is simpler, and you are not adding a dependency in the critical payment path.
The calculus changes when the business wants international expansion, new payment methods your current processor does not support, or any level of redundancy. At that point, direct integration stops being the simple option and becomes the architecture you will need to work around.
The payment infrastructure global expansion case goes through this in detail: the processor coverage assumptions that hold in one market often do not hold across three or four.
How Orchestra changes the calculus
Orchestra connects to 120+ payment providers through two integration paths.
| API path | JavaScript library | |
|---|---|---|
| Environment | Backend or serverless | Browser (client-side) |
| Card collection | Your team owns UI and card-collection flow | Library handles card entry, Apple Pay, Google Pay |
| PCI scope | SAQ D (328 requirements) | SAQ A (31 requirements) |
| Cardholder data on your servers | Yes | Never |
Both paths support the same routing and failover features. When a processor goes down, Orchestra routes to a backup automatically. When you want to add a new processor, it is a configuration change, not a new integration project. New payment provider connections are added at no additional cost.
Orchestra does not require ripping out an existing direct integration. The Library or API can sit alongside a working direct connection, routing new PSPs or payment methods through Orchestra while the existing connection keeps processing. Migration does not require a rewrite.
Frequently asked questions
What’s the difference between a payment gateway and direct PSP integration?
Direct PSP integration means your team writes code against a specific processor’s API, handling its authentication, error formats, and webhooks. A third-party gateway sits between your app and one or more processors, providing a shared interface but locking you into that vendor’s contract terms and feature set.
Is a third-party payment gateway the same as payment orchestration?
No. A gateway typically routes to a single processor it owns or resells. An orchestration platform connects to many independent PSPs through one integration, so you keep processor choice and can route or fail over between them.
Which approach reduces PCI compliance scope more?
Both can reduce scope if card data never touches your servers. The difference is control: a single-processor gateway ties your compliance posture to one vendor’s tokenization, while an orchestration layer keeps a consistent PCI scope as you add or swap processors.
How much engineering time does direct PSP integration take?
Teams typically report 4-12 weeks per processor for a production-ready direct integration, including error handling, webhook reconciliation, and testing (SPD Technology, 2026). That cost repeats for every additional PSP added later.
Does adding a payment gateway or orchestration layer add latency?
Both add a network hop. The relevant question is what you get for it: a gateway adds a hop to reach one processor, while an orchestration layer adds a hop that buys routing and failover across several. Evaluate the added latency against the cost of a processor outage with no fallback.
When should a team skip both and integrate a PSP directly?
When the business runs on a single processor with no near-term plans for a second provider, new markets, or redundancy, and the volume does not justify the operational cost of an outage. Direct integration is simpler until that changes.
Can we adopt an orchestration layer without ripping out an existing direct integration?
Yes. Orchestra sits alongside a working direct integration. Route new PSPs or payment methods through Orchestra while the existing connection keeps processing. Migration does not require a rewrite.