This website uses cookies to help improve your user experience
Here is a strange way to open a guide on how to build a payment gateway: most companies asking the question should not build one. Integrating Stripe, Adyen, or a comparable provider is faster, cheaper, and already carries the compliance weight.
The decision is rarely about engineering ambition. It is about economics, reach, and control. This guide is for the set of cases where building pays off: high transaction volume, multi-acquirer routing you control, or payments that are your actual product.
For those teams, the path is recognizable. A feasibility study confirms or kills the business case, architecture and design lock in the transaction lifecycle and the security boundary, a stack is chosen for the money path, and the core is built, deployed, certified, and integrated. After launch, the gateway becomes a platform to operate and keep current.
Cost tracks with how much of the core you build versus reuse:
Our payment gateway development cost guide breaks the numbers down. Timelines sit between several months and a year-plus, with processor integration and certification often setting the pace.
We asked Kiryl Anoshka, Oxagile’s Senior JavaScript Engineer specializing in fintech, to pressure-test the build decision, separate the parts of a gateway that are genuinely hard from the parts that only look hard, and explain why the cost of a creating your own payment gateway is mostly the cost of operating it.
Key takeaways:
The term gets stretched to cover the whole payment stack, which hides where the real work and the real risk actually sit. A payment gateway is the software layer between your checkout and the money rails.
It captures the payment details, secures them, and turns a customer’s intent to pay into messages the processors, networks, and banks understand. Everything else in a payment processing setup, including moving the money, holding it, and approving it, is handled by other players the gateway talks to.
In practical terms, the gateway accepts a payment request, secures the card data, tokenizes the card number, and forwards authorization and settlement messages to the processor and networks.
It sees the raw card number only for a moment at capture, then replaces it with a token. A vault stores that token, and nothing downstream touches the real number. The gateway is not the processor, the acquirer, or a bank, and it never holds your money. It handles the request and the data, not the funds.
| Component | Role in the transaction |
| Gateway | Captures and secures payment details, turns intent to pay into network messages |
| Processor | Routes the transaction between the parties |
| Acquirer | The merchant’s bank |
| Card networks (Visa, Mastercard) | Carry the transaction across the system |
| Issuer | The customer’s bank that approves or declines |
Fraud screening, recurring billing, and reporting sit as modules around this core rather than forming part of the definition. What used to be optional, rule-based add-ons are increasingly run by AI engines: real-time fraud scoring, smart retries, decline recovery, and anomaly detection on the transaction stream. That shift is steadily raising the bar for what a modern payment processing gateway is expected to do, a point we return to later.
Expert’s point of view:
“Everyone fixates on the checkout API because it is the visible part. It is maybe a fifth of the work. The money sits in the parts nobody demonstrates: the tokenization vault, settlement, and reconciliation that has to balance to the cent at the end of every month.”
Start from the honest default. For most businesses, an off-the-shelf gateway is the right call, because established providers launch faster, run cheaper, and already absorb the compliance burden.
The reasons to create your own payment gateway come down to a handful of specific situations, and it is worth being clear-eyed about whether you are really in one, because the wrong answer here stays expensive for a long time.
Kiryl comments:
“The honest answer for most companies is to integrate payment gateways and move on. Building only starts to make sense when the percentage you pay a provider on every transaction grows past the cost of running your own rails, or when the gateway is the thing you actually sell. Get that judgment wrong and you are paying for it for years.”
A gateway is a set of layers that carry a transaction from the customer’s checkout through to settled, reconciled funds. Understanding how to implement payment gateway logic correctly starts with one question that decides how cheap the whole thing is to secure: where is card data allowed to travel?
The end-to-end flow runs from the checkout host, into the API and security layer, through the domain core (the transaction state machine and method router), out to processors and networks, then into capture, settlement, and reconciliation.
Card data is captured in a hosted field and tokenized at once into a PCI-scoped vault, the PAN encrypted under AES-256-GCM. Network tokens come from the networks rather than your vault. The domain core holds only logic, while state, the vault, the ledger, and the async workers sit around it.
The method router sends each payment to its adapter (card, account-to-account, BNPL, open banking, crypto, BaaS), with the card path the deepest: acquirer, then networks, then issuer, then batched settlement.
Reconciliation matches authorized against settled and updates the ledger, the step most teams underestimate and the one that turns into a fraud question the moment the numbers stop matching. Productized gateways add merchant APIs and onboarding on the same core, while fraud screening, recurring billing, and multi-method payments attach as composable, increasingly model-driven modules.
Build infrastructure that handles transaction authorization, settlement workflows, fraud controls, and connections with banks, processors, and digital wallets.
A gateway build runs in phases, and the first two decide the rest. Feasibility and architecture lock in most of the cost and risk before a single production line of code exists, which is exactly where most “build” cases should be confirmed or killed.
The projects that go wrong are usually the ones that treated those phases as paperwork, rushed into engineering, and met the bill during certification. Knowing how to make a payment gateway that ships on time is mostly knowing how much is already settled before you write any code.
| Phase | What it locks in |
| Feasibility and business case | Volume model, fee math, target markets, regulatory scope |
| Architecture and design | Lifecycle, CDE boundary, decimal money, idempotency |
| Technology stack | Money-path language, ledger, message bus, key storage |
| Application layer and integrations | Orchestration and routing services, merchant onboarding and admin APIs, ERP and webhook integrations |
| Core build | Auth, capture, refund, tokenization vault, signed webhooks |
| Production deployment | Segmented CDE, observability, disaster recovery |
| Integration and certification | Processor integration, scheme certification, ERP wiring |
| Support and evolution | Scheme mandates, PCI re-validation, new rails and regions |
Kiryl, on saying no:
“Feasibility is the cheapest place to kill a project, and almost nobody uses it that way. Every month you wait to walk away, walking away costs more. By the time you are integrating processors, a “no” costs you a year and most of a budget.”
The authorization path lives or dies on predictable latency under load, so the money path wants a compiled, concurrency-first language. We use both Go and Rust for it: each gives the high throughput and low, predictable latency the authorization path needs, without GC pauses that blow tail latency and trip payment SLAs.
Rust earns the most sensitive code, the parts that touch card data and money, because its memory safety rules out whole classes of exploitable bugs, shrinking the attack surface where it matters most.
The ledger lives in PostgreSQL for native decimal money and ACID guarantees, with Redis for idempotency and rate limiting and a durable message bus (Kafka, RabbitMQ, or SQS) for asynchronous settlement, webhooks, and retries. Key material sits in a managed KMS or HSM, and a MERN stack covers everything off the money path.
A production payment gateway setup pairs each control with the failure it answers:
Reliability planning belongs here in the design itself: the practices behind reliability, observability, and incident response should be built in well before anything reaches a post-launch backlog.
Security defines the architecture from the first decision, not the last sprint. PCI DSS, the Payment Card Industry Data Security Standard, is the global baseline for handling cardholder data, and every system that stores, processes, or transmits it forms your cardholder data environment, or CDE.
The engineering goal is to keep that CDE as small as possible and still hold bank-grade controls. A smaller scope means a cheaper assessment, a smaller attack surface, and a smaller blast radius if something goes wrong.
PCI obligations scale with annual transaction volume. A gateway is a service provider, which sits on a two-tier scale. Level 1 covers more than 300,000 card transactions a year and requires an on-site QSA assessment producing a ROC and an AOC, plus quarterly ASV scans and penetration testing. Level 2 covers 300,000 or fewer and allows an annual self-assessment (SAQ D for Service Providers) with an AOC, alongside quarterly ASV scans.
That is your own obligation. The merchants who use your gateway sit on a separate, four-level scale:
| Merchant level | Annual card transactions | Assessment |
| Level 1 | More than 6 million, or any merchant that has suffered a breach | On-site QSA assessment, ROC and AOC, quarterly ASV scans, penetration testing |
| Level 2 | 1 million to 6 million | Self-assessment (SAQ), AOC, quarterly ASV scans |
| Level 3 | 20,000 to 1 million e-commerce | Self-assessment (SAQ), quarterly ASV scans |
| Level 4 | Fewer than 20,000 e-commerce, or up to 1 million total | Self-assessment (SAQ), ASV scans as required by the acquirer |
Which questionnaire applies depends on how card data is handled: a fully hosted checkout that keeps the PAN off merchant systems qualifies for the shortest one, SAQ A, while storing or processing it directly pulls the merchant into SAQ D. So the same hosted-field design that shrinks your CDE also drops your merchants to the lightest tier.
Thresholds vary slightly by card brand and shift over time, but the principle holds: fewer systems inside the CDE means a lower tier and a cheaper assessment every year.
The cheapest system to secure is the one that never sees a card number. Capture card data in a gateway-hosted field or iframe, and the merchant’s own pages stay out of scope under the lightest questionnaire, SAQ A. Tokenize the PAN the moment it arrives, and it lives in one small encrypted vault while the rest of the platform runs on tokens.
Inside that vault, bank-grade controls apply: AES-256-GCM at rest, TLS in transit, keys in a managed KMS or HSM rotated under dual control, network segmentation, least-privilege access, and audit logging on anything that touches card data.
Kiryl comments on scope:
“People treat PCI as a compliance tax. It is really an architecture problem. Every design decision that keeps the real PAN out of your environment shrinks the audit, the attack surface, and the blast radius at once, and scope discipline ends up the single biggest lever on what the platform costs to run.”
PCI is global, the rest depends on where you operate. In the EU, PSD2 mandates Strong Customer Authentication (usually EMV 3DS) and GDPR governs personal data. The UK adds the FCA and the Payment Services Regulations. The US requires state-by-state money-transmitter licensing if you hold funds.
India’s RBI mandates that payment data stay in-country, and Brazil has LGPD alongside local rails such as Pix. The moment you hold balances or onboard sub-merchants, AML, KYC, and sanctions-screening obligations attach on top.
None of this is a trade-off against security: a tight CDE delivers both lower cost and stronger protection, and it lowers every annual audit, scan, and remediation bill for the life of the platform.
The build is a finite, capitalized cost. The gateway is an operating liability you carry for as long as it runs. Total cost of ownership, the build plus everything after it, is what should drive the build-versus-buy decision, yet most teams underwrite on the build number alone and get caught by the run-rate.
A production build runs between several months and over a year, and the calendar is not all engineering. Processor integration and scheme certification can add months outside your control, so plan the launch around certification windows than on code-complete.
After launch, the recurring costs begin. PCI is an annual cycle of re-validation, quarterly ASV scans, and penetration testing. Visa and Mastercard publish mandatory updates twice a year, in April and October.
Go direct to the schemes and you implement those on their timeline and recertify with acquirers whenever APIs change. Sit on a processor or acquirer-as-a-service that bundles connectivity, and most of that burden shifts to them. That convenience is exactly what you give up by going direct.
Reliability is a permanent line item. A payment system cannot absorb an unplanned outage quietly, so 24/7 on-call, incident response, observability, key rotation, and SLA management run continuously.
So does the team: payments engineering, security, SRE, and compliance roles form a standing group, not one you disband at launch. A tight PCI scope and clean architecture compound in your favor here, lowering the audit, scan, recertification, and maintenance bill every year the platform runs.
Kiryl notes:
“Everyone can price the build. What surprises people is what comes after it: PCI re-validation every year, the April and October scheme releases, on-call for a system that cannot quietly fail. That is the real budget.”
We are not theorizing here. Oxagile runs its own production payment gateway, so a client engagement starts from a proven core rather than a blank page. That distinction matters more than it sounds.
Most of the cost and risk in a gateway hides in failure modes a team only meets once real money and live issuers are in play, and operating one of our own means we have already met them. A client build starts past that learning curve, on an engine whose hardest parts have been proven under load and through certification.
For teams seeking to create a custom payment gateway without the full build risk, this is the most defensible middle path, and it sits alongside the rest of our payment software development work.
Most gateways put their AI behind a reporting API, so the model only sees a transaction after it has settled. Ours runs on the gateway’s own event stream, inside the authorization path, which changes what it is allowed to do: it can act on a transaction while the money is still in flight. That placement is the whole point, and it is an engineering problem before it is a modeling one.
Expert’s take:
“The model is the easy part. The hard part is the latency budget: scoring every transaction inline, before authorization, without adding the milliseconds an issuer will punish you for. Get that plumbing right and the model pays for itself on declined-payment recovery alone.”
From that position, the model does a few concrete things. It scores each transaction inline before capture, with rules setting the floor and the model handling the patterns rules miss. It classifies declines in real time and decides whether to retry or cascade to another processor, recovering authorizations a fixed decline-equals-failure flow would write off.
It picks a processor and path per BIN, region, and method against live approval and cost data. And it watches the event stream for velocity, linked-account, and behavioral patterns that a single check at authorization cannot see.
Reconciliation runs the same way, with settlement matched against the ledger automatically and the exceptions flagged and ranked for a person to handle. Because the model sits on the event backbone, each of these is an action it can take in the flow, blocking, retrying, or rerouting, rather than a note left for someone to read after the money is gone.
Oxagile was brought in to extend a payment processing platform that combines gateway, merchant, and business-account services in a single system.
The work centered on one of the platform’s core modules, the layer handling account and transaction management, and covered a partial redesign alongside a set of new features.
The engagement delivered:
Result: A more flexible account and transaction layer without disrupting the platform around it.
The decision to create your own payment gateway is a serious commitment, and for most businesses it is the wrong one.
Where the economics, reach, or control needs genuinely force taking this direction, success depends less on the checkout API than on the invariants underneath it. We’re talking about exact decimal money, safe retries, a domain-owned state machine, and a PCI boundary kept deliberately small. Get those right and the platform stays cheap to secure and operate. Get them wrong and nothing downstream recovers it.
The other half of the decision is honesty about the run-rate. The build is finite, but the audits, scheme mandates, on-call, and team are not. Budget for the platform you will operate, because the one you launch is only the starting point.
Our payments engineers and fintech architects work from a proven production base. Reach out to discuss your volume, target markets, and the build-versus-buy math for your case.
Realistically from a few months to well over a year, and the clock is driven by integration and certification than by writing the gateway itself. Starting from a proven base, the core comes together fast, and what remains is mostly processor integration and brand or scheme certification, which run on their own timelines.
Building everything from scratch points you at the long end. On a base where the engine and PCI controls already exist, a pilot lands near the short end.
There are three main cases:
Below that threshold, integrating an existing provider is faster, cheaper, lower-risk, and the most honest answer for most businesses.
Defense in depth is the right model. Score each transaction inline before authorization with a risk model, layer EMV 3-D Secure, velocity rules, and device signals on top, and run continuous event-stream monitoring behind it for anomalies, linked-account patterns, and AML or sanctions screening if you hold funds. Fold reconciliation in as well, since the gap between authorized and settled is where leakage tends to hide.
