Payment gateway, unified

An online payment gateway with one integration for every acquirer.

topropay is the gateway for payment processing that reaches dozens of acquiring banks, hundreds of methods and every major card scheme through a single API. Smart routing sends each transaction to the route most likely to approve, cascading failover keeps the sale alive on a soft decline, and one ledger reconciles it all — so you stop running a stack of point integrations and start running one payment gateway online.

Book a discovery call Read the API docs
POST /v1/payments 
$ curl https://api.topropay.com/v1/payments \
    -H "Authorization: Bearer $TOKEN" \
    -d amount=4900 -d currency=EUR \
    -d method=card -d token=tok_8Ka...

← 200 OK
{
  "id":      "pay_01HZ9F...",
  "status":  "approved",
  "acquirer":"acq_eu_3",
  "route":   "primary",
  "approval_score": 0.96,
  "auth_ms": 412
}
approved routed in 412 ms · 1 cascade reserved

The short version

What a unified payment gateway online does for your business

Most teams begin with one provider's payment gateway widget. Then they meet the limits the hard way: a scheme unsupported in a new market, a card type the gateway cannot route, a renewal that fails silently, or a regional acquirer that demands yet another integration. Each fix adds another contract, another dashboard and another stream of reports to reconcile.

topropay collapses that sprawl into one orchestration layer. A single integration gives you access to hundreds of methods and dozens of acquirers. For every transaction, a routing engine picks the path most likely to be approved at the lowest cost. You keep the providers and pricing you already have. You add new markets as configuration, not code. And every settlement reconciles in one place. The result is a checkout that converts better and a payments operation that is far simpler to run.

How it works

How to integrate payment gateway capacity into your stack

From signed contract to first live transaction, the path is short. You integrate once, then shape methods, markets and routing as configuration. These are the four phases of a typical rollout — most of the work after the first connection is in the dashboard rather than in code.

  1. Connect once

    Drop the unified API into your checkout, app or backend. One integration replaces the wiring you would otherwise repeat for every acquirer, wallet and local rail — and it is the only code commit needed to integrate payment gateway capacity end to end.

  2. Configure methods and markets

    Choose the payment methods you want available per country from the dashboard. Cards, wallets, SEPA, open banking and local schemes appear in your checkout without separate provider builds.

  3. Set the routing policy

    Tell the gateway what to optimise for — approval rate, processing cost, currency or scheme preference. Cascading retries on soft declines are on by default and tunable per rule.

  4. Go live and reconcile

    Push real traffic, watch authorisations in real time, and let every settlement land in one ledger. Refunds, disputes and reporting are handled from the same console — no provider-by-provider reconciliation.

Gateway at a glance

1API
One unified gateway connection covers cards, wallets and account-to-account rails.
300+methods
Local and global payment methods reachable from a single integration.
50+acquirers
Multi-acquirer routing behind the same gateway endpoint.
99.99%uptime
A payment gateway online platform engineered for peak traffic.

Why teams choose us

The case for a single gateway for payment across markets

Merchants move to a unified gateway to recover lost sales and retire stack complexity. The ledger below is what changes once every authorisation, settlement and method runs through one connection.

Higher approvals
Per-transaction scoring routes each payment to the acquirer most likely to approve it, lifting authorisation rates without a code change on your side.
Faster integration
A consistent, well-documented REST API and SDKs mean engineers can integrate payment gateway logic in days, not quarters.
Real resilience
Soft declines cascade to the next ranked acquirer inside the same request — your checkout sees one clean result and the sale survives outages.
No vendor lock-in
Keep your existing acquirer contracts. topropay orchestrates them; it does not force you to renegotiate the pricing you already have.
Local everywhere
Local acquiring, currencies and methods across Europe, the UK, APAC and LATAM, so the checkout feels native in every market you sell into.
One ledger
Settlements, fees, refunds and chargebacks from every provider reconcile into a single normalised export ready for your ERP or warehouse.
Operational control
Edit routing rules, retry windows and method availability from a dashboard — no vendor ticket, no redeploy, no waiting on a release window.
Compliance built in
Tokenisation, 3-D Secure 2 and SCA are applied per transaction, keeping the regulated surface area inside the gateway rather than your code.

Capabilities

Built-in features of a secure gateway payment platform

Everything you need to authorise, secure, route and reconcile a payment lives inside the gateway — there is no extra vendor bolted on around the edges for fraud, tokenisation or settlement reporting.

Unified payments API

A single REST surface and typed SDKs that reach every connected acquirer, scheme and payment method. The same payment gateway website payment object describes a card sale, a SEPA debit or an Apple Pay charge.

Smart routing

Each authorisation is scored against live acquirer health, scheme preferences, currency and historical approval rates, then sent to the route most likely to clear at the lowest cost.

Cascading retries

Soft declines fail over to the next ranked acquirer mid-request. The shopper sees a single result; the gateway sees the recovery.

Tokenisation vault

Cards are tokenised at capture in a PCI DSS vault, so raw card data never touches your servers. Stored tokens are reusable across acquirers without re-tokenisation.

3DS2 & SCA

Strong Customer Authentication and 3-D Secure 2 are applied per transaction where the market and risk profile require them — never blanket-on, never blanket-off.

Centralised reconciliation

Every payout, fee, refund and chargeback is normalised into one ledger, so closing the books is one export rather than a merge of provider files.

Webhooks & events

Real-time events for every state change feed your downstream systems — order management, anti-fraud, finance — with idempotency and signed payloads built in.

Operations console

Search any transaction, replay a request, edit a routing rule or refund a payment from a single dashboard, with role-based access and full audit history.

Where it fits

Where teams put the payment gateway on website checkouts

The same gateway carries a brand-new storefront and an established business at scale. Four of the most common moments teams adopt it:

  • Case · 01

    From the first sale

    A new store launching its first checkout uses the gateway to accept cards, wallets and local methods on day one — no separate provider builds, no waiting on an acquirer.

  • Case · 02

    When you outgrow one provider

    A scaling merchant adds a second acquirer behind the same integration to lift approvals and break a vendor dependency without rewriting the checkout.

  • Case · 03

    Expanding into a new region

    A team selling cross-border switches on local acquiring and methods for the new market from the dashboard — the gateway picks the right route per transaction.

  • Case · 04

    Migrating from a legacy stack

    An established business consolidates several point integrations into one gateway, retiring bespoke code and merging settlement files into a single ledger.

These moments overlap more often than not. A subscription business expanding abroad needs renewal recovery and local acquiring together; a marketplace running events needs split payouts and peak-time resilience at the same time. Because every capability sits on one integration, you combine them without adding vendors — and you can change the mix as the business changes, rather than committing to a setup you will outgrow. For related angles see the credit card payment processor guide, the PCI compliance posture, and the wider payment provider overview.

Industry relevance

Payment gateway website implementations across industries

Wherever revenue depends on a checkout that converts and clears, the same unified gateway applies. A short read across the sectors that use it most:

Retail & DTC
Direct-to-consumer brands rely on local methods and high approval rates to keep cart abandonment down through seasonal peaks.
Subscriptions & SaaS
Renewal recovery, account-updater flows and intelligent retries protect recurring revenue from soft declines and expired cards.
Marketplaces & platforms
Split payments and seller payouts run through one gateway connection, with per-merchant reporting and reconciliation underneath.
Travel & hospitality
Multi-currency capture, staged charges and large baskets demand the routing depth and redundancy of a multi-acquirer gateway.
Digital goods & gaming
Low-friction checkout, instant authorisation and broad method coverage matter most where the buyer is one click from leaving.
Financial services
Regulated flows, tokenised cards and a clear compliance posture make a unified gateway easier to operate than a stack of point integrations.

The platform is built for both mainstream and demanding, high-volume merchants, and it serves payment service providers that resell capacity to their own customers. What stays constant across every sector is the shape of the problem: take the payment, get it approved, keep it compliant and account for it cleanly. Solve that once, with one gateway, and a new product line or a new country becomes a configuration change rather than a project.

Trust & compliance

Compliance behind every gateway payment services connection

Handling money online means handling regulation. The platform is built so the heavy compliance lifting sits with us, keeping your own scope small.

  • PCI DSS aligned

    Card data is tokenised in a vault built to PCI DSS so your own scope stays small.

  • PSD2 ready

    3DS2 and SCA apply per transaction so European card payments stay compliant by default.

  • GDPR-minded

    Processed under EU data-protection rules, with residency options where required.

  • Bank-grade resilience

    Redundant acquiring and automatic failover keep authorisation live through outages.

By keeping card data inside a tokenised vault and applying authentication per transaction, the gateway holds the regulated surface area so your own systems never see raw card numbers. That keeps your PCI scope small, your audits shorter and your engineers focused on the product rather than on payment-security plumbing — while redundant acquiring and automatic failover keep authorisation available through outages and seasonal peaks.

Common questions

Questions about integrating payment gateway with topropay

What does a payment gateway actually do?

A payment gateway moves a payment from your checkout to the acquiring bank that authorises it, then back to your application with an approve or decline result. topropay is an online payment gateway that also routes the request across many acquirers, retries soft declines on different routes, tokenises card data and reconciles settlements — all behind a single API.

How long does integrating payment gateway capacity into our checkout take?

Most teams have a working sandbox in a day and live traffic within a week or two. Because there is one API to integrate rather than one per acquirer, the engineering work to integrate payment gateway flows is concentrated in a single, well-documented connection, and additional methods or markets are configuration rather than code afterwards.

Can I add a payment gateway to website checkouts I have already built?

Yes. The unified API plugs into an existing checkout without a rewrite. You can keep your front end exactly as it is and switch the back-end calls to topropay — adding a payment gateway to website code is typically a focused change inside your payments service rather than a redesign of the storefront.

How do you implement payment gateway logic for recurring billing?

Subscription teams implement payment gateway flows around stored tokens: the first authorisation tokenises the card, future renewals reference the token, and intelligent retries with optional account-updater logic recover failed renewals. The gateway handles the SCA exemption logic and 3DS2 challenges where they apply, so recurring revenue stays compliant without bespoke code.

What makes this a secure gateway payment platform?

Raw card data is captured inside a PCI DSS tokenisation vault and never touches your servers. 3-D Secure 2 and SCA run per transaction where required, payloads are signed, requests are idempotent, and every event is auditable. The combination of tokenisation, authentication and operational hardening is what makes it a secure gateway payment surface end to end.

Is this gateway for payment processing suitable for high-volume merchants?

It is built for scale. Per-transaction routing, cascading retries and redundant acquiring are designed for merchants and PSPs processing serious volume across many markets, schemes and acquirers — and the gateway payment services on top (reconciliation, dashboards, reporting) are tuned for finance and operations teams running real businesses, not test setups.

Do you offer a payment gateway for online payment use cases only, or in-app too?

Both. The same payment gateway for online payment surface — web checkouts, hosted payment pages, secure fields — also handles in-app and server-to-server use cases through the same API. One contract, one integration, every channel.

How does a payment gateway to website code differ from a hosted checkout?

A payment gateway to website integration gives you full control of the UI: card fields, wallet buttons and method selection live in your own front end, with the gateway handling tokenisation and authorisation behind the scenes. A hosted checkout swaps that out for a topropay-hosted page if you prefer to keep card data entirely out of your front end. Both options use the same back-end gateway and the same reporting underneath.

Does putting a payment gateway in website code increase compliance burden?

Done correctly, it lowers it. By keeping card data in the tokenisation vault and using hosted fields or a hosted checkout, the payment gateway in website code only handles tokens and references — not card numbers — so your PCI scope drops to the smallest applicable category.

What does a payment gateway website payment object look like in your API?

A single payment resource carries the amount, currency, customer, method, routing hints and metadata. The same object describes a card sale, a SEPA debit, an Apple Pay charge or an account-to-account transfer — only the method-specific fields differ. That is what keeps a payment gateway website payment integration consistent regardless of the rail underneath.

Will I lose visibility if I orchestrate through one gateway?

Visibility increases, not decreases. Every transaction across every acquirer flows through one operations console with full request/response detail, every settlement reconciles into one ledger, and every event fires from one webhook stream. You stop chasing provider-specific dashboards and read one source of truth.

Talk to our payments engineers

Implement payment gateway capacity in days, not quarters.

Book a discovery call. We map your current setup, score where authorisations leak today, and scope a single-API rollout across your markets — cards, wallets, account-to-account and local schemes included. No vendor renegotiation, no stack rebuild.

Book a discovery call [email protected]

Related

Beyond a single gateway