Embedded Checkout

Overview

How it works and why it matters

Embedded checkout places payment controls inside the merchant's website or application rather than sending buyers to an entirely separate page. Integration boundaries still matter: who hosts sensitive components, signs payment requests, enforces amounts and validates server-side payment outcomes.

Important technical and operational details

The customer remains on the merchant surface while the provider may collect sensitive payment data or coordinate the Checkout Session. Embedded checkout differs from a fully merchant-built Checkout Page and from a provider-hosted redirect. For clearer boundaries, compare Checkout Session with Checkout Page ; they may share identifiers while representing different stages or responsibilities.

The merchant must validate order data server-side and reconcile the embedded session with provider events and the final order and payment states. Operational controls include allowed domains, content security policy, secure token use, version management, accessibility testing, localization, loading and failure states, and server-side event reconciliation.

Operational controls include allowed domains, content security policy, secure token use, version management, accessibility testing, localization, loading and failure states, and server-side event reconciliation. This evidence lets support and engineering distinguish customer exits from technical failures, retry safely, and reconcile asynchronous provider events without creating duplicate orders or charges.

Support staff should be able to explain the status without creating a second order or payment action.

Related concepts

Checkout Session; Checkout Page

Further reading

• docs.stripe.com documentation
• docs.stripe.com documentation