Hosted checkout vs embedded checkout
Send the buyer to the payment company's page, or mount their card fields inside yours. Same money, different branding, different PCI paperwork.
See it
What it is
Two separate questions get mashed into one word. First: who hosts the card fields, the provider or you? Second: where do those fields appear, on a page the buyer is sent to, in an overlay on top of your page, or inline inside your own form? Provider-hosted fields do all three: Stripe Checkout can redirect or embed, Paddle drops an overlay over your page, Stripe's Payment Element and Adyen Drop-in sit inside your markup. In everyday usage 'hosted' means provider-hosted and taken away from your page, 'embedded' means provider-hosted and inline, and actually touching raw card data yourself is a third, much rarer thing.
The trick that makes inline safe: those input fields are iframes served from the provider's domain, so the raw card number never enters your DOM or your server. Done that way you can qualify for the smallest PCI bucket (SAQ A), as long as you meet every eligibility condition for it, including how the page is delivered and which scripts you load onto it. Hand-roll the card form with your own inputs and the card data now flows through your systems, which expands your PCI scope toward SAQ D and a much longer control set. SAQ D is a self-assessment questionnaire, not automatically an external audit, though your acquirer can still require a QSA depending on your volume and history.
What you trade either way: the provider's page ships wallets, 3-D Secure, tax fields, and new payment methods without you writing code, while your own form buys branding and control at the price of owning the edge cases.
Gotcha: the fear of redirects is mostly folklore. Provider pages usually convert as well or better because they are relentlessly optimized, localized, and wallet-ready. Pick embedded when checkout is part of the product experience (marketplaces, multi-step flows, in-app upgrades) and accept that you now own the error states, the 3-D Secure return URL, and the mobile keyboard behavior.
Ask AI for it
Give me both checkout paths in my Next.js store so I can compare. One: a hosted Stripe Checkout Session created server-side from a price ID, with success and cancel URLs, that redirects the customer to Stripe. Two: an embedded flow using a server-created PaymentIntent plus the Payment Element mounted inside my own styled form, with confirmPayment handling the 3-D Secure redirect and a return_url that verifies status server-side. In both versions no raw card number may touch my DOM, my logs, or my server, and the order is only marked paid from the webhook.