Filter methods by region and currency before showing them

What it is

Which methods can pay this order depends on ship-to or bill-to, settlement currency, and rail coverage. Filter early means dropping methods that cannot work before the list opens, leaving only options that are true for this order. It is not “grey it and explain”—that is copy after display—it is not putting doomed methods in the choice set so people select and then get refused.

Why it happens

Region and currency are hard constraints: a wallet serves one country, a card scheme will not take a currency, COD covers some postcodes. People arrive with “what I always use,” tap it, get refused, and blame the card or the network. Long lists raise search cost; irrelevant options also imply they should work. Filter after address or currency is known and before the list; recompute when address changes. Guessing region from IP too early filters travelers wrong; filtering only at submit lets people finish typing and then fail.

Studying it

With one account, change ship-to country or currency. Compare a world list that errors at submit, a short list filtered by address, and an IP pre-filter that disagrees with address.

Independent variables: filter basis (IP / ship-to / bill-to / currency), when it runs, whether dropped methods still appear as “available elsewhere.” Dependent variables: issuer refusal after select, list update after address change, leave when a familiar method is missing.

One-country lab samples will not show filter differences. Do not treat “fewer methods” as better by default—over-filtering hides still-valid schemes. Measure “should have been available but wasn’t.”

Where it stops holding

Digital goods have no ship-to; use bill-to or account country, and allow that country to be edited before pay. If a shop lets people switch display currency, filter on capture currency, not browse currency. Enterprise accounts may have contracted rails; do not reuse the consumer table. Sanctions and export controls are compliance filters; failure copy is compliance, not “this card is temporarily unsupported.”

Applying it

• Build the list after address and currency are known; before that, ask for ship/bill-to rather than showing a world menu.
• Recompute on address or currency change; if the selected method dies, clear it and say the region or currency changed.
• Familiar-but-impossible methods do not belong in the chooser; coverage education lives in help, not a long disabled list.
• Verify the same account through domestic address, foreign address, and a currency change; record list diffs. Then use a test identity for a filtered-out rail and confirm it never appears and does not fail only at submit.

Related

• Within the group: H7.04.1 Switching methods must not wipe the order · 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.6 Split tender needs amounts people can audit
• Adjacent: S3.06 Regional legal requirements on the interface · H7.02 Checkout flow · H7.06 Payment failure
• Search terms: geo payment methods · currency tender filter · available payment methods