You can build a payment gateway, but you will be liable for security, compliance, and fraud — and most businesses should not

A payment gateway is software that encrypts card data, routes transactions to banks, and returns approval or decline. You can write code that does this. What you cannot do is avoid the legal and technical weight that comes with it. The moment you touch a credit card number, you become responsible for PCI DSS compliance — a security standard that requires annual audits, encryption at rest and in transit, network segmentation, and documented incident response. You are also liable for fraud losses, chargebacks, and any breach that exposes customer data. Building a gateway means you are not just writing software; you are taking on the role of a payment processor in the eyes of the law.

Most businesses that think they want to build a gateway actually want to reduce fees or gain control over the transaction flow. Neither goal is solved by building one yourself. Fees come from the card networks (Visa, Mastercard) and your bank, not from the gateway software. Control over data is real, but the compliance cost to achieve it safely is usually higher than the savings. If you are a high-volume merchant or a payment service provider, building a gateway might make sense. If you are a small business or a SaaS platform, using an existing gateway and integrating it is almost always the right move.

Key Takeaways

  • Building a payment gateway means you become responsible for PCI DSS compliance, which requires encryption, network security, annual audits, and documented procedures — not just code.
  • You cannot avoid card network fees or interchange rates by building your own gateway; those costs are set by Visa, Mastercard, and your acquiring bank, not by your software.
  • A breach of your gateway exposes you to liability for fraud losses, customer lawsuits, and regulatory fines — often in the millions of dollars.
  • Most businesses reduce costs and risk faster by integrating a third-party gateway (Stripe, Square, PayPal) than by building and maintaining their own.
  • If you do build one, you will need a bank relationship with an acquiring bank, a merchant account, and legal review of your terms of service.

What PCI DSS compliance actually requires

PCI DSS (Payment Card Industry Data Security Standard) is a set of rules written by Visa, Mastercard, American Express, Discover, and JCB. It applies to anyone who stores, processes, or transmits card data. Compliance is not optional — your acquiring bank will audit you, and non-compliance can result in fines, account termination, or loss of the ability to accept cards at all.

The standard has six main categories. First, you must build and maintain a secure network: firewalls, no default passwords, no direct public access to card data. Second, you must protect cardholder data: encryption at rest, encryption in transit (TLS 1.2 or higher), and no storage of sensitive authentication data like the CVV. Third, you must maintain a vulnerability management program: patch systems within 30 days of release, run antivirus software, and conduct annual penetration testing by a may have access to third party. Fourth, you must implement access control: unique user IDs, role-based permissions, and audit logs of who accessed what and when. Fifth, you must monitor and test your network regularly: intrusion detection, log monitoring, and quarterly network scans. Sixth, you must maintain an information security policy: incident response procedures, employee training, and documentation of everything.

Compliance is not a one-time checklist. You must undergo an annual audit by a may have access to Security Assessor (QSA) — an independent firm certified by the card networks. The audit costs between $5,000 and $50,000 per year depending on your transaction volume and the complexity of your systems. You must also file a self-assessment questionnaire (SAQ) with your acquiring bank, and you must respond to any breach within 30 days with a forensic investigation.

Why you cannot avoid card network fees

When a customer swipes a card, the transaction moves through a chain: your gateway → your acquiring bank → the card network (Visa or Mastercard) → the customer's issuing bank. Each step takes a cut. The issuing bank charges interchange, which is typically 1.5% to 2.5% of the transaction amount. The card network charges an assessment fee, usually 0.1% to 0.2%. Your acquiring bank charges a markup on top of that, usually another 0.5% to 1.5%. These fees are set by the networks and the banks, not by your gateway software.

Building your own gateway does not change these fees. You still need an acquiring bank to connect to the card networks, and that bank will still charge you interchange plus their markup. The only way to reduce fees is to negotiate volume discounts with your acquiring bank, and those discounts are available whether you use Stripe or build your own. If you are processing millions of dollars per month, you might negotiate a basis point or two off the markup — but you will spend far more than that on compliance, security, and engineering.

The one scenario where building a gateway makes financial sense is if you are a payment service provider (PSP) — a company that processes payments on behalf of other merchants. In that case, you can aggregate volume, negotiate better rates, and pass savings to your customers. But you also become a money transmitter in most states, which requires licensing, bonding, and regulatory oversight. That is a different business entirely.

Liability and breach risk

If your gateway is breached and card data is stolen, you are liable for the cost of the breach. That includes forensic investigation (often $100,000 to $500,000), notification to affected customers, credit monitoring services, regulatory fines, and lawsuits. The 2013 Target breach, which exposed 40 million card numbers through a third-party vendor, cost Target over $18 million in settlements alone — and that was just the direct cost. Indirect costs (lost sales, reputation damage, engineering time) were much higher.

You are also liable for chargebacks. A chargeback occurs when a customer disputes a transaction with their bank. The bank reverses the charge and charges you a fee (usually $15 to $100 per chargeback). If your chargeback rate exceeds a threshold (typically 1% of transactions), your acquiring bank can terminate your account or raise your fees. If you are processing payments for other merchants (as a PSP), you are liable for their chargebacks too, which means you need reserves to cover them.

Fraud is another liability. If a customer's card is used fraudulently on your platform, the cardholder's bank will often reverse the charge. You absorb the loss. If your fraud rate is high, your acquiring bank will either terminate you or require you to implement fraud detection tools — which cost money and still do not catch everything.

The technical work beyond the code

Writing the code to encrypt a card number and send it to a bank is the smallest part of building a gateway. The larger work is infrastructure. You need a secure network with firewalls, intrusion detection, and network segmentation. You need a separate environment for testing that is not connected to production. You need logging and monitoring that captures every transaction, every access, and every error. You need a way to rotate encryption keys without downtime. You need a disaster recovery plan and a way to restore from backups without exposing card data.

You also need to handle edge cases that third-party gateways have already solved. What happens if the bank's API times out? What happens if a transaction is approved but the network fails before you receive the confirmation? What happens if a customer's card is declined and they retry five times in a row? What happens if you receive a chargeback six months after the transaction? Each of these scenarios requires code, testing, and documentation.

Finally, you need to integrate with the card networks' APIs directly or through a processor. Visa and Mastercard do not sell direct access to small companies; you must go through an acquiring bank or a processor like First Data or Fiserv. That relationship requires a contract, a merchant account, and ongoing communication about compliance and fraud.

When building your own gateway makes sense

Building a gateway is justified in a few narrow cases. If you are a payment service provider processing billions of dollars per year, the savings from negotiating your own rates and owning your infrastructure can exceed the compliance and engineering costs. If you are a bank or a large financial institution, you already have the compliance infrastructure and the regulatory relationships in place. If you are building a payment system for a specific vertical (e.g., a point-of-sale system for restaurants), you might build a gateway to integrate tightly with your product.

For everyone else — SaaS platforms, e-commerce sites, marketplaces, subscription services — using an existing gateway is faster, cheaper, and safer. Stripe, Square, PayPal, and others have already invested millions in compliance, security, and fraud detection. They handle PCI DSS for you (you still have some responsibility, but they carry most of the load). They absorb some fraud losses. They negotiate rates with the card networks. They update their systems when the networks change their rules. You pay a fee for this, but the fee is almost always lower than the cost of building and maintaining your own.

What you need if you do build one

If you decide to build a gateway anyway, you will need three things before you can process a single transaction. First, a merchant account with an acquiring bank. This is a bank account specifically for payment processing. The bank will underwrite you, meaning they will review your business, your volume, your fraud risk, and your compliance posture. They will require you to sign a merchant agreement that outlines your obligations, their obligations, and the fees they will charge. This process can take weeks or months.

Second, you need a connection to the card networks or a processor. Most acquiring banks will give you access to their processor's API, which handles the routing to Visa, Mastercard, and other networks. You will need to integrate with this API, test it, and maintain it. The processor will provide documentation, but you are responsible for implementing it correctly.

Third, you need legal review of your terms of service. Your terms must disclose that you process payments, that you comply with PCI DSS, and what happens if there is a dispute or a breach. You should also have a privacy policy that explains how you handle card data. A lawyer familiar with payment processing should review both documents before you launch.

You will also need to budget for ongoing compliance: annual QSA audits, quarterly penetration testing, security patches, and incident response procedures. You will need to hire or contract with security engineers who understand PCI DSS. You will need to maintain relationships with your acquiring bank and your processor. All of this is ongoing, not one-time.

Frequently Asked Questions

Can I use a third-party payment processor instead of building a gateway?

Yes, and this is the right choice for most businesses. Processors like Stripe, Square, and PayPal handle PCI DSS compliance, fraud detection, and card network integration. You integrate their API into your product, and they handle the rest. You pay a percentage of each transaction (usually 2% to 3%), but you avoid the compliance, security, and engineering costs of building your own.

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

A gateway is the software that encrypts card data and routes transactions. A processor is the company that operates the gateway and connects to the card networks. Most people use the terms interchangeably, but technically a processor is larger — it includes the gateway, the merchant account, the acquiring bank relationship, and customer support. When you integrate Stripe, you are integrating Stripe's gateway and using Stripe as your processor.

Do I need PCI DSS compliance if I use a third-party gateway?

You still have some responsibility, but the gateway provider carries most of the load. If you use a hosted payment form (like Stripe's Checkout), you have minimal PCI responsibility because the card data never touches your servers. If you build your own form and send card data to your server, you have more responsibility. Your gateway provider will tell you which SAQ (self-assessment questionnaire) you need to complete based on your integration method.

How much does it cost to build a payment gateway?

The engineering cost to build the code is $50,000 to $500,000 depending on complexity. The ongoing compliance cost is $10,000 to $100,000 per year. The acquiring bank will charge you interchange plus a markup (usually 1% to 3% of transaction volume). If you process $1 million per month, you will pay $10,000 to $30,000 in fees alone. Most businesses find that using a third-party gateway at 2% to 3% per transaction is cheaper than building their own.

Can I build a gateway just for my own business without becoming a payment processor?

Yes, as long as you only process payments for yourself and not for other merchants. You still need an acquiring bank, a merchant account, and PCI DSS compliance. But you do not need money transmitter licensing or the regulatory oversight that comes with being a PSP. You are simply a business that processes its own payments, which is much simpler than being a payment service provider.