What building a payment gateway actually means

Building a payment gateway means creating the software infrastructure that sits between a customer's payment method (card, bank account, digital wallet) and your business's bank account. You are not creating the payment network itself — Visa, Mastercard, and ACH already exist. You are building the middleman that talks to those networks, handles the data securely, and tells your store whether a transaction succeeded or failed.

Most businesses do not build their own gateway. They use one that already exists — Stripe, Square, PayPal, or a processor specific to their industry. Building one yourself makes sense only if you process enough volume that the per-transaction fees become expensive, or if your business model (like a marketplace or payment service) requires you to move money between many accounts in ways existing gateways do not support.

If you are asking this question because you want to accept payments on your website, you almost certainly do not need to build a gateway. You need to integrate with one that exists. The distinction matters because it changes what you actually need to do.

Key Takeaways

  • Building a payment gateway requires acquiring a merchant account from a bank or processor, integrating with card networks or ACH rails, and handling PCI DSS compliance — a security standard that costs money and time to maintain.
  • Most businesses use an existing gateway instead because the per-transaction cost is lower than the infrastructure cost of building one, unless you process millions of dollars monthly.
  • If you want to accept payments on your website or app, you integrate with an existing gateway using their API — you do not build a new one.
  • Building a gateway requires a banking relationship, a payment processor license in some states, and the ability to hold customer funds in a settlement account while transactions clear.
  • The technical work is smaller than the regulatory and banking work — compliance, fraud prevention, and settlement reconciliation take longer to set up than the code.

The banking and licensing layer you need first

Before you write any code, you need a merchant account — a bank account that can receive card payments. You cannot get this from your regular business bank. You need it from a processor or acquiring bank that has signed agreements with Visa and Mastercard. They will ask for your business license, tax ID, processing history (if you have one), and expected monthly volume. If you are new, they will want to know what you sell and may require a reserve account where they hold a percentage of your deposits for 6 to 12 months.

Some states require a money transmitter license if you will be holding customer funds or moving money between accounts on behalf of others. This is different from a merchant account. If you are building a marketplace, a payroll platform, or anything where you temporarily hold money that belongs to someone else, you likely need this license. The requirements vary by state — some require it, some do not, and some have exemptions for certain business types. You need to check with your state's financial regulator before you start.

You also need a settlement account — the bank account where customer payments actually land. This is separate from your operating account. Transactions take one to three business days to settle, so you need a place to hold them while they clear and while you reconcile them against your records.

Connecting to card networks and payment rails

Once you have a merchant account, your processor gives you credentials to connect to the card networks. You do not connect directly to Visa or Mastercard. You connect through your processor's API, which handles the routing. Your code sends transaction data (card number, amount, merchant ID) to your processor's server. Their server routes it to the card network, which checks with the cardholder's bank, and the bank sends back an approval or decline.

This happens in seconds. Your code waits for the response and tells your store whether to complete the order. If you also want to accept bank transfers (ACH in the US), you connect to an ACH network through your processor in the same way — you send account and routing numbers, they route to the Federal Reserve's ACH system, and you get back a response in one to two business days.

The processor handles tokenization — the practice of storing a reference to a card instead of the card number itself. This is critical for security. You never store raw card data. Instead, the processor gives you a token, and you store that token. When you need to charge the card again, you send the token, not the card number. This keeps you out of PCI scope for stored data.

PCI DSS compliance and why it costs

PCI DSS (Payment Card Industry Data Security Standard) is a set of security rules you must follow if you handle card data. Even if you use tokenization and never store card numbers, you still handle card data in transit — when the customer enters it on your checkout page. PCI DSS requires encryption, firewalls, access controls, regular security testing, and annual audits. The cost depends on your volume and architecture.

If you process fewer than 20,000 transactions per year, you can often meet PCI DSS requirements by using a hosted payment form (a page the processor hosts, not you) and paying for an annual self-assessment. This costs a few hundred dollars per year. If you process more, or if you build your own checkout page, you need a quarterly vulnerability scan and an annual penetration test. These cost $1,000 to $5,000 per year depending on your processor and the complexity of your system.

If you build a full gateway and handle card data at scale, you need a may have access to Security Assessor (QSA) to audit you annually. This costs $5,000 to $15,000 per year. You also need to maintain a security incident response plan, train staff on data handling, and document everything. The compliance work never stops.

Fraud detection and chargeback management

When you process payments, you are liable for fraud. If a customer disputes a charge, the card network investigates and either sides with you or forces you to refund the money. If you lose too many disputes (called chargebacks), your processor can terminate your account. This is why fraud prevention is not optional — it is part of building a working gateway.

You need rules that catch obvious fraud: a card used in two countries in one hour, a card used by five different IP addresses in one day, a card used to buy $10,000 worth of gift cards. You also need velocity checks — how many transactions from this card, this email, this IP address in the last hour. These rules are complex and change constantly as fraud patterns evolve. Most gateways use machine learning models trained on millions of transactions to score the risk of each new transaction.

You also need to handle chargebacks when they happen. When a customer disputes a charge, the card network sends you a notice. You have 7 to 10 days to respond with evidence that the transaction was legitimate — an order confirmation, a shipping receipt, proof of delivery, or a signed contract. If you lose the dispute, you refund the customer and pay a chargeback fee (usually $15 to $100 per dispute). If you lose too many, your processor raises your rates or closes your account.

The technical architecture and API design

The code itself is smaller than the regulatory layer, but it still matters. Your gateway needs an API that merchants can call to create transactions, refund them, check their status, and retrieve settlement reports. The API needs to be stateless (each request contains all the information needed to process it), fast (merchants expect responses in under 500 milliseconds), and reliable (99.9% uptime is standard).

You need a database to store transaction records, customer tokens, and settlement data. You need a queue system to handle the asynchronous work — sending a transaction to the card network, waiting for the response, updating your database, and sending a webhook to the merchant's system to tell them the result. You need monitoring and alerting so you know when ready if something breaks. You need logging so you can debug problems and prove to auditors that you handled data correctly.

You also need an admin dashboard where merchants can see their transactions, refund them, read settlement reports, and manage their account settings. This is not complex code, but it is tedious and straightforward to get wrong. A merchant who cannot find a transaction or cannot refund a customer will leave you for a competitor.

When building your own actually makes sense

You should consider building a gateway if you process more than $10 million per year and the per-transaction fees from existing gateways exceed your cost of building and maintaining your own infrastructure. At that volume, you can negotiate a lower rate directly with a processor, and you can afford the engineering team to build and maintain the system.

You should also consider it if you are building a marketplace or a payment service where you need to move money between many accounts in ways existing gateways do not support. Stripe Connect and PayPal Commerce Platform handle some of this, but if your business model is unique, you may need custom infrastructure.

You should not build one if you are a small business that wants to accept payments on your website. Use Stripe, Square, or another existing gateway. The cost per transaction is lower, the compliance burden is lighter (they handle PCI DSS), and you can launch in days instead of months. The time you save is worth far more than the fees you pay.

Frequently Asked Questions

Do I need a payment gateway to sell online?

You need a way to accept payments, but you do not need to build a gateway. You need to integrate with an existing one. Most online stores use Stripe, Square, PayPal, or a processor specific to their industry. Integration takes a few hours to a few days depending on your platform.

What is the difference between a payment gateway and a payment processor?

A gateway is the software that handles the transaction — it takes the customer's payment information and routes it to the processor. A processor is the company that actually moves the money — they have the merchant account, the bank relationships, and the connection to the card networks. Most gateways are built by processors or work closely with them.

Can I build a payment gateway without a banking license?

You can build the software, but you cannot operate it without a merchant account and, in many states, a money transmitter license. The banking relationship is the hard part. The code is just the tool that uses it.

How long does it take to build a payment gateway?

The code takes three to six months if you have an experienced team. The banking and licensing takes two to six months in parallel. The compliance and security work takes another three to six months. Total: six months to a year before you can process your first real transaction. Most businesses use an existing gateway instead because it launches in days.

What happens if I process a fraudulent transaction?

You are liable. The cardholder disputes it, the card network investigates, and if they side with the cardholder, you refund the money and pay a chargeback fee. If you have too many chargebacks, your processor can raise your rates or close your account. This is why fraud detection is critical.