Fintech & Trust-Critical UX
Somebody is sending a deposit on a flat. It is 1,800 pounds, to an account they have never paid before, from a phone on a train.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full Fintech & Trust-Critical UX course on DesignPath
They read the confirmation screen four times. They compare the account number against an email, character by character, and they still hesitate before the last tap.
Nobody reads a checkout screen that way. This is the one domain where users want the extra step, and where removing it is the mistake.
What This Domain Changes
Two facts drive the whole module.
The mistake does not come back.UK Finance put authorized push payment losses in the UK at 450.7 million pounds in 2024, down 2% on the year before. Almost all of that money was sent deliberately, by the account holder, through an interface that did exactly what it was told.
Anxiety is the default state.Handing over money triggers a caution people never bring to a social app. They arrive slower, read more, and abandon at the first thing that looks wrong. A screen that hides a fee until the receipt does more damage here than a slow load.
So the patterns hold and their weight changes. Modals & Dialogs owns the confirmation dialog; here it is the last thing standing between somebody and a permanent loss. Error Messages owns wording; here the message arrives after the money has gone.
Anatomy of a Payment
Almost every screen in a financial product is describing one transaction to one person. Doing that accurately requires knowing what a transaction is made of.
The vocabulary below is the one your engineers and your compliance team already use. Learning it is the difference between a design review about wording and one about what is true.
The Six Parts
The payer and the payee.Two parties, each identified differently depending on the rails. A UK bank transfer identifies the payee by a six-digit sort code and an eight-digit account number. Neither contains a name, and that gap is where misdirected payments live.
The amount and the currency.Always together. An amount without a currency is the ambiguity that costs the most on a multi-currency account.
The rails.The network carrying it: a card scheme, a bank transfer system like Faster Payments or SEPA, a direct debit. The rails decide the speed, the cost, the cut-off times and whether the payment can be recalled at all.
The reference.What the payee will use to recognize it. Invisible in consumer products and the entire point in business ones.
The authorization.The moment the payer approves it, which is when a card payment reserves the funds.
The fees and the rate.Charged by whom, deducted from which side, and at what exchange rate.
The Five States
A payment is not on or off. It moves through states, and the screen has to name the one it is in.
Initiated.The person has submitted it and nothing has left.
Authorized.Approved and reserved, but not moved. This is where a card payment sits when a merchant "holds" money, and it is why a balance can drop before anything is spent.
Pending or in flight.Sent, not yet arrived. Whether it can still be stopped depends entirely on the rails.
Settled or posted.The money is in the other account and the transaction is final.
Reversed or disputed.Returned, charged back, or under investigation. This state has its own timeline, usually weeks.
Why the States Are a Design Problem
The gap between authorized and settled is the source of most confusion in consumer finance.
Somebody sees a coffee leave their balance on Friday and appear in the statement on Tuesday, in a different position in the list. Occasionally the amount differs, because the final figure was not fixed at authorization. Every one of those is normal, and almost no interface explains any of it.
So show the state as a word rather than a color, and say what happens next with a date. "Pending, expected to clear Tuesday" answers the question that produces the support call.
The One Thing That Decides Everything Else
Whether the payment can be recalled is a property of the rails, not of your product.
A card payment can usually be disputed. A completed bank transfer usually cannot be pulled back, which is why the confirmation screen carries so much weight in this domain. Find out which of the two you are designing for before you write a single word of the confirmation, because the honest sentence differs completely.
Pro tip: Ask your engineers to list the states a transaction can be in, in their own words. Any state on their list with no screen in your design is a state your users will meet with no explanation.



