While payment orchestration provides redundancy, flexibility, and failover capabilities, many mid-sized retailers or startups initially integrate with a single payment gatewayGateway gateway A service that authorizes and processes card payments for online merchants. Examples include Stripe, Adyen, and PayPal. connected to a single acquiring bank for simplicity, speed of integration, or cost minimization.
However, this architecture introduces several risks and limitations in case of transaction errors.
🔂 Typical Flow in a Single-Gateway, Single-AcquirerAcquirer acquirer A financial institution or payment processor that manages the merchant account, enabling businesses to accept card payments. Acquirers receive all transactions from the merchant and route them to the appropriate issuing bank. Setup
mermaidCopyEditsequenceDiagram
User ->> Website: Initiates checkout
Website ->> Payment Gateway: Send transaction
Payment Gateway ->> Acquirer: Forward transaction
Acquirer ->> Issuer: Request authorization
Issuer -->> Acquirer: Respond (approve/decline)
Acquirer -->> Payment Gateway: Relay response
Payment Gateway -->> Website: Show success/failure
🚨 What Happens When a Transaction Fails?
1. Gateway-Level Failures
- Types: API timeout, gateway unavailability, DNS errors, TLS handshake failure.
- Effect: Transaction never reaches acquirer or issuerIssuer issuer A bank or financial institution that issues payment cards to consumers. Responsible for authorizations and chargebacks..
- Impact: Hard fail with no fallback.
- Customer Experience: Generic error message like “Something went wrong, please try again.”
2. Acquirer-Level Failures
- Types: Processing timeout, internal system errors, misconfigured routing.
- Effect: Transaction may get dropped or delayed.
- Impact: Increased soft declines or unexplained failures.
- Customer Experience: Delays or failed payments without recourse.
3. Issuer Declines
- Types: Hard or soft declines from customer’s issuing bank.
- Effect: Gateway relays decline to merchantMerchant merchant An individual or business that accepts payments in exchange for goods or services., but has no logic to retry with alternatives.
- Impact: Conversions drop even if another acquirer could have succeeded.
- Customer Experience: Repeated card declines → cart abandonment.
4. AuthenticationAuthentication authentication A security process used to verify the identity of the user or cardholder. May involve passwords, biometrics, OTPs (one-time passwords), or 3-D Secure. Failures
- Types: 3DS timeout, ACS unavailable, failure in risk scoring.
- Effect: Payment authentication fails; no fallback path.
- Impact: Lost revenue in SCA markets.
- Customer Experience: Frustrating checkout loops.
❌ Limitations of a Single Gateway Setup
| Area | Limitation |
|---|---|
| Redundancy | No backup if gateway or acquirer goes down |
| Success Rate Optimization | No option to retry on alternate acquirer with better BIN/issuer performance |
| Cost Optimization | Unable to route high-cost transactionsTransactions transactions Interactions where value is exchanged for goods or services. to cheaper PSPs |
| Region/Method Expansion | Limited to what the gateway/acquirer supports |
| Resilience & Risk Control | Entire transaction funnel depends on one provider’s uptime and rules |
🛠️ What Can Be Done in a Single-PSP Setup?
Even in a single gateway/acquirer setup, some mitigation strategies can be applied:
| Strategy | Description |
|---|---|
| Frontend Retry Prompt | Allow customers to re-submit the same payment method if timeout/unknown error |
| Alternate Payment Methods | Offer walletsWallets wallets See Digital Wallets., pay-later, bank transfer as fallbacks (within the same gateway) |
| Retry After Delay | Soft declines can be retried once after a delay or session refresh |
| Customer Messaging | Provide contextual error messages (e.g., “Try another card or method”) |
| Analytics on Declines | Use decline codes and response analysis to spot systematic issues |
🧠 Why Mature Retailers Move to Orchestration
Retailers with growing volume or global ambitions often migrate to multi-gateway and multi-acquirer orchestration models to address:
- Uptime assurance (PSP redundancy)
- Conversion optimization (route by BIN/region/method)
- Cost control (optimize MDRs across PSPs)
- Payment method diversity (local methods, wallets, A2A)
- Compliance scalability (3DS, PCI, tokenization routing)
🧭 Summary Comparison: Single PSP vs. Orchestration
| Feature | Single Gateway/Acquirer | Payment Orchestration |
|---|---|---|
| Uptime Redundancy | ❌ None | ✅ Multi-PSP, multi-path routing |
| Retry Logic | ❌ Basic frontend retry | ✅ Smart retry engine with exponential backoff |
| BIN/Issuer Routing | ❌ Fixed PSP path | ✅ Dynamic routing based on BIN/region |
| Error Recovery | ❌ Limited, manual fallback | ✅ Automated failover to alternate PSP/acquirer |
| 3DS Management | ❌ Rely on single provider logic | ✅ Multiple authenticators, fallback options |
| Cost Optimization | ❌ Fixed pricing | ✅ Route based on fees, FX, and MDRs |
| Scale & Flexibility | ❌ Constrained | ✅ Designed for growth and localization |
Below is a side-by-side simulation of customer experience flows during payment, comparing:
- Single Gateway & Acquirer Setup (basic integration)
- Payment Orchestration Setup (multi-PSP, multi-rail with smart logic)
We’ll go through 3 typical scenarios:
- A. Normal Success
- B. Gateway/Acquirer Failure
- C. Soft Decline (issuer unavailable)
Each flow shows the customer’s journey, backend handling, and final experience.
🧭 Scenario A: Normal Payment Success
| Step | Single Gateway & Acquirer | Payment Orchestration Setup |
|---|---|---|
| 1 | Customer enters card details | Customer enters card details |
| 2 | Gateway routes to acquirer → issuer approves | POL routes to most optimal PSP based on BIN/currency |
| 3 | Transaction approved | Transaction approved |
| ✅ | Payment successful message shown instantly | Payment successful message shown instantly |
✅ Customer Experience: Identical in both — seamless and quick.
🔴 Scenario B: PSP/API Timeout or Acquirer Down
| Step | Single Gateway & Acquirer | Payment Orchestration Setup |
|---|---|---|
| 1 | Customer submits card details | Customer submits card details |
| 2 | Gateway API call times out (no response) | Primary PSP API call fails → retry logic kicks in |
| 3 | Retry attempt fails too → transaction fails | POL retries using exponential backoff + delay |
| 4 | Error message shown: “Something went wrong” | POL auto-routes to backup PSP/acquirer → issuer approves |
| ❌ | Customer must re-enter details or abandon cart | ✅ Payment successful — no change in customer interaction |
🧠 Insight: Orchestration hides backend failure from the customer.
🚨 Risk in single PSP model: Abandoned cart, loss of revenue.
🟡 Scenario C: Soft Decline from Issuer (e.g., ‘Do Not Honor’)
| Step | Single Gateway & Acquirer | Payment Orchestration Setup |
|---|---|---|
| 1 | Customer enters valid card | Customer enters valid card |
| 2 | Transaction reaches issuer → Soft decline (do_not_honor) | POL classifies decline as retryable |
| 3 | Gateway shows “Payment declinedDeclined declined A transaction that is not approved by the issuer. Reasons may include insufficient funds, suspected fraud, or incorrect card details.. Try again.” | POL retries same transaction with slight delay |
| 4 | Retry again fails → Customer asked to choose other method | Retry is routed via alternate PSP/acquirer → issuer approves |
| ❌ | Friction → customer hesitates or leaves | ✅ Payment successful without visible retry |
📉 Single PSP: Results in user frustration or drop-off.
🧠 Orchestration: Converts with retry or alternate path — preserves experience.
🎥 Visual Comparison (Text-Based Flow Simulation)
🔸 Single Gateway & Acquirer
plaintextCopyEdit[User Enters Card Info]
↓
[Payment Gateway]
↓
[Acquirer]
↓
[Issuer Decline OR Gateway Timeout]
↓
[FAILURE] → "Sorry, something went wrong"
↓
[Customer retries manually OR abandons]
🔹 Payment Orchestration
plaintextCopyEdit[User Enters Card Info]
↓
[Orchestration Engine: Route to Optimal PSP]
↓
[PSP Timeout or Soft Decline Detected]
↓
[Retry Logic Triggered → Retry Same PSP or Switch PSP]
↓
[Success OR Seamless Failover]
↓
[Payment Success Message to Customer]
🧠 Key Takeaway
| Dimension | Single Gateway | Payment Orchestration |
|---|---|---|
| Resilience | ❌ None | ✅ Full retry/failover logic |
| Conversion Optimization | ❌ Limited | ✅ Dynamic routing for issuer/region success |
| Customer Experience | ❌ Exposed to backend failure | ✅ Seamless — failures masked behind logic |
| Scalability | ❌ Requires manual reintegration | ✅ Easy PSP addition, global scaling |
| Risk Management | ❌ One path only | ✅ Rules, thresholds, velocity checks |
Vibhu Arya is a fintechFintech fintech
Short for financial technology, refers to tech-enabled innovation in financial services. and payments expert with 15+ years of experience simplifying how money moves across digital and retail ecosystems. He’s led strategy and partnerships at Citibank, Adyen, and IKEA, and helped scale fintech startups (Snapdeal, iPaylinks) to $1B+ valuations. Vibhu’s expertise spans cards, crypto, cross-border, and real-time payments. He is the founder of PaymentsPedia.com, where he writes about the future of payments.
📧 vibhu@paymentspedia.com | LinkedIn