Designing a payments flow people finish

A payment flow is the one screen sequence where hesitation is expensive and recoverable mistakes are not. Everywhere else in a product, someone who gets confused tries again later. Here they close the tab.

Most advice about it is about persuasion — trust badges, urgency, fewer fields. The more useful framing is narrower: a payment flow is a form someone is filling in while slightly anxious, often on a phone, often with a physical card in their other hand. Design for that person and most of the rest follows.

The total, before anything is typed

The single most damaging thing a checkout does is change the number after someone has committed to it. Shipping added at step three, a service fee at the summary, a currency conversion that appears at the end.

The cost is not the money. It is that every figure shown earlier is now retroactively untrustworthy, and the person has to re-examine a decision they thought they had made. Anyone who has been surprised once reads the rest of the flow looking for the next surprise instead of finishing it.

A number that changes late does not just cost you that number. It costs you the credibility of every number you showed before it.

If a charge genuinely cannot be known upfront — shipping that depends on an address, tax that depends on a region — say so where the total first appears, with the range. "From £4.50, confirmed at the next step" is a complete answer. A total that quietly grows is not.

Card entry is a physical act

Someone entering card details is copying sixteen digits from an object into a screen, usually one-handed. Almost every common defect in card forms comes from forgetting that:

• The wrong keyboard. A card number field that opens a full alphabetic keyboard on a phone is a small, constant tax. Numeric input modes exist and cost one attribute.
• No grouping. Cards are printed in groups of four. A field that formats as the person types matches what their eye is doing on the card; one long undelimited string does not.
• Rejecting spaces. People paste card numbers with spaces in them. Strip the spaces yourself instead of returning an error about them.
• Expiry as two dropdowns. The card shows 09/28. Two select menus are three interactions where one short text field is one.
• Validating too early. An error appearing on the fourth digit of a sixteen-digit number is noise. Validate the field when the person leaves it, not while they are still in it.
• Clearing the form on error. Forcing someone to retype a card because one field was wrong is the most reliable way to lose them at the last step.

None of this is clever. All of it is the difference between a flow that feels considered and one that feels like a database form someone styled.

Designing for the interruption

Card payments in much of the world involve a verification step handed off to the bank — an app notification, a code, a redirect to a page the product did not design and cannot control.

This is the least designed part of most checkouts and the most likely place to lose someone, because the product's careful interface hands over to something that looks nothing like it. Two things help, and both are about the handoff rather than the bank's page:

1. 01Say it is coming. A line before the redirect — that the bank will ask to confirm, and that the order is not lost — turns an alarming jump into an expected step.
2. 02Survive the return. Coming back must land on a state that makes sense, including when the verification failed or timed out. A person returning to an empty basket assumes the money left and the order did not exist.

What a decline actually needs to say

Payments fail routinely and for boring reasons: a typo, an expired card, a bank's own risk rules. The interface usually reports all of them identically, with something like "Payment failed. Please try again."

That message tells the person nothing about what to do differently, so their options are to repeat the exact same action or leave. Most leave. The useful version separates what you know from what you do not:

• Something you can see is wrong — an invalid number, a past expiry date — should be named precisely, with the entered details preserved.
• Something the bank refused cannot be explained by you, and pretending otherwise is worse. Say that the bank declined it, that it is often resolved by trying another card or contacting them, and keep everything else in the order intact.
• Something on your side failed should say so plainly and promise the money was not taken, which is the actual question in the person's head.

The last one matters more than its frequency suggests. In an ambiguous failure, the fear is not that the payment did not work — it is that it worked twice.

Where this was explored

That limit is worth being explicit about in an article like this, because payment-flow advice is unusually full of statistics whose source, sample and date have gone missing somewhere in the retelling. The arguments above stand on mechanism — what the person is physically doing, and what they are afraid of — which you can check against your own flow without taking anyone's number on trust.

There is more on how this site labels concept work, and what each label does and does not claim, in Concept, published, and client work.

What to check in your own flow

1. 01Complete it yourself on a phone, on a slow connection, with a real card.
2. 02Check the total shown first against the total charged last. If they differ, fix that before anything else here.
3. 03Enter a wrong card number deliberately. Read the error as though you did not build it.
4. 04Abandon it halfway, come back, and see what state you land in.
5. 05Force the bank verification step and watch the return, including the failure path.
6. 06Try it with a password manager filling the fields, which is how a large share of people will do it.

If you are building a flow where money changes hands and want a second read on it, tell us what you are building.