A payment gateway and a payment processor do different jobs inside the same transaction. The gateway captures and encrypts a customer's card data, while the processor moves the money between banks. Both take part in every online payment, so the split matters when you choose tools or scope payment gateway software development for a product.
What Is a Payment Gateway?
A payment gateway is the technology that captures a customer's card details at checkout and encrypts them for secure transfer to the processor. It's the customer-facing part of the flow, the point where sensitive data is collected and locked down before it goes anywhere.
Think of it as the online equivalent of a card terminal in a shop. It's built for card-not-present payments on a website or in an app.
Gateways come in a few forms. Some are hosted pages that redirect the customer, while integrated and API-based setups keep them on your site. Our explainer on what a payment gateway is covers those types in detail.
What Is a Payment Processor?
A payment processor is the service that takes the encrypted transaction from the gateway and moves it through the card networks and banks. That's how an approved checkout turns into money in your account.
The processor works in the background to authorise each payment. It communicates with card networks such as Visa and Mastercard, the customer's issuing bank, and your acquiring bank. Once a payment is approved, it settles the funds into your merchant account, usually within a few working days.
Processors also do more than route data. They run fraud screening, manage chargebacks and disputes, and keep transactions compliant with card scheme rules, charging a fee on each one for the service.
Payment Gateway vs Payment Processor: The Core Difference
The core difference between a payment gateway and a payment processor is data versus money: the gateway transmits information, the processor moves funds. One sits at the front of the transaction, the other behind it.
The distinction is easier to hold onto across four points:
- Role: the gateway is front-end and customer-facing, the processor is back-end and hidden from the buyer.
- Job: the gateway captures and encrypts card data, the processor authorises the payment and settles the funds.
- Need: any business accepting cards needs a processor, while a gateway becomes necessary once you take payments online or in an app.
- Fees: gateways often charge a monthly or per-transaction fee, while processing costs usually land between 1% and 3% of each sale, plus a fixed fee.
In practice the two are interdependent. A gateway with no processor cannot move money, and a processor with no gateway has no secure way to collect card data online.
How a Card Payment Gets Processed Step by Step
A card payment gets processed in a sequence that passes between the gateway, the processor, the card networks, and two banks. The whole authorisation takes about two seconds, though the money itself lands later.
Here is the flow behind a single online payment:
- The customer enters their card details at checkout.
- The gateway encrypts the data and sends it to the processor.
- The processor forwards the request to the card network and the customer's issuing bank.
- The issuing bank approves or declines based on available funds and fraud checks.
- The response travels back through the processor and gateway to the checkout screen.
- On approval, the processor settles the funds into your merchant account through the acquiring bank.
Authorisation happens in seconds, but settlement, the actual movement of money, typically takes a few working days to reach your account.
Do You Need Both a Gateway and a Processor?
You need both a gateway and a processor for most online sales, though not every setup requires each one. What you need depends on how your customers pay.
For a website or app taking card-not-present payments, you need both. The gateway captures and secures the card data, and the processor authorises and settles it. Recurring billing and marketplace models rely on the same pairing.
A purely in-person shop can sometimes run on a processor and a card terminal alone, since the terminal captures the card directly. A gateway on its own, though, cannot move money; it always depends on a processor behind it.
What This Means When You Build a Payment Product
When you build your own payment product, the gateway and processor stop being tools you pick and become architecture decisions you own. The questions shift to which components you integrate, which you build, and who holds PCI DSS scope across the flow.
An API-first approach keeps those parts loosely coupled, so you can add tokenisation, multi-currency support, or new fraud checks without reworking the core. Designing the gateway and processor layers deliberately is also where frameworks like PCI DSS, PSD2 and GDPR get built in early, rather than retrofitted later.
In our experience with custom FinTech software development, that split is the part teams underestimate most. We've seen it on an EMI-licensed payments product and a non-custodial exchange alike.
If you're scoping a checkout, a wallet, or a full payments platform, we can help you design those layers around your compliance needs. Book a Discovery call and we'll map out the payment software development your product needs.
