How to Build a Payment Gateway — and When to Buy One Instead

“Can we just build our own payment gateway?” is usually asked for one of three reasons: fees that have stopped making sense at your volume, money movement your provider will not express, or an aggregator deciding your merchants are not welcome. All three are legitimate complaints. Only one is actually an argument for building a gateway — and it is almost never the fee one.

This is a plain account of what a gateway is made of, what the build includes, what it costs to keep running after launch, and where the line sits between building the thing and building on top of it. No estimate in days: anyone who gives you one without seeing your acquirer, your verticals and your settlement model is guessing.

What a payment gateway actually is

The word covers more than the thing most engineers picture. A gateway takes a card from a customer and turns it into an authorization at an issuing bank — but in practice it is six systems wearing one name.

Capture and tokenization. Collect the card without your servers seeing the number, and exchange it for a token you can safely store and re-use.
Connectivity. A certified connection to an acquirer or processor, which is what actually reaches the card networks and the issuer.
Transaction lifecycle. Authorization, capture, partial capture, void, refund, retry, recurring — each with its own rules and failure states.
Risk. Velocity and fraud rules, AVS and CVV handling, and 3-D Secure where liability shift matters.
Money out. Clearing, settlement, funding schedules, fee deduction, reserves and payouts — the part merchants actually judge you on.
Evidence. Reporting, reconciliation, dispute handling and the records merchants and their accountants ask for years later.

Teams that set out to “build a payment gateway” usually mean the first three. The last three are where the work lives, and they are why a gateway is a product rather than a feature.

What you are signing up to build

Tokenization, the vault, and the PCI question that decides everything

The first architectural decision sets your compliance burden for the life of the system: does raw card data ever touch infrastructure you control? If not — because card entry happens in an iframe or hosted field served by someone else’s PCI-compliant environment — your scope stays small. If it does, because you operate the vault yourself, you are in the business of storing cardholder data, and PCI DSS applies to the systems, the network segmentation, the key management and the people around it.

That is not a one-off exercise. It is an annual assessment, scanning, evidence collection, and a validation level that depends on the volume you process. Confirm current PCI DSS requirements and your validation level with your acquirer and a QSA before you design anything; the standard is revised, and the version that applied when your architecture was sketched may not be the one you are assessed against. For build-versus-buy the point is simpler: the vault is the largest permanent cost difference between the options.

Acquirer connectivity and certification

Your gateway does not talk to Visa or Mastercard. It talks to an acquirer or processor, over an interface certified before it carries live money: test scripts, card ranges, response-code handling, reversal and timeout behaviour, sign-off. It recurs, too, because scheme mandates and interface versions change on a schedule you do not control.

Two implications people miss. Your gateway inherits the acquirer’s appetite: if your merchants sit in regulated or specialty verticals, the technical connection is the easy half and the underwriting relationship is the hard one — see what the high-risk label actually costs. And one acquirer is a single point of failure, so the day you add a second you have also signed up to build routing, failover and per-acquirer reconciliation.

The transaction lifecycle, in its unhappy paths

The happy path is a weekend. The rest is the project. Authorizations expire. Captures land partially. Refunds race settlement. Timeouts leave you not knowing whether the issuer approved — which is why idempotency keys exist, and where home-built integrations double-charge. Recurring billing adds network tokens, account updater behaviour, retry schedules and dunning. We catalogued the failure modes in what AI gets wrong when it writes your payment code; a gateway has to be immune to every one of them, not merely survive them.

Settlement, funding and reconciliation

Invisible in a design document, dominant in operations. Authorizations are not money. Money arrives in batches, net of fees, on a funding schedule, sometimes split across acquirers, occasionally short because a reserve was held or a chargeback debited. Somebody has to match every settled batch to the transactions that produced it, explain the difference to a merchant looking at a different number in your dashboard, and do it every day. Moving money to third parties multiplies the same problem — the subject of marketplace and multiparty payouts.

Disputes, and the clock you inherit

Chargebacks arrive long after the sale, through the acquirer, with deadlines and evidence formats attached. A gateway has to accept the notification, surface it fast enough for the merchant to respond, package the evidence, track the outcome and account for the debit. Reserves run on their own timetable too — how rolling reserves work covers the release arithmetic. None of it can be bolted on later without a data model that anticipated it.

The costs that never appear in the build estimate

Build estimates price the first version. The running system is priced by the things below, and they do not stop:

Annual PCI validation for as long as you hold card data, including the evidence work your engineers do rather than your auditor.
24/7 ownership. Money movement has no maintenance window. Someone is on call for settlement that did not run on a Sunday.
Scheme and acquirer mandates, which land on their timetable rather than your roadmap’s, plus recertification each time you change acquirer or add a card type.
Reconciliation operations — a daily human process in almost every gateway, however good the automation.
Fraud tuning. Rules decay; someone has to keep approval rates and chargeback ratios in balance.

Against that, the saving is the margin between your provider’s pricing and interchange-plus-acquirer cost. That margin is real at scale, and rarely as large as the fully loaded cost of the list above until volume is substantial and the engineering team is already payments-literate.

When building is genuinely the right answer

Build when the gateway is part of the product rather than plumbing underneath it. The clearest cases: a platform onboarding its own sub-merchants, where onboarding is the competitive advantage; routing control across multiple acquirers for approval rates or redundancy; or money flows no provider will express — split payouts with retained fees, deferred settlement tied to delivery, multiparty flows where funds never rest with you.

Do not build because fees look high, because an aggregator froze you, or because your current API is unpleasant. The first is a pricing negotiation, the second an underwriting problem — why processors shut businesses down explains what triggers it — and the third a reason to change provider, not to become one.

The middle path: buy the rails, build the experience

Most teams asking this want control of the experience and the economics, not ownership of a card vault. That is a cheaper build: certified rails underneath, your product on top. Hosted fields so raw PAN never reaches your servers; tokens you own; an API for charges, refunds and payouts; signed webhooks for every state change; settlement reporting already reconciled. Our developer documentation covers tokenization, charges and webhook verification, and the end-to-end integration walkthrough shows the same path in working code.

On that footing you build the parts that are actually yours: onboarding, routing rules, dashboards, pricing logic, payout timing. Payment infrastructure is the version we run for platforms and ISVs; RapidPayLink covers hosted payment links where the checkout itself is the product; and the Medusa plugin is the same idea pre-wired for headless commerce.

A decision checklist

Will raw card data touch your systems? If it does not have to, do not let it. That single answer sets your compliance cost.
Is the gateway part of what customers buy from you? If not, it is infrastructure — and infrastructure is the thing to rent.
Can you name the flow no provider will support? If you cannot, you are solving pricing with engineering.
Who is on call at 3am for settlement? Name the person before you approve the project.
What is the real fee delta? Price it against interchange-plus, not against your invoice, then weigh it against a permanent team.

The honest version

Building a payment gateway is a reasonable decision for a small number of companies and an expensive detour for everyone else. The deciding question is not whether your engineers can do it — they probably can — but whether owning the vault, the certification and the overnight reconciliation makes your product better. If not, buy rails you can build on and spend the team on the part your customers see.

If you are weighing it up, Kadima will walk through your flows and tell you which parts you would have to own and which you can inherit — including whether your verticals are boardable at all, a harder question than the architecture. Start with how a high-risk payment gateway differs if your merchants sit in specialty categories, see if you qualify in about a minute, or call (888) 292-8555 or email [email protected].

This article describes general industry practice, not compliance advice. PCI DSS requirements, validation levels and card-network mandates change — confirm the current rules with your acquirer and a qualified assessor before making architectural or compliance decisions.