An infrastructure layer that sits in front of acquirers, PSPs, payout rails and FX, exposes one API and one ledger, and removes the per-provider integration tax that comes with international growth. Pay-ins and mass payouts share the same vault and the same event model; finance closes the month from one export.
Online payment platform
The online payment platform that runs pay-ins and mass payouts from one API.
topropay unifies every connected acquirer, PSP, alternative method and bank rail behind one contract — inbound and outbound. Authorisation, settlement, FX, mass payout, reconciliation and reporting share the same vault, the same event model and the same ledger across Europe, the UK, APAC and LATAM.
- 300+
- payment methods
- 60+
- connected providers
- 40+
- markets
- <200ms
- routing decision
The short version
What a unified payment platform is — and what it isn't
A replacement for your acquirer relationships, a wholesale FX broker or a banking licence. Existing contracts can stay in place; the platform sits in front, scoring every authorisation and every payout against your own outcomes, and never tries to be the only provider behind the merchant.
Capability matrix
Pay-in, pay-out and treasury on the same business payment platform
Three columns of capability, three rows of concern. The same orchestration layer covers the inbound side, the outbound side and the treasury that sits between them.
| Concern | Pay-in | Pay-out | Treasury |
|---|---|---|---|
| Methods | Cards, wallets, BNPL, bank rails, local APMs and crypto across every supported market | Bank transfers (SEPA, Bacs, ACH, PIX, Interac, SPEI), wallet payouts and card payouts where supported | Multi-currency wallet balances, FX conversion on policy, settlement currency by configuration |
| Orchestration | Per-transaction routing across acquirers; cascade through soft declines inside the same request | Beneficiary validation, bulk-file ingestion, retry policy per rail, scheduled batches and on-demand payouts | Real-time balance views; automatic top-ups between rails; ERP-ready exports keyed off vault tokens |
| Operations | Hosted checkout, hosted fields, SDK; signed webhooks; SIEM-friendly event stream | Operator portal for approval workflows; dual-control for high-value batches; signed payout receipts | Daily reconciliation across pay-in, pay-out and FX; per-tenant reporting for PSPs and platforms |
Key benefits
Five reasons international merchants and PSPs adopt a unified payment platform
Five outcomes that show up consistently once orchestration covers both sides of the ledger — not just acceptance and not just payout, but the same surface across both.
- Reach
An international payment platform behind one contract
Merchants and PSPs operating across Europe, the UK, APAC and LATAM reach every connected acquirer and method through one unified API. Adding a new region is a configuration change, not a new build — the engineering footprint stays the same as you grow.
- Approvals
Routing that fights for every authorisation
Per-transaction scoring on BIN, scheme, currency, country and risk picks the route most likely to clear at the lowest landed cost. Cascading absorbs soft declines inside the same request — the buyer sees a single clean result, the merchant sees the lift in the approval curve.
- Payouts
Mass payout solutions on the same surface
Bulk payout files, on-demand transfers, scheduled batches and approval workflows all run through the unified API — the same surface that handles the inbound side. No second platform for payouts; mass payout becomes a configuration of the same pay-in stack.
- Methods
Hundreds of methods, including a crypto payment platform path
Cards, wallets, bank rails, BNPL and (via partner gateways) a crypto payment platform path all surface through the same checkout and the same reconciliation feed. Merchants accept what their buyers expect without a per-method integration.
- Reporting
Unified reconciliation across pay-in and pay-out
Settlements, fees, refunds, chargebacks and payout dispatch normalise into one ledger. Finance closes the month from a single export; treasury sees real-time balances per currency; PSPs see per-tenant rollups without bespoke pipelines.
How it works
From onboarding to a daily reconciliation across pay-in and pay-out
Six concrete stages between contract signature and the first reconciliation export that includes both inbound and outbound flows.
- 01
Onboard
One platform-side onboarding replaces a queue of per-provider applications. KYC, underwriting and contracting flow through the sub-merchant model where merchants prefer it.
- 02
Integrate
Drop in the hosted checkout, or integrate the unified API and SDKs. Web, mobile and server flows share the same shape and the same vault.
- 03
Configure
Methods, routing policies, payout rails, approval workflows and risk thresholds are all dashboard-level. Engineering does not touch production once the integration is live.
- 04
Authorise & capture
Inbound authorisations run through the routing engine in under 200ms; cascading absorbs declines. Refunds, partial captures and disputes run on vault tokens through the same API.
- 05
Pay out
Outbound transfers run as bulk files, scheduled batches or on-demand calls. Beneficiary validation, dual-control approvals and signed receipts ship by default.
- 06
Reconcile
Pay-in, pay-out, FX and chargebacks normalise into one ledger every day. Daily exports drop straight into your ERP; the event stream feeds your warehouse and SIEM in real time.
Mass payout solutions
Bulk payouts on the same surface as pay-ins
Bulk-file ingestion, scheduled batches and on-demand transfers across major bank rails, wallet payouts and card payouts where supported — all through the same unified API and the same vault as the inbound side. No second integration, no second reconciliation, no second operator portal.
- CSV / JSON file ingestion plus a REST payout API
- Per-rail policy: SEPA, Bacs, ACH, PIX, SPEI, Interac, wallets
- Beneficiary validation against bank-master data where available
- Dual-control approvals on high-value batches
- Signed payout receipts and full audit log per beneficiary
- Retry policy per rail; failed transfers re-queued automatically
Industry relevance
Where a multi-region, pay-in + pay-out platform earns its keep
Eight verticals running on the platform today, with a slightly different mix of inbound methods, payout rails and treasury policy for each.
-
DTC & retail
International storefronts, multi-currency settlement, local methods per market
-
Marketplaces
Split payments, seller payouts, per-tenant reporting
-
Gig & freelance platforms
Freelancer payment method coverage across bank rails, wallets and cards
-
Subscriptions & SaaS
Vault-token recurring with smart retries and account updaters
-
Travel & ticketing
Staged captures, partial refunds, multi-currency capture
-
PSPs & ISVs
Resold capacity downstream with per-tenant routing and reporting
-
Financial services
Wallets, top-ups and payouts in regulated regions
-
Affiliate & creator economy
Mass payout flows for affiliate networks and creator platforms
topropay works with licensed and regulated operators only. Gaming and entertainment merchants are onboarded where a current operating licence exists; grey- and black-market verticals are out of scope regardless of integration shape.
Platform features
The capability surface behind the platform
Twelve capabilities, formatted as a compact key / value list so engineers can scan them quickly. What the platform actually ships — not what we'd like it to ship later.
-
unified-apiOne REST contract plus SDKs for web, mobile and server — covers pay-in and pay-out. -
hosted-checkoutDrop-in checkout, hosted fields and low-level SDK for the inbound side. -
smart-routingPer-transaction scoring across BIN, scheme, currency, country and risk. -
cascadeSoft declines fail over to the next ranked acquirer inside the same authorisation. -
vault-tokensPCI DSS Level 1 vault; refunds, retries and recurring run on vault tokens. -
3ds-scaSelective 3DS2 / SCA challenges, PSD2-compliant in Europe. -
mass-payoutBulk file + API payouts, dual-control approvals, signed receipts, retry policy per rail. -
treasuryMulti-currency wallet balances, FX conversion on policy, real-time balance views. -
webhooksSigned events into your SIEM, warehouse or in-house tooling — per-event-type subscription. -
operator-portalOne dashboard for authorisations, payouts, refunds, disputes and chargebacks. -
tenant-reportingPer-tenant rollups for PSPs and platforms with downstream merchants. -
sandbox-paritySandbox per environment that behaves like production — pay-in, pay-out and reconciliation included.
Trust & compliance
A PCI DSS Level 1 service-provider posture, inherited by every sub-merchant
Card data captures into topropay's PCI DSS Level 1 vault before it touches any underlying provider. SCA and 3DS2 are wired into the authorisation path for selective challenges in Europe. Sanctions screening runs at onboarding; AML monitoring scales to merchant vertical and volume. Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP thresholds are tracked and surfaced in the dashboard. Regional data-residency options are available where regulators require them, and signed event logs are exposed from the dashboard for audit. Licensed and regulated operators only — grey- and black-market verticals are out of scope.
Ready to unify the stack
Run pay-in and pay-out off the same platform — across every market you operate in.
A 45-minute platform tour walks through the inbound methods, payout rails and treasury policies relevant for your geographies, with a sandbox you can test against before any commercial commitment.
Frequently asked
Buyer questions about the online payment platform
What buyers actually ask before they commit — covering definitions, the international angle, use cases, methods, comparisons and adoption.
How is an online payment platform different from a payment gateway?
A payment gateway is one connection that authorises and clears card transactions. An online payment platform like topropay sits one level higher: pay-in across many gateways, pay-out across many bank rails, treasury across multi-currency balances, reconciliation across all of them — all behind one API. Some buyers use the terms interchangeably; the platform reach is what separates them in practice.
What does 'unified payment platform' actually mean here?
Unified payment platform means one integration surface across what would otherwise be several integrations — gateways, payout rails, FX, reconciliation. The platform absorbs the per-provider differences and exposes a single contract; unified payment systems thinking applied across the whole pay-in / pay-out lifecycle rather than just one side of it.
Is topropay an e payment platform, a payment platform or both?
Functionally it is both an e payment platform — every method, every region, every rail behind one API — and a payment platform for the wider treasury and payout flows that sit alongside the inbound side. The distinction is mostly terminology; the product surface is one platform either way.
Where does 'payment platform as a service' fit?
Payment platform as a service describes how PSPs and platforms can resell topropay's connected capacity downstream. The orchestration, vault, routing and reconciliation become a building block in another platform's product, with per-tenant reporting and isolated dashboards for each downstream merchant.
Is this really an international payment platform or one optimised for a single region?
International payment platform is the design centre, not an afterthought. The platform connects acquirers and methods across Europe, the UK, APAC and LATAM; routing policies and method mixes are per-region; settlement currency is a configuration choice; FX is a treasury function rather than an embedded markup.
Are mass payouts supported across the same regions?
Mass payouts are supported across the major bank rails (SEPA, Bacs, ACH, PIX, SPEI, Interac), plus wallet payouts and card payouts where the underlying provider supports it. Bulk-file ingestion, scheduled batches and on-demand transfers run through the same unified API as inbound authorisations.
Does the platform fit as a business payment platform for B2B flows?
Business payment platform usage covers B2B card acceptance, supplier payouts, invoice settlement and recurring billing across business buyers. The orchestration is the same as B2C — what changes is method bias (more bank rails, fewer wallets), ticket size and approval workflow needs, all of which are configurable.
What about a freelancer payment method setup for gig platforms?
Freelancer payment method coverage runs through the payout side of the platform. A gig or freelance platform ingests a beneficiary list, picks a per-rail policy (bank transfer where it's cheapest, wallet payout where it's faster) and runs scheduled batches or on-demand transfers. Each freelancer sees the same operator experience regardless of which underlying rail was used.
Can the platform act as a social payment platform for community / creator flows?
Social payment platform flows — creator tipping, fan funding, community marketplaces — fit the same shape as marketplace flows: inbound card and wallet payments split between creator and platform, outbound payouts to creators via bank rails or wallet payouts, per-creator reporting. The platform doesn't ship social UI itself; it provides the payment plumbing underneath one.
Is there a crypto payment platform path inside the unified API?
Yes — a crypto payment platform path runs through partner crypto gateways that plug into the same unified API as fiat methods. Stablecoin and major-token authorisations surface in the same checkout and the same reconciliation feed; conversion-on-receipt policies are configurable per merchant.
What about an open payment system approach — can I plug in my own providers?
Open payment system principles are baked in: the platform connects to existing acquirer and PSP relationships rather than replacing them. If you bring an existing provider, we wire it as a route in the engine. The integration surface stays one API regardless of how many of your own contracts sit behind it.
How do we decide whether this is the best payment platform for our setup?
Best payment platform depends on geography mix, method mix, payout needs and the shape of your treasury. For a single-region, card-only, pay-in-only merchant, a simpler local provider may be enough. For merchants and PSPs operating internationally with mixed methods and payout flows, the unified pay-in + pay-out + treasury shape of topropay tends to win on total cost of ownership.
How does the platform compare to running mass payout solutions separately?
Running mass payout solutions on a separate stack means two integrations, two reconciliation feeds, two operator portals and a manual join in finance. topropay's unified shape removes that join — pay-in and pay-out share the vault, the event model and the ledger, so a payout to a beneficiary references the same data model as the authorisations that funded it.
How fast can a new merchant or PSP go live on the platform?
Most merchants reach a live integration in days for the hosted checkout and weeks for a fully embedded pay-in + pay-out build. The slowest step is usually onboarding (KYC, underwriting), not engineering — the API surface is small enough to integrate in a sprint. Once live, switching on new methods, new payout rails or new acquirers is dashboard work, not a release.
Related
Related on the topropay platform
- Aggregation Payment aggregator overview The aggregation pattern behind the multi-provider platform — many connections in, one settlement out.
- Processors Payment processors, orchestrated Every connected processor as a routable lane behind the same unified API.
- Acceptance Accept online payment, MID optional The acceptance side of the platform — sub-merchant or direct MID.
- Checkout Modern e-commerce payment system How the platform surfaces inside a modern online retail checkout.
- Regional India payment gateways and global rails Regional gateway coverage across India (via licensed partners) and every other supported market.
- Orchestration Payment orchestration overview The orchestration model that the platform is built around.