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

Transfers matter more than almost anything else in Kredive. When one fails, a business can miss a payroll deadline, pay a supplier late, or not know where its money has gone.

Whatever had actually gone wrong, the user saw the same thing:

It didn't say why the transfer failed, whether the destination was having problems, whether trying again would help, or whether the account had already been debited.

I worked on everything around those failures, from spotting a reliability problem before a transfer is sent to helping people recover when a payment doesn't go through. That meant analysing transfer behaviour, mapping the failure states, designing the new flows and interactions, and working with engineering so the design fit the product's technical constraints.

Failures clustered around particular destinations and particular times. Nothing in the product showed users that.

I analysed success rates by destination, payment rail and time of day. On average about 82% of transfers went through first time, but the average hid a lot. Routine transfers cleared reliably. Some destinations dropped sharply at peak periods and at month-end, and one fell to 41% in its worst window.

The failures had a pattern in where and when they happened. That meant Kredive could respond to those conditions instead of treating every failed transfer the same way.

Support data pointed the same way. The question that came up most was:

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

Fail → Retry → Fail again → Retry again

For a business making a time-sensitive payment, that uncertainty could turn a technical failure into a much bigger operational problem. So the question I designed against was:

When a transfer failed, the old experience ended 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. So the interface was part of the problem: it fed the retry loops, duplicate debits and support requests visible in the product data.

Kredive can't control the payment infrastructure underneath it. What it can do is show how reliable that infrastructure is right now, and help users act on it before a payment fails.

Four principles shaped the experience.

Show users the current health of their destination before they send, early enough to change what they decide.

When another route has a better chance of succeeding, Kredive can use it and avoid a path it knows is failing.

A failed transfer should explain what actually happened.

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

Together they change what the product says, from “something went wrong, figure it out” to “here's what's happening, and here's what happens next.”

A transfer that works looks much the same as before. Most of the change is in what happens when one doesn't.

The new flow has four stages, and each one closes a gap in the old experience.

Check → Route → Send → Recover

The user enters an amount and a destination. Before they commit, Kredive checks how reliable that destination is right now.

If it's healthy, the transfer goes ahead as normal. If reliability has dropped, the user sees a clear warning before sending. That information used to exist only inside the system, where no user could use it.

If the selected destination is degraded and another viable route is available, Kredive can suggest the healthier path. It says so, too: the user can see that the route has changed, and why.

Once the user confirms, Kredive keeps the payment's state in view, so there's no guessing between submitting a transfer and knowing whether it has completed.

When a payment fails, Kredive says why. If the failure is temporary, it can queue the payment and retry automatically when the destination recovers, so the user doesn't have to resubmit it or keep checking.

Once the payment completes, Kredive confirms the outcome.

More transfers went through first time, and people stopped retrying into failures.

Smart routing and queued retry are what moved first-attempt success from 82% to 96%. The 600 or so payments recovered each day are ones that would previously have stalled in a retry loop.

Repeat attempts into a failing destination dropped by 71%, and support tickets about destination availability and transfer failures by 49%. Duplicate debits caused by repeated retries fell by 58%. During degraded periods, the median time for a payment to reach confirmation went from around 11 minutes to under 2.

Kredive stopped leaving the reliability problem to the user. A healthy destination behaves as it always did. When reliability drops, the product says so, chooses a healthier route where it can, and recovers eligible payments itself when the issue is temporary.

That is what increased successful transfers, and it removed the behaviour that created the duplicate debits and support demand in the first place.

The transfer screen looked simple. Underneath it were different failure states, changing reliability, payment status and recovery, and that is where the hard UX problem was. The real problem isn't always in the interface you can see.

My part was to make that complexity understandable without pushing the technical detail onto users. I worked through the states a payment could enter, decided what people needed to know at each one, and designed flows that help them recover. The old one only told them to try again.

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

Kredive no longer assumes every transfer will work. When one doesn't, the user has a clearer path.