Collecting failed payments from underserved renters

Rhino is a B2B(2C) financial product offering renters a lower-cost alternative to cash security deposits. Renters pay a monthly fee that protects their landlord, but 25% of renters were considered delinquent with 1+ unpaid invoice – leaving $1.9M uncollected and little recourse due to property manager-controlled cancellations. Our mission: recover lost revenue.

Key metric

Collect 10% of the $1.9M in unpaid invoices

Results

$405,763 collected 1 month post launch, ~90% drop in delinquent renters, 70% drop in payment related support tickets.

The team

• Lead product manager
• Engineering manager
• Business stakeholders

Searching for signals

We undertook a multi-method research deep dive to understand renter payment failures within the broader payments system. Our work included mapping the existing payment recovery workflow, analyzing Stripe transaction data and support tickets for failure patterns, and conducting a targeted survey with delinquent renters to understand their bill-paying behaviors. Together, these inputs surfaced systemic trends and informed our initial hypotheses.

Insights

Stripe charge data analysis

Stripe charge logic will charge the entire outstanding balance, one invoice at a time, and most delinquent renters have 2 failed invoices. The primary payment failure error is ‘insufficient funds’.

Support ticket analysis

Retry payment/update payment is the the #1 support ticket, with renters calling in trying to use an existing card on file.

Payment recovery workflow

Renters are asked to update their payment method each time they have a failed payment, an option patients don’t understand how to leverage for payment of a balance.

Survey

Most delinquent renters are financially insecure. This means they need to allocate and load funds as bills are due, and typically only have one credit or debit card.

Opportunity

Our research led us to define two primary Jobs to Be Done contributing to uncollected failed payments:

  • When my payment fails, I want to know how much I owe and the reason it failed so I can pay the balance.

  • When I have an upcoming payment, I want to know how much I owe and the date I will be charged to ensure I have the funds available.

    (While this job wouldn’t directly move the collect failed payments metric, we identified it as a critical preventative lever and prioritized it as a fast follow.)

I lead a cross functional brainstorm centered around our insights and defined jobs.

The design approach

Build a pay balance workflow accessible from the account, and updated communications directing how to pay.

To ensure our solutions accurately reflected both the user’s mental model and our underlying payment processes, we defined design criteria that ensured the experience accurately represented backend payment states while minimizing resolution friction.

  • Surface actionable feedback by exposing payment failure reasons using existing error data.

  • Accurately reflect balance through a total balance view with optional line-item detail for multiple missed payments.

  • Enable resolution by allowing balances to be paid directly.

  • Minimize recovery friction by supporting use of an existing card on file.

  • Preserve backend charge logic by reflecting partial payments and enabling incremental resolution.

Before

Renters received an email about a failed payment, but it lacked clear next steps. The link sent them to an “update payment method” flow that didn’t match how they expected to pay their balance with an existing payment method. They also couldn’t tell how much they’d be charged—often spanning multiple invoices—leading to partial charges, insufficient funds, and repeated payment failures—even after updating payment.

What changed

I redesigned the failed payment email to guide renters toward paying their balance efficiently, using language targeted towards recent and older balance collection. A single, clear call to action linked to a failed payment workflow aligned with user expectations: task-focused language, full visibility of itemized charges, and a default card option, turning fragmented touch points into a cohesive system, designed to scale.

To ensure payment flow continuity, we also introduced two new updates:

Action required section: Previously, renters had no in-account indicator or access to the pay-balance flow. We added a dedicated section showing required actions and a link to pay.

Partial charge confirmation screen: Stripe’s retry logic often resulted in partial payments that could not be handled through standard in line validation. We added a confirmation screen to alert renters when a balance remained, with actions to resolve it.

Impact

67%

Email click-thru (compared to 27%)

~90%

Drop in delinquent renters

~70%

Drop in payment support tickets MoM

$405,763

Collected in 1 month post launch

What’s Next?

As noted during discovery, we found that renters weren’t acting maliciously—they intended to pay but often lacked sufficient notice to prepare for charges. To address this, we implemented proactive communications sent before a payment failure, alerting renters to upcoming charges and shifting from reactive collections to a more preventive approach.