Payments in in-app browsers

Checkout is the worst place to discover that the container your page is running in cannot open a window.

6 August 2026 · PAD team

Apple Pay

Web Apple Pay needs merchant validation and a native sheet. Most embedded WebViews do not support it, so the button either does not render or does nothing when pressed. There is no error to catch reliably.

3-D Secure

Bank confirmation steps typically open in a new window or redirect through several domains. In-app browsers handle both poorly: the window is ignored, or the visitor ends up on a page with no way back.

This is the most common cause of "payment started but never completed" in traffic from social ads.

Redirect chains

Any checkout that bounces through a payment provider and back is fragile here. Each hop is a chance for the container to lose the session, and the cookie isolation described earlier makes recovery harder.

What survives

• Card fields rendered inline, with no external sheet
• Providers that keep the whole flow on one domain
• Wallets that fall back to a card form when the native path is unavailable

The reliable answer

Move the visitor into the real browser before checkout starts. It costs one interstitial and removes an entire class of failures, including the ones you cannot instrument.

For app products specifically, the better answer is usually to skip web checkout entirely and let the purchase happen inside the app after install, which is also what the stores require in most categories.