Payment Orchestration

Every extra provider you integrate directly is another API, another webhook format, another set of error codes to maintain. An orchestration layer collapses all of that into one connection: your store integrates once — through a free plugin or the API — and every provider behind the layer becomes available without another line of code. If the concept is new to you, start with our plain-English explainer, what payment orchestration is; this page is about what the layer actually does with each payment.

A single-provider checkout has no decisions to make — and that is exactly its weakness. The provider that converts best for domestic cards is rarely the one that supports the wallet your international customers expect, and neither may settle in the currency you want to hold. Routing turns that from a rebuild into a rule: one currency to one provider, another market to another, and the rest to your default.

Because the rules live in your dashboard rather than in checkout code, adding a market means activating a provider, not scheduling a development project. It is also the structural fix for the checkout error that quietly kills international sales — "payment method not available for your currency" — because the layer simply routes that customer to a provider that does accept it.

Every provider has bad days. With one integration, their downtime is your downtime: every sale fails until they recover, and you usually learn it from customers. With orchestration, a technical failure — a timeout, a server error, a gateway outage — is retried through another active provider while the customer is still on the page.

The discipline is in what not to retry. A hard decline like insufficient funds is a bank's answer, not a technical fault; re-running it through another provider cannot succeed. The layer classifies each failure before deciding, a distinction we unpack in why payments fail and in our guide to payment gateway downtime and failover.

Two verification habits separate a robust payment system from a lucky one. First, no order is marked paid because a browser was redirected to a success page — that redirect is attacker-controllable, and trusting it is how stores end up shipping unpaid orders or holding paid ones. The payment is real when your server confirms it with the provider. Second, every webhook signature is verified — each provider signs callbacks differently, and the layer implements each scheme once, centrally, instead of leaving it to whoever wired up that provider.

Card data follows the same principle of never trusting the edges: with hosted checkout, card details are entered on a hosted payment page and never touch your server, which is what keeps a store on the short SAQ A path rather than a full audit — how PCI scope actually works, and our trust center covers the rest of the security posture.

Five providers means five settlement reports, five formats, five definitions of a refund. Orchestration normalises all of it into a single ledger, so "what did we take yesterday" is one query rather than a spreadsheet merge — and the numbers finally match across store, providers and bank.

One country, one currency, one provider you are happy with, and no concrete plan to change any of it: keep the direct integration. Orchestration earns its place at the second provider, the second market, or the first outage that cost real money — the honest test is in our orchestration explainer. PaymentHood adds no per-transaction fee either way, so the question is only architectural, never a margin trade.