A payment gateway captures and encrypts a customer’s card details at checkout. A payment processor takes that encrypted data and moves it through the banking network to complete the transaction. We hear the two terms used interchangeably all the time, and it’s easy to see why — from a customer’s point of view, a payment either goes through or it doesn’t. But if you’re choosing infrastructure for your business, the difference matters: it affects which providers you need, how many contracts you’re signing, and where the cost sits. Most online businesses need both a gateway di pagamento and a processor, and increasingly, modern platforms bundle both into one system rather than making you stitch two vendors together.
What Is a Payment Gateway?
Think of a payment gateway as the part of the transaction the customer actually sees. It’s the technology sitting between your checkout page and the rest of the payment chain — the piece that captures a card number, an expiry date, a CVC, and encrypts all of it before it goes anywhere else.
In practical terms, a gateway does four things: it captures the payment details at checkout, encrypts them to PCI DSS standards (the security requirements every business handling card data has to meet), sends that encrypted data on to the payment processor, and then returns the result — approved or declined — back to you and your customer. This whole loop, in a well-built setup, takes about two seconds.
Gateways matter for more than just moving data. Most include fraud screening tools that flag suspicious patterns before a transaction is even authorized, which is one reason “payment gateway vs payment processor” conversations often end up being about risk management as much as plumbing. If you sell internationally, a decent gateway also handles multi-currency transactions, letting you accept payments in a customer’s local currency without building separate checkout flows for every market. None of this happens without PCI DSS compliance — it’s not optional, and any gateway worth using should already have it baked in.
What Is a Payment Processor?
If the gateway is customer-facing, the processor is the part working behind the scenes. It’s the infrastructure that takes the encrypted data handed off by the gateway and gets it in front of the right bank.
A processor’s job breaks down into a few concrete steps: receive the encrypted transaction from the gateway, contact the customer’s issuing bank to confirm funds are available and the transaction is authorized, move the money from the customer’s account to the merchant’s account, and handle settlement — the part where funds actually land. That authorization step relies on what’s sometimes called a two-step handshake between the issuing bank and the acquiring bank, confirming the transaction is legitimate before any money moves.
One distinction worth knowing: unlike a gateway, a processor doesn’t need an online checkout to function. It’s the same infrastructure a physical retail card terminal relies on, which is why processors matter for in-person transactions too. Fees here are usually a percentage of the transaction or a flat rate, and — same as gateways — a processor needs to be PCI DSS compliant to legally handle card data at all.
Ready to upgrade your payment infrastructure?
Stop struggling with fragmented payment flows. Access dedicated IBANs, SEPA Instant, and seamless API integrations – all from a single, unified platform.
Payment Gateway vs Payment Processor: Key Differences
Once you separate the two roles, the difference between a payment gateway and a payment processor comes down to where each one sits in the transaction and who it’s talking to.
The gateway is customer-facing: it captures and encrypts data at checkout. The processor is bank-facing: it handles authorization and settlement once that data has already left the customer’s browser. Positionally, the gateway operates between the customer and the payment network; the processor operates between that network and the banks on either side of the transaction. Gateways are essential for online sales — there’s no checkout without one — while processors can work without a gateway entirely in in-person settings. On security, the gateway’s job is encryption and fraud screening at the point of entry; the processor’s job is verifying legitimacy through that bank-to-bank handshake. And the fee structures differ too: processors typically charge a percentage or fixed fee per transaction, while gateways often add a separate monthly or per-transaction fee on top.
Here’s how that breaks down side by side:
| Payment Gateway | Payment Processor | |
|---|---|---|
| Role | Customer-facing data capture and encryption | Bank-facing authorization and settlement |
| Where it operates | Between customer and payment network | Between payment network and banks |
| Online transactions | Essential | Required alongside a gateway |
| In-person transactions | Not required | Can operate without a gateway |
| Funzione principale | Encrypts and transmits payment data securely | Verifies funds and moves money between banks |
| Security responsibility | PCI DSS encryption and fraud protection at checkout | Transaction legitimacy verification and settlement |
| Fee structure | Monthly or per-transaction gateway fees | Percentage or fixed fee per transaction |
| Customer visibility | Visible at checkout | Invisible to the customer |
The two aren’t competing for the same job — they’re complementary. Every card-based eCommerce transaction needs both to actually complete.
Do You Need Both a Payment Gateway and a Payment Processor?
For online sales, yes — pretty much every business does. The gateway captures and secures the customer’s payment details; the processor takes that data and pushes it through to the banks. Skip one and the other has nothing to work with.
The real decision isn’t whether you need both — it’s whether you get them from one provider or two. Managing separate gateway and processor relationships means two contracts and two places where something can go wrong at 2am on a Friday. Choosing a provider that offers both under one roof usually works out cheaper and less painful to operate. It’s part of why more platforms have moved toward combining the two, giving you one connection that handles the full flow instead of pairing a standalone gateway with a separate acquiring relationship. We’ve written more about how this fits together in our breakdown of payment gateway fundamentals, worth a read if you’re mapping out your setup from scratch. ConnectPay is one example of this combined approach — alongside gateway and processing functionality, it layers in IBAN accounts, multi-currency support, SEPA and SWIFT connectivity, and embedded compliance, so a business isn’t left assembling five separate pieces of infrastructure to take a payment.
Payment Gateway vs Payment Processor Examples
Abstract definitions only go so far — seeing where real providers fall on the gateway-vs-processor line makes the split easier to hold onto.
On the gateway side: Stripe Checkout, PayPal Checkout, ConnectPay’s own gateway, and Authorize.net all sit at the point of sale, capturing and encrypting customer data. On the processor side: Adyen, Worldpay, and the acquiring networks run by Visa and Mastercard handle the movement of funds behind the scenes rather than the checkout experience itself. Then there’s a third category — providers that do both. ConnectPay, Stripe, and PayPal fold gateway and processor functions into one connection rather than requiring a separate provider for each.
This is exactly why people ask, “is PayPal a payment gateway or payment processor?” — the honest answer is both, depending on how it’s integrated. For most merchants using PayPal’s standard checkout, it’s functioning as a combined solution rather than strictly one or the other. Zelle is a different case. It’s a peer-to-peer payment network built for sending money between individuals, not a merchant payment processor or gateway — it wasn’t designed to handle checkout flows, fraud screening, or settlement for a business, so “is Zelle considered a payment processor” is really a no. You can read more on how these payment types compare in our guide to business payment methods.
What Are the 4 Types of Payment Gateways?
Not all gateways work the same way, and the type you pick shapes both your checkout experience and how much PCI DSS responsibility lands on your own servers.
Hosted gateways redirect the customer to the provider’s own payment page to complete the transaction. Simplest to set up, but that redirect breaks the checkout flow and can cost you conversions. Integrated or API-based gateways keep the customer on your site the entire time, working invisibly through an API — better experience, more customization, and this is where ConnectPay’s gateway sits, letting businesses build a checkout that feels like their own product. Self-hosted gateways put the merchant in charge of collecting and forwarding payment data from their own server — maximum control, but the highest PCI DSS burden, since card data briefly passes through infrastructure you own. White label gateways hand over a fully brandable version of the infrastructure, which platforms and fintechs use to offer payments under their own name — something ConnectPay also supports for businesses that want the processing power without its branding attached.
How ConnectPay Combines Both in One Platform
If you’ve made it this far, the practical takeaway is probably obvious: managing a gateway and a processor as two separate relationships is more work than it needs to be.
ConnectPay is an EMI-licensed platform that combines payment gateway and payment processor functionality into a single connection, alongside IBAN accounts, SEPA and SWIFT payments, multi-currency support, acquisizione delle carte, e embedded AML and KYC compliance. That combination removes a real cost — not just the fees of running two vendors, but the operational overhead of reconciling two systems, two support relationships, and two points of failure. Because the architecture is API-first, businesses can embed both the checkout-facing gateway and the bank-facing processing layer directly into their own product rather than bolting on a third-party redirect. If you’re weighing up your options, it’s worth seeing the full platform to judge whether a combined setup fits your business better than piecing one together yourself.









