English
German
Spanish
French
Turkish
Back to Guides
Types of Payment Gateways Explained: Hosted, API, Self-Hosted, and Crypto
Payment gateways fall into four architectural categories, each with a different tradeoff between integration effort, checkout control, PCI compliance scope, and conversion rate. Crypto payment gateways form a fifth category that sits outside the card-payments taxonomy entirely.
This guide compares the five types side by side, with concrete use cases, PCI implications, and a decision framework at the end for picking the right architecture for your business.
Boost Your Business by Accepting Crypto Payments
Why the Type of Gateway Matters
The type of gateway you pick decides three things you will live with for years:
- How much control you have over the checkout UI. Branding, layout, fields, error messages, conversion funnel.
- How much PCI DSS scope you absorb. From near-zero (SAQ-A) to a full audit (SAQ-D). The gap is tens of thousands of dollars and months of engineering work per year.
- How fast you ship and how easily you maintain. Hosted is weeks; pure API is months. Both are legitimate choices; picking without knowing the tradeoff is a mistake.
Four traditional types exist for card payments: hosted, self-hosted, API/integrated, and local bank integration. Crypto payment gateways form a fifth category - structurally different because there are no cards and no PCI scope to worry about.
Hosted Payment Gateway
A hosted payment gateway redirects the buyer from your site to a PSP-hosted checkout page to complete the payment, then returns them to your site afterward.
Pros
- Fastest integration; can be live in hours.
- Lightest PCI scope (SAQ-A). The PSP handles everything.
- PSP maintains UI, new payment methods, and compliance updates for you.
- Good default for small merchants, pilot integrations, and non-technical teams.
Cons
- Off-site redirect hurts conversion 2 to 8% on mobile.
- Limited branding and UX control.
- Some modern PSPs mitigate this with iframes or drop-in widgets.
Best for: SMBs, lean teams, non-technical merchants, pilots, any business where payment UX is not a competitive differentiator.
Self-Hosted Payment Gateway
A self-hosted gateway keeps the buyer on your site, but the form is yours to build, style, and host. Card data goes from your server to the gateway over your backend.
Pros
- Full UI control. The checkout looks and feels like your product.
- No redirect, no iframe; best possible conversion rates.
Cons
- Heaviest PCI scope (SAQ-D). Card data touches your servers.
- Typically $50k to $200k per year in compliance overhead.
- Large attack surface for card skimmers (Magecart).
Best for: Enterprise merchants with dedicated compliance teams and an existing PCI program. Rare for greenfield builds in 2026 because modern API gateways with hosted fields achieve 95% of the UX benefit at 5% of the compliance cost.
API / Integrated Gateway (Modern Default)
An API gateway uses client-side SDKs (hosted fields, drop-in components, or tokenizing iframes) to collect card data directly from the buyer to the gateway, bypassing your servers entirely. You build a native-feeling checkout in your own UI, but the sensitive data never touches your infrastructure.
Pros
- Full UI control + lightest PCI scope (SAQ-A). Best of both worlds.
- Native mobile SDKs, Apple Pay / Google Pay, 3DS2, tokenization all out of the box.
- Modern developer experience; webhooks, idempotency, sandbox parity.
Cons
- More engineering work than hosted (weeks, not hours).
- Requires frontend JS/SDK integration discipline to preserve SAQ-A.
Best for: The default choice for modern e-commerce, SaaS, marketplaces, and any business that wants a native checkout without a PCI audit. 80% of new integrations in 2026 are this type.
Local Bank Integration Gateway
A local bank integration gateway connects directly to the buyer's bank, usually for account-to-account (A2A) payments, pay-by-bank, iDEAL, PIX, UPI, Bizum, BLIK, or similar local schemes. The buyer authenticates with their bank; funds move via open banking or the local card network.
Pros
- Extremely low fees (often 0.1 to 0.5% flat).
- Instant settlement in most schemes.
- No chargeback rights on many local schemes.
- Essential for markets where cards are a minority payment method (NL, BR, IN, PL).
Cons
- Geo-specific; each country is a separate integration.
- Consumer protection varies by scheme.
- UX differs wildly between countries.
Best for: International merchants with meaningful volume in specific countries, or any business where shaving 2 to 3 percentage points off fees is material.
Crypto Payment Gateway (The Fifth Type)
A crypto payment gateway sits outside the card-payments taxonomy entirely. There is no PAN, no PCI, no interchange, no acquirer, no merchant account. The buyer's wallet signs a transaction; the blockchain settles it.
Pros
- Sub-1% flat fees vs 2.9%+ on cards.
- No chargebacks ever.
- Instant cross-border settlement.
- High-risk categories accepted.
- Stablecoin rails eliminate volatility.
Cons
- Buyer needs a crypto wallet (addressable market ~600M and growing).
- Operational team has to understand confirmations, reorgs, and off-ramp.
- Regulatory picture still evolving in several jurisdictions.
Like API gateways, most modern crypto gateways come in hosted and API flavors. A hosted crypto checkout is a redirect to a QR-code page; an API crypto checkout is an embedded widget or programmatic invoice creation. Same architectural choice, different rails underneath.
Best for: Any business where fees, chargebacks, or global reach are material constraints. Increasingly a default option alongside cards, not a replacement.
All Five Types at a Glance
| Type | Integration effort | UX control | PCI scope | Typical fee | Best for |
|---|---|---|---|---|---|
| Hosted | Hours | Low | SAQ-A (lightest) | 2.9% + $0.30 | SMBs, pilots |
| Self-hosted | Weeks + audit | Full | SAQ-D (heaviest) | 2.5 to 3.5% | Enterprise with PCI program |
| API / integrated | 1 to 4 weeks | Full | SAQ-A | 2.5 to 2.9% | Modern default |
| Local bank integration | Per-country, weeks | Medium | None (non-card) | 0.1 to 0.5% flat | Geo-specific expansion |
| Crypto gateway | Days to 2 weeks | Full (hosted or API) | None | 0.4 to 1% flat | High-risk, global, low-margin |
How to Choose a Type
A quick decision framework:
- Do you have a PCI program and a compliance budget? If no, rule out self-hosted immediately.
- Do you need native checkout UX? If yes, pick API/integrated. If you can tolerate a redirect, hosted is cheaper and faster.
- Do you serve buyers in countries with strong local non-card rails? Add local bank integration on top.
- Are your fees, chargebacks, or global reach a problem? Add a crypto gateway as a second checkout option. Fiat and crypto are complements, not substitutes.
- Are you in a high-risk vertical? Lead with crypto. Most card acquirers will reject you; crypto gateways will not.
The best modern stacks look like: API gateway for cards + Apple/Google Pay, local bank integration for key markets, crypto gateway alongside both. One checkout, multiple rails, picks the cheapest and fastest path for each buyer.
Boost Your Business by Accepting Crypto Payments
Get Started
Frequently Asked Questions
Four traditional types: hosted (redirect to PSP page), self-hosted (form on your site, card data via your server), API or integrated (form on your site, card data direct to gateway via SDK), and local bank integration. A fifth modern category is the crypto payment gateway, which does not fit inside the card-payment taxonomy.
A hosted gateway redirects the buyer to a PSP-hosted checkout page. An API gateway keeps the buyer on your site with a native checkout, while sensitive card data goes directly from the client to the gateway via SDK, bypassing your servers. API gateways give you full UX control at the lightest PCI scope, which is why they are the modern default.
Hosted gateways and API/integrated gateways both qualify for PCI DSS SAQ-A, the lightest self-assessment. Self-hosted gateways that touch card data on your server require SAQ-D, the heaviest. Crypto gateways have no PCI scope at all.
A gateway where the checkout form lives on your server and card data passes through your backend before being forwarded to the gateway. Maximum UI control, maximum PCI scope. Mostly used by enterprise merchants with dedicated compliance teams.
A gateway that connects to local bank or account-to-account rails (iDEAL in the Netherlands, PIX in Brazil, UPI in India, Pay-by-Bank in the UK). Low fees, fast settlement, but geo-specific and often without chargeback rights.
Functionally yes, structurally separate. They do the same job (capture, authorize, settle) but on blockchain rails instead of card networks, so the fee model, compliance picture, and operational details are entirely different.
Partially. Most hosted gateways offer logo, color, and copy customization, but you cannot fully change the layout or field ordering. For pixel-perfect brand control, use an API gateway with hosted fields.
API/integrated gateways, because the buyer never leaves your site and the UX is fully native. Hosted gateways typically lose 2 to 8% of mobile conversion to the redirect. Self-hosted matches API conversion but at a much higher compliance cost.
Yes, and most mature merchants do. A typical stack is: API gateway for cards and wallets, local bank integration for specific countries, and a crypto gateway for global or high-risk buyers. A payment orchestration layer can route transactions across all three based on rules.
Start with an API/integrated gateway from a reputable PSP. It gives you native UX, lightest PCI, fastest iteration, and the widest payment-method coverage. Add a crypto gateway early if your vertical is high-risk or your margins cannot sustain 3% card fees.
