Checkout Usability
Part of Checkout technology for Australian merchants
Hosted checkout versus embedded checkout
Compare hosted and embedded checkout by page control, redirects, order handoff, card-data scope and the work each option leaves to the merchant.
Choose a hosted checkout if the provider’s payment page meets the purchase needs and the store can manage the redirect and return. Choose an embedded checkout if payment needs to sit within the merchant page and the team can maintain that page’s layout, state and error handling. Both approaches need a dependable handoff from payment to order.
What changes for the buyer and the store
A hosted checkout sends the buyer to a provider-hosted payment page. An embedded checkout places a provider form or components on the merchant page. An embedded provider component is different from a merchant-built card form, even if both appear within the same site.
| Question | Hosted page | Embedded provider form or components |
|---|---|---|
| Where does the buyer enter payment details? | On the provider-hosted page. | In provider-supplied elements on the merchant page, subject to the chosen integration. |
| Who shapes the page? | The provider controls more of the payment page; the merchant controls the pages around it. | The merchant controls the surrounding page and must keep its order summary and payment state in step. |
| Can the buyer leave the site? | The initial journey includes a redirect. | Some payment methods or authentication steps may still redirect the buyer. |
| What needs checking? | Branding, available fields, session expiry and the return journey. | Component styling, amount updates, mobile layout and error recovery. |
Adyen’s documented standard integration, for example, requires merchant payment and webhook servers for both options. Neither detail should be assumed for another provider.
Hosted vs Embedded Checkout: Key Differences
- Where does the buyer enter payment details?On the provider-hosted page.
- Who shapes the page?The provider controls more of the payment page; the merchant controls the pages around it.
- Can the buyer leave the site?The initial journey includes a redirect.
- What needs checking?Branding, available fields, session expiry and the return journey.
- Where does the buyer enter payment details?In provider-supplied elements on the merchant page, subject to the chosen integration.
- Who shapes the page?The merchant controls the surrounding page and must keep its order summary and payment state in step.
- Can the buyer leave the site?Some payment methods or authentication steps may still redirect the buyer.
- What needs checking?Component styling, amount updates, mobile layout and error recovery.
Plan the return and order handoff
Before payment begins, the store must supply the intended amount, currency and order reference in the form its provider requires. Afterwards, it needs a reliable outcome for the order. A browser reaching a return page does not alone establish that payment succeeded.
Adyen’s hosted flow, for example, returns the shopper to the merchant website with session data; the merchant server retrieves the session result, while a separate webhook provides the payment outcome.
Trace cancellation, a declined attempt, expiry and retry. Can the buyer resume with the basket intact? Can several attempts remain linked to one order? If a method sends the buyer to an app or another site, is the route back clear? Record the answers for the product under consideration.
Order Handoff Flow: Hosted Checkout (Adyen)
- Merchant sends amount, currency, order reference to AdyenVia API request with required parameters
- Buyer redirected to Adyen-hosted payment pageSecure payment environment managed by Adyen
- Payment completed on hosted pageSession data retained for retrieval
- Buyer returned to merchant site with session dataRedirect includes session token for lookup
- Merchant server retrieves session resultCalls Adyen API to confirm payment status
- Webhook delivers final payment outcomeAsynchronous notification from Adyen to merchant server
Check card-data responsibilities separately
A hosted page or provider iframe may reduce the card-data handling the merchant implements. The interface name does not determine a PCI assessment category.
PCI Security Standards Council guidance says that, for an embedded iframe to qualify for SAQ A, all elements involved in collecting or processing card data must come directly from a PCI DSS validated third-party provider. The other eligibility criteria must also be met. The actual implementation needs its own assessment.
PCI Compliance Implications: Hosted vs Embedded Checkout
- Pros – Hosted CheckoutReduces merchant’s PCI DSS scope if all card data is handled by a validated third party.
- Cons – Hosted CheckoutLess brand control over payment experience; redirect can increase cart abandonment.
- Pros – Embedded CheckoutSeamless UX within merchant site; consistent branding across checkout flow.
- Cons – Embedded CheckoutRequires full PCI DSS compliance if components are not fully validated by a third party.
Compare with a real basket
Use the same sample order for each candidate. Include a delivery change, discount, payment failure and return from an external step when that step applies. Record which screen displays the amount, how the order receives its final payment state, and who can repair a broken handoff.
