Payment Gateway vs Payment Processor: The Actual Difference
Ask three vendors what they sell and you will get three different answers to the same question. One calls itself a payment gateway. Another calls itself a payment processor. A third calls itself both. The confusion is not accidental: many providers, including Stripe and Square, sell both functions bundled into a single product, so the distinction disappears from the sales pitch even though it still matters technically and, for some businesses, financially.
This is a practical explanation of what each layer actually does, using the lens of what a food ordering platform, restaurant group, or e-commerce store experiences when they are actually choosing between providers, not a diagram of abstract data flow.
The Short Answer
A payment gateway is the customer-facing layer. It captures card details at checkout, encrypts them, and passes them along for authorization. A payment processor is the back-end layer. It takes that authorization request, routes it through the card networks to the customer's bank, and manages the transfer of funds ( Stripe, payment processor vs payment gateway). The gateway hands off the data. The processor decides whether the money moves and makes sure it actually does.
Most modern providers sell both under one contract, which is why the terms get used interchangeably in casual conversation. The distinction still matters when you are evaluating vendors, debugging a declined transaction, or deciding whether to use different providers for different parts of your payment stack.
What a Payment Gateway Actually Does
The gateway is the piece your customer's browser or app actually talks to. When someone enters their card number on your checkout page, the gateway captures that data, encrypts it immediately, and either tokenizes it (replacing the raw card number with a reference token so your servers never store sensitive card data) or forwards it directly for authorization.
Hosted vs API-Based Gateways
A hosted gateway redirects the customer to a page controlled by the gateway provider to enter payment details, then redirects them back once the transaction completes. It is faster to implement and shifts most of the PCI compliance burden onto the gateway provider. A self-hosted or API-based gateway keeps the customer on your own checkout page throughout, giving you full control over branding and user experience, but it means more of your own infrastructure sits inside PCI scope, and self-hosted checkouts generally convert faster because the customer never leaves the page ( Shopify, payment gateway integration strategic guide).
For a food ordering platform building a native checkout inside its app, API-based is usually the right call, because a redirect mid-order on a mobile app creates exactly the kind of friction that kills conversion. For a smaller restaurant group running a simple online ordering page, a hosted gateway is often the faster, cheaper path to launch.
What the Gateway Does Not Do
A gateway does not decide whether a transaction is approved. It does not hold funds. It does not manage your relationship with a card network or a bank. Its job ends once the payment data has been securely captured and handed off.
What a Payment Processor Actually Does
The processor is the layer that turns a captured card number into an actual decision and, eventually, actual money in your bank account.
Authorization Routing
Once the gateway hands off the transaction, the processor formats it into the messaging standard used by card networks, sends it through to Visa or Mastercard, who route it to the customer's issuing bank for approval or decline. This round trip typically completes in under two seconds.
Fraud Tooling and Compliance
Processors run real-time fraud scoring on every transaction (Stripe's Radar and Adyen's equivalent tools are processor-layer functions), handle PCI DSS compliance obligations tied to the transaction itself, and implement 3D Secure authentication for card-not-present payments where required. Fraud prevention and compliance tooling live at the processor layer, not the gateway layer, even though the two are often marketed together.
Settlement
After a transaction is authorized, the processor batches it with other approved transactions and initiates settlement, typically landing funds in your bank account one to two business days later, minus interchange, network fees, and the processor's own margin.
How They Work Together in a Real Transaction
For a typical online order, in this example a customer ordering food through a delivery app, the sequence looks like this:
- The customer enters card details in the app's checkout
- The gateway captures and encrypts the data, tokenizing it before it ever touches the platform's own servers
- The gateway sends an authorization request to the processor
- The processor routes the request through the card network to the customer's issuing bank
- The issuing bank approves or declines based on available credit and fraud signals
- The response returns through the same chain: bank to network to processor to gateway to app
- The customer sees "Order confirmed" within one to two seconds
- At batch settlement, the processor submits all authorized transactions for the day
- Funds settle to the platform's account, typically one to two business days later, net of fees
The gateway owns steps one, two, three, and the customer-facing part of step seven. The processor owns everything else. Both are present in every single transaction, whether or not the business ever thinks about them as separate.
Why This Distinction Matters for a Food Ordering Platform or Marketplace
For a platform routing payouts to individual restaurants rather than collecting payment for itself, the gateway and processor questions compound. The platform needs a gateway that can handle a checkout experience embedded in someone else's app or website, and a processor built for split payments, meaning it can hold funds temporarily and disburse a portion to the platform and a portion to the restaurant on each order, with correct tax and compliance handling for every sub-merchant. This is a fundamentally different technical requirement than a single merchant taking payment for itself, and it is why marketplace-specific tools like Stripe Connect, Adyen for Platforms, and Braintree Marketplace exist as distinct products from their standard checkout offerings.
Getting this wrong at the platform level is expensive to unwind later. A platform that launches on a standard single-merchant processor and later needs to add restaurant payouts often has to rebuild its entire payment integration from scratch. Understanding how processors classify different business models by risk and structure before you build is worth doing early, as covered in our guide to how payment processors classify your business vertical.
It is also worth understanding how the processor relates to the merchant acquirer, the institution that actually holds the underlying merchant account and carries the financial risk, since that is a separate relationship again from both the gateway and the processor. Our guide on merchant acquirer vs payment processor covers that distinction in full.
When You Need to Choose Them Separately vs When One Company Does Both
| Scenario | Recommended Approach | Why |
|---|---|---|
| Small business, standard checkout, fast launch | All-in-one provider (Stripe, Square) | Gateway and processor bundled, minutes to set up, no separate contracts |
| High-volume enterprise with existing acquirer relationship | Separate gateway and processor | Interchange-plus pricing through a direct acquirer, gateway chosen independently for technical fit |
| Marketplace or platform with sub-merchant payouts | Purpose-built platform product (Stripe Connect, Adyen for Platforms) | Standard bundled checkout products do not support split payments or sub-merchant onboarding |
| International or multi-currency business | Gateway with strong multi-currency support, processor evaluated separately for settlement speed by region | Not every processor settles every currency at the same speed or cost |
Global ecommerce sales are projected to reach $3.88 trillion in 2026, and the payment gateway market alone is projected to grow from roughly $34.5 billion to $90.3 billion by 2034, which reflects how much specialization is happening at the gateway layer specifically as checkout experience becomes a competitive differentiator in its own right ( Corefy, best payment gateway APIs in 2026).
Common Mistakes When Evaluating "Payment Processors" That Are Actually Gateways
A recurring problem: a business shops for a "payment processor," gets pitched by a sales rep whose product is technically a gateway reselling processing from a separate back-end provider, and signs a contract without understanding that a third party actually holds the financial risk and sets the real terms. This matters because contractual protections, dispute handling, and account stability ultimately trace back to whoever is acting as processor and acquirer, not whoever built the checkout page.
Before signing with any provider, ask directly: who processes the transaction once it leaves your checkout, and who actually holds the merchant account? If the sales rep cannot answer clearly, that is worth treating as a warning sign rather than a technicality.
Not enough payment methods offered at checkout accounts for roughly 10% of cart abandonment, and sites offering digital wallets like Apple Pay see two to three times higher mobile conversion than standard card entry ( Coastal Pay, best payment methods to increase checkout conversion). Confirm the gateway supports the payment methods your specific customers actually use before evaluating processor pricing at all, since a technically cheaper processor behind a gateway that cannot offer Apple Pay or the wallet your customers prefer is a net loss.
The Bottom Line
The gateway captures and moves the data. The processor decides whether the money moves and gets it into your account. Most businesses will use a single provider that bundles both, and that is a perfectly reasonable choice for most standard use cases. What matters is knowing which layer you are actually evaluating when a sales rep describes their product, so you are comparing gateway features to gateway features and processor risk terms to processor risk terms, rather than treating every vendor conversation as the same decision. Our guide on how to choose a payment processor walks through that comparison in more depth.
If you are not sure whether your current setup, or a provider you are evaluating, actually fits how your business processes payments, the free risk assessment compares your transaction profile against processors and gateways that have already been matched to businesses like yours.
Frequently Asked Questions
Wondering if your current provider is the right fit? See how your business matches against 21 providers.
Book a 15-Minute CallFree. No sales pitch. No strings attached.
Sources & References
External links open in a new tab. ChosePayments is not affiliated with these sources.
If you're making a payment provider decision where getting it wrong is expensive, we offer independent advisory support before you apply.