Around 70% of users who didn't complete a first purchase dropped out at the same step: the moment they had to leave the game, install a second app, and come back to finish paying. Fixing that one step did more than fix that one step. It changed what we believed about the whole flow.
The product and the funnel it sat inside
Aptoide is a non-Google Android app store. Games on Aptoide use Aptoide Billing for in-app purchases, with a real incentive: every purchase returns cashback to the player's Aptoide Balance, spendable on any other Aptoide-billed game.
For most of the wallet's life, claiming that benefit meant doing something unusual mid-purchase. If the player didn't already have the Aptoide Wallet installed, they had to leave the game, install it as a separate app, and come back to finish paying. That came from the project's origin: the wallet was built around an ERC-20 token, so every user existed as a wallet address.
Where users were actually falling out
The funnel for a first-time purchase looked like this:
| Step | What the user had to do | Where the drop-off lived |
|---|---|---|
| Browse / pick item | Open game, pick the IAP they wanted | Light: normal store conversion |
| Trigger Aptoide Billing | Tap "buy" in the host game | Light: billing prompt loads |
| Migrate to the wallet app | Leave the game and install Aptoide Wallet (if not already installed) | ~70% of all funnel dropouts sat here |
| Complete payment | Pick method, pay, return to game | Moderate: payment-method friction |
| Receive item + bonus | Item delivered, bonus appears in Balance | No drop-off |
For a couple of years this was good enough. The bonus was a strong enough incentive that growth compounded anyway. But it leaned on acquisition to do the convincing: social and partnerships had to teach users what the wallet was and build enough trust to install a second app and pay through it. That worked, but it was expensive, and it had started to bottleneck in specific markets and demographics. We weren't pulling in new audiences anymore. We were converting a self-selecting cohort already willing to do extra work to save money.
Why this was a UX problem
Installing a second app to pay sounds like an engineering issue, but it wasn't. The user shouldn't have needed that step at all. So our first move was a web payment flow that let users skip the wallet install entirely. Not a full rebuild, just a wedge to remove the step.
The first move: pay as a guest on the web
The hard constraint was the bonus. Cashback was the wallet's strongest benefit, and it could only be earned through the wallet app, because it had to be credited to an ERC-20 address that didn't exist until the wallet did.
We split the difference. The web flow shipped as a pay-as-a-guest option: users could complete a purchase in the browser without installing anything. They could still claim the bonus by installing the wallet, either before paying (where it shows up as an incentivized payment method, not a prerequisite) or after the purchase succeeds.
A surprise in the data
The interim flow shipped, and the metric we expected to move did move: the first-step drop-off collapsed, because there was no first-step migration anymore.
What we didn't expect was the second number. Conversion through the web flow ran roughly 14% higher than through the native Android wallet flow, even with the wallet heavily promoted, and even though the wallet was the only path that surfaced the bonus inside the payment.
That changed the plan. The web flow stopped being a stopgap and became the obvious next platform for the wallet itself.
So we decided: go web-first
Two things converged at the same time:
- The web flow had quietly outperformed the native flow on the metric the wallet existed to move.
- An iOS wallet was on the roadmap, meaning we were about to add a second native flow to maintain alongside Android.
| Path | What it would mean | Cost |
|---|---|---|
| Keep native, add iOS | Two parallel native flows + the existing friction | High build + maintenance, no conversion upside |
| Native primary, web for edge cases | Forces every user back through the friction | Compounds the bottleneck we just discovered |
| Web-first, fully featured | One flow for Android, iOS, anywhere else | High up-front design effort, single surface to maintain |
The call: build a fully featured web payment flow as the primary surface, treat the native wallet apps as companions rather than the funnel itself, and use the upcoming iOS work as the forcing function to ship the platform-agnostic version instead of another native one.
Validating the move
Re-platforming a payment surface is the kind of change where getting it wrong means finding out by losing money. We ran two tracks of validation early:
Two patterns came out of this and shaped the design directly:
- Promoting the bonus during payment still mattered. Placing the wallet first or last in the list didn't move conversion much either way. Removing it entirely took a significant hit.
- With an ever-growing set of local and global payment methods, first-time buyers couldn't reliably pick one. Choice paralysis was its own drop-off.
Both findings fed the smaller tweaks that compounded across the funnel.
A few extra tweaks that compounded
| Tweak | What it did | Why it mattered |
|---|---|---|
| Hide payment methods irrelevant to the user's geography | Shorter, scannable picker | Removed methods users would never select anyway |
| Default to a payment method | Reduced first-purchase choice paralysis | Method selection stopped being a decision point for most users |
| Layout, copy, and placement discipline across the flow | Faster comprehension on lower-end devices | Most of the audience is on hardware that punishes any layout inefficiency |
From wallet to account
Moving to the web surfaced a problem the native app had absorbed for years. The backend was still built around ERC-20 addresses: every user existed as a wallet address, with everything that implies. Private keys, recovery phrases, the vocabulary of self-custody.
On the native app, the wallet handled key management in the background and most users never thought about it. On the web that was a non-starter. Someone landing on a payment flow has no wallet open, no keys to recover, and no appetite for a seed-phrase tutorial mid-purchase.
Rebuilding the backend to drop the wallet-address model would have blown the timeline and pulled engineering off the move that was actually shifting the metric. So we left the wallet address under the hood and put an account on top. Each wallet got an email, and sign-in became a magic-code flow: the user enters an email, gets a one-time code, and they're in. The backend kept its identity model. The user got an account that works like every other one they use. The wallet address is now invisible to them.
Rolling out without breaking things
Since this was an architecture change, we were cautious with the rollout. The full sequence shipped through country-scoped A/B tests, validating each change against the native flow in low-risk markets before extending it.
This gave us two things at once. First, evidence that the new flow was at least neutral on conversion in every market we tested before it became the default anywhere. Second, an early warning system for the failure modes a big architecture change tends to produce (payment-method incompatibilities, edge-case account states, fraud-system surprises), caught in cohorts small enough to roll back.
The platform side benefit
Making the web flow the primary surface helped with a few other problems:
- iOS wallet development simplified. The iOS work no longer needed to be a native re-implementation of the Android wallet; it could lean on the same web flow.
- Login stopped being a wallet-management problem. The old flow made users manage backups and private keys to protect their ERC-20 address: necessary in the original crypto architecture, deeply unfriendly outside it. The new login dropped that entirely.
- Updates rolled out without app-store gatekeeping. Improvements to the payment experience reached users without waiting on app-store reviews on either platform.
Outcomes
| Dimension | Before | After |
|---|---|---|
| Apps the user had to install to complete a first purchase | Two (store + wallet) | One (store only) |
| Where the biggest funnel drop sat | ~70% of dropouts at the wallet-migration step | Step eliminated; drop redistributed across smaller, addressable steps |
| Web flow vs. native flow conversion | Native was the only flow | Web ran ~14% higher than native, even with the bonus weighted toward native |
| Payment-flow conversion (initiation to completion, excluding store discovery) | Baseline | ~4 percentage point lift (absolute) after the full sequence rolled out |
| Platforms covered by one flow | Android only (iOS in pipeline as a second native build) | Platform-agnostic: one flow serves Android, iOS, and browser |
| Login UX | Wallet backups + private-key handling | Standard account login, no key management surfaced to the user |
The payment-flow lift is in absolute percentage points (not relative), end to end from billing initiation through completion. It doesn't include earlier funnel steps like store discovery, install, or app open. Exact A/B-test deltas live inside Aptoide; the figures above are reconstructed honestly from what I worked with at the time.
This flow shipped under the visual identity introduced in the Aptoide Wallet rebranding, so every surface the user now lands on, from the Android store through the web payment to the iOS flow, reads as the same product. The friction work and the brand work landed as one experience, even though they were two projects internally.
