The problem
Aptoide games use Aptoide Billing for in-app purchases, with cashback returned to the player's Aptoide Balance. For first-time buyers, claiming that benefit came with an unusual requirement: leave the game, install the separate Aptoide Wallet app, then return to finish paying.
Around 70% of users who did not complete a first purchase dropped at that migration step. Acquisition campaigns could convince motivated users to accept the extra work, but the flow was bottlenecking growth in specific markets and demographics.
The user should not have needed the migration step at all. Our first move was a narrow experiment: let people complete the purchase on the web without installing the wallet.
The first experiment
The constraint was cashback. It could only be credited after the wallet created an ERC-20 address, so removing the app also removed the product's strongest incentive.
We introduced pay as a guest. Users could finish in the browser with no installation, while the wallet remained an optional, incentivized payment method. They could also claim their bonus after a successful purchase.
The experiment removed the expected drop-off, but it revealed something more important: the web flow converted roughly 14% better than the native Android wallet flow. The bonus was valuable, but it did not outweigh the cost of switching context and installing another app.
The decision: go web-first
At the same time, an iOS wallet was on the roadmap. Maintaining separate Android and iOS payment funnels would preserve the same friction while multiplying the product and engineering cost.
We made the web experience the primary payment surface and repositioned the native apps as companions. One responsive flow could now serve Android, iOS, and browser users, while improvements could ship without waiting for app-store releases.
Designing the primary flow
Usability studies and country-level A/B tests exposed two issues beyond the forced installation:
- The bonus still mattered. Its position in the payment list made little difference, but removing it reduced conversion.
- Too many payment methods created choice paralysis. First-time buyers struggled to identify the option that was relevant and trustworthy in their market.
The design response was deliberately practical:
| Change | Effect |
|---|---|
| Hide low-usage methods by geography | A shorter picker with locally relevant choices |
| Default to the last-used or most relevant method | Fewer decisions for first-time and returning buyers |
| Keep the bonus visible throughout payment | The value proposition stays present without blocking checkout |
| Tighten layout and copy | Faster comprehension on the lower-end devices common in the audience |
From wallet address to account
The web move also exposed a legacy identity problem. The backend still treated every user as an ERC-20 wallet address, with private keys and recovery phrases handled quietly by the native app. That model made no sense to someone arriving in a browser to buy an item.
Rebuilding the backend identity model would have delayed the work that was already improving conversion. Instead, we kept the address under the hood and placed a familiar account layer on top. Users enter an email, receive a one-time code, and sign in without seeing wallet-management concepts.
Validation and rollout
Payments leave little room for a risky big-bang release. We combined prototype usability studies with country-scoped A/B tests, comparing each change with the native flow in lower-risk markets before expanding it.
The staged rollout checked that conversion remained neutral or positive while exposing payment-method incompatibilities, unusual account states, and fraud-system surprises in cohorts small enough to roll back.
Outcomes
| Before | After |
|---|---|
| Two apps required for a first purchase | One app; the separate wallet install was removed |
| ~70% of dropouts at wallet migration | The step was eliminated |
| Native-only payment experience | Web converted ~14% better than native |
| Baseline payment completion | ~4 percentage point absolute lift after rollout |
| Separate Android and planned iOS flows | One flow across Android, iOS, and browser |
| Wallet backups and private-key concepts | Email and one-time-code account access |
The conversion lift is measured in absolute percentage points, from billing initiation through completion. It excludes earlier steps such as store discovery, installation, and app open; exact internal A/B-test deltas are not public.
This flow shipped with the new Aptoide Wallet identity, so the trust work and the friction work landed as one continuous experience.
