Making local payment methods easier to discover, use, and manage across markets

The first-time deposit flow asked users to add a payment method before buying. But Apple Pay was already available in Buy and required no setup.

A user who left onboarding could go directly to Buy and pay with Apple Pay.

A user who followed the flow first added a card or linked an account, then continued on to make a deposit. After returning to Buy, they had three ways to pay: their balance, the method they had just added, or Apple Pay / Google Pay.

The new method was still useful, but it was not required for the user’s immediate goal. Following the recommended path created more work than leaving it.

This exposed the mismatch: onboarding was organized around funding the account, while many users simply wanted to make their first trade.

Growing assets under management was a business goal, and directing new users to Deposit supported it.

But Deposit did not always match the user’s immediate goal. Someone trying to make a trade could pay directly with a card, wallet, or local bank method.

I proposed moving from first-time deposit to first-time trade. Users started with the trade they wanted to make, then saw the payment options available to them.

Deposit remained an option, but it was no longer the only route presented first. Users could compare methods and choose based on speed, cost, and required setup.

The payment list showed each method’s speed, fee, limit, and required action.

After selection, an interstitial explained the provider handoff, what users needed to prepare, and whether verification or waiting could follow.

ACH required account linking. iDEAL opened another service. Wire transfers required bank instructions. Some methods also included verification or waiting.

I defined what users needed to know before continuing:

• Where they would go next
• What they needed to prepare
• Whether the method was instant
• Fees and limits
• Whether verification or waiting could follow

The payment list supported comparison. An interstitial then explained the next step without repeating the same information.

I collected the existing payment flows across markets and used the flow with the most states and exceptions to define the framework.

From there, I separated the shared journey from market-specific rules, tested it against the remaining regions, and turned recurring patterns into reusable components.

This gave each market room to support its own payment methods without creating a different experience from scratch.

A separate payment-method screen appeared before the amount page.

Switching methods or managing an account meant leaving Deposit and navigating back.

Deposit now opened on the amount page with an account selected.

Tapping the account opened a sheet where users could switch, add, manage, or check the status of payment methods.

The same structure could be reused across markets while preserving each method’s required steps.

I grouped methods by what happened after selection:

• Ready accounts — select and deposit
• View instructions — open manual transfer or wire details
• Add payment methods — view icons for methods requiring setup

The grouping reduced unnecessary taps and made available payment options easier to scan.

Previously, a newly added UAE Simple Transfer account disappeared from the amount page during its cooldown. Users had to reopen the payment sheet to find its status.

In the new design, the account remained selected with a “Pending” label. The CTA changed to “Check pending status.”

Once the account became available, the CTA returned to Deposit.

Users could enter an amount directly and manage every method from one sheet.

New markets could reuse the same structure for ready accounts, payment instructions, account setup, and pending states.

Within one month:

The release included several onboarding and checkout changes, so these figures reflect the combined product update rather than one individual screen.