Payment unified errors: helping users recover from failed payments
When a payment failed, users had to work out the fix on their own. I designed one error framework so every Grab service explains errors the same way and suggests a way forward.
My role
Lead designer. Led workshops, brainstorms, visual and interaction design, and aligned designers across verticals.
Team
Payment team, working with content design, data analytics and other vertical teams.
Impact
+0.98pp more users retried after a failed payment, consistent across countries.
The problem
Users kept retrying without knowing why
When checkout failed, users had to recover by themselves. With little understanding of the reason, many kept retrying and kept failing.
Reframing
The real problem was bigger than payment
My first hypothesis was that recommending another payment method would help users recover. But after mapping the full checkout journey I found the same error had different solutions in different services, and the approach only partly solved the problem.
I ran an internal review with designers, engineers and business partners. It showed a chain of pain: unclear messages for users, extra cost for engineers, and lower completion for the business.
Approach
Two tracks, so teams could move in parallel
I split the work into a long-term error handling framework and a short-term payment method fallback.
Framework
One structure for every error
I grouped errors (geo location, service incompatibility, service disruption, insufficient funds, technical, security) by whether the payment method can still be used, and by whether the user has another method available. Each group gets one standard solution.
Alignment
Payment is only one part of the user flow
I proposed the solution in a workshop with the payment team, then wrote a guideline so other teams could apply it the same way. The new flow cut the steps from four clicks to two.
User testing
Users want control over their money
I led testing in Singapore and Indonesia. Users preferred a manual suggestion over automatic fallback. They want control of their spending, and automatic fallback would need their consent first.
The product team still wanted auto fallback, so I proposed a plan: ship manual suggestions now to learn how accurate the recommendation model is, and ask for consent to auto fallback later.
Scaling
Extending to top-up and add-card errors
The same structure now covers payment, top-up and add-card errors. With a content designer, I also cut five overlapping low-balance messages down to two clear ones.
Result
More retries, and a lesson about the model
The new design encouraged more users to retry (+0.98pp), but retry success fell 1.74pp. The pattern was the same in every country. The root cause was that the recommendation model could not get real-time signals.
Next, I am working with data analytics to find the root cause and propose an interim solution until the model improves.
