One layer above the providers

Payment gateway providers — consolidated behind one unified API.

topropay sits one layer above traditional payment gateway providers. The merchant integrates one API; behind the scenes a panel of connected providers competes for each authorisation, soft declines cascade across the panel, and finance reads one reconciliation feed.

Book a coverage review Read the API docs
EU acq UK acq US acq AU acq APAC LATAM ACH Crypto topropay one API
One API · many connected providers · routed per authorisation.
60+
connected gateway providers in the panel
300+
payment methods reachable globally
40+
supported markets across EU, UK, APAC and LATAM
1 API
in front of every connected provider
1 ledger
across every gateway settlement

Aggregator vs single provider

How a panel of online payment gateway providers compares to one

Six axes that tend to flip between integrating one payment gateway provider directly and integrating topropay as the orchestration layer.

Axis Single gateway provider topropay panel
API surface One API per gateway provider One API across every connected provider
Approval rate Locked to one acquirer's BIN routing Per-transaction routing across the panel; soft-decline cascade inside the same auth
Geographic coverage Per-region gateway provider + per-region integration EU, UK, APAC, LATAM and US connectivity unified under one contract
Reconciliation One settlement feed per gateway provider One normalised ledger across every connected provider
PCI scope Per-gateway PCI integration PCI DSS Level 1 vault inherited regardless of which connected provider clears the auth
Dispute queue Per-gateway dispute portal One unified dispute queue across the panel; evidence-pack templates per vertical

Key benefits

Why a connected panel beats picking one of the best payment gateway providers

Four properties that show up the moment a merchant stops trying to pick one perfect payment gateway provider and starts routing across a panel.

One integration, every provider

Add or swap a connected gateway provider as a routing-policy change instead of a re-integration. The merchant's checkout code never changes.

Routing tuned to your BIN mix

Per-BIN, per-currency and per-country scoring picks the highest-EV provider for each authorisation. Soft declines cascade to the next ranked lane inside the same auth.

Geo coverage without per-region projects

US, Australian, EU and APAC gateway providers all sit behind the same unified API. Expanding into a new market is a connection, not an integration project.

One ledger across the panel

Settlements, interchange, fees, refunds and chargebacks from every connected provider normalise into one reconciliation feed for finance.

How a payment gateway providers list runs underneath

From connected panel to settled authorisation in four steps

What happens between a connected provider being added to the panel and a settled row in the merchant's reconciliation feed.

  1. 01

    Connect provider relationships

    topropay's connected provider panel is enabled per merchant; relationships sit with licensed acquirers in each target geography.

  2. 02

    Define a routing policy

    Per-BIN, per-currency and per-country routing rules rank the connected providers for each authorisation; weights are dashboard-editable.

  3. 03

    Route, cascade & retry

    Each authorisation runs through the top-ranked provider; soft declines cascade to the next ranked provider inside the same auth without surfacing to the buyer.

  4. 04

    Reconcile in one feed

    Settlement files from every connected provider normalise into one ledger; daily exports tagged by provider, scheme, currency and routing policy.

Regional coverage

Connected gateway providers across US, Australia, EU, UK and APAC

Geographic coverage is connection-driven, not integration-driven. Three regional slices to anchor the panel.

  • United States

    payment gateway providers in usa — card, ACH and wallet under one API

    US-side connectivity covers Visa, Mastercard, Amex, Discover, ACH (NACHA-compliant), Apple Pay, Google Pay and Click to Pay through licensed US acquirers. us payment gateway providers integrate behind the same unified API as European and APAC providers; the merchant doesn't run a separate US-only integration.

  • Australia

    australian payment gateway providers and APAC connectivity

    Australian connectivity covers card scheme acceptance plus PayID and OSKO (NPP) through licensed AU partner acquirers. New Zealand, Singapore and broader APAC connectivity sits behind the same API; the routing engine picks the optimal lane per BIN.

  • Europe, UK & LATAM

    EU, UK and LATAM gateway providers on the same panel

    EU and UK card connectivity, SEPA Direct Debit, iDEAL, Bancontact, Bacs and Open Banking sit alongside LATAM rails (PIX, Boleto, OXXO via partners). The same routing engine and the same reconciliation feed apply across regions.

Platform features

Capabilities shared across every connected gateway provider

Twelve capabilities the platform ships once and reuses across every connected provider — the primitives that make the panel feel like one product.

  • Unified API across providers One REST contract for card, ACH, SEPA, wallet, BNPL and crypto provider connectivity.
  • Hosted, embedded & SDK surfaces Three integration shapes share the same back-end — picked per merchant's PCI and UI constraints.
  • Smart routing engine Per-transaction scoring on BIN, scheme, currency, country pair and risk across the connected panel.
  • Cascade & retry Soft declines cascade to the next ranked provider inside the same authorisation; nothing leaks back to the buyer.
  • PCI DSS Level 1 vault Card data captures into the platform vault before any connected provider sees it; PAN never lands in merchant systems.
  • Network tokens & updaters Network tokens (VTS, MDES) by default for card; scheme updaters keep saved credentials alive across re-issuance.
  • 3DS2 / SCA orchestration Selective EMV 3DS2 challenges per authorisation — PSD2-compliant in Europe without breaking conversion.
  • Unified dispute queue One queue across providers; evidence-pack templates per vertical; automated representment for select scheme types.
  • Risk & fraud controls Velocity rules, list management and partner-agnostic fraud-engine connectors layered on top of routing.
  • One reconciliation feed Settlements, fees, refunds and chargebacks across every connected provider normalised into one ledger.
  • Webhooks & accounting connectors Signed lifecycle events; connectors for popular ERPs and accounting systems.
  • Per-merchant routing policies Independent routing weights per merchant or per merchant-group; resellers configure their downstream merchants individually.

Trust & compliance

Compliance posture across the connected provider panel

One audited environment underpins the orchestration layer; per-provider scheme programmes surface in the dashboard so the merchant sees where every connected provider stands.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every connected provider.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per connected provider; routing weights can rotate around at-risk lanes.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the SCA bar.
Bank-rail mandate posture
NACHA authorisations for ACH, SEPA mandate IDs for SEPA Direct Debit; captured and retained per scheme rules.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and country mix.
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 which connected provider clears the auth.

Ready to consolidate

Replace one gateway provider with a whole panel of them.

A 30-minute coverage review covers the connected providers relevant to your geographies and BIN mix, routing weights tuned to your traffic, and a sandbox to test against before any commercial commitment.

Book a coverage review Read the API docs

Frequently asked

Buyer questions about payment gateway providers on topropay

Definitions, panel-selection mechanics, regional coverage, override controls and the practicalities of running on a panel instead of a single provider.

  1. 01

    What does topropay actually do compared with traditional payment gateway providers?

    Traditional payment gateway providers are point connections — one API per acquirer relationship. topropay sits one layer above: it connects to many gateway providers and acquirers, exposes one unified API in front of them, and routes each authorisation across the panel. The merchant integrates once; the panel can grow or shrink behind the scenes without re-integration.

  2. 02

    Is topropay a payment gateway, or a layer on top of payment gateway providers?

    topropay is the orchestration layer on top of the providers. It owns the unified API, the PCI L1 vault, the routing engine, the unified dispute queue and the reconciliation feed. The acquiring relationships and the per-region licences sit with licensed connected gateway providers and acquirers.

  3. 03

    How are online payment gateway providers selected for the connected panel?

    Online payment gateway providers are selected for the connected panel based on geographic coverage, scheme support, regulatory licensing, dispute / chargeback posture and operational stability. Connections are vetted before they're available to merchants for routing; underperforming connections can be down-weighted in the routing engine.

  4. 04

    How does the platform handle australian payment gateway providers?

    Australian payment gateway providers integrate into the connected panel through licensed AU partner acquirers. Card scheme acceptance plus PayID and OSKO (NPP) flows are exposed through the same unified API. Merchants targeting Australian buyers don't run a separate AU integration — the routing engine picks the AU-optimal lane per authorisation.

  5. 05

    Who are the best payment gateway providers for a merchant evaluating options today?

    The 'best payment gateway providers' for any given merchant depends on geography, BIN mix, vertical, dispute posture and existing tech stack. Rather than locking the merchant to a single provider, topropay's panel approach gives the merchant exposure to multiple connected providers behind one integration; the routing engine picks the highest-EV provider per authorisation rather than the merchant having to pre-commit.

  6. 06

    What about payment gateway providers in usa specifically?

    Payment gateway providers in usa connectivity covers Visa, Mastercard, Amex, Discover, ACH (NACHA-compliant), Apple Pay, Google Pay and Click to Pay through licensed US acquirers. US BIN routing follows the same engine as the rest of the world — soft declines cascade to the next ranked US lane inside the same authorisation.

  7. 07

    Are us payment gateway providers integrated differently from EU ones?

    No. US payment gateway providers and EU payment gateway providers sit behind the same unified API. The routing engine respects scheme-specific rules per region (US ACH NACHA, EU SEPA mandates, EU PSD2 SCA), but the API surface the merchant integrates against is the same regardless of region.

  8. 08

    Is there a payment gateway providers list we can share with stakeholders?

    The full payment gateway providers list on the connected panel is shared under NDA during onboarding. Publishing a public list isn't useful — the panel changes as new providers are added or weights rotated. What stakeholders typically care about — geographic coverage, scheme support, scheme-programme posture per acquirer — is shared in writing as part of underwriting.

  9. 09

    How does the platform decide which connected provider to route a given authorisation to?

    The routing engine scores every connected provider on BIN, scheme, currency, country pair, risk signals (device fingerprint, velocity, list hits) and dispute-programme position. The top-ranked provider receives the authorisation; if it returns a soft decline, the next ranked provider receives the retry inside the same authorisation. Hard declines (insufficient funds, blocked card) don't cascade.

  10. 10

    Can the merchant override the routing engine?

    Yes. Per-merchant routing policies in the dashboard let the merchant pin specific BIN ranges to specific providers, weight one provider higher for certain currencies, or exclude providers for certain countries. Manual overrides coexist with the scoring engine — the policy editor surfaces the resulting routing behaviour for review.

  11. 11

    What happens if a connected provider has an outage?

    If a connected provider has an outage, its score in the routing engine drops automatically based on real-time error rates; authorisations route to the next ranked provider. Manual provider-disable in the dashboard takes the lane offline immediately for any merchant who wants to force the bypass.

  12. 12

    Can resellers / PSPs offer the connected panel to their downstream merchants?

    Yes. PSPs and resellers inherit the connected provider panel and configure independent routing policies per downstream merchant. The PSP keeps the merchant relationship, contracting and pricing; the platform handles the per-merchant provider-side message exchange.

  13. 13

    How does the platform compare to an in-house provider-selection layer?

    An in-house provider-selection layer means owning the integration with every gateway provider, the BIN-based routing logic, the scheme-rule updates, the dispute aggregation and the reconciliation normalisation. topropay's panel approach delivers the same outcome (per-transaction provider choice across many connections) without the merchant maintaining a per-provider integration project.

  14. 14

    Are the connected providers visible to the cardholder?

    No. The cardholder sees the merchant's branding throughout. Connected provider identities surface only on settlement statements and statement descriptors (per scheme rules) and on dispute documentation. The checkout, receipts and emails carry the merchant's brand.

  15. 15

    What's the typical timeline to move from a single payment gateway provider to topropay?

    Most merchants move from a single payment gateway provider to topropay in 2–6 weeks, including KYB, sandbox testing and a phased traffic cutover. Many run topropay in parallel with their existing provider during the cutover period so that approval, cost and dispute outcomes can be measured per-provider before absorbing the rest of the volume.

Related

Related on the topropay platform