What a payment gateway actually does, and why building one matters

A payment gateway is the software that sits between a customer, a merchant, and the banks—it captures card data, validates it, sends it to the payment processor, and returns an approval or decline. Building one from scratch means writing the code and infrastructure to handle that entire chain yourself, rather than using Stripe, Square, or another vendor's platform.

You build a gateway when you need control over the exact flow of transactions, when you operate in a region where existing gateways don't work, when your transaction volume is so high that per-transaction fees become prohibitive, or when your business model (like a marketplace or a lending platform) requires you to move money in ways off-the-shelf gateways don't support. Building one is not a shortcut—it is a years-long project that requires hiring security specialists, compliance lawyers, and experienced payment engineers.

This guide covers the actual pieces you need to build, the order in which to build them, the regulatory bodies you will answer to, and the real costs involved. It assumes you have a technical team and a reason that existing gateways will not work for you.

Key Takeaways

  • A payment gateway requires a merchant account with a bank, a processor connection, a secure server to hold encryption keys, and code to validate and route transactions—not just a website.
  • You must obtain PCI DSS compliance certification (a security standard for handling card data), which typically takes six months to a year and costs tens of thousands of dollars.
  • You need a separate acquiring bank (the bank that receives money from customers' cards) and a processor (the company that moves that money to your account), and they are not the same entity.
  • Building the gateway itself is 20 percent of the work; the remaining 80 percent is fraud detection, dispute handling, reconciliation, and regulatory reporting.
  • You must register with card networks (Visa, Mastercard, American Express) or work through a network-registered processor, and this process takes months and involves background checks.

The three separate banking relationships you must establish first

Before you write a single line of code, you need three separate contracts with three separate entities. The first is an acquiring bank—a bank licensed to accept card payments on behalf of merchants. This bank holds the merchant account where customer payments land. They are the ones who will freeze your account if fraud spikes, and they are the ones who will demand proof that you are not running an illegal operation.

The second is a payment processor—a company that handles the technical connection to the card networks (Visa, Mastercard, American Express, Discover). The processor translates your transaction request into the format the card networks understand, sends it through their systems, and returns the result. Stripe, Square, and PayPal are processors. So are smaller companies like Worldpay and Global Payments. When you build your own gateway, you still need a processor to connect you to the networks—you cannot call Visa directly.

The third is a tokenization service or card vault—a separate secure server where you store encrypted card data if you need to charge the same card repeatedly (for subscriptions, for example). You do not store card data on your own servers. You send it to the vault, the vault returns a token, and you store only the token. This separation is a PCI DSS requirement and a practical security measure.

Finding an acquiring bank willing to work with you is the hardest part. Most banks have underwriting teams that will reject you if your business model looks risky (high refund rates, subscription services, international transactions, or anything they have not seen before). You will need a business license, tax ID, bank statements showing revenue, and often a personal may provide from the founder. The process takes two to four months.

PCI DSS compliance: the legal requirement that shapes everything

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements written by Visa, Mastercard, American Express, and Discover. It dictates how you must store, transmit, and handle card data. Compliance is not optional—your acquiring bank will not sign with you without it, and your processor will not connect to you without proof of it.

PCI DSS has six levels, based on transaction volume. If you process fewer than 20,000 Visa transactions per year, you are Level 4 and can self-assess using a questionnaire. If you process more, you must hire a may have access to Security Assessor (QSA)—a third-party firm certified by the card networks to audit your systems. A QSA audit costs $15,000 to $100,000 depending on the size of your operation, and it takes three to six months. You will need to pass it annually.

The standard requires you to use encryption for all card data in transit and at rest, to segment your network so card data never touches your web servers, to log all access to systems that touch card data, to run regular penetration tests (hiring hackers to attack your systems), and to have a written incident response plan. If you store card data yourself (which you should not), you must use tokenization or encryption so that even if someone steals your database, the card numbers are useless.

Most teams building a gateway hire a security consultant for the first year to design the architecture correctly. Retrofitting security later costs far more than building it in from the start.

The technical architecture: what code you actually write

Your gateway needs four core pieces: a payment form (the interface where customers enter card data), a transaction engine (the code that validates and routes transactions), a processor connector (the code that speaks to your processor's API), and a reconciliation system (the code that matches what you sent to what the processor confirmed).

The payment form should never touch your servers directly. Instead, use a hosted payment page or iframe provided by your processor or tokenization service. The customer enters their card on that page, the processor tokenizes it, and only the token comes back to your servers. This keeps card data off your infrastructure and dramatically simplifies PCI compliance.

The transaction engine is where you write business logic: checking that the customer has enough funds (if you are a lending platform), applying fraud rules (declining transactions from new cards in high-risk countries, for example), splitting payments across multiple accounts (if you are a marketplace), and logging every decision for later audit. This is where most of your code lives.

The processor connector is an API client that speaks to your processor's API. You send a transaction request with the tokenized card, the amount, the merchant ID, and metadata. The processor returns a response code (approved, declined, error), a transaction ID, and a timestamp. You store all of this in your database and return a result to the merchant's website.

The reconciliation system is critical and often overlooked. Every night, your processor sends you a settlement file listing every transaction they processed, the fees they charged, and the net amount they deposited into your acquiring bank account. You must match this file against your own transaction log. Discrepancies mean fraud, processor errors, or bugs in your code. Most teams spend weeks building reconciliation logic and months debugging it.

Fraud detection and dispute handling: the work that never ends

Once transactions start flowing, fraud starts flowing too. You need a fraud detection system that flags suspicious transactions before they settle. This can be as simple as rules (decline any transaction over $5,000 from a new card, decline any card used in five different countries in one day) or as complex as machine learning models trained on your own transaction history.

Most teams start with rules and add machine learning later. You can also buy fraud detection from vendors like Kount, Sift, or Forter, which use their own models trained on billions of transactions. This costs $500 to $5,000 per month depending on volume, but it is often cheaper than hiring a data scientist.

Disputes are transactions that customers contest. A customer claims they did not authorize a charge, or they claim they were charged twice, or they claim the merchant never delivered the goods. The customer's bank (the issuing bank) opens a dispute and asks your processor for evidence. You have 7 to 10 days to respond with proof: an email from the customer authorizing the charge, a shipping confirmation, a delivery signature, anything that shows the transaction was legitimate. If you lose the dispute, the money goes back to the customer and you pay a chargeback fee (usually $15 to $100).

You need a system to track disputes, store evidence, and generate responses. Most processors provide a portal where you can upload evidence, but you should also build your own system so you can analyze patterns. If your chargeback rate exceeds 1 percent of transactions, your acquiring bank will shut you down. If it exceeds 0.5 percent, they will charge you a penalty fee.

Card network registration and ongoing compliance reporting

Visa, Mastercard, American Express, and Discover each require you to register as a merchant or a service provider (depending on whether you process your own transactions or process on behalf of others). Registration involves background checks, proof of PCI compliance, and annual fees. Mastercard charges $500 to $2,500 per year depending on your volume. Visa charges $1,000 to $5,000. American Express charges separately.

Once registered, you must submit quarterly compliance reports to each network. These reports show your transaction volume, your chargeback rate, your fraud rate, and your PCI compliance status. If any metric looks bad, the network can fine you, require you to hire a consultant, or terminate your registration.

You also must maintain a Risk Management Program—a written document describing how you detect fraud, how you handle disputes, how you monitor for money laundering, and how you respond to security breaches. This is not a one-time document; you update it annually and submit it to your processor and acquiring bank.

The real timeline and cost of building a gateway

Most teams underestimate both. Here is what actually happens:

Months 1 to 3: Find an acquiring bank and processor willing to work with you. This is the bottleneck. You will be rejected by five banks before one says yes. Cost: $0 to $5,000 in consulting fees to help with applications.

Months 3 to 6: Design your architecture, hire a security consultant, and begin building. You will spend most of this time on security, not on features. Cost: $50,000 to $150,000 in engineering and consulting.

Months 6 to 9: Build the core transaction engine and processor connector. Test extensively in the processor's sandbox environment. Cost: $100,000 to $300,000 in engineering.

Months 9 to 12: Hire a QSA and undergo PCI compliance audit. Fix any gaps they find. Cost: $15,000 to $100,000 for the audit, plus engineering time to remediate.

Months 12 to 15: Go live in production with a small volume of test transactions. Monitor closely for bugs and fraud. Cost: $50,000 to $150,000 in engineering and monitoring.

Months 15+: Scale up, build fraud detection, build dispute handling, build reconciliation, and maintain compliance. Cost: $200,000 to $500,000 per year in ongoing engineering and compliance.

Total first-year cost: $400,000 to $1,000,000. Total ongoing cost: $200,000 to $500,000 per year. These are realistic numbers for a team of four to six people. Larger teams cost more.

When to use an existing gateway instead

Building a gateway makes sense if you process millions of dollars per month and per-transaction fees would cost you more than building and maintaining your own system. It makes sense if you operate in a region where existing gateways do not work. It makes sense if your business model requires you to move money in ways existing gateways do not support (like a marketplace that splits payments between multiple merchants).

It does not make sense if you are a startup, if you process less than $1 million per month, or if you just want to avoid paying Stripe's fees. The fees exist because Stripe handles fraud, disputes, compliance, and security for you. Building your own means you handle all of that yourself, and the cost is higher than you think.

Frequently Asked Questions

Can I build a gateway without getting PCI DSS certified?

No. Your acquiring bank will not sign with you, and your processor will not connect to you without proof of compliance. PCI DSS is a requirement from the card networks, not a suggestion. You can delay certification by using a hosted payment page (so card data never touches your servers), but you still need to pass a Level 1 or Level 2 assessment depending on your volume.

Do I need to register with all four card networks?

Not directly. Your processor is registered with the networks and handles most of the registration on your behalf. However, you still need to register as a merchant or service provider with each network, and each one has its own application and fees. Your processor can guide you through this, but you cannot skip it.

What happens if my gateway gets hacked?

You must notify your acquiring bank, your processor, and the card networks within 72 hours. You must hire a forensics firm to determine what was stolen. If card data was compromised, you must notify every customer whose card was affected and offer them free credit monitoring. You will face fines from the card networks, potential lawsuits from customers, and possible shutdown by your acquiring bank. This is why security is not optional.

Can I process transactions without a merchant account?

No. A merchant account is a bank account specifically licensed to accept card payments. Without it, you have no way to receive money from customers' cards. You cannot use a personal bank account or a business checking account—they will reject card transactions. You must have a merchant account with an acquiring bank.

How long does it take to go live?

Realistically, 12 to 18 months from the day you start talking to banks to the day you process your first real transaction. Most of that time is spent on compliance, security, and getting banks to say yes. The actual coding takes three to six months. Plan accordingly.