Merchant websites

Merchant websites, one stack across the whole portfolio.

topropay powers the payment side of every merchant website a brand operates — DTC, subscription, marketplace, app surface and licensed gaming sites — through one unified API, one operator portal and one ledger. Per-site routing policy, per-site method availability, one integration shape.

Book a portfolio review Explore the platform
store.example/
DTC € 189,00
app.example/billing/
Subs $ 39,00 / mo
market.example/
Marketplace R$ 489,00
play.example/ licensed
Gaming £ 49,00
One API behind all four sites.
One API
across every merchant website
300+
methods reachable per site
<200ms
routing decision
1 ledger
across the portfolio

Key benefits

Why one orchestration layer wins across many gateway websites

Four outcomes that show up consistently once an orchestration layer sits behind every merchant website in the portfolio rather than per-site stacks.

  1. 01

    Run one payment stack across many merchant websites

    For a brand with several merchant websites — a flagship DTC site, a B2B portal, a marketplace, a region-specific spin-off — topropay handles the lot through one API and one contract. The platform routes per-site policies inside the same orchestration layer rather than running a parallel integration per property.

  2. 02

    Per-site routing policy, one set of integrations

    Each merchant website can carry its own routing policy — approval-weighted for the flagship DTC site, cost-weighted for the marketplace, vertical-specific for a licensed gaming site. The integration shape doesn't change; the policy does.

  3. 03

    Methods per site, configurable per market

    Surface iDEAL on the Dutch storefront, PIX on the Brazilian one, Apple Pay on the iOS-heavy app, ACH on the US B2B portal. Method availability per site and per market is dashboard-configurable; the underlying API is the same.

  4. 04

    One reconciliation feed across the merchant-website portfolio

    Settlements, fees, refunds and chargebacks across every connected provider and every merchant website normalise into one ledger. Finance closes the month from one export with per-site, per-method and per-acquirer tags on every row.

How it works

From a portfolio of merchant websites to one unified back-end

Five stages between mapping the merchant-website portfolio and running every site through one orchestration layer. Most teams reach the first live site in days.

  1. 01

    Map the merchant-website portfolio

    A short discovery: which sites exist, what they sell, who buys, what they pay with. The output is a per-site routing and method policy, not a generic 'one config fits all'.

  2. 02

    Integrate once, scope per site

    Drop the hosted checkout, embedded SDK or low-level SDK into each merchant website that needs it. The platform identifies the calling site via API key or tenant tag; routing and method policy attach per site.

  3. 03

    Switch on per-site methods and routing

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

  4. 04

    Run live traffic across the portfolio

    Every authorisation runs through the routing engine, scored against per-site policy. Soft declines cascade to the next ranked acquirer inside the same request. Vault tokens and webhook events follow the same shape on every site.

  5. 05

    Reconcile the portfolio in one feed

    Settlements, fees, refunds and chargebacks roll up into one normalised ledger keyed off vault tokens — with per-site, per-method, per-acquirer and per-policy tags on every row. Finance closes the month once, not per site.

Verticals across the portfolio

Verticals topropay supports across merchant websites

Six vertical shapes that share the same orchestration layer but stress it differently — including a dedicated note on the licensed-gaming case below.

  • DTC

    Direct-to-consumer and online retail

    Online retailers running one or many DTC merchant websites — flagships, region-specific, sub-brand spin-offs — share one orchestration layer. Surface local methods per site; route across acquirers per transaction; reconcile in one feed.

  • Sub

    Subscriptions and SaaS sites

    Subscription portals on every plan size — from indie SaaS to enterprise. Network-token-driven recurring, smart retries and account-updater wiring run on every subscription-style merchant website through the same engine.

  • Mkt

    Marketplaces and platforms

    Multi-seller marketplaces and B2B platforms. Split payments, per-seller payouts and per-tenant reporting on one orchestration layer; the platform reconciles per-seller across the marketplace's merchant-website tenants.

  • Travel

    Travel, ticketing and hospitality

    Booking sites, ticketing portals and hospitality merchant websites. Staged captures, multi-currency capture, dispute analytics and per-acquirer chargeback timelines on a single API across the portfolio.

  • PSP

    PSPs and ISVs reselling capacity

    PSPs reselling capacity to downstream merchant websites — their tenants inherit the routing, method coverage and reconciliation; the PSP keeps the relationship and pricing. Per-tenant policies sit inside the same platform contract.

  • Gaming

    Licensed gaming and sportsbook operators

    Licensed gaming and sportsbook operator merchant websites run through the same orchestration layer as any other merchant — with operator-specific routing policies, jurisdiction-filtered method lists, and KYC / AML / responsible-gaming controls on top. See the dedicated scope note below for the in-scope vs out-of-scope boundary.

Licensed gaming · scope

Payment gateway for gaming — in scope and out of scope

Licensed gaming and sportsbook operator merchant websites are supported under the same orchestration layer as any other merchant — with strict compliance bars. The details, with the in-scope vs out-of-scope boundary stated explicitly.

In scope
  • Licensed sportsbook and casino operators in permitted jurisdictions with current operating licences (UK GC, Malta MGA, Curaçao, Gibraltar, US state-level, etc.) and full KYC / AML / responsible-gaming controls.
  • Payment gateway for gaming sites where the operator holds the relevant regulatory authorisations for every market the site accepts deposits from.
  • Payment gateway for gaming app integrations on native iOS and Android — same underlying routing engine as the web flow, same compliance posture.
  • Operator-specific routing policies, jurisdiction-filtered method lists, and per-jurisdiction risk thresholds layered on top of the standard orchestration.
Out of scope
  • Unlicensed gambling, grey-market betting or any gaming operator without a current operating licence in the relevant jurisdiction.
  • Operators routing traffic from jurisdictions outside their licence scope.
  • 'Cash-out' or wallet flows that bypass the operator's KYC and responsible-gaming controls.
  • Methods or routes not explicitly permitted by the underlying acquirer for the gaming MCC and the operator's specific licence scope.

Platform features

Capabilities shared across every merchant website

What the platform ships once and reuses across every merchant website in the portfolio — the primitives that make the cluster feel like one product.

  • Unified gateway across sites

    One REST API serves every merchant website in the portfolio, with per-site API keys and tenant tags for routing-policy scoping.

  • Per-site routing policy

    Approval-, cost- or composite-weighted policies per site — set from the dashboard, adjustable without a release.

  • Per-site method availability

    Methods enable / disable per site, per market — local-method surface per region without per-site code changes.

  • PCI DSS Level 1 vault

    Card data captures into the vault on every site before merchant origin sees it; vault tokens drive refunds, retries and recurring.

  • Cascade & retry

    Soft declines cascade to the next ranked acquirer inside the same authorisation — works the same way on every merchant website.

  • 3DS2 & SCA orchestration

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

  • Gaming-vertical primitives

    Operator licence scoping, per-jurisdiction method filtering, KYC / AML / responsible-gaming integration hooks.

  • Network tokens & updaters

    Network tokens by default plus scheme account updaters keep saved cards alive across re-issuance events.

  • Signed webhooks

    Per-site webhook URLs and HMAC-signed events; replay-safe with idempotency keys.

  • Unified reconciliation

    Per-site, per-method, per-acquirer and per-policy tags on every row of the unified ledger.

  • Operator portal

    One dashboard for every merchant website in the portfolio — authorisations, refunds, disputes, chargebacks.

  • Sandbox parity

    Per-environment, per-tenant sandbox that mirrors production routing, cascade, 3DS and refund flows.

Trust & compliance

Compliance posture across the portfolio

One audited environment underpins every merchant website in the portfolio. Merchants inherit posture rather than carrying separate certifications per site.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants on every site inherit the posture.
SCA & PSD2
Selective 3DS2 on the authorisation path keeps approval high in Europe without skipping compliance.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring scaled to merchant vertical and per-site traffic.
Gaming-specific compliance
Operator licence evidence captured during onboarding; per-jurisdiction method filtering enforced at routing.
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 or per-site routing.

Ready to map the portfolio

One payment stack across every merchant website.

A 30-minute portfolio review covers the sites in scope, per-site routing and method policy, and (where relevant) the licensed-gaming compliance bar. Sandbox parity per site, no commercial commitment up front.

Book a portfolio review Read the API docs

Frequently asked

Buyer questions about merchant websites and gaming sites

Questions buyers ask before committing — covering multi-site integration, licensed gaming scope, India gaming, multi-jurisdiction operators and per-site testing.

  1. 01

    What does topropay mean by merchant websites?

    Merchant websites is the umbrella term for the buyer-facing sites a merchant operates that need payment acceptance — DTC storefronts, B2B portals, marketplaces, subscription sites, app surfaces and licensed gaming operator sites. topropay handles every one of them through the same unified API and one operator portal, with per-site routing and method policy.

  2. 02

    Are gateway websites and merchant websites the same thing in this context?

    Gateway websites usually refers to the merchant-facing surface that hosts the payment gateway — i.e. the same thing as merchant websites in this context. The platform sits behind every gateway website in the portfolio: one API, one ledger, per-site routing policy.

  3. 03

    Can a merchant with many merchant websites integrate once and use the same stack everywhere?

    Yes. The integration shape is the same across every merchant website — drop in the hosted checkout, embedded SDK or low-level SDK; identify the site via API key or tenant tag; carry per-site policy on the platform side. Adding a new merchant website is dashboard configuration, not a fresh integration project.

  4. 04

    How does payment gateway for gaming work on the platform?

    Payment gateway for gaming is supported for licensed operators only. The operator integrates as a sub-merchant under topropay's connected acquirers that underwrite the gaming vertical; routing policies and method lists are filtered per the operator's licence scope. Unlicensed gambling and grey-market operators are out of scope regardless of how the integration is configured.

  5. 05

    Is payment gateway for gaming in india supported?

    Payment gateway for gaming in india is supported where the operator holds the relevant Indian licence (state-specific, since gaming regulation in India is largely state-level) and where the underlying connected provider is willing to underwrite the operator. India connectivity is delivered through licensed partner gateways; the operator's licence and the partner gateway's appetite together determine what runs. Unlicensed gaming in India is out of scope.

  6. 06

    Does the platform handle payment gateway gaming flows on web and mobile equally?

    Yes — payment gateway gaming flows on web and mobile share the same back-end. Native iOS and Android SDKs surface the same authorise endpoint as the web hosted checkout; tokenised pay-sheets, deposit flows, withdrawal-payouts and operator-portal cancel flows are identical across surfaces.

  7. 07

    What does a payment gateway for gaming site integration look like?

    A payment gateway for gaming site integration on topropay is the standard hosted-checkout or embedded-SDK shape, plus operator-specific policies layered on top: per-jurisdiction method filtering, KYC / AML / responsible-gaming hooks, deposit-velocity limits and gaming-MCC-aware routing. The underlying integration is the same as for any other merchant website.

  8. 08

    Are payment gateway for gaming websites with multiple jurisdictions a special case?

    Yes. Payment gateway for gaming websites operating across multiple licensed jurisdictions run multiple routing policies in parallel — one per jurisdiction, each scoped to its permitted method list and per-jurisdiction acquirer subset. The operator integrates once; the platform routes per-licence under the hood.

  9. 09

    How does payment gateway for gaming app differ from the web integration?

    Payment gateway for gaming app differs only on the surface — the underlying authorise endpoint, vault, webhook event model and reconciliation feed are identical. Native pay-sheets (Apple Pay / Google Pay), in-app KYC handoffs and platform-store payment-rule compliance (where applicable) are handled inside the SDK.

  10. 10

    Can a merchant run a non-gaming and a licensed gaming merchant website inside the same platform contract?

    Yes — a merchant with a non-gaming DTC site and a licensed gaming operator site can run both under one platform contract, each with its own routing policy, method list and compliance posture. The platform separates the two operationally inside the same dashboard and the same reconciliation feed (tagged per site).

  11. 11

    What's the integration timeline across a portfolio of merchant websites?

    First merchant website on the platform usually goes live in days for a hosted-checkout integration, weeks for an embedded build. Subsequent sites — once the first integration is wired — typically launch in hours each, since they reuse the same SDK, API keys are scoped per site and per-site policy is dashboard configuration.

  12. 12

    How does dispute and chargeback handling work across multiple merchant websites?

    Disputes and chargebacks across every merchant website in the portfolio surface in one unified queue. Evidence-pack templates per vertical accelerate response; the queue tags every case with the originating site, acquirer and routing policy. Operators don't open a different console per site.

  13. 13

    Is reconciliation per merchant website or rolled up across the portfolio?

    Both. The unified reconciliation feed contains every row with a per-site tag — finance can roll up across the whole portfolio, or filter to a specific merchant website. Most teams run a global month-close and then per-site analytics in the same export.

  14. 14

    What happens if one of the merchant websites in the portfolio is a different vertical (e.g. licensed gaming)?

    Different verticals across merchant websites in the same portfolio is the normal case. The platform applies per-site policies — a DTC site might run approval-weighted card routing while a licensed gaming site runs gaming-MCC-aware routing across the underwriting-permitted acquirer subset. The dashboard surfaces both under the same operator portal but tags traffic per site.

  15. 15

    How is per-site sandbox testing handled?

    Sandbox tenants exist per environment and per site — the merchant can build and test each merchant website's integration in isolation, with rotating sandbox webhook secrets and deterministic helpers for triggering specific outcomes. Production rollout is per-site too; the merchant doesn't have to flip the whole portfolio at once.

Related

Related on the topropay platform