What it means
An online retailer sells in several countries and uses two card processors. Its checkout sends a payment to one provider, receives an authorisation result, and may try another route when a defined failure permits it.
Payment orchestration manages that sequence without making the buyer understand the underlying providers. Map the checkout flow first: the customer chooses a method, enters details and expects one clear confirmation, while behind the scenes payment authorisation, capture, settlement and refunds may pass through different systems at different times.
Routing rules can use card country, currency, amount or processor availability, and Stripe's orchestration documentation describes selecting a processor by rules and testing those rules before activation, although supported destinations and features depend on the provider and integration. Adyen's payment-orchestration overview frames the subject around connecting payment methods, providers and back-end operations, and since vendor products differ, the term describes a capability rather than one standard software package.
A payment should have an idempotent reference so a timeout or retry does not create a duplicate charge, and the previous attempt's state should be confirmed before another request is sent, because a technical failure message does not necessarily mean no funds were authorised. Cross-processor retries need guardrails, since a genuine issuer decline or authentication requirement may not be cured by another processor and indiscriminate retries can increase fees, fraud signals and customer confusion.
Separate authorisation from capture as well, because an authorised card transaction can later be captured, voided or expire. Support local payment methods where the business has legitimate demand, since a bank transfer, wallet or card may have different settlement and refund paths, and do not add options just because a gateway lists them but assess conversion, costs and operational support.
Keep an event trail for each attempt covering route, processor reference, amount, currency, status and timestamp, and reconcile these records with settlement reports and the order ledger so that one checkout may generate several attempts but produces only the intended customer charge. Plan for failures too: if the preferred processor is unavailable the fallback must meet the same security, currency and authentication requirements, and outages and partial responses should be tested, not only happy-path test cards.
Fraud controls and strong customer authentication can vary by route, so the orchestration layer should preserve the required signals rather than treat a second processor as a bypass, and rules must respect local regulation and the provider's supported flow. Measure success with a carefully defined denominator, because approved authorisations divided by eligible payment attempts may differ from successful paid orders divided by checkout starts, which also reflects abandoned carts and non-payment issues.
An illustrative authorisation rate is 9,300 approved attempts from 10,000 eligible attempts, or 93%, and if one customer made several attempts that figure is not the share of customers who paid. Compare provider costs beyond the headline processing rate, since cross-border fees, currency conversion, chargebacks, refunds and operational work can change the result and better authorisation at a higher cost may or may not increase contribution margin.
Token portability is a practical constraint, because a credential stored by one provider may not be usable by another and Stripe's documentation names specific exceptions, and payment data should be protected through approved tokenisation and security flows with limited access to transaction records and no card details in ordinary business systems. Give support teams a unified view of what happened and trace refunds to the successful charge and proper rail, remembering that for owners orchestration is useful when payment complexity is real enough to justify it, so start with the failure modes and business objectives, test routing safely and monitor the combined payment ledger, since more providers alone do not make checkout reliable.
In practice
Real-world examples.
Example
A UK-issued card is routed to the configured processor for that card country. The routing rule was tested before activation. The order record shows which route handled the payment.
Example
A gateway outage triggers a tested fallback rather than a duplicate order charge. The unique payment reference lets the system confirm that the first attempt did not authorise before trying the second route. The customer sees one charge.
Example
The payments team reconciles several attempts to one successful customer order. Failed attempts and the successful one share the same order reference. Finance posts only the successful charge as revenue.
Formula
Calculation
Authorisation rate = approved payment attempts / eligible attempts x 100. A customer-level success rate = customers who eventually paid / customers who attempted x 100.
Worked example. Processor A receives 6,000 eligible attempts and approves 5,520, a rate of 5,520 / 6,000 x 100 = 92%. Processor B receives 4,000 eligible attempts and approves 3,780, a rate of 3,780 / 4,000 x 100 = 94.5%. Combined, 5,520 + 3,780 = 9,300 approvals from 10,000 attempts gives 93%.
That 93% counts attempts, not customers. If the 10,000 attempts came from 8,500 customers and 7,650 of them eventually paid, the customer-level success rate is 7,650 / 8,500 x 100 = 90%. The two figures answer different questions, which is why the denominator must be stated before comparing providers.Case study
Seen in the real world.
This entirely fictional example follows Mesa Market, an invented online retailer. Its primary processor timed out during a promotion, and staff initially could not tell which orders had authorised. The team added unique payment references and reconciled every attempt before testing fallback routing. The exercise reduced ambiguity in later incidents; it does not imply that every failed payment should be retried.
During the incident, 400 orders showed an unclear status. After reconciling processor records, the team found 310 had authorised, 70 had failed cleanly and 20 had been attempted twice, and it released the duplicate holds. It now treats the event trail as a requirement before adding any second processor.
Watch out
Common mistakes.
- Retrying a payment before verifying whether the first attempt authorized.
- Treating a second processor as a way around an issuer decline or authentication.
- Comparing provider approval rates without matching transaction mix and costs.
Questions
People also ask.
What is payment orchestration?
Coordinating payment routes, methods, responses and records across providers.
Does it require multiple processors?
Not always; the need depends on the methods and operations being coordinated.
Will it fix every failed payment?
No. Issuer decisions, authentication, fraud and integration limits still apply.
From the founder's library
Take it further with the book.
Build your financial confidence beyond this definition. Shihan's full-length guide, Accounting Fundamentals, takes the same plain-English approach and turns it into a complete, practical playbook for non-finance managers, business owners and students - with chapter-end quiz answers and presentation slides included.
25% off with code MMHQ25, applied at checkout. Priced in USD - checkout may show the equivalent in your local currency.
View the book and save 25%Related