Field note · 2 June 2026

Guest checkout when the OS already knows the shopper

Apple Pay and Google Pay already carry a name, an address suggestion, and a credential. Putting a password wall in front of that is not “building a relationship”. It is asking someone to duplicate identity the OS just offered. In GB retail apps we still see this because CRM teams own the definition of a customer, and checkout is treated as a capture form.

Capture after pay

Let the wallet complete. Then offer an account as a way to see the order, not as a gate to pay. Email can come from the wallet payload when the shopper allows it. If they refuse, you still have a paid order and a receipt screen. Guest Path Redesign Intensive is a week of drawing that tree until legal, CRM, and native agree on the same boxes.

Fraud is not an excuse for a wall

Risk checks can run on device signals and PSP scores without a password. If your fraud vendor requires an account id, create a silent guest account on the server and do not show a login UI. Showing a login UI “for security” when the wallet already authenticated is how you manufacture Checkout Abandonment in Apps in band 01 of our map.

Where this fails

Subscriptions that need a recoverable login are a different design. Do not pretend a one-tap grocery order and a yearly membership are the same guest story. Native Checkout Recovery Studio module 4 is short on purpose; we send membership teams away with reading, not with a fake guest flow.

Map context: abandonment map.