Online Checkout Solutions: Hosted, Embedded and One Page Checkout
Online checkout solutions are the tools that collect a shopper’s card or wallet details at the end of an online purchase and pass them securely to a payment gateway. They come in three main forms: hosted checkout on the provider’s page, embedded checkout that places the provider’s payment fields inside your page, and a direct API integration where your own systems handle card data.
That choice settles three things at once: how much of the payment page you control, how much PCI DSS work falls on your business, and how many buyers finish the purchase. One page checkout is a layout decision that can sit on top of any of the three.
The stakes are high. Baymard Institute’s meta-analysis of 50 studies puts the average documented cart abandonment rate at 70.22%.
What are the main types of online checkout solutions?
Checkout types differ by who serves the payment fields to the shopper’s browser. With hosted checkout the provider serves the whole payment page. With embedded checkout the provider serves the card fields inside your page, usually in an iframe. With a direct API your server receives card data. That difference drives design control, PCI scope and build effort.
| Checkout type | How it works | Design control | Typical PCI DSS questionnaire | Build effort |
|---|---|---|---|---|
| Hosted (redirect) | Shopper is redirected to a payment page served by the provider, then returned to your site | Limited to the logo, colors and text the provider allows | SAQ A | Lowest |
| Embedded (iframe or payment widget) | Provider’s payment form loads inside your checkout page | High around the form; the provider controls the card fields | SAQ A if every element of the payment form comes from the provider, plus the script-attack criterion | Low to medium |
| Merchant page that controls the redirect or posts data | Your page builds the payment form or passes data to the provider through your own scripts | Full | SAQ A-EP | Medium |
| Direct server-to-server API | Card data reaches your systems before going to the provider | Full | Outside SAQ A and A-EP, usually SAQ D or a full assessment | Highest |
The questionnaire column shows where each pattern usually lands. Your acquirer or the card brands decide which questionnaire applies to you, so confirm it before you build. For what happens after checkout, read our explainer on what a payment gateway is and how it works.
How does hosted checkout affect PCI DSS scope?
Hosted checkout keeps card data off your systems entirely, which is why it usually qualifies for SAQ A, the shortest PCI DSS self-assessment questionnaire. Your website never receives, stores or transmits the card number. The trade-off is less control over the payment page and a visible hop to another domain.
The PCI Security Standards Council’s SAQ A covers card-not-present merchants whose account data functions are completely outsourced to PCI DSS compliant third parties. For e-commerce it adds a condition: every element of the payment pages or forms delivered to the customer’s browser must originate only and directly from a PCI DSS compliant service provider. The merchant must also review the provider’s Attestation of Compliance and confirm it covers the services used.
Redirects got simpler in 2025. A PCI SSC clarification published on 28 February 2025 states that the new SAQ A script-attack criterion does not apply to merchants whose webpage redirects customers to the provider, for example with an HTTP 30x redirect, a meta redirect tag or a JavaScript redirect. It also does not apply to merchants that fully outsource payment, such as by emailing customers a link to the provider’s payment page.
What changes with an embedded checkout?
An embedded checkout keeps shoppers on your domain while the card fields still come from the provider. It can qualify for SAQ A. Since the new PCI DSS v4.0.1 requirements took effect on 1 April 2025, though, merchants using embedded forms must also confirm that their site is not susceptible to attacks from scripts that could affect their e-commerce systems.
PCI DSS points to settle before you embed a payment form
- SAQ A r1 for PCI DSS v4.0.1 asks embedded-form merchants to confirm their site is not susceptible to script attacks.
- According to PCI SSC FAQ 1588, you can meet this with techniques such as those in PCI DSS Requirements 6.4.3 and 11.6.1, or by getting confirmation from your PCI DSS compliant provider that its embedded form includes protection against script attacks when implemented as instructed.
- If your own website controls how shoppers or their data reach the provider, or serves elements of the payment page itself, read the SAQ A-EP eligibility criteria.
- Ask the provider for its Attestation of Compliance and written implementation instructions, and keep both on file.
In practice, the implementation guide matters as much as the product. A widget loaded exactly as documented carries far less risk than the same widget surrounded by unreviewed marketing tags on the checkout page.
Is a one page checkout better than a multi-step checkout?
A one page checkout puts shipping, delivery and payment on a single screen. Teams like it because it forces them to cut fields. Baymard’s research finds that the number of steps matters less than what customers must do on each step, so a lean multi-step flow can perform as well as a single page with the same fields.
In its analysis of one page checkouts, Baymard reports that test users had relatively few problems moving between steps when a few simple guidelines were followed, and that usability issues came mainly from what customers had to do at each step. Field count is the number to watch. Baymard’s checkout benchmark finds the average US checkout shows 23.48 form elements by default, while its testing shows an ideal flow can be as short as 12 to 14.
Count the fields in your own checkout, including the account-creation prompt. Above 20, removing fields will usually do more than merging pages.
Why do shoppers abandon checkout?
Shoppers abandon checkout mostly over cost surprises, delivery times, trust and effort. Payment problems play a smaller but direct part: declined cards and missing payment methods both appear in survey data. All of these sit in the checkout itself, so design and payment setup can fix them.
The figures below come from Baymard’s survey of US online shoppers, excluding those who were just browsing. They describe US shoppers, so treat them as an outside reference point when reviewing a Saudi checkout.
Three of these reasons are payment decisions. Trust depends on a familiar, secure-looking payment step. Declines depend on routing, 3-D Secure handling and fraud rules. Method coverage depends on what your provider supports.
Which wallets and payment methods belong on a Saudi checkout?
A Saudi checkout should start with mada, then add Apple Pay, international cards and the local wallets and installment options your customers use. Each extra method should earn its place, because a long row of logos slows the payment step on a phone screen.
- mada: SAMA’s mada page states that mada e-commerce runs over the 3-D Secure protocol, so your checkout must handle the authentication step smoothly.
- Apple Pay: the same SAMA page lists adding a mada card to Apple Pay as a mada service, so many domestic shoppers pay with mada through Apple Pay. Our Apple Pay payment gateway guide covers domain verification and certificates.
- Visa, Mastercard, American Express and UnionPay for international and premium cardholders.
- STC Pay and PayPal for wallet users, and SADAD for customers who prefer bill payment.
- Tabby and Tamara for installments on higher-value baskets.
Order the methods by what your own data shows. If most Saudi orders come from phones, put mada and Apple Pay first on mobile.
How do you choose an online checkout solution?
Pick the checkout type that matches your team’s capacity to carry PCI DSS work, then optimize the layout. A business without a security team gains most from hosted or embedded checkout. A business with strict design needs and an engineering team may justify an API build and the compliance work that comes with it.
- Confirm your PCI DSS questionnaire. Ask your acquirer which SAQ fits each checkout pattern you are considering.
- Get the provider’s evidence. Request the Attestation of Compliance and, for embedded forms, written confirmation of script-attack protection.
- Check method coverage. mada, Apple Pay and the wallets and installment options your customers use.
- Test on mobile first. Count fields, check 3-D Secure screens and run a declined card to see what the shopper sees.
- Plan for links and invoices. Phone, WhatsApp and B2B orders need payment links, not a cart.
For a decision tree by business model, see our guide to choosing the best payment gateway for e-commerce.
Why choose HyperPay for your online checkout?
HyperPay gives Saudi merchants every checkout pattern in this guide from one SAMA-licensed provider, so you can match the integration to your PCI DSS position instead of rebuilding when it changes. HyperPay Payments offers a checkout that works across browsers and devices, with customizable options for the payment form and ready-made plugins for popular shopping cart platforms.
- COPYandPay, HyperPay’s JavaScript payment widget, sends card data directly from the shopper’s browser to HyperPay’s payment platform, which keeps card numbers off your servers.
- A server-to-server API supports fully custom flows, and mobile SDKs for Android and iOS add in-app payments. All three are listed in HyperPay’s integration guide.
- The gateway supports tokenization, recurring payments and pre-authorization.
- Shoppers can pay with mada, Visa, Mastercard, American Express, UnionPay, Apple Pay, STC Pay, PayPal, SADAD, Tabby and Tamara.
- HyperPay Protect adds real-time fraud screening, blacklists and 3-D Secure to the payment step.
- HyperBill issues invoices and sends them by SMS, email or WhatsApp, so customers can pay without a website checkout.
Behind the product sit public credentials. HyperPay is certified to PCI DSS v4.0.1 Level 1, ISO/IEC 27001:2022 and ISO 22301, and is licensed by SAMA as an Electronic Money Institution, listed on SAMA’s register as Hyperpay Inc Saudi Information Systems Technology Company. Ask our team which integration fits your PCI DSS position and for the documents your acquirer will want to see.
Frequently asked questions
What is an online checkout solution?
An online checkout solution is the part of a payment setup that collects the shopper’s card or wallet details and sends them to the payment gateway. It can be a hosted page run by the provider, an embedded form inside the merchant’s page or a direct API integration. The type chosen determines design control, PCI DSS scope and build effort.
What is the difference between hosted and embedded checkout?
With hosted checkout the shopper is redirected to a payment page run by the provider and returned afterwards. With embedded checkout the provider’s payment fields load inside the merchant’s own page, often in an iframe. Both can qualify for PCI DSS SAQ A, but embedded checkout also requires confirming the page is protected against script attacks.
Is a one page checkout better for conversion?
Not automatically. Baymard’s research shows shoppers handle multiple steps well when basic guidelines are followed, and that friction comes mainly from the fields and tasks on each step. A one page checkout helps when it forces the team to remove fields. A lean multi-step flow with the same fields can perform about as well.
What is the average cart abandonment rate?
Baymard Institute calculates an average documented online cart abandonment rate of 70.22%, based on 50 studies. Its survey of US shoppers lists extra costs, slow delivery, distrust of the site with card details and forced account creation among the top reasons. These are US figures and should not be read as Saudi benchmarks.
Which PCI DSS questionnaire applies to a hosted checkout?
A merchant using a hosted checkout that fully outsources card processing to a PCI DSS compliant provider usually completes SAQ A. PCI SSC clarified in February 2025 that the newer script-attack criterion does not apply to merchants that redirect shoppers to the provider’s page. Your acquirer confirms which questionnaire applies to your setup.
If you are planning a new checkout or replacing one that loses orders, contact HyperPay to compare the integration options for your store or app.