When the bank goes down, the payment shouldn't.

Transfers are one of the most important parts of Venus. For a business, a failed payment isn't just an error in the interface. It can mean a missed payroll deadline, a delayed supplier payment, or uncertainty about where money has gone.

The problem was that very different situations could produce the same experience:

There was no clear indication of why the transfer failed, whether the destination was currently experiencing problems, whether trying again would help, or whether the account had already been debited.

I focused on the experience around these failures — from identifying reliability issues before a transfer is sent to helping users recover when a payment doesn't go through.

The work involved analysing transfer behaviour, mapping the failure states, designing the new flows and interactions, and working closely with engineering to make sure the experience was practical within the product's technical constraints.

Failures weren't spread evenly across the product. They concentrated around specific destinations and times — a pattern the existing experience didn't make visible to users.

I analysed transaction success rates across destination, payment rail, and time of day. The headline number was an average first-attempt success rate of around 82%, but that average hid significant variation.

Routine transfers could clear reliably, while particular destinations experienced sharp drops during peak periods and month-end. One destination reached just 41% success during its worst window.

The important insight was that these failures weren't simply random errors. There were patterns in where and when they happened.

That created an opportunity for the product to respond to those conditions instead of treating every failed transfer in exactly the same way.

The support data pointed to the same problem.

Users weren't primarily asking how to make a transfer. They were asking:

When a payment failed, users often tried the same route again because the product gave them no better option.

That created a cycle:

Fail → Retry → Fail again → Retry again

For businesses trying to make time-sensitive payments, that uncertainty could turn a technical failure into a much bigger operational problem.

The design challenge became clear:

When a transfer failed, the old experience effectively stopped at the error message.

Every one of these gaps pushed users towards an immediate retry, even when the same route was likely to fail again.

The interface wasn't just missing information. It was contributing to the retry loops, duplicate debits, and support requests visible in the product data.

Venus can't control the underlying payment infrastructure. The design opportunity was therefore to make its reliability visible and help users act on it before they had to deal with a failure.

Four principles shaped the experience.

Show users the current health of their destination before they send.

Instead of hiding reliability information, the experience surfaces it early enough to influence the user's decision.

When another route has a better chance of succeeding, Venus can use it rather than sending the payment through a known-problematic path.

A failed transfer should explain what actually happened.

Some failures are temporary. Users shouldn't have to sit there repeatedly pressing Try again.

These principles shift the experience from “something went wrong, figure it out” to “here's what's happening, and here's what happens next.”

The successful transfer journey doesn't need to become significantly more complicated.

The biggest change happens when something goes wrong.

The result is a transfer experience designed around recovery, not just successful completion.

The new flow moves through four clear stages:

Check → Route → Send → Recover

Each stage closes a gap in the previous experience.

The user enters the amount and destination.

Before they commit, the experience checks the current reliability of the destination and surfaces relevant information.

A healthy destination can proceed normally. If reliability has dropped, the user sees a clear warning before sending.

This turns information that previously existed only in the system into something the user can actually use.

If the selected destination is degraded and another viable route is available, Venus can suggest a healthier path.

The important part is transparency.

The user can see that the route has changed and why, rather than having the product silently make a decision behind the scenes.

Once the user confirms the payment, the experience communicates its state clearly.

The goal is to remove the uncertainty between submitting a transfer and knowing whether it has actually completed.

When a payment fails, the experience identifies the reason instead of showing a generic error.

For temporary failures, Venus can queue the payment and retry automatically when the destination recovers.

The user doesn't need to repeatedly submit the same payment or keep checking whether it eventually went through.

Once it completes, Venus confirms the outcome.

The changes had a measurable impact on both transfer success and the behaviour surrounding failed payments.

Smart routing and queued retry increased first-attempt transfer success from 82% to 96%.

Around 600 payments are automatically recovered each day that would previously have stalled in a retry loop.

Repeat attempts into a destination experiencing failures dropped by 71%.

Support tickets around destination availability and transfer failures dropped by 49%.

The median time for a payment to reach confirmation during degraded periods fell from around 11 minutes to under 2 minutes.

Duplicate debits caused by repeated retries dropped by 58%.

The most significant change was that Venus no longer relied on the user to solve a reliability problem themselves.

When a destination was healthy, the transfer could proceed normally.

When reliability dropped, the product could surface that information, choose a healthier route where possible, and automatically recover eligible payments when the issue was temporary.

That combination increased successful transfers while reducing the behaviours that created duplicate debits and support demand in the first place.

This project reinforced something I think is important in product design: the visible interface isn't always where the real problem lives.

The transfer experience looked simple on the surface, but the complexity underneath it — different failure states, changing reliability, payment status, and recovery — created a much harder UX problem.

My contribution was to make that complexity understandable without exposing users to the underlying technical complexity.

That meant working through the different states a payment could enter, deciding what information users actually needed at each point, and designing flows that helped them recover rather than simply telling them to try again.

I worked closely with engineering throughout the process to understand the technical constraints and make sure the proposed interactions, states, routing behaviour, and retry experience could be supported reliably.

The result was a product experience that doesn't assume everything will always work.

It gives users a clearer path when it doesn't.