If you're planning to accept online payments with Stripe, one of the first decisions you'll need to make is how much of the checkout UI you want to build yourself versus let Stripe handle.
Historically, developers framed this as Stripe Checkout vs Stripe Payment Element — two separate products. As of 2026, Stripe has consolidated both under a single API: the Checkout Sessions API, with three selectable UI modes. This guide has been updated to reflect that change.
Many developers, especially beginners working with Next.js, still ask:
- Which Stripe integration is easier?
- Should I use hosted Checkout, an embedded form, or a fully custom Elements page?
- Which one is better for SaaS products?
- Which option offers more customization?
- Can I switch later if my application grows?
In this guide, we'll compare the three UI modes, explain how each works, and help you decide which fits your project.
2026 Update: It's One API Now, Not Two Products
Stripe's current official guidance:
The Checkout Sessions API is the recommended API for most developers. The Payment Intents API is a lower-level API that you can use to build your own checkout or payments, but it requires significantly more code and ongoing maintenance. We recommend the Payment Element with Checkout Sessions for most integrations because it covers similar payment flows as Payment Intents.
In practice, this means every option below is created through the same call — stripe.checkout.sessions.create() — with a different ui_mode:
checkout.sessions.create({ ui_mode: "hosted_page" }) → full-page redirect
checkout.sessions.create({ ui_mode: "embedded_page" }) → embedded form, no redirect
checkout.sessions.create({ ui_mode: "elements" }) → fully custom UI, most control
This is the framing shift worth internalizing: it's no longer "Checkout vs Payment Element" as two separate integrations — it's one API, three levels of control, plus the older "build a PaymentIntent and drop Payment Element on it yourself" approach that still works but is now positioned as the manual, do-everything-yourself path rather than a default alternative.
Stripe also provides Checkout Studio for configuring and optimizing Checkout experiences without building every part of the UI yourself.
One of the biggest selling points of using a single checkout.sessions.create() API is the backend simplicity. Regardless of which UI mode you choose, you only need to listen for a single webhook event: checkout.session.completed. If you scales from Hosted to Elements later, your backend fulfillment logic doesn't need to change at all?
The Three UI Modes
A full-page payment experience, either via redirect to a Stripe-hosted page or embedded full-page on your site.
Customer
↓
Your Website
↓
Stripe Hosted Checkout Page
↓
Payment Completed
↓
Your Website Success Page
Advantages
- Fastest integration — a Checkout Session and a redirect is often under an hour of work
- Stripe handles compliance, PCI burden is lowest here
- Built-in payment methods (cards, Apple Pay, Google Pay, Link, bank transfers, regional methods) with zero extra config
- Continuously optimized by Stripe for conversion and mobile
Disadvantages
- Limited branding — colors/logo yes, layout no
- Customer technically leaves your page (even the "embedded" hosted variant is still Stripe's iframe content)
2. Embedded (the middle option)
An embedded form on your own page — no redirect, but still Stripe-built and maintained UI, just meaningfully less code than Elements.
Customer
↓
Your Website (embedded iframe)
↓
Stripe Processes Payment
↓
Success Page (same site)
This fills the gap the old "Checkout vs Payment Element" framing treated as binary. If your only objection to hosted Checkout was "the customer leaves my page," embedded mode solves that without taking on Elements-level implementation work.
Best for: sidebars, modals, chat-based checkout, or anyone who wants "stay on my site" without owning the full payment form's state and validation.
The established embedded mode (embedded_page) displays a full checkout form on your website, while the new 2026 preview (elements) provides smaller, modular components optimized for sidebars, chats, and modals.
A fully custom payment form built with Stripe's PaymentElement component, giving you substantially more control over the layout, appearance, and checkout flow.
Customer
↓
Your Website
↓
Payment Element
↓
Stripe Processes Payment
↓
Success Page
Advantages
- Full control over layout, branding, UX, multi-step flows
- No external redirect
- Best fit for complex ecommerce, upsells, custom checkout logic
Disadvantages
- More development work — client secrets, form state, confirmation flow all on you
- More testing surface since the flow is fully custom
💡 Note on implementation: You can reach Elements-mode UI two ways — through checkout.sessions.create({ ui_mode: "elements" }) (the current recommended path, which still gives you Stripe-managed tax/discounts/subscription logic), or the older pattern of creating a raw PaymentIntent and mounting PaymentElement yourself. The older pattern still works and is what most existing tutorials (including our own Payment Element implementation guide) show — but per Stripe's current docs, it's now the "you rebuild tax/discounts/subscriptions yourself" option, not a default equal to Checkout Sessions.
Feature Comparison
| Feature | Hosted | Embedded | Elements |
|---|
| Setup Time | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Customization | 15 configurable settings<br/> via brand settings | 70 configurable settings<br/> via the Appearance API | Full CSS customization<br/> via the Appearance API |
| Stripe-hosted page | Yes | No | No |
| Embedded on your site | No | Yes | Yes |
| Customer Stays on Site | No | Yes | Yes |
| PCI Burden | Lowest | Lowest | Low |
| Development Effort | Low | Low–Medium | Medium–High |
| Best for Beginners | Yes | Yes | No |
| Stripe manages <br/>tax/discounts/subscriptions | Yes | Yes | Yes (via Checkout Sessions)<br/>/ No (raw PaymentIntent) |
Next.js 16 Implementation Comparison
All three modes start the same way — one checkout.sessions.create() call, differing only by ui_mode and, for Elements, how you render the result.
Hosted
API Route or Server Action
→ checkout.sessions.create({ ui_mode: "hosted_page" })
→ redirect to session.url
Embedded
API Route or Server Action
→ checkout.sessions.create({ ui_mode: "embedded_page" })
→ return session.client_secret
→ mount <EmbeddedCheckout> client-side, no redirect
Elements
API Route or Server Action
→ checkout.sessions.create({ ui_mode: "elements" }) (recommended)
— or —
→ paymentIntents.create() (manual, more control, more to maintain)
→ mount <PaymentElement> client-side
→ handle confirmation flow yourself
The additional flexibility in Elements mode still comes with additional implementation complexity — that part hasn't changed.
When Should You Use Each Mode?
Choose Hosted If
- You're new to Stripe or building an MVP
- You want the fastest implementation and least maintenance
- SaaS subscriptions, digital products, small business checkout
Choose Embedded If
- Your only reason to consider Elements was "keep the customer on my page"
- You want Stripe-managed tax/discounts/subscriptions but don't need a fully custom form
- Sidebar, modal, or chat-based checkout flows
Choose Elements If
- Checkout UX is part of your product's differentiation
- You need multi-step checkouts, upsells, or deeply custom logic
- Enterprise or large ecommerce with requirements Stripe's prebuilt UI can't express
Decision Matrix
| Your Situation | Recommendation |
|---|
| First Stripe integration | Hosted |
| SaaS product | Hosted |
| Startup MVP | Hosted |
| Want to stay on your domain, minimal custom code | Embedded |
| Chat / modal / sidebar checkout | Embedded |
| Custom checkout design | Elements |
| Enterprise application | Elements |
| Large ecommerce store | Elements |
Both dimensions remain effectively a tie across all three modes when implemented correctly — Stripe's infrastructure backs PCI compliance, SCA, 3D Secure, and fraud detection identically regardless of ui_mode. Choose based on UX and development bandwidth, not performance or security differences.
Migration Path
Nothing here has changed conceptually — you're still not locked in:
Launch MVP
↓
Hosted (fastest)
↓
Validate Product
↓
Need to stay on-site → Embedded
↓
Need full custom UX → Elements
Since all three now share the same underlying checkout.sessions.create() call, moving between hosted and embedded in particular is a smaller lift than it used to be — you're mostly changing ui_mode and how you render the result, not rebuilding your integration from scratch.
Frequently Asked Questions
Is this still "Checkout vs Payment Element"?
Not officially, as of 2026 — Stripe now frames it as one Checkout Sessions API with three UI modes (hosted, embedded, elements). The old terms still describe the same UX outcomes, which is why this post keeps using them alongside the new framing.
Which is easiest with Next.js 16?
Hosted, by a clear margin. Embedded is a close second and removes the "customer leaves the page" downside with only a modest increase in code.
Should I still use a raw PaymentIntent + Payment Element instead of Checkout Sessions elements mode?
Only if you're deliberately managing tax, discounts, subscriptions, and currency conversion yourself. Stripe's current docs are explicit that Checkout Sessions is the default recommendation; raw PaymentIntents are for when you want to opt out of Stripe managing those pieces.
Can I use subscriptions with all three modes?
Yes — subscription mode works the same across hosted, embedded, and elements.
Can I switch later?
Yes, and it's easier now than before since all three share the same Checkout Sessions foundation.
Final Recommendation
Start with hosted unless you have a specific reason not to — it's still the fastest path to a working, compliant checkout. Reach for embedded the moment "customer leaves my site" is your only objection. Save elements for when checkout UX is a genuine product requirement, not a default choice.
Helpful Resources
Continue Learning
If you'd like step-by-step implementation guides, check out these tutorials:
These guides walk through complete setup, API routes, server actions, webhooks, and production deployment for both Stripe integrations. Note: both linked implementation guides currently show the pre-2026 direct integration pattern (raw Checkout Session redirect / raw PaymentIntent + Elements) rather than the unified Checkout Sessions ui_mode approach — updates to those are planned.