Questions partners ask before they sign.

omwio is multi-tenant software for running a payment platform under your own brand. Each partner gets an isolated tenant on its own domain with a manager panel, a merchant panel, a hosted checkout, a Processing API and merchant documentation. Merchants, providers, routing, payments, payouts, wallets, invoices and disputes are configured there rather than built.

You bring the brand, the merchants and the provider relationships. We supply and operate the technology layer underneath.

No. omwio is software. We are not an acquirer, a payment institution, an e-money institution or a money services business, and we are never the payment service provider of record for your merchants.

Acquiring and PSP relationships are contracted by you directly, and the platform connects to them as provider modules.

No. Money moves between payers, your providers and your merchants under your contracts with those providers. omwio records and orchestrates the transactions — balances, wallets, reserves, payouts — but funds never pass through an omwio account.

Companies building a payment business of their own: payment companies entering a new market, platforms bringing payments in-house, and operators who have outgrown a gateway that was never meant to be resold.

If you need a single merchant account for your own shop, a PSP is a better fit than a white-label platform — and we will say so on the first call.

You can, but the parts that take years are the unglamorous ones: ledgers that agree with exports, routing, dispute workflows, reconciliation, permissions and tenant isolation. On omwio they already exist and already agree with each other.

What is left for your team is configuration — domains, providers, tariffs and merchants — plus the parts of your product that are genuinely yours.

An orchestrator mostly sits in front of PSPs for one business's own checkout. omwio is a platform you resell: on top of routing across providers it gives you tenants, merchant onboarding with tariffs and commissions, a merchant panel, wallets and balances, invoices, payouts and disputes — everything a partner needs to run merchants of their own.

There is no public price list. Fees are set in your order form and depend on the billing plan — Core plus the optional modules you choose — and on your rollout.

We put the billing plan, the module set and the rollout schedule in writing before anyone signs, so the commercials are known up front.

Core is not a trial tier. A tenant on Core alone can onboard merchants with tariffs and commissions, take payments, pay out, refund, handle chargebacks and disputes, invoice through a hosted page, run multi-currency wallets and exchanges, route across providers and MIDs, and see conversion and provider analytics — with RBAC, 2FA and an admin audit trail.

Optional modules add support inboxes, monitoring, reconciliation, antifraud, mass payouts, advanced exports and custom branding.

No. A disabled module is removed from panel navigation and closed at the API route level, so it is genuinely off rather than merely out of sight.

No. When a plan is assigned, its module set is frozen into the tenant's entitlement snapshot. Editing the plan template later does not touch live tenants; a plan is re-applied deliberately — to one tenant, or in bulk to the tenants bound to it.

Yes. After a thirty-minute call we stand up a demo tenant on a demo domain with your logo and palette, connected to a sandbox provider, and walk the full path live: merchant onboarding, a payment, a payout, an invoice and a dispute.

After that comes a pilot with one merchant, one provider and real traffic, so you see the platform under your own conditions.

On termination your tenant data is made available for export for the period stated in your order form, and is then deleted in line with the retention schedule. Your provider contracts are yours throughout, so they are not tied to us either.

Possibly — it depends on your activity and jurisdiction, not on the software. Because omwio is not a payment institution, any licence, registration or permission your payment activity requires is yours to hold, or is held by the licensed providers you work with.

We do not give legal advice, but we will walk through how the platform fits the model you or your counsel have in mind.

Card details are entered on the hosted checkout on your pay host and passed to providers through secure input paths. They are never stored in the panel domains, and merchants never handle raw card numbers in their own integration.

Your exact PCI DSS obligations depend on your providers and on how you operate, so confirm the scope with your assessor; we will provide what they need about the platform side.

You do. Onboarding, verifying and monitoring your merchants, and any KYC or KYB obligations attached to that, rest with you as the tenant operator and with your licensed providers. The platform gives you the controls to do it: per-merchant settings, permission-gated review steps, antifraud screening and monitoring.

Inside your tenant you are the controller and we act as processor, under our data processing terms. Customer records are stored encrypted, with blind-index lookup so search by reference, e-mail or phone never needs plaintext.

Transfers outside the EEA rely on an adequacy decision or on standard contractual clauses. The current list of sub-processors is available to partners on request.

Yes. Before a tenant is provisioned we verify the legal entity, its owners and directors, the licences it relies on, and screen against sanctions, PEP and adverse-media sources — repeated on an ongoing basis. The depth scales with risk.

Yes. The manager panel, the merchant panel, the hosted checkout, the merchant documentation and outbound e-mail all read your branding from one tenant configuration. Merchants sign up with you, log into you and receive mail from you; the platform underneath never shows through.

Yes. You point your domain at the platform and five hosts come up branded and isolated: manager, merchant, pay, api and docs — for example merchant.yourbrand.com and api.yourbrand.com. Cookies are host-scoped, so a session on one tenant domain is never valid on another.

The hosted checkout carries your logo, colours, copy and payment-method presentation, while the payment logic behind it stays on the platform's tested path. Deeper theming of panels, checkout and mail is what the Custom branding module adds.

Yes. Each brand or partner is its own tenant on its own domain, with its own merchants, branding and data, isolated from the others. Adding one is configuration, not a new deployment.

Outbound e-mail — invoices, notifications, alerts and password resets — is rendered in the recipient's own language rather than the sender's panel locale, and each tenant has its own locale default.

Yes. You contract acquirers and PSPs directly; the platform attaches them as provider modules, you register your MIDs against them, and you decide which methods each currency supports. We do not issue merchant accounts or MIDs.

Tell us which one. A new provider is added as a module that translates its responses into the platform's four instruction types, so merchants' integrations do not change when it lands. Whether and when depends on the provider's API, which is why we ask early.

Routing decides on MIDs. Methods are enabled per currency, rules are set per method, and per-merchant overrides sit on top without forking the system definition. Before anything goes live you can preview which route a given merchant and method would resolve to.

Retry and provider-status handling are part of the platform, and provider analytics show success rates and failure reasons per provider and MID. The Monitoring module adds health signals for providers, MIDs and routes so problems surface before merchants report them.

Card acquiring (hosted or direct card input), card-to-card P2P with proof upload, bank transfers on local rails, crypto wallets, hosted redirects and region-specific local methods. What is available in practice depends on the providers you connect.

Whatever the provider, the payer's next step comes back as one of four instruction types: card input, card P2P requisites, crypto wallet address or redirect.

Merchants hold wallets per currency with balance history and reserve visibility. Currency pairs have their own rate sources and rate locks, merchants can exchange between wallets with a live quote, and rounding rules are enforced server-side so screens and exports agree.

Yes. Single and batch payouts are in Core, with a release step. The Mass payouts module adds batch upload with review and approval steps, so a large run is checked by the right people before money moves.

Refunds, chargebacks and a structured dispute workflow are in Core. A manager can let a merchant open disputes on its own payments and payouts — from the panel or the API — with a reason and up to five evidence files. The manager resolves them, and balances are rolled back and re-posted automatically.

Yes, with the Accounting & reconciliation module: treasury, daily P&L, provider funds and settlement matching with explicit breaks, so a mismatch is a listed item rather than a surprise at month end.

Yes, as the Antifraud module: rule and velocity screening on the transaction create path, before anything reaches a provider. It is enabled per billing plan.

Core includes conversion and provider analytics — success rates, failure reasons and volume over time by merchant, provider and MID — and merchants get their own dashboard. Downloadable statements follow the same rounding as the screen. The Advanced exports module adds scheduled and large-scale exports.

Through one Processing API on your api host, with the hosted checkout on your pay host for the payer. Merchants manage API keys and callbacks in their panel and integrate against documentation on your own docs host.

Because provider quirks are normalised before they reach the API, an integration keeps working when you add a provider, a method or a currency.

Every processing call is signed: an HMAC signature over the body, a timestamp and a nonce. Replayed requests are rejected. Every failure — validation, auth, signature, conflict — returns the same error shape: ok, error.code, error.message, error.details.

merchant_order_id is unique per tenant and merchant. Sending the same one again returns a controlled 409 conflict instead of a second payment, so retries on a flaky network are safe.

Yes. Merchants configure callbacks in their panel's developer section. Statuses use one collapsed vocabulary, so merchants see the same states whichever provider processed the payment.

Yes, on your own docs host: your branding, a curated Processing API reference and your environment details. Integration never sends a merchant to a third-party brand.

On the platform side there is no processing code to write: claim the domain, connect providers, set tariffs and routing, onboard merchants. In practice the pace is set by your provider contracts and onboarding, so we agree the schedule with you in writing before signing.

Yes — migration from an existing gateway is one of the things our technical team handles. The usual path is to bring providers across first, then move merchants in stages, starting with a pilot merchant on live traffic.

Support channels, hours and any service levels are written into your order form. Technical questions go to tech@omwio.com, and enquiries get a reply within one business day.

You do — they are your merchants under your brand. The Support inbox module lets your team handle merchant tickets inside the panel, next to the transaction data, and Support inbox AI adds suggested answers and triage.

No. Every request is tied to its tenant by domain before anything else runs, so isolation is part of the architecture rather than a query filter someone might forget. Inside a tenant, RBAC decides what each role can see and do, and admin activity is recorded.