Choosing a payment provider (Stripe, PayPal, a local acquirer) is only half the decision. How you integrate that provider—hosted page, embedded fields, or direct API—shapes checkout conversion, PCI obligations, and how much engineering you maintain.
Here’s a clear breakdown of the three main payment gateway integration types, and how to pick the right one for an online store, SaaS billing flow, or custom app.
Quick answer
| Integration type | Best for | PCI burden | Checkout UX | Build effort |
|---|---|---|---|---|
| Hosted / redirect | Fast launch, low compliance appetite | Lowest | Leaves your site (often hurts conversion) | Lowest |
| Embedded fields (iframes / Elements) | Most modern stores & apps | Low–moderate | Stays on your page | Medium |
| Direct API (card data on your stack) | Rare; heavy control + compliance teams | Highest | Full control | Highest |
For most SMBs in 2026, embedded is the default sweet spot. Use hosted when speed and simplicity beat UX polish. Treat direct API as an enterprise exception, not a starting point.
1. Hosted payment page (redirect)
The customer clicks “Pay,” then goes to the gateway’s hosted checkout (or a full-page redirect). Card data never touches your servers.
Pros
- Fastest to ship
- Minimal PCI scope (often SAQ A–level patterns when done correctly)
- Gateway handles much of the UI, localization, and fraud tooling
Cons
- Context switch can increase abandonment (especially on mobile)
- Branding and flow control are limited
- Returning to your site after payment needs careful success/cancel/webhook handling
Use when: you’re validating ecommerce quickly, your team is small, or the gateway’s hosted experience is already trusted in your market (common with regional providers).
2. Embedded fields (iframes / Elements-style)
Payment inputs render inside your checkout page, usually via secure iframes or official SDKs (for example Stripe Elements–style components). Card data goes to the gateway; your page keeps the look and step flow.
Pros
- Customer stays on your domain and design
- Strong conversion potential vs hard redirects
- PCI scope stays manageable when you never touch raw card numbers
- Works well for one-page checkouts and in-app web views
Cons
- More frontend work than a pure redirect
- You own layout, validation UX, and mobile polish
- Still depends on correct webhook/order confirmation logic
Use when: conversion matters, you want brand-consistent checkout, and you’re building a serious ecommerce or app billing experience.
3. Direct API (your stack handles sensitive data)
Your frontend or backend collects card details and talks to the gateway API with a high-control model. This can mean raw PAN handling—which triggers the heaviest PCI obligations (often SAQ D territory).
Pros
- Maximum UI and flow control
- Custom vaulting / complex orchestration (when truly required)
Cons
- Expensive compliance, audits, and security engineering
- Higher breach impact if anything goes wrong
- Rarely justified for startups or typical SMB stores
Use when: you have a compliance program, dedicated security ownership, and a product reason that embedded SDKs cannot cover. Most teams should not start here.
PCI in plain language (why this choice matters)
PCI DSS is the security standard for handling card data. Your integration type largely decides how much of that burden sits on you.
- Hosted / properly embedded: card data stays with the gateway → lighter questionnaire and fewer controls on your app.
- Direct / raw card handling: your systems enter full cardholder data scope → audits, policies, and ongoing cost.
If a vendor pushes “just post the card number to your API,” treat that as a red flag unless compliance is already funded.
UX and conversion: when redirects hurt
Redirects fail quietly when:
- Mobile browsers interrupt the return trip
- Customers don’t recognize the gateway page
- Your order is marked paid only on redirect success (webhooks ignored)
- Back button / refresh creates duplicate or lost orders
Embedded checkout reduces those frictions—but only if you still verify payments via webhooks, not browser redirects alone. For webhook fundamentals later in this cluster, see the planned webhooks guide; for market-specific gateways, browse our payment gateway services.
Decision checklist
Ask:
- Do we need launch in days/weeks with minimal compliance overhead? → Hosted
- Do we care about on-brand checkout and mobile conversion? → Embedded
- Do we have PCI budget and a rare technical requirement? → only then consider Direct API
- Are we selling in regions where local hosted methods dominate? → hosted or embedded with a local gateway may beat a global-only stack
- Do we need subscriptions, wallets (Apple Pay / Google Pay), or installments? → confirm the integration model supports them before building
Common mistakes
- Building checkout UI that collects card numbers into your own database “temporarily”
- Trusting the thank-you page without webhook verification
- Choosing direct API because it “sounds more professional”
- Ignoring mobile return flows on hosted checkout
- Mixing test keys in production or skipping sandbox order tests
Related guides
- Stripe vs PayPal for online business
- Multi-currency checkout best practices
- Best payment gateway in the UAE (and matching guides for other GCC markets)
How EG Stars implements this
We integrate gateways into websites, apps, and billing flows with the model that fits your risk and UX goals—hosted where it wins, embedded when conversion matters—plus sandbox testing, secure key handling, webhook verification, refunds, and launch support. We’ve shipped regional and global providers (including Thawani, Moyasar, Paymob, PayPal, and Stripe) depending on market. See also payment gateway integration.
Summary
- Hosted = fastest, lightest PCI, weaker UX control.
- Embedded = best default for modern checkout conversion with manageable PCI.
- Direct API = maximum control, maximum compliance—rarely the MVP choice.
Not sure which model fits your store or app? Get in touch—we’ll map provider, integration type, and a go-live path for your markets.