When the payment
gateway disappeared.

Be clear about what is unavailable.

The first decision was about honesty and speed. We made the unavailable state visible and offered Walgold, Wallex’s gold-investing platform, as an alternative for users whose immediate goal was investment.

In Frames 01–02, the familiar page makes the interruption visible and introduces the temporary alternative.

This had a clear limit: buying gold did not fulfill the intent of someone trying to buy crypto. It was a temporary option while we worked to restore deposits into Wallex.

Three days to design. One week to ship.

By Saturday, there was still no clear end to the shutdown. Waiting was no longer a useful product strategy. We set the previous first-deposit conversion as our recovery benchmark and worked with our payment partners on another route.

Sender information from card-to-card and reference-based transfers could be matched to the information we collected from users. Frames 03–04 show the method-selection page and reference-based instructions. That gave us a way to reconcile transfers and credit the corresponding Wallex accounts.

The release restored access by the end of the week. Average activation recovered to approximately half of its previous level. That was meaningful progress, but also a clear sign that availability alone was not enough.

The route people chose was not the route they needed.

We looked at navigation paths alongside completed deposits. People repeatedly entered the “Direct Payment” activation flow, apparently expecting the familiar gateway. Yet card-to-card transfers accounted for roughly three quarters of completed deposits.

The mismatch made the naming problem concrete. We changed the label from “Direct Payment” to “Automatic Payment.”

Make the next step easier to understand.

With deposits available again, I took ownership of the next phase as both product owner and designer. Working with Shape Up, I coordinated the redesign through release.

The work centered on three questions: which method should I use, how do I transfer correctly, and when will the money arrive?

Start with the amount, not a list of methods.

Each payment method had a different limit. Showing those limits on the cards still left people contacting support to work out which one to use. I redesigned the choice around the amount users intended to deposit.

Entering an amount made eligibility explicit: unsupported methods remained visible but disabled. We aimed to recommend the fastest eligible route, updating the recommendation as the amount changed. The top of the page also brought rotating activity messages and support into view, providing reassurance before an unfamiliar financial task. Frame 05 shows both the empty and amount-entered states, with eligibility and the recommendation updating together.

Confirm the source before the user leaves.

Missing source-card details and transfers from someone else’s card created preventable errors. Immediately after method selection, we asked people to choose a saved card or add their own (Frame 07).

The transfer instructions then made the movement of money explicit: from this registered source, to this Wallex destination. Guidance and the post-transfer action stayed in the same journey (Frame 08).

Teach the banking step where it happens.

“Transfer to this card” was not enough. Every bank had its own labels, navigation, and sequence. Covering every banking app at once would have expanded the scope considerably.

We prioritized the five banks responsible for more than 80% of incoming transfers and placed step-by-step guidance inside the flow. That concentrated the effort on the journeys most people were taking. Frame 09 shows the banking instructions and the return path to Wallex.

Design for the wait after the transfer.

Sending the money did not end the user’s journey. Until their Wallex balance updated, many contacted support to ask when the funds would arrive.

We added “I’ve completed the transfer.” Users entered the method, source, and date and time. Frame 10 collects those details; Frame 11 uses them to show an expected arrival time, rather than leaving users to guess.

If the expected window had passed, the experience changed with it. We acknowledged the longer wait, offered a direct route to support, and explained common causes with the relevant next action (Frame 12).

Recovery beyond the previous baseline.

After the final release, average conversion from signup to first deposit reached approximately 9% above its pre-disruption baseline, and approximately 119% above the first transfer-based release.

During the first few days after launch, conversion briefly peaked around 38% above the old baseline. That early peak is shown separately from the final average.

The journey ends when the money is usable.

The shutdown began as an infrastructure problem. Recovering from it required coordinated decisions about payment operations, product scope, interaction design, and support.

Our first release gave people a way to deposit again. The redesign made it easier to choose, act, and understand what would happen next. Owning both product and design helped me connect those decisions to a single recovery objective.

A deposit experience needs to support the user all the way to having their money available to use.

About the figures: the supplied presentation boards combine Persian product interfaces and English annotations. Frame references follow the numbers printed on the boards, including the two states labeled 05. The boards retain the supplied account details and activity figures. Analytics charts use rounded shares or relative performance. No separate improvement in trust or support volume is claimed.