Blog

Payment UX: where the money actually leaks

Everyone optimizes the button color; the money leaks in the plumbing around it — 3DS redirects, error messages written by gateways, and the missing wallet button. A tour of the last thirty seconds of your funnel.

By the time a customer reaches your payment form, they have decided to give you money. Everything that happens next is you either accepting it gracefully or fumbling it. Yet payment UX gets a fraction of the attention lavished on hero sections — partly because the failures are invisible: analytics files them under “abandonment”, which sounds like the customer's fault. Usually it is the plumbing's.

Having built on both hosted checkouts and custom forms, we find the leaks cluster in the same five places. In rough order of money recovered per hour of work:

1. The wallet buttons you don't show

Apple Pay and Google Pay collapse the entire form — card number, address, the typing, the doubt — into one biometric gesture. On mobile they routinely outconvert card forms by double digits, and mobile is where typing sixteen digits hurts most. If you support wallets, show them first, above the card form, not as a footnote under it. If you don't support them, that is probably your single largest recoverable leak, at an implementation cost modern PSPs have made embarrassingly small.

2. The 3DS redirect black hole

Strong Customer Authentication sends European customers on a round trip to their bank — an ugly interstitial, sometimes an app switch, occasionally a minute of limbo. You cannot skip it; you can stop losing people around it. Before: one line of copy — “your bank may ask you to confirm” — turns a scary redirect into an expected step. After: the return leg must be bulletproof, because customers come back with stale sessions, double-tapped confirmations and back-button archaeology. Test the return with an expired session. Twice. That is precisely where we have seen orders exist in the PSP and not in the shop.

3. Error messages written by a gateway, for a gateway

“Transaction declined (code 05).” The customer reads: something is wrong with us — and leaves. Every decline needs a human translation and a next step: declined → “try another card or a wallet”; insufficient funds → never say that aloud, say “this card didn't go through”; expired → point at the expiry field. And preserve the form state: making someone retype everything after a decline is how one failed payment becomes zero payments instead of a retry. Recovery UX is the cheapest revenue in e-commerce — these customers are still at the till with the wallet open.

4. Webhooks that lie about reality

The order's source of truth is the webhook, not the redirect — customers close tabs between paying and returning. That makes the webhook handler revenue infrastructure: idempotent, because payment events arrive twice on bad days and a duplicate must not mint a second order; and reconciled, because a silently failed webhook leaves a paid customer with no product — the most expensive bug there is, paid in refunds and trust. Ours are idempotent by construction, and we still glance at the reconciliation on Mondays. Paranoia is a feature here.

5. Hosted vs custom: decide with math, not pride

For our own store we chose the PSP's hosted checkout — and we design interfaces for a living, so the pride argument was available. The math won: the hosted page ships with wallets, 3DS choreography, validation in forty languages and a compliance team we don't employ. A custom form buys brand continuity and bills you for everything above, forever. Honest rule: custom forms are for teams with payment engineers on staff; everyone else is trading conversion for cosmetics. Spend the freed week on leaks 1–4 — customers remember whether paying felt effortless, not whose logo the form wore.

Walk your own payment step this week with a card that declines (your PSP's test cards work fine for this). Watch what the customer watches. The leaks announce themselves — they were just filed under “abandonment”, where nobody looks.