Most eSIM integrations are designed around the happy path: the user picks a plan, pays, scans a QR code or taps "Install", and lands abroad with data. Then the first support ticket arrives: "I installed the eSIM but it doesn't work." If your app has nothing to say at that moment, the user blames your brand, not the connectivity supplier behind it.
This post is about designing that failure path on purpose: what you can check before purchase, which signals tell you where a profile actually is, the usual causes of "installed but no data", what to show in-app, what to log, and when to refund or re-issue automatically.
1. Prevent the cheapest failures before checkout
A surprising share of activation problems are really compatibility problems that were sold anyway. Before the user pays:
- Check eSIM support on the device. In a native app you have better options than on the web. Where you can read the device's EID (the eUICC identifier), store it with the order: it proves the device has an eUICC and helps support later. On the web you mostly can't detect eSIM support reliably, so fall back to a device allow-list plus a clear "How to check if my phone supports eSIM" step.- Warn about carrier locks. A locked phone may have an eUICC and still refuse a third-party profile. You usually can't detect this, so say it plainly in the checkout copy.- Set expectations on timing. Tell the user to install before travelling (on Wi-Fi), and to switch data to the eSIM line only on arrival.## 2. Track profile state from real signals, not from "the user clicked Install" Your backend sees an order. The SM-DP+ (the server that prepares and delivers the eSIM profile) sees a download. The phone sees a profile that is installed, enabled or deleted. These are different states, and support needs all of them. Under the GSMA consumer eSIM spec, the device sends notifications back to the SM-DP+ for events like install, enable, disable and delete. Whether you get those events depends on your connectivity supplier's API: many expose them as webhooks or as a profile-status endpoint. Model them explicitly:
- ORDERED - paid, profile reserved, activation code issued- DOWNLOADED / INSTALLED - the device fetched and installed the profile- ENABLED - the profile is active on the device- ATTACHED / IN_USE - the network has seen the line, or data usage has started (from usage records, if your supplier exposes them)- DELETED - removed from the device (important: many profiles can't be reinstalled after deletion)The gap that generates tickets is between INSTALLED and IN_USE. If a profile was installed hours ago, the user's trip start date has passed, and no usage has appeared, that's your trigger to reach out proactively instead of waiting for an angry email. ## 3. Know the usual causes of "installed but no data" In practice, most cases fall into a short list, and almost all are device settings rather than network faults:
- Data roaming is off on the eSIM line. Travel eSIMs usually connect as roaming, so this is the number-one cause.- The wrong line is selected for mobile data. The profile is enabled, but the phone still uses the home SIM for data.- APN not set or wrong. Most profiles set it automatically; some devices or plans need it entered manually.- Network selection. Automatic selection picked a network the plan doesn't support; manual selection fixes it.- Not yet in the destination, or the plan's validity window hasn't started.- Profile deleted while "troubleshooting", which often turns a settings issue into a re-issue.Only after these does it make sense to escalate a genuine network or provisioning problem. ## 4. Put the troubleshooting inside the app A help-center article is a fallback. A better pattern is a guided checklist inside the order screen, ordered by likelihood and specific to the platform:
- "Is data roaming turned on for this eSIM?" with the exact settings path for iOS and Android- "Is this eSIM selected for mobile data?"- "Are you in [destination] now?" with the plan's validity dates- A big "Don't delete the eSIM" warning, because that step is often irreversible- Only then: "Still not working? Contact support", with the order context pre-attachedBanks adding travel eSIM inside their apps follow the same idea: BBVA's announcement for its Italian app lists usage tracking, usage alerts, buying more data and contacting technical support side by side in the app (BBVA's announcement). Support isn't a separate channel; it's part of the product screen. ## 5. Log what support will actually need When a ticket reaches a human, they should not have to ask the user for screenshots of settings. Attach to every order:
- ICCID of the profile and EID of the device (if captured)- Device model and OS version- Timestamps for order, profile download, install/enable notifications, and first usage- Last network or country seen, if your supplier exposes it- Which checklist steps the user already confirmed in-appTreat ICCID and EID as personal data: restrict access, and don't send them to analytics tools that don't need them. ## 6. Decide refund and re-issue rules before launch Write the rules down as code, not as agent judgment:
- Never downloaded and the trip hasn't started: refund automatically on request.- Downloaded, then deleted, no usage: re-issue a new profile if your supplier allows it; otherwise refund per policy.- Installed, no usage, checklist completed, user in destination: escalate to the supplier with the logged context, and offer a fallback (re-issue or refund) within a defined time.- Usage started: it's a network or plan question, not an activation one; route it differently.Clear rules keep refunds predictable for finance and fast for the user, which matters most when they're standing in an airport. ## 7. Agree who owns tier 1 and tier 2 If you're a bank, travel app or MVNO reselling someone else's connectivity, settle this in the contract:
- Tier 1 (your brand): in-app checklist, settings guidance, refund and re-issue decisions within policy.- Tier 2 (connectivity supplier): profile state, provisioning faults, network attach problems, coverage issues.- The handoff: which fields you send (ICCID, timestamps, country), the expected response time, and how the answer flows back to the user.Without this, the user gets bounced between "contact your eSIM provider" and "contact the app you bought it from". ## Wrapping up Activation support is where an embedded eSIM either earns trust or loses it. The checklist is short: check compatibility before payment, track real profile state, guide the user through the common fixes in-app, log the identifiers support needs, automate refund and re-issue rules, and draw a clear line between your support and your supplier's. If you're adding branded eSIM to a travel, mobility or fintech product and want the provisioning, portal and support layer handled for you, that's what we're building at One-eSIM: One-eSIM for travel, mobility and fintech. Disclosure: I work on One-eSIM (1-esim.com), a B2B eSIM platform.
Top comments (0)