Gateway services

Gateway services — every primitive, one API.

topropay's gateway services cover every primitive a payment gateway exposes — authorise, capture, refund, dispute, vault, reconciliation — plus orchestration on top. Cards, ACH, crypto, BNPL and bank rails behind one REST surface.

Book a services review Read the API docs
topropay · gateway services
  • POST/v1/paymentsauthorise
  • POST/v1/payments/:id/capturecapture
  • POST/v1/payments/:id/refundrefund
  • POST/v1/payments/:id/voidvoid
  • POST/v1/vault/tokensvault
  • GET/v1/disputesdispute
  • GET/v1/settlementsreconcile
7 primitives · one REST surface · signed webhooks
1 API
across every connected provider
PCI L1
vault from day one
<200ms
routing decision
1 ledger
across every method

Key benefits

Why orchestrated payment gateway services win over single-provider gateways

Four outcomes that show up consistently once gateway services run through an orchestration layer rather than a single provider's appetite.

  1. 01

    Every gateway-service primitive behind one API

    Authorise, capture, void, refund, partial-capture, multi-currency-capture, dispute response, chargeback evidence, vault tokenisation, network tokens, scheme account updaters — every primitive a payment gateway exposes, behind the same unified REST surface.

  2. 02

    Multi-provider routing instead of one provider's appetite

    Most gateway-services products tie you to one provider's underwriting, rate card and uptime story. topropay's gateway services run authorisations across the connected acquirer portfolio with cascade on soft decline — every provider's appetite available per transaction.

  3. 03

    Cards, ACH, crypto and BNPL on the same surface

    Card-only gateway services force a parallel integration for ACH, another for crypto, another for BNPL. topropay's gateway services surface all of them through the same authorise endpoint — different `method` field, same lifecycle and webhook event model.

  4. 04

    One reconciliation feed across every service

    Settlements, fees, refunds and chargebacks from every connected provider normalise into one ledger keyed off vault tokens. Finance closes the month from a single export; the ledger tags every row with the gateway service, method and routing policy that ran it.

How it works

From SDK install to a daily reconciliation export in five stages

Five concrete stages between the first API call and a daily reconciliation export finance can close the month against.

  1. 01

    Drop in the gateway-services SDK

    Pick a server SDK (Node, Python, PHP, Ruby, Java, Go) or call the REST API directly. Sandbox keys, webhook URLs and the first authorise call typically take under an hour.

  2. 02

    Switch on the services and methods you need

    Card payment gateway services, ACH, crypto, BNPL and APMs are dashboard toggles. Routing policies (approval-, cost- or composite-weighted) and risk thresholds sit alongside the toggles.

  3. 03

    Authorise through the unified surface

    Every authorisation — card or otherwise — runs through the routing engine. Soft declines cascade to the next ranked acquirer inside the same request.

  4. 04

    Capture, refund and dispute on the same API

    Captures, partial captures, refunds and dispute responses all run against vault tokens through the same API. The merchant doesn't deal with PAN data; the platform handles the PCI scope.

  5. 05

    Reconcile from a single daily export

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

Main use cases

Where best payment gateway services earn their keep

Six merchant shapes that share the same gateway-services API but stress it differently — the platform is the same; the policy on top is what varies.

  • DTC

    Online retail and DTC

    Drop-in hosted checkout, embedded SDK or low-level API — every gateway-services primitive available behind one integration.

  • SaaS

    Subscriptions and SaaS

    Vault-token-driven recurring, smart retries and account updaters keep renewal revenue alive across card re-issuance.

  • Plat

    Marketplaces and platforms

    Sub-merchant onboarding, split payments and per-tenant reporting on one orchestration; per-seller analytics in the operator portal.

  • Travel

    Travel and ticketing

    Staged captures, multi-currency capture, dispute analytics and per-acquirer chargeback timelines on one API.

  • PSP

    PSPs and ISVs

    Reseller-side white-labelling lets PSPs brand the gateway-services surface per merchant; orchestration is shared.

  • Risk

    Licensed high-risk merchants

    Chargeback-aware routing across an acquirer subset tuned per vertical — same gateway-services API as mainstream merchants.

Statement descriptors

Avoid the generic 'gateway services webpayment charge' on cardholder statements

Cardholders who see an unfamiliar descriptor — "gateway services webpayment charge" and similar — often search for it before recognising the merchant. topropay encourages every merchant to configure a recognisable per-merchant descriptor so cardholders see the merchant name on their statement, not a generic gateway label.

Default (avoid) GATEWAY SERVICES WEBPAYMENT CHARGE

A generic provider-level descriptor. Triggers cardholder confusion, support volume and unnecessary chargebacks ("I don't recognise this charge").

Recommended YOURBRAND* ORDER 4F8A · yourbrand.com

A per-merchant descriptor with brand, order reference and a recognisable URL. Configured from the dashboard once; applies to every subsequent authorisation.

For cardholders who landed here from a 'what is this charge' search: see the FAQ below for the practical next steps.

Platform features

Capabilities shared across every gateway service

What the platform ships once and reuses across card, ACH, crypto, BNPL and facilitation — the primitives that make the catalogue feel like one product.

  • Authorise / capture / refund

    Predictable verbs against a stable REST surface; idempotency keys on every mutation.

  • Hosted, embedded, SDK surfaces

    Drop-in checkout, hosted fields, and low-level SDK — three integration shapes, one back-end.

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

  • PCI DSS Level 1 vault

    Card data captures into our vault before it touches any underlying provider.

  • Network tokens & updaters

    Network tokens by default; scheme updaters keep saved cards alive across re-issuance.

  • 3DS2 & SCA orchestration

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

  • Dispute & chargeback queue

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

  • Statement descriptors

    Configurable per-merchant statement descriptors so cardholders recognise the charge on their statement — and don't trigger 'what is this charge' searches.

  • Crypto via partner gateways

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

  • Unified reconciliation

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

  • Sandbox parity

    Sandbox that mirrors production — routing, cascade, 3DS, refund and chargeback scenarios.

Trust & compliance

Compliance posture across the gateway services

One audited environment underpins every service. Merchants inherit 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 service mix.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping the compliance bar.
Scheme programme tracking
Visa VDMP / VAMP and Mastercard ECP / EFMP thresholds tracked across the connected acquirer panel.
Signed webhooks
Replay-safe webhook delivery with HMAC signatures; SIEM-friendly out of the box.
Data residency
Regional data-residency options for merchants under regulators that require it.
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 integrate

Every gateway-services primitive on one API.

A 30-minute services review covers the primitives relevant to your stack, the routing policy that fits, the SDK that matches your back-end, and a sandbox to test against before any commercial commitment.

Book a services review Read the API docs

Frequently asked

Buyer questions about gateway services on topropay

Questions buyers (and the occasional confused cardholder) ask before they commit — covering integration shape, Mastercard / Visa flows, statement descriptors, BNPL, crypto, dispute handling and sandbox parity.

  1. 01

    What does topropay mean by gateway services?

    Gateway services on topropay is the umbrella for every primitive a payment gateway exposes — authorise, capture, refund, dispute, vault, reconciliation — plus the orchestration on top: smart routing, cascade, multi-provider settlement. The merchant integrates once; the platform handles the per-provider plumbing underneath.

  2. 02

    How are payment gateway services on topropay different from a single-provider gateway?

    A single-provider gateway exposes its own gateway services behind its own API. topropay's payment gateway services sit one layer above — every connected acquirer's gateway is reachable from the same unified API, with routing on every authorisation and one reconciliation feed across them.

  3. 03

    What does an online payment gateway services integration look like in practice?

    An online payment gateway services integration on topropay is typically: install the server SDK or call the REST surface, drop in the hosted checkout (or embed the 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

    Are crypto payment gateway services available inside the same surface?

    Yes. Crypto payment gateway services run through licensed partner crypto gateways and surface inside the same unified API as card and bank rails. The merchant adds 'method: crypto' to the authorise call; the lifecycle and reconciliation feed are identical to card.

  5. 05

    What's typically the best payment gateway services setup for a multi-method merchant?

    Best payment gateway services for a multi-method merchant is usually an orchestration-layer gateway like topropay — one integration covers cards, wallets, bank rails, BNPL and crypto, and the routing engine picks the right provider per authorisation rather than committing the merchant to one provider's appetite for every method.

  6. 06

    I'm a cardholder — what is the 'gateway services webpayment charge' on my statement?

    If you're a cardholder seeing a 'gateway services webpayment charge' on your bank statement and you don't recognise it, that's a generic descriptor used by some payment processors when the merchant hasn't configured a specific statement descriptor. The first step is to check recent online purchases (subscriptions in particular often appear with unfamiliar descriptors). If you can't identify it, contact your card issuer — they can usually trace the underlying merchant. On topropay, merchants are encouraged to configure recognisable per-merchant statement descriptors so cardholders don't see generic 'gateway services' lines on their statements.

  7. 07

    Does topropay support payment gateway services mastercard flows specifically?

    Payment gateway services mastercard flows — Mastercard authorisations through the platform — are supported on every connected acquirer that holds a Mastercard licence. Routing weights are tuned by BIN, scheme and country pair on real traffic; Mastercard-specific programme thresholds (ECP / EFMP) are tracked in the operator portal. The integration shape is identical to Visa or other schemes.

  8. 08

    What payment gateway services Visa flows are supported alongside Mastercard?

    Visa flows mirror the Mastercard shape — routing by BIN / scheme / country pair across Visa-licensed acquirers in the connected panel, with Visa-specific programme thresholds (VDMP / VAMP / VFMP) tracked. The merchant doesn't pick 'Visa gateway services' vs 'Mastercard gateway services' separately; the schemes share one API and one operator portal.

  9. 09

    How does the gateway-services surface handle BNPL and bank-rail methods?

    BNPL providers (Klarna, Afterpay, Affirm, Clearpay) and bank rails (SEPA, Bacs, iDEAL, PIX, OXXO, PayID, ACH) plug into the same authorise endpoint as card. The hosted checkout surfaces them as method tiles next to the card form; settlement and refund flows match the card-side shape.

  10. 10

    Is there a difference between hosted, embedded and SDK gateway-services surfaces?

    Hosted: redirect or iframe checkout — the platform renders the surface, the merchant integration is a session token plus a webhook handler. Embedded: hosted card-data fields rendered inline inside the merchant's own page (PCI SAQ A-EP). SDK: low-level primitives for merchants who want full UI control. All three back onto the same gateway-services API.

  11. 11

    How do gateway services handle multi-currency authorisations?

    Multi-currency authorisations are configured per merchant — settlement currency is a policy choice. Authorise in the buyer's local currency where the connected acquirer supports it; settle in the merchant's preferred currency with conversion handled by the acquirer or by the platform per policy. The merchant doesn't carry FX they didn't ask for.

  12. 12

    Can a merchant build their own gateway-services UI on top of the API?

    Yes. Merchants who want full UI control build against the REST API and the low-level SDK directly — the hosted checkout is optional. The same primitives (authorise, capture, refund, dispute) are available; the merchant takes on the UI and the PCI scope that comes with it.

  13. 13

    How is dispute handling structured inside the gateway-services queue?

    Disputes from every connected acquirer surface in one unified queue. Evidence-pack templates per vertical (subscription, travel, ticketing, etc.) accelerate response; automated representment is available for select scheme types. The merchant doesn't open a different console per acquirer for chargeback work.

  14. 14

    Are gateway-services sandbox flows representative of production?

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

  15. 15

    How are gateway services priced?

    Pricing is per-authorisation on top of underlying provider economics — no platform retainer, no per-environment fee, no minimum monthly. Interchange and scheme fees pass through where the underlying acquirer supports it; the platform's fee is a separate line on the invoice.

Related

Related on the topropay platform