An embedded checkout keeps the payment form inside the merchant's own page, so the buyer types card details and finishes the order without the browser ever leaving the store's URL. The page belongs to the merchant; the fields inside it belong to the provider.
Iframes, tokens and the merchant's DOM
The provider supplies a client-side component — hosted fields in an iframe, or a mounted JavaScript element — that renders inside the merchant's layout. Keystrokes go into the provider's frame, which the merchant's own scripts cannot read.
That frame exchanges the card data for a single-use token. The merchant's server then sends the token, the amount and an order reference for authorization through its payment gateway. The card number never reaches merchant infrastructure.
The compliance scope you take on
This is the real trade-off, and it is not zero. Because the merchant controls the page that loads the payment script, it normally sits in a heavier PCI DSS self-assessment category than a full redirect to a hosted payment page would allow.
In practice that means script integrity checks, a content security policy, external scanning, and change control over anything touching the checkout template. A merchant unable to commit to those obligations should not run an embedded form, whatever it does for conversion.
Handling a 3-D Secure challenge in your own layout
Authentication is where these integrations get untidy. Some issuers return a frictionless result and nothing appears; others demand a challenge, which the component renders in a modal or an inline frame.
Test both paths, plus the buyer who closes the challenge window, plus an issuer that times out. A flow that only works when the bank is quiet will fail on exactly the transactions worth the most.
What it costs to run
An embedded form is a maintained integration, not a one-time build. Provider SDK versions change, browsers tighten iframe and cookie behavior, and every release needs regression testing across devices and wallets.
Budget that upkeep against the gain, which is precisely the redirect you removed: no domain change, no session lost inside an in-app browser, no return journey that can fail. Whether it pays back is a question for checkout optimization data rather than preference.
When it is the wrong pattern
Low order volume, no in-house frontend capability, or a market where most buyers pay by bank redirect anyway — in each case an embedded form adds obligations without a return. Repeat buyers with stored credentials are served better by one-click checkout, which is often built on the same component.