Embedded checkout is a payment integration that keeps the card form inside the merchant's own page, so the buyer completes the order without leaving the store's URL, while the payment fields belong to the provider. The provider's hosted fields or JavaScript element run in an iframe the merchant's scripts cannot read and exchange card data for a single-use token, which the merchant's server sends for authorization through its gateway. Because the merchant controls the page loading the script, it falls into a heavier PCI DSS self-assessment category than a hosted payment page redirect, requiring script integrity checks. 3-D Secure challenges must render inside the layout, and SDK and browser changes make regression testing a recurring cost.
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.