The problem
Customers were unintentionally making duplicate online account payments, often multiple times, due to a lack of clarity about whether their first payment went through. These payment errors had real consequences:
Customer pain: maxed-out cards, repeated charges, time lost chasing refunds.Business impact: at least 200 duplicate payments per quarter (~$120k/month in refunds), plus manual workload across Accounts Receivable, Branch Ops, Tech, and Customer Success.
Strategic friction: hindered the company’s goal of shifting more payments online to free up branch staff.
Discovery & problem framing
Though product and engineering leads initially assumed a simple UI fix would suffice (“just block the payment”), I advocated for discovery to uncover root causes and identify the most effective, sustainable solution.Framing the problem was the the most efficient way to nip it in the bud for good.
What I led
Stakeholder interviews with Accounts Receivable and Branch Ops to hear real-world pain firsthand.
Quantitative analysis of payment data to uncover behavioural patterns:
50% of duplicate payments occurred within 20 seconds
majority involved saved cardsHigher repeat behavior on mobile apps
44% of users returned to the dashboard after submitting a payment
If it's clear payment was submitted, they won't attempt to pay again
The solution
When a payment is submitted, remove the action button and indicate it is processing
Since this was a low-risk 'just do it' fix once we understood the cause, my design efforts focused on mapping complexity and ensuring robust coverage across all payment flows.
Key contributions
Mapped 3 distinct user flows: invoice payments, statement payments, unauthenticated 'punchout' payments.
Created a journey map to visualise how duplicate payments affected customers, AR teams, and branch staff, surfacing shared pain points and systemic bottlenecks.
Defined a 72-hour block logic: once a payment was submitted, users were blocked from repeating it until it was either processed or bounced.
UX/UI interventions
Added a 'processing' state next to paid items across the dashboard, transaction history, and punchout screens.
Designed platform-specific enhancements for iOS and Android, where confusion was highest, making the confirmation screen far more prominent.
Delivered responsive mockups for web, iOS, and Android to ensure consistency across all touch points.
Challenges
Initial resistance from product & tech
PM and TL believed this was a simple button fix. I had to advocate for time to investigate root causes and push for a discovery-led approach.
Payment processing lag
Payments take 1–2 days to clear with banks and financial institutions, so we couldn’t just remove items from the dashboard or mark them as 'paid' immediately. We had to allow for the delay while still preventing accidental resubmissions, which I solved by introducing a 'processing' state and a 72-hour block window.
Complexity of payment logic
Each payment flow (invoice, statement, punchout) had its own behaviour and edge cases. Mapping this complexity was key to ensuring coverage and preventing unintended consequences.
No way to trace invoice payments
This part of the app was built on outdated tech that didn’t support basic analytics. We couldn’t track key metrics like device type or payment method, and had to infer behavior based on other payment types (e.g. statements) when sizing the problem and designing the solution.
Outcome & impact
Problem eliminated: duplicate online payments dropped from 1.2% to zero immediately.
Efficiency win: AR team no longer spends time issuing refunds (~18/month previously).
Cross-functional praise: engineering Tech Lead called it “really impressive analysis”.
UX visibility: I showcased the case study to product and department leads as a model for data-driven, discovery-led design.
