Field note · 4 March 2026

Drop-off after the payment sheet, not before it

Most dashboards still draw a funnel that ends at “checkout started”. In an app, that event is often fired when the shopper taps a button that merely presents an OS sheet. From that moment the shopper is negotiating with Apple, Google, or a card form your WebView barely owns. If they leave, your tool calls it abandonment at the previous step because nothing else was named.

Three events that change the conversation

We ask cohorts to log sheet presented, token received, and order confirmed as separate events, with OS and wallet type attached. Teams resist because it looks like “more analytics work”. Then they discover that 70% of what they called cart abandonment happened after presentation. That number is not a benchmark; it is a pattern we see in traces from GB storefronts that already have a mature web checkout.

Silent failure is not a bounce

A wallet can close without an error payload you recognise. Merchant identifiers expire. The shopper can dismiss the sheet because Face ID failed twice. If your UI returns to the cart with the same primary button and no explanation, you trained them to tap again or to leave. Payment Sheet Friction Lab is built around that empty return, not around button colour.

What not to do

Do not fire a marketing email titled as if they never intended to pay. Do not collapse all sheet dismissals into one “user cancelled” bucket if your PSP also cancels. Split dismissals you can see (explicit close) from failures you cannot (no callback). The second group is where engineering time belongs.

Further reading in class: module 2 of Native Checkout Recovery Studio. The wider map is on Checkout Abandonment in Apps.