What a payment orchestration layer actually provides
An orchestration layer's job, by definition, is narrow: it connects many payment providers through one API so an operator doesn't have to integrate each acquirer separately. That solves one real problem — talking to multiple providers through a single interface — but it stops there. The layer itself is not a merchant panel, not a back office, and not an accounting system.
What the operator still has to build
Everything a merchant or an operations team actually touches day to day sits outside that API: a branded merchant panel where merchants log in and see their own transactions and balances, a back office for managers to onboard merchants and resolve issues, and an accounting layer that turns raw provider calls into books that close. With a bare orchestration layer, all of that is the operator's own build — and it has to be built and maintained in parallel with the orchestration integration itself.
Where this ground is already covered in omwio's Core
Core is the part of omwio that is present in every billing plan and cannot be switched off, because it is what makes a payment platform usable at all. It already includes the pieces an orchestration layer leaves out:
- Merchants onboarded with their own tariffs, commissions, assigned methods and per-merchant overrides
- Payments, payouts, exchanges, refunds and chargebacks modeled as one transaction type with a shared, collapsed status that merchants actually see
- Multi-currency wallets per merchant with balance history and reserve visibility
- Providers attached as modules, MIDs registered against them, and route resolution that can be previewed for a given merchant and method before traffic reaches it
- A branded hosted checkout page and a signed Processing API, with provider quirks normalised before they reach anyone integrating
- Invoicing with branded mail in the recipient's language, and an encrypted, tenant-scoped customer directory with blind-index search
- Refunds, chargeback handling and a structured dispute workflow, including merchant-raised disputes with evidence files, resolved by the manager with balances rolled back and re-posted automatically
- Conversion and provider analytics ranked by merchant, provider and MID, with merchants getting their own dashboard limited to their own data
- Currency pairs with rate sources and locks, merchant-to-merchant exchanges, and server-enforced rounding
- RBAC down to individual panel actions, tenant-scoped two-factor authentication, session controls and a recorded audit trail
A tenant running only Core can already onboard merchants, take payments, pay out, invoice, exchange currency and resolve disputes — the parts that an orchestration layer leaves as someone else's project.
Modules that extend the same base
Beyond Core, the same platform offers optional modules rather than separate systems to integrate. Support inbox lets merchants open tickets directly from the transaction, invoice or wallet in question, so the reference travels with the conversation and managers work the queue inside their own panel under the same RBAC. Support inbox AI adds triage and drafted replies on top, grounded in the tenant's own data, with a human always pressing send. Monitoring tracks success rates, latency and error mix per provider and per MID, with route-aware alerts that point at which route to fail over rather than just signaling that something is wrong. Accounting & reconciliation adds treasury and provider-funds views split into reserved, frozen and free, a daily P&L that closes and is corrected only by dated reversals, a financial register for money moving outside transactions, and import-and-match against provider statements on amounts, references and timing windows.
What this changes day to day
With an orchestration layer alone, the panel, the back office and the books are a separate build that has to be kept in sync with the routing integration as it evolves. With Core as the baseline and modules layered on top, the merchant panel, transaction model, wallets, routing, checkout, invoicing, disputes, analytics and — where enabled — support and reconciliation already agree with each other, because they were built as one product rather than assembled from parts that each have their own idea of what a transaction or a balance is.
