What you're actually building when you create a payment gateway

A payment gateway is software that sits between a customer's payment method—a credit card, bank account, or digital wallet—and your business's bank account. When you build one, you're creating a system that captures payment data, validates it, sends it to the card networks or banks for approval, and then tells your website or app whether the transaction succeeded or failed. You are not creating the banking infrastructure itself; you are creating the middleman layer that talks to existing banks and payment processors.

Most businesses do not build their own gateway from scratch. Instead, they integrate an existing gateway (Stripe, Square, PayPal) into their website or app using that gateway's code libraries and API documentation. If you are reading this because you want to accept payments online, that integration route is almost always faster and cheaper than building. If you are reading this because you work for a financial institution or a very large merchant and need to understand how gateways work internally, or because you are considering whether to build one, the sections below explain the real technical and regulatory requirements.

Key Takeaways

  • Most businesses integrate an existing payment gateway rather than build one, because building requires banking partnerships, security certifications, and ongoing compliance with payment card industry rules.
  • If you do build one, you need a merchant account with a bank or processor, a connection to card networks (Visa, Mastercard, American Express), and PCI DSS Level 1 certification, which costs tens of thousands of dollars annually.
  • The gateway software itself handles tokenization (storing payment data safely), encryption, fraud detection, and routing transactions to the correct processor—each piece requires separate technical work and testing.
  • Building in-house makes sense only if you process millions of dollars monthly and need custom logic that existing gateways cannot provide, or if you are a processor yourself offering gateways to other merchants.

The banking and processor relationships you need before you write code

Before you build any software, you need a merchant account—a bank account specifically for receiving card payments. You cannot get one by calling your regular bank and asking. You need to explore through a payment processor or acquiring bank, and they will ask for your business registration, your processing history (if any), your average transaction size, and your monthly volume. They will also run a background check.

Once you have a merchant account, you need direct connections to the card networks themselves. Visa, Mastercard, American Express, and Discover each have their own rules, data formats, and approval processes. You cannot talk to them directly as a small business; you go through an acquiring bank or a processor that already has those connections. The processor acts as your translator to the networks. They charge you per transaction (typically 2 to 3 percent plus a flat fee) and handle the settlement—moving money from the card issuer's bank to your merchant account, usually within one to three business days.

If you are building a gateway to sell to other merchants (rather than just for your own business), you also need a sponsorship agreement with an acquiring bank. This agreement lets you act as a middleman: merchants connect to your gateway, your gateway connects to the acquiring bank, and the bank settles funds to your account, which you then distribute to the merchants. This is how companies like Stripe and Square operate. Without this agreement, you cannot legally process payments on behalf of other businesses.

PCI DSS certification and what it actually requires

The Payment Card Industry Data Security Standard (PCI DSS) is a set of rules written by Visa, Mastercard, American Express, and Discover to protect cardholder data. If your gateway touches credit card numbers—even briefly—you must meet PCI DSS requirements. The standard has four levels based on transaction volume. Level 1 (the highest security tier) applies if you process over 6 million transactions per year. Level 4 (the lowest) applies if you process fewer than 20,000 transactions per year.

Level 1 compliance requires an annual audit by a may have access to Security Assessor (QSA), a third-party firm certified by the card networks to inspect your systems. The audit costs $10,000 to $50,000 depending on the size of your operation. You must also pass a quarterly vulnerability scan and maintain detailed logs of who accessed what data and when. Your servers must be in a locked room with cameras. Your employees must sign confidentiality agreements. Your code must be tested for vulnerabilities before it goes live. If you store card data, it must be encrypted both in transit (over the internet) and at rest (on your servers).

Most gateways avoid storing card numbers at all by using tokenization: the customer's card number is sent directly to the processor or a tokenization service, which returns a token—a random string of characters that represents that card. Your gateway stores the token, not the card number. This dramatically reduces your PCI burden because you are no longer storing the sensitive data. However, you still need to may support the connection between your customer and the tokenization service is encrypted, and you still need to audit your code.

The core software components you need to build

A payment gateway consists of several interconnected pieces. The payment form is what the customer sees—the boxes where they enter their card number, expiration date, and CVV. This form must be hosted on an HTTPS connection (encrypted) and must never send the card data to your own servers. Instead, it sends it directly to your processor or a tokenization service using JavaScript. Your servers never see the card number.

The transaction router is the logic that decides where to send each transaction. If a customer pays with a Visa card, it routes to Visa's network. If they pay with an American Express card, it routes to Amex. If they use a digital wallet like Apple Pay or Google Pay, it routes to that wallet's processor. The router also handles retries: if the first attempt fails due to a network hiccup, it tries again automatically.

The fraud detection engine examines each transaction for red flags: Is the billing address the same as the shipping address? Is the card being used in a country different from where it was issued? Is the transaction amount unusually large for this customer? Has this card been reported stolen? You can build this yourself using rules you define, or you can integrate a third-party fraud service like Kount or Sift that uses machine learning to spot patterns you might miss.

The settlement system tracks which transactions succeeded, which failed, and which are still pending. It generates reports for your accounting team and for the acquiring bank. It also handles refunds: when a customer requests their money back, the settlement system reverses the original transaction and moves the money back to their card.

Integration with your website or app

Once the gateway software exists, you need to connect it to your storefront. If you run a website, you use the gateway's API (process programming interface)—a set of code instructions that let your website talk to the gateway. Your website sends the customer's order details to the gateway, the gateway processes the payment, and the gateway sends back a response: success or failure. Your website then shows the customer a confirmation page or an error message.

If you run a mobile app, you use the gateway's mobile SDK (software development kit), which is similar to an API but optimized for phones. The SDK handles the encrypted connection, the tokenization, and the response handling. It also integrates with the phone's built-in payment systems—Apple Pay on iPhones, Google Pay on Android—so customers can pay with a single tap.

Testing is critical. Before you go live, you run thousands of test transactions using fake card numbers that the processor provides. You test successful payments, declined payments, expired cards, and fraud scenarios. You test what happens if the network goes down mid-transaction. You test refunds, partial refunds, and chargebacks. This testing phase typically takes weeks.

Ongoing compliance, monitoring, and support

Once your gateway is live, you do not stop. The card networks release new security standards every few years, and you must update your code to meet them. Visa and Mastercard now require 3D find authentication (a second verification step, like a code sent to the customer's phone) for certain transactions. You must build this into your gateway.

You also need 24/7 monitoring. If your gateway goes down, transactions fail and customers cannot buy anything. You need alerts that notify your team when ready if response times slow down, if error rates spike, or if the connection to the processor drops. You need a backup processor so that if your primary processor has an outage, transactions automatically route to the backup.

Customer support is ongoing. Merchants using your gateway will have questions: Why did this transaction decline? How do I refund a customer? How do I see my settlement report? You need a support team that understands both the gateway and the payment industry. You also need detailed documentation and a sandbox environment where merchants can test their integration before going live.

When building your own makes sense versus when it does not

Building your own gateway makes sense if you are a bank or a large payment processor that needs to offer gateways to thousands of merchants. It makes sense if you process so much volume that the per-transaction fees from an existing gateway cost you millions of dollars annually, and you can save money by building in-house. It makes sense if you need custom logic that no existing gateway provides—for example, if you run a marketplace where different merchants have different fee structures, or if you need to integrate with a legacy banking system that no modern gateway supports.

Building your own does not make sense if you are a small or medium-sized business that just needs to accept payments. The cost of building, certifying, and maintaining a gateway far exceeds the fees you would pay to Stripe, Square, or another existing provider. Even if you process $1 million per month, Stripe's fees (around 2.9 percent plus 30 cents per transaction) are cheaper than the staff, servers, and compliance costs of running your own gateway.

If you are unsure, start by integrating an existing gateway. As your business grows and your needs become more specific, you can revisit the question of building in-house. Most successful payment companies started by integrating existing infrastructure, then built their own gateway only after they had a clear reason to do so.

Frequently Asked Questions

Can I build a payment gateway without a merchant account?

No. A merchant account is your connection to the banking system. Without one, you have nowhere to deposit the money customers pay you. You must explore for a merchant account through a processor or acquiring bank before you write any code.

Do I need PCI DSS certification before I launch?

Yes, if you touch card data. If you use tokenization and never store card numbers on your servers, your PCI burden is lower, but you still need to meet PCI DSS requirements for the parts of your system that do handle data. You cannot launch without being PCI compliant, or the card networks will shut you down.

How long does it take to build a payment gateway?

A basic gateway that handles credit cards and one processor typically takes three to six months for a small team, including testing and compliance work. A production-grade gateway with multiple processors, fraud detection, and support for digital wallets takes a year or more. This assumes you already have the banking relationships in place.

What if I want to accept payments but do not want to build a gateway?

Integrate an existing gateway like Stripe, Square, PayPal, or Authorize.net. These companies have already done the banking, compliance, and fraud work. You add a few lines of code to your website, and you can start accepting payments within hours. This is the path most businesses take.

Can I build a gateway and sell it to other merchants?

Yes, but you need a sponsorship agreement with an acquiring bank, which is harder to get than a merchant account. The bank is taking on more risk because you are processing payments on behalf of other businesses. You also need to meet higher security standards and provide better support. This is a business model for payment processors, not for most merchants.