If you are pricing out a payment gateway, you have probably found a wide range of numbers and very little agreement on what they include. That is because most estimates quote the part that is easy to scope and quietly skip the part that actually decides whether building is a good idea. The build is a project. A gateway is a permanent obligation. Pricing the first and ignoring the second is how platforms talk themselves into a multi-year commitment they did not mean to make.
Building a payment gateway from scratch typically runs a software platform several hundred thousand to a few million dollars upfront, then a comparable amount every year to run it. The build is the cheap part. The real cost is PCI Level 1 attestation, network certifications, fraud tooling, uptime engineering and the team that carries all of it forever.
What "building a payment gateway" actually means
When a platform says it wants to build a gateway, it usually means one of a few different things, and they cost wildly different amounts. A thin integration layer over an existing processor is a few weeks of work. A true gateway, the thing that authorizes, captures, tokenizes, routes and settles card transactions on its own rails, is a multi-year program with a permanent team attached. Most cost estimates you find online quietly assume the first and quote it as if it were the second. The first question is always which one you actually need, and for the overwhelming majority of platforms the honest answer is neither.
The upfront build is the number everyone quotes
The engineering to stand up core gateway functionality, card authorization and capture, tokenization and vaulting, basic reporting and a merchant onboarding flow, generally lands somewhere between several hundred thousand and a couple million dollars depending on how much you build versus assemble. That is real money, but it is also the part of the estimate that is easiest to scope and the least dangerous. If the build cost were the whole story, more platforms would build.
The build is a project with an end date. Everything that makes a gateway a gateway is a cost with no end date.
The run cost is the number that matters
Here is what the build-cost estimates leave out, and it is the part that sinks platforms that go it alone:
- PCI DSS Level 1. The moment you store, process or transmit card data directly, you are a Level 1 environment: an annual third-party audit, a QSA, network scans, and an engineering burden to keep the whole system in scope and attested. This is the single line most build estimates ignore. See PCI compliance for SaaS platforms for what that actually entails.
- Network and processor certifications. Visa and Mastercard certifications, plus a processor or acquirer certification, each with their own test scripts and renewal cycles.
- Fraud and risk tooling. Tokenization is table stakes. You also need fraud screening, chargeback handling and monitoring, none of which ship with the build.
- Uptime and on-call. A gateway that is down is merchants who cannot get paid. That means redundancy, observability and a real on-call rotation, every night, forever.
- Maintenance against a moving target. Card network mandates, new card products, regulatory change. Someone has to absorb all of it.
Add it up and the ongoing cost of running a gateway often rivals or exceeds the original build cost, every single year. That is the figure to put in front of a decision, not the build quote.
What buying or partnering actually replaces
When you partner with a processor or a PayFac-as-a-service provider, you are not just outsourcing code. You are handing off the PCI Level 1 scope, the certifications, the fraud infrastructure, the uptime obligation and the compliance treadmill. That is why the build-versus-buy math so rarely favors building: the buy option is priced as a small share of revenue, and the build option asks you to staff a payments company inside your software company. The full decision, including the cases where building genuinely makes sense, is laid out in build vs buy vs partner.
When building can actually make sense
It is not never. If payments processing is your core product rather than an attached revenue line, if you are at a scale where a few basis points of saved cost dwarfs a multimillion-dollar run rate, or if you have a genuinely novel flow no provider supports, owning the rails can pay off. Those conditions are rare, and the platforms that meet them usually already know it. For everyone else, the question is not how to build a gateway cheaply. It is how to capture payments economics without building one at all, which is what embedded payments cost and how platforms make money from payments are really about.
How to actually decide
The number that decides this is not the build quote and it is not a benchmark from a blog. It is your build cost plus your honest annual run cost, set against what partnering would cost as a share of your payments revenue, modeled on your real volume. Run that and the answer is usually obvious. If you want to pressure-test it against your numbers before you commit a roadmap to it, that is exactly the conversation worth having first.