Travellers already open your app before a trip to book a flight, pay for a hotel, or check a loyalty balance. Mobile data abroad is the one thing they still go somewhere else for. That makes it an obvious product to add, and more travel, mobility and fintech teams are trying it.
The catch is that an eSIM looks simple from the outside. It's a QR code. Underneath, it's a telecom product with supply, provisioning, lifecycle and support problems. This post walks through what it actually takes to embed eSIM data into an existing app, and the build choices you have.
What happens when a customer buys an eSIM
From the customer's side, buying an eSIM takes about thirty seconds. Behind that, a few systems have to work together:
- Connectivity supply. Someone has to own data capacity in the destination country, through an operator or a roaming agreement, at a price that leaves you a margin.- Provisioning. An eSIM profile is generated and assigned on an SM-DP+ server (the system that securely delivers eSIM profiles to devices), then delivered as a QR code or an activation link.- Activation. The customer installs the profile, switches data to it, and turns on roaming. This step causes most support tickets.- Lifecycle. Usage tracking, low-data alerts, top-ups, expiry, and refunds.- Support. "It's not connecting" at 2 a.m. in another time zone.If you only build the checkout, you still own every one of these problems. Your customers just blame your brand for them. ## Three ways to add eSIM to your product ### 1. Redirect to a partner's store The fastest option is an affiliate link or a partner-branded store. It takes almost no engineering. But you give away the customer relationship, the data, and most of the margin. That's fine for a test, but weak as a product. ### 2. White-label storefront A storefront under your brand with your bundle catalogue, checkout, payments, QR delivery and onboarding pages. The customer stays with you and you control pricing. Integration is light, usually a subdomain or a link from inside your app. ### 3. API-embedded eSIM The deepest option. eSIM offers appear inside the existing journey: a "Add 5 GB for Japan" option on the flight confirmation page, or a data bundle as a card or loyalty perk. This converts best because the offer appears at the moment of need. It also takes the most engineering. ## A reference architecture for the API approach Here's a simplified flow for adding eSIM to a booking confirmation:
- Offer. When a booking is confirmed, your backend calls a catalogue endpoint with the destination country and trip dates, and gets back matching bundles with prices.- Purchase. Payment goes through your existing payment flow. On success, your backend calls an order endpoint with an idempotency key, so a retry never creates two eSIMs.- Delivery. The order returns an activation code or QR. Show it in the app and send it by email. Install instructions should be specific to the device platform.- Lifecycle events. Subscribe to webhooks for installed, activated, low data, and expired. These drive push notifications and top-up prompts.- Top-up. A low-data event triggers a one-tap top-up offer in your app. This is where a lot of the revenue comes from.- Support. Pass the order and device status to your support tool, so agents can see whether a profile was ever installed before they ask the customer to reinstall.Some practical notes from this kind of build:
- Treat the order endpoint as non-idempotent unless the provider says otherwise, and always send your own idempotency key.- Store the ICCID (the eSIM's unique ID) against your customer and booking. It's your key for every support and lifecycle call.- Don't make activation the customer's problem. Most failed activations come from roaming being off or the wrong data line being selected. A short in-app checklist cuts tickets a lot.- Price in local currency and show data and validity clearly. "5 GB / 30 days" sells better than plan names.## Where teams usually get stuck The API call is the easy part. The hard parts are:
- Coverage and supply. Negotiating with operators country by country takes months.- Margins. You need per-market control over cost, price and partner share.- Operations. Refunds, failed installs, and top-ups all need tooling, not spreadsheets.- Analytics. You need to know activation rate, attach rate per booking, and revenue per market, or you can't tell whether this is working.This is why many teams use a platform for the telecom side and keep the customer experience for themselves. ## How One-eSIM fits in Disclosure: I work on One-eSIM. It's a cloud platform for this exact problem. It includes a connectivity marketplace with multi-region supply under one set of commercial terms, a white-label webshop engine, an API layer for embedding eSIM into booking, payment and loyalty journeys, a management portal for pricing and margins, AI-assisted support and top-up flows, and real-time analytics. The brand keeps the customer relationship. If you're working on this for a travel, mobility or fintech product, the platform overview lays out the deployment models. I'm also happy to answer questions in the comments, including if you're building it yourself.
Top comments (0)