Accept online payment
topropay lets a merchant accept payments online across every connected acquirer, PSP and method through a single integration. Take cards, wallets, bank rails, BNPL and crypto — with or without your own merchant account. Every authorisation is routed for the best result, and every settlement lands in one ledger.
Key benefits
Accepting a payment changes the moment more than one provider sits behind the checkout. These are the four outcomes merchants tell us they noticed first after go-live.
Cards, wallets, bank rails, BNPL and crypto run through the same unified API. The checkout surface re-orders the method list per shopper's market, currency and device, so the most likely-to-convert option is always at the top.
Per-transaction scoring picks the route most likely to clear at the lowest landed cost. Soft declines cascade to the next ranked acquirer inside the same request, so a shopper sees a single clean result instead of an error and a retry button.
Through the sub-merchant model, merchants integrate against topropay's MIDs and inherit the platform's acquiring posture. Useful for merchants in early stages or in verticals where a direct MID is slow to provision; the day-to-day shape from a buyer's perspective is identical.
Settlements, fees, refunds and chargebacks across every connected acquirer normalise into a single ledger keyed off vault tokens. Finance closes the month from one export instead of a CSV-per-provider merge.
How it works
The path from contract to live traffic is short — most merchants go live in days. Here is what changes at each step, and what stops being your problem.
Drop in the hosted checkout for a fast launch, or integrate the SDK and hosted fields if full control of the checkout surface matters. Same back-end either way.
Method availability is dashboard-configurable per market. Turn on cards everywhere, add wallets where they convert, layer BNPL and bank rails where shoppers expect them, light up crypto where treasury can use it.
Approval-weighted, cost-weighted or composite — pick the policy per region. The routing engine scores every authorisation against your own traffic in under 200ms.
Authorisations flow through the routing engine; soft declines cascade to the next ranked acquirer. Captures, refunds and partial captures all run against vault tokens through the same API.
Settlement, fees, refunds and chargebacks roll up into one ledger every day. Adjust routing weights, change the method mix or add a new acquirer from the dashboard, not a release.
Main use cases
Six kinds of merchant share the same orchestration layer but use it in different ways. The product stays the same; the policy on top is what varies.
Online retailers using the platform as the layer that lets them accept payment online across every connected provider — surfaces local methods per market, routes across acquirers, and consolidates the reporting.
Recurring billing on vault tokens with smart retries and account updaters — renewal recovery becomes a configuration choice, not a per-provider scripting exercise.
Multi-seller platforms split payments and run seller payouts through one orchestration layer; reporting keeps every seller's ledger straight without bespoke plumbing.
Resellers ride the connected portfolio downstream: their merchants inherit routing, reconciliation and method coverage; the PSP keeps the relationship and pricing.
Staged captures, partial refunds and multi-currency capture run end-to-end so a complex booking is one timeline across providers, not a CSV-per-acquirer merge.
For licensed operators in permitted jurisdictions, sports-betting accept-payment flows run through the same orchestration as the rest of the platform, with operator-specific risk rules layered on top.
Platform features
Twelve capabilities, grouped so an engineering, ops or treasury reader can quickly find the tiles that matter. This is what the platform ships today, not a future roadmap.
One REST contract plus SDKs for web, mobile and server. Replaces a backlog of per-provider integrations.
Drop-in checkout for fast launch; hosted fields and SDK for full control of the surface.
Per-transaction scoring on BIN, scheme, currency, country and risk — ranked routes per authorisation.
Soft declines fail over to the next ranked acquirer inside the same authorisation.
Card data lives in our vault. Refunds, retries and recurring run on tokens, never PANs.
Network tokens by default plus scheme account updaters keep saved cards alive through re-issuance.
Selective challenges per transaction — PSD2-compliant in Europe without breaking conversion.
Settlements, fees, refunds and chargebacks normalise into one ledger across every accepted method.
Velocity rules, list management and a partner-agnostic fraud-engine model — bring your own or ride ours.
One dashboard for authorisations, refunds, disputes and chargebacks across every connected acquirer.
Signed, normalised events fit cleanly into your SIEM, warehouse or in-house tooling.
Europe, the UK, APAC and LATAM connectivity behind one contract, including local methods per region.
With or without a MID
Two valid paths through the same platform. The buyer sees the same checkout; the difference shows up in onboarding, settlement and where the compliance work sits.
Trust & compliance
Every authorisation runs through one audited environment. Merchants integrate as sub-merchants and inherit the platform's PCI DSS, SCA and operational posture. You no longer carry a separate certification for each provider.
Service-provider posture validated annually on-site; quarterly ASV scans run on the platform cycle.
Selective authentication on the authorisation path; PSD2-compliant in Europe without breaking approvals.
Card data captures into the vault before it ever touches your systems; events and refunds run on vault tokens.
Webhooks are signed and replay-safe; the event stream is SIEM-friendly out of the box.
Data-residency options for merchants under regulators that require it; signed event logs available from the dashboard for audit.
Licensed gaming, regulated financial services and other compliance-bound merchants supported where current licences exist. Grey and black-market verticals are out of scope.
Ready to start accepting
A 30-minute review walks through the methods relevant for your markets, whether the direct-MID or sub-merchant path fits, and a sandbox to test against before any commercial commitment.
Frequently asked
The questions buyers ask before they commit — covering definitions, the MID and sub-merchant paths, mobile, vertical fit and integration timing.
It means a single API call from your storefront or app reaches every connected acquirer, PSP and method behind the platform. The shopper sees a hosted checkout or your own surface; topropay routes the authorisation to the route most likely to clear, captures, reconciles and reports the result. The set of methods you accept and the routing policy that runs them are configuration choices, not separate integrations.
Yes. Through the sub-merchant model, you ride topropay's acquiring contracts and the platform settles to your bank on a fixed cycle. This is the common path for early-stage merchants and for merchants who would rather inherit the platform's underwriting than negotiate per-acquirer contracts themselves. The day-to-day buyer experience is identical to a direct-MID setup.
Both. The hosted checkout and SDKs ship for web, iOS and Android, so an accept payment app flow on mobile uses the same authorisation engine, vault and reconciliation as the web checkout. A merchant that wants only a web surface skips the mobile SDK; the back-end shape stays the same.
Accept payment online without merchant account contracts is the standard path through the sub-merchant model — one onboarding with topropay replaces a queue of per-acquirer applications. Most early-stage merchants begin this way and migrate to a direct-MID model later if economics or contractual constraints justify it. The decision is reversible.
Payment accept inside the platform is the moment an authorisation succeeds against the chosen route and a corresponding ledger entry is created. Tokenisation, vault storage and event delivery all hang off that moment; refunds, captures and chargebacks reference the same transaction record over its lifecycle.
Cards, the major wallets (Apple Pay, Google Pay, Click to Pay) and BNPL are broadly available; bank rails and local APMs vary by region. Accept payment methods can be configured per market in the dashboard, so a German checkout might surface SEPA and iDEAL alongside cards, while a Brazilian checkout surfaces PIX and Boleto. The unified API absorbs the difference.
Accept payment solutions on the platform layer vertical-specific risk rules, method bias and routing policies on top of the shared orchestration. A travel merchant gets staged captures and multi-currency capture by default; a subscription merchant gets network-token recurring and scheme updaters; a marketplace gets split payments and per-seller reporting. The base platform is the same; the policy is what changes.
Crypto payment accept flows are delivered through partner crypto gateways that plug into the same unified API as fiat methods. Stablecoin and major-token authorisations route through their own settlement path but appear in the same operator portal and the same reconciliation feed. Conversion-on-receipt policies are configurable per merchant and per asset to keep treasury predictable.
Accept all payment methods relevant to a specific buyer base is more useful (and more achievable) than 'every method on Earth'. The platform exposes hundreds of methods globally; the right subset for a buyer base is a function of geography and vertical. We'd rather ship the methods that move the needle for your shoppers than load the checkout with everything available.
Accept payment gateway behaviour on topropay covers the gateway surface — authorisation, capture, refund — but across many acquirers instead of one. From your integration's perspective it looks like one gateway; from the routing engine's perspective each acquirer is a lane the engine scores per transaction. Operationally it absorbs the work of running multiple gateways simultaneously.
Sports betting accept payment flows are supported where the operator holds a current licence in a permitted jurisdiction and runs full KYC, AML and responsible-gaming controls. Routing, cascading and reconciliation all behave the same way; operator-specific risk rules and method bias sit on top. Unlicensed gambling and grey-market betting are out of scope regardless of integration shape.
Online payment accept on a low-code stack usually means embedding the hosted checkout via an iframe or a short script tag, plus a single webhook handler. That ships in hours; the SDK and hosted-fields path is for teams that need full control of the surface and have engineers to maintain it.
Where direct provider coverage is thin, the platform reaches the market through licensed partner gateways — the integration shape stays the same on your side. India connectivity, for example, is delivered through licensed partner gateways rather than a direct topropay licence; the merchant sees one API.
Most merchants reach a live integration in days for the hosted checkout, weeks for a fully embedded 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 or new acquirers is a dashboard change, not a release.
* UPI and other India-domestic methods are delivered through licensed partner gateways rather than a direct topropay RBI Payment Aggregator licence.
Related