You cannot build a payment gateway alone—you need a bank, a processor, and a network

A payment gateway is not software you write and deploy. It is a set of connections: your business connects to a payment processor, which connects to a bank, which connects to Visa, Mastercard, or another card network. If you want to accept payments, you either plug into an existing gateway (Stripe, Square, PayPal) or you build the merchant-facing layer on top of one. You cannot replace the processor or the bank—those are licensed, regulated entities that handle the actual money movement.

What you can build is the interface your customers see, the backend logic that decides what happens when a payment arrives, and the integration that talks to the processor's API. This is useful if you have unusual payment flows, need to combine multiple payment methods, or want to avoid paying per-transaction fees to a third-party gateway. But it still requires you to contract with a processor and a bank, and it requires you to handle security standards that most small businesses should not attempt alone.

Key Takeaways

  • You must contract with a payment processor and a bank to move money; you cannot build those parts yourself.
  • Building your own gateway means writing code that talks to the processor's API, handles customer data securely, and logs transactions—not replacing the processor.
  • PCI DSS compliance is mandatory if you touch card data, and the security burden is substantial enough that most businesses should use a hosted solution instead.
  • The cost of building and maintaining your own gateway is usually higher than using Stripe or Square unless you process millions of dollars per month.
  • You need a merchant account with a bank and a processor agreement before you write a single line of code.

What a payment processor actually does, and why you need one

A payment processor is a company licensed to move money from a customer's bank account or card to your business account. Visa and Mastercard do not deal with individual merchants—they set the rules and run the network. Your processor is the middleman that talks to the card networks, submits transactions for authorization, handles disputes, and deposits money into your bank account.

Examples include First Data, Worldpay, Stripe Connect (which uses a processor behind the scenes), and Square's processor. When you build your own gateway, you are not replacing the processor. You are writing code that formats your transaction data, sends it to the processor's API, receives an authorization response, and stores the result. The processor still does the actual work of moving money.

You need a processor agreement before you can accept any payments. This agreement spells out your fees, your chargeback liability, and the data you are allowed to store. Most processors will not sign an agreement with you unless you also have a merchant account at a bank—a separate account that receives the deposits and holds reserves in case of chargebacks.

The security and compliance layer you cannot skip

If your code ever touches a customer's card number, expiration date, or CVV, you must comply with PCI DSS (Payment Card Industry Data Security Standard). This is not optional. Visa and Mastercard require it, and your processor will audit you for it. PCI DSS has 12 major requirements: firewalls, encryption, access controls, regular security testing, incident response plans, and more.

Most of these requirements are easier to meet if you use a hosted gateway (like Stripe Hosted Checkout) that never lets your servers touch the card data. If you build your own gateway and handle card data yourself, you must encrypt all card data in transit (TLS 1.2 or higher) and at rest (AES-256 or equivalent), run your servers on a network isolated from the rest of your business, conduct annual penetration testing by a may have access to security firm, maintain detailed logs of who accessed card data and when, have a written incident response plan and test it at least once per year, and restrict card data to the minimum needed for a single transaction, then delete it immediately.

The annual cost of PCI compliance—testing, audits, network isolation, and staff training—is usually $10,000 to $50,000 per year for a small business. If you process less than $10 million per year, this cost almost always exceeds the savings from avoiding third-party gateway fees.

The actual code you would write

If you decide to build your own gateway despite the compliance burden, here is what your code does. First, you collect payment details. Your website or app collects the customer's card number, expiration date, CVV, and billing address. This data never touches your servers directly—instead, you use a tokenization service (provided by your processor) that sends the data directly to the processor and returns a token. Your code stores the token, not the card data.

Second, you format the transaction request. Your code takes the token, the amount, the customer's name, and any other data your processor requires, and formats it according to the processor's API specification. Different processors use different formats (XML, JSON, proprietary), so this step is processor-specific. Third, you send the request and handle the response. Your code sends the formatted request to the processor's API endpoint over an encrypted connection. The processor responds with an authorization code (if approved), a decline reason (if rejected), or an error message (if something went wrong). Your code must handle all three cases.

Fourth, you log the transaction. Your code stores the transaction ID, the amount, the authorization code, the timestamp, and the customer identifier in your database. This log is your proof of what happened and is required for PCI audits and chargeback disputes. Fifth, you trigger fulfillment or error handling. If the transaction was approved, your code tells your fulfillment system to ship the order, send the invoice, or unlock the digital product. If it was declined, your code displays an error message to the customer and offers retry options. This is straightforward if your processor has good API documentation. Most do. The complexity comes from edge cases: what happens if the customer's network drops mid-transaction? What if the processor times out? What if the same transaction is submitted twice? Your code must handle all of these without charging the customer twice or losing the transaction entirely.

When building your own gateway makes financial sense

The break-even point depends on your processor's fees and your transaction volume. Most processors charge a percentage (1.5% to 2.9%) plus a per-transaction fee ($0.20 to $0.30). If you process $100,000 per month, that is roughly $2,000 to $3,000 in fees. If you process $1,000,000 per month, it is $20,000 to $30,000.

Building your own gateway costs money upfront (developer time, security audits, compliance infrastructure) and ongoing (maintenance, security updates, PCI audits). If your upfront cost is $50,000 and your ongoing cost is $20,000 per year, you need to save at least $70,000 in processor fees in the first year to break even. That requires processing roughly $2.5 million per month at typical rates. There are exceptions. If you are a payment processor yourself (like a marketplace or a SaaS platform that lets other businesses accept payments), you may negotiate lower rates with your upstream processor and pass savings to your customers. If you have highly unusual payment flows (like splitting a single payment across multiple accounts), you might save money by building custom logic. But for a typical e-commerce business, the math does not work unless you are very large.

The alternative: using a processor's API without building a full gateway

Many processors offer a middle ground: you use their API to submit transactions, but they handle tokenization, PCI compliance, and the hosted checkout page. Examples include Stripe's Payment Intents API and Square's Payments API. Your code still talks to the processor, but the processor handles the parts that require heavy compliance.

This approach costs less than building a full gateway (you avoid the PCI audit burden) and gives you more control than using a pre-built checkout page. You can customize the payment flow, combine multiple payment methods, and integrate with your own business logic. Most developers choose this route instead of building a gateway from scratch.

What you need before you start

Before you write any code, you need a merchant account at a bank. This is a business checking account that receives deposits from your processor and holds reserves for chargebacks. Your bank will ask for your business license, tax ID, and processing history. You also need a processor agreement. Contact a processor directly (or through a reseller) and negotiate rates and terms. The processor will ask about your business type, your expected monthly volume, and your chargeback history. They will also ask whether you plan to store card data or use tokenization.

You will also need a PCI compliance plan. Before you accept your first payment, decide whether you will handle card data yourself or use tokenization. If you handle card data, hire a security firm to help you design your infrastructure and plan your audit. Finally, have a lawyer review your processor agreement and your privacy policy. Payment processing involves customer data, and the rules vary by state and country.

Frequently Asked Questions

Can I use an open-source payment gateway like OpenCart or WooCommerce?

Yes, but these are not gateways—they are shopping carts that integrate with existing processors. WooCommerce, for example, connects to Stripe, PayPal, and Square. You still need a processor agreement; the open-source software just provides the interface. These are good choices if you want to avoid building your own code.

What happens if I build a gateway without PCI compliance?

Your processor will discover it during an audit or after a data breach, and they will terminate your account. You will also face fines from Visa and Mastercard (up to $100,000 per month in some cases) and potential liability if customer card data is stolen. PCI compliance is not optional.

Can I build a gateway that accepts only certain payment methods, like ACH or wire transfer?

Yes, and these methods have lower compliance burdens than card payments. ACH transfers and wire transfers do not require PCI compliance because the customer's bank account number is not as sensitive as a card number. You still need a processor agreement and a merchant account, but the security requirements are lighter.

How long does it take to build a payment gateway?

The basic integration with a processor's API takes a few days to a few weeks, depending on the processor's documentation and your team's experience. Adding error handling, logging, and testing takes another few weeks. PCI compliance and security audits add months. Most teams should budget three to six months from start to first live transaction.

What if my processor goes out of business?

Your merchant account moves to another processor, but your code may need changes because each processor has a different API. This is one reason to use a processor's API directly rather than building a custom gateway—if you switch processors, you only change the API calls, not your entire payment system.