Hosted checkout

Hosted checkout is a payment page that lives on a provider's servers rather than the merchant's own website, so customers complete a purchase or sign up for a subscription without the merchant ever directly handling their card details. The merchant sends the customer to (or embeds) a checkout experience the provider builds and maintains, then gets notified once payment succeeds.

For a subscription business, hosted checkout is one of the fastest ways to start accepting recurring payments without building and maintaining a custom payment form. Because the payment fields are rendered and processed on the provider's infrastructure, a hosted checkout offered by a subscription platform such as Recurly can also carry most of the PCI compliance burden for card data, along with built-in support for common payment methods and fraud checks, so the merchant's engineering team doesn't have to build and maintain that layer itself.

Why hosted checkout matters for subscription businesses

Every subscription business eventually has to decide how much of its checkout experience to build versus buy. Building a fully custom payment form means owning PCI scope, keeping up with card network and payment method changes, and maintaining fraud tooling, all of which take engineering time away from the product itself. Hosted checkout shifts that burden to the provider, which is especially valuable for smaller teams or companies launching in new markets quickly.

The tradeoff is control over the visual experience. A hosted page lives on a different domain (or in an iframe) than the merchant's site, which can mean less flexibility over layout and branding compared to a fully custom, self-built form. Recurly's hosted checkout products, for example, support logo and color branding and multi-language/currency localization out of the box, and its newer Checkout product also supports a custom domain and multiple configurations for different promotions or segments — though layout customization on both stays within template and configuration options rather than open CSS control. Most providers offer some level of styling and branding controls to narrow that gap, which is often enough for merchants who want to launch quickly without a large engineering investment.

How hosted checkout works

1. The customer selects a plan or adds items to a cart on the merchant's site.

2. The merchant redirects the customer to the provider's hosted checkout page, or embeds it inline, passing details like the plan, price, and customer information.

3. The customer enters payment details directly on the provider's page, which is served and secured by the provider rather than the merchant.

4. The provider processes the payment, running any fraud checks and payment method validations it supports.

5. The provider notifies the merchant of the outcome, typically through a webhook or redirect, and the merchant provisions the subscription or order.

6. The customer is returned to the merchant's site, usually to a confirmation or account page.

How to use hosted checkout effectively

Getting the most out of a hosted checkout page usually comes down to a few practical choices:

• Apply available branding options (logo, colors, fonts) so the transition from the merchant's site to the hosted page feels seamless rather than jarring.

• Configure the payment methods shown on the page to match the markets and customer base being served.

• Set up webhook or callback handling so subscription or order provisioning happens reliably as soon as payment succeeds.

• Test the full redirect and return flow on mobile as well as desktop, since hosted pages can behave differently across devices and browsers.

• Review the checkout page's currency and localization settings for any international markets being targeted.

Benefits and examples

Hosted checkout offers several practical advantages over building a payment form from scratch:

• Reduced PCI compliance scope. Because card data is entered and processed on the provider's page, the merchant typically qualifies for a simpler PCI self-assessment.

• Faster time to launch. Teams can start accepting payments without building, testing, and maintaining their own payment form.

• Built-in support for new payment methods. Providers can add support for additional payment methods or card networks without the merchant needing to update its own checkout code.

• Lower ongoing maintenance. Security patches, fraud tooling updates, and compliance changes are handled by the provider rather than the merchant's engineering team.

As an example, imagine a subscription business launching in a new region where local debit schemes are common. Rather than building support for those payment methods into a custom checkout form, the business points customers to its hosted checkout page, where the provider has already added the new methods. Customers in that region see the relevant payment options automatically, without the merchant shipping any new checkout code.

Frequently asked questions

Is hosted checkout secure? Yes, when provided by a reputable payment or subscription platform, since card data is entered and processed on the provider's PCI-compliant infrastructure rather than the merchant's own servers.

Does hosted checkout hurt conversion because customers leave the merchant's site? It can introduce a visual break for a fully redirect-based flow, though embedded (iframe) hosted checkout options reduce that effect by keeping customers on the merchant's page.

Can hosted checkout be customized to match a brand? Most hosted checkout products support some level of branding, such as logo, color, and font customization, though the level of control is generally less than a fully custom-built form.

What is the difference between hosted checkout and a custom checkout integration? Hosted checkout is built and maintained by the provider and lives on the provider's page or domain. A custom integration means the merchant builds its own payment form using the provider's APIs, which gives full control over design but puts more PCI compliance and maintenance responsibility on the merchant.