Your payment platform,
under your brand.
Infrastructure, not an acquirer. We never hold funds and are never the PSP for your merchants.
Multi-tenant software for partners: isolated tenants on your own domains, branded panels, merchants, providers and routing in one configurable environment. You keep the provider relationships — we supply the technology layer.
The demo runs on a tenant in your colours: merchant onboarding, a payment, a payout and a dispute.
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
One API error format
The same shape for every kind of failure
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 you need to accept, pay out and reconcile.
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
- The same totals in every panel, export and report
Routing & providers
- Provider modules with one instruction format per method
- 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 personal data, searchable without exposing it
- Accounting, reconciliation, monitoring and antifraud modules
Why build on it
What you do not build from scratch.
Everything below is either configuration or already running. None of it is a roadmap item you inherit.
Launch is configuration, not development
Processing, ledgers, routing, disputes and reconciliation are the parts of a payment platform that take years. They already exist and already agree with each other — what is left for you is domains, providers and tariffs.
Your brand from one configuration
Panels, hosted checkout, merchant documentation and outbound e-mail all use your branding from a single configuration. Merchants never see the platform underneath.
Each partner's data stays separate
Every request is tied to its tenant by domain before anything else runs, so one partner's data cannot reach another's — no 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. See what you can customise →
Processing API
One API for merchants. Provider changes do not break the integration.
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 format
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.
One format for every method
Card, card P2P, crypto and redirect payments come back in the same response format (card_input, card_p2p_requisites, crypto_wallet_address, redirect), whichever provider is behind them.
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
- Conversion and provider analytics
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
Accounting & reconciliation→
Treasury, daily P&L, provider funds and settlement matching
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.
Whatever a provider returns, the platform turns it into one of four instruction types — card input, card P2P requisites, crypto wallet address, redirect — and shows the payer 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.
Card data stays on the hosted checkout
Card details are entered on the hosted payment page and passed to providers through secure input paths. They are never stored in the panel domain.
Encrypted customer data
Customer records are stored encrypted. Search by reference, e-mail and phone still works, without exposing personal data in plain text.
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.
omwio is a software platform for companies building branded payment infrastructure: merchant management, provider integrations, routing, payments, payouts, wallets, disputes and APIs in one configurable environment. We supply the technology layer. We are not an acquirer or payment service provider, we never hold funds, and we are not a party to the relationship between you, your merchants and your providers.
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.
Blog
From the blog
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.