Hosted Checkout

Hosted checkout is a way of accepting online payments in which the page that collects the shopper's payment details is built, served and secured by a payment service provider instead of the merchant. When the shopper is ready to pay, the merchant's site hands them to the provider's page; the shopper enters card or other payment details there, and is returned to the merchant once the payment has been attempted.

The model exists mainly to keep sensitive card data away from the merchant's own servers, which lowers the merchant's security burden. It is one of three common integration styles, alongside an embedded checkout, in which the provider's fields appear inside the merchant's page, and a direct integration, in which the merchant's server receives card data and passes it to the provider. Hosted checkout is offered by almost every payment gateway and payment service provider.

The merchant's server first tells the provider what is being sold: the amount, currency, an order reference and the addresses to which the shopper should be sent after success or cancellation. The provider replies with a session and a web address. The merchant redirects the shopper's browser to that address, where the provider shows the available payment methods, collects the details and runs any authentication step such as EMV 3-D Secure.

After the attempt, the provider redirects the shopper to the merchant's return page. Because a shopper can close the browser before the redirect completes, the merchant should not rely on the return alone. The provider also sends a server-to-server message, a webhook notification to the merchant's callback URL, and the order is marked paid only when that message, or a status query, confirms the result.

The main attraction is a smaller compliance footprint. A merchant that never sees, stores or transmits card numbers has far fewer obligations under the PCI DSS. Merchants using a full redirect generally qualify for the shortest self-assessment questionnaire, because the cardholder data environment sits with the provider. The merchant keeps some duties, notably protecting the page that performs the redirect, since an attacker who alters it could send shoppers to a fake payment page.

The provider also takes on the work of keeping the page current: new authentication rules, browser changes, support for wallets and local methods, and translation into many languages.

• Full redirect. The shopper leaves the merchant's domain and sees the provider's address in the browser. This gives the largest reduction in compliance scope.
• Iframe or lightbox. The provider's page is displayed in a frame inside the merchant's page, so the shopper appears to stay on the site while the fields still belong to the provider.
• Hosted fields. Only the individual input boxes are served by the provider and the merchant controls everything around them. This sits between hosted and embedded models.
• Link-based pages. A payment link opens a hosted page without the merchant having a website at all.

A hosted page for a bank-based method works in a similar way: the shopper is sent onward again, through a bank redirect, to approve the payment in their own banking app.

For a small merchant the benefits are speed and safety. Integration can take hours, there is little security work, and new payment methods appear without further development. Providers test their pages across very large volumes, so the layout is usually well optimised for phones.

The drawbacks concern control. The merchant can normally change only the logo, colours and a few fields, so the payment step may not match the rest of the site. A visible move to another domain can unsettle some shoppers and contribute to cart abandonment, although a familiar provider name can have the opposite effect. Detailed analytics on where shoppers drop out may be limited to what the provider reports. A merchant tied to one provider's hosted page also finds it harder to route payments across several acquirers, which is why larger merchants using payment orchestration tend to prefer embedded or direct integrations.

Hosted checkout is the default for new online shops, charities, event organisers and software companies that want to start taking payments quickly. E-commerce platforms commonly supply it to their merchants as standard. It is also used by large organisations for lower-volume channels, such as invoice payments, where building a custom page is not worthwhile. Subscription businesses often use a hosted page for the first payment and to collect a stored credential, then charge later renewals from their own systems without the shopper present. Some providers add a hosted customer portal on the same basis, letting customers update a card or cancel a plan on pages the merchant does not have to build.