Payment Gateway vs Payment Processor
Definition
A payment gateway is the software layer that securely captures, encrypts, and transmits payment data from the point of sale to the processor, while a payment processor routes the transaction through card networks and facilitates the actual movement of funds between issuing and acquiring banks.
How It Works
When a customer enters card details, the payment gateway encrypts the data via TLS and tokenization, then sends an authorization request to the payment processor. The processor forwards this to the card network (Visa/Mastercard), which routes it to the issuing bank for approval. At settlement, the processor initiates fund movement from the issuing bank through the network to the acquiring bank, which deposits into the merchant's account.
Why ISVs Care
ISVs must decide whether to integrate a standalone gateway and pair it with a separate processor, or use a full-stack provider that bundles both. Gateway-only integrations give more control over processor selection and pricing negotiation but add complexity. For ISVs building embedded payments, this distinction determines API architecture decisions, PCI scope (gateway-side tokenization reduces it), and whether the ISV can switch processors without rewriting their checkout flow.
Understanding the difference between a payment gateway and a payment processor is foundational for any ISV evaluating payment integration strategies.
The Core Distinction
A payment gateway handles the front end of a transaction: capturing card data, encrypting it, and transmitting it securely. A payment processor handles the back end: routing authorization requests through card networks, communicating with issuing banks, and orchestrating fund settlement.
Think of it this way: the gateway is the secure messenger, the processor is the logistics coordinator.
How They Work Together
Here’s what happens in a typical card transaction:
- Customer submits payment — The gateway captures card details via hosted fields or SDK
- Gateway encrypts and tokenizes — PAN is replaced with a non-sensitive token, reducing PCI scope
- Gateway sends to processor — An authorization request is forwarded to the payment processor
- Processor routes to card network — Visa, Mastercard, or other network receives the request
- Card network contacts issuing bank — The cardholder’s bank approves or declines
- Response flows back — Approval/decline returns through the same chain to the gateway
- Settlement occurs — Typically end-of-day, the processor initiates fund movement to the merchant’s acquiring bank
The entire authorization leg takes 1-3 seconds. Settlement typically occurs within 1-2 business days.
Why This Matters for ISVs
For ISVs building embedded payments, the gateway vs. processor distinction has three direct implications:
PCI Compliance Scope
Using a gateway with hosted fields or iframes (like Stripe Elements or Adyen’s Drop-in) qualifies your platform for SAQ A — the lightest PCI compliance burden. Direct API integration with a processor typically requires SAQ D, which involves significantly more security controls and audit requirements.
Vendor Lock-in and Portability
If your gateway and processor are the same provider (Stripe, Adyen, Braintree), switching means rebuilding your entire payment flow. If you use a gateway-only provider with a separate processor, you can swap processors without touching the checkout UX — though this architecture is more complex to build initially.
Revenue Optimization
ISVs that separate gateway and processor can negotiate processing rates independently, potentially securing better interchange-plus pricing at scale. Full-stack providers offer simplicity but less pricing flexibility.
Common Misconceptions
“They’re the same thing.” They’re not, though many providers bundle both. Stripe, for example, acts as both gateway and processor — which is why developers sometimes conflate the two.
“ISVs only need a gateway.” You always need both. The question is whether they come from the same vendor or different vendors.
“Processors are always cheaper than full-stack providers.” At scale, direct processor relationships can save money. Below ~$10M in annual processing volume, the overhead of managing separate gateway and processor relationships rarely justifies the savings.
Choosing the Right Approach for Your ISV
| Factor | Full-Stack (Gateway + Processor) | Separate Gateway + Processor |
|---|---|---|
| Integration speed | Faster — single API | Slower — two integrations |
| PCI scope | Depends on method | Depends on method |
| Pricing flexibility | Fixed or tiered | Negotiable at scale |
| Processor portability | Low — tightly coupled | High — swap processors easily |
| Best for | ISVs < $10M TPV, speed priority | ISVs > $50M TPV, cost optimization |
What This Means for Embedded Payments
For ISVs considering embedded payments, start with a full-stack provider like Stripe Connect, Adyen for Platforms, or Finix. The integration speed advantage outweighs the pricing flexibility of separate gateway/processor at early stages.
As your platform scales past $50M in total payment volume, evaluate whether separating gateway and processor — or becoming a PayFac — makes economic sense.