Switching methods must not wipe the order

What it is

Changing tender in checkout (card to wallet, cash-on-delivery to instant pay) must leave address, line items, already-chosen offers, and notes—the order—intact. Loss is switching that restarts checkout, empties the cart, releases a coupon, or wipes fields other than card data. PAN must not travel between methods; that is not loss. Throwing away the recipient and the goods is.

Why it happens

Mentally, method is “how to pay”; the order is “what and where.” Technically they are often separate sessions: each rail wants its own place, lock, and redirect. If switch means cancel-and-recreate, the backend is simpler and the frontend is a full refresh. People hold one copy of what they typed in working memory; rebuild cost is high, so switch feels like punishment and they stick with the default even when it fails more. A coupon released on cancel can be taken or expire; the cost jumps from inconvenience to loss.

Studying it

Have people complete address and a coupon, then change method at pay. Compare in-place switch with restarting checkout.

Independent variables: whether switch rebuilds the order, whether coupon and stock locks keep, whether non-card fields remain, full-page refresh. Dependent variables: field completeness after switch, abandon, switching back, complaints about a lost coupon.

Fake lab coupons will not show “sniped”; use expiring or limited ones. Do not lump loss after an issuer redirect-return with loss from an on-page radio—the first is rail constraint, the second is the merchant state machine.

Where it stops holding

After a jump into a bank or wallet app, the rail may drop its session; the merchant should still keep the order draft. Some rails require the method to be locked before submit, so switch must void the payment intent—the intent, not the address. Changing one leg of split tender follows split rules; it is not a whole-order switch. An expired guest session has no draft to keep.

Applying it

• Split order draft from payment intent: switching voids only the unfinished intent; lines, address, coupon, and notes stay.
• Switch on the same page; do not eject to the cart. If the coupon must be re-locked, check it still applies; if not, ask for another coupon rather than dropping it silently.
• On a failed return from a rail, land on the same checkout summary, not home.
• Verify by filling checkout and rotating through three methods: goods, address, coupon remain. Then simulate a rail failure return and confirm the cart is not empty.

Related

• Within the group: H7.04.2 Unavailable methods need a reason · H7.04.3 Default method from successful history, not platform preference · H7.04.4 Method surcharges belong at selection, not at settle · H7.04.5 Filter methods by region and currency before showing them · H7.04.6 Split tender needs amounts people can audit
• Adjacent: H7.02 Checkout flow · H7.06 Payment failure · H7.03 Price transparency
• Search terms: payment method switch · checkout state · order draft