Use case summary
The hosted checkout is responsive by default and adapts to the customer it opens in front of: light or dark to match their device, language from their browser, payment methods for their detected country, and wallets where the device supports them. All from one configuration you maintain. Result: the same checkout performs on a phone and on a laptop.
- Payment Manager
Why the device decides more than the design
Checkout is usually designed on a laptop, by people on laptops, and reviewed on the same screens. The customer is often somewhere else: on a phone, one-handed, on mobile data, in a dark room with their screen inverted.
What breaks is rarely the layout. It is the card form, which takes sixteen digits and an expiry date typed on a small keyboard. It is a page in the wrong language because nobody checked the browser locale. It is a method list built for one market shown to someone in another. It is a payment state the customer cannot read, so they close the tab rather than retry.
Each of those is small, and each arrives at the last screen before the money. There is no later step where a customer who gave up can be recovered.
How to set up a checkout that works on any device
Everything below is configured once per checkout, in the Layout and Branding tabs.
- 1
Start from the hosted checkout
The hosted checkout is responsive by default across desktop, tablet, and mobile. Pick your integration type now, since it decides where the rest applies: hosted page, embedded flow, payment links and QR, or your own frontend on the API. Methods, routing, and recovery stay consistent across all four.
- 2
Set the theme to follow the device
In Branding, set Mode to Auto so the checkout matches each customer's light or dark setting. Choose light-only or dark-only instead if your brand requires a fixed appearance.
- 3
Choose which languages to offer
Language is selected automatically from the customer's browser. In Layout, use Limited languages to exclude any market you do not support, so nobody lands on a page in a language your team cannot answer questions in.
- 4
Enable the methods each market uses
Country is detected when the checkout opens, and the method list follows it. Enable the methods you want available per market from 800+ methods across 650+ connected providers, and put wallets near the top so customers can confirm with their device instead of typing a card.
- 5
Turn on saved methods and hide expired cards
In Layout, switch on Saved methods so returning customers see their own cards, and Hide expired cards so a card that can no longer work never becomes a decline.
- 6
Hide the header if you are embedding
Switch on Hide if embedded when the checkout runs in an iFrame, so it sits inside your own flow without a duplicated header.
- 7
Check it in preview, then publish
Review styling, layout, fonts, colors, and the button label in preview mode before publishing. Changes can be rolled back to the previous version or reset to default at any point.
What you get
The checkout fits the customer in front of it, without a separate build per device.
Fewer drop-offs at the final step
Wallets and saved methods remove the card form, which is the slowest part of a mobile checkout and the place where a customer who had already decided to buy gives up.
A page that reads as intended on any screen
Responsive layout, theme matching the device, language matching the browser, and methods matching the country mean customers are not asked to adapt to a page built for someone else's context.
One configuration to maintain
Device, theme, language, and country are handled by the same checkout, so improving it improves every context at once rather than requiring a mobile variant to keep in sync.
Changes without a release
Layout, branding, and method display are edited in the builder, previewed, and published by your payment team, which keeps checkout improvements out of the front-end queue.
Mobile brings 70% of the traffic and converts at well under half the rate
Contentsquare's 2026 Digital Experience Benchmark analyzed 99 billion web and app sessions across 6,500 sites in nine industries. Mobile accounted for 69.9% of all traffic, while desktop converted 74% higher: 3.4% against 2% on mobile, and 3.7% against 2% in retail specifically. Not all of that gap is the checkout, since mobile sessions are often shorter and more exploratory. But because so much traffic arrives on a phone, the mobile payment experience drives most of the revenue.