Default method from successful history, not platform preference
Aliases: last successful tender · default tender · preselected payment
What it is
Whatever is already checked when the method list opens is the default. It should be this person’s most recent successful capture on this site, not the wallet the platform is pushing, the rail with the best take-rate, or a campaign partner. A default is a prediction, not an ad slot. This is not how unavailability is explained, and not whether switching wipes the order.
Why it happens
A default is read as “what the system thinks I should use.” At the last checkout step most people stop comparing tools and go with the check—status quo, not an accurately read preference. If the default is a promoted rail, a high-failure method gets selected again and people conclude they cannot use anything else. Last success is evidence that this card or wallet cleared for this person on this device. Last failure, expired cards, and unlinked accounts are not defaults. New payers have no history: default to none, or to a locally common method that is available on this order, and require an explicit tap—do not dress a promotion as memory.
Studying it
Set default to last success, platform promo, lowest merchant fee, or empty (must choose). Watch first-submit success and change rate.
Independent variables: default source, whether a previously failed method stays default, whether an expired card stays checked. Dependent variables: first-submit success, number of changes, abandon after default failure, noticing that default was swapped for a promo.
Do not treat “high use of the default” as success—that can mean nobody changed it. Split “unchanged and paid” from “unchanged and failed.” Promo placements can exist; do not bind them to the default radio in the test.
Where it stops holding
When policy requires one reimbursable method, that can be default if copy says policy, not memory. Shared household accounts may have someone else’s card as “last success”; remember per member or confirm each time. Subscription renewal charges against a contractual mandate, not a checkout tick. If this order’s currency differs from history, last success may be unavailable—fall back to empty, do not force-check.
Applying it
- Default to the last successful capture for this identity if it is still available on this order; otherwise leave empty and say why.
- Expired, unlinked, or repeatedly failed methods never default. Promoted wallets live in the list or an ad slot, not the pre-check.
- New users get no pre-check; a “most people use” hint is fine if the radio stays clear.
- Verify with an account whose last success is card A: A is pre-checked. Mark A expired: it is not pre-checked and the reason is visible. A fresh account must not arrive with a promo checked.
Related
- Within the group: H7.04.1 Switching methods must not wipe the order · H7.04.2 Unavailable methods need a reason · 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.11 Payment security interaction · H6.02 Third-party login · H7.08 Subscriptions and cancellation
- Search terms:
default payment method·last successful tender·status quo bias