For resellers · PSPs · ISVs
Build your own branded payment gateway on top of topropay's orchestration layer. The PCI L1 vault, the connected acquirer panel, the routing engine, the dispute queue and the reconciliation feed already exist; your team writes the surface and owns the merchant relationship.
Build vs buy
Six axes that tend to flip between building scheme-licensed acquiring from scratch and building a branded gateway on top of an orchestration layer.
Key benefits
Four properties that show up once the scope of a from-scratch build hits engineering and finance — and the appetite for inheriting solved infrastructure grows.
Direct scheme registration with Visa, Mastercard, Amex and Discover is a year-plus project for new entrants. Building on top of a connected acquiring panel means the licensed entities ride underneath; your gateway brand sits on the surface.
Each direct acquirer integration is months of work. The platform already speaks to a panel of connected acquirers — adding a region or a provider is a routing-policy change rather than a re-integration on your side.
Card data captures into the platform vault before any of your code or any connected provider touches it. Your gateway never holds PAN data, which collapses your own PCI scope to SAQ A or SAQ A-EP.
Your team builds the surface (checkout UI, dashboard, branding, merchant onboarding flow). Everything beneath — vault, routing, cascade, dispute, reconciliation — is shipped already and runs as a managed service.
How it works
From scoping the gateway's product surface to scaling it across downstream merchants. Each step is a concrete deliverable; none of them are scheme-licensing work, because that sits with the connected acquirers.
Decide what your branded gateway will expose to its merchants — checkout shape (hosted / embedded / SDK), supported methods per market, onboarding flow, dashboard scope, pricing model.
KYB on your entity; agreed commercials; access to the connected provider panel and the routing-policy editor. Sandbox keys issued for your engineering team.
Your team wraps topropay's unified API with your gateway brand, your checkout UI, your dashboard. Hosted-fields tokenisation runs through the platform vault; PAN never lands on your origin.
Define routing weights per BIN, currency, country pair and merchant vertical. Resellers configure each downstream merchant independently; the policy editor is dashboard-driven, not code.
Onboard one or two pilot merchants, parallel-run against an existing provider where possible, measure approval rate, dispute outcomes and time-to-settle before scaling.
Once the pilot proves out, onboard additional merchants through your gateway's branded surface; the connected panel scales horizontally without re-engineering work on your side.
Main use cases
Five common shapes for teams creating branded gateways — PSPs, vertical ISVs, smaller banks, MoR platforms, and multi-brand merchant groups.
Build a branded gateway with your own checkout, dashboard and merchant-onboarding flow. The platform sits underneath as the orchestration layer; you keep the merchant relationship and contracting.
Software platforms (events ticketing, hospitality, professional-services billing) embed payments under their own brand instead of redirecting customers to a third-party gateway.
Smaller banks and neobanks add card and bank-rail acceptance for SMB customers through a white-labelled gateway without standing up a full acquiring stack themselves.
MoR / payments-on-behalf platforms surface a single gateway brand to their seller base; topropay handles the multi-acquirer side; the platform owns the seller relationship.
Retail or hospitality groups operating many brands centralise on a single internal 'group gateway' so finance, dispute and reconciliation stay unified across the estate.
Platform features
Twelve platform capabilities your gateway brand exposes to its merchants without building them — the primitives that make a from-scratch project a 12–18 month job.
Industry relevance
topropay's reseller / PSP offering targets licensed gateway operators serving licensed merchants in EU, UK, APAC and LATAM. Vertical fits include payments-focused PSPs, vertical SaaS platforms embedding payments, smaller banks and neobanks adding acceptance, MoR platforms, and multi-brand merchant groups consolidating internally.
Trust & compliance
One audited environment underpins every gateway brand on the platform; per-provider scheme-programme positions surface in the dashboard so the gateway-builder sees where the panel stands.
Ready to ship a branded gateway
A 30-minute reseller / PSP call confirms the connected provider panel relevant to your geographies, the per-merchant routing capability, the sandbox you can test against, and the commercial structure before any contract.
Frequently asked
What it really takes to ship a branded gateway, what's free vs paid, who owns the merchant relationship, and how migration / exit work.
To create a payment gateway from scratch you need scheme registration with Visa, Mastercard, Amex and Discover; relationships with one or more acquiring banks per region; a PCI DSS Level 1 environment for card data; a routing engine; a reconciliation pipeline; a dispute / chargeback handler; merchant onboarding (KYB, sanctions screening); and a 24×7 ops team. Realistically it's a 12–24 month project with a seven-figure budget before the first merchant transacts.
Yes. The faster path is to create your branded payment gateway on top of an orchestration platform like topropay. The platform contributes the scheme connections, PCI L1 vault, routing, dispute and reconciliation layers; your team contributes the gateway brand, checkout UI, dashboard and downstream-merchant onboarding flow. Time-to-live drops from 12–24 months to roughly 6–12 weeks.
Searches for 'create your own payment gateway for free' usually surface either open-source PCI-compliant code libraries (which don't include acquiring) or sandbox accounts on commercial gateways (which let you build against a test environment without commercial commitment). Production traffic always involves licensed acquiring, scheme registration and PCI compliance — none of which are free in the long run. The honest answer is 'free sandbox, paid production'.
Creating your own payment gateway on topropay means standing up a branded gateway product on top of the platform — your checkout UI, your dashboard, your onboarding flow, your pricing — with topropay's connected provider panel and orchestration layer doing the heavy lifting underneath. Your merchants see your brand; the per-transaction routing across acquirers happens transparently behind it.
Yes. payment gateway create-on-demand patterns — e.g. ISVs spinning up a per-customer gateway brand programmatically — work because the platform's reseller / PSP onboarding flow can be driven via API. Per-downstream-merchant onboarding, routing policy and dashboard scoping are all configurable per merchant rather than baked into a single shared deployment.
Yes, the create payment gateway website side is the surface — marketing site, sales funnel, merchant portal, brand pages — that customers experience. The payment gateway underneath is the technical product. Many resellers ship the website first (Astro / Next / WordPress) while the technical integration runs in parallel; the platform side is API-driven and decoupled from your marketing site stack.
If the goal is just to create a payment gateway website (a brochure-and-funnel site for an existing gateway), the platform side isn't strictly needed — any modern static-site stack works. If the goal is to ship both the site and the underlying gateway product, the platform side handles the back; the site handles the merchant-facing front.
Your branded gateway owns the merchant relationship — contracting, pricing, support, account management. topropay sits below as the infrastructure / orchestration layer that your team writes against. Downstream merchants don't see topropay's brand in their day-to-day.
Pricing for gateway-builders / PSPs is usage-based: a platform fee per transaction (typically expressed as a basis-points spread or a flat fee depending on volume tier), plus pass-through scheme and acquirer fees. The reseller sets its own margin on top when pricing to its downstream merchants. Detailed numbers are part of the commercial conversation.
Compliance posture is layered. PCI DSS L1 on the vault, switch and tokenisation runs at the platform level; the gateway-builder inherits it. Sanctions screening and AML monitoring run at the platform level on every downstream merchant. The gateway-builder is responsible for any local-jurisdictional requirements specific to its market (e.g. local consumer-protection registration, marketing-conduct rules).
Yes. A single branded gateway can serve EU, UK, APAC and LATAM merchants through one platform record. Per-region acquiring sits with licensed connected acquirers in each region; the gateway-builder doesn't need separate per-region integrations on its side.
Yes. Licensed gaming, regulated financial services and other compliance-bound verticals are supported only where current operating licences exist. Grey and black-market verticals (unlicensed gambling, adult content, IP-infringing goods, etc.) are out of scope regardless of which branded gateway sits in front. Gateway-builders inherit this position by virtue of the connected provider panel.
The platform ships the unified dispute queue, the evidence-pack templates and the automated-representment paths for select scheme types. The gateway brand surfaces these to its downstream merchants under its own branding, optionally enriches the evidence with merchant-specific metadata (order details, delivery proof, customer correspondence) and routes the case back through the platform for submission.
Migration is supported — the platform doesn't lock you in. Vault tokens can be migrated to the merchant's new vault (subject to PCI scheme-compatible handover procedures), settlement history can be exported in full, and merchant records can be portable subject to the underlying acquirer's contract terms. Most gateway-builders stay on the platform precisely because direct-acquiring carries the costs they were trying to avoid in the first place.
A single-merchant 'own gateway' — where the merchant just wants to brand the checkout under their own name — is normally better served by topropay's standard merchant onboarding plus checkout-branding options, not the reseller / PSP onboarding. The reseller path is right when the merchant intends to onboard other downstream merchants under the gateway brand.
Related