Build on top · not from scratch

Build a payment gateway on a certified platform, not from zero.

Building a payment gateway from scratch is a 24-month, multi-million-dollar project — PCI DSS Level 1 audit, acquirer contracts, scheme programme registrations, EMV 3DS2, vault tokenisation, dispute infrastructure, reconciliation ledger. topropay ships all of that as the foundation. You build the product on top.

Book a build-vs-buy call Read the API docs
24+ months
typical scratch build to first live authorisation
$3–8m
typical scratch budget (PCI L1, dev, ops, licensing)
2–6 weeks
topropay build-on-top timeline to first live auth
1 API
instead of dozens of scheme, acquirer and rail contracts

The scratch ladder

What build a payment gateway from scratch actually costs

Eight hurdles between an empty repo and a live authorisation on a self-built gateway. For each: what building it involves, and what topropay ships in its place.

  1. 01

    PCI DSS Level 1 certification

    Annual on-site QSA audit; quarterly ASV scans; network segmentation; HSM-backed key management. Typical 12–18 months from zero to first attestation, and it never stops — the audit repeats every year.

    on topropaytopropay is PCI DSS Level 1. Sub-merchants inherit the posture — SAQ scope typically shrinks to SAQ A or SAQ A-EP.

  2. 02

    Acquirer relationships & MIDs

    Each acquirer wants: KYB, funding history, scheme registrations, chargeback history, sponsorship. Onboarding is 3–9 months per acquirer. Multiply by the geographies you serve.

    on topropayThe connected acquirer panel is already live. Merchants ride topropay's MIDs via the sub-merchant model, or pin their own MIDs where they hold them.

  3. 03

    Scheme programme registrations

    Visa (VDMP / VAMP / VFMP), Mastercard (ECP / EFMP), Amex, Discover, JCB — each has its own registration, its own thresholds, its own paperwork.

    on topropayScheme-programme posture is maintained per connected acquirer; positions surface in the dashboard so routing can rotate around at-risk lanes.

  4. 04

    Vault & tokenisation

    PAN vault (encrypted-at-rest, HSM-wrapped keys), network-token integrations with VTS and MDES, scheme account updaters. This is a full engineering initiative on its own.

    on topropayThe platform vault holds vault tokens plus network tokens (VTS, MDES) issued at first authorisation. Refunds, recurring and account updater flows all reference the token, not the PAN.

  5. 05

    EMV 3DS2 / SCA orchestration

    Integrating with a 3DS server, handling the ACS handoff, running exemption logic per PSD2 rules — usually 4–8 engineering months of focused work.

    on topropaySelective 3DS2 runs on the platform authorisation path. Frictionless flows pass through; step-ups happen where issuer or amount require them.

  6. 06

    Smart routing engine

    Per-BIN, per-currency, per-country-pair scoring; live approval-rate feedback; cascade logic on soft decline; per-merchant policy overrides. Building this from scratch is 12–18 engineering months.

    on topropayThe routing engine runs per authorisation across the connected provider panel. Weights are dashboard-editable per merchant.

  7. 07

    Dispute infrastructure

    Per-scheme dispute intake, evidence-pack templates, representment automation, chargeback-ratio dashboards. Every scheme has different case-file shapes and deadlines.

    on topropayUnified dispute queue across providers; evidence-pack templates per vertical; automated representment for select scheme types.

  8. 08

    Reconciliation & finance ledger

    Ingesting settlement files from every acquirer, normalising fee schedules, tagging refunds and chargebacks to the original authorisation, exporting to ERP. Another quarter+ of engineering.

    on topropayOne normalised reconciliation feed across every connected provider; daily CSV / API exports tagged by provider, scheme, currency and routing policy.

Key benefits

Why teams choose to build payment gateway on topropay instead of from zero

Four properties that show up the moment a team stops trying to rebuild the whole stack and starts building the product on top of one that already exists.

Skip the multi-year certification chain

PCI DSS Level 1, Visa VDMP / VAMP / VFMP, Mastercard ECP / EFMP, EMV 3DS2 — all already in place on the platform. Your team's build-payment-gateway roadmap starts from a working authorisation surface.

Inherit the acquirer panel

Instead of negotiating 5–10 acquiring relationships across your target geographies, ride the connected panel that already exists. Add or replace lanes as a routing-policy change, not a re-integration.

Focus engineering where it moves the product

Your team's time compounds on your checkout UX, your merchant admin, your product-specific policies — not on rebuilding vault tokenisation, dispute plumbing and settlement normalisation.

Retain optionality on the surface

Hosted checkout, embedded hosted-fields, or full low-level SDK — three integration shapes share the same back-end. Nothing about building on topropay locks you to a specific UX.

How build your own payment gateway on top works

Six steps from contract to first live authorisation

What actually happens between the contract signature and the first authorisation flowing through the gateway product being built.

  1. 01

    Scope your gateway product

    Define the merchant-facing surface you want to ship — hosted checkout, embedded fields, a bespoke SDK, or a full-stack white-label. topropay powers all four shapes.

  2. 02

    Contract & KYB

    Standard KYB for the entity building on the platform. Underwriting sizes for volume, vertical mix and regional coverage; typical timeline is 1–3 weeks.

  3. 03

    Enable connected acquirers

    The acquirer panel is enabled per contract; regional coverage lights up according to the geographies the gateway will serve. No per-region integration project.

  4. 04

    Wire the surface to the API

    Integrate against the unified authorisation, vault and webhooks endpoints. Sandbox covers the full lifecycle from authorise through settlement, refund and dispute.

  5. 05

    Configure routing policy

    Dashboard-editable per-BIN, per-currency and per-country routing weights. Cascade rules define how soft declines flow across the panel inside the same authorisation.

  6. 06

    Go live & operate

    First live authorisations flow through the panel; reconciliation feeds into the ledger; dispute queue populates as chargebacks appear. Standard ops from day one.

Main use cases

What people build payment system products for on top of the platform

Five recurring product shapes teams build on topropay — white-label gateways, PSP products, regional gateways, SaaS-embedded payments and internal enterprise gateway surfaces.

  • White

    White-label gateway for a niche vertical

    An operator wants to sell a branded gateway to their vertical — SaaS billing, marketplaces, ticketing. Build the merchant-facing product; topropay carries the acquiring and scheme heavy lifting behind the scenes.

  • PSP

    PSPs building on the platform to reach downstream merchants

    A licensed PSP builds their commercial product on top of the platform; downstream merchants ride the PSP's contract; the platform handles per-provider message exchange behind.

  • Reg

    Regional gateways serving a specific market

    A gateway product targeting a specific country pairs local method coverage (bank rails, wallets) with the platform's cross-border card acceptance. Building this from scratch would take years.

  • SaaS

    SaaS platforms embedding gateway-shaped payments

    A vertical SaaS wants its customers to accept payments inside the product without leaving. topropay's SDK plus the sub-merchant model make this a build-payment-system project measured in weeks, not years.

  • Ent

    Enterprises building on top for internal use

    A large enterprise with multiple business units doesn't want to run 5 separate gateway integrations. Build a single internal payment surface on topropay; the units share the ledger and dispute queue.

Platform features

Capabilities the platform ships that your build-a-payment-gateway team doesn't have to write

Twelve capabilities the platform ships once and reuses across every gateway product built on top — the primitives that make 'building a gateway' feel like building a product instead of an infrastructure project.

  • Unified authorisation API

    One REST contract for card, ACH, SEPA, wallet, BNPL and crypto legs of the gateway product.

  • PCI L1 vault

    PAN captured into the vault before any acquirer sees it; refund and recurring flows reference vault tokens.

  • Network tokens (VTS, MDES)

    Issued at first authorisation; scheme updaters keep saved credentials alive across re-issuance.

  • Smart routing engine

    Per-BIN, per-currency, per-country-pair scoring across the connected provider panel.

  • Cascade & retry

    Soft declines cascade to the next ranked provider inside the same authorisation; nothing leaks back to the buyer.

  • EMV 3DS2 / SCA

    Selective challenges per PSD2 exemption logic; frictionless flows pass through; step-up where required.

  • Unified dispute queue

    One queue across providers; evidence-pack templates; automated representment for select scheme types.

  • Sub-merchant onboarding

    For gateway products with downstream merchants: KYB, sponsorship and routing weights configured per sub-merchant.

  • Direct-MID mode

    For gateway products that hold their own acquiring relationships: pin authorisations to specific merchant IDs by rule.

  • One reconciliation feed

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

  • Signed webhooks

    Replay-safe lifecycle events for auth, capture, settlement, dispute, refund; SDK signing helpers included.

  • Dashboard & operator portal

    White-labelable operator surface for the gateway product's internal team — routing weights, disputes, refunds, KYB queue.

Trust & compliance

Compliance posture inherited by every gateway product built on top

One audited environment underpins every gateway built on the platform. Sub-merchants and gateway-product operators inherit the relevant posture per feature rather than carrying separate certifications themselves.

PCI DSS Level 1
Annual on-site assessment plus quarterly ASV scans; sub-merchants inherit the posture across every connected provider.
Scheme programmes
Visa VDMP / VAMP / VFMP and Mastercard ECP / EFMP positions surfaced per connected acquirer; routing weights can rotate around at-risk lanes.
SCA & PSD2
Selective EMV 3DS2 on the authorisation path — PSD2-compliant in Europe without breaking conversion.
Bank-rail mandate handling
NACHA authorisations for ACH; SEPA mandate IDs for SEPA Direct Debit; captured and retained per scheme rules.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and country mix.
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 gateway shape.

Ready to skip the scratch build

Ship your gateway product 12–18 months faster.

A 30-minute build-vs-buy call walks through your product's shape, the certifications you'd otherwise need, and the platform surface you'd build on. Followed by a sandbox your engineering team can integrate against before any commercial commitment.

Book a build-vs-buy call Read the API docs

Frequently asked

Buyer questions about building a payment gateway on topropay

Scope definitions, licensing boundaries, integration shapes, timeline realism and the honest verdict on build-vs-buy for gateway-shaped products.

  1. 01

    What does 'build a payment gateway' realistically involve if done from scratch?

    Building a payment gateway from scratch is a 24-month, multi-million-dollar undertaking. It requires PCI DSS Level 1 certification (annual audit, quarterly ASV scans, HSM key management), acquirer relationships in every geography served (3–9 months per acquirer), scheme programme registrations (Visa VDMP / VAMP / VFMP, Mastercard ECP / EFMP), a vault with network-token integrations, EMV 3DS2 orchestration, a smart-routing engine, dispute infrastructure per scheme, and a reconciliation ledger. Each of those is its own multi-month engineering initiative.

  2. 02

    Can I still build a payment gateway if I use topropay as the foundation?

    Yes. Building on topropay means you still own the product — the merchant-facing surface (hosted checkout, embedded fields, SDK or white-label admin), the pricing, the go-to-market and the customer relationship. What you're not building is the multi-year certification and integration chain underneath. Your team's build-payment-gateway roadmap starts from a working authorisation surface.

  3. 03

    How is build payment gateway on topropay different from a plug-and-play SaaS?

    A plug-and-play SaaS gives you a pre-baked checkout with limited customisation. Building on topropay gives you the primitives — vault, routing, connected acquirer panel, dispute queue — plus three integration shapes (hosted, embedded, SDK) that you can compose into whatever gateway product you want to ship, including a full white-label gateway for downstream merchants.

  4. 04

    Is it possible to build your own payment gateway without an acquiring bank relationship?

    Yes, in practice — building your own payment gateway on top of topropay's sub-merchant model gets you to live authorisations without holding your own acquiring bank relationship yet. Direct-MID mode is available when the merchant (or the gateway product's operator) does hold their own MID, so the same integration handles both paths.

  5. 05

    What's the honest verdict on 'build a payment gateway from scratch' as an option?

    For 99% of teams, build a payment gateway from scratch is not the right call. The 1% for whom it might be: existing licensed acquiring institutions, large regulated financial institutions with capital and multi-year timelines, or nation-scale infrastructure projects. For everyone else — including well-funded fintechs — building on top of an existing certified platform is the shape that ships. topropay is that platform.

  6. 06

    How does build payment system differ from build payment gateway?

    Build payment system typically means the wider stack — gateway, ledger, reconciliation, dispute tools, operator surface, merchant admin. Build payment gateway is a narrower slice — the authorisation surface and its plumbing. topropay covers both: the platform is the payment system, and any surface you ship on top of it is your gateway product.

  7. 07

    How long does it take to build a payment product on top of topropay?

    Most teams building a payment product on top of topropay ship their first live authorisation in 2–6 weeks. The variables are: KYB timeline for the underlying entity, the complexity of the merchant-facing surface being built, and any scheme-programme registrations the connected acquirers need to file. Sandbox covers the full lifecycle from day one so engineering can build against it in parallel with underwriting.

  8. 08

    What engineering effort remains when you build on topropay?

    The remaining engineering effort is the merchant-facing surface and the product-specific policies. That means: your checkout UI (or SDK integration), your merchant admin dashboard (if you're a PSP-shaped product), your KYB queue for downstream merchants, and any vertical-specific routing rules. Vault, routing, tokenisation, dispute plumbing and reconciliation are already there.

  9. 09

    Can we start with hosted checkout and migrate to a bespoke SDK later?

    Yes. All three integration shapes — hosted checkout, embedded hosted-fields, low-level SDK — share the same back-end. Starting with hosted checkout for time-to-first-revenue and migrating to an SDK later doesn't require a re-platforming. Vault tokens and merchant records carry across.

  10. 10

    How does the sub-merchant model interact with 'build your own payment gateway'?

    If the gateway product being built serves multiple downstream merchants, the sub-merchant model handles it: each downstream merchant onboards under the gateway operator's contract; KYB, sponsorship and routing weights are configured per sub-merchant; funds settle to the gateway operator, who then settles downstream (or to the sub-merchant directly, per scheme rules and jurisdiction).

  11. 11

    What compliance does the gateway product's operator need to hold?

    Compliance requirements for the gateway operator depend on jurisdiction and business model. In many EU jurisdictions, operating as a PSP requires a Payment Institution or E-Money Institution licence; in the US, money-transmitter licences are per state; in Australia, an AFSL may be required. topropay covers PCI DSS on the payment-processing layer; the gateway operator covers their own jurisdictional licensing.

  12. 12

    Can we white-label the operator dashboard for our gateway product?

    Yes. The operator dashboard is white-labelable — colours, logo, domain and copy can be customised so the gateway product's internal team and downstream merchants see a branded surface rather than topropay-branded infrastructure.

  13. 13

    What does the routing engine give us that we couldn't rebuild ourselves?

    The routing engine gives per-BIN, per-currency, per-country-pair scoring with live approval-rate feedback loops across a connected provider panel — plus soft-decline cascade inside the same authorisation. Rebuilding this from scratch is 12–18 engineering months, and the value only materialises once you have multiple connected providers to route between, which is another multi-quarter project. On topropay, both are turnkey.

  14. 14

    What are the compliance boundaries the platform enforces?

    topropay enforces licensed-verticals-only across every gateway product built on top. Licensed gaming, regulated financial services and other compliance-bound verticals are supported where operating licences exist; adult, unlicensed gambling and grey / black-market verticals are out of scope. This applies regardless of the shape of the gateway being built.

  15. 15

    How do we evaluate build-vs-buy for our specific case?

    The evaluation typically covers: (1) timeline to first live authorisation, (2) cost to certification, (3) engineering team size available for infrastructure vs product, (4) whether the merchant relationships you want require you to hold specific licences, and (5) the geographic coverage you need on day one vs 24 months from now. A 30-minute build-vs-buy call with topropay walks through the specifics before any commercial commitment.

Related

Related on the topropay platform