Build vs buy a payment gateway: what it costs to build a payment platform and when to license one
Building a payment gateway is not one integration: it is a gateway API, a PCI DSS scope with a vault, a checkout, routing, dozens of provider adapters that keep changing, cabinets for merchants and operations, a ledger and the reports a regulator asks for. A payment business that builds it spends a year before the first merchant pays and a team forever after; one that licenses it launches in weeks and spends its engineers on what makes it different.
What “a gateway” actually contains
- Gateway API and SDKs: requests, signatures, statuses, webhooks with retries, sandbox.
- PCI DSS scope: a vault for card data, tokens, key management, the yearly audit, the people who own it.
- Checkout: a hosted page in the languages of your markets, 3-D Secure, wallets, local methods, accessibility, speed.
- Provider adapters: every acquirer, Open Banking aggregator, local method and crypto provider, each with its own API, callbacks and quirks, each changing yearly.
- Orchestration: routing rules, cascading, limits, restrictions, a flow builder the operations team can use.
- Cabinets: the merchant cabinet, the admin panel, roles, audit, support tools.
- Finance: balances, fees, reserves, settlements, reconciliation with every provider’s reports.
- Compliance: journals and retention, a trace per payment, reports for the regulator and the schemes.
What each part takes to build
| Part | First version | What keeps it alive |
|---|---|---|
| Gateway API, webhooks, sandbox | 3–4 months | Versioning, SDKs, documentation, support for merchants’ developers |
| Vault, tokens, PCI DSS scope | 3–4 months plus the audit | Key rotation, the yearly assessment, every change reviewed against the standard |
| Hosted checkout | 2–3 months | Languages, methods, wallets, the payment-page requirements of PCI DSS v4, browser changes |
| Provider adapters | 2–4 weeks each | API changes, new mandatory fields, deprecated endpoints, new providers for new markets |
| Routing and cascading | 2–3 months | Rules the operations team can read; versions, rollback, measurement |
| Cabinets, roles, audit | 4–6 months | Every feature merchants ask for; every report; every language |
| Ledger, fees, reserves, settlements | 3–4 months | Reconciliation with every provider’s format; the accountants’ questions |
| Journals, trace, retention | 1–2 months | Storage that grows for years; the regulator’s requests |
The parts overlap, but a realistic first version with a dozen providers is a year of a full team, and the second year is spent on what the first year postponed.
The numbers that matter
The team that builds this is a backend lead, several backend engineers, a frontend engineer, a QA, a DevOps and a product owner, for at least a year, before any merchant pays. After the launch the integrations alone keep two engineers busy. The cost is not the salaries only: it is the merchants not signed while the platform was being built, the acquirer that changed its API the week before the launch, and the compliance questions a home-built journal cannot answer.
What licensing changes
- Time to market: weeks, not quarters; the first merchant pays as soon as the first acquirer contract is in place.
- Catalogue: the providers are integrated already; a new one is enabled, not developed, and an on-request one is built as an adapter that every client then gets.
- Maintenance: releases arrive; the client’s engineers build features for its merchants, not adapters.
- Compliance: the vault, the journals and the reports are part of the product, built to the standard’s requirements and documented at contract stage.
- Control: the data is the client’s, the platform can run in the client’s cloud account, and the routing, fees and limits are the client’s configuration.
The middle path: license and run it yourself
A client that must own its infrastructure licenses the platform and runs it in its own cloud account: the same images, the same release process, the client’s keys, network rules, database and storage. The client’s operations team installs the releases when it chooses; its security team keeps its controls; the vendor never has access to the data. That answers the regulator’s question about where the data lives without the cost of writing the software.
When to build anyway
If the platform is the product you sell, if a regulator requires full ownership of the code in the payment flow, or if your flows are so unusual that no platform fits, build. Otherwise license, keep your engineers for your own product, and keep the option of your own cloud account for when the regulator asks where the data lives.
A checklist before deciding
- List the providers your merchants need in the next two years; count the ones already integrated in the platform you consider.
- Count the people who would build and then maintain each part of the table above.
- Ask where the platform can run and who holds the keys.
- Ask how the data and the merchants leave if you leave.
- Compare the licence to the payroll of the team, not to the price of the first version.
Updated: 2026-11-08