Insights · 13 min read
A real payment gateway is infrastructure, not a checkout feature. Here is the architecture, PCI DSS compliance, fraud controls, and what it costs to build one.
By GGP Editorial
Most people who say they want to build a payment gateway want one of two much smaller things: a checkout page, or a Stripe integration. A real gateway is infrastructure. It sits between a merchant's checkout and the card networks, authorizes transactions, holds card data, settles funds, and answers to an acquirer and a PCI auditor. Building one is closer to building a small financial institution than a web feature.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects, and we have built payment, trading, and financial systems for clients in the US, Brazil, South Africa, and Singapore. This guide walks through what a payment gateway actually is, the architecture, the compliance burden, what a build costs, and the one decision that shapes everything else.
If you are sizing the budget first, start with our breakdown of how much it costs to build a FinTech app, then come back here for the gateway-specific numbers.
A payment gateway is the software that accepts a card transaction from a merchant, formats it, routes it to an acquirer or processor for authorization, and returns the result. It is not the card network, not the issuing bank, and not the checkout button.
That matters because three products get confused with it.
Integrating a payment gateway means connecting Stripe, Adyen, or a local processor to your own app so you can accept cards. That is a weeks-long integration project, and we covered it in our payment gateway integration guide. Building a gateway means you become the Stripe in that sentence. You own the auth flow, the token vault, the fraud rules, and the PCI compliance.
A payment system is the broader ledger and money-movement layer a business runs on. We wrote about that in payment system development. The gateway is one component inside it, the part that talks to the card networks.
A cross-border payment platform moves money between countries and currencies, which is a remittance or payout business. We covered that separately in how to build a cross-border payment platform. A gateway accepts cards; a cross-border platform moves money across borders.
If you are building the thing that accepts the card, gets the authorization, and settles the captured funds, keep reading.
When a customer hits pay, a chain of parties fires.
The merchant's checkout sends the card details to the gateway. The gateway swaps the card number for a token and routes the transaction to a processor or acquirer. The processor sends it through the card network (Visa, Mastercard, Amex, Discover) to the cardholder's issuing bank. The issuer approves or declines, and the response travels back the same path in a second or two. If it is approved, the merchant can capture the funds, which settle through the network a day or two later, minus interchange and fees.
The gateway's job in that chain is to take the raw card data once, protect it, route it, record the result, and support the capture, refund, and void calls that come after. The engineering is not hard on the happy path. It gets hard on refunds, chargebacks, partial captures, retries, timeouts, and the reconciliation at day-end.
The visible part of a gateway is the payment form. The rest is what decides whether the thing survives an audit and a fraud attack.
A gateway should not store raw card numbers if it can help it. Tokenization swaps the card number (the PAN) for a random token at the moment of capture and stores the mapping in a vault. The merchant and your internal systems then handle tokens, not card numbers, which shrinks the part of the system PCI DSS applies to. Building a vault means a strongly encrypted store, strict key management, and an audit trail of who touched what.
In the EU and UK, Strong Customer Authentication under PSD2 requires two of three things for most online payments: something the customer knows, has, or is. 3-D Secure 2.x is the EMVCo protocol most gateways use to do that. The checkout redirects to the issuer's challenge, the customer authenticates, and the gateway passes the result back. Skipping 3DS2 is not an option if you serve European cards, and it raises fraud and liability-shift questions everywhere else.
Any entity that stores, processes, or transmits cardholder data has to meet PCI DSS. A gateway that touches card data directly is typically held to the highest level, which means a Report on Compliance from a Qualified Security Assessor, not a self-assessment form. The current standard is PCI DSS v4.0.1, and its requirements cover network segmentation, encryption in transit and at rest, access control, logging, and vulnerability management. The audit is a recurring cost and a recurring engineering constraint. Our guide to security requirements for FinTech platforms covers the hardening in more detail.
Authorization tells you the card has funds. It does not tell you the person using the card is the owner. A fraud engine layers velocity checks, AVS and CVV matching, device fingerprinting, and machine-learning scoring on top of the auth result. The rules have to be visible and editable, because your risk team tunes them, not your engineers.
Each day, the gateway's record of authorized and captured transactions has to match the acquirer's settlement file to the cent. Discrepancies compound if you only catch them at month-end. The gateway needs a daily reconciliation job and a ledger that tracks every leg of every transaction. This is the same discipline we describe in payment system development, applied to card traffic.
This is the decision that shapes the whole build, and most teams do not make it explicitly.
A full payment service provider owns the merchant relationships, signs with one or more acquirers or processors directly, and carries the merchant accounts. This is the Adyen or Worldpay model. It gives you control and better margins, but you carry the acquiring agreements, the risk, and the full compliance weight.
A payment facilitator (payfac) runs on top of a sponsoring acquirer. You onboard sub-merchants under a master merchant account, and the sponsor bank takes the acquiring risk. This is the Stripe and Square model. You get to market faster and you do not sign your own acquiring deals, but you pay the sponsor, you follow their rules, and you are exposed to their risk appetite.
| Model | What you own | What someone else owns | Best when |
|---|---|---|---|
| Full PSP | Merchant accounts, acquiring agreements, risk, margins | Nothing | Payments is your core business and you have the volume to justify it |
| Payfac on a sponsor | Onboarding, the software, sub-merchant support | The acquiring license and risk | You want to sell payments to merchants fast without signing acquiring deals |
Most first-time builders should start payfac and plan a path to full PSP once volume justifies it. It is the same build-versus-buy-versus-white-label logic we walked through for cross-border platforms, applied to acquiring. If you are still deciding who should build it, start with how to choose a FinTech development company.
The features that matter at launch are not the ones customers see.
| Must have in v1 | Can wait |
|---|---|
| Tokenization vault | Card issuing |
| Auth, capture, void, refund, partial capture | Recurring billing engine |
| 3-D Secure 2.x integration | Crypto on/off ramps |
| Merchant onboarding and KYC | Marketplace split payouts |
| A fraud rules engine | Loyalty and rewards |
| Daily reconciliation against settlement files | Customer-facing analytics |
| Admin console with transaction lookup | Mobile SDKs |
| Merchant and partner API with webhooks | Multi-entity accounting |
The admin console is the module nobody demos and everyone needs. When a transaction is stuck or a merchant disputes a chargeback, your operations team needs one screen that shows the transaction, the token, the auth result, the capture status, and every status change. Without it, every support question becomes an engineering ticket.
Cost in a gateway build is driven by five things, in rough order of impact.
Compliance. PCI DSS Level 1, 3DS2 certification, and the audit trail they demand are real engineering work and recurring audit fees. The more card data you touch directly, the more of your system the audit covers.
Processor and acquirer integrations. Every processor has its own API, its own test environment, and its own settlement file format. One processor is one integration. Three processors means you also build the routing and failover layer between them, which is more than three times the work.
Fraud and security tooling. A basic rules engine is manageable. Adding device fingerprinting, ML scoring, and a case-management console for your risk team pushes the build toward a data product.
Token vault and key management. Storing card data correctly, rotating keys, and surviving a QSA review is specialist work. Getting it wrong is the expensive kind of wrong.
Team and location. A gateway build needs a product manager, a designer, two to four backend engineers with payments experience, one or two frontend engineers, a QA lead, and a security-aware architect. Where the team sits changes the bill a lot. We break down the rate difference in software development cost in China.
As a rough guide, a single-processor MVP with tokenization, the four core transaction calls, 3DS2, a basic fraud engine, and a merchant portal usually lands between $150,000 and $350,000. A full PSP with multi-acquirer routing, hardened fraud tooling, reconciliation, and a full reporting stack runs $400,000 to $1,000,000 or more. These are ranges, not quotes, and the only number that matters is the one from a scoped proposal. We wrote about getting a real number in how to estimate a custom software project.
A single-processor MVP runs six to ten months from kickoff to a limited launch. A full PSP runs twelve to twenty-four months or more. The PCI audit, the processor certifications, and the 3DS2 certification run in parallel with the build, and they can outlast it. Start the processor and acquirer conversations before anyone writes a line of code. The code will be ready before the contracts are, and you do not want a team waiting.
Building the checkout first. The payment form is the last thing that matters. The vault, the routing, the fraud rules, and the audit trail are what let the product exist at all.
Underestimating the compliance timeline. PCI Level 1 and processor certification run on their own schedule and often outlast the build. Starting them late is the most expensive scheduling mistake in this category.
Ignoring reconciliation until month-end. If the ledger does not reconcile daily against the acquirer's settlement file, the discrepancy compounds. Make daily reconciliation a launch requirement.
One processor, no fallback. A single processor is a single point of failure. Build the routing layer so a processor outage does not take the gateway down.
Treating fraud as a post-launch problem. Fraud finds you in week one, not year one. Ship with a rules engine and a risk team that can tune it.
A single-processor MVP with tokenization, the core transaction calls, 3DS2, and a basic fraud engine usually lands between $150,000 and $350,000. A full PSP with multi-acquirer routing and hardened fraud tooling runs $400,000 to $1,000,000 or more. These are ranges, not quotes; the real number comes from a scoped proposal.
No. Integrating a gateway means connecting Stripe, Adyen, or a processor to your app so you can accept cards, which is a weeks-long project. Building a gateway means you become the infrastructure that authorizes and settles card transactions, which is a months-long build with PCI Level 1 and processor relationships attached.
It depends on the model. A full PSP signs acquiring agreements, which are business and regulatory relationships, not software. A payfac runs under a sponsoring acquirer's license. Licensing is a legal matter, so get legal advice early and treat the compliance and reporting requirements as part of the scope.
Tokenization, auth, capture, void, refund and partial capture, 3DS2, merchant onboarding, a basic fraud rules engine, daily reconciliation, an admin console, and a partner API. Skip card issuing, recurring billing, and marketplace features until you have volume.
Six to ten months for a single-processor MVP, twelve to twenty-four or more for a full PSP. The PCI audit and processor certifications run in parallel and can outlast the build, so start them first.
Start as a payfac on a sponsoring acquirer unless payments is your core business and you already have the volume to justify signing your own acquiring deals. Most teams launch payfac and move toward full PSP later.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa, and Singapore. We build custom software, mobile apps, SaaS platforms, FinTech and payment systems, ERP and CRM, and AI products on a stack that includes Java, Spring Boot, Go, Python, React, Vue, and Node. Our FinTech work includes a multi-market trading system spanning Hong Kong, US, and A-share markets, which you can read about in our multi-market trading system case study.
If you are planning a payment gateway, a payfac, or a payment system, talk to us about your project. Send us the model you are leaning toward, the processors or markets you have in mind, and the rough scope, and we will help you work through the build-versus-buy-versus-white-label call, the compliance layer, and what to ship first.
Tell us what you are building and where you are today. We typically reply within 24 hours.
