Overview
Improving visibility into failed ePayments and guiding resolution within Bill.com’s UI.
When payments failed in Bill.com, customers didn’t know why or what to do next. This led to frustration, high support call volumes, and delayed resolutions. I redesigned the experience to surface clear explanations and actionable steps directly in the UI.
My Role
Lead Product Designer
I partnered with PMs, engineers, and support teams to research customer pain points and design a self-serve resolution flow for failed payments.
Business Problem
Bill.com’s product didn’t provide reasons or resolution steps for failed payments. Customers couldn’t self-resolve, leading to:
• Low visibility: Customers were unaware when payments failed or why it happened.
• High support burden: Customers contacted support frequently, with no clear resolution path in-product.
Customer Problem
Customers had no clarity on why payments failed or what steps to take, leaving them stuck and frustrated.
Previous Experience
Failed payments appeared in the payments grid, but information was limited. On the detail page, failures were flagged without any guidance on what caused them or how to resolve them. As a result, customers often had to contact support, creating frustration and delays.
The failed payment shows up in the failed payments tab on the payments' grid.
The payment details page has a failed chip, but no recommendations on how to resolve them or what the next steps should be.
Project Objective
Surface clear reasons and guided resolution steps for failed ePayments directly within Bill.com’s UI, reducing support contacts and customer frustration.
The Goal
How might we...
…help customers quickly understand why a payment failed and provide simple, in-product steps to resolve the issue on time?
The Process
To tackle failed payments, I collaborated with stakeholders and dug into the data behind return codes. There were more than 50 potential failure codes, but not all of them occurred frequently or required the same level of attention.
Mapping the problem space: I created detailed flow diagrams to capture when and where payment failures occurred, linking them to the specific return codes. This helped visualize the complexity of the issue across both the funding and disbursement legs.
Identifying priorities: By analyzing frequency and impact, I highlighted the top return codes driving over 90% of failures (e.g., insufficient funds, invalid account numbers, and account closures). These became our priority focus areas.
Iterating for clarity: The diagrams went through multiple iterations as we validated findings with stakeholders. Each pass simplified the flows and emphasized customer pain points, making it easier to align on resolution steps and prioritize engineering work.
Outcome: These artifacts became the foundation for determining what customers needed surfaced in the UI—clear failure reasons paired with actionable next steps.
Mapping the Problem Space
Throughout the project, I created multiple flow diagrams to make sense of the complexity of failed payment scenarios. These diagrams were critical for alignment with engineering, operations, and support teams. Each iteration built on the last as we narrowed in on the most impactful resolution paths.
First Iteration: Mapped out all return codes and reasons behind payment failures. This helped us see the landscape, but it was too broad (50+ return codes).
Second Iteration: Focused on the highest-frequency codes and split failures by funding vs. disbursement leg. This narrowed the problem space and made patterns clearer.
Third Iteration: Incorporated resolution paths into the diagrams. By layering in when and where the failure happened (AP vs. AR, Funding vs. Disbursement), we connected return codes with precise customer-facing guidance.
👉 These iterations weren’t just documentation—they were decision-making tools. Each diagram helped prioritize which issues to address first and shaped the final resolution flows we delivered.
Final Designs
These wireframes represented the final handoff to engineering. I worked closely with engineers and product to ensure the designs were implemented smoothly and aligned with the release plan.
Scenario 1: Insufficient Funds
Funding Debit Failed: Disbursement Not Complete
Peter (AP) is trying to pay Victor (Vendor), but the payment fails due to insufficient funds in Peter’s account.
Peter (AP) is trying to pay Victor (Vendor), but the payment fails due to insufficient funds in Peter’s account.
Instead of a generic “failed” message, the new design clearly shows why the payment failed and instructs Peter to transfer funds and reinitiate the payment. This eliminates guesswork and reduces the need to contact support.
The updated UI surfaces clear, actionable guidance:
• Displays the failure reason (e.g., insufficient funds).
• Provides a direct next step (e.g., transfer funds and retry).
• Reduces reliance on support by resolving the issue in-product.
Scenario 2: AP Disbursement Return — Network Vendor on the Payables Side
Peter (AP) is trying to pay Victor (Vendor) and there was an error in the payment.
Peter’s payment did not go through to Victor. An email was sent to Peter so that he can inform Victor to correct his information.
Peter’s payment did not go through to Victor. An email was sent to Peter so that he can inform Victor to correct his information.
In the new design, the interface explains the problem and directs Peter to void and reissue the payment after Victor updates his details. This makes it easy for Peter to communicate next steps to the vendor and resolve the issue quickly.
Peter (AP, payer)
This is what the payer will see:
• The payment to Victor failed.
• Banner explains there is an issue with Victor’s account.
• Instructions direct Peter to void and reissue payment once Victor updates his account
Victor (Vendor)
This is what the vendor will see:
• A red banner explains Bill.com is having trouble with his account.
• Clear guidance to update account info.
• Prompt to contact Peter so the payment can be reissued.
Scenario Summary
Across both scenarios, the redesigned experience surfaced clear reasons for failed payments and actionable next steps directly within Bill.com’s UI. By guiding both payers and vendors through resolution paths, the designs reduced confusion, empowered customers to self-serve, and lowered the volume of support calls.
Impact
• 40% reduction in support calls related to failed payments after in-product resolution steps were introduced.
• 65% faster resolution time, with customers resolving issues in minutes rather than waiting on support.
• Higher customer satisfaction scores, driven by greater visibility and confidence in handling payment failures..