Business Guide
Understand how OMNYTH works from a business perspective — without needing to read the code.
What is Payment Orchestration?
Payment orchestration is a coordination layer that sits between your application and payment providers. It receives a payment instruction, selects the right provider and rail, applies compliance rules, handles failures, and returns a structured result.
Without orchestration, integrating a new payment provider or expanding to a new country requires bespoke development. With OMNYTH, it requires configuration.
Countries and Country Configuration
Each country in OMNYTH has a configuration profile defining its supported currencies, available rails, default routing rules, and compliance requirements. Adding a new country means creating a country profile — not writing integration code.
Country configuration controls which payment types are permitted, maximum transaction limits, screening requirements, and which providers are active for that market.
Payment Rails
A payment rail is a settlement network — SWIFT, ACH, SEPA, TARGET2, local instant payment schemes. Each rail has different speed, cost, and coverage characteristics.
OMNYTH abstracts rails behind a uniform interface. Your application specifies the payment type and OMNYTH selects the appropriate rail based on country, currency, amount, and routing rules.
- SWIFT — cross-border wire transfers
- ACH — US domestic batch payments
- SEPA — EU area euro transfers
- CLIQ / CliQ — Jordan instant payment scheme
- RTGS — high-value real-time gross settlement
Providers
A provider is a financial institution or payment processor that executes transactions on a rail. OMNYTH abstracts providers behind typed port interfaces. Swapping providers requires a configuration change, not a code change.
Multiple providers can be configured for the same rail, enabling failover — if the primary provider returns an error, OMNYTH automatically routes to the secondary.
Flows
A flow is the step-by-step orchestration plan for a payment. It defines which validation runs, which screening applies, how routing is decided, and what happens on failure.
Flow lifecycle:
- Draft — being designed, not active
- Published — active and selectable for new payments
- Executing — a payment is currently running through the flow
- Completed — execution finished successfully
- Failed — execution terminated with an unrecoverable error
Flows are versioned. Publishing a new version does not affect payments already in-flight on the previous version.
Routing
Routing decisions in OMNYTH are made at the flow step level. A Routing Decision step evaluates rules against the payment context — amount, currency, customer type, country — and selects the target provider.
Rules are evaluated in priority order. The first matching rule wins. If no rule matches, the default provider for the country-rail combination is used.
Payment Lifecycle
Every payment moves through a defined set of states:
- RECEIVED — payment accepted, not yet submitted to the flow
- SUBMITTED — submitted for flow execution
- PROCESSING — flow is executing steps
- PENDING_APPROVAL — paused awaiting human approval
- APPROVED — approval granted, resuming
- REJECTED — approval denied
- COMPLETED — payment settled successfully
- FAILED — payment could not be completed
- CANCELLED — cancelled before completion
Monitoring and Visibility
Every step in every flow execution is logged with a timestamp, input, output, and duration. The OMNYTH platform provides full step-level visibility for every payment — searchable by payment ID, customer, amount, or status.
Metrics are exported to Prometheus and visualized in Grafana dashboards covering throughput, success rate, provider latency, and error rates by step type.