Payment cloud

Payment cloud — elastic, tokenised, multi-acquirer.

topropay's payment cloud puts every connected acquirer, PSP and method behind one tokenised API. Cloud-based payment processing, cloud payment gateway behaviour and centralised reconciliation, with the routing engine that picks the best route per transaction and the cascade engine that absorbs soft declines.

Book a cloud review Explore the platform
routing engine PCI L1 vault · tokens unified ledger merchant API A1 A2 A3 A4 A5 A6
One cloud. Many providers. One API.
Cloud
elastic capacity, region-aware
Tokens
PCI L1 vault by default
Multi-AZ
redundant acquiring zones
1 API
across every method and region

Key benefits

Why a cloud based payment gateway beats on-prem and single-provider stacks

Four outcomes that show up consistently once payments move into a cloud orchestration layer instead of a per-provider on-prem stack.

  1. Elasticity

    Cloud-based payment processing that scales with peak traffic

    Authorisation throughput, webhook delivery and the operator portal all run on horizontally-scaled cloud infrastructure. Merchants don't provision per-provider capacity buffers; the platform absorbs peaks across the connected provider portfolio.

  2. Tokens

    Token-based payment system with PCI Level 1 vault

    Card data captures into the vault before it ever touches merchant origin. Every subsequent authorisation runs against a vault token; network-token-by-default carries the credentials across card re-issuance.

  3. Routing

    Smart routing on every cloud-side authorisation

    Per-transaction scoring on BIN, scheme, currency, country pair and risk picks the route most likely to clear at the lowest landed cost. Soft declines cascade to the next ranked route inside the same request — no per-provider retry leak.

  4. Resilience

    Multi-zone failover by design

    Redundant acquiring zones and automatic failover keep authorisation available through outages and seasonal peaks. Cloud-side capacity moves traffic around any provider that degrades; merchants stay live.

How it works

From cloud-side connect to a normalised ledger row

Five stages inside the cloud — from the first integration call to the daily reconciliation export — that the merchant inherits without operating individually.

  1. Connect

    Integrate against the cloud API once

    One REST surface, one SDK family. Cloud-side endpoints absorb the per-provider plumbing the merchant would otherwise maintain.

  2. Configure

    Set routing, methods and risk policies from the dashboard

    Cloud policies are dashboard-level — no release cycle to flip a routing weight or add a method. Per-region and per-segment policies cohabit cleanly.

  3. Authorise

    Tokenise, route and cascade in the cloud

    Sensitive data captures into the vault; the routing engine scores the authorisation in under 200ms; cascade absorbs soft declines inside the same request.

  4. Settle

    Multi-acquirer settlement, normalised

    Each connected acquirer settles on its own schedule; cloud-side normalisation rolls everything into one ledger keyed off vault tokens.

  5. Improve

    Cloud-side analytics and policy tuning

    Per-acquirer, per-region, per-vertical analytics live in the operator portal. Routing weights adjust against your own outcomes — not benchmarks.

Main use cases

Where cloud-based payment solutions earn their keep

Six merchant shapes that share the same cloud orchestration but stress it differently. Same back-end, different policy on top.

  • 01

    Cloud-native SaaS merchants

    Merchants already running on cloud infrastructure plug a cloud-based payment gateway into the same operational model — autoscaling, observability, signed events into existing SIEMs.

  • 02

    Marketplaces and platforms

    Multi-tenant marketplaces use cloud payment processing for split-payment routing and per-seller payouts; per-tenant analytics live in the operator portal alongside platform-side reporting.

  • 03

    Subscription businesses

    Subscription-based payment gateway behaviour — vault tokens, network tokens, smart retries, scheme updaters — runs cloud-side; the merchant's billing system focuses on plans and pricing.

  • 04

    Cross-border DTC

    Cloud-based payment solutions surface local methods per market on a single checkout — PIX in BR, BLIK in PL, iDEAL in NL, PayID in AU — without per-region engineering work.

  • 05

    Travel, ticketing and high-ticket

    Staged captures, partial refunds and multi-currency capture for the long-lifecycle bookings travel and ticketing run — same cloud back-end as a single-charge DTC checkout.

  • 06

    PSPs and ISVs

    Reseller-side cloud API access and per-tenant dashboards let a PSP brand the surface per merchant; cloud-side orchestration is shared across the customer base.

Model comparison

On-prem payment stack vs payment cloud orchestration

Two valid models. The on-prem stack is the simpler buy on day one; the cloud model trades a slightly larger up-front integration for years of operational leverage.

Dimension On-prem / single-provider topropay payment cloud
Capacity Provision per-provider; scale up via tickets Cloud-side autoscaling across the connected portfolio; merchants don't provision
Deployment Per-region installs; lengthy update cycles Cloud-deployed updates land platform-side; merchants pick them up without ops work
Token model Often per-provider tokens, fragmented across vaults Single vault, single token namespace, one identifier per customer across rails
Resilience Tied to the on-prem footprint and the provider behind it Redundant acquiring zones, automatic failover; outage at one provider is rotated around
Analytics Self-hosted dashboards with delayed feeds Cloud-side analytics live next to operational data; no warehouse pipeline to build
Compliance Carry PCI and audit footprint yourself Inherit PCI Level 1 posture as a sub-merchant; compliance is platform-side

Platform features

Capabilities inside the cloud-based payment systems surface

What the platform actually ships across the cloud surface — from the API up to the operator portal and the reconciliation feed.

  • Cloud payment gateway

    Unified REST API and SDK family across every connected acquirer, PSP and method.

  • Token-based vault

    PCI DSS Level 1 vault keeps PAN data out of merchant origin; refunds, retries and recurring run on tokens.

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

  • Multi-region capacity

    Cloud-side capacity in multiple regions, with regional data-residency options for merchants under relevant regulators.

  • 3DS2 & SCA orchestration

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

  • Signed webhooks

    Replay-safe, normalised events into your SIEM, warehouse or in-house tooling.

  • Unified reconciliation

    Settlements, fees, refunds and chargebacks normalised into one ledger across every method and region.

  • Operator portal

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

  • Blockchain partner gateways

    Crypto rails through licensed partner gateways surface as another method on the same cloud API.

  • Sandbox parity

    Per-environment sandbox that mirrors production routing, cascade and updater behaviour.

  • Audit log

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

Trust & compliance

Compliance posture across the payment cloud

Cloud-side environments are audited once, on a documented cycle; merchants inherit the posture as sub-merchants rather than carrying separate certifications.

PCI DSS Level 1
Annual on-site assessment, quarterly ASV scans; sub-merchants inherit the posture from the cloud platform.
Cloud isolation
Tenant-level isolation, encrypted-at-rest data, key rotation on a documented schedule.
Regional data residency
Regional data-residency options for merchants under regulators that require it; signed event logs retained per policy.
SCA & PSD2
Selective 3DS2 challenges on the authorisation path keep approvals high in Europe without skipping compliance.
Audit posture
Operator actions logged with actor identity, reason code and timestamp; signed event log retained for audit.
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 migrate

Move authorisation, vault and reconciliation into one payment cloud.

A 30-minute cloud review walks through the connected acquirer set for your traffic, the routing policies that fit, and a sandbox to test against before any commercial commitment. Existing on-prem contracts can stay in place during migration.

Book a cloud review Read the API docs

Frequently asked

Buyer questions about the payment cloud — and a note on healthcare terms

What buyers ask before committing — covering the cloud model, tokenisation, blockchain and subscription gateway shapes, plus a clarification on healthcare reimbursement frameworks (IPPS, APC, Medicare) that are out of scope for this platform.

  1. 01

    What does topropay mean by a payment cloud?

    A payment cloud is the cloud-deployed orchestration layer that sits in front of the connected acquirer, PSP and method portfolio. Capacity, observability and policy updates all live on the platform side; the merchant integrates against the cloud API once and inherits the operational shape that ships with it.

  2. 02

    How does cloud based payment processing differ from a hosted gateway?

    Cloud based payment processing on topropay covers the full operational shape — authorise, capture, refund, reconcile, dispute — across many acquirers, with routing and cascade in the cloud. A hosted gateway typically ships only the authorisation surface for one provider; everything else stays the merchant's problem.

  3. 03

    Is this a token based payment system or a card-based payment system?

    Both. A card based payment system is the underlying card scheme behaviour (Visa, Mastercard, Amex, etc.). A token based payment system is how topropay represents card data inside its cloud — vault tokens replace PAN data, network tokens carry across re-issuance. The two co-exist by design: cards underneath, tokens on top.

  4. 04

    What does digital token based electronic payment system mean in the platform's vocabulary?

    A digital token based electronic payment system, in topropay's vocabulary, is the design where every subsequent authorisation, refund or recurring debit runs against a token rather than the underlying PAN or account number. The token lives in the platform's vault; the merchant never sees the original credential.

  5. 05

    Are value based payment systems supported?

    Value based payment systems is a healthcare-reimbursement term — paying providers based on patient outcomes rather than service volume. topropay does not operate inside healthcare reimbursement; the platform handles the consumer-facing payment side for merchants in licensed and regulated verticals.

  6. 06

    How does the cloud payment gateway behave at peak load?

    The cloud payment gateway scales horizontally — peak-hour spikes absorb cleanly because authorisations spread across the connected acquirer portfolio and the routing engine rotates around any provider that degrades. Merchants don't provision per-provider capacity buffers themselves.

  7. 07

    What cloud based payment solutions are typical for cross-border merchants?

    Cloud based payment solutions for cross-border merchants combine multi-region acquirer routing, local-method coverage per market, multi-currency settlement and one consolidated reconciliation feed. The cloud absorbs per-region differences; the merchant sees one operational shape.

  8. 08

    How is cloud payment processing different across regions?

    Cloud payment processing is region-aware: EU traffic routes through EU acquirers with PSD2 / SCA applied selectively; US traffic routes through US acquirers with US debit-routing policies; LATAM traffic uses PIX and OXXO where appropriate. The merchant integrates once; the cloud handles per-region behaviour.

  9. 09

    The IPPS is based on what type of payment system?

    The IPPS (Inpatient Prospective Payment System) is the US Medicare reimbursement framework that pays hospitals a pre-determined rate per discharge based on Diagnosis-Related Groups (DRGs). It is a prospective-payment / outcomes-tied system, not a consumer-payment rail. topropay does not operate inside Medicare reimbursement; the orchestration layer covers consumer- and merchant-facing payments.

  10. 10

    The payment system used by medicare is based on what model?

    The payment system used by Medicare is largely a prospective-payment model: IPPS for inpatient care (DRG-based), OPPS for outpatient (APC-based), MPFS for physician services, and similar systems for skilled nursing and home health. These are healthcare-reimbursement systems and sit outside topropay's scope — the platform is a payments-orchestration layer for licensed merchants, not a healthcare-reimbursement engine.

  11. 11

    What is the apc payment system?

    The APC (Ambulatory Payment Classification) system is the US Medicare framework that pays for outpatient services on a per-group basis under OPPS (Outpatient Prospective Payment System). Like IPPS, it is a healthcare-reimbursement framework; it does not relate to consumer card or bank-rail payments. We mention it here for clarity because the term is frequently confused with consumer payment-processing systems.

  12. 12

    Is there a blockchain based payment gateway inside the cloud?

    Blockchain based payment gateway functionality is exposed through licensed partner crypto gateways that plug into the same cloud API as fiat. Stablecoins, majors and L2 networks ride the same vault-token and reconciliation model; merchants who want fiat-only books turn on conversion-on-receipt per asset.

  13. 13

    Are cloud based payment systems suitable for high-volume merchants?

    Yes — cloud based payment systems on topropay are sized for high-volume merchants. Cycle scheduling, authorisation throughput and webhook delivery all run on horizontally-scaled cloud infrastructure; merchants don't need to provision per-provider capacity individually.

  14. 14

    Does the platform support a subscription based payment gateway shape?

    Yes — a subscription based payment gateway shape is built into the cloud orchestration. Cycle scheduling, network-token-by-default, smart retries, scheme updaters and customer-portal cancel flows live inside the platform; the merchant's billing system stays focused on plans and pricing.

  15. 15

    Can a merchant migrate from on-prem payment infrastructure to the payment cloud incrementally?

    Yes — migrations usually run in three stages: (1) integrate the cloud API in parallel with the on-prem stack, (2) shift a share of traffic 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