What you actually need to do to build a payment gateway

Building a payment gateway means creating the software that sits between a customer, a merchant, and the banks—it captures card data, encrypts it, sends it to the card networks, and tells the merchant whether the transaction went through. You cannot do this alone in a garage. You need a payment processor (the company that actually moves money), a bank sponsor (a real bank that holds the merchant accounts), compliance infrastructure, and engineers who understand encryption and PCI standards. Most people who think they want to "build a gateway" actually want to build a payment application on top of an existing gateway—a shopping cart, an invoicing tool, or a point-of-sale system that plugs into Stripe, Square, or another established processor.

If you genuinely need to build infrastructure-level software, you are either a large financial institution, a payment processor yourself, or you need to partner with one. This article covers both paths: what it takes to build a true gateway from the ground up, and the more realistic route of building a payment application that uses someone else's gateway.

Key Takeaways

  • A true payment gateway requires a bank sponsor, a payment processor partner, PCI compliance certification, and millions in capital—most startups build applications on top of existing gateways instead.
  • Building a payment application (shopping cart, invoicing tool, point-of-sale) means integrating with an existing gateway's API and handling the merchant onboarding and customer experience yourself.
  • PCI DSS compliance is mandatory if you touch card data; most developers avoid this by using tokenization, which lets the gateway handle the sensitive data.
  • You need a merchant account, a processor agreement, and legal documentation covering fraud liability, chargebacks, and data security before you can accept any payment.
  • The fastest path to market is using a hosted payment form (like Stripe Hosted Checkout) rather than building your own card entry interface.

The difference between a gateway, a processor, and a payment application

A payment gateway is the software infrastructure that authorizes transactions. It receives encrypted card data, validates it against the card networks (Visa, Mastercard, Amex), checks for fraud, and returns an approval or decline. Building one requires a banking license or a partnership with a bank, because the gateway must connect directly to the card networks and the Automated Clearing House (ACH) system. Stripe, Square, and PayPal all operate their own gateways.

A payment processor is the company that actually moves the money. It holds merchant accounts, settles funds into the merchant's bank account, handles chargebacks, and manages the relationship with the acquiring bank. A processor and a gateway often work together—sometimes they are the same company, sometimes they are separate.

A payment application is what most people can realistically build. It is the user interface and business logic on top of a gateway—a shopping cart that collects order details, an invoicing system that sends payment links, a point-of-sale app that takes card payments in a store. You build the application, integrate it with an existing gateway's API, and let the gateway handle the actual transaction. This is what Shopify does (it uses its own gateway but also integrates with others), what Square does for third-party developers, and what thousands of smaller companies do.

Building a payment application: the realistic path

Start by choosing a gateway partner. The major options are Stripe, Square, PayPal, Authorize.Net, and Adyen. Each has an API, documentation, and a sandbox environment where you can test without real money. Stripe and Square are the most developer-friendly; Authorize.Net is older but widely used; Adyen is built for high-volume merchants.

Read the gateway's API documentation and build your integration. You will need to handle several flows: creating a customer record, tokenizing a card (storing a reference to it without storing the card number itself), charging the token, handling refunds, and managing webhooks (notifications when a payment succeeds or fails). Most gateways provide client libraries in Python, Node.js, Ruby, PHP, and other languages, so you do not write the encryption yourself.

Decide whether to use a hosted payment form or build your own card entry interface. A hosted form (like Stripe Hosted Checkout or Square Payment Form) means the customer enters their card on a page the gateway controls, not your page. This keeps you out of PCI scope—you never touch the card data. Building your own card entry field requires PCI DSS Level 1 compliance, which is expensive and complex. Use the hosted form unless you have a specific reason not to.

Set up a merchant account with the processor. This is the bank account where funds land after a transaction. You will need to provide business documents, tax ID, bank details, and sometimes a processing history. The processor will ask about your business model, your expected monthly volume, and your industry (some industries like gambling or adult content are higher-risk and harder to board). Approval typically takes three to five business days.

PCI compliance and data security

PCI DSS (Payment Card Industry Data Security Standard) is a set of rules that anyone handling card data must follow. It covers encryption, network security, access controls, and audit trails. There are four compliance levels based on how many transactions you process per year. Level 1 (over 6 million transactions annually) requires a full audit by a may have access to security assessor. Level 4 (under 20,000 transactions annually) requires a self-assessment questionnaire.

The easiest way to stay compliant is to never touch the card data yourself. Use tokenization: the customer's card is sent directly to the gateway (encrypted, over HTTPS), the gateway returns a token (a random string), and you store and charge the token. The gateway holds the actual card number in a secure vault. This keeps you out of PCI scope entirely, or at least at the lowest level.

If you must build your own card entry interface, you need to encrypt the card data before it leaves the customer's browser, use HTTPS everywhere, maintain a firewall, conduct regular security audits, and document everything. This costs tens of thousands of dollars per year and requires hiring security expertise. Most startups avoid this by using a hosted form or a pre-built payment library that handles encryption client-side.

Legal and financial setup before launch

You need a merchant services agreement with your processor. This document specifies the transaction fees (usually 2.2% to 3.5% plus a per-transaction fee), the settlement schedule (usually next business day), and the chargeback liability. Read it carefully—some processors hold you liable for all chargebacks; others cap your liability or share it.

You need terms of service that explain to your customers how you handle their payment data, what happens if a transaction fails, and what your refund policy is. You need a privacy policy that describes what data you collect and how you use it. If you are in the EU or UK, you need to comply with GDPR or UK GDPR, which means getting explicit consent to store payment data and allowing customers to request deletion.

You need fraud detection rules. Most gateways provide built-in fraud tools (velocity checks, address verification, 3D Secure), but you should also implement your own logic: flag transactions from new customers, flag large orders, flag orders shipping to a different address than the billing address. Document your fraud rules so you can explain them if a customer disputes a decline.

You need chargeback handling procedures. When a customer disputes a charge with their bank, the bank asks you for proof that the transaction was legitimate. You need to keep order records, shipping confirmations, and customer communication for at least 18 months. If you lose a chargeback dispute, you pay the chargeback fee (usually $15 to $100) plus the transaction amount.

Technical architecture and testing

Your application needs to handle several failure modes: the gateway is down, the customer's bank declines the card, the network connection drops mid-transaction, the customer closes their browser before the payment completes. Build your system so that a failed payment does not leave the customer charged but the order unfulfilled, or vice versa.

Use the gateway's sandbox environment to test every scenario: successful charge, declined card, expired card, insufficient funds, 3D Secure challenge, refund, partial refund, and timeout. Write automated tests so that when you deploy new code, you know the payment flow still works. Many payment bugs happen because a developer changed something unrelated and broke the webhook handler.

Implement idempotency: if the same payment request is sent twice (because the customer clicked submit twice, or because of a network retry), the gateway should charge only once. Most gateways support this through an idempotency key—a unique identifier you send with each request. If the request is retried, the gateway recognizes the key and returns the same result without charging again.

Log all payment events (charge attempt, success, failure, refund) with timestamps and transaction IDs. Do not log card numbers or CVV codes. These logs are essential for debugging, for customer service, and for proving compliance if you are audited.

Scaling and choosing between white-label and custom

As you grow, you may outgrow a single gateway. Some merchants need multiple payment methods (card, ACH, wallet, buy-now-pay-later). Some need to operate in multiple countries with different currencies and regulations. At this point, you have two choices: integrate with multiple gateways (complex, but gives you flexibility), or switch to a payment orchestration platform (like Spreedly or Adyen) that sits between your application and multiple gateways and routes transactions intelligently.

You may also consider a white-label gateway—a gateway that you rebrand and resell to your own customers. This requires a much deeper partnership with the processor, higher volume commitments, and more complex compliance. It is not a realistic option for a startup unless you are building a platform specifically for payment processing (like a point-of-sale system for restaurants, or an invoicing platform for accountants).

For most payment applications, the path is: start with one gateway (Stripe or Square), build your application on top of it, integrate additional gateways only when a customer specifically needs them, and use a payment orchestration platform only when you have enough volume to justify the cost.

Frequently Asked Questions

Do I need to build my own gateway or can I use an existing one?

Use an existing one. Building a true gateway requires a banking license, a processor partnership, and millions in capital. What you probably want to build is a payment application (a shopping cart, invoicing tool, or point-of-sale system) that uses an existing gateway's API. This is realistic for a startup and is how most payment software is built.

What is the cheapest gateway to integrate with?

Stripe and Square have the lowest per-transaction fees for most merchants (around 2.7% plus $0.30 per transaction for cards). Authorize.Net is slightly cheaper for high-volume merchants. The "cheapest" gateway depends on your transaction size, volume, and industry. Compare the total cost, not just the percentage.

Can I accept payments without PCI compliance?

Yes, if you use a hosted payment form or tokenization. The gateway handles the card data, you never touch it, and you stay out of PCI scope. If you build your own card entry interface, you must comply with PCI DSS Level 1, which requires annual audits and costs tens of thousands of dollars.

How long does it take to integrate a payment gateway?

Using a hosted payment form and a pre-built library, you can have a working integration in a few hours to a few days. Building your own card entry interface, implementing fraud detection, and handling all edge cases takes weeks to months. Most developers underestimate this—budget for testing and debugging.

What happens if my payment application gets hacked?

If you use tokenization and never store card data, the hacker cannot steal card numbers. If you store customer data (email, address, phone), you must notify affected customers and may face fines under data protection laws. If you are PCI compliant and follow the processor's security guidelines, your liability is limited. Read your merchant services agreement to understand what you are responsible for.