Skip to content
Ajgori Technologies
All posts

E-commerce 9 min read

Hosted payment page vs embedded checkout: pros and cons

How hosted payment pages and embedded checkouts work, and how they differ on security, customer experience and development effort.

On this page
  1. How a hosted payment page works
  2. How an embedded checkout works
  3. Hosted payment page vs embedded checkout at a glance
  4. Security and compliance differences
  5. Effect on the customer experience
  6. When to choose a hosted payment page
  7. When to choose an embedded checkout
  8. Summary

A hosted payment page vs integrated checkout decision is mostly a trade-off between simplicity and control. With a hosted payment page, customers leave your site briefly to pay on a page run by the payment gateway, which keeps card details away from your systems and is quick to set up. With an embedded checkout, customers pay without leaving your page, which gives a smoother experience and more design control, but asks more of your developers and your security setup. Both are widely used and both can be safe.

A payment gateway is the service that processes card and wallet payments for your online store. Many gateways offer both options, sometimes with several variations. This guide explains how each works, how they differ on security, customer experience and effort, and how to choose. If you need help with a checkout, our e-commerce service page explains how we work.

How a hosted payment page works

A hosted payment page is a checkout page run by the payment gateway on its own website.

  1. The customer reviews their order on your site and clicks to pay.
  2. Your site creates a payment session with the gateway, including the amount, currency and an order reference.
  3. The customer is redirected to the gateway's page, which may show your logo and colours.
  4. They enter their payment details there, and complete any verification step from their bank.
  5. The gateway sends them back to your confirmation page.
  6. The gateway notifies your server of the result through a webhook, a direct message from the gateway to your store.

Because the customer types their card details on the gateway's page, those details never pass through your website or server.

How an embedded checkout works

An embedded checkout collects payment details inside your own page. The customer never leaves your site.

  1. Your checkout page loads a payment component provided by the gateway, such as secure card fields or a full payment form.
  2. The customer enters their details in those fields, which look like part of your page.
  3. The component sends the details directly to the gateway, which returns a token, a stand-in reference, to your site.
  4. Your site completes the payment using that token, and handles any verification step within the page.
  5. The result is confirmed on your page and through a webhook to your server.

What your developers handle

With an embedded checkout, your team takes on work that a hosted page would handle for you:

  1. Loading the payment component correctly on every device and browser.
  2. Showing errors clearly, such as a declined card or a mistyped expiry date, in your own design.
  3. Handling bank verification inside the page, including customers who close or fail the verification step.
  4. Preventing double payments if a customer clicks twice or refreshes during processing.
  5. Testing every payment method you offer, in the gateway's test environment, before launch.
  6. Keeping the integration updated when the gateway releases new versions of its components.

None of this is unusual for an experienced developer, but it should be included in the plan and the quote.

In most modern embedded checkouts, the sensitive card fields are still controlled by the gateway, even though they appear inside your design. This is different from building your own card form, which puts full responsibility for card data on your business and is rarely a good idea for small and medium stores.

Hosted payment page vs embedded checkout at a glance

Criteria Hosted payment page Embedded checkout
Customer experience Brief redirect to another page Stays on your site throughout
Design control Limited to the gateway's branding options Close match to your own design
Development effort Lower Higher, including error and verification handling
Security responsibility Mostly with the gateway Shared, with more on your site's security
Payment methods Gateway shows the methods it supports You choose which methods to show and how
Maintenance Mostly handled by the gateway Your team maintains the checkout page and integration

Security and compliance differences

Any business that accepts cards must follow the PCI Data Security Standard (PCI DSS), which sets security requirements for handling card data. How much of the standard applies to you depends largely on how card details are collected.

  1. Hosted payment pages keep card entry entirely on the gateway's systems. This usually means fewer requirements for your own website, though you are still responsible for keeping your site secure and the link to the payment page trustworthy.
  2. Embedded checkouts using the gateway's secure fields also keep card details off your server, but because the payment form sits inside your page, the security of that page matters more. A compromised page could, in principle, interfere with what customers see.
  3. Your own card form, where card numbers pass through your server, brings the widest responsibilities and is best avoided unless you have a specific need and the expertise to support it.

Whichever option you choose, ask your gateway which PCI requirements apply to your setup, and keep your website software, plugins and admin accounts secure.

Customer verification also matters. Many card payments include a check by the customer's bank, using standards such as EMV 3-D Secure. Hosted pages handle this for you. Embedded checkouts must handle it within your page, which the gateway's components usually support.

Effect on the customer experience

The checkout is where customers decide whether they trust you with their money, so small differences matter.

Hosted payment page

  • Familiar and trusted. Some customers recognise the gateway's page and feel reassured.
  • A visible jump. Leaving your site can feel abrupt, especially if the payment page looks very different from your store.
  • Fewer design options. You can usually add a logo and colours, but not change the layout.
  • Return journey. If the customer closes the page before returning, your store must still confirm the order through the webhook.

Embedded checkout

  • A consistent look. The payment step looks and feels like the rest of your store.
  • More control. You decide the layout, the order of fields and how errors are shown.
  • More to get right. Error messages, loading states and verification steps must be handled carefully on your page.
  • Mobile experience. A well-built embedded checkout can feel faster on phones, while a poorly built one can be confusing.

What matters in both

Whichever checkout you choose, a few things make the biggest difference to customers:

  1. Clear totals. The final amount, including delivery and any fees, should be visible before payment.
  2. Trust signals. Your business name, contact details and returns or cancellation terms should be easy to find.
  3. Helpful errors. When a payment fails, the customer should know why and what to do next.
  4. A reliable confirmation. The confirmation page and email should match what was ordered and paid.
  5. Payment methods your customers use. Local cards, wallets or other methods popular in your markets.

Test the full journey as a customer on a phone and a computer, in the gateway's test mode, before going live.

Unexpected costs at the payment step can put customers off, whichever checkout you choose.

When to choose a hosted payment page

A hosted payment page is usually the better choice when:

  • You want to launch quickly with limited development effort.
  • You want to keep your security responsibilities as small as possible.
  • Your store runs on a platform where the gateway's hosted page integrates easily.
  • You do not need a highly customised checkout design.
  • Your team has limited capacity to maintain a custom payment integration.

When to choose an embedded checkout

An embedded checkout is usually the better choice when:

  • A smooth, branded checkout is important to your customers and your brand.
  • You want control over the layout, fields and payment methods shown.
  • You have developers who can build, test and maintain the integration properly.
  • Your website security is well managed, with regular updates and protected admin accounts.
  • You sell on mobile heavily and want to design the payment step for small screens.

Some gateways also offer in-between options, such as a payment page that opens in a window over your site. Ask your gateway which options it supports and try each in its test environment.

You can also change later. Some stores start with a hosted page to launch quickly, then move to an embedded checkout once sales grow and the team has capacity. Keeping payment records, webhooks and order statuses well organised from the start makes that move much easier.

For more background, see our guide to how payment gateways work for online stores. If you are building on Laravel, our guide on integrating a payment gateway into a Laravel app covers the technical side, and our guide to taking payments on a travel booking website covers the extra care travel businesses need.

Summary

  • A hosted payment page sends customers to the gateway to pay; an embedded checkout keeps them on your site.
  • Hosted pages need less development and keep more security responsibility with the gateway.
  • Embedded checkouts give a smoother, branded experience but need more development and stronger site security.
  • Both usually keep card details off your server; building your own card form is best avoided.
  • Choose hosted for speed and simplicity; choose embedded for control and a smoother experience.

The right checkout type depends on your customers, your team and how much control you need. If you're deciding how to take payments on your store, you can tell us about it here.

E-commerce

Related posts

E-commerce

What it costs to build an online store

What drives the cost of building an online store, which costs continue after launch, and how to plan a realistic first version.

7 min read

Working on something?

Get in touch and tell us about it.