PRE-UX RESEARCH · 21 SEPTEMBER 2026 · INSTALLATION FOLLOW-UP

Tap to start eSIM setup.

Finding: iPhone and supported Android phones can start their native eSIM installation flow from a link containing the same activation data used by a QR code. This is a promising fit for the existing order page. The customer still confirms installation on the phone.

Agreed redesign direction · Yaya, 21 September 2026: use an “Add eSIM to this phone” action, with visible QR/manual alternatives. iOS has an explicit Apple support baseline; Android links are documented by provisioning providers but require device testing. Research only: no product controls or live activation links have been added.

What is supported

iPhone · official support from iOS 17.4

Apple documents opening a carrier installation link on iOS 17.4 or later, followed by Allow and Continue. It also supports holding a carrier QR code in a default browser or email app to start Add eSIM on those versions. Device eligibility and carrier support still matter. Apple: Set up eSIM on iPhone.

Apple publishes this link format in its iOS 17.5 release notes, explicitly identifying iOS 17.4+ as the enabled baseline. The carddata value is the GSMA activation string. Apple developer release notes.

Evidence confidence: high for the platform mechanism. Silent.link provisioning and specific browser/device combinations have not been tested.

Android · direct link exists, coverage must be established

eSIM Go documents an Android installation URL accepting the SM-DP+ and activation code, and says embedded-app links should open externally. This is a first-party provisioning-provider guide, not a universal Android compatibility promise. eSIM Go: Android direct installation.

Gigs exposes an androidInstallUrl alongside iosInstallUrl in its SIM credential API. That independently establishes commercial use of both link formats. Gigs: SIM credentials.

CELITECH states Android 10+ with current Google Mobile Services as its minimum requirements. Treat this as its deployment guidance, not a Google guarantee covering all Android 10+ phones. No definitive Google OS/device support matrix for this URL was found in the sources checked. CELITECH: activation-link requirements.

Direct verification: on 21 September 2026, Google's public Digital Asset Links file delegated URL handling to com.google.android.gms. Retrieved over HTTPS with no activation data. This supports a Google Play services dependency; it does not prove installation support on a particular handset.

EE's Android click-to-install instructions show an installation link, a Setup confirmation and subsequent SIM preferences. This demonstrates that “click to install” still involves native steps; EE's porting instructions should not be copied into our travel/additional-eSIM flow. EE: Android click-to-install guide.

Evidence confidence: strong for the link mechanism, incomplete for broad device coverage. Test Pixel and Samsung separately. Keep manual/QR setup for unsupported services, regional variants and other Android builds.

Environment	Research recommendation	Remaining check
eSIM-capable iPhone, iOS 17.4+	Candidate primary direct-install action	Safari, other browser, profile/provider eligibility and confirmation screens
Older supported iPhone software	QR/manual instructions	Do not advertise the newer carrier-link mechanism
eSIM-capable Pixel / Samsung with current Google services	Candidate direct-install action after testing	OS, Google services, browser and OEM combinations; no blanket version guarantee
Android without the relevant Google handler, or unknown capability	Prominent alternative installation methods	Hardware eSIM support does not imply this link is handled
Desktop / installing on another phone	Show QR and manual details for the target phone	Do not launch an installation action on the wrong device
Embedded browser / in-app webview	Offer “Open in your browser” guidance and fallback	External app handoff is integration-specific; test actual entry points

Use the existing activation data

Local evidence: frontend/src/pages/order.js receives data.data.qr, renders it as a QR code and exposes the whole value as the unified string. It also separates the SM-DP+ address and activation code into copyable fields. That is the data needed by the published link formats. Reusing the complete string is preferable to reconstructing it from only two fields, which could drop optional parameters.

Illustrative URL shapes below use placeholders only; they are not executable installation links:

https://esimsetup.apple.com/esim_qrcode_provisioning?carddata=<encoded complete LPA activation string>

https://esimsetup.android.com/esim_qrcode_provisioning?carddata=<encoded complete LPA activation string>

Proposed construction requirements: use the appropriate published lowercase host/path and parameter name; preserve the activation payload's original case and content; encode it once as a query value. Do not lowercase the whole credential or strip additional fields. Validate exact payload handling with a provider-approved test profile. Apple supplies the iOS format; eSIM Go supplies the Android format in the linked documentation above.

Architecture inference: a website handoff appears possible using the order data already available, without requiring a new native app or a new endpoint just to construct a URL. This is not proof that every silent.link profile is eligible; the provisioning partner must confirm supported activation strings, any confirmation-code requirement and reuse rules.

The link is a credential-bearing alternative to the QR. Gigs explicitly warns that installation URLs contain credentials. Keep them within the private order experience; avoid analytics URLs, link shorteners, session recordings and support screenshots containing the payload. The research pages contain no customer codes. Gigs credential handling note.

Native app provisioning is a different option

Apple's native CTCellularPlanProvisioning API requires carrier-app entitlement. Android's START_EUICC_ACTIVATION API is a carrier-app/LPA interaction with caller checks, not a browser JavaScript API. Neither is necessary to explore the documented HTTPS handoff. Building an app solely for this task would add a separate download/onboarding journey. Apple native provisioning API; Android EuiccManager.

The proposed customer experience

Paid order, installation details ready → Add eSIM to this phone → phone confirmation and installation → choose the appropriate mobile-data settings → connected or relevant help.

This can replace navigating manually to the add-eSIM screen and copying/pasting activation values. It does not remove consent, download time, a provider confirmation code if required, or data-line configuration. We have not measured an end-to-end click or time reduction.

Primary label: “Add eSIM to this iPhone” or “Add eSIM to this Android phone”. Supporting text: “Your phone will ask you to confirm installation.” Avoid promising “Installed in one click”.
Secondary route: “Use QR code or manual setup”, visible beside the main action. On a desktop, make QR the obvious route. Do not put a compulsory device questionnaire in front of a clear installation action.
Device detection: use it to suggest a route, with a manual device choice. Treat browser identity as a hint, not proof of hardware, carrier eligibility or link-handler support.
After handoff: keep the order accessible. Do not mark the eSIM installed just because the link was tapped or the browser returned to focus. The reviewed web-link documentation supplies no website success callback; the existing order's activated field needs a confirmed meaning before using it as installation evidence.
Already installed: show relevant management/help rather than urging installation again. Preserve current plan-specific reuse restrictions; do not recommend deleting the eSIM to retry.

Separate installation from using the correct data line. Google's Pixel instructions include SIM preferences after setup; labels and available steps vary. Relevant help should finish the connection task without claiming that a profile download alone proves usable service. Google: dual SIM setup and preferences.

Every handoff needs an exit

What the user sees	Proposed next step
Nothing happens / a browser error opens	Return to the saved order; try the system browser if inside another app; expose QR/manual instructions immediately. Do not create a new order.
Installation cancelled	Keep details available, let the user resume intentionally, and provide help. Cancellation is not proof that the profile is unused.
Same phone cannot scan its own screen	Use the direct action; on eligible iOS versions offer the documented long-press QR path; otherwise provide device-specific manual entry. Do not assume a screenshot/gallery scanner works on every Android.
Unsupported/locked device, no eSIM option or no internet	Explain the prerequisite and route to compatibility/provider help; preserve the order. Avoid endless attempts with the same button.
Code rejected, previously used or profile already present	Check the phone's SIM list and contact support with non-secret order context. Replacement/reinstall rules belong to the provisioning partner.
Installed but no data	Relevant plan instructions for data-line selection, roaming/APN where required, coverage and support. Do not treat this as a request to reinstall.

Baseline manual route on Pixel: Settings → Network & internet → SIMs → Add SIM → Set up an eSIM, then follow device prompts. Google's guide notes carrier-dependent differences. Google: set up a new eSIM.

What is ready, and what must be tested

Ready for UX exploration: both platform URL formats, the iOS version baseline, proposed labels, website handoff, local data fit and fallback structure. Not yet proven: silent.link profile compatibility, reliable Android coverage, native completion detection, physical-device installation or actual time saved.

Provisioning questions

Do all current plan families accept the existing full QR payload through these links? Are there optional fields or separate confirmation codes?
Does first download or first network use change validity/status, and what exactly does our activated field mean?
What are cancellation, download retry, already-installed and replacement rules for each plan?
Can we obtain disposable test profiles to establish a device/browser support matrix without consuming customer eSIMs?

Physical-device trial matrix

Use authorised disposable profiles and record exact handset, region, OS, browser and Google services versions. No trials were run in this research session.

Group	Cases	Success evidence
iPhone	Current iOS/Safari; oldest supported baseline if accessible; alternate browser; embedded-browser entry	Correct native prompt, expected profile, successful setup, usable fallback after cancel/failure
Pixel	Current and older supported OS; current Google services; Chrome; missing/disabled handler condition if safely reproducible	Native handoff rather than inert webpage; correct profile; repeatable behaviour and clear fallback
Samsung	Supported Galaxy/One UI; Chrome and Samsung Internet; embedded entry	OEM-specific steps documented; no assumption that a Pixel pass covers Galaxy
Fallbacks / unsupported	Desktop, non-eSIM device, older software, same-phone manual path, no connectivity, used code	Clear alternative/help; no dead end, duplicate purchase or inappropriate deletion advice
Every eligible group	Cancel, return to order, successful download, already installed, data-line selection	Order remains accessible; no false success state; setup and connectivity outcomes distinguished

Measure actions and active task time from “order ready” to “profile installed”, and separately to “working mobile data”. Compare against the current manual flow on the same device; exclude network wait from active interaction time. Publish tested combinations before broad Android claims. Browser emulation alone cannot exercise the phone's native eSIM installer.

Research decision: proceed to designing and device-validating a direct-install option for both platforms. No implementation, native app, backend change or paid test purchase is authorised by this document. Yaya accepted this direction for the redesign on 21 September 2026. Tracker item 08 remains open for implementation and device validation; this acceptance does not authorise implementation now.