Customer journeys in payments: the moments that decide trust

A customer journey in payments is not a single flow, it is a set of moments, and the moments that matter are the ones where the customer is anxious. The first is onboarding, when the customer gives their identity documents and waits to be approved. The second is the first payment, when the customer is unsure whether the money will arrive. The third is the first exception, when a payment is delayed or blocked and the customer needs to know why. The fourth is the first dispute, when the customer has lost money and needs it back. A product that handles the routine well but fails at these four moments will lose the customer. Onboarding is a conversion problem and a compliance problem at the same time. The customer wants to be approved in minutes, and the bank must perform know your customer checks, screen against sanctions lists, and assess the risk. The journey must therefore be designed to collect the minimum information needed for the risk level, to give the customer a clear status at every step, and to explain a rejection in plain language. A journey that asks for a document the customer does not have, or that goes silent for three days, will lose the customer to a competitor. The first payment is a trust test. The customer needs to know the payment was sent, the amount, the expected arrival time, and the reference the beneficiary will see. The status must be updated as the payment moves, and the customer must be able to see the same status the operations team sees. A status that says only pending, with no explanation and no expected time, is not a status, it is a shrug. The requirements must state the status vocabulary, the update triggers, and the maximum time between updates. The first exception is where trust is won or lost. When a payment is blocked by screening, the customer needs to know it was blocked, why, what the bank needs from them, and how long it will take. When a payment is returned, the customer needs to know the reason code in plain language, not just AC04, and needs to know whether the money is back in their account. The exception journey must be designed with the same care as the happy path, because the customer will remember the exception longer than they remember the hundred payments that worked. The dispute journey is the hardest, because the customer has lost money. For a card payment the dispute is a chargeback, and the customer needs to know the reason code, the evidence required, and the timeline, which is typically 30 to 45 days for the merchant to respond. For an authorised push payment fraud case the customer needs to know whether they are covered by the reimbursement rules, and the five business day deadline for the refund. The requirements must state the dispute timeline, the evidence list, and the communication at each stage. Accessibility is a legal and a practical requirement. A payment journey must work for a customer who cannot see the screen, who cannot use a mouse, or who reads in a language other than the one the app is written in. The Web Content Accessibility Guidelines require the journey to be perceivable, operable, understandable and robust, and the European Accessibility Act makes this a legal obligation for payment services from June 2025. The acceptance criteria must include a test where the journey is completed using only a keyboard and a screen reader. For a business analyst, the journey map is the deliverable. It must show every step, every decision point, every status update, and every exception path, with the customer emotion at each step. The acceptance criteria must include a test where a real customer completes the journey and the time, the drop-off point, and the satisfaction score are recorded. Last reviewed 7 November 2026. Further reading: the European Accessibility Act, Directive (EU) 2019/882; the Web Content Accessibility Guidelines 2.1; the Payment Systems Regulator work on authorised push payment fraud; the Financial Conduct Authority consumer duty guidance.