Unavailable methods need a reason

What it is

A method in the list cannot be used—greyed out, error on tap, or “not supported” only after the tap. Give a reason means stating the constraint in the same glance: amount over limit, goods type barred, region unsupported, rail down, risk check failed. Grey without copy makes people blame their card, tap again, or leave for another shop. This is not which method should be default, and not when a surcharge appears.

Why it happens

Methods are tools; unavailability is a constraint. Unstated constraints force elimination: network, account, or merchant refusal. Wrong attribution drives wrong action—swap cards, resubmit, call the bank—when the real block is cash-on-delivery not allowed on this order. A maintenance window labeled “system error” reads as whole-order failure. Reasons must be actionable: name substitutes if another method works; name the cap if amount can drop; give an expected return if waiting is the only move—not a fake “please retry.”

Studying it

Build the same list as grey-no-copy, reason on hover, reason always in the row, plus one method that explains only in a modal after tap.

Independent variables: when the reason appears, tap-to-reveal vs always on, whether copy names a substitute. Dependent variables: dead clicks, successful switch, leave because “I can’t pay,” wrongly editing card or address.

Lab participants read grey type; live checkout skip grey rows, so recruit people who need the blocked method (cash-only COD users). Do not mix filtered-out methods (not rendered) with rendered-but-disabled: the first is list composition, the second is reason copy.

Where it stops holding

Over-specific risk refusals become an attack surface; “this order cannot use this method” plus a support ticket is enough. Methods impossible in the region should be filtered, not a long grey list. Legal bans should read as a compliance limit, not a technical fault. Temporary maintenance and permanent unavailability must be told apart, or people wait for nothing.

Applying it

• When a disabled method is still shown, put a human sentence in the row with a next action; do not rely on grey and an icon.
• Maintenance gets a window; limits get a number; goods restrictions get “use X for this category.”
• Taps on disabled rows should not silence; move the same sentence to focus so the tap is acknowledged.
• Verify with someone who can only use the blocked method: within ten seconds they should say why and what to use instead. Failure: “the card is broken” or repeated submit.

Related

• Within the group: H7.04.1 Switching methods must not wipe the order · 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.06 Payment failure · H3.02 Three elements of error messages · H7.13 Payment failure and unknown state
• Search terms: unavailable payment method · disabled tender · payment restriction