Payment Orchestration
Payment Orchestration: What It Is and How It Works
Payment orchestration is the layer that decides which processor handles each transaction, retries a decline through a backup, and hands your app back one consistent result. Here is how the routing works, what changes in your PCI DSS scope, and what a working implementation looks like.
Free to start • No credit card required
What Payment Orchestration Actually Means
A payment gateway connects your app to one processor. A payment orchestration platform sits above several gateways and processors and picks the right one per transaction. You integrate once. The orchestration layer routes the charge, retries it through a different processor if the first one declines or times out, and hands your app back a consistent result regardless of which processor ran it.
One Integration, Two Working Parts
Orchestra ships this as a JavaScript library and a REST API that work together. The library captures payment in your checkout, so card data never touches your servers. The API is what your backend calls after capture. Both sit on the same routing and failover layer.
REST API
Drives everything after capture from your backend, platform, or serverless environment: charges on stored tokens, captures, refunds, recurring billing. Orchestra handles routing, failover, and gateway-specific formatting behind one API call.
JavaScript Library
Where payment is captured. Pre-built components handle card entry, Apple Pay, Google Pay, and other payment methods client-side, so cardholder data never touches your servers.
How the Routing Works
Orchestra reports 8-12% higher approval rates on transactions that get a retry, average routing decisions under 50ms, and roughly 15% lower processing cost from routing to the cheapest processor currently up (source: orchestrasolutions.com/payment-routing-optimization/).
What Changes in Your PCI DSS Scope
Card capture runs through Orchestra’s library, so cardholder data never touches your servers. That is what moves the scope, and it holds no matter what your backend does through the API afterward. The difference is large enough to change a build-vs-buy decision on its own.
At Capture: the Library
Card entry, authentication, and processing run client-side in Orchestra’s library, and cardholder data never touches your servers. Orchestra states this moves a merchant from SAQ D (328 requirements) to SAQ A (31 requirements), roughly a 90% cut in what applies to you.
After Capture: the API
Your backend charges stored tokens, issues refunds, and runs recurring billing through the REST API. It never handles card details, so those operations add nothing to your PCI scope.
Source: orchestrasolutions.com/payments-compliance-outsourcing/, orchestrasolutions.com/api-vs-library/.
Explore the Payment Orchestration Library
Nine articles dig into specific pieces of payment orchestration: routing mechanics, PSP integration costs, PCI scope, and 3D Secure.
-
3D Secure Authentication: How 3DS2 Works and When to Use It
3D Secure authentication adds identity verification to online card payments. Regional conversion data shows 3DS helps in some markets and hurts in others. This guide covers the authentication flow, regional impact data, frictionless rate optimization, the multi-PSP consistency problem, and where mandates are heading.
-
The True Cost of PCI Non-Compliance in Multi-PSP Environments
PCI non-compliance costs $5,000-$100,000 per month in fines, with breach costs averaging $10.22 million in the US. For organizations managing multiple PSPs, each integration expands the Cardholder Data Environment and multiplies compliance burden. Payment orchestration through a PCI Level 1 provider can reduce scope by up to 90%.
-
Payment Orchestration After PSP Integration: What to Expect, What to Watch
Learn how payment routing boosts approvals and lowers costs. Explore Orchestra’s API-driven routing to simplify flows and recover lost sales.
-
Encryption vs Tokenization vs Masking: Which Reduces PCI Scope?
Encryption keeps payment data in PCI scope. Masking destroys it. Tokenization removes it while keeping it usable. Here’s which PCI DSS requirements each method satisfies and where each one fits in a payment data flow.
-
Payment Orchestration vs. Payment Processing: Understanding the Differences for Modern Businesses
Payment processing handles transactions. Payment orchestration decides how, where, and through whom they run. Learn how the two layers differ.
-
Why Bad PSP Documentation Costs You Months of Development Time
Traditional PSP integration takes 3–6 months. Learn why, and how payment orchestration architecture lets teams go live in under 2 weeks without the custom dev work.
-
Why PSP Integration Forces You to Rewrite Your Payment Stack
Traditional PSP integration takes 3–6 months. Learn why, and how payment orchestration architecture lets teams go live in under 2 weeks without the custom dev work.
-
3DS2 Hosted Solution: Buy vs. Build for Multi-PSP Stacks
A hosted 3DS2 solution means a third party runs the 3DS Server that initiates authentication requests, not the ACS and not your vault. Here’s what that boundary means for a team routing across multiple PSPs, and the integration path to get there.
-
SCA vs 3DS2: What PSD2 Actually Requires You to Build
SCA is the PSD2 mandate; 3DS2 is the protocol that satisfies it. Here’s the exact exemption math, what a compliant integration has to send, and what PSD3 changes.
See What Orchestration Looks Like on Your Stack
Run a transaction through Orchestra’s sandbox, or talk to us about your current processor setup.
Free to start • No credit card required