Payment gateway for ecommerce

Payment gateway for ecommerce — one API, every method, every market.

topropay puts every connected acquirer, PSP and method behind one unified API. Cards, wallets, bank rails, BNPL and (via partner gateways) crypto — surfaced on the same ecommerce checkout, routed per transaction, reconciled into one ledger.

Book a checkout review Read the API docs
CART Pay €189 GATEWAY Acquirer A · BIN 4012• Acquirer B · BIN 5410• Acquirer C · BIN 4170• Acquirer D · BIN 5311• routed in 184ms BANK settled
Cart → routed gateway → one settlement.
Drop-in
hosted checkout in days
300+
methods reachable
<200ms
routing decision
1 ledger
across every connected provider

Key benefits

Why an orchestrated ecommerce gateway wins

Four outcomes that show up consistently once the ecommerce gateway is wired through the orchestration layer rather than per-provider plumbing.

  1. 01

    One payment gateway for ecommerce — not five

    Most ecommerce stacks accumulate per-provider integrations: one gateway for cards, one for BNPL, one for local APMs, one for crypto, one for ACH. topropay collapses the lot behind a single unified API — the merchant integrates once, the routing engine fans authorisations out across the connected portfolio.

  2. 02

    Surface the right method per shopper

    The checkout re-orders the visible method list per shopper's market, currency and device — iDEAL first for a Dutch buyer, PIX first for a Brazilian buyer, Apple Pay first on iOS, cards everywhere as the fallback. Method availability per market is dashboard-configurable.

  3. 03

    Routing, cascade and chargeback tooling included

    Every authorisation runs through the routing engine; soft declines cascade to the next ranked acquirer inside the same request. Chargeback-aware policies and dispute-evidence templates per vertical sit on top — without a separate fraud / chargeback tool to bolt on.

  4. 04

    One reconciliation feed across every method

    Settlements, fees, refunds and chargebacks from every connected provider normalise into one ledger keyed off vault tokens. Finance closes the month from one export rather than a CSV-per-provider merge — and the ledger tags every row with the method, acquirer and routing policy that ran it.

How it works

From integration to live in five stages

Five concrete stages between the first SDK call and a daily reconciliation export finance can close the month against. Most merchants reach the live stage in days.

  1. 01

    Drop in the gateway surface

    Pick the integration shape — hosted page (redirect or iframe), embedded hosted fields, or low-level SDK — and drop it into the merchant's checkout. Same back-end for all three.

  2. 02

    Switch on methods and routing

    Method availability per market, routing policy (approval-, cost- or composite-weighted) and risk thresholds are dashboard-level. Engineering integrates the API once; ops tunes the policies afterwards.

  3. 03

    Authorise across the connected provider portfolio

    Every authorisation runs through the routing engine. Soft declines cascade to the next ranked acquirer inside the same request — the shopper sees one clean result, not a per-provider retry loop.

  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 surface. The merchant doesn't deal with PAN data; the platform handles the PCI scope.

  5. 05

    Reconcile from one daily export

    Settlements, fees, refunds and chargebacks normalise into one ledger keyed off vault tokens — daily exports drop into ERP or warehouse with per-method, per-acquirer and per-policy tags.

Main use cases

Where the gateway earns its keep

Six merchant shapes that share the same orchestration layer but stress it differently — DTC, SaaS, marketplaces, travel, crypto-accepting and PSPs.

  • DTC

    Direct-to-consumer brands

    An ecommerce website payment gateway that surfaces local methods per market without per-provider work on the merchant side. The result: a checkout that converts in every market the brand sells in, without a stack of bespoke per-region plug-ins.

  • SaaS

    Subscriptions and recurring billing

    Network-token-driven recurring, smart retries, account updaters and a customer-portal cancel flow — through the same payment gateway for ecommerce site that captures the initial sign-up. Renewal recovery becomes a configuration choice.

  • Marketplace

    Marketplaces and platforms

    Split payments, per-seller payouts and per-tenant reporting on one orchestration layer. The marketplace doesn't need to become a registered facilitator itself — the underlying acquirer relationships sit with the platform.

  • Travel

    Travel and ticketing

    Staged captures, multi-currency capture, partial refunds and dispute analytics on a single API. High-ticket bookings benefit disproportionately because per-acquirer chargeback timelines and 3DS / SCA flows are abstracted into one consistent contract.

  • Crypto

    Crypto payment gateway for ecommerce

    Stablecoins, majors and L2 networks surfaced through licensed partner crypto gateways — exposed inside the same unified API and reconciled into the same ledger as cards. Optional conversion-on-receipt keeps treasury fiat-only when needed.

  • 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.

Model comparison

Single provider vs orchestrated

Two valid models. The single-provider gateway is the simpler buy; the orchestrated model trades a slightly larger up-front integration for years of optionality across providers.

Dimension Single-provider gateway topropay orchestration
Integration shape One gateway per method (cards / BNPL / APMs / crypto) — multiple SDKs and webhook handlers One unified API in front of every method, with one SDK family and one webhook stream
Method coverage Whatever each provider underwrites individually Cards, wallets, bank rails (SEPA, Bacs, iDEAL, PIX, OXXO, PayID), BNPL and (via partner gateways) crypto on one contract
Routing Static — each method runs through its single provider, regardless of BIN / scheme / market Per-transaction scoring across the connected acquirer portfolio with cascade on soft decline
Reconciliation One settlement file per provider — merged manually for finance close Normalised ledger across every connected provider, signed daily exports, method-tagged rows
Onboarding Direct underwriting per provider Sub-merchant onboarding once, then platform-side relationships with several providers in parallel
Resilience Outage at one provider = outage on that method Routing engine moves traffic around the outage; affected methods stay available where alternatives exist

Platform features

Capabilities behind the gateway

What the platform actually ships for an ecommerce gateway — from the API surface up to the operator portal and reconciliation feed.

  • Unified ecommerce gateway API

    JSON-over-HTTPS REST surface with idempotency, signed webhooks and OpenAPI specs; SDKs for web, mobile and server.

  • Hosted, embedded and SDK surfaces

    Drop-in hosted checkout for fast launch, hosted fields for inline integrations, low-level SDK for full UI control.

  • Smart routing engine

    Per-transaction scoring on BIN, scheme, currency, country pair, risk and merchant policy.

  • 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 our vault before it touches any underlying provider; refunds and recurring run on vault tokens.

  • 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 case types.

  • Crypto via partner gateways

    Crypto rails delivered through licensed partner gateways — same API, same reconciliation feed as fiat.

  • 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 at scale

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 across the connected acquirer panel.
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 ship

One payment gateway for ecommerce. Every method, every market.

A 30-minute checkout review walks through the method mix relevant to your traffic, the routing policy that fits, the SDK that matches your stack, and a sandbox to test against before any commercial commitment.

Book a checkout review Read the API docs

Frequently asked

Buyer questions about payment gateway ecommerce on topropay

Questions buyers ask before they commit — covering integration shape, crypto, BNPL, ACH/SEPA, dispute handling, migrations and sandbox parity.

  1. 01

    What does topropay mean by payment gateway for ecommerce?

    Payment gateway for ecommerce on topropay is the orchestration layer that authorises, captures, refunds and reconciles every payment on an ecommerce checkout — from a single unified API. The merchant integrates once; the platform routes across the connected acquirer, PSP and method portfolio behind it.

  2. 02

    How is payment gateway ecommerce on topropay different from a single-provider gateway?

    A single-provider payment gateway ecommerce setup runs every authorisation through one acquirer's appetite, rate card and uptime story. topropay's orchestrated equivalent runs each authorisation through the route most likely to clear at the lowest landed cost across several connected providers — and cascades soft declines that a single provider would lose.

  3. 03

    How does a payment gateway for ecommerce site integration usually look end-to-end?

    A payment gateway for ecommerce site integration on topropay is typically: install the server SDK (or call the REST API directly), drop in the hosted checkout or embedded SDK, configure methods and routing from the dashboard, wire one webhook handler. Hosted-checkout flows ship in days; fully embedded builds take weeks.

  4. 04

    What does a payment gateway for ecommerce website integration look like for a small team?

    Payment gateway for ecommerce website integration for a small team usually means the hosted page on a redirect — minimal PCI scope on the merchant side, one webhook handler, and dashboard-level configuration for methods and routing. Most ecommerce platforms (Shopify-like, WooCommerce-like, custom stacks) can wire it in hours rather than days.

  5. 05

    Is there a crypto payment gateway for ecommerce inside the same API?

    Yes. Crypto payment gateway for ecommerce flows surface through the same unified API as cards — stablecoins, majors and L2 networks via licensed partner crypto gateways. The merchant adds 'method: crypto' to the authorise call; the rest of the lifecycle (webhooks, refunds, reconciliation) is identical to card.

  6. 06

    What's typically the best payment gateway for ecommerce website at scale?

    Best payment gateway for ecommerce website at scale is the one that fits the merchant's actual traffic mix — geography, method mix, ticket size, vertical. For multi-market merchants with cards plus local APMs (iDEAL in NL, PIX in BR, BLIK in PL), an orchestration-layer gateway like topropay typically beats picking a single provider's gateway, because it removes the per-provider-per-method work the single-gateway model accumulates.

  7. 07

    How is best online payment gateway for ecommerce evaluated in practice?

    Best online payment gateway for ecommerce is usually evaluated on five axes: approval rate, landed cost, method coverage per market, integration ergonomics and reconciliation ergonomics. topropay's orchestration model lets merchants A/B those axes on their own traffic rather than choosing a provider on a sales pitch.

  8. 08

    Can a merchant migrate from an existing ecommerce gateway without rebuilding the checkout?

    Yes. Migrations usually run in three stages: integrate topropay in parallel with the existing gateway, shift a share of traffic to topropay and measure the routing uplift, absorb the remaining volume on a schedule the engineering and finance teams agree on. Existing acquirer contracts can stay in place; the orchestration sits in front.

  9. 09

    Does the platform handle method-specific surfaces like iDEAL bank-selection or PIX QR rendering?

    Yes. iDEAL bank-selection, PIX QR rendering, Apple Pay / Google Pay pay-sheets, BNPL provider redirects — all handled by the hosted checkout out of the box. The merchant doesn't render those surfaces; the platform does. The same is true on the embedded SDK path for merchants who want UI control around the form.

  10. 10

    How is the unified ecommerce gateway priced?

    Pricing on the unified ecommerce gateway is 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 on the invoice.

  11. 11

    What does the integration look like for headless / API-first ecommerce stacks?

    Headless / API-first ecommerce stacks integrate against the REST API directly. The merchant calls /v1/payments to authorise, captures via /v1/payments/:id/capture, refunds via the refund endpoint, and receives signed webhooks for every state change. The hosted checkout is optional — many headless stacks build their own surface and use the API as pure infrastructure.

  12. 12

    Does the platform support BNPL inside the same ecommerce gateway?

    Yes — BNPL providers (Klarna, Afterpay, Affirm, Clearpay) plug into the same authorise endpoint as card. The hosted checkout surfaces them as method tiles next to the card form; per-market availability is dashboard-configurable. Settlement and refund flows match the card-side shape.

  13. 13

    Can a merchant accept ACH or SEPA Direct Debit through the same payment gateway for ecommerce?

    Yes. ACH (US) and SEPA Direct Debit (EU) plug into the same authorise endpoint as card and BNPL. NACHA mandate evidence and SEPA mandate IDs are captured and retained per scheme rules; recurring flows on bank rails share the same recurring engine as card-on-file recurring.

  14. 14

    How does the dispute and chargeback queue work across providers?

    The unified dispute and chargeback queue surfaces every case across every connected provider in one place. Evidence-pack templates per vertical accelerate response; automated representment is supported for select scheme types. The merchant doesn't open a different console per provider for chargebacks.

  15. 15

    Is the sandbox close enough to production to build the full integration against?

    Yes. The sandbox covers every production endpoint, signed webhooks (with rotating test secrets), and deterministic helpers for triggering specific outcomes — soft / hard declines, 3DS challenge / frictionless, iDEAL bank-confirmation success / failure, PIX bank-credit timing, ACH R-code rejections, refund-flow scenarios and chargeback simulations. Merchants build the full integration against the sandbox before any commercial commitment.

Related

Related on the topropay platform