Payment orchestration: integrate once, run it yourself

Payment orchestration: integrate once, run it without developers

Payment orchestration is a layer that connects one merchant integration to many payment service providers. With Omno you integrate once, and after that your payments team owns everything from the dashboard: adding or switching providers, building routing rules, managing every brand and user, and seeing every transaction. Your developers build your business, not payment plumbing.

Updated 29 October 2026

In 30 seconds

After one integration, providers, routing rules and the checkout are changed in the dashboard, not in code.

Every brand, user and transaction is managed from one place.

Orchestration helps most across several countries or providers; with one market and stable approvals, a direct gateway may be simpler.

What it does

Add or switch providers

Connect a new provider or turn one off in the dashboard without touching your code. Each provider connection lives inside Omno.

Routing in your hands

Build and change routing rules in the dashboard as your traffic shifts, with no deploy.

Engineers stay on product

Your developers integrate one API once, then build your business instead of payment plumbing.

Multi-brand control

Manage all brands, users and transactions from one place, each brand with its own providers, rules and checkout under role-based access control.

Two ways to integrate

The hosted checkout with a no-code builder, or your own checkout with Card Fields for cards and Direct Links for local methods and wallets.

One API in both directions

Payments and payouts use the same authentication, transaction model and webhook format, whichever provider processes them.

How does payment orchestration work?

A merchant integrates once with Omno. From then on, every payment request goes to the same API, and Omno decides which payment service provider should handle it. The decision happens in two steps. First, eligibility rules remove every provider that cannot or should not take this payment: the wrong country, a method the provider does not support, a customer group the provider is not allowed to serve, or a customer verification level the provider does not accept. Second, routing chooses one provider from the providers that are left.

The selected PSP processes the payment. If it is unavailable or rejects the request, cascading sends the same payment to the next provider in your rule, until one accepts, so the customer does not have to type their details again. When the transaction reaches a final state, Omno sends a webhook to your backend. That webhook, or a call to Get Transaction Info, is the source of truth for the outcome. Redirects back to your site only tell the browser where to go next.

The same model applies to money going out. A payout request enters through the same API, is matched to eligible providers, and reports its outcome by webhook in the same format as a payment.

What does Omno connect behind the API?

Behind the single integration sit card acquirers, local payment method providers, wallets and crypto processors. The exact set depends on your markets and is configured per merchant account. Omno publishes the number of connected providers and methods in the facts on this page rather than in prose, so the figures stay current.

You choose how customers reach those providers:

Hosted checkout. One checkout page in your brand for cards, Apple Pay, Google Pay, local methods and crypto. Your backend creates a session, and your frontend opens it with the Web SDK. This is the recommended flow for new integrations.
Card Fields. Your own checkout for cards, with three secure Omno card fields embedded in your page and styled to match. Card data never touches your servers, and every payment runs through Omno’s card routing.
Direct Links. Your own buttons for local methods, wallets and crypto. Behind each button, Omno routes the payment across several providers of that method, and the shopper approves it in the method’s own page or app.
iFrame. The checkout embedded inside your own page for teams that want the hosted flow without a full redirect.

Around those flows, the platform adds the pieces finance and operations teams need: a full transaction trail for every payment, customer profiles, reports and widget analytics, fraud scoring and customer rules, saved cards and accounts, and multi-brand management with role-based access control.

What does your team run without developers?

The integration is a one-time project. After it, the payments team owns the day-to-day work in the dashboard. They connect a new provider or turn one off, build and change routing rules as traffic shifts, adjust the checkout in the builder, and manage every brand, user and transaction from one place. None of this needs a code change or a release, so your engineers stay on your product.

What changes versus a single PSP?

With one provider, every decline is final, every outage is your outage, and every new market is a new contract plus a new integration. Your approval rate is whatever that provider’s acquiring banks and risk models give you, and you have no second opinion.

With orchestration, several things change at once:

Declines become recoverable. A payment one PSP rejects can move to another whose acquiring bank or risk policy is different.
Outages stop being total. When a provider times out or fails, traffic moves to the next eligible route.
New markets become configuration. Adding a local method in a new country means enabling a provider that already exists inside Omno, not opening a new engineering project.
Data becomes comparable. Approval rates, decline reasons and processing times for every provider sit in one dashboard with the same definitions, so you can see which route works best for which country, method and customer segment.
Negotiation improves. When volume can move between providers, pricing and service conversations change.

What does not change is your responsibility for compliance in each market. Orchestration routes payments; it does not license you to operate where you are not licensed.

When is orchestration worth the extra layer?

Orchestration pays for itself when at least one of these is true: you process in more than one country, you rely on local payment methods that a single provider does not cover, a meaningful share of your declines are soft declines that another acquirer might approve, or a provider outage would stop your revenue. E-commerce merchants selling across borders usually meet the first two, and merchants in regulated and high-risk sectors often meet all four.

It is less useful for a merchant with one market, one card acquirer and stable approval rates. In that case the gain from routing is small and a direct gateway may be simpler. If you are unsure, start from the integration guide in the docs and compare your current decline reasons with the providers available in your markets.

{ "event": "payin.status_changed", "transaction_id": "tx_7c1e09a4", "merchant_reference": "order-48213", "status": "SUCCESS", "psp": "psp_b", "attempts": 2, "amount": 120.00, "currency": "EUR", "method": "card", "created_at": "2026-10-13T09:41:07Z" }

Settings you control

Routers

Define which PSPs a router can use and in what order. Pass a routerId on a request to pin a transaction to a specific router.

Eligibility rules

Restrict each PSP by country, payment method, customer group and verification level so customers only see providers that can accept them.

Cascade order

The order of providers in each routing rule is the order a payment moves through them until one accepts.

Webhook endpoints

Set where final transaction statuses are delivered for each merchant account.

Frequently asked questions

What is the difference between payment orchestration and a payment gateway?

A payment gateway connects you to one processor or acquirer. An orchestration platform sits above several gateways and PSPs, decides which one handles each transaction, moves a declined payment to the next provider in the rule and gives you one reporting and webhook layer across all of them.

Does Omno replace my existing PSP contracts?

No. Omno is the technology layer. Acquiring and payouts are performed by licensed partner PSPs, and you can keep the providers you already work with while adding new ones through the same API. Each provider runs its own onboarding for your business. Omno can help you choose providers and prepare, but the approval is the provider's.

Which integration flow should a new merchant choose?

Omno recommends the hosted checkout for new integrations. It takes cards, Apple Pay, Google Pay, local methods and crypto, and your team shapes it with the no-code builder. Teams that build their own checkout use Card Fields for cards and Direct Links for local methods, wallets and crypto. The legacy Payment Page is not offered to new merchants.

Do we need developers after the integration?

Not for day-to-day changes. Adding or switching providers, editing routing rules, changing the checkout and managing brands and users all happen in the dashboard.

How do I know the final status of a payment?

From the webhook Omno sends to your backend, or by calling Get Transaction Info. Browser redirects and client-side events are useful for the user interface but are not authoritative.