How an embedded checkout works
The merchant's page loads the provider's JavaScript library or mobile SDK, which draws the payment form in a container on the page. The form is either one iframe holding the whole checkout, or hosted fields: a separate iframe for each of the card number, the expiry date and the security code, styled to match the page.
When the buyer pays, the fields send the card data straight to the provider, and the merchant's page receives a token or a payment result. The merchant's server confirms the payment through the provider's API, and a webhook reports the final outcome. A 3-D Secure challenge, when the issuer asks for one, opens in an overlay on the same page.
Why merchants choose an embedded checkout
The buyer stays on the merchant's domain and sees the merchant's design, which is why embedded forms are common where conversion is measured closely. Wallet buttons such as Apple Pay and Google Pay, and local payment methods, load into the same component.
The trade-off is the page around the form. A malicious script on that page can alter what the buyer sees, so the merchant keeps some PCI DSS duties for the page, which a full redirect would move to the provider.
Embedded checkout or hosted checkout?
- Hosted checkout
- A full page on the provider's domain, to which the buyer is redirected. Less to build and less for the merchant to secure, at the cost of leaving the merchant's site.
- Direct API integration
- The merchant's own form collects card numbers and sends them to the provider's API. Full control over the design, and the merchant's systems handle card data.
Where an embedded checkout shows up in a platform
Modules that do the work
- CheckoutA hosted checkout for cards, wallets, bank payments and crypto, routed to the best provider.
- Card acquiringCard acceptance on the phone, in store and online, through the acquirer you choose.
- Fraud & riskReal-time fraud scoring, limits and case management, with the risk engines you already trust.