What building a payment gateway actually means

Building a payment gateway means creating the software layer that sits between a customer, a merchant, and the banks or payment networks that move money. You are not building the entire financial infrastructure—you are building the piece that accepts a payment method (card, bank account, digital wallet), validates it, sends it to the right processor, and tells the merchant whether the transaction succeeded or failed.

Most businesses do not build their own gateway from scratch. Instead, they integrate an existing one—Stripe, Square, PayPal, Adyen—into their website or app. But if you are building a gateway because you need custom routing, you serve a specific industry with unusual requirements, or you want to offer payment services to other merchants, you need to understand the actual technical and legal work involved.

The core job is the same regardless of scale: accept payment data securely, validate it against fraud rules, route it to an acquiring bank or processor, handle the response, and store the transaction record. Everything else—compliance, security, dispute handling—flows from those steps.

Key Takeaways

  • A payment gateway is the software that accepts payment data, validates it, and sends it to a processor or bank—not the entire payment system.
  • You must obtain a merchant account from an acquiring bank and integrate with a payment processor or card network to move real money.
  • PCI DSS compliance is mandatory if you handle card data directly; most builders use tokenization or hosted payment forms to avoid this burden.
  • You need to build fraud detection, handle declines and retries, store transaction records securely, and manage disputes—these are not optional features.
  • Most new payment businesses start by reselling or white-labeling an existing gateway rather than building infrastructure from zero.

The technical architecture you need to build

A working payment gateway has four main layers: the front end (where the customer enters payment data), the tokenization layer (which converts sensitive data into a token), the routing engine (which decides where to send the transaction), and the settlement layer (which records what happened and when money moves).

The front end is usually a form or modal that collects card number, expiration, CVV, and billing address—or it accepts data from a digital wallet like Apple Pay or Google Pay. This form must run over HTTPS and never send raw card data to your own servers. Instead, it sends data directly to a tokenization service (your own or a third party's) that returns a token—a random string that represents the card without exposing the actual number.

The routing engine receives that token and decides where to send it: to Visa, Mastercard, American Express, or a specific acquiring bank. This decision depends on which networks and processors you have contracts with, which ones offer the best rates for this transaction type, and whether you are routing based on card type, merchant location, or transaction size.

The settlement layer records every transaction in a database, tracks its status (pending, approved, failed, disputed), and reconciles what your processor told you happened against what actually cleared through the banking system. This is where you catch processor errors, duplicate charges, and chargebacks.

Compliance and security requirements that are non-negotiable

PCI DSS (Payment Card Industry Data Security Standard) is the rulebook for anyone handling card data. Compliance is not optional—it is a condition of your merchant account and your processor contract. The standard has four levels based on transaction volume, and even Level 4 (under 20,000 transactions per year) requires annual self-assessment, vulnerability scanning, and written security policies.

If you handle raw card data on your servers, you must meet Level 1 or 2 compliance, which means annual third-party audits, penetration testing, and a dedicated security team. Most builders avoid this by using tokenization: you never store the card number itself, only the token. This drops your compliance burden significantly because you are no longer a "cardholder data processor."

Beyond PCI, you need to encrypt all data in transit (TLS 1.2 or higher), encrypt sensitive data at rest, implement strong access controls so employees cannot see customer card data, and maintain audit logs of who accessed what and when. You also need a data breach response plan—if card data leaks, you must notify affected customers and your processor within specific timeframes (usually 30 to 60 days).

Fraud detection is a compliance issue and a business one. You must implement 3D Secure (Visa Secure, Mastercard Identity Check) for online card transactions—this adds a second authentication step and shifts liability for fraud to the card issuer if the customer completes it. You also need velocity checks (reject multiple failed attempts from the same card in minutes), address verification (AVS), and CVV matching. Many builders use a third-party fraud service like Kount or Sift rather than building detection rules themselves.

Obtaining a merchant account and processor contracts

You cannot move real money without a merchant account from an acquiring bank. This is a business bank account specifically for payment processing. The bank underwrites you—they check your business registration, your owners' credit, your processing history if you have one, and your industry risk profile. High-risk industries (gambling, adult content, cryptocurrency) face higher fees or outright rejection.

The acquiring bank does not move money directly to customers. Instead, they contract with a payment processor (Stripe, Square, First Data, Global Payments) who handles the technical integration, fraud screening, and daily settlement. You sign agreements with both the bank and the processor, and both take a cut of every transaction—usually 2.2% to 3.5% plus $0.30 per transaction for card payments, higher for international or high-risk transactions.

If you are building a gateway to serve other merchants (a payment service provider or PSP model), you need a master merchant account and the ability to create sub-merchant accounts under it. This requires a higher underwriting bar and separate contracts with your processor that allow you to on-board and off-board merchants programmatically. Stripe Connect and Square are examples of platforms that do this; building it yourself requires processor approval and technical integration with their sub-merchant APIs.

Expect the merchant account application to take two to four weeks. Have ready: business license, articles of incorporation, personal identification for all owners, bank statements for the past three months, and a description of your business model and expected monthly volume.

Building the transaction flow and handling failures

A transaction starts when a customer submits payment data. Your gateway receives it, tokenizes it, and sends it to the processor with metadata: merchant ID, amount, currency, order ID, customer email, billing address, and any fraud signals you have collected. The processor sends it to the card network (Visa, Mastercard, Amex), which routes it to the customer's bank (the issuer).

The issuer approves or declines based on available funds, fraud rules, and whether the customer has flagged the transaction as suspicious. The response comes back through the network to the processor to your gateway in seconds. Your gateway stores the response (approval code, decline reason, network reference number) and returns it to the merchant's website or app.

If the transaction is approved, money does not move immediately. Instead, the processor batches all approved transactions and settles them once per day (usually overnight), moving the funds to the merchant's bank account minus fees. This settlement lag is why a customer's bank statement may show a pending charge for a day or two after purchase.

Declines happen for many reasons: insufficient funds, card expired, fraud block, processor error, or network timeout. Your gateway must retry failed transactions intelligently—some declines are temporary and worth retrying in seconds; others are permanent. You also need to handle soft declines (the issuer rejected it but the customer can try again) differently from hard declines (the card is closed or stolen). Most processors provide a decline code that tells you which is which.

Timeouts are the hardest case: your gateway sends the transaction but never receives a response before the connection closes. You do not know if the transaction went through. Your code must handle this by querying the processor for the transaction status using the order ID, and either completing it or rolling it back depending on what the processor says happened.

Storing transaction records and handling disputes

Every transaction must be stored in a database with: transaction ID (yours and the processor's), merchant ID, amount, currency, card token (never the raw card number), approval code, timestamp, customer email, billing and shipping address, and the response from the processor. This record is your proof of what happened and your defense against disputes.

Disputes (also called chargebacks) happen when a customer tells their bank the transaction was unauthorized or the product never arrived. The bank pulls the transaction record from you and asks the merchant to prove the charge was legitimate. If the merchant cannot prove it, the bank reverses the charge and the merchant loses the money plus a chargeback fee (usually $15 to $100).

Your gateway must make it easy for merchants to retrieve transaction records, download statements, and export data for their accounting system. You also need to notify merchants when a chargeback is filed so they have time to respond. Most processors handle chargeback management, but you need to integrate their chargeback API so merchants can see disputes in your dashboard and upload evidence (shipping proof, customer communication, delivery confirmation).

Chargebacks are expensive and common. A merchant with a chargeback rate above 1% may lose their processor contract. Your gateway should flag high-risk transactions and help merchants reduce chargebacks through better order confirmation, shipping tracking, and customer communication.

Deciding between building from scratch and reselling an existing gateway

Building a payment gateway from zero means writing code to handle tokenization, routing, settlement reconciliation, fraud detection, and compliance reporting. It also means hiring security engineers, passing annual audits, and maintaining uptime 24/7 because payment processing never stops. Most companies that do this are large financial institutions or payment networks themselves.

A more realistic path is to resell or white-label an existing gateway. You integrate Stripe, Square, or Adyen into your product, customize the branding and user experience, and take a margin on top of their fees. You handle customer support and merchant on-boarding; the processor handles the infrastructure, compliance, and settlement. This lets you launch in weeks instead of years and avoids the security and regulatory burden of handling card data yourself.

Another option is to build on top of a payment platform API. Stripe, for example, offers APIs for creating custom payment flows, managing disputes, and building merchant dashboards. You write the business logic and user experience; Stripe handles the hard parts. This is how most modern payment startups work.

If you genuinely need to build your own gateway—because you serve a niche market, need custom routing, or want to offer payment services to other merchants—start by integrating an existing processor's API first. This teaches you how payment flows work and what compliance looks like. Then, if you still need custom infrastructure, you have a foundation and a clearer picture of what to build.

Frequently Asked Questions

Do I need to build my own gateway or can I just use Stripe?

Most businesses should use Stripe, Square, or a similar processor. They handle compliance, fraud, settlement, and disputes. You only build your own if you need features they do not offer, serve merchants they will not accept, or want to resell payment services to other businesses.

What happens if my gateway goes down during a transaction?

If your gateway times out, the transaction status is unknown. Your code must query the processor to learn about it went through, then either confirm it to the customer or roll it back. Never assume a timeout means the transaction failed—many actually succeeded.

Can I store credit card numbers in my database?

No. You must use tokenization—convert the card number to a token and store only the token. Storing raw card numbers makes you responsible for Level 1 PCI compliance, which requires annual audits and is expensive. Tokenization shifts that burden to the processor.

How long does it take for money to reach my bank account?

Most processors settle once per day, usually overnight. Money reaches your merchant account the next business day. Some processors offer faster settlement (same-day or next-day) for a higher fee. Weekends and holidays delay settlement by one day.

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

A gateway is the software that accepts payment data and routes it. A processor is the company that moves the money—they connect to banks and card networks. Most gateways are built by or integrated with a processor. You need both to accept payments.