How I helped expand an ACH-only payment experience with debit-card payments, giving delinquent customers more flexibility to bring their accounts current while supporting a broader goal of reducing charge-offs.
Role: Senior Product Designer, Payments
Platforms: Responsive web, native iOS & Android
Partners: Product Management, Front-End & Back-End Engineering, UX Research, UX Writing, Card Product Design, Fraud/Verification, Payment platform vendor
Focus: Payment UX · Interaction Design · Usability Testing · Cross-Platform Design · Design Systems · Engineering Collaboration · Implementation & QA
Impact
• Launched debit card payments to all eligible customers
• Helped reduce credit card charge-offs below the company's target
• Influenced a faster payment posting experience that improved customer value perception
The Problem
Prosper Marketplace, a financial services company, wanted to give its delinquent customers more flexibility in how they make payments by introducing an additional digital payment method across its servicing experience.
What initially appeared to be a simple addition affected the entire payment journey: eligibility changed with a customer’s account status, and customers could already have pending or scheduled payments. The experience also needed to support adding, selecting, verifying, expiring, and removing debit cards—while preventing duplicate payments, and remaining consistent with the existing ACH experience.
My role was to map these interconnected states and translate payment rules into an experience that clearly guided customers through what they could do, what would happen next, and how their choices might affect existing payments.
The original add a payment method experience was limited to only one kind: bank accounts.
Understanding the user journey
I began by mapping where the new payment method would appear throughout the existing experience and identifying the states, decisions, and edge cases that could affect the customer journey. I saw that by adding an "Add a payment method" screen before letting them add a bank account, we could provide a user with an alternate path. The other option was to include a button on the "Add a bank account" screen that allowed them to add a different payment method, however that would still require an additional screen showing the other options the company was planning to add besides debit cards (such as Google Pay, Apple Pay, etc.). My decision to introduce the options on a separate screen at an earlier step would allow us to scale those additional payment methods more easily.
Working closely with product and engineering, I explored how customers would select and manage payment methods, understand their available options, resolve errors, and move successfully through the payment flow.
Rather than treating the work as a single new screen, I approached it as an extension of the existing payments system. This helped us identify opportunities to reuse established patterns while introducing new interactions only where the additional payment method required them.
The previous ACH payment only user flow for adding a bank account.
The new user flow for adding a debit card. This direction required an interstitial "add payment method" screen to let users choose between adding a bank account or adding a debit card.
From "Bank Accounts" to "Payment Methods"
One of the first structural changes was language.
The existing experience referred specifically to adding and managing bank accounts. That worked when ACH was the only option, but it no longer described the system we were building.
Working closely with a Senior UX writer, I proposed introducing the broader category of payment methods for eligible customers. Within that structure, customers could distinguish between a bank account and a debit card while still understanding both as ways to make a payment.
This affected more than navigation labels. It influenced:
The existing experience referred specifically to adding and managing bank accounts. That worked when ACH was the only option, but it no longer described the system we were building.
Working closely with a Senior UX writer, I proposed introducing the broader category of payment methods for eligible customers. Within that structure, customers could distinguish between a bank account and a debit card while still understanding both as ways to make a payment.
This affected more than navigation labels. It influenced:
- Account settings
- The Make-a-payment flow
- Saved-method selection
- Confirmation and transaction details
- Card-management flows
- Empty, expired, disabled, and error states
This was an important design decision because it gave us room to add debit cards without creating a disconnected, one-off experience. It also established a framework that could accommodate future payment methods.
Designing components for recognition, trust, and reuse
Because customers were entering sensitive financial information, I looked for opportunities to make the new experience feel familiar and trustworthy.
Card-network indicators for Visa, Mastercard, and Discover helped customers quickly recognize supported payment methods, while established Shape components were reused wherever possible to maintain consistency with the broader Prosper experience.
I also worked closely with Engineering on component implementation and revised assets where needed so they could be reused more efficiently. The payment forms became a practical application of the input components and interaction patterns being developed within Prosper's Shape design system.
Card-network indicators for Visa, Mastercard, and Discover helped customers quickly recognize supported payment methods, while established Shape components were reused wherever possible to maintain consistency with the broader Prosper experience.
I also worked closely with Engineering on component implementation and revised assets where needed so they could be reused more efficiently. The payment forms became a practical application of the input components and interaction patterns being developed within Prosper's Shape design system.
Adding a new payment method surfaced an opportunity to simplify the existing component architecture by unifying the patterns for selecting payment methods and managing saved accounts. While I explored a more flexible shared component, implementing it would have required broader research and engineering changes outside the project’s scope. I ultimately preserved the existing patterns and prioritized delivering the new payment experience successfully—a reminder that good systems thinking also means knowing what not to change yet.
In order to reduce the need for 2 different components (a payment method tile for managing payment methods and a radio select tile component for selecting them when making a payment), I explored a component that could support both actions. It was ultimately determined to be out of scope for this project and shelved for potential future exploration.
Preparing customers with a new way to pay
Because debit-card payments were initially available only to eligible delinquent customers, discovery was also part of the experience.
I designed notifications and supporting messaging to let customers know when the new payment method was available and help them understand how to use it.
I partnered with the Senior UX Writer to adapt messages to the available notification components and coordinated with multiple engineering teams so banners and payment experiences remained aligned across the Credit Card platform.
I designed notifications and supporting messaging to let customers know when the new payment method was available and help them understand how to use it.
I partnered with the Senior UX Writer to adapt messages to the available notification components and coordinated with multiple engineering teams so banners and payment experiences remained aligned across the Credit Card platform.
Notifications alerting customers of their ability to use debit cards for payments surface at key touchpoints.
Outcome
The debit-card payment experience successfully rolled out to 100% of the targeted delinquent-customer population. By the second quarter of 2026, Prosper also achieved its broader business target of reducing credit-card charge-offs to below 13%.
The project expanded customer payment flexibility while giving me the opportunity to work across research, interaction design, design systems, payment-processing constraints, implementation, and QA.
Most importantly, it reinforced that payment UX is not only about making a transaction easy—it is about designing the surrounding system so customers can successfully recover when circumstances, account states, or payment methods change.
The project expanded customer payment flexibility while giving me the opportunity to work across research, interaction design, design systems, payment-processing constraints, implementation, and QA.
Most importantly, it reinforced that payment UX is not only about making a transaction easy—it is about designing the surrounding system so customers can successfully recover when circumstances, account states, or payment methods change.
The new debit card input screen designed for desktop and mobile.
The final select payment method screen showing the debit card network logo.