Payment gateway vs payment processor
Also known as: payment gateway, payment processor, card processor, merchant services provider
A payment gateway is the front door that securely captures a customer's card details at checkout and sends them on, while a payment processor does the behind-the-scenes work of routing the transaction through card networks and banks.
While the two terms get used interchangeably, and companies like Stripe bundle both, the distinction still matters when you're comparing fees, switching providers, or troubleshooting a failed payment.
Payment gateway vs payment processor, explained at three levels
At home
When you buy something online, the payment gateway is like the cashier who takes your card and checks it's real. The processor is like the courier who carries the request to your bank and brings back a 'yes' or 'no.' You only see the checkout page, but both are working in the background.
At work
A business that wants to take card payments needs both pieces. The gateway connects your website or terminal to the payment system, and the processor handles the communication with the banks. Many providers now sell them together, so a small business may not need to pick each separately.
At home
When you click 'Pay', the gateway's form, often embedded from the payment company, encrypts your card details so the store's own website never handles them in plain form. The gateway passes them to the processor, which formats an authorization request and sends it through the card network, such as Visa or Mastercard, to the bank that issued your card. Your bank checks your balance and fraud signals, then answers yes or no along the same path, usually in a second or two.
At work
In a split setup, the gateway is software that collects card data, tokenizes it, and exposes APIs for authorizing, capturing, and refunding payments. The processor runs the connection to the card networks for the merchant's acquirer and handles clearing files and settlement. Bundled providers such as Stripe or Square combine both and usually charge a flat rate, while separate arrangements often use interchange-plus pricing. A hosted gateway form keeps raw card numbers off your servers, which shrinks your PCI DSS compliance scope.
At home
A card payment has two stages: authorization (the bank places a hold) and capture (the merchant claims the money), followed by clearing and settlement, often a day or two later. Gateways expose these as API calls. In my opinion, understanding that split explains most of those confusing 'pending' charges on your statement, like a hotel hold that later changes amount.
At work
Architecturally, the key questions are who holds the merchant account, where card data is tokenized, and whether those tokens are portable. Gateway tokens are usually proprietary, so moving to another provider means a coordinated data migration under PCI DSS rules, or re-collecting every card. Processors also differ in authorization rates by card type and region, and multi-processor routing adds resilience but needs a provider-neutral vault. I'd specify token export rights in the contract before signing, because that clause decides how easily you can leave.
Real-world examples
At home
Carlos ordered a jacket from a small online shop. The checkout form was supplied by the shop's payment gateway, which encrypted his card number. The processor sent the request through Visa to his bank, which approved it in about a second, and the shop got a 'success' message without ever seeing his full card number.
At work
Lena runs finance for a growing online retailer that started on a flat-rate bundled provider. At their current volume, she modelled a separate gateway with interchange-plus processing and found meaningful savings. Before switching, she confirmed that the old provider would export stored card tokens, so customers wouldn't have to re-enter their cards.
How it compares
| feature | Payment gateway | Payment processor |
|---|---|---|
| Main job | Capture and secure card data, pass it on | Route transactions to card networks and banks |
| Where it sits | Between the checkout and the payment system | Between the merchant's bank and the card networks |
| Customer sees it? | Sometimes, as the checkout form | Almost never |
| Compliance impact | Hosted forms reduce PCI DSS scope | Handles card data in the network |
| Example | Authorize.Net | Moneris, Fiserv, Global Payments |
The gateway is the front door; the processor is the hallway behind it. Many providers bundle both.
For analysts
When you write requirements for a payments change, specify token portability and multi-processor routing explicitly. I've seen businesses locked into a provider for years simply because nobody asked who owned the stored cards. That one clause can be worth more than the per-transaction rate.
History & origin
As online shopping took off in the mid-1990s, merchants needed a way to send card data from websites to the existing card-processing world. Authorize.Net, founded in 1996, became one of the earliest standalone gateways. For years, a merchant typically signed up separately for a merchant account with an acquiring bank, a processor, and a gateway. Companies such as PayPal, and later Stripe (launched publicly in 2011), collapsed these layers into a single sign-up by acting as payment facilitators. In Canada, Moneris, formed in 2000 by RBC and BMO, became a dominant processor for in-person card payments. I'd argue the bundling was the real innovation. The technology existed already, but nobody had made it easy.