Building Trust on a Payment Screen
A payments product added security badges and lost conversion, then recovered it by removing them and explaining what actually happens to the money.
Definition
A decision case about trust signals: which ones work, which ones backfire, and why the specific worry a user has matters more than generic reassurance.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this page
A composite scenario assembled from situations that recur across teams. It is written to teach reasoning rather than to report on a named company, and outcomes are stated directionally rather than as invented measurements.
Problem
Users were abandoning at the screen where they connected a bank account, and support conversations suggested they were unsure what the product would be able to do with the connection.
Context
A consumer money management product requiring a read-only bank connection. The team's first response was to add trust markers: security badges, a padlock icon, and a line stating that the connection was bank-grade encrypted.
Constraints
- The bank connection was mandatory for the product to function at all.
- The connection was handled by a regulated third-party provider whose brand was unfamiliar to most users.
- Regulatory copy about data usage had to appear and could not be reworded.
- The team could not change what the connection technically permitted.
Decision
Remove the generic badges and encryption language, and replace them with a plain statement of what the product can and cannot do with the connection, shown before the connection begins.
Rationale
The badges answered a question users were not asking. Research showed the worry was not 'will this be intercepted' but 'can this move my money'. Encryption language addressed the first and left the second unanswered, while adding visual noise that made the screen feel like it was defending itself. Stating the actual permissions answered the real question directly.
Evidence used
- Interviews in which participants described their fear in terms of money movement, never in terms of interception.
- Session recordings showing users hovering over the badges without clicking, then leaving.
- Support transcripts asking whether the product could make payments.
- The Stanford Web Credibility research finding that design quality and clarity outrank badges in credibility judgements.
Trade-offs accepted
- The compliance team preferred badges because they were quick to point at during reviews.
- The new copy required legal approval and a review cycle each time it changed.
- Explaining the permission model added a short block of text to a screen the team wanted to keep minimal.
Outcome
Completion of the connection step improved, and support questions about whether the product could move money fell substantially. The screen became simpler rather than busier, which had not been the expected direction.
Alternatives considered
Add more security badges and certifications
Why not: Badges are generic reassurance for a specific worry. Unverifiable badges also attract scepticism, and users had already ignored the ones present.
Delay the bank connection until later in onboarding
Why not: The product does nothing useful without it. Deferring the step would have moved the drop-off rather than removing it.
Explain the encryption in more detail
Why not: More detail about a mechanism users were not worried about does not address the worry they had.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
How do users evaluate the credibility of web sites?
B. J. Fogg et al., Stanford Persuasive Technology Lab, 2003
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Concepts behind this decision
What the reasoning in this case rests on.
- Authority BiasCognitive bias
- Halo EffectCognitive bias
- Mental ModelsMental model
- OnboardingPattern
- Payments and CheckoutPattern
- Deceptive PatternsPrinciple
- User InterviewsResearch method
- MicrocopyUX writing