Launch your own
payment gateway.
omwio is the multi-tenant platform behind your brand. Each partner gets an isolated tenant, its own domains, its own merchants and its own processing rails — without building ledgers, routing or compliance from scratch.
manager.yourbrand
Tenant manager panel
merchant.yourbrand
Merchant panel
pay.yourbrand
Hosted checkout
api.yourbrand
Processing API
docs.yourbrand
Merchant docs
Branded hosts per tenant
manager · merchant · pay · api · docs
Isolated partner-facing panels
Neither can read across the boundary
Optional packaged modules
Gated by billing plan, enforced in the API
Canonical API error shape
One envelope for every failure mode
Separated control planes
One platform, two separated panels.
Every tenant is isolated by domain. Your partner runs their own back office, their merchants run their own panel, and neither can see across the boundary — RBAC decides what each role sees inside it.
Capabilities
Everything a gateway needs, already built.
The parts that take years to get right — ledgers, routing, disputes, reconciliation — ship as part of the platform instead of your roadmap.
Money movement
- Payments, payouts and merchant-to-merchant exchanges
- Refunds, chargebacks and structured dispute workflows
- Mass payouts with review and approval steps
- Invoices with hosted public payment pages
Ledger & balances
- Multi-currency merchant wallets per tenant
- Balance history with reserve and hold visibility
- Currency pairs, rate sources and rate locks
- Rounding rules enforced server-side, not in the UI
Routing & providers
- Provider modules with typed payment instructions
- Provider MIDs with per-merchant method overrides
- Route resolution preview before anything goes live
- Retry and provider-status handling out of the box
Control & trust
- RBAC down to individual panel permissions
- Tenant-scoped 2FA, sessions and password resets
- Encrypted PII with blind-index lookup fields
- Reconciliation, monitoring and antifraud modules
Why build on it
The advantage is what you do not have to build.
Everything below is either configuration or already running. None of it is a roadmap item you inherit.
Time to market measured in weeks
Processing, ledgers, routing, disputes and reconciliation are the parts of a gateway that take years. They are already built, already tested, and already agree with each other.
Your brand on every surface
Panels, hosted checkout, merchant documentation and outbound e-mail all read your tenant branding from one configuration. Merchants never see the platform underneath.
Isolation you can sell
Tenant boundaries are enforced at request resolution, not by a filter someone might forget. That is the answer to the due-diligence question your partners will ask.
Commercials you control
Tariffs, commissions and routing are yours to shape per merchant, and packaging is yours to shape per partner through billing plans.
Amount due
€149.00
Secured by yourbrand · TX-8H2QK-4LMPD-91XRT
The hosted checkout carries your identity while the payment logic stays on the platform's tested path. See what you can customise →
Processing API
A merchant-facing contract that stays stable.
Your merchants integrate once. Provider changes, new rails and new methods land behind the same public shapes.
POST /v1/transactions HTTP/1.1
Host: api.yourbrand.com
X-Signature: 9f2c… # HMAC over body + timestamp + nonce
X-Timestamp: 1756310400
Content-Type: application/json
{
"type": "payment",
"merchant_order_id": "ORD-10482",
"amount": "149.00",
"currency": "EUR",
"method": "card",
"customer": { "email": "buyer@example.com" }
}{
"ok": true,
"data": {
"token": "TX-8H2QK-4LMPD-91XRT",
"status": "pending",
"amount": "149.00",
"currency": "EUR",
"payment_instructions": [
{
"type": "redirect",
"title": "Continue to payment page",
"payload": { "url": "https://pay.yourbrand.com/…" }
}
]
}
}Signed requests
Every processing call is authenticated by HMAC signature, timestamp and nonce — replayed requests are rejected.
One error envelope
Validation, auth, signature and conflict failures all return the same ok / error.code / error.message / error.details shape.
Idempotent orders
merchant_order_id is unique per tenant and merchant; duplicates return a controlled 409 instead of a stray database error.
Canonical instructions
Provider quirks are normalised into card_input, card_p2p_requisites, crypto_wallet_address and redirect — no provider wording leaks to merchants.
Go live
From domain to first transaction.
No processing code to write. The work is configuration, and it is reversible.
Claim your domain
Point your domain at the platform. Manager, merchant, checkout, API and docs hosts come up branded and isolated.
Connect providers
Attach acquirers and PSPs as provider modules, register MIDs, and define which methods each currency supports.
Shape the commercials
Set tariffs, commissions and routing per merchant. Preview route resolution before a single transaction runs.
Onboard merchants
Invite merchants into their own panel with API keys, callbacks and documentation already generated for your brand.
Packaging
Core stays constant. Modules are yours to choose.
Every tenant runs on the same core contract. Optional modules are assigned through billing plans and frozen into the tenant's entitlement snapshot — editing a plan never silently changes a live partner.
Core
Not a trial tier. A tenant on Core alone can onboard merchants, take payments, pay out, invoice and resolve disputes. Present in every plan, on every tenant, from day one.
- Merchants, tariffs and commissions
- Payments, payouts, refunds and chargebacks
- Multi-currency wallets and balance history
- Invoices and hosted checkout
- Providers, MIDs and routing
- Disputes with evidence upload
- Currency pairs, rates and exchanges
- RBAC, 2FA and admin audit trail
Packaged add-ons
Enforced in both panel navigation and at the API route level — a disabled module is genuinely off, not just hidden.
Support inbox→
Merchant tickets handled inside the panel, next to the data
Support inbox AI→
Suggested answers and triage for the support queue
Monitoring→
Health signals for providers, MIDs and routes
Reconciliation→
Match provider settlements against platform records
Antifraud→
Rule and velocity screening before processing
Mass payouts→
Batch payout upload, review and release
Advanced exports→
Scheduled and large-scale data exports
Custom branding→
Deeper theming of panels, checkout and outbound mail
Rails
Add a provider, not a rewrite.
Provider modules return typed instruction objects. The platform normalises them into four canonical shapes — card input, card P2P requisites, crypto wallet address, redirect — stores them, and renders the right checkout step. New rails do not ripple into merchant integrations.
Money in
- Card acquiringHosted or direct card input
- Card P2P requisitesCard-to-card with proof upload
- Bank transfersLocal rails and SEPA-style credit
- Crypto walletsAddress issuance and confirmation
Money out
- PayoutsSingle and batch, with a release step
- FX exchangePair-aware quotes with rate locks
How the payer meets it
- Hosted redirectProvider page, your checkout token
- Local methodsRegion-specific, same instruction shape
Trust
Isolation is the architecture, not a setting.
Tenant isolation by domain
Tenant resolution happens at the edge of every request. Cookies are host-scoped, and cross-tenant reads are impossible by construction, not by convention.
PCI-aware card handling
Sensitive card input is captured on the hosted checkout surface and handed to providers through secure input paths rather than being persisted in the panel domain.
Encrypted customer data
Customer records are stored encrypted with blind-index fields for reference, e-mail and phone lookups, so search works without exposing plaintext PII.
Granular RBAC and audit
Roles carry individual permissions per panel action. Admin activity is recorded, and merchant 2FA can be force-reset from the manager panel when needed.
About omwio
We build the part nobody sees.
We are infrastructure, not an acquirer. We never hold your funds and are never the payment service provider of record for your merchants — what we operate is the multi-tenant control layer above your own provider relationships.
Isolation belongs in the architecture
Not in a query filter someone can forget. Tenant resolution happens at the edge of every request.
A stable contract beats a rich one
Provider quirks get normalised before they reach your merchants, so their integration survives our roadmap.
White-label means the whole surface
Panels, checkout and outbound mail. If any of them reads as someone else's product, the illusion is gone.
Next step
See it running under your brand.
We will spin up a tenant on a demo domain, connect a sandbox provider and walk the full path — merchant onboarding, a live payment, a payout and a dispute.