Learn / Fixes
How to test checkout in an in-app browser
When an assistant sends a shopper to your checkout, the purchase often completes inside an in-app browser rather than in the shopper’s usual browser. That environment is narrow, cold, and restricted in ways ordinary mobile testing does not reproduce, so a checkout that passes every device test you run can still fail the sessions an assistant actually sends you.
When an assistant sends a shopper to your checkout, the purchase often completes inside an in-app browser rather than in the shopper’s usual one. Shopify’s help centre describes ChatGPT users completing "their purchase on your online store checkout in a ChatGPT in-app browser, or in a new tab when customers use ChatGPT web".
That environment is not the one your device testing covers, and it is the one that now carries assistant referred sales. See can ChatGPT buy from your store.
What makes it different
The narrow viewport is the least interesting difference. What actually breaks checkouts is everything else.
- No history. No cookies, no saved address, no signed in state, no previously dismissed anything.
- Restricted storage. Flows that stash state client side across a redirect can lose it.
- Redirect handling. A payment step that opens a new context may not return where you expect.
- Limited controls. No extensions, sometimes no easy way back, and gestures handled differently.
How to reproduce it
- Use a device you have never used for your store, so nothing is warm.
- Open your product URL from inside a messaging or social app, which puts you in that app’s embedded browser rather than your default one.
- Complete the journey to the payment step: choose a variant, add to cart, proceed, and stop before submitting a payment.
- Note every place you had to do something an agent could not: dismiss an overlay, accept a banner, choose a region, create an account.
If you cannot arrange the device, a private window at a narrow width with storage restricted reproduces most of it.
What to fix first
Anything that loses state across a redirect, because that failure produces an error rather than an obstacle and looks like a broken store. Then anything requiring an account, then overlays. See how to offer guest checkout for agents and how to stop popups blocking agent checkout.
Put it in the routine
This test belongs with every checkout, theme and payment app change rather than on a calendar, because those are the changes that break it. The related stall pages are checkout error and payment step unreachable.
Questions
How is this different from testing on a phone?
Your phone browser has your cookies, your saved details, your extensions and your history. An in-app browser has none of that and may restrict storage and redirects as well. The viewport is the least important difference.
How do I actually reproduce one?
Open your checkout from inside a messaging or social app on a device you have not used for your store, which puts you in that app’s embedded browser cold. Failing that, a private window at a narrow width with storage restricted gets you most of the way.
What usually breaks?
Flows that depend on a redirect returning to state you kept client side, anything assuming a saved session, third party payment steps that open a new context, and overlays that are dismissible only by a gesture the embedded browser handles differently.