Payment acceptance

Payment acceptance, global, on one API.

topropay is the acceptance layer in front of every connected acquirer, PSP and method. Cards, wallets, bank rails, BNPL and (via partner gateways) crypto — surfaced on web, mobile and in-store through one unified API, routed per transaction across the connected provider panel, reconciled into one ledger.

Book an acceptance review Read the API docs
WEB topropay.com/checkout/

€189.00

Cards · Apple Pay · iDEAL · BLIK

Pay €189.00
MOBILE native SDK

€189.00

Apple Pay · Card · iDEAL

Pay €189.00
IN-STORE QR · terminal

€189.00

Scan with bank app · PIX · iDEAL

Confirm in app
One acceptance engine across three surfaces.
Global
EU, UK, APAC, LATAM coverage
300+
methods reachable
<200ms
routing decision
1 ledger
across every receipt

Four pillars

What 'payment acceptance solutions' actually means at scale

Four pillars that together make acceptance a product rather than a checkbox — surface, method, region and the underlying infrastructure.

  1. Surface

    Acceptance across every surface — web, mobile, in-store

    Payment acceptance on topropay is one engine across the merchant's checkout surfaces. The hosted page, the embedded SDK, the native iOS / Android pay sheet and the in-store QR all run authorisations through the same back-end. Vault tokens identify the customer regardless of where the authorisation came from.

  2. Method

    Hundreds of methods inside one acceptance layer

    Cards, wallets (Apple Pay, Google Pay, Click to Pay), bank rails (SEPA, Bacs, Open Banking, iDEAL, BLIK, PIX, OXXO, PayID), BNPL and (via partner gateways) crypto — all surfaced through the same unified API. Method availability per market is dashboard configuration, not separate integrations.

  3. Region

    Global payment acceptance, region-correct routing

    International payment acceptance only works when routing keeps each authorisation intra-region where possible — EU card BINs to EU acquirers, US BINs to US acquirers, APAC to APAC. The platform's connected acquirer panel makes that the default, not a per-merchant project.

  4. Stack

    Payment acceptance infrastructure, not a checkbox

    Beyond the checkout surface: PCI DSS Level 1 vault, signed webhooks, scheme account updaters, network tokens, selective 3DS2 / SCA, smart routing, cascade-on-decline, unified dispute queue, and one reconciliation feed. The infrastructure side is what makes the acceptance story durable.

How it works

From API key to live international payment acceptance in five stages

Five concrete stages between dropping in the API key and a daily reconciliation export finance can close the month against. Hosted-checkout merchants reach live in days; embedded builds take weeks.

  1. 01

    Integrate the unified API once

    JSON-over-HTTPS REST surface with idempotency, signed webhooks and OpenAPI specs. Pick the hosted checkout for fast launch or the embedded SDK for full UI control — both back onto the same engine.

  2. 02

    Switch on methods per market

    Method availability and ordering per market are dashboard-configurable. A French shopper sees cards plus SEPA; a Brazilian shopper sees cards plus PIX; a Dutch shopper sees cards plus iDEAL. No per-method plug-in required.

  3. 03

    Authorise across the connected acquirer panel

    Every authorisation runs through the routing engine — scored on BIN, scheme, currency, country pair and risk. Soft declines cascade to the next ranked acquirer inside the same request.

  4. 04

    Capture, refund and dispute through the same API

    Captures, partial captures, refunds and dispute responses all run against vault tokens through the same API. Operator portal handles the lifecycle across providers.

  5. 05

    Reconcile from one daily export

    Settlements, fees, refunds and chargebacks from every connected provider normalise into one ledger keyed off vault tokens. Daily exports drop straight into ERP or warehouse.

Main use cases

Where global payment acceptance earns its keep

Six merchant shapes that share the same acceptance layer but stress it differently — DTC, mobile-first, marketplaces, subscriptions, travel and PSPs.

  • DTC

    Direct-to-consumer brands selling globally

    Ecommerce payment acceptance with local methods per market and routing across the connected acquirer panel. The checkout converts in every market the brand sells in.

  • Mobile

    Mobile-first and in-app acceptance

    Native iOS and Android SDKs surface Apple Pay, Google Pay and regional wallets inside the same authorisation engine the web checkout uses. Mobile authorisations roll up into the same ledger as web.

  • Marketplaces

    Marketplaces and platforms

    Per-seller payouts, split payments and per-tenant reporting on one orchestration. The marketplace handles its sellers; the platform handles the per-provider acquiring relationships.

  • Subs

    Subscriptions and SaaS

    Network-token-driven recurring with smart retries and scheme account updaters — renewal recovery becomes a routing policy rather than a per-provider retry script.

  • Travel

    Travel, ticketing and high-ticket

    Staged captures, multi-currency, partial refunds and dispute analytics on a single API. High-ticket bookings benefit disproportionately because per-acquirer dispute timelines are abstracted into one contract.

  • PSP

    PSPs and ISVs reselling capacity

    Resellers ride the platform's connected portfolio downstream. Their merchants inherit the routing, method coverage and reconciliation; the PSP keeps the relationship and pricing.

Platform features

Capabilities behind payment acceptance infrastructure

What the platform actually ships beneath the checkout — the API contract, the back-end primitives, the operator surface and the sandbox.

  • Unified acceptance API

    One REST surface in front of every connected acquirer, PSP and method; SDKs for web, mobile and server.

  • Hosted checkout

    Drop-in checkout via redirect or iframe; signed session tokens; brandable surface; localised method ordering per market.

  • Embedded SDK

    Hosted fields inline on the merchant's own page, or low-level SDK for full UI control; PCI scope minimised either way.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair and risk signals — ranked routes per authorisation.

  • Cascade & retry

    Soft declines cascade to the next ranked acquirer inside the same authorisation; nothing leaks back to the buyer.

  • PCI DSS Level 1 vault

    Card data captures into the platform's vault before merchant origin; vault tokens drive refunds, retries and recurring.

  • Network tokens & updaters

    Network-token-by-default plus scheme account updaters keep saved cards alive across re-issuance events.

  • 3DS2 / SCA orchestration

    Selective challenges per transaction — PSD2-compliant in Europe without breaking conversion elsewhere.

  • Dispute & chargeback queue

    Unified queue across providers, evidence-pack templates per vertical, automated representment for select scheme types.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks across every connected provider normalised into one ledger.

  • Operator portal

    One dashboard for authorisations, refunds, disputes and chargebacks across every connected provider.

  • Sandbox parity

    Per-environment sandbox that mirrors production — routing, cascade, 3DS, refund and chargeback scenarios.

Trust & compliance

Compliance posture across the acceptance layer

Every authorisation runs through a single audited environment. Merchants inherit the platform's posture rather than carrying separate certifications per provider.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture regardless of method mix.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per vertical, volume and geography mix.
Scheme programme tracking
Visa VDMP / VAMP and Mastercard ECP / EFMP thresholds tracked per acquirer-bank relationship; dashboard alerts surface position vs limit.
Data residency
Regional data-residency options for merchants under regulators that require it; EU-resident traffic stays in-region by default.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of integration shape.

Ready to accept

One acceptance layer across surfaces, methods and regions.

A 30-minute acceptance review covers the methods relevant to your buyer base, the routing policies that fit, the SDKs that match your stack, and a sandbox to test against before any commercial commitment.

Book an acceptance review Read the API docs

Frequently asked

Buyer questions about payment acceptance on topropay

Questions buyers ask before committing — definitions, regional shape, infrastructure beneath the checkout, pricing and sandbox parity.

  1. 01

    What does topropay mean by payment acceptance?

    Payment acceptance on topropay is the umbrella for every part of accepting payments at scale — the checkout surface (web, mobile, in-store), the method mix per market, the routing across the connected acquirer panel, the vault, the dispute queue and the reconciliation feed. The merchant integrates once; the platform absorbs the per-provider complexity behind it.

  2. 02

    How does international payment acceptance work in practice?

    International payment acceptance works when the platform connects to acquirer banks in each region a merchant sells into and routes intra-region by default. A French-issued card paying a UK-domiciled merchant clears through a UK acquirer; a Brazilian-issued card pays through PIX or a Brazilian acquirer. The merchant doesn't run that triage; the routing engine does.

  3. 03

    What's included in payment acceptance services on topropay?

    Payment acceptance services on topropay include the unified API, the hosted and embedded checkout surfaces, smart routing across acquirers, PCI DSS L1 vault, network tokens and scheme updaters, selective 3DS2 / SCA, the unified dispute queue and the daily reconciliation feed. Sub-merchant onboarding and the operator portal are included; there's no separate per-service contract.

  4. 04

    Are payment acceptance solutions priced per service or per authorisation?

    Payment acceptance solutions on topropay are priced per authorisation on top of underlying provider economics — no platform retainer, no monthly minimum, no per-environment fee. Interchange and scheme fees pass through where the underlying provider supports it; the platform fee is a separate line.

  5. 05

    How is global payment acceptance different from running multiple regional gateways?

    Running multiple regional gateways means multiple integrations, multiple webhook handlers, multiple reconciliation files. Global payment acceptance on topropay collapses that into one — the integration shape and operator surface stay the same as the merchant adds regions. New markets become a configuration change rather than an engineering project.

  6. 06

    What credit card acceptance services does the platform expose?

    Credit card acceptance services on the platform cover Visa, Mastercard, Amex, Discover, JCB and RuPay across the connected acquirer panel. Network tokens, scheme account updaters, 3DS2 / SCA, selective dispute representment and chargeback-programme tracking are all included; the credit card lane shares the same routing engine as wallets, bank rails and BNPL.

  7. 07

    What's the payment acceptance infrastructure beneath the checkout?

    Payment acceptance infrastructure beneath the checkout includes: the PCI DSS L1 vault, the routing engine, the cascade-and-retry engine, network-token wiring, scheme-updater hooks, 3DS / SCA orchestration, signed webhook delivery, the operator portal, the unified reconciliation feed and the sandbox parity environment. Each is exposed through the unified API; the merchant doesn't bolt them on individually.

  8. 08

    How does an online payment acceptance system handle peak traffic?

    An online payment acceptance system on topropay absorbs peak traffic by spreading load across the connected acquirer portfolio and cascading around any provider that degrades. Platform-side capacity is horizontally sized; merchants don't need to provision per-provider buffers individually. Sandbox helpers cover spike-traffic scenarios for pre-launch testing.

  9. 09

    What's the ecommerce payment acceptance shape for a small team?

    Ecommerce payment acceptance for a small team is usually the hosted-checkout path — minimal PCI scope on the merchant side, one webhook handler, dashboard-level configuration for methods and routing. Most ecommerce platforms can wire it in hours; the merchant doesn't need a payments-engineering team to maintain it.

  10. 10

    Can the same payment acceptance setup handle web and in-store?

    Yes. The same authorisation engine powers web checkout (hosted or embedded), native mobile pay sheet and in-store QR / till flows. Vault tokens identify the customer across surfaces; the reconciliation feed tags every row with the surface where the authorisation originated.

  11. 11

    How are alternative payment methods handled inside the acceptance layer?

    Alternative payment methods (APMs) — iDEAL, BLIK, PIX, OXXO, PayID, BNPL and others — surface as method tiles on the same hosted checkout. Each method has its own back-end handler at the connected provider level; the merchant calls one authorise endpoint with the method field, and the platform handles the rest.

  12. 12

    Are crypto rails part of payment acceptance services?

    Yes. Crypto rails are delivered through licensed partner crypto gateways and exposed inside the same unified API as fiat. Stablecoins, majors and L2 networks all behave like another method tile on the checkout; optional conversion-on-receipt keeps treasury fiat-only when needed.

  13. 13

    How is recurring billing integrated with the payment acceptance system?

    Recurring billing runs through the same acceptance system: card-on-file recurring uses network tokens and scheme updaters; ACH and SEPA Direct Debit recurring share the same scheduling engine. The initial authorisation captures into the vault; renewals run server-to-server against the vault token.

  14. 14

    Can merchants migrate from another payment-acceptance provider without rebuilding the checkout?

    Yes. Migrations usually run in three stages: integrate topropay in parallel with the existing provider, shift a share of traffic and measure the routing uplift, absorb the remaining volume on a schedule the engineering and finance teams agree on. Vault-token migration from compatible sources is supported.

  15. 15

    How is payment acceptance tested before going live?

    The sandbox covers every production endpoint, signed webhooks (with rotating test secrets), and deterministic helpers for triggering specific outcomes — soft / hard declines, 3DS challenges, iDEAL / PIX bank-confirmation outcomes, ACH R-code rejections, refund and chargeback scenarios. Merchants build the full acceptance integration against the sandbox before any live volume.

Related

Related on the topropay platform