Payments
Payment Orchestration Fundamentals
How to route, retry and reconcile payments across multiple providers without coupling your product to any one of them.
4 chapters · 14 min read · Updated July 19, 2026
What you'll learn
- The anatomy of a rail interface
- Routing strategies and when each applies
- Idempotency and duplicate-safe retries
- Reconciliation across providers
CHAPTER 01
Why Orchestration
Orchestration exists so that provider choice becomes an operational decision instead of an engineering project.
- Providers differ in cost, coverage and reliability.
- Coverage gaps appear as you expand into new markets.
- Outages are certain; the question is how they are absorbed.
CHAPTER 02
The Rail Interface
Every provider should implement the same small contract, with provider-specific behaviour handled at the edge.
- Authorize, capture, reverse, status and webhook handling.
- Normalised error taxonomy across providers.
- Provider quirks contained in adapters, never in business logic.
CHAPTER 03
Routing & Retries
Routing rules belong in configuration so they can be changed, reviewed and rolled back independently of deployments.
- Least-cost, latency-based and coverage-based routing.
- Idempotency keys on every money-moving call.
- Retry budgets and circuit breakers per provider.
CHAPTER 04
Reconciliation
Reconciliation should be continuous and automated, with exceptions surfaced as a queue rather than discovered at month end.
- Match on provider reference and ledger entry.
- Age and assign unmatched items automatically.
- Track reconciliation coverage as an operational metric.