What you actually need to build a payment processor
Building a payment processor means creating the infrastructure that moves money from a customer's bank account or card to a merchant's account. You need four separate pieces: a way to accept payment data (the interface), a system to validate and route transactions (the core engine), connections to banks and card networks (the rails), and compliance with payment regulations (the legal layer). Most people who think they want to build a processor actually need to build a payment gateway that sits on top of an existing processor—a much smaller project.
If you want to move actual money between real bank accounts, you will need a money transmitter license in most US states, a relationship with at least one acquiring bank, and integration with the Federal Reserve's payment networks or private networks like Visa and Mastercard. This takes 6 to 18 months and costs $50,000 to $500,000 before you process a single transaction. If you want to build a gateway that collects payment data and passes it to an existing processor like Stripe or Square, you can launch in weeks for under $10,000.
Key Takeaways
- A true payment processor moves money between bank accounts and requires money transmitter licenses, acquiring bank relationships, and direct connections to Visa, Mastercard, and the Federal Reserve.
- A payment gateway collects payment information and routes it to an existing processor, which is legal to build without a license and costs far less to launch.
- The core technical components are a payment form or API, a transaction database, fraud detection rules, and reconciliation logic that matches what you charged to what actually settled.
- Compliance requirements include PCI DSS certification (if you handle card data), state money transmitter licenses (if you move money), and regular security audits.
- Most successful payment companies start by solving one specific problem—invoicing, subscriptions, international transfers—rather than trying to be a general processor.
The difference between a processor and a gateway
A payment processor is the company that actually moves money. It holds licenses to transmit money, maintains relationships with banks, and connects directly to card networks. Stripe, Square, and PayPal are processors. They take the payment data you send them, validate it against the card network, move money from the customer's bank to the merchant's bank, and handle disputes and chargebacks.
A payment gateway is software that collects payment information and sends it to a processor. It is the form on a website, the API you call, the dashboard where you see transactions. You can build a gateway without a license because you are not moving money yourself—you are just collecting data and passing it along. Shopify's payment form is a gateway. So is the checkout page on most e-commerce sites.
If you want to launch something in the next year, build a gateway. If you want to build a processor, plan for licensing, banking relationships, and regulatory work that will take longer than the technical build.
The technical architecture you need
A payment system has five layers, and each one has to work before the next one can function. The first layer is data collection—a form or API endpoint where a customer enters their card number, bank account, or digital wallet. This layer must never store the raw card data; instead, it sends it directly to a tokenization service (usually provided by your processor or a third party like Stripe's API) that returns a token you can store safely.
The second layer is transaction validation. When a customer submits payment, your system checks that the token is valid, the amount is reasonable, and the customer is not flagged for fraud. This is where you run rules like "block transactions over $10,000 from new accounts" or "flag three failed attempts in five minutes." Most processors provide fraud detection tools; you add your own business rules on top.
The third layer is routing and settlement. Your system sends the validated transaction to the processor (or to the card network if you are a processor yourself). The processor responds with an approval or decline. If approved, the transaction enters a queue to settle—usually the next business day. Your database tracks the status of every transaction from submission through settlement.
The fourth layer is reconciliation. Every night, you compare what your system says it charged to what actually settled in the bank account. Transactions fail for reasons outside your control—a customer's bank declines it, a card is reported stolen, a chargeback is filed. Your reconciliation process catches these mismatches and flags them for investigation.
The fifth layer is reporting and webhooks. Your merchants need to see what they earned, what was refunded, what is pending. You send webhooks (automated notifications) to their systems when a transaction settles or fails. You provide a dashboard where they can see transaction history, download reports, and manage refunds.
Licensing and compliance requirements
If you build a gateway and never touch the money yourself, you do not need a money transmitter license. You are a software company, not a financial institution. You do need PCI DSS certification if you handle card data directly—but most gateways avoid this by using tokenization, which means the card data never touches your servers.
If you build a processor and actually move money between accounts, you need a money transmitter license in every state where you operate. Some states require this even if you only move money for a single merchant. The license process involves background checks, proof of net worth, a detailed business plan, and sometimes a surety bond. Each state has different requirements; there is no single federal license. You will also need an Employer Identification Number (EIN) from the IRS and a business bank account.
You must also establish a relationship with an acquiring bank—a bank that will hold merchant funds and settle transactions. Acquiring banks are cautious; they will ask for your compliance certifications, your fraud prevention plan, your chargeback history (even if it is zero), and proof that you are not processing high-risk merchants like gambling or adult content. This relationship can take 3 to 6 months to establish.
Finally, you need regular security audits. If you handle payment data, you must conduct penetration testing at least annually and fix any vulnerabilities before they are exploited. You must also maintain audit logs of who accessed what data and when. These are not one-time tasks; they are ongoing compliance obligations.
How to connect to card networks and banks
Card networks (Visa, Mastercard, American Express, Discover) do not sell direct access to small companies. Instead, you connect through an acquiring bank or a processor that already has network access. The acquiring bank handles the relationship with the card network and provides you with the technical specifications you need to send transaction data in the right format.
The most common format is ISO 8583, a standard that defines how to encode transaction data—card number, amount, merchant ID, timestamp, and dozens of other fields. Your system must build messages in this format and send them over a secure connection (usually TLS encryption) to the acquiring bank's gateway. The bank's gateway validates the message, sends it to the card network, and returns a response code: approved, declined, or error.
For bank account transfers (ACH, wire, or real-time payment networks), you connect through the Federal Reserve's systems or through a private network like The Clearing House. Again, you do not connect directly; you work through a bank that has access. The bank provides you with API documentation and test credentials so you can build and test your integration before going live.
These connections are not instant. A card transaction takes 1 to 3 seconds to approve or decline. An ACH transfer takes 1 to 3 business days to settle. A wire transfer settles the same day but costs more. Your system must handle all three timelines and communicate clearly to merchants which timeline applies to each transaction type.
Fraud detection and chargeback management
Fraud is the reason most payment processors fail. A fraudster uses a stolen card to buy $5,000 worth of goods, the merchant ships the goods, and then the cardholder disputes the charge. The processor is liable for the loss because it approved a fraudulent transaction. Your fraud detection system must catch this before it happens.
Basic fraud detection uses rules: block transactions from countries where you do not do business, block amounts that are 10 times higher than the customer's average, block multiple failed attempts from the same card in a short time. More advanced detection uses machine learning to find patterns—a customer who usually buys in New York suddenly buys in Nigeria, or a customer who usually buys $50 items suddenly buys $5,000 items.
You also need a chargeback management system. When a customer disputes a charge, the card network notifies you. You have a window (usually 10 to 30 days) to respond with evidence that the transaction was legitimate—a shipping confirmation, a signed receipt, an email from the customer confirming the purchase. If you do not respond or your evidence is weak, you lose the chargeback and pay the customer back plus a chargeback fee.
Chargeback rates matter. If your chargeback rate exceeds 1% of transactions, card networks can fine you or revoke your processing rights. If it exceeds 2%, they usually do revoke you. This is why fraud prevention is not optional; it is the difference between a sustainable business and one that gets shut down.
Starting small: what to build first
Do not try to build a general-purpose processor. Build a processor for one specific use case: invoicing, subscriptions, marketplace payments, international transfers, or payroll. This focus lets you understand the specific compliance and fraud challenges of that use case and build the right safeguards.
Start by building a gateway on top of an existing processor. Use Stripe Connect, PayPal Commerce Platform, or Square's APIs. This lets you launch in weeks, learn how payment systems actually work, and build a merchant base. Once you have merchants and revenue, you can invest in building your own processor infrastructure.
Your first version should handle one payment method—credit cards or bank transfers, not both. It should support one currency. It should have a basic dashboard where merchants can see transactions and issue refunds. It should have webhooks so merchants can integrate with their own systems. Everything else is a future feature.
Test extensively before going live. Use your processor's sandbox environment to simulate thousands of transactions: approvals, declines, chargebacks, refunds, timeouts. Test what happens when a transaction takes 10 seconds to approve instead of 1 second. Test what happens when a merchant's bank account is closed. Test what happens when a customer disputes a charge. Every scenario you do not test in sandbox will happen in production.
Frequently Asked Questions
Do I need a money transmitter license to build a payment gateway?
No. A gateway collects payment data and sends it to an existing processor; it does not move money itself. You need a license only if you actually transfer money between accounts or hold customer funds. If you use tokenization and never store raw card data, you also do not need PCI DSS certification—the processor handles that.
How much does it cost to build a payment processor?
A gateway built on top of an existing processor costs $5,000 to $50,000 to develop and launch. A full processor with your own acquiring bank relationship and card network connections costs $100,000 to $500,000 in development, licensing, and compliance, plus ongoing costs for security audits and regulatory filings. Costs vary widely based on the payment methods you support and the countries you operate in.
How long does it take to get a money transmitter license?
Most states take 3 to 6 months to review and approve a money transmitter license application. Some states take longer. You must apply in every state where you operate. During this time, you cannot legally move money, so you must use an existing processor or a partner bank to handle transactions.
What happens if a transaction fails to settle?
Your reconciliation system flags it. You investigate the reason—the customer's bank declined it, the card was reported stolen, the merchant's account was closed. You then either retry the transaction (if the reason was temporary), refund the customer, or contact the merchant to resolve it. Your system must track the status and notify both parties of the outcome.
Can I build a payment processor without connecting to Visa and Mastercard directly?
Yes. You can build a processor that only handles bank transfers (ACH, wire, real-time payments) and never touches card networks. This is simpler because you only need a relationship with one bank, not multiple card networks. However, you still need a money transmitter license and all the compliance infrastructure. You will also have fewer merchants because most want to accept cards.