eSIM
in m10

Product intro

A money app, doing something new

m10 is PashaPay's everyday consumer app in Azerbaijan. It's what people open to pay bills, split a check, pay off a traffic fine, and lately, charge an EV. In other words: a money app, opened out of habit, not excitement.

eSIM changes what m10 is for. It adds a full buy-to-install flow for travel data: pick a country or region, pay, get your eSIM, and connect, all without leaving the app. eSimba runs the provider network behind it; Anyway and million-payments handle the transaction.

Why does that matter? For users, it replaces something genuinely annoying, standing in an airport hunting for a physical SIM, or downloading yet another app just to get four days of data somewhere you'll leave in a week. For the business, it's more than a nicer flow. It's a new revenue line with its own margin, real differentiation (very few payment apps do a genuine end-to-end eSIM purchase), and a reason to open m10 for something other than a bill.

Context

No before — a first for m10

There was no "before" inside m10 for this. It's not a redesign, it's the first time m10 touches travel connectivity at all. The market already had answers, though; none of them lived inside a payment app:

• Physical SIM at destination — cheapest option, but means finding a kiosk, dealing with local registration rules, and doing it in a language you may not speak.
• Roaming from your home carrier — the path of least effort, but pricing is often opaque and expensive outside a handful of "friendly" countries.
• Standalone travel-eSIM apps (Airalo, Holafly, Yesim) — genuinely good at the eSIM part, but one more app to download, register on, and pay through — disconnected from the money app you already trust and use daily.

Two things made the timing sharper. Locally, ABB (International Bank of Azerbaijan) shipped a similar feature inside their own banking app while ours was still mid-build, right in the middle of an internal management transition, which made the competitive pressure land harder than it would have otherwise. Globally, Revolut had already set the reference point: full in-app purchase and plan management, no separate app required. That became our internal benchmark for "good."

Business goal

Sizing the bet

The goal wasn't "add an eSIM feature." It was to open a new revenue line and give people an actual reason to open m10 beyond paying a bill. Three things had to be true for it to be worth building: it needed to generate its own margin, be differentiated enough that people would choose it over a dedicated eSIM app, and create recurring, high-intent sessions tied to travel instead of obligation.

The global appetite backs this up. Of people aware of eSIM, 19% already use it, and 51% of those used it specifically while traveling in the last year (GSMA, 2024). Travel isn't a side use case here, it's the primary one. At an average ticket of $7–12 and a 15–25% margin, the capture-rate scenario above works out to an estimated GMV of ~952K–2,448K AZN and revenue of ~143K–612K AZN in year one.

Those numbers, not "better UX," are what made the case internally: a quantified new revenue stream with a plausible path to real scale, sized against an actual outbound-travel market instead of a guess.

Target audience

Travelers already inside the app

Not all m10 users. Specifically, the ones who travel internationally: the subset of roughly 9.2M online Azerbaijanis who take one of the country's 1.37M annual outbound trips, need mobile data on arrival, and already trust m10 enough to pay through it. Frequent travelers, taking 2–3 trips a year, are the sharpest fit, since they hit this same pain point again and again rather than once.

Technical constraints

Three systems that had to agree

This was harder to build than it looks. m10 is a financial app, and an eSIM purchase touches money, a third-party data provider, and a payment gateway all at once. Three systems, all of which had to agree before a user got their eSIM.

• eSimba — the eSIM provider, for catalog data (regions, countries, plans) and order creation/confirmation, gated behind an API key pulled fresh from Vault on every call rather than stored locally.
• million-payments → Anyway — the payment rails, run as a two-phase process: a check step that creates the order in Esimba and shows a confirmed price, then a separate pay step that reserves funds, executes the charge, and only then confirms the order with Esimba. All of it coordinated through async events over Kafka.
• Device fragmentation — three install paths (QR code, one-tap auto-install, manual entry) had to be supported because eSIM support isn't uniform across devices or OS versions, especially on Android, which holds roughly 81% of the local market. A device-compatibility check runs up front so users don't attempt a purchase their phone can't use.

For MVP, the scope stayed deliberately narrow: buy, install, done. Customizable data packages, topping up an existing eSIM from the payments page, and a dedicated "personal cabinet" were all cut from v1 and pushed to the next phase. Not because nobody wanted them, but because getting the purchase-to-install path solid, inside a financial app, with a hard external dependency and a competitor already live, mattered more.

Research

A light competitor pass

This wasn't rigorously documented at the time, so what follows is reconstructed from memory, high-level rather than a full audit.

Adopt

• Revolut — the actual gold standard: a fully in-app eSIM flow, no separate app or account, inside a financial product. Direct proof the model we wanted (m10-native, not bolted on) was viable, and it shaped the core structure of the flow.
• Airalo / Yesim — as standalone eSIM specialists, their catalog browsing (search + "popular" shortcuts) and offering three install paths side by side were worth borrowing directly, even though the apps themselves are the thing we were designing against.

Explore later

• Customizable data packages and in-app top-up — good ideas in these apps, but scoped out of MVP and pushed to the next phase.

Avoid

• The core weakness across Airalo/Yesim: being a separate app entirely — a new download, a new login, a disconnected payment method. Avoiding exactly that was the whole premise of building this inside m10.

We also watched ABB's own eSIM feature once it shipped mid-project. It wasn't really a design input so much as a signal: this was quickly becoming table stakes for banking apps in this market, and that added urgency.

Design process

Designing for someone who's never set up an eSIM

The scenario we designed against: someone booking a trip abroad, a few days out, who's never set up an eSIM before and doesn't want to think about carriers once they land.

Entry, not a destination. eSIM went into m10's existing "My Payments" hub, next to Mobile Operators and Utilities. That's a pattern people already use for buying things through m10, rather than a new top-level feature fighting for attention on the home screen. A single value-prop screen and a Terms of Use step run once: accept, and the app remembers.

Entry point — My Payments hub, value-prop landing, and the one-time Terms of Use step

Letting the user pick their own mental model. The catalog splits into Countries, Regions, and "the whole world," because "where am I going" means something different depending on the trip. Forcing everyone into one framing felt wrong, so we didn't.

Choosing a destination — by country, by region, or the whole world

Transparency before commitment. Plan details surface device compatibility, network type, tethering support, validity window, and an honest fair-use speed caveat, before the user pays, not after. Nobody likes finding the fine print after they've already paid. Payment plugs into m10's own bonus points and balance system rather than a bolt-on checkout, with purchase-terms confirmation reasserted right at the moment of paying.

Plan selection, plan details, and payment — using m10's existing bonus and balance system

Designing for how the product is actually used. Sharing an eSIM uses the native OS share sheet instead of an in-app-only mechanism, because these purchases are frequently made for the family, not just the buyer. The recipient shouldn't need m10 installed just to receive it.

My eSIMs, plan details with QR/activation code, and sharing via the native OS share sheet

Designing for unfamiliarity, not competence. eSIM is genuinely new for most people in this market, and I designed for that assumption rather than against it. That shaped a pre-install checklist front-loading the most common failure points, and three parallel install methods (QR, one-tap, manual) shown side by side instead of forcing one "best" path on everyone. Activation happens in the OS, outside m10 entirely. The real job was making that handoff feel like one continuous flow instead of a jump to somewhere else.

Pre-install checklist, guided quick-install steps, and OS-level activation

Designing for the handoff. The flow closes with a push notification, so confirmation reaches the user even if they've already left the app.

Push notification confirming install, and the eSIM appearing active in My eSIMs

Rejected concepts

A "Plan for you" guided recommendation (a banner offering to answer a few questions and get matched to a plan automatically) got cut and folded into MVP2's customizable-packages scope instead of being attempted alongside a brand-new provider integration. Buying multiple eSIMs in one purchase, and eSIM-specific discounts separate from m10's existing bonus system, were both rejected for the same reason: managing multiple simultaneous orders, or building a dedicated pricing engine, was more complexity than a small dev team could absorb in one pass.

Rejected: guided "Plan for you" recommendation and customizable package selection — cut to MVP2

The fuller "personal cabinet" (Active/Expired tabs, purchase history, visual progress-bar cards with actions built in) was the right long-term idea. It just needed time the team didn't have under a hard ship-fast constraint. That's why it became the explicit MVP2 plan referenced in Results below, not something invented after the fact to explain a gap.

Rejected: fuller personal cabinet with Active/Expired tabs and visual progress-bar cards — cut for time, becomes the MVP2 plan

Collaboration

Shipping under a hard dependency

No formal user testing happened here, but that doesn't mean it shipped without scrutiny. The scrutiny just came from a different direction. Every flow went through design and PM review, then multiple PBRs with the dev team and the eSimba integration team specifically, since a third-party provider sat in the critical path of every screen. Legal reviewed it too, given the consent requirements and the fact that a financial app was shipping a travel/telecom feature with real third-party data dependencies.

This was harder to coordinate than a typical feature, for a specific reason: m10 is a financial app, so this added a payment-adjacent flow (check → hold → pay → confirm) plus an entirely new external dependency, right as the company was going through a management transition. That combination is what actually drove the cuts. Customizable packages, multi-eSIM purchase, dedicated eSIM discounts, and the fuller personal cabinet all got negotiated out of MVP1 in those PBRs. Not because they were bad ideas, but because a small dev team taking on a brand-new provider integration under time pressure, with a competitor already live, couldn't take all of it on at once.

Outcome

Pre-launch, MVP2 already scoped

Pre-launch, still MVP1, so there are no real usage metrics yet. Honest status: too early to measure.

What's next, for MVP2: customizable data packages (choosing exact amount and destination), topping up an existing eSIM directly from the payments page, and the fuller personal cabinet, the richer, more visual version we explored and cut during design. The goal is positioning m10 as the fastest, cheapest way to get connected while traveling.