Every product has exactly one screen where the goodwill runs out. For most of them, it's the payment screen. Everything before it is a promise, and everything after it is a receipt, but the moment someone is asked to hand over money is the moment they start looking for reasons not to.
I have spent most of the last decade somewhere near that moment. Payment systems at Uber, checkout work for clients at Strakzat, and a long stretch of design system work that mostly existed so that flows like these could stay consistent while everything around them changed. What follows is the part that generalises: not the specific patterns, which age badly, but the way of thinking about them, which does not.
Drop-off is a signal, not a failure
The first useful reframe is that abandonment is information. A payment flow with zero drop-off would be suspicious, because it would mean nobody was reconsidering, and people should reconsider when they spend money.
What matters is where they leave. Someone who abandons at the basket has a pricing problem. Someone who abandons at the payment method has a trust problem or a coverage problem. Someone who abandons at the confirmation screen has an anxiety problem, usually because the screen has not told them what happens next.
Those are three different products with three different fixes, and a single funnel number flattens them into one. The first thing I do on any checkout project is insist that drop-off is measured per step, per method, and per device, because the aggregate hides everything worth knowing.
Three numbers, not one
The funnel most teams look at is a single conversion rate, and it moves for reasons nobody can name. The three that actually explain it are the reach rate (of everyone who intended to pay, how many got as far as a payment method), the attempt rate (of those, how many pressed the button), and the success rate (of those attempts, how many the issuer approved).
They fail for entirely unrelated reasons. Reach is a product problem: the price was a surprise, the account wall arrived too early, the guest option was hidden. Attempt is a trust and coverage problem. Success is mostly outside your control and is where the work is about handling the answer rather than changing it.
Reporting them separately is the difference between "checkout is down two points" and "German attempt rate fell when we reordered the methods". I have never regretted the extra dashboard rows.
The failure you cannot see
Card declines are the clearest example. In most flows a decline is presented as a generic error, because the issuer's reason codes are famously unhelpful and the temptation is to give up on them. The result is that a customer whose card was declined for an expired date, a customer with insufficient funds, and a customer who tripped a fraud rule all get the same red box.
Two of those three could have finished if you had told them what to do. The third could not, and telling them anything specific would be handing information to whoever is running the card. That tension is real, and the resolution is not to write off the whole category. It is to map the reason codes you are allowed to act on, write honest copy for those, and keep a generic message for the rest.
Retries are a product decision
When a payment fails for a soft reason, something has to decide whether to try again, when, and how many times. That schedule is usually set by whoever wrote the billing job, and it is usually invisible in the interface.
It should not be. A subscription that retries silently for two weeks and then cancels has spent two weeks not telling someone their card expired, and the first thing they hear about it is that their account is gone. The same retry schedule with one honest email on the first failure converts far better, and the change is entirely on the design side of the line.
Coverage beats elegance
There is a version of payment design that is mostly about aesthetics: the card form with the animated flip, the perfectly kerned input mask, the confetti on success. It is fun to build, it demos beautifully in a design review, and it moves almost nothing.
What moves the numbers is coverage. Whether the method someone already uses is there, at the top, without hunting. In the Netherlands that means iDEAL, which is not a nice-to-have but the default way most people pay online, and a Dutch checkout that buries it under card is quietly telling a large share of its customers that it was not built for them. In Germany it is direct debit and invoice. In much of Asia it is wallets that have very little in common with the European model.
This is why payment design does not travel well. A flow that converts beautifully in one market can be actively hostile in another, and the mistake is almost always the same: treating the payment method list as a UI problem rather than a market research problem.
Ordering is a design decision with a price tag
Once you have the right methods, the order matters more than the styling. People pick from the top. A method placed fourth is, functionally, a method that most people will not see.
The honest way to order the list is by what the local customer base actually uses, refreshed on real data rather than on the assumption that made sense at launch. The dishonest way, which is common, is to order by what is cheapest for the business. That works until someone notices, and the trust cost outlasts the interchange saving.
The saved card is a promise
Storing a card is the highest-leverage thing a checkout can do and the easiest one to do badly. A returning customer with a working saved card is close to a one-tap purchase; the same customer with a saved card that has silently expired is worse off than a stranger, because the flow assumes it will work and only discovers otherwise at the end.
Two things fix most of it. Check the expiry against the calendar before the flow starts and say something early. And let the card be replaced without deleting it first, since a delete-then-add flow leaves a window where the account has no payment method at all, which is exactly when the subscription renewal fires.
Trust is built before the payment screen
By the time someone reaches checkout, most of the trust decision has already happened. The price shown on the product page, whether it included tax, whether the delivery cost appeared at the last moment, whether the site felt like it belonged to a real company. Checkout inherits all of it.
The single largest conversion improvement I have been part of was not a checkout change at all. It was moving the total cost, including delivery, up to the point where someone first considers the purchase. The checkout numbers improved because the people arriving at checkout had already made peace with the number.
That is the uncomfortable version of the lesson: a lot of checkout optimisation is repair work for a promise that was broken earlier in the flow.
Regulation is a design constraint, not a lawyer's problem
In Europe, strong customer authentication changed payment design more than any framework or fashion did. Suddenly the flow could leave your product entirely, go to a bank app, and come back in a state you did not fully control. Every assumption about a linear checkout stopped holding.
Designers who treated that as compliance overhead built flows that felt like they were apologising. The teams that did well treated the redirect as a real part of the experience: telling people it was coming, keeping the context visible when they returned, handling the case where they never returned at all.
The same is true of the quieter obligations. Storing a card requires a mandate that a person can actually understand. Subscriptions require a cancellation path that is not hidden. These read as legal requirements, but they are all describing something a decent designer would want anyway, which is that the person knows what they agreed to.
Authentication is not one experience
Strong customer authentication does not feel like one thing to a customer, because it is not. A banking app that pushes a notification is nearly seamless. A bank that sends an SMS code needs the customer to leave the browser and come back. A bank that opens its own web page inside a redirect can look, to someone who has been warned about phishing all year, exactly like a scam.
You cannot fix the third one, but you can prepare for it. Naming the bank before the redirect ("your bank will ask you to confirm") turns an unexplained jump into an expected one, and that single line is worth more than any amount of polish on the screen it leaves.
The state you forget is the one that ships
Payment flows have more states than almost anything else in a product, and the ones that get designed are the happy ones. Here is the list I keep, because I have shipped bugs in every one of them:
- The payment is pending and may resolve minutes later, so success cannot be assumed and failure cannot be declared.
- The customer closed the tab during the redirect and comes back tomorrow through a bookmark.
- The card was authorised but capture failed, so the money is held but the order does not exist.
- The customer paid twice because the button did not disable and the network was slow.
- The refund is partial, and the interface only ever imagined full ones.
- The saved card expired between the last order and this one.
None of these are edge cases in the sense of being rare. At any real volume they happen constantly. They are edge cases only in the sense that they are usually left to whoever is on call.
Design the reconciliation, not just the screen
The deeper version of this is that a payment is not an event, it is a small distributed system with a customer attached. The interface is making a claim about the state of that system, and the claim is often wrong for a few seconds and occasionally wrong for a few days.
The most useful thing a designer can do here is refuse to let the interface overstate its confidence. "Payment received" and "we have asked your bank" are different sentences, and a flow that says the first when it means the second will eventually have to send an email taking it back.
Errors are copy, and copy is a design surface
The default error in most checkouts is a sentence written by whoever wired up the request. "Something went wrong. Please try again." It is not wrong, exactly, but it is a shrug in a moment where someone has their card in their hand.
A better one answers three things: what happened, whether their money moved, and what to do now. The middle one is the one people actually want, and it is the one generic copy never covers. "We could not reach your bank. Nothing has been charged. Try again, or pick another method" is the same failure, described by someone who understands what the person on the other side is afraid of.
This is worth writing before the flow is built rather than after. Error copy written at the end gets written against the code; error copy written alongside the flow changes the flow, because you discover which failures you cannot describe honestly and go back and make them describable.
What I would tell someone starting on this
Learn the money. Not the accounting, but the shape of it: authorisation, capture, settlement, chargeback, and roughly how long each takes. You cannot design honest states for a system whose states you do not know, and every good payment designer I have worked with could explain the whole chain on a whiteboard.
Read the decline codes and the support tickets before you read the analytics. The analytics tell you that people left. The tickets tell you why, in their own words, and the phrasing they use is usually the phrasing your interface should have used in the first place.
Then, once you understand it, spend your effort on the boring parts. The clear total. The method people already use, first in the list. The error that says what to do next. The confirmation that says what happens now. None of it makes a portfolio look exciting, and all of it is what decides whether someone finishes.