• Denys Kyrychenko, Co-founder & CEO at Corefy


• 07.08.2026 02:15 pm
#payments

Every team that decides to build its own payment gateway starts from a number that turns out to be too small. The engineering estimate is usually competent, but it prices launch day. The expense lives in year three, when 9 providers are connected, and the auditor comes back annually.

So, the useful question about an in-house build or a white label payment gateway: what does each one commit you to long after go-live, in budget and in headcount?

This piece sets out what a build estimate typically excludes, the costs that only appear after launch, and the cases where building really is the right call.

What a build estimate covers, and where it stops

Most gateway estimates cover the transaction path: a hosted payment page (HPP) or embedded checkout, a card vault and tokenization, the authorization flow, 3D Secure (3DS), one or two acquirer connections, a ledger, and an internal dashboard with basic reporting. A strong team scopes this accurately and delivers it in 6 to 9 months.

The operational layer around that path is where estimates go quiet. It includes merchant onboarding and the sub-merchant hierarchy underneath it, per-merchant and per-route fee configuration, settlement and statement generation, reconciliation against every provider's own file, rolling reserves, refund and chargeback workflows, sanction and risk lists, and status mapping that turns each provider's vocabulary into one set of statuses your team can report on.

None of that is exotic. It’s simply the software your payment operations team touches every day, and it rarely appears in a build plan written by people who have not yet run a payment business. In practice, this layer is at least as large as the transaction path, and it grows with every merchant and every market you add.

The 4 costs that arrive after go-live

These are the lines that turn a one-off project into an annual commitment. 

1. Compliance is an annual subscription

Operating your own cardholder data environment puts PCI DSS on your permanent cost base, and the standard itself dictates the rhythm. External vulnerability scans by an Approved Scanning Vendor are required at least once every three months. Internal and external penetration tests are required at least once every 12 months, and again after any significant change to the environment. At Level 1, that sits on top of an annual assessment by a Qualified Security Assessor, plus the internal evidence work needed to survive it.

Version 4.0.1 raised the floor again. Since 31 March 2025, payment-page script inventory and tamper detection are documented controls rather than informal habits: every script that loads on the payment page needs authorization, a written justification and an integrity check, and unauthorized changes to scripts or security-impacting HTTP headers have to raise an alert. That is tooling plus a named owner, every year, forever.

Safeguarding is following the same path. The FCA's PS25/12 supplementary regime, in force from 7 May 2026, requires daily reconciliation of safeguarded funds, a monthly regulatory return and an annual independent safeguarding audit. That is a recurring obligation with a named owner too.

2. The license sets your launch date

The statutory clock looks fast on paper: the FCA must determine a complete application within three months, and an incomplete one within 12. In practice, the second number governs, because almost no application is complete at submission and every information request restarts the substantive work. The capital is locked up before authorization, not after — €125,000 for payment execution and merchant acquiring, €350,000 for an authorized e-money institution.

Running the build and the application in parallel is the right call. But if the regulator gates your launch anyway, the engineering timeline stops buying you speed and starts buying you control, which is a separate argument that has to stand on its own.

3. Integration maintenance never ends

This is the cost that surprises even experienced teams, because it does not behave like a project. Providers change API versions, add mandatory fields, redefine status semantics, rotate certificates, launch new methods, and deprecate old flows. A connector that worked in March may start producing declines in September.

We publish our platform work every month, so the run-rate is easy to see. Across the first seven months of 2026, our integrations team shipped 64 new provider connections and roughly 580 updates to connections that already worked. That is around 80 changes a month to software nobody asked us to change, on a connector pool of more than 600.

Divide that by however many providers you plan to run. 3 connectors will not consume a team. 15 will, and it is a normal number once you sell into several markets.

4. Uptime has a headcount

Resilience is the least visible line and the most expensive to get wrong, and in the UK it no longer depends on internal standards. Under the FCA's operational resilience rules, payment and e-money institutions have had to identify their important business services, set impact tolerances for the maximum tolerable disruption, and stay within those tolerances in severe but plausible scenarios since 31 March 2025. Mapping, scenario testing and board-approved self-assessment are annual work.

Own the gateway, and you own the failover logic, the provider status monitoring, the scenario testing and the incident process that has to produce a regulator-grade report inside four hours. Those are salaries, and you pay them whether or not there is an incident that month.

A three-year cost model you can defend

The most useful correction to a build case is a change of unit. Stop comparing a build quote with a platform quote, and compare the fully loaded cost of running each option for three years, plus the revenue you do not earn while you wait.

Engineering is the largest variable, and public statistics set the floor. ONS data puts the median full-time salary for programmers and software development professionals in the UK at around £57,000. A production-grade gateway needs backend, integrations, front-end, DevOps and QA capacity permanently, not for the length of the build.

Two rules make the comparison honest. First, count the run-rate, not the build: whatever headcount you assume for year one, assume most of it again in years two and three. Second, price the delay. If your model shows 12 months to first transaction, the cost of the build includes a year of the margin you would have earned processing.

What separates a white label payment platform from a branded skin

The buy side has its own failure mode: a white label payment gateway solution that puts your logo on a checkout page and stops there. If the operational layer described earlier is missing, you have bought a front end and inherited the back-office build anyway.

6 questions separate the two. They are worth asking any white label payment gateway provider before pricing is discussed.

• Merchant lifecycle. Can you onboard a merchant, structure sub-merchants under them, set fees per merchant and per route, hold rolling reserves, and issue statements without an engineering ticket?

• Routing depth. How many attributes can a routing rule use, can rules cascade to a second provider after a decline, and can your payment manager change them directly in the interface?

• Money control. Does the platform reconcile against each provider's statements, expose one ledger, and handle payouts as well as payments?

• Brand depth. Does your domain cover the checkout, the merchant portal, the API reference, and the 3DS authorization step, so the infrastructure stays invisible to your merchants and their customers?

• Connectivity, and who maintains it. How many connections are live today, who absorbs the maintenance described above, and how long does a new provider take to activate?

• Exit. What happens to your tokens, transaction history, and merchant data if you leave? A platform confident in its value will answer this plainly.

Corefy's own answer sits in that shape: our white label payment gateway platform gives operators 600+ provider connections, routing and cascading, reconciliation, merchant management and a branded portal on their own domain. Companies entering the market as service vendors rather than merchants use the same infrastructure through our solution, which adds the merchant-facing tooling a payment service provider needs from day one.

When building is still the right call

The case against buying deserves stating properly. A platform is a dependency, and every dependency limits what you can promise your customers. Three situations justify the build.

• Payments are the product. If your differentiator lives at protocol level, in a proprietary risk engine, a scheme connection you hold directly, or settlement mechanics nobody else offers, that component has to be yours. It does not follow that the whole stack has to be.

• Volume changes the arithmetic. At sufficient scale, per-transaction platform fees exceed the fully loaded cost of an engineering team, and building becomes cheaper per unit. Run the crossover point rather than assuming it; it usually sits further out than founders expect.

• A constraint requires ownership. Some licenses, contracts, or jurisdictions demand direct control of components you cannot subcontract. That is a fact to design around, not a preference to argue with.

The pattern that survives contact with reality is usually hybrid: buy the connectivity and the operational layer, build the thing your customers actually pay you for. Splitting the decision by component rather than settling it wholesale is what keeps the engineering budget pointed at the product.

How to make the decision in 30 days

The build vs buy payment gateway question stalls because it gets debated in the abstract. 5 steps make it concrete.

1. Write the operating spec. List every screen and action your payment operations team will need on a normal Tuesday: onboarding a merchant, adjusting a fee, investigating a decline, closing a reconciliation. That list, not the transaction path, is the real scope.

2. Get the licensing timeline first. Ask counsel for a realistic determination date in your target jurisdiction. Everything else schedules around that answer.

3. Price three years, both columns, with a maintenance run-rate. Use loaded salary costs, an explicit per-connector maintenance assumption, and the compliance figures above.

4. Run one real flow before you commit. Take a genuine merchant scenario, including a decline and a reconciliation, through a trial of any platform you are considering. Demos hide the operational layer; a real flow does not.

5. Decide on the binding constraint. If it is capital or time, buy. If it is control over a component that is genuinely your differentiator, build that component and buy the rest.

The market has already answered part of the question

Our State of Payment Maturity 2025 report, based on assessments from 672 businesses worldwide, found that 58.5% still run payments through disconnected systems, and that the share of companies working with five or more providers rose from 24.6% to 37.1% in a single year. Only 11.7% have reached the stage where routing and risk logic adapt automatically.

Complexity is arriving faster than in-house capacity to manage it. Our analysis of 112 payment management job descriptions for The State of the Payment Manager Role points the same way: approval rate is the most cited key performance indicator (KPI) in the role, and reporting and analytics appear far more often than provider management. The people you hire to run payments are measured on performance. Every hour they spend maintaining connectors is an hour not spent on the metric they were hired to move.

That is the honest version of build vs buy. The cost of building a payment gateway is not the build. It is the permanent claim the build makes on the scarcest thing in a payment business: the attention of the people who know how to make payments perform.

If you are running this comparison now, the fastest way to test it is against a live setup. Talk to a payment expert about launching under your own brand and put real numbers on both columns before the roadmap is committed.