What Is a Payment Gateway
Definition
A payment gateway is a technology service that authorizes and encrypts payment transactions between a merchant's application and the acquiring bank's payment processor, acting as the secure intermediary that transmits cardholder data without exposing it to the merchant's systems.
How It Works
The gateway exposes APIs (REST or hosted fields/iframes) that the merchant's application calls to initiate a transaction. When a customer submits payment, the gateway tokenizes the card data at the point of entry, replacing the PAN with a non-sensitive token. It then constructs an authorization message and forwards it to the processor, handling retry logic, 3D Secure authentication, and AVS/CVV verification.
Why ISVs Care
The gateway is the primary integration point for any ISV adding payments. Gateway selection determines PCI DSS scope — hosted fields or iframes (SAQ A) vs. direct API integration (SAQ D). It dictates UX flexibility over checkout design, available currencies and payment methods, and whether the ISV can support multi-processor routing. ISVs building vertical SaaS often choose gateways with robust APIs and white-label capabilities.
A payment gateway is the technology that makes digital payments possible. For ISVs integrating payments into their software, it’s the first and most critical infrastructure decision.
What a Payment Gateway Actually Does
At its core, a payment gateway performs four functions:
- Data capture — Collects card numbers, expiration dates, and CVV codes through secure input fields
- Encryption and tokenization — Replaces sensitive card data with non-reversible tokens before it ever touches your servers
- Authorization routing — Sends the transaction to the payment processor with the right message format
- Response handling — Returns approval, decline, or error codes to your application in real-time
The gateway sits between your application’s checkout UI and the payment processor. Every digital transaction — whether online, in-app, or via API — passes through a gateway.
How Payment Gateways Work (Technical Flow)
When a customer pays through an ISV’s platform:
- Frontend capture — The gateway’s SDK (hosted fields, Drop-in UI, or API) collects payment data in the customer’s browser or device
- Client-side tokenization — Card data is tokenized before it ever reaches the ISV’s server, reducing PCI scope to SAQ A
- Server-side authorization — The ISV’s backend sends the token to the gateway’s API with transaction amount, currency, and metadata
- Gateway to processor — The gateway constructs an ISO 8583-format message and routes it to the appropriate payment processor
- 3D Secure (if required) — For SCA/PSD2 compliance, the gateway handles the challenge flow with the cardholder’s bank
- Authorization response — Approved, declined, or flagged for review — returned to the ISV in ~1-3 seconds
- Webhook notifications — Asynchronous events for settlement, chargebacks, and disputes arrive via webhooks
Types of Payment Gateway Integrations
ISVs typically choose from three integration approaches:
Hosted Payment Page (Redirect)
The customer leaves the ISV’s app and completes payment on the gateway’s hosted page. Lowest PCI burden (SAQ A) but the worst user experience — context switching kills conversion rates.
Embedded Components (Hosted Fields / Drop-in)
The gateway provides pre-built UI components (Stripe Elements, Adyen Drop-in, Braintree Hosted Fields) that render within the ISV’s checkout flow. Card data never touches the ISV’s servers. This is the recommended approach for most ISVs — it balances PCI simplicity with UX control.
Direct API Integration
The ISV collects card data directly and sends it to the gateway via API. Maximum UX flexibility but requires SAQ D compliance — significantly more security controls, quarterly scans, and potentially an on-site QSA audit. Only appropriate for ISVs processing high volumes with dedicated security teams.
What ISVs Should Look For in a Gateway
| Feature | Why It Matters for ISVs |
|---|---|
| Multi-currency support | Enables your merchants to accept payments in their customers’ local currencies |
| Tokenization vault | Store payment methods for recurring billing without handling raw card data |
| White-label checkout | The payment experience carries your brand, not the gateway’s |
| Multi-processor routing | Route transactions to different processors by geography, card type, or cost optimization |
| Webhook reliability | Mission-critical for reconciliation — you need guaranteed delivery with retry logic |
| Sandbox environment | Test transactions without hitting live card networks |
Gateway vs. Full-Stack Payment Provider
Many modern providers (Stripe, Adyen, Square) bundle gateway and processor functionality together. For ISVs, the key question is whether you need the gateway as a standalone component or as part of a complete payment stack.
Standalone gateway makes sense when you want to choose your own processor, need multi-processor routing for cost optimization, or have existing processor relationships.
Full-stack provider makes sense when you want the fastest integration path, don’t need processor portability, and prefer a single vendor relationship.
PCI Compliance Impact
Your gateway integration method directly determines your PCI DSS compliance scope:
| Method | SAQ Level | Effort | Suitable For |
|---|---|---|---|
| Hosted page (redirect) | SAQ A | Low | MVPs, low-volume ISVs |
| Hosted fields / Drop-in | SAQ A | Low | Most ISVs (recommended) |
| Direct API (server-side) | SAQ D | High | High-volume ISVs with security teams |
| iFrame embed | SAQ A-EP | Medium | ISVs needing URL control |
For most ISVs, hosted fields provide the optimal balance: SAQ A compliance with full UX control over the checkout experience.