Web payment systems

Web payment systems — one API in front of every web checkout.

topropay's unified web payment API sits across every connected acquirer, PSP and method. Cards, wallets, bank rails, BNPL and (via partner gateways) crypto all run behind one REST surface. Routing, cascade, vault and reconciliation come built in, so a web payment gateway feels like infrastructure, not a vendor.

Book an API walkthrough Read the API docs
request.http
  1. POST /v1/payments
  2. Host api.topropay.com
  3. Auth Bearer sk_live_•••
  4. {
  5. amount 18900
  6. currency EUR
  7. method card
  8. vault_token vt_9421
  9. routing approval-weighted
  10. }
response.json
  1. 200 OK
  2. {
  3. id pay_4f8a
  4. status authorised
  5. acquirer_id acq_eu_03
  6. route_score 0.84
  7. ms 184
  8. }
One POST. Routed across many. Returned in under 200ms.
REST
JSON-over-HTTPS unified API
SDKs
Web · iOS · Android · server
Webhooks
signed, replay-safe events
1 ledger
across every method

Key benefits

Why orchestrated web payment solutions win on every axis

Four outcomes show up again and again once the orchestration layer sits behind a web checkout. A single direct gateway rarely matches them.

  1. 01

    One web payment API in front of every connected provider

    The merchant integrates against a single REST surface. The platform fans authorisations out across the connected acquirer, PSP and method portfolio — the merchant doesn't write per-provider integrations or maintain per-provider webhook handlers.

  2. 02

    Routing and cascade on every authorisation

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

  3. 03

    Vault tokenisation, PCI Level 1, by default

    Card data captures into the platform's vault before it ever touches the merchant's origin. Refunds, captures, retries and recurring all run on vault tokens — the merchant inherits the service-provider posture rather than carrying it themselves.

  4. 04

    One reconciliation feed across every web rail

    Settlements, fees, refunds and chargebacks across every connected provider normalise into one ledger keyed off vault tokens. The merchant's finance team closes the month from a single export instead of a stack of acquirer-specific files.

How it works

From a merchant-side POST to a ledger row in five stages

Here is what happens between a single authorise call and the line finance closes the month against. Five stages, and about one round trip per authorisation.

  1. REQUEST

    Merchant fires a single POST

    From the merchant's web checkout: one authorise call with amount, currency, method and either a vault token (returning shopper) or capture data (new shopper).

  2. ROUTE

    Routing engine scores the request

    BIN, scheme, currency, country pair and risk signals decide which connected acquirer runs the authorisation. Decision in under 200ms.

  3. AUTH

    Authorisation runs through the chosen route

    If the chosen acquirer returns a soft decline, the cascade rotates to the next ranked route inside the same request. The merchant gets one final result.

  4. EVENT

    Signed webhook fires

    A signed event with normalised fields lands on the merchant's webhook URL: authorised / declined / captured / refunded / disputed. Replay-safe with idempotency keys.

  5. LEDGER

    Receipt rolls into the unified ledger

    The authorisation, settlement and any fee adjustment appear in the same normalised export as every other method — daily, signed, audit-friendly.

Main use cases

Where web payment processing earns its keep

Six merchant shapes that share the same web payment API but stress it differently — the platform is the same; the policy on top varies.

  • 01

    Online retail and DTC

    Drop-in payment page or embedded SDK on the merchant's checkout; methods per market; routing across every connected acquirer; one ledger.

  • 02

    SaaS and subscriptions

    Vault-token-driven renewals, smart retries and account-updater wiring keep recurring revenue alive across card re-issuance — through the same web API.

  • 03

    Marketplaces and platforms

    Split payments, per-seller payouts and per-tenant reporting on the same orchestration; the platform reconciles in one feed.

  • 04

    PSPs and ISVs

    Reseller-side white-labelling and API access let a PSP brand the surface per merchant; the back-end orchestration is shared across the customer base.

  • 05

    B2B invoicing and trade

    Web payment processing for invoice-driven flows — cards, bank rails and (where treasury wants it) stablecoins via partner gateways on the same API.

  • 06

    Travel, ticketing and high-ticket

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

Model comparison

Single-provider web payment gateway vs orchestrated web payment systems

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.

Dimension Single-provider gateway topropay orchestration
Integration shape One acquirer's API, with their SDK and their webhooks One REST API across every acquirer the platform connects to, with one SDK family and one webhook stream
Method coverage Whatever that acquirer underwrites Cards, wallets, bank rails, BNPL and (via partner gateways) crypto under one API
Routing Static — every authorisation runs through that one acquirer Per-transaction scoring across the connected portfolio with cascade on soft decline
Reconciliation One settlement file from one acquirer Normalised ledger across every connected acquirer, signed daily exports
Onboarding Direct underwriting per acquirer Sub-merchant onboarding once, then platform-side relationships with several acquirers in parallel
Resilience Outage at the acquirer = outage at your checkout Routing engine moves traffic around the outage; the checkout stays available

Platform features

Capabilities behind a payment gateway web service

What the platform actually ships for web payment processing — from the API surface up to the operator portal.

  • Unified web payment API

    JSON-over-HTTPS REST surface with idempotency, predictable error model and OpenAPI specs.

  • Web payment gateway services

    Drop-in hosted checkout, hosted fields and low-level SDK — three surfaces, 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; retry-engine for renewal traffic.

  • PCI DSS Level 1 vault

    Capture, store and reuse PAN data as vault tokens; merchant origin never touches sensitive data.

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

  • Signed webhooks

    Replay-safe webhook delivery with HMAC signatures; per-event subscription; sandbox parity.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks normalised into a single ledger; daily exports.

  • Operator portal

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

  • Sandbox parity

    Per-environment sandbox that behaves like production, including routing and cascade scenarios.

  • Audit & event log

    Signed event log of every authorisation, refund, dispute and operator action — surfaceable for compliance and audit.

Trust & compliance

Compliance posture for a web payment API

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.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approvals high in Europe without skipping compliance.
Signed events
Webhook events HMAC-signed with rotation; replay-safe with idempotency keys; SIEM-friendly.
Data residency
Regional data-residency options for merchants under regulators that require it.
Audit posture
Operator actions, cancel events and refund events logged with actor identity, reason code and timestamp.
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

One web payment API. Every method, every market.

A 30-minute API walkthrough covers the endpoints relevant for your traffic shape, the routing policy that fits, the SDK family, and a sandbox to test against before any commercial commitment.

Book an API walkthrough Read the API docs

Frequently asked

Buyer questions about web payment systems on topropay

Questions buyers ask before committing — covering integration shape, API contract, merchant-account boundaries and the operational shape of the platform.

  1. 01

    What does topropay mean by web payment systems?

    Web payment systems on topropay is the umbrella for everything that authorises, captures, refunds and reconciles a payment initiated from a web surface — the unified REST API, the hosted and embedded checkout surfaces, the routing engine, the vault and the reconciliation feed. The merchant treats it as one system; the platform fans it out across the connected provider portfolio underneath.

  2. 02

    How does the web payment gateway behave inside the unified API?

    The web payment gateway behaviour — authorise, capture, refund, partial refund, void, dispute — runs through the same REST surface as every other rail. From your code, you call one endpoint; the platform picks the acquirer per transaction. The gateway is logically 'one' from your perspective and 'many' from the routing engine's.

  3. 03

    What web payment solutions are typically the right fit for a new merchant?

    Web payment solutions for a new merchant usually start with the hosted page (fastest to live, minimal PCI scope) and grow toward embedded hosted fields or the low-level SDK as the team needs more control over the checkout surface. Method mix and routing policy are dashboard configuration in all three.

  4. 04

    What does web payment processing look like at scale?

    Web payment processing at scale runs server-to-server through the platform's API: vault tokens replace PAN data, network tokens carry across card re-issuance, the routing engine scores every authorisation, cascade absorbs soft declines, and signed webhooks fire per state change. The merchant doesn't operate per-provider plumbing; the platform does.

  5. 05

    How is the web payment API structured?

    The web payment API is JSON-over-HTTPS, REST with explicit verbs (POST for create, GET for fetch, DELETE for cancel where applicable), idempotency keys on mutation endpoints, signed webhooks for events, and OpenAPI specs for SDK generation. Predictable error model, no surprise rate-limit headers, sandbox parity for every endpoint.

  6. 06

    Is there an online web payment system shape for very small merchants?

    Yes — an online web payment system shape for a very small merchant is usually the hosted page on a redirect, configured from the dashboard, with one webhook handler on the merchant side. No engineering team required to maintain it; the platform absorbs the per-provider work.

  7. 07

    What kind of web payment software primitives does the platform expose for an in-house build?

    Web payment software primitives include the vault, the routing engine, the cascade behaviour, network-token wiring, scheme-updater hooks, 3DS / SCA orchestration, the webhook signer / verifier, the operator portal API and the reconciliation feed. Each primitive is callable independently for merchants who want to build their own surface on top.

  8. 08

    How do web payment gateway services on topropay differ from a single-provider gateway?

    Web payment gateway services on topropay are a layer above the underlying gateways — one API surface across many, with routing, vault and reconciliation built in. A single-provider gateway exposes its own API and the merchant takes whatever appetite, rate card and uptime that provider ships. The orchestration model trades a slightly larger up-front integration for years of optionality.

  9. 09

    Do I still need a web site merchant account if I integrate with topropay?

    A web site merchant account is one of two valid paths: (a) merchant holds a direct merchant account with each underlying acquirer — topropay sits in front as the orchestration layer; (b) merchant integrates as a sub-merchant on the platform's acquiring contracts and skips the direct merchant-account step. Both work; the right choice depends on volume, vertical and contractual preference.

  10. 10

    Is the integration shape a payment gateway web service or something else?

    It is a payment gateway web service in the SOAP / REST-API sense — the integration is HTTPS calls against a stable API surface, with documented contracts and SDKs. The 'web service' framing is correct; we use REST + JSON rather than SOAP for the public API, with OpenAPI specs powering the SDK family.

  11. 11

    How does the platform handle high-traffic spikes on a web payment system?

    High-traffic spikes on a web payment system absorb cleanly: the routing engine spreads load across the connected acquirer portfolio, the cascade engine rotates around any provider that degrades, and platform-side horizontal capacity is sized to handle peaks. Merchants don't need to provision per-provider capacity buffers individually.

  12. 12

    Where does the web payment API stop and merchant-side code start?

    The web payment API stops at the authorisation, capture, refund, dispute and reporting boundary. Merchant-side code handles the checkout UI (if not using the hosted page), the order ledger, the customer record and any vertical-specific business logic. The API never assumes anything about the merchant's commerce platform; it just authorises payments.

  13. 13

    Can web payment processing be combined with offline / in-store flows?

    Yes — the same API powers web, mobile and in-store flows. An in-store till or kiosk uses the same authorise endpoint; the only difference is the entry mode (CIT vs MIT) flagged on the request. Settlement and reconciliation share one feed across surfaces.

  14. 14

    How do I migrate from a single-provider web payment system to topropay?

    Migrations usually run in three stages: (1) integrate the unified API in parallel with the existing provider, (2) shift a share of traffic to topropay and measure the routing uplift, (3) absorb the remaining volume on a schedule the engineering and finance teams agree on. There's no Big Bang cut-over requirement; existing acquirer contracts can stay in place.

Related

Related on the topropay platform