If you’re a travel brand, OTA, fintech, airline, or publisher, this telecom co marketing toolkit is your practical blueprint for launching a joint eSIM campaign that travellers actually love. Below you’ll find clear templates for landing pages and ad copy, rock‑solid UTM conventions for clean attribution, and the creative specs to brief your team or agency without back‑and‑forth. We’ve also added real snapshots from partner launches, plus a downloadable asset pack so you can go live fast.

Because travellers come first, everything here is designed to remove friction from discovery to activation. That means localised offers (think Esim United States, Esim France, and regional bundles like Esim Western Europe), transparent pricing, and copy that answers the questions passengers actually ask in‑journey. Use this as your baseline, adapt to your brand, and keep tracking clean so your team can see what’s working from day one. When you’re ready to scale, explore Simology’s partner solutions via For Business and the resources on our Partner Hub.

What this toolkit covers

• Landing page structure and traveller‑first messaging
• Ad copy templates for Search, Social, and CRM
• UTM taxonomy and tracking hygiene (with setup steps)
• Creative specs and file guidance
• Case snapshots and results
• Asset pack download and launch timeline

Build a traveller‑first landing page

A strong landing page does three things: reassures, simplifies, and converts. It’s not a brochure; it’s a decision aid. Start with a single, focussed conversion goal (buy, activate, or learn how eSIM works), and avoid sending travellers elsewhere until they’ve taken that action.

Essential sections (checklist)

• Above‑the‑fold value prop: “Travel data that works on arrival — no SIM swap.”
• Primary CTA: “Get an eSIM” or “Choose your destination.” Secondary “How it works.”
• Social proof: ratings, partner trust marks, concise testimonials.
• Country/region picker with best‑selling packs (e.g., Esim Spain, Esim Italy, Esim North America).
• 3‑step “How it works” with icons: Buy → Scan QR → Connect on landing.
• Clear inclusions: data allowance, validity, tethering, coverage, top‑up.
• Price clarity: local currency where relevant, taxes/fees if applicable.
• Compatibility check: iOS/Android models and dual‑SIM note.
• Support and refunds policy summary; link to full help.
• FAQ drop‑downs (top 5 only to keep it scannable).

Pro tip: Embed a destination smart search tied to our catalogue so travellers can jump straight to Destinations.

Traveller‑first template blocks you can copy

Headline options: - “eSIM for effortless travel data — no queues, no plastic.” - “Land connected in the USA/Europe — install your eSIM before you fly.”

Lead paragraph: - “Skip airport SIM stalls. Buy your eSIM in minutes, install via QR, and connect instantly on arrival. Keep your usual number active for calls while using local data.”

Feature bullets: - “Fast 4G/5G where available” - “Keep your SIM — no swap needed” - “Works in X countries” (adapt per plan) - “Hotspot/tethering supported” - “Secure checkout, instant delivery”

Plan grid microcopy: - “Good for maps and messaging (3–5 days city break)” - “Great for streaming and hotspots (10–14 days+)”

Destinations module: - “Popular now: Esim United States, Esim France, Esim Western Europe”

UX patterns that boost conversion

• Keep plan cards consistent: allowance, validity, price, CTA in the same order.
• Add sticky CTA on mobile.
• Use device‑aware badges: “Works on your iPhone 13” where possible.
• Offer a “First time using eSIM?” link to a simple explainer rather than a long tech page.

Ad copy templates that convert

Your job: speak to the trip and the pain you remove (roaming shock, airport queues, public Wi‑Fi). Keep claims verifiable and concrete.

Paid Search templates

Generic: - H1: “eSIM for Travel — Instant Setup” - H2: “No Roaming Fees | Keep Your Number” - Desc: “Install before you fly. Fast 4G/5G on arrival. Plans for Destinations.”

Destination‑specific: - H1: “USA eSIM — Connect on Landing” - H2: “Local Data | No SIM Swap” - Desc: “Buy online, scan QR, you’re live in minutes. See plans: Esim United States.”

Regional: - H1: “Europe eSIM — One Pack, Many Countries” - H2: “Holiday & Business Travel” - Desc: “Use across top hubs. Explore Esim Western Europe.”

Brand+Partner: - H1: “[Your Brand] x Simology eSIM” - H2: “Exclusive Offer for Travellers” - Desc: “Data plans for US, Europe and more. Start here.”

Social and Display templates

Short primary text: - “Land connected. eSIM delivered instantly.” - “No queues. No roaming bill shock. Just data that works.”

Body copy: - “Choose your destination, buy in minutes, scan the QR, and you’re online on arrival. Popular: Esim Spain, Esim Italy.”

CTAs: - “Get eSIM” - “View Plans” - “Install Before You Fly”

Subject lines (CRM): - “Install your eSIM before you fly” - “Avoid roaming fees on your trip to France” - “One eSIM for your US itinerary”

Pro tips: - Mirror keywords from your landing page H1 for Quality Score alignment. - Use location and trip type: “city break”, “road trip”, “business week”. - Always A/B one message that educates (what is eSIM?) vs. one that assumes awareness.

UTM attribution and tracking hygiene

Clean data wins budget. Use one UTM taxonomy across all channels and partners so your analytics platform tells a single story.

Standard taxonomy (recommended)

• utm_source: partner or platform
• Example: “google”, “facebook”, “ota‑brand”
• utm_medium: channel
• “cpc”, “display”, “email”, “affiliate”
• utm_campaign: offer context
• “esim‑usa‑2025q1”, “esim‑western‑europe‑summer”
• utm_content: creative or placement variant
• “vid‑15s‑stories”, “img‑1080‑citybreak”, “lp‑variant‑a”
• utm_term: paid search keyword (where relevant)

Naming rules: - Lowercase only, hyphens as separators, no spaces, no PII. - Keep to < 50 characters where possible. - Include date or season if you’ll revisit later.

Set‑up steps (How‑To)

1) Create a shared UTM guide - One page listing approved values and examples. - Store it alongside briefs on your internal drive or the Partner Hub.

2) Build links with checks - Use a sheet with data validation or your BI tool’s URL builder. - Force required fields; block free‑text where possible.

3) Map to analytics - In GA4, define channel groupings aligned to utm_medium. - Create campaign naming rules to auto‑group reports.

4) QA before launch - Test each ad link in a clean browser session. - Confirm UTMs persist through any redirects. - Validate final landing URLs resolve correctly.

5) Monitor and tidy - Weekly: flag off‑taxonomy values and correct them at source. - Archive ended campaigns to preserve CTR/CVR baselines.

QA checklist: - Are all links HTTPS and canonicalised? - Are UTMs present on all paid links and CRM CTAs? - Is there a single default landing page per campaign? - Does your order confirmation page pass source/medium to revenue?

Pro tip: If you’re driving to multiple country pages (e.g., Esim France and Esim North America), keep campaign consistent and vary utm_content to identify which destination module was clicked.

Creative specs and file guidance

Brief clearly to avoid rework and keep load times fast.

• Static image (Social/Display)
• 1080×1080, 1080×1350, 1200×628
• PNG/JPG, ≤ 500 KB (aim for 200–300 KB)
• Safe‑area for text: < 20% coverage for readability
• Vertical video (Stories/Reels/TikTok)
• 1080×1920, 9:16, 15–30 s
• MP4/H.264, ≤ 15 MB where possible
• Hook in first 2 seconds; show install flow
• Horizontal video (YouTube/Pre‑roll)
• 1920×1080, 16:9, 15 or 30 s
• Include brand bumper in first/last 1.5 s
• HTML5 display
• 300×250, 728×90, 160×600, 300×600, 320×50
• Under 150 KB per creative
• Landing page assets
• Hero image < 200 KB; lazy‑load non‑critical images
• SVG for logos/icons; system fonts or preloaded web fonts

Copy guardrails: - Avoid vague superlatives; favour concrete benefits (e.g., “Install before you fly”). - Localise price and spelling (US vs UK English when relevant). - Make inclusions/exclusions explicit near the CTA.

Case snapshots

• Airline pre‑departure email
• Audience: USA‑bound leisure travellers
• Tactic: “Add eSIM before you fly” segment + Esim United States landing
• Result: +31% CTR vs generic roaming tips; 22% of clicks installed within 24 hours
• OTA booking confirmation page
• Audience: Weekend city‑breakers
• Tactic: Inline module featuring Esim Spain and Esim Italy
• Result: CVR uplift from 2.4% to 4.1% with localised imagery and prices
• Fintech travel card app
• Audience: Multi‑country travellers
• Tactic: In‑app banner to Esim Western Europe
• Result: 18% attach rate when shown post‑FX notification
• Publisher travel guide
• Audience: France itinerary researchers
• Tactic: Content block linking to Esim France with step‑by‑step install
• Result: Average time on page +42%; strong assisted conversions

Launch in one week: a simple plan

Day 1: Scope and assign - Choose priority destinations via Destinations and set one goal (sales or installs). - Confirm analytics owner and paid media owner.

Day 2: Landing page build - Implement the template blocks above; add country modules. - Set up events and test UTMs.

Day 3: Creative and copy - Produce two image variants and one 15 s vertical video per destination. - Draft search, social, and CRM copy using templates.

Day 4: Tracking and QA - Finalise UTM list, build links, and run full link tests. - Check mobile speed (aim < 2.5 s LCP).

Day 5: Soft launch - Launch in one market (e.g., Esim North America) with 50% budget. - Monitor CTR, CVR, CPI; fix any leaks.

Day 6–7: Scale and optimise - Roll out to additional pages (e.g., Esim United States, Esim France). - A/B headline and hero; shift spend to best‑performing placements.

Download the co‑marketing asset pack

To make this painless, grab the partner asset pack on our Partner Hub. It includes: - Editable landing page blocks (copy + wireframe) - Ad copy bank for Search, Social, CRM - UTM builder spreadsheet with validation - Brand guidelines, logos, and icon set - Creative spec checklist and QA worksheet

If you’re weighing a broader programme, see options on For Business.

FAQ

1) What’s the fastest way to go live? - Start with one destination page (e.g., Esim United States), one search campaign, and one social placement. Use the UTM sheet to keep tracking clean, then scale.

2) Should we drive to a regional or country page? - If the itinerary is fixed, use country pages like Esim France. For multi‑stop trips, regional pages such as Esim Western Europe convert well.

3) How do we explain eSIM to first‑timers without hurting conversion? - Keep it to three steps above the fold and put deeper guidance behind an expandable “How it works.” Avoid technical jargon on the primary path.

4) How many ad variants should we run at launch? - Two image variants, one short video, and two copy angles per channel is enough to find a winner without spreading budget too thin.

5) What metrics matter most in week one? - Landing page CVR, cost per install (or sale), and bounce rate by device. Use UTMs to break down performance by creative and destination.

6) Can we cross‑sell during or after purchase? - Yes. In confirmation pages or post‑purchase emails, promote add‑ons like regional upgrades (e.g., Esim North America) or destination alternatives via Destinations.

Next step: Download the asset pack and start your build on the Partner Hub.

Launching an eSIM partnership should be fast, predictable, and traveller‑first. This partner onboarding checklist (telecom‑grade, yet plain English) gives you a week‑by‑week plan from signature to soft launch. You’ll see who owns each task, what “done” looks like, and how to keep travellers front‑and‑centre. Whether you’re a travel brand, OTA, telco, MVNO, or fintech adding connectivity, use this to align teams across branding, legal, sandbox testing, and go‑live. Expect a four‑to‑six week run‑way depending on your integration scope and catalogue size. We also include acceptance criteria and pro tips drawn from real launches, plus a downloadable PDF version of the checklist inside our Partner Hub. If you need help selecting launch markets, browse our Destinations catalogue and top sellers like Esim United States, Esim France, Esim Spain, Esim Italy, Esim Western Europe, and Esim North America.

Who this checklist is for

• Travel brands and OTAs adding ancillary connectivity revenue
• Telcos/MVNOs white‑labelling travel eSIM
• Fintechs, banks and loyalty programmes bundling roaming
• Workplace and events platforms providing temporary connectivity
• Systems integrators building on behalf of the above

If you’re scoping this project, share this article with Commercial, Legal, Product/Engineering, Brand/Marketing, Finance, Support Ops, and Data teams on day one.

Week‑by‑week onboarding plan

Each week includes owners and acceptance criteria. Use the downloadable PDF from the Partner Hub as your live tracker.

Week 0 (Pre‑flight): Decide scope and prepare

Owners: Commercial, Product, Brand

Key tasks: - Define your launch catalogue (countries/regions, data sizes, validity). Consider a phased start with hero SKUs for Esim United States, Esim France, Esim Italy, Esim Spain, and Esim North America or Esim Western Europe. - Choose integration: Hosted checkout, API, or both (for web vs app). - Nominate an internal project owner and a weekly stand‑up cadence. - Request access to the Partner Hub and sandbox credentials. - Gather brand assets: logo files (SVG/PNG), colour palette, tone‑of‑voice guide.

Acceptance criteria: - One‑page scope confirming catalogue, integration path, timelines, and success metrics (e.g., time‑to‑activation < 60s; NPS ≥ 60). - Partner Hub access confirmed for relevant team members.

Pro tip: - Traveller‑first pricing wins. Anchor plans around common trip lengths (5–7, 10, 15, 30 days) and popular volumes (3–5 GB starter, 10–20 GB standard).

Week 1: Contracts and compliance

Owners: Legal, Commercial, Finance, InfoSec

Key tasks: - Execute MSA and service schedules; confirm territory restrictions and brand use. - Complete KYC/KYB and tax forms (as applicable). - Sign DPA and confirm data processing roles. Define breach notification pathways. - Share security posture: data retention, logging, access controls. - Set commercial terms: revenue share, currency, billing cycle, payment method.

Acceptance criteria: - Countersigned agreements; purchase order (if required). - DPA and security questionnaire completed and approved. - Billing profile configured; test invoice generated and validated.

Pro tip: - Keep privacy notices simple. Tell customers what data is needed to deliver eSIM, how long you keep it, and how to get support. Link to your policy at checkout.

Week 2: Branding and catalogue build

Owners: Brand/Marketing, Product, Content, CX

Key tasks: - Approve co‑branding and logo placement. Define naming conventions (e.g., “Simology eSIM – United States 5 GB / 30 days”). - Write concise product copy that answers traveller questions: coverage, speeds, hotspot, top‑up, activation steps, refund policy for unactivated eSIMs. - Build your product catalogue in sandbox: SKUs, prices, currencies, taxes, promo codes. - Draft support content: device compatibility, dual‑SIM setup, and step‑by‑step install guides. - Map cross‑links to coverage pages like Destinations and country packs such as Esim United States or Esim Western Europe.

Acceptance criteria: - Copy and imagery approved; SKU list frozen for UAT. - Checkout and product pages meet brand guidelines and accessibility standards (WCAG AA). - Internal CX playbooks drafted and searchable.

Pro tip: - Publish pre‑travel advice: “Install before you fly, switch on abroad.” It cuts first‑day roaming stress and inbound support.

Week 3: Sandbox integration and testing

Owners: Engineering, QA, Product

Key tasks (API or hosted checkout): - Generate sandbox API keys; set IP allow‑list and webhook endpoints. - Implement core flows: create order, deliver eSIM (SM‑DP+ activation code), resend QR/email, top‑up, refund/cancel (if unused), and status webhooks. - Implement device checks to display “eSIM‑compatible only.” Offer guidance for iOS/Android. - Build error handling and retries for transient network timeouts. - Instrument analytics: funnel steps, activation events, and support deflection.

Test cases to run: - Create and fulfil orders for hero SKUs (e.g., US 5 GB, Western Europe 10 GB). - Delivery methods: QR email, deep link, and manual code. - Activation: install profile, line toggling, data roaming on/off, APN checks. - Edge cases: duplicate orders, expired links, email typos, payment fails, refund of unactivated eSIM. - Latency thresholds: order to code < 3s; webhook delivery < 5s (p95). - Observability: logs contain correlation IDs; PII masked.

Acceptance criteria: - UAT pass report with screenshots, logs, and p95 timings meeting thresholds. - No P1/P2 defects open; alerting in place for failures > 1% in any step. - Support can reissue codes/QRs from console without engineering help.

Pro tip: - Test on both platforms and multiple OEMs. iOS and Android handle eSIM prompts differently; document the exact button text customers will see.

Week 4: Support, operations, and reporting

Owners: Support Ops, CX, Finance, Data

Key tasks: - Define SLAs: first response, resolution, refund of unactivated eSIMs. - Build macros for top queries: “Does my phone support eSIM?”, “How do I install?”, “No data after landing.” - Train support on device settings, dual‑SIM behaviour, and roaming toggles. - Configure dashboards: sales, activations, failure rates, refund rate, CSAT/NPS. - Finance: reconcile test invoices; confirm tax handling; set dispute process. - Incident management: on‑call rota, severity matrix, comms templates.

Acceptance criteria: - Knowledge base live; macros tested end‑to‑end. - SLA adherence tracked; weekly ops review scheduled. - Revenue, activation, and refund reporting validated against sandbox data.

Pro tip: - Aim to resolve “no data” tickets in under five minutes by training agents to check: (1) eSIM line set as primary for mobile data, (2) data roaming ON, (3) device restarted after landing.

Week 5: Go‑live and hypercare

Owners: Project Lead, Engineering, Marketing, Support Ops

Key tasks: - Switch to production keys; repeat smoke tests on a single low‑risk SKU. - Final price check, tax, and currency confirmation. - Roll out tracking pixels/SDKs with consent. - Update support/KM links to production. - Soft launch to 5–10% of traffic or private cohort. - Monitor dashboards and error budgets; hold daily stand‑ups during week 1. - Plan promo for top routes using links to Esim United States, Esim France, Esim Spain, and Esim Western Europe.

Acceptance criteria: - First 100 production orders with ≥ 98% successful activation. - Refund rate for unactivated eSIMs ≤ 1% in week 1. - No unresolved P1/P2 issues for 72 hours.

Pro tip: - Keep hypercare short but intense: a focused, cross‑functional channel (Eng, CX, Data) with on‑call coverage across time zones where you market.

Roles and responsibilities (RACI‑lite)

• Commercial: scope, pricing, revenue targets, relationship management
• Legal/Compliance: MSA, DPA, KYC/KYB, data governance
• Product/Engineering: integration, sandbox, observability, reliability
• Brand/Marketing: naming, copy, assets, campaign plan
• Support Ops/CX: SLAs, playbooks, tooling, training
• Finance: billing, tax, reconciliation, disputes
• Data/Analytics: dashboards, KPIs, experimentation framework

Acceptance test pack: what “ready” means

Use this cut‑down checklist before go‑live: - Catalogue: all SKUs priced, taxed, translated (if applicable), and visible - Delivery: QR and manual code arrive within 60 seconds; deep link opens correctly - Install: profile installs on recent iOS and Android; APN pre‑configured - Activation: data attaches abroad within 60 seconds of landing - Controls: pause/resume data line; hotspot works (if plan permits) - Error handling: friendly guidance for incompatible devices and failed payments - Refunds: unactivated eSIM refund path works in < 2 minutes - Analytics: funnel steps tracked; correlation IDs propagate from order to activation - Security: webhook signatures verified; PII masked in logs; access restricted - Support: agents can find a customer, reissue QR, and send the correct install guide

Catalogue tips: start focused, grow fast

• Start with a small, high‑demand set (US, EU, UK). Use bundles like Esim North America and Esim Western Europe for multi‑country trips.
• Mirror trip reality: weekend break (3–5 GB/7 days), city‑hopping (10 GB/15 days), sabbatical (20–30 GB/30 days+).
• Localise copy where it increases trust; keep tech terms consistent across markets.
• Use the Destinations pages to educate travellers on coverage and device support.

Governance and cadence

• Weekly stand‑up during build, daily stand‑up during hypercare
• A single owner for scope, risk, and timelines
• Clear “no‑go” criteria (e.g., activation success < 95%, webhook failure > 2%)
• Monthly post‑launch review: funnel, NPS, refunds, catalogue updates

Frequently asked questions

1) How long does the Simology partner onboarding take? Most partners go live in 4–6 weeks. Hosted checkout is fastest; full API plus apps and custom catalogue leans towards six weeks.

2) Do we need developers to launch? Not strictly. You can launch with hosted checkout and brand configuration. For deeper integration, our APIs and sandbox are documented in the Partner Hub.

3) Which destinations should we launch first? Pick high‑volume routes for your customers. Common winners are Esim United States, Esim France, Esim Spain, Esim Italy, and regional bundles like Esim Western Europe or Esim North America. Browse full coverage on Destinations.

4) How do we test eSIM without travelling? Use sandbox orders to simulate fulfilment and activation. For production smoke tests, install and activate before travel, then confirm network attach abroad on day one. Document device‑specific steps for iOS and Android.

5) What branding controls do we have? You control naming, copy, and presentation within agreed guidelines. Co‑branding ensures consistency and trust for travellers. Assets and examples are available in the Partner Hub.

6) What about data protection and refunds? We provide a DPA and secure processing. You remain the merchant of record to your customers and should offer clear refund terms for unactivated eSIMs. Avoid storing activation codes in clear text; mask PII in logs.

Download the checklist

A printable, week‑by‑week PDF with tasks, owners, and acceptance criteria is available inside the Partner Hub. Share it with your project team and use it as your live go‑live tracker.

Next step: Explore Simology’s B2B options and get access to the Partner Hub via For Business.

Wholesale pricing for eSIM is different to retail: you’re negotiating capacity, not just buying SKUs. That means tiers, commits, and forecasting accuracy decide your margin as much as your selling price. In this guide we unpack the mechanics of wholesale pricing eSIM: how tier schedules actually calculate, what “hard vs soft” commitments mean in practice, and how to build a forecast tied to travel seasonality and itineraries data. You’ll find worked breakeven maths, practical demand-shaping tactics that don’t hurt the traveller experience, and checklists you can run every month. We’ll also show where regional packs such as Esim Western Europe or Esim North America help you reach volume tiers faster—while still giving travellers the coverage they expect across popular routes like the US, France, Italy and Spain. If you’re a reseller, OTA, fintech, or device brand building travel connectivity, use this as your operating playbook.

What drives wholesale pricing for eSIM?

Wholesale price per GB (or per bundle) is set by a few levers:

• Volume tiers: lower unit costs kick in above stated thresholds (e.g., 10k, 50k, 100k GB/quarter).
• Commitments: price discounts in exchange for a minimum draw (soft commit) or pay-or-take (hard commit).
• Geography and roaming policy: single-country vs regional vs global; in-country vs roaming partners.
• Validity and pack size: shorter validity and micro-packs cost more per GB; larger bundles cost less.
• Quality-of-service: 4G/5G access, throttling thresholds, and fair-use policies.
• Commercial terms: price hold periods, FX currency, payment terms, and promotion allowances.

Pro tip: - Aggregate demand into broader regional products (e.g., Esim Western Europe) to climb tiers faster without sacrificing the traveller experience.

Tier schedules that actually work

A tier schedule defines your unit cost as volume increases within a time window (usually monthly or quarterly). There are two common models:

1) Stair-step (all units at the tier rate once you pass the threshold)
2) Marginal (each tier’s rate applies only to the units within that tier band)

Sample stair-step schedule (quarterly, illustrative USD):

• Tier 1: 0–9,999 GB = $4.50/GB
• Tier 2: 10,000–49,999 GB = $3.90/GB
• Tier 3: 50,000–99,999 GB = $3.30/GB
• Tier 4: 100,000+ GB = $2.80/GB

Blended cost calculation example (stair-step): - If you end the quarter at 12,000 GB, all 12,000 GB price at $3.90 → Blended = $3.90/GB. - At 9,800 GB you’re stuck at $4.50/GB. Missing the 10k tier by 200 GB costs: 9,800 × ($4.50 − $3.90) = $5880.

Marginal schedule example: - First 10,000 GB at $4.50, next 40,000 GB at $3.90, etc. - Blended = (10,000 × $4.50 + 2,000 × $3.90) / 12,000 = $4.40/GB.

Pro tips: - Ask which model applies; your demand-shaping tactics differ materially between stair-step and marginal. - Request a end-of-period “true-up” option if you’re near a threshold; it reduces expensive shortfalls.

Commitments: soft vs hard (and why it matters)

Commitments exchange predictability for price. The fine print decides your risk.

• Soft commit (drawdown): You commit to a volume window (e.g., 30 TB/quarter). If you fall short, you may roll forward a portion or pay a gap fee.
• Hard commit (take-or-pay): You pay for the committed volume whether you consume it or not, usually for deeper discounts.
• Floors/ceilings: Some contracts allow ±10–20% variance without penalty.
• Price protection: The wholesale rate is held for a fixed term; important in volatile FX or roaming markets.
• Carryover and expiry: Clarify if unconsumed volume can roll to the next period.

Worked example (quarterly): - Commit: 30,000 GB at $3.60/GB (hard). Retail ASP blended = $5.40/GB. - If you consume 27,000 GB, you still pay for 30,000 GB. Effective cost per consumed GB = (30,000 × $3.60)/27,000 = $4.00/GB (margin shrinks). - If you hit 35,000 GB and a “best-tier-applies” clause exists, you may benefit from the 50k band if the schedule is marginal and pro-rata true-up is allowed.

Checklist before you sign: - Commitment type and tolerance band - Tier model (stair-step vs marginal), and true-up mechanics - Price hold duration and currencies accepted - Carryover rules and expiry dates - Penalties, promo allowances, and support SLAs

Forecasting that matches travel seasonality

Travellers don’t move in straight lines; your forecast shouldn’t either. Anchor your plan to itineraries and known peaks.

Key inputs: - Bookings and search data by corridor (origin–destination) - Seasonality curves (e.g., Europe peaks Jun–Sep; US peaks around spring break and summer) - Product mix by destination: Esim United States, Esim France, Esim Italy, Esim Spain, and regional packs like Esim Western Europe or Esim North America - Attach rate assumptions by channel (web, app, checkout upsell)

Step-by-step: from itineraries to SKU forecast

1) Map corridors and destinations
- Use your booking data and reference coverage in Destinations to build a top-20 route list.

2) Build monthly arrival curves
- Distribute expected travellers by month using last year’s arrivals and events calendars (festivals, trade shows, school holidays).

3) Set attach rate per corridor
- Example: OTA checkout upsell 8–12%, post-booking emails 3–5%, in-app for existing users 15–25%.

4) Choose pack mix by stay length and use
- City-breakers: 3–5GB; road-trippers: 10–20GB; remote workers: 20–50GB regional packs.

5) Convert travellers to data volume
- Travellers × attach rate × average GB per plan = monthly GB demand.

6) Layer variance buffers
- Apply ±15% range, then choose a commit that your p50–p60 scenario can reliably hit.

Pro tips: - Bundle single-country with regional coverage to capture multi-country itineraries (e.g., France–Italy–Spain) under one plan and push volume into a single tier. - Use early-bird promotions to pull demand from month 1 to month 0 when you’re close to a tier.

Breakeven and margin maths made simple

Keep a small set of formulas in your pricing sheet:

• Blended wholesale cost per GB = Weighted average of tiers and/or commits.
• Revenue per GB (implied) = Average selling price (ASP) per plan ÷ Average consumed GB per plan.
• Gross margin % = (Revenue − Cost) ÷ Revenue.

Worked example (USD, illustrative): - You sell a 10GB US plan at $18 ASP. Average actual consumption = 7.5GB (some users underuse). - Implied revenue per GB = $18 / 7.5 = $2.40/GB. - If your blended wholesale cost is $1.85/GB, gross margin = ($2.40 − $1.85) / $2.40 = 22.9%.

Breakeven ASP targeting: - Target ASP = Blended cost per GB × Expected consumption per plan ÷ (1 − Margin target) - With $1.85/GB cost, 7.5GB consumption, 25% margin: Target ASP = 1.85 × 7.5 ÷ 0.75 = $18.50.

Pro tips: - Monitor “consumption/entitlement ratio” (used GB ÷ plan GB). Improving utilisation by 0.5GB can lift margin more than a 20c price change. - FX hedging: if you buy in EUR and sell in USD/GBP, set an FX buffer in costs.

Demand shaping that respects travellers

The goal: reach better tiers without compromising experience.

Tactics that work: - Regional-first catalogues: Promote Esim Western Europe to travellers visiting France–Italy–Spain; promote Esim North America for US–Canada–Mexico trips. - Plan-size rationalisation: Offer 5GB/10GB/20GB core sizes; prune slow-moving variants that fragment volume. - Time-bound promos: Run 5–10% discounts late in the month/quarter if you’re within 5–8% of the next tier. - Value add-ons: Free hotspot allowance or extended validity instead of deep price cuts; protects ASP. - Tie-in at booking: Highlight coverage on destination pages like Esim France or Esim Italy within itineraries flows.

Guardrails: - Keep throttling and fair-use transparent; never silently degrade service to squeeze margin. - Cap promo frequency to avoid training customers to wait for discounts.

Risk management: variance and buffers

Even great forecasts miss. Design controls:

• Safety commit: Contract at 60–70% of p50 demand; use spot or overage for spikes.
• Spillover product: If a country SKU risks overage, route customers to a regional SKU with headroom.
• Threshold alerts: Daily run-rate vs tier threshold; auto-trigger promotional levers when gap <8%.
• SLA monitoring: Latency and attach success; quality issues can tank conversion and strand volume.

Scenario planning checklist

Run this monthly in the run-up to peak season:

• Update arrivals and attach-rate assumptions by corridor
• Refresh tier attainment model and true-up status
• Recalculate blended cost and breakeven ASP
• Identify SKUs to promote for tier climbing
• Validate inventory/commit headroom by region
• Confirm FX impact on costs and planned prices
• Prepare switchbacks (alternative SKUs) if a network degrades

Case example: Western Europe summer peak

Context: - You expect 42,000 travellers across France–Italy–Spain June–August. - Attach rate target: 12% via checkout plus 4% in-app = 16% overall. - Average plan: 10GB regional.

Forecast: - Travellers × attach rate = 6720 plans. - Entitlement volume = 6720 × 10GB = 67,200 GB. Expected consumption ratio 0.75 → 50,400 GB used.

Commercial move: - Instead of three separate country SKUs, concentrate on Esim Western Europe to consolidate volume and achieve the 50k GB tier. - Offer a June pre-departure promo to pull 5% of July demand forward if you’re short of the threshold. - Feature destination coverage pages in your content stack: Esim France, Esim Italy, Esim Spain.

Outcome: - Blended wholesale rate improves by $0.40/GB at the higher tier, translating to ~$20k extra gross margin over the quarter without raising retail prices.

Operational mechanics and KPIs to track

Instrument these weekly:

• Activation success rate and time-to-first-byte
• Average consumed GB per plan and consumption/entitlement ratio
• Top-ups per 100 activations
• Overage and throttling incidence
• Refund rate and support contact rate
• Tier attainment tracker (run-rate vs thresholds)
• Channel attach rate trends (checkout vs post-booking vs in-app)

Pro tip: - Tie a real-time “tier gap” widget into your merchandising engine to auto-boost regional SKUs when you’re near thresholds.

How Simology helps partners execute

• Coverage and planning: Use Destinations to align catalogue with where travellers actually go, from the Esim United States to multi-country options like Esim North America.
• Commercial tooling: Consolidate commits across country and regional SKUs, with clear stair-step vs marginal models and end-period true-up options where available.
• Data and dashboards: Forecasting modules that ingest itineraries and seasonality; alerts for tier thresholds and SLA anomalies.
• Partner enablement: Bulk provisioning, voucher flows, and flexible APIs via the Partner Hub.
• B2B support: Contracting, FX-aware pricing guidance, and joint promotional planning—see For Business.

FAQ

1) What is “wholesale pricing eSIM” in plain terms?
It’s the rate you pay for eSIM data capacity at scale, influenced by volume tiers and commitments, not just per-plan retail price. Your margin depends on hitting thresholds and managing consumption.

2) Should I choose soft or hard commitments?
If your demand is seasonal or volatile, soft commits with limited carryover reduce risk. If your forecast is dependable and you can aggregate demand (e.g., regional SKUs), hard commits can unlock better rates.

3) How do I avoid missing a tier by a small margin?
Monitor run-rate daily. In the final week, promote regional packs (e.g., Esim Western Europe) or run a limited discount. Ask for end-of-period true-up rights when negotiating.

4) What pack sizes maximise margin without harming travellers?
Offer a tight set (5GB, 10GB, 20GB). Use data on average consumption; if 10GB users typically consume 7–8GB, pricing can be set to a healthy margin while keeping fair value.

5) Do regional eSIMs hurt user experience?
No—done right they improve it. Travellers moving between, say, France–Italy–Spain avoid swaps, and your volumes consolidate to better tiers. Highlight coverage pages like Esim Italy to build confidence.

6) How often can wholesale tiers or prices change?
Typically quarterly, with a price-hold clause. Mid-term adjustments can occur with FX swings or network changes; build 3–5% contingency into your margin model.

Next step: Explore tooling, APIs and commercial options in the Simology Partner Hub to structure your tiers, forecast with seasonality, and protect margins.

Building trust in telecom is about more than network reach; it’s about how you respond when something goes wrong. Travellers expect seamless connectivity across borders, and your enterprise or wholesale operation needs a support framework that’s fast, clear, and consistent. This guide breaks down what an effective support SLA looks like in telecom, how to prioritise incidents with a severity matrix, and how to communicate before, during, and after disruption. You’ll find practical response-time benchmarks, ready-to-use RCA templates, maintenance window patterns that respect traveller behaviour, and status page best practices. Whether you’re powering eSIM across Destinations or servicing multi-region fleets using Esim North America and Esim Western Europe, these practices help you protect customer experience while giving your teams a clear playbook. Use this as your baseline to align carriers, partners, and your internal tiers on a common, traveller-first approach.

What a good telecom support SLA includes

A support SLA in telecom (support sla telecom) sets expectations on availability, response, communication, and remediation when service degrades. Keep it short, unambiguous, and enforceable.

Core components: - Scope: Services, regions, and components covered (e.g., activation, provisioning, data, voice, SMS). - Availability targets: Per component and region; define business vs. 24×7 coverage. - Severity matrix: How you classify incidents by impact and urgency. - Response SLOs: Initial response, update cadence, workaround and restoration targets. - Escalation: Tiers, roles, and time-to-engage. - Communication: Channels, status page use, and stakeholder notifications. - RCA & credits: When a post-incident report is required; how credits are evaluated. - Maintenance: Window policy, freeze periods, and notice rules.

Severity matrix (telecom-specific)

Define severity by customer impact and scope. Keep it to four levels to reduce ambiguity.

Severity

Definition

Typical impact

Examples

Sev 1 – Critical

Broad outage or safety-critical impact; no workaround

Majority of active users impacted; revenue/safety at risk

Nationwide data attach failure; eUICC download failing for all

Sev 2 – Major

Degradation or regional issue with partial workaround

Subset of users, one region or feature

Throttling in one country; provisioning delays in one MNO

Sev 3 – Minor

Limited feature impact; clear workaround

Small cohort or single partner

Delays in usage reporting; intermittent SMS OTP failures

Sev 4 – Informational

No service impact

Queries, docs, requests

API questions; portal access request

Pro tips: - Always classify by current customer impact, not perceived root cause. - Allow dynamic reclassification as the blast radius grows or shrinks.

Response, updates, and restoration targets

Use clear targets per severity and enforce a minimum update cadence.

Severity

Initial response

Update frequency

Work hours

Target restore

RCA delivery

Sev 1

15 minutes

30 minutes

24×7

2 hours (workaround) / 6 hours (fix)

48 hours draft / 5 business days final

Sev 2

30 minutes

60 minutes

24×7

8 hours (workaround) / 24 hours (fix)

3 business days draft / 7 business days final

Sev 3

4 hours

Daily or on-change

Business hours

3 business days

Included in weekly summary

Sev 4

1 business day

As needed

Business hours

N/A

Not required

Notes: - “Restore” means service usable with or without workaround; “fix” is permanent remediation. - If third-party carriers are involved, include time-to-engage (e.g., ≤30 minutes for Sev 1).

Tiers and escalation paths

A tiered model keeps first-response fast while ensuring deep expertise is engaged when needed.

• Tier 1 (Frontline/Service Desk)
• Intake, validation, repro, customer comms
• Tools: runbooks, status page updates, IM channels
• Engage Tier 2 within: 15 mins (Sev 1), 30 mins (Sev 2)
• Tier 2 (NOC/Support Engineering)
• Correlate logs, metrics, and partner tickets
• Execute mitigations and workarounds
• Engage Tier 3/Carrier within: 15 mins (Sev 1), 60 mins (Sev 2)
• Tier 3 (Platform/Network/Core Engineering)
• Root cause analysis, configuration/infra changes
• Own permanent fix and RCA
• External carriers/partners
• Pre-agreed contacts and escalation ladders
• 24×7 readiness for Sev 1/2; firm SLAs in interconnect agreements

Escalation checklist: - Single incident commander (IC) per incident - Communications lead distinct from IC - Technical lead for diagnosis/remediation - Customer liaison for high-value or wholesale partners

Incident communications playbook

Before: prepare

• Define your components and regions on the status page (e.g., “Activation API”, “eUICC download”, “Data in France/Italy/US”).
• Pre-write incident templates for each severity.
• Maintain a contacts matrix (internal, carriers, key customers).
• Set notification channels: status page, email, partner Slack/Teams bridges, and portal banners.
• Subscribe key accounts to incident updates for the regions they sell, such as Esim France, Esim Italy, Esim Spain, and Esim United States.

During: communicate clearly and on a clock

Golden rules: - Lead with impact, not speculation. - Time-stamp in UTC and local time if region-specific. - Give next update time even if there’s no change.

Update template (initial): - Title: [Sev X] Region/Component – Short description - Start time: 2025-03-10 14:20 UTC - Impact: Who is affected and how (e.g., “New activations in Italy failing; connected devices remain online.”) - Scope: Regions/components - Workaround: If any - Next update: e.g., “in 30 minutes”

Update template (progress): - What changed since last update - Current hypothesis (clearly labelled) - Actions in progress and ETA - Next update time

Recovery template (restore): - Restoration time - Residual risk or degraded features - Required customer actions (e.g., toggle data, re-scan network)

After: close the loop with an RCA

RCA should be blameless, factual, and actionable. Share appropriately with wholesale partners.

RCA outline: - Summary: One paragraph plain-English description - Impact: Duration, affected regions/components, % of sessions/users - Timeline: Key events with UTC timestamps - Root cause: Technical detail and contributing factors - Detection: How it was found; detection gaps - Mitigation: Immediate actions - Corrective actions: Permanent fixes with owners and target dates - Prevention: Monitoring, tests, or process changes - Customer impact & comms: What was said, when, and why - Credits (if applicable): Criteria and calculation method

Pro tips: - Attach metrics (graphs), not just logs. - Distinguish trigger vs. root cause. - Include “what would have caught this earlier?”

Status page best practices

A status page is your single source of truth for live service health.

Must-haves: - Component-level visibility: APIs, provisioning, data by country/region (e.g., Western Europe vs North America). - Transparent history: 90 days minimum of incidents and maintenance. - Subscriptions: Email/RSS/webhooks for partners. - Timezones: Default UTC; include local time for regional incidents. - Plain-English updates: Avoid vendor codes and internal jargon. - Incident templates: Pre-approved language for speed. - Accessibility: Mobile-friendly; loads fast on low bandwidth.

Nice-to-haves: - Partner-specific audiences/labels for wholesale cohorts. - Dependency notes for third-party carriers. - Dedicated pages for regional portfolios like Esim Western Europe and Esim North America.

Common pitfalls to avoid: - Silent fixes without updates. - Over-promising ETAs; give ranges if uncertain. - Mixing marketing content with service health.

Maintenance windows that respect travellers

Your change calendar should align with low-usage periods and peak travel patterns.

Policy recommendations: - Standard windows: 01:00–05:00 local time per affected region. - Advance notice: 7 calendar days (minor), 14 days (major), 30 days (potentially disruptive). - Freeze periods: - Summer holiday peaks for Europe (e.g., July–August for Esim Western Europe) - Major US holidays and end-of-year travel for Esim United States - Bundling: Group low-risk changes to reduce churn; separate high-risk changes with rollback plans. - Rollback: Mandatory tested rollback for any change that affects attach, provisioning, or routing. - Monitoring: Extra alerting during and after maintenance for at least 2× the change duration.

Maintenance notice template: - Title: [Planned Maintenance] Component/Region - Window: Start–End in local and UTC - Impact: Expected behaviour (e.g., “up to 5 minutes provisioning delay; no loss of active sessions”) - Risk level: Low/Medium/High - Rollback: Available (Yes/No) - Contact: Support channels during the window

Step-by-step: Build your SLA and comms package in 7 steps

1) Define components and regions - List all customer-facing functions and map them to regions/countries visible on Destinations.

2) Draft your severity matrix - Use the four-level model above; add examples for your stack.

3) Set response and update SLOs - Start with the table in this guide; adjust to your operating coverage (24×7 vs business hours).

4) Establish tiered escalation - Assign named ICs, comms leads, and technical leads; define time-to-engage per severity and external-carrier contacts.

5) Stand up an authoritative status page - Component/region breakdown; subscriptions; incident templates; UTC-first timestamps.

6) Publish maintenance policy - Windows, notice periods, freeze calendar tied to regional travel peaks (e.g., Europe summer and North America holidays).

7) Operationalise RCA - Adopt the RCA template; create an internal deadline (e.g., 48h draft/5–7 days final) and share with wholesale partners via your portal or Partner Hub.

Alignment with Simology partners

For partners building on Simology: - Commercial alignment: Use For Business to frame enterprise expectations on uptime, response, and reporting. - Geographic clarity: Map your product mix to our regional portfolios (e.g., Esim France, Esim Italy, Esim Spain) and ensure your status components match. - Traveller-first policy: Prioritise incidents that prevent activation or data attach for travellers currently in-region; communicate workarounds promptly (e.g., manual network selection). - Shared comms: Mirror status updates in your partner portal, and subscribe key customers to relevant regions.

Quick checklists

On-call pack: - Incident templates (initial/progress/restore) - Severity criteria cheat sheet - Carrier escalation contacts and SLAs - Runbooks for common failures (attach, APN, provisioning) - Status page access and posting rights

Minimum data to include in every update: - What we know - What we don’t know - What we’re doing next and when we’ll update - Customer actions (if any)

FAQ

• What’s the difference between restoration and resolution?
• Restoration means users can operate normally (often via workaround). Resolution is the permanent fix. Your SLA should target both where appropriate.
• How often should we update during a major incident?
• For Sev 1, every 30 minutes. If there’s no change, say so and state the next update time. Consistency builds trust.
• Can severity change mid-incident?
• Yes. Reclassify as impact grows or contracts. Document the change and adjust cadence accordingly.
• How do we handle third-party carrier faults?
• Engage within 15–30 minutes for Sev 1/2, reference interconnect SLAs, and communicate dependency status on your status page. Include carrier timelines and constraints in your updates.
• What belongs on the maintenance calendar?
• Any planned activity that can affect activation, provisioning, data plane, or billing—no matter how small. Provide risk, expected impact, and rollback detail.
• How do we support multi-region customers travelling the same day?
• Use UTC timestamps, include local times for affected regions, and call out roaming impacts across portfolios like Esim North America and Esim Western Europe. Provide region-specific workarounds.

Next step: Ready to align your SLA and incident comms with Simology? Visit the Partner Hub to access enablement materials and coordinate your rollout.

Modern travel demands instant connectivity, and eSIM makes it happen. For partners reselling or embedding Simology connectivity, the job is bigger than coverage and price. You’re handling identity checks, personal data, and operational logs across borders. This guide brings together the essentials of eSIM compliance eKYC GDPR in plain English so you can build trust with travellers while staying audit‑ready. We outline what data is genuinely needed, how to minimise risk, and how long to keep records without over‑retaining. You’ll also find checklists and pro tips for privacy‑by‑design and practical data retention schedules. If you serve travellers headed to multiple regions — from Esim United States to Esim Western Europe — your compliance posture must flex with local rules while giving a consistent, friction‑light experience. Use this as a blueprint to align your teams and vendors, and to make privacy a feature travellers can feel.

Why eKYC matters for eSIM travellers and partners

Electronic Know Your Customer (eKYC) verifies a traveller’s identity before activating service in markets where it’s required by telecom, anti‑fraud, or security regulations.

Typical triggers: - Prepaid SIM rules (many EU and APAC markets). - Roaming controls and fraud prevention. - Payment risk or chargeback mitigation for high‑value plans.

What eKYC usually collects: - Identity document data (passport, national ID, sometimes driving licence). - Face verification (selfie with liveness) to match the document. - Minimal device data to bind activation (e.g., EID/IMEI), and IP/location signals for risk scoring.

Country differences matter. For instance, some EU countries require SIM registration before first use, while the United States is generally lighter on mandatory SIM registration but robust on privacy and law enforcement requests. If your travellers are buying across Esim France, Esim Italy, or Esim Spain, your workflow should adapt to each market’s rules without making the user repeat steps. Direct travellers to options on Destinations, and ensure your backend enables compliant activation journeys per country.

GDPR and global privacy principles, distilled

GDPR sets the global benchmark for personal data protection. Even when you sell outside the EU, adopting its core principles will simplify operations and reduce risk.

Key principles to build into your eSIM flows: - Lawful basis: Most eSIM processing rests on contract (to provide service), legal obligation (where eKYC is mandated), and legitimate interests (fraud prevention). Use consent only for optional features like marketing. - Purpose limitation and minimisation: Collect only what the regulation or the service genuinely requires. Don’t repurpose identity images for unrelated analytics. - Storage limitation: Keep data only for the period needed to meet legal, tax, or dispute requirements — then delete or irreversibly anonymise. - Security and confidentiality: Encrypt at rest and in transit. Limit access by role. Maintain separation between KYC images and operational logs. - Transparency and control: Clear notices at point of capture, easy access to rights (access, rectification, deletion), and visible retention timelines.

Cross‑border transfers: - If EU/UK data leaves the EEA/UK, safeguard with adequacy decisions, Standard Contractual Clauses (SCCs) or UK IDTA as appropriate, plus transfer risk assessments and technical controls (encryption, key management).

Practical tip: Keep your Data Processing Agreement (DPA) stack tidy. You should have a DPA in place with Simology and any sub‑processors, aligned to the data you actually collect in each workflow.

Data retention and logs: what to keep, and for how long

Telecom operations generate a lot of data. You need enough to support travellers, fulfil lawful obligations, and investigate fraud — but not so much that you create unnecessary risk.

Common data categories - eKYC data: document images, extracted fields, liveness artefacts, verification outcome, and audit trail. - Activation and provisioning: EID/IMEI, ICCID, activation timestamps, plan details, order/payment references. - Network session metadata: session start/stop, cell/location approximations, volume counters (no content). - Support and compliance: consent logs, policy versions, ticket history, refunds/disputes, law enforcement requests (where applicable). - Security: access logs, API logs, fraud signals, device fingerprints.

Typical retention ranges (select minimum necessary) - eKYC images and liveness artefacts: 90 days to 24 months, depending on local mandate and dispute window. Prefer deleting images once the verification decision is final and only retaining a hashed template or verification token where admissible. - Extracted KYC data (e.g., name, document number): retain only as long as needed to meet telecom registration requirements; commonly 6–24 months, varying per country. - Activation/provisioning records: 12–24 months to support customer care, chargebacks, and lawful requests. - Network session metadata (no content): 6–12 months is typical in many markets; local law may require longer or shorter. - Billing/tax records: often 6–7 years in many jurisdictions. Store these separately and avoid bundling with KYC images. - Security and access logs: 6–18 months to support incident response and forensics.

Do not keep - Raw biometric templates or full‑resolution video beyond the shortest regulatory and operational need. - Duplicate copies of KYC images in analytics sandboxes or support tools. - Content of communications (not part of eSIM data plans) unless explicitly regulated and lawful.

Step‑by‑step: Build your retention schedule

1) Map your data: - List every field captured in eKYC, activation, usage, billing, and support.

2) Assign lawful purpose and system of record: - For each field, define why you need it and where it lives.

3) Set retention per category: - Use the shortest timeline that satisfies the strictest regulatory need for that market.

4) Automate deletion: - Implement lifecycle rules (e.g., S3 object lifecycle, database TTLs) and keep evidence of deletion in audit logs.

5) Separate storage: - Store KYC images separately from billing/usage. Restrict access via least privilege.

6) Document it: - Maintain a one‑page retention matrix per market. Keep it updated when laws change.

Pro tips - Use tokenisation: replace document numbers with irreversible tokens in everyday systems; keep the mapping in a segregated vault. - Prefer summary over detail: retain aggregate usage counters over per‑packet detail. - Time‑box support access: temporary just‑in‑time access for agents, with session recording.

Privacy‑by‑design for eSIM: a practical checklist

• Minimise from the start: collect only the document type required for that country. If a national ID suffices, don’t ask for a passport.
• Make it legible to travellers: show exactly why data is needed, where it’s stored, and for how long.
• Default to the strictest market: design flows that can downgrade requirements for lighter regimes, not the other way around.
• Secure everywhere: TLS 1.2+, encryption at rest (AES‑256 or better), HSM‑protected keys, rotating secrets.
• Strong vendor governance: DPAs, sub‑processor lists, breach SLAs, penetration tests, and SOC 2/ISO 27001 where available.
• Data Protection Impact Assessment (DPIA): run a DPIA for identity verification and cross‑border transfers.
• Consent hygiene: separate toggles for marketing vs service updates; keep timestamped consent logs.
• Traveller self‑service: portal to access/delete data where allowed, and to download invoices for expenses.

eKYC implementation options and risk control

Right‑size your eKYC to the market and plan type:

• Document scan + liveness: standard for countries with SIM registration rules. Store verification outcome; avoid long‑term storage of the raw selfie/video.
• Database checks: where lawful, validate against government or telco registries to avoid storing images.
• Risk‑based flows: lighter checks for low‑risk, low‑value plans; step‑up verification if fraud signals trigger.
• Offline fallback: for travellers with poor connectivity, enable deferred document upload with limited temporary access.
• Re‑use safely: if a traveller verified last month for Esim North America, you may re‑use a tokenised verification to buy Esim United States without re‑capturing images, subject to local rules.

Pro tips - Hash and forget images: retain a cryptographic hash of the document image for deduplication/fraud detection, not the image itself. - Separate decisioning: store “pass/fail + reason code” in operational systems; keep raw artefacts in a secure verification vault with short retention.

Cross‑border operations: aligning US, EU, and beyond

• EU/UK: expect SIM registration in several markets, strong GDPR rights, and tight storage limitation. Host EU resident data in the EEA/UK where possible, with SCCs for any exports.
• United States: generally fewer mandatory KYC rules for prepaid; focus on CPNI, state privacy laws, and law enforcement response processes. Regional nuances apply.
• APAC/MENA: several markets require passport/ID capture for SIM activation; watch for data localisation (country‑resident storage) requirements.

Keep it simple for travellers. Someone buying Esim Western Europe wants one purchase to cover France, Italy, and Spain. Behind the scenes, your systems should meet each market’s registration rules without extra friction. Offer clear guidance on Destinations and provide country‑specific help within the checkout.

What travellers expect (and notice)

• Speed: a sub‑2 minute identity check that works on mobile.
• Clarity: simple explanations for why an ID is needed in France versus not in the US.
• Control: the ability to delete their account or remove a stored document when rules allow.
• Security cues: trusted logos, clear privacy links, and no surprise re‑verification for add‑on plans.
• Helpful coverage info: straightforward product pages like Esim France, Esim Italy, and Esim Spain that set expectations before checkout.

Partner integration with Simology

If you’re building on Simology via wholesale or bundling connectivity into your product:

• Define roles early: who is controller vs processor for eKYC, activation, and support data.
• Use standard endpoints: integrate identity verification and consent capture through approved APIs; don’t invent parallel data stores.
• Align retention with us: mirror Simology’s recommended timelines and ensure automated deletion on your side.
• Centralise help content: point travellers to the right local guidance and plan pages on Destinations.
• Governance cadence: quarterly reviews of sub‑processors, transfers, DPIAs, and incident drills.

Explore options on For Business and get documentation, samples, and support via the Partner Hub.

Quick compliance checklists

eKYC readiness - Markets mapped: which plans require ID? - Verification vendor vetted and under DPA. - Short‑term storage of images with auto‑delete. - Decision tokens available for re‑use. - Clear traveller messaging per market.

GDPR and privacy - Lawful bases documented per data category. - Transparent notices and consent logs. - Data subject request workflow tested end‑to‑end. - Cross‑border safeguards (SCCs/IDTA) in place.

Logs and retention - Separate stores for KYC, usage, billing, and support. - Automated retention rules and deletion evidence. - Least‑privilege access with time‑boxed elevation. - Regular log integrity and access reviews.

Security - Encryption everywhere, key rotation, HSM/KMS. - MFA and SSO for all admin access. - Pen tests and vulnerability management. - Incident response runbooks and contacts maintained.

FAQ

Q1: What is eKYC in the context of eSIM? A1: eKYC is a digital identity check used before activating service in markets that require SIM registration or where you need stronger fraud protection. It typically includes scanning a government ID and a quick liveness check to confirm the document belongs to the traveller.

Q2: Do all countries require eKYC for eSIM? A2: No. Requirements vary by country and plan type. Several EU and APAC markets require registration; others, such as parts of the United States, typically do not. Check plan pages like Esim United States and regional bundles such as Esim Western Europe for local notes.

Q3: How long should we keep KYC images? A3: Keep them only as long as needed to satisfy local rules and operational needs. Many partners aim for 90 days to 12 months, deleting images once verification is final and retaining only a decision token or hash. Always separate image retention from billing/tax record retention.

Q4: What network data is retained about travellers? A4: Operational metadata such as activation timestamps, session start/stop times, and aggregated data volumes. Content of communications is not retained. Typical retention ranges from 6 to 12 months, subject to local law and support requirements.

Q5: How is GDPR handled when serving multi‑region travellers? A5: Apply GDPR principles by default: minimisation, clear purposes, storage limitation, strong security, and proper transfer safeguards (e.g., SCCs). Host EU data in the EEA/UK when possible, and use contractual and technical measures for any transfers.

Q6: Can previous eKYC be reused for repeat purchases? A6: Often, yes. If regulations allow, store a tokenised verification result and reuse it for future activations (e.g., moving from Esim North America to Esim United States), avoiding another document capture. Respect market‑specific rules and set an expiry for reuse.

Next step: Access implementation guides, sample DPAs, and integration support via the Simology Partner Hub.

Getting eSIM billing right isn’t just about taking payments—it’s about trust, compliance, and clarity for travellers and partners at scale. This guide covers the practical building blocks of esim vat invoicing multi currency operations: how to handle VAT/Sales Tax by region, present FX cleanly, calculate pro‑rations fairly, and run refund, chargeback, and dunning flows that reduce friction. Whether you’re a marketplace, reseller, MNO/MVNO, or travel brand, the goal is the same: ship fast, stay compliant, and keep customer effort low. We’ll walk through usable checklists and decision points, and point to where Simology supports your commerce stack—across destinations like Esim Western Europe, Esim North America, and single‑country packs such as Esim United States, Esim France, Esim Italy, and Esim Spain. For partnership options and operational tooling, see For Business and our Partner Hub.

Why billing precision matters for eSIM at scale

• Tax compliance varies by region and buyer type. Poor handling risks fines or blocked payouts.
• Travellers expect local currency clarity and transparent FX—especially when buying on the move.
• Pro‑rations and top‑ups must feel fair; opaque maths is a refund magnet.
• A clear refund and chargeback playbook minimises losses and disputes.
• Strong dunning keeps B2B/wholesale cashflow healthy without harming relationships.

VAT invoicing essentials for eSIM providers and partners

Identify tax nexus by region

• EU/UK: B2C digital services are typically VATable where the customer is located; B2B may use reverse charge if a valid VAT number is provided.
• US/Canada: Sales tax/GST/HST/PST rules vary by state/province and product classification; marketplace vs. seller of record impacts liability.
• APAC/ROW: Several countries operate VAT/GST on digital services to local consumers. Thresholds and registration rules differ.

Note: Always validate assumptions with your finance team and align seller‑of‑record responsibilities in partner contracts.

Data you must capture on a VAT‑compliant invoice

• Seller legal name, address, and tax registration (e.g., VAT ID).
• Buyer details; collect VAT number for B2B where applicable.
• Unique invoice number, issue date, supply date (if different).
• Line items: product name (e.g., “eSIM 5 GB – France”), quantity, unit price, discounts.
• Tax rate and amount per line, and total tax.
• Currency of account and any FX conversion basis.
• Notes: reverse charge wording (when applicable), credit note references for refunds.

Step‑by‑step: Configure VAT and invoice rules

1. Define seller‑of‑record per market and channel (direct vs. reseller).
2. Configure tax determination: by billing address, IP/geo, payment BIN, or combined evidence.
3. Set B2B logic: VAT number capture, real‑time validation, and reverse charge handling.
4. Attach tax codes to catalogue SKUs by region (e.g., EU digital service vs. US telecom).
5. Generate VAT invoices on payment capture; issue credit notes on refunds.
6. Store signed PDFs plus machine‑readable data (e.g., CSV/JSON) for audit.
7. Provide travellers with self‑serve invoice downloads via order history.

Pro tip: When selling cross‑border packs like Esim Western Europe, ensure your SKU structure supports per‑buyer tax determination even if the product spans multiple countries.

Multi‑currency pricing and FX display that customers trust

Display vs settlement currency

• Display currency: what the shopper sees at checkout (e.g., EUR, GBP, USD, CAD).
• Settlement currency: what your gateway pays out in (often USD or EUR).
• Show the display currency by user location or browser currency, but disclose when settlement occurs in a different currency.

Pro tip: Present a single total in the shopper’s local currency with tax included for B2C. For B2B, show net, tax, and gross with the buyer’s VAT status clearly flagged.

Rounding, fees, and rate sources

• Use a consistent FX source (e.g., daily mid‑market rate plus a disclosed margin).
• Round prices to local conventions (e.g., .99, or 0.05 increments where applicable).
• Clearly disclose any FX mark‑up and that the card issuer may apply additional conversion fees.

Step‑by‑step: Implement multi‑currency in your checkout

1. Detect preferred currency from locale and BIN, allow manual override.
2. Convert base prices using your rate source and cache rates for the day.
3. Compute taxes in the display currency; track base currency equivalents for accounting.
4. Apply rounding rules per currency; store pre‑ and post‑round values.
5. Show a plain‑English FX note (e.g., “Billed in USD; amounts shown in EUR for your reference” where relevant).
6. Reconcile settlements: map PSP payouts in the settlement currency back to order‑level FX snapshots.

Pro tip: Keep the FX snapshot (rate ID, timestamp, margin) on each order to simplify refunds and audits.

Pro‑rations, expiries, and top‑ups

Common scenarios and calculations

• Mid‑cycle upgrade to a larger data pack: charge a pro‑rated difference based on remaining days or unused data value.
• Early cancellation (goodwill): offer a pro‑rated credit note based on unused data/validity.
• Auto‑renewal cancellations before renewal date: no proration; ensure clean cancellation messaging.
• Top‑ups: treat as separate SKUs with their own tax rules; avoid recalculating tax on the original order.

Two pro‑ration models - Time‑based: Value remaining = price × (days remaining ÷ total days). - Usage‑based: Value remaining = price × (unused data ÷ total data).

Pro tip: Pick one model per product family and document it in the checkout and invoice notes to avoid disputes.

Refund and chargeback flows that reduce friction

Refund policy matrix

• Technical failure (e.g., profile never delivered/activated): full refund.
• Partial usage but network issues verified: partial refund or goodwill credit.
• Buyer error (wrong device/region) with no usage: one‑time goodwill refund to reduce chargeback risk.
• Fraud or card testing: block and no refund; share device/usage fingerprints with your PSP.

Always issue a credit note matching the original tax treatment and currency.

Step‑by‑step: Process a refund

1. Verify eligibility: review activation logs, usage, and support notes.
2. Select type: full, partial (amount or percentage), or voucher credit.
3. Calculate tax reversal: mirror original tax rate and FX snapshot.
4. Create credit note linked to the original invoice; include reason code.
5. Execute refund via PSP in the original payment method and settlement currency.
6. Notify the customer with clear timelines (e.g., “3–10 business days depending on bank”).

Pro tip: For travellers buying local packs like Esim France or Esim United States, add geo‑tips in the confirmation email (device compatibility, APN steps). Fewer setup issues mean fewer refund requests.

Chargeback playbook

• Prevention
• Strong descriptor: include “Simology eSIM” and support URL.
• 3‑D Secure where available; AVS/CVV checks and velocity rules.
• Pre‑delivery device checks (e.g., eSIM capability).
• Evidence for representment
• Order details, IP/device fingerprint, and BIN country match.
• Delivery proof: eSIM QR/profile delivered timestamp.
• Usage logs (data session started), and T&Cs acceptance.
• Customer communications and refund policy shown at checkout.
• Triage
• Low‑value/high‑cost disputes: consider concession.
• High‑value/clear evidence: proceed to representment with focused docs.
• Post‑mortem
• Update fraud rules (e.g., block risky BIN ranges, disposable emails).
• Feed learnings into support macros and checkout copy.

Pro tip: Create reason‑code playbooks (e.g., “product not received” vs. “fraudulent”). Standardise the evidence pack to submit within 48 hours.

Dunning and collections for B2B and wholesale

Practical timeline and comms

• Day 0: Invoice issued with net terms (e.g., Net 14/30). Include payment link, bank details, currency, and tax breakdown.
• Day 3 before due: Friendly reminder with statement of account.
• Day 0 due: Notice with next steps and escalation path.
• Day 7 overdue: Second reminder; offer card-on-file as a fallback.
• Day 14–21 overdue: Account manager call; agree a payment plan.
• Day 30+: Suspend non‑critical benefits (marketing funds, new activations) while preserving active travellers where possible.

Pro tip: For resellers sourcing regional packs like Esim North America or Esim Western Europe, suspend new order creation before disabling existing lines to avoid traveller impact.

Risk controls and suspension logic

• Credit limits per partner; auto‑adjust based on payment history.
• Collateral or prepayment for new partners until two clean cycles.
• Grace windows for active travellers; offer top‑up vouchers funded from security deposit if needed.
• Automated dunning across email + portal banners; keep comms factual and friendly.

Regional nuances to watch

• EU/UK: Display VAT‑inclusive prices for consumers. If a B2B buyer enters a valid VAT number, apply reverse charge and show required wording on the invoice.
• US: Product taxability differs by state; telecom vs. digital service classification can change rates. Marketplace facilitator laws may shift liability.
• Canada: GST/HST/PST mix varies by province; register thresholds apply.
• Travellers often buy in one country for use in another (e.g., purchase from the UK for Esim Spain). Determine tax based on customer location rules, not the visited country, unless local laws require otherwise.
• Multi‑country bundles: Use consistent SKUs tied to the buyer’s location for tax, not each covered country.

Pro tip: Keep your plan catalogue aligned with geo coverage on Destinations so tax and pricing logic stays in sync with what travellers actually buy.

Reporting, reconciliation, and audits

Daily reconciliation checklist

• Match orders to payments: amount, currency, fees, settlement date.
• Verify tax amounts by jurisdiction and product SKU.
• Confirm invoice and credit note sequences are gap‑free.
• Review refunds vs. payouts; reconcile FX differences to a gain/loss account.
• Surface anomalies: negative margin orders, duplicate refunds, or out‑of‑policy credits.

Export formats and storage

• Provide CSV/JSON exports per day/week with:
• Order ID, SKU, region, buyer type (B2B/B2C), FX rate used.
• Net, tax, gross, currency, settlement currency, fees.
• Invoice/credit note numbers and links.
• Retain PDFs and raw data per statutory timelines; ensure timezone consistency across logs.

Pro tip: Store an immutable “tax calc snapshot” per order so later tax engine changes don’t alter historical documents.

Quick setup checklist (save this)

• Define seller‑of‑record per channel/region.
• Map tax codes per SKU and integrate VAT number validation.
• Implement display currency with clear FX notes; keep settlement currency stable.
• Choose a single pro‑ration model and document it.
• Automate credit notes for refunds; mirror original tax and FX.
• Build a reason‑coded chargeback pack and a 30‑day dunning cadence.
• Reconcile daily; export audit‑ready tax and payout data.

FAQ

Q1: How should I handle VAT for B2B eSIM sales in the EU/UK? A: Collect and validate the buyer’s VAT number at checkout. If valid, apply reverse charge and include the correct wording on the invoice. If not, charge VAT as for B2C. Keep the validation result with the order.

Q2: Can I show prices in multiple currencies but settle in USD or EUR? A: Yes. Use a stable settlement currency operationally, show shopper‑friendly display currencies, and disclose the settlement currency and any FX margin. Keep the FX snapshot per order for refunds and audits.

Q3: What’s the fairest way to calculate partial refunds on data packs? A: Pick one method and be consistent. Time‑based works well for validity‑driven plans; usage‑based suits metered data. Mirror the original tax and FX when issuing the credit note.

Q4: How do I reduce “product not received” chargebacks? A: Send a post‑purchase email with device compatibility checks, clear activation steps, and support links. Keep delivery logs of the eSIM profile and show your refund policy at checkout. For country packs like Esim Italy, add country‑specific APN tips.

Q5: What should a VAT invoice include for eSIM? A: Seller and buyer details (including VAT IDs), unique invoice number, dates, line‑item prices, tax rates and amounts, totals, currency, and any reverse charge text. Issue credit notes for any refunds.

Q6: How should dunning work for wholesale partners? A: Use a clear cadence (reminders before and after due), offer multiple payment methods, set credit limits, and suspend new activations before impacting existing travellers. Manage it via your partner portal—see our Partner Hub.

Next step: Build a compliant, traveller‑friendly billing stack with Simology—start here: For Business.

Mobile data isn’t just “internet in your pocket.” For enterprises with roaming staff, payment terminals, or IoT fleets, the path your traffic takes is a security control. A private APN creates a closed data path from SIMs to your network, letting you enforce policy, isolate traffic from the public internet, and integrate cleanly with VPNs or zero-trust tools. This guide explains what private APNs are, when to use them, how they work with VPNs, typical use cases, what they cost, and how to deploy successfully—without jargon.

If your teams travel, the stakes go up: roaming adds new networks, new attack surfaces, and variable policies. A well-designed private APN keeps device traffic predictable and governable across borders. Whether you’re connecting laptops via eSIM, securing field equipment across Esim Western Europe, or building a partner-ready solution via our Partner Hub, the right APN choice determines how easily you can meet audit, compliance, and uptime targets.

Use this as a practical checklist to decide if a private APN fits—and how to keep costs and complexity under control.

What is a Private APN?

A private APN (Access Point Name) is a carrier-side configuration that defines how SIM traffic is handled. Rather than breaking out to the public internet using NAT on a generic, shared APN, a private APN:

• Identifies your SIMs into a dedicated routing context
• Assigns private/static IP ranges if required
• Applies custom firewall, DNS and content policies
• Delivers traffic to you over a defined path (e.g., IPsec/GRE to your DC/cloud)

Think of it as “your own lane” inside the mobile core, with enterprise-grade traffic isolation and policy controls.

Key benefits

• Traffic isolation: Your devices don’t share a public NAT pool with everyone else.
• Predictable addressing: Private or static IPs allow IP allowlisting and system-to-system integrations.
• Policy enforcement: Apply DNS filtering, firewall rules, and segmentation per SIM group.
• Controlled breakout: Choose where traffic exits—your data centre, cloud VPC, or a regional gateway.

Common variants

• Private APN with public breakout: Policy and IP control, but final internet egress is via carrier NAT.
• Private APN with private breakout: End-to-end private path to your network over IPsec/GRE/MPLS; no public internet until you decide.
• Roaming home routing vs local breakout: Decide whether traffic tunnels back to a home gateway or breaks out regionally for latency/compliance.

When should you use a Private APN?

Choose a private APN when one or more of these apply:

• You must IP-allowlist mobile devices to access corporate apps, SCADA, or payment backends.
• You need to block open internet access by default, allowing only approved destinations.
• You require consistent, auditable logs of device egress and DNS activity.
• You deploy IoT/OT fleets where devices are headless and should never be internet-reachable.
• You need static or reserved IPs per SIM for device-to-cloud rules or legacy systems.
• You’re operating in higher-risk or compliance-heavy sectors (finance, health, critical infrastructure).

Travel scenarios where it shines:

• Regional workforces moving between the US, Canada and Mexico using Esim North America
• Teams rotating across France, Italy and Spain with Esim France, Esim Italy and Esim Spain
• Short-term projects needing fast onboarding in the US via Esim United States

Check your target countries and carriers via Destinations.

Private APN vs VPN vs Zero Trust

These are complementary, not either/or.

• Private APN: Carrier-layer isolation and policy. Ensures trusted device identity (SIM/IMSI), private addressing, and controlled gateways.
• VPN (IPsec/GRE/SSL): Secure tunnel from APN gateway to your network or cloud VPC. Use to terminate traffic into your security stack.
• Zero Trust/SASE: Identity-driven access per user/device/app. Often layered on top (device certificate, posture checks) for user devices.

Recommended patterns

• Corporate laptops/phones on the road
• Private APN + clientless approach: Route all traffic via your gateway where CASB/SWG runs.
• Or Private APN + device VPN: Enforce split tunnel for corporate apps; APN blocks all other internet.
• IoT/OT equipment
• Private APN with private breakout to your VPC/DC; no public internet access.
• Partners/contractors
• Private APN with segmented SIM groups and per-segment firewall policies; issue time-bound SIMs.

Pro tips: - Avoid double encryption where unnecessary. If APN-to-cloud IPsec is in place and devices only talk to your internal services, you may not need device-level VPN. - Use device certificates via MDM/EMM for user hardware. The APN identifies the SIM; your MDM identifies the device.

Security controls you actually get

• Identity and segmentation
• SIM/IMSI-based policies and groups
• Optional IMEI binding for device lock
• Addressing
• Private RFC1918 subnets, with optional static IPs per SIM
• CGNAT or 1:1 NAT as needed
• Firewalling
• Default deny; allow only required FQDNs/IPs/ports
• Geo or ASN-based controls for sensitive backends
• DNS
• Force safe resolvers; block DNS-over-HTTPS egress
• Use internal resolver via tunnel for split-horizon domains
• Logging and SIEM
• Per-SIM flow logs and DNS logs exported to your SIEM
• DDoS posture
• With private breakout, you decide internet egress; with public breakout, leverage carrier scrubbing

Roaming and travel: what to plan for

• Latency vs control
• Home routing centralises control but adds RTT from, say, Tokyo to a London gateway.
• Regional breakout (e.g., EU vs US gateways) reduces latency for users on Esim Western Europe or Esim North America.
• Regulatory constraints
• Some countries restrict VPN or enforce local breakout. Match your APN design to the route permitted in the destination. Confirm on Destinations.
• IP allowlists and roaming IPs
• If you rely on static source IPs, avoid scenarios where roaming uses dynamic CGNAT or changes egress country by country. Private breakout fixes this by presenting consistent IP space.
• Device onboarding during travel
• eSIM QR provisioning helps. Pre-stage profiles for each region (e.g., Esim France for an EU tour, Esim United States for US trips).

Cost model: what you’ll actually pay

Expect costs in these buckets:

• One-off setup
• APN configuration, IP ranges, SIM group policies, initial tunnel(s)
• Monthly platform fee
• Covers APN gateway capacity, monitoring, and management
• Per-SIM charge
• Often tiered; sometimes includes static IP options
• Data usage
• Pooled or per-SIM; roaming may have regional rates
• Tunnels and hosting
• IPsec/GRE tunnel endpoints in your DC/VPC; cloud egress costs may apply
• Change management/professional services
• Policy updates, incident support, new region gateways

Ways to optimise: - Start with a private APN + public breakout for policy control; add private breakout later for critical apps. - Use regional gateways to avoid transatlantic hairpin data charges for travellers. - Reserve static IPs only for systems that truly need allowlists; use dynamic private IPs elsewhere. - Monitor top talkers; block chatty apps at APN firewall instead of paying for unnecessary data.

Quick decision checklist: do you need a private APN?

Tick “yes” if the statement is true:

• We must restrict mobile devices from open internet by default.
• We rely on IP allowlists for any critical app or third-party API.
• We need device fleet observability (per-SIM traffic and DNS logs).
• We operate IoT or unattended devices that should never be publicly reachable.
• We have travellers across multiple regions and require consistent egress policies.
• We must meet compliance or audit requirements for network segregation.

Three or more “yes” answers usually justify a private APN.

Implementation: step-by-step

1) Define scope and risk - List device types (laptops, phones, IoT), users, and data sensitivity. - Map apps/domains/ports that must be reachable. - Decide “deny-by-default” vs “allow-by-default”.

2) Choose coverage and form factor - Confirm countries and networks via Destinations. - Select regional plans (e.g., Esim North America or Esim Western Europe) and country add-ons (Esim Italy, Esim Spain).

3) Addressing and segmentation - Allocate private subnets per SIM group (e.g., staff vs IoT). - Decide where static IPs are required.

4) Breakout architecture - Start with private APN + public breakout if you only need policy/DNS controls. - For maximum control, deploy private breakout to your DC/cloud via IPsec/GRE. - If latency matters for travellers, request EU and US gateways.

5) Security policy and DNS - Set default deny; allow only business apps/domains. - Enforce DNS to your resolvers; block DoH/DoT egress except approved endpoints. - Add geo/ASN blocks for risky destinations if relevant.

6) Integrate identity and device posture - Bind SIMs to users via MDM/EMM; consider IMEI binding for corporate-owned devices. - For user devices, layer device certificates or ZTNA for application-level control.

7) Build and test tunnels - Establish redundant tunnels; validate failover. - Test roaming from target countries (US/EU) for latency and policy correctness.

8) Logging, monitoring, and alerts - Export flow and DNS logs to SIEM. - Create alerts for policy violations and unusual data volumes.

9) Pilot and scale - Pilot with 10–50 users/devices across two regions. - Iterate rules, then scale to full fleet.

Pro tips: - Test common collaboration apps (Teams/Zoom) for split vs full tunnel to avoid performance complaints. - Document emergency bypass processes for critical field operations.

Common pitfalls (and how to avoid them)

• IP allowlists failing during roaming
• Use private breakout with consistent source IPs; avoid reliance on roaming CGNAT ranges.
• DNS leaks
• Force DNS to your resolver; block outbound UDP/TCP 53/853 except to approved IPs; manage DoH with SNI filtering.
• Overly broad “allow” rules
• Prefer FQDN and minimal port ranges; segment by SIM group.
• Latency surprises
• Place gateways regionally; verify RTT from your top travel corridors.
• Tunnel single points of failure
• Always build at least two tunnels to independent endpoints.

Who is this for?

• Enterprises securing roaming staff devices with eSIM
• Payments, logistics, and field services managing unattended endpoints
• MSPs/ISVs embedding connectivity into their solutions via our Partner Hub
• Organisations looking for turnkey policies and global eSIM bundles via For Business

FAQ

Q1: What is the main difference between a public and a private APN?
A private APN creates an isolated routing context for your SIMs with custom policies and addressing. Public APNs use shared NAT to the internet with limited control and no dedicated security posture.

Q2: Do I still need a VPN if I use a private APN?
Often yes, but it depends. For IoT or tightly controlled fleets, APN-to-cloud IPsec may be sufficient without device VPN. For user devices, a device VPN or ZTNA provides identity and app-level control on top of the APN.

Q3: Can I get static IPs for my SIMs?
Yes. Private APNs can assign static or reserved private IPs per SIM, which is ideal for IP allowlisting and legacy integrations. Public static IPs are possible but less common; many use private breakout and egress via corporate firewalls.

Q4: Will a private APN work while roaming internationally?
Yes. Design for either home routing (all traffic returns to your gateway) or regional breakout (e.g., EU/US). This affects latency and compliance—verify coverage per country on Destinations.

Q5: How much does a private APN cost?
Expect a setup fee, a monthly APN platform charge, per-SIM pricing (optionally for static IPs), data usage, and tunnel/cloud costs. You can start small with policy-only public breakout, then add private breakout and regional gateways as needs grow.

Q6: Does this support eSIM and multi-region bundles?
Yes. Private APN policies apply to both physical SIMs and eSIMs. For travellers, pair your APN with regional plans like Esim Western Europe or Esim North America and country-specific options such as Esim France or Esim United States.

Next step

Design the right private APN for your fleet and travel patterns. Speak to our enterprise team via For Business to scope coverage, security policies, and rollout.

Enterprises want travel-ready devices that “just work” the moment staff land. The trick is marrying modern eSIM provisioning with your MDM so you can control cost, security, and user effort. This guide shows practical mdm esim deployment patterns that scale across Jamf (Apple), Intune (iOS and Android), and Samsung Knox. We’ll cover enrolment flows that minimise user taps, profile locking to stop accidental deletions, dual‑SIM policies that split work vs personal usage, and roaming presets for fleets moving between regions. You’ll also find checklists and pro tips that reduce support tickets and bill shock.

We assume your organisation provides work devices for travel, or supports COPE/CYOD where personal lines coexist with corporate data. Use this as a blueprint to pilot, then operationalise. For region planning, see our coverage library across Destinations, including ready-to-deploy options for Esim United States, Esim France, Esim Italy, Esim Spain, Esim Western Europe, and Esim North America.

What you can and can’t automate today

Before designing flows, acknowledge current platform realities:

• Silent eSIM install is limited. On iOS and standard Android Enterprise, fully silent eSIM download/activation is generally not available to third‑party MDMs. Users usually scan a QR or paste an activation code (SM‑DP+ address and code).
• MDM excels at governance. You can lock who can add/remove plans, steer which SIM handles data, and preconfigure roaming behaviours (especially on Samsung via Knox).
• Multiple eSIM profiles can be stored. Most recent iPhones and Androids can hold several eSIMs, with one active for data at a time. This enables preloading per-region profiles.
• The right pre-provisioning removes friction. If you deliver the code securely, guide the user at enrolment, and then lock settings, day‑one travel becomes smooth.

Core building blocks for mdm esim deployment

• Activation methods:
• QR code scan (most common, fastest for users).
• SM‑DP+ server and activation code entered manually.
• Carrier/eSIM app deep-link (opens to a prefilled code; still user-confirmed).
• Ownership and enrolment models:
• COBO (corporate-owned, business-only): strongest control, ideal for travel pools.
• COPE/CYOD: align dual‑SIM policies to separate work data (eSIM) and personal voice (physical SIM).
• Automated Device Enrolment (Apple) / Zero-touch (Android) for day‑0 governance.
• Lifecycle states:
• Download, enable for data, set data roaming, lock modifications, suspend or remove post‑trip.
• Policy pillars:
• Profile locking (prevent removal/changes).
• Dual‑SIM defaults (data on eSIM; personal SIM voice only).
• Roaming presets (country/region-based switching and controls).

Cross‑platform baseline policy pack (start here)

Apply these controls in Jamf, Intune, and Knox (where supported):

1) Restrictions and lock‑down - iOS/iPadOS: Disable “Modify eSIM/cellular plan” in Restrictions payload (Jamf and Intune support this). This prevents deleting or adding plans after deployment. - Android Enterprise (fully managed): Disallow mobile network configuration changes. Use OEMConfig/Knox to enhance this on Samsung. - Optionally disable hotspot if you fund only device use, not tethering.

2) Secure delivery of activation details - Store and distribute SM‑DP+ and activation codes via: - Jamf Self Service item or Intune Company Portal page. - A managed app with AppConfig (codes scoped per user/group). - Conditional access for off-network users via VPN or Microsoft Tunnel.

3) Dual‑SIM governance - Communicate the standard: “eSIM = work data; physical SIM = personal voice/text.” - Enforce default data SIM and block data on the personal SIM where the platform allows (Knox can enforce; iOS typically requires user confirmation guided by Self Service).

4) Roaming controls - iOS: you cannot programmatically toggle Data Roaming on/off; provide in-app guidance and compliance notifications. - Samsung via Knox: set data roaming per region profile; lock the user toggle if you need strict cost control.

5) Observability and support - Use a managed data-usage app or network analytics to alert at thresholds. - Create device groups per destination; push correct eSIM profile and instructions before travel.

Pro tip: Pre-provision multiple regional eSIMs (e.g., Esim Western Europe plus Esim United States) on eligible devices; switch the active data line just before travel.

Jamf patterns for iOS/iPadOS

Recommended enrolment flow (ADE)

• Use Apple Business Manager with Automated Device Enrolment to drop users into Jamf out of the box.
• During Setup Assistant, restrict “Cellular Plan” modifications via a configuration profile pushed immediately after enrolment.

Day‑0 “self‑serve” eSIM installation

1) Scope a Jamf Self Service item named “Activate Work Travel eSIM”. 2) Present country/region options mapped to your travel catalogue (e.g., Esim France, Esim Italy, Esim Spain, or broader Esim North America). 3) On selection, reveal the QR or invoke a deeplink to your eSIM provider’s install URL (still user‑approved). 4) After installation, prompt the user to: - Set the eSIM as “Mobile Data” line. - Keep personal SIM for “Default Voice Line” (if COPE). - Enable Data Roaming if travelling out of their home network.

5) Post‑install, Jamf immediately re‑applies the restriction to prevent further eSIM changes.

Pro tips: - Use Jamf Smart Groups based on upcoming travel to target the correct instructions and codes. - Embed a 30‑second video or step‑by‑step within Self Service; it reduces support tickets dramatically.

Pre‑travel top‑ups and seasonal switches

• Create Self Service policies “Enable EU Data” and “Enable US Data”.
• Each policy reveals the relevant QR/code and a short checklist for the user to switch the Mobile Data line.
• Re-lock eSIM modifications after the switch.

Dual‑SIM policy on iOS

• You cannot currently force default data line via MDM on iOS; instead:
• Provide a one-screen Self Service guide with screenshots.
• Use an in-app confirmation (“I’ve set eSIM for data”) to mark the device compliant and suppress reminders.
• Restrict eSIM modification to keep the work plan intact.

Microsoft Intune patterns (iOS and Android)

Enrolment and scoping

• iOS/iPadOS: Enrol through Company Portal or ADE; apply the iOS device restriction to block eSIM modifications post‑install.
• Android Enterprise:
• COBO: Fully Managed is best for travel pools.
• COPE: Work Profile on company‑owned gives balance but fewer network controls; consider Samsung + KSP for more power.

Delivering eSIM details securely

• Use Intune to publish a Company Portal resource “Install Work eSIM” scoped by Azure AD groups (e.g., “Travel_EU_Q4”).
• Optionally deliver codes via a managed app using AppConfig so they never appear in email or chat.
• For high-risk destinations, require VPN before revealing the code.

Enforcing dual‑SIM and roaming (Android)

• With Samsung devices, deploy the Knox Service Plugin (KSP) via Intune’s OEMConfig:
• Set preferred SIM for mobile data to eSIM.
• Disable data on physical SIM (voice/text unaffected).
• Toggle and lock Data Roaming per region profile (e.g., allow in EU, block elsewhere).
• For non‑Samsung Android, use available Android restrictions to limit user changes; depth varies by OEM.

Pro tip: Maintain device groups per region and travel window. When a user is added to “Travel_US_Nov,” Intune auto-publishes the Esim United States resource, applies KSP roaming settings (if Samsung), and sends a single push prompting installation.

Samsung Knox deployment patterns (Knox Manage or Intune + KSP)

Samsung offers the deepest cellular controls for Android Enterprise:

• Preferred data SIM: Force eSIM as the data line and keep personal SIM for voice/SMS.
• Data Roaming control: Allow/block and optionally hide the toggle from users to prevent drift.
• Mobile networks UI restrictions: Prevent users from adding/removing profiles or altering APNs.
• APN fine‑tuning: Rarely needed with eSIM, but useful for private APN cases.

Typical flow (COBO travel handset): 1) Zero‑touch enrol into Knox Manage or Intune DO. 2) Push KSP with a “Home” profile (roaming off, data on eSIM, tethering off). 3) Before travel, switch to a “Destination” profile (roaming on, data on eSIM, usage alerts). 4) Distribute the eSIM activation QR via Knox E-FOTA notification or Intune Company Portal. 5) Lock network settings post‑install.

Pro tip: Pair KSP roaming policies with a data-usage app that shows per‑SIM consumption. Users understand what’s going on, and you stay ahead of overages.

Roaming presets for fleets

Build a small library of policy + plan bundles:

• Western Europe bundle:
• eSIM: Esim Western Europe
• Policy: Data roaming on; personal SIM data off; hotspot allowed for field teams if needed.
• Guidance: Remind users to choose eSIM for data on arrival.
• North America bundle:
• eSIM: Esim North America or country‑specific Esim United States
• Policy: Roaming on; push time‑zone and dialling tips; enable Wi‑Fi Assist guidance if required.
• Country‑specific bundles:
• France/Italy/Spain with Esim France, Esim Italy, Esim Spain
• Policy: Standard dual‑SIM rules; translate quick-start steps for local teams if necessary.

Preload multiple profiles (where devices support it) so frequent travellers only switch the active data line in Settings. Reference coverage and plan validity on Destinations when planning trips.

Operational playbooks

• COBO travel pool devices
• Device state: Fully managed (Jamf ADE / Intune DO / Knox Manage).
• Install method: QR in a managed portal with a 60‑second guide.
• Lockdown: Block eSIM modifications; hide roaming toggles (Samsung).
• Offboarding: Remove or disable the travel profile after return (user‑assisted).
• COPE (personal SIM + corporate eSIM)
• Device state: Jamf or Intune with clear Self Service instructions.
• Policy: eSIM for data; personal SIM voice/SMS. Restrict personal SIM data (Samsung) or provide guidance (iOS).
• Privacy: Communicate what is and isn’t monitored; keep trust high.
• Frequent-flyer executives
• Preload EU + US eSIMs; give a one‑tap Self Service checklist “Switch Data to EU/US”.
• Provide a wallet card or offline PDF with steps for when they land without data.

Troubleshooting quick checks (field-proven)

• eSIM not downloading? Confirm device is unlocked, on Wi‑Fi, and date/time is automatic.
• No data after install? Ensure the eSIM is selected as the Mobile Data line and Data Roaming is on outside the home network.
• Dual‑SIM confusion? Rename lines (e.g., “Work eSIM” and “Personal SIM”) in Settings to reduce mistakes.
• Poor performance? Toggle Airplane Mode for 10 seconds; then check network selection is automatic.
• Stuck policy? Force an MDM sync (Jamf: Self Service “Update Inventory”; Intune: Company Portal “Check status”).

FAQs

• Can MDM silently install an eSIM profile?
• Generally no on iOS and standard Android. Expect a user‑confirmed QR scan or code entry. Build your flow to make that step quick and clear.
• How do I stop users deleting the work eSIM?
• iOS/iPadOS: Disable eSIM/cellular plan modifications via MDM Restrictions.
• Android: Use Device Owner restrictions; on Samsung, enforce additional SIM/network policies via Knox.
• Can I enforce that work data uses the eSIM and personal SIM is voice only?
• Yes on Samsung via Knox (preferred data SIM, disable personal SIM data).
• On iOS, you’ll guide users to set eSIM as the data line and then lock plan modifications.
• Can I turn Data Roaming on/off with MDM?
• Samsung via Knox: yes, including hiding the toggle.
• iOS: not programmatically; provide clear user prompts at install and arrival.
• How many eSIMs can a device store?
• Modern iPhones and Androids can store multiple eSIM profiles, with one active for data. Exact limits vary by model. Preload frequent destinations and switch as needed.
• What’s the best way to support travellers landing without data?
• Provide QR codes that work over hotel/airport Wi‑Fi, offline quick-start steps in Self Service, and a short SMS template they can send from their personal SIM to get help.

Next step

Ready to pilot mdm esim deployment with proper policy controls? Share your route map and device mix with our enterprise team via For Business. We’ll help you design enrolment flows, locking, dual‑SIM policies, and region bundles that scale.

Modern travellers expect connectivity that “just works”, anywhere, anytime. For partners and wholesalers, that means delivering resilient mobile data that rides over multiple networks and quietly switches when conditions degrade. Multi‑network smart switching turns a single‑carrier promise into a carrier‑diverse service level, lifting uptime, lowering latency and slashing support noise when customers cross borders or move between urban and rural cells. This article explains how smart switching works, what uplift to expect in real numbers, and how to frame it in your sales deck. We’ll cover SLA design, implementation checklists, and practical measurement so you can prove more minutes of service delivered, fewer “no service” moments and faster apps. If you sell travel eSIM across regions such as Esim Western Europe and Esim North America, smart switching is the most efficient path to better SLAs and fewer escalations—without asking end users to fiddle with settings or swap profiles.

What is multi‑network smart switching?

Multi‑network smart switching is a policy‑driven capability embedded in the SIM/eSIM stack that selects the best available network at any moment, based on real‑time quality signals such as:

• Radio availability and signal quality
• Attach success/failure and PDP/PDN session stability
• Latency to key targets (e.g., DNS, CDN edges)
• Packet loss and jitter
• Commercial rules (whitelists/blacklists, cost ceilings, fair use)

Instead of pinning a device to a single carrier, your eSIM has access to multiple MNOs/MVNOs in each country. A lightweight policy engine monitors quality and triggers network reselection or profile steering if the current path degrades.

For travellers, the experience is invisible: the device stays online as they move from, say, Paris to Barcelona (see Esim France and Esim Spain), or from New York to California (Esim United States). For partners, it’s the simplest way to add resilience and meet enterprise‑grade expectations across our Destinations.

Why smart switching matters for SLAs

Quantifying uptime uplift

If you rely on a single network with 99.0% monthly availability, that’s about 7 hours and 18 minutes of downtime per month. With access to two independent networks of similar quality, the combined availability approaches:

• Combined availability ≈ 1 − (1 − A1) × (1 − A2)
• Example with A1 = 0.990 and A2 = 0.990 → 1 − 0.01 × 0.01 = 99.99%

Real‑world failures are not perfectly independent (storms, fibre cuts, or national outages can hit multiple networks), so a conservative planning assumption is:

• Single‑network monthly downtime: 200–450 minutes (varies by market granularity)
• Dual/triple‑network smart switching downtime: 5–30 minutes
• Practical uplift: 10× to 40× less downtime, translating into 99.95%–99.99% delivered availability

Even a modest two‑network design with correlated risks typically lifts availability from 99.0–99.5% to 99.95%+. Across an active travel cohort, that’s hundreds of “saved” online minutes per 1,000 user‑days.

Latency and app performance

Choosing the lowest‑latency path matters for cloud apps, maps and messaging. Smart switching prefers networks with:

• Local or regional breakout rather than home‑routed traffic
• Healthier peering to major CDNs and collaboration suites
• Lower radio congestion in the moment

Observed results partners can expect:

• EU intra‑region p95 latency improvements of 20–40% when switching to a better‑peered MNO (e.g., from 120–160 ms to 70–110 ms)
• Within the US, p95 latency reductions of 15–30% by avoiding congested areas or leveraging a stronger regional carrier
• 10–25% reduction in time‑to‑first‑byte for common mobile web flows

For many travel use cases, perceived speed is as valuable as raw throughput. Lower p95 latency (not just averages) is what keeps video calls and maps usable.

Support ticket reduction

Most travel connectivity tickets cluster into a few buckets:

• No service / can’t attach
• “Data is slow”
• Intermittent drops
• APN/profile confusion

Smart switching prevents the first three by auto‑moving away from bad cells, degraded cores or poorly performing peering. Typical reductions once deployed:

• 30–50% fewer “no service” tickets
• 20–35% fewer “slow data” tickets
• 40–60% drop in intermittent dropouts, especially at cell edges and transit hubs

Fewer incidents means lower support cost per account and happier travellers—reflected in higher CSAT/NPS.

How smart switching works in practice

• Multi‑MNO access per country: eSIM profiles grant access to multiple carriers in markets covered by products such as Esim Western Europe, Esim North America, and country packs like Esim Italy.
• Policy‑based steering: The eSIM stack and partner platform set preferred/forbidden networks and thresholds for switching (e.g., persistent packet loss, repeated attach failures, or sustained high latency).
• Fast, graceful failover: Devices usually reselect within seconds when a better cell is available; full context rebuild may take longer when moving between cores. End users typically experience a brief blip rather than an outage.
• Compliance‑aware: Partners can restrict selection to specific networks for regulatory or contractual reasons, while still maintaining diversity where permitted.

Note: switching behaviour can vary by device OS and modem firmware. Always include device diversity in your test plan.

Designing a multi network switching SLA

A robust multi network switching SLA should define:

• Coverage scope: Countries/regions and included technologies (4G/5G NSA/SA; 2G fallback where applicable).
• Availability target: e.g., 99.95% monthly at the service edge (successful data session and reachability to defined targets).
• Latency: p95 thresholds to strategic targets (e.g., 100 ms within region), plus packet loss/jitter bounds.
• Attach success: e.g., >99.8% attach success within three attempts.
• Time‑to‑recover: e.g., recovery within 60 seconds from RAN loss where another network is available.
• Maintenance windows: whether counted or excluded.
• Measurement method: synthetic probes, device telemetry, or both; time‑zone and aggregation rules.
• Credits/remedies: aligned to impact, not just percentage figures.

Practical baseline examples to include in proposals:

• Expected availability: 99.95–99.99% across Tier‑1 markets; 99.9–99.95% in challenging geographies.
• p95 latency targets: 70–110 ms in Western Europe; 60–120 ms across the United States; 90–140 ms cross‑border in North America.
• Typical downtime minutes avoided vs. single‑network: 150–400 minutes per month saved at scale.

Caveat: When multiple carriers share common infrastructure (e.g., the same backhaul or data centre), failures may correlate. Build safety margins into your SLA targets and document assumptions.

Implementation checklist for partners

1) Select the right products and footprint - Map travel routes against our Destinations. - Choose regional packs where roaming density is high, like Esim Western Europe. - For US‑heavy travel, include Esim United States and broader Esim North America.

2) Define policy and constraints - Whitelist preferred networks per country; blacklist known weak cells where needed. - Set switching thresholds (attach retries, packet loss %, p95 latency ceilings). - Add compliance rules (e.g., force domestic breakout for specific roles).

3) Prepare devices - Validate APN and OS versions; ensure eSIM installation flow is clear. - Test both iOS and Android, including dual‑SIM scenarios.

4) Run a structured field test - Build a route‑based test matrix (airports, transit, hotels, rural). - Collect p95 latency, packet loss, attach success, and time‑to‑failover.

5) Operationalise monitoring - Set up synthetic probes in key cities (e.g., Paris, Milan, Madrid, New York). - Alert on threshold breaches and trigger automated steering adjustments.

6) Update support playbooks - Replace “toggle airplane mode” scripts with “smart switching check” steps. - Categorise tickets to isolate improvements in the first 60 days.

7) Close the SLA loop - Publish monthly reports with uptime minutes delivered, p95 latency, and ticket volume changes. - Share before/after comparisons with enterprise customers.

Pro tip: Keep policy simple to start. Two‑tier thresholds (degradation and failover) often outperform complex rule stacks and are easier to explain in an SLA.

Measuring outcomes: before/after that executives understand

Track and report the metrics that translate to traveller experience and support load:

• Downtime minutes per 1,000 user‑days
• p95 latency by country and by hour of day
• Attach success rate and PDP/PDN drop rate
• Time‑to‑failover when quality degrades
• Ticket volumes by category and severity
• CSAT/NPS for connectivity over time

Benchmarks seen after rollout:

• Downtime per 10,000 user‑days: from 500+ minutes down to 50–150 minutes
• p95 latency: 20–40% reduction in Western Europe and 15–30% across the US
• Attach failure rate: 25–50% reduction
• Support tickets: 35–55% reduction overall; first‑response times down by 20–30%

These results form the backbone of your SLA narrative and your sales proof points.

How to position smart switching in your sales deck

Structure your pitch around outcomes, not internals:

• Headline: “Always‑on travel connectivity with carrier diversity. 99.95%+ delivered availability. Auto‑failover in seconds.”
• Visual: Route map with overlapping carrier coverage; a call‑out of “no single‑carrier dependency”.
• Benefits slide:
• 10–40× fewer downtime minutes vs. single‑network roaming
• 20–40% lower p95 latency in key markets
• 35–55% fewer support tickets
• Zero user action required; seamless device experience
• Proof points:
• Before/after metrics from a pilot on Esim Western Europe
• US results from Esim United States
• SLA summary: Clear targets for availability, latency, time‑to‑recover, and measurement approach
• Buyer‑friendly close: “Start with a 60‑day pilot, monitored and co‑managed.”

Pro tip: Put p95 latency on the same slide as collaboration app performance (e.g., “Teams/Meet calls stay stable at p95 < 110 ms”). Stakeholders can connect the dots instantly.

Where smart switching helps most

• Frequent‑traveller teams moving between EU countries (Paris–Milan–Barcelona) with Esim France, Esim Italy and Esim Spain
• US‑centric road warriors relying on robust coverage across states with Esim North America
• Pop‑up retail and events that cannot tolerate single‑cell congestion
• Field service in rural areas where one network often outperforms others
• Critical apps that are latency‑sensitive (payments, UCaaS, live translation)

Pro tips for smooth operations

• Keep the APN consistent across products to simplify device setup and MDM policies.
• Monitor p95, not just averages. It’s where user pain lives.
• Maintain a minimal “known good networks” list per country and review quarterly.
• Educate users that brief blips can occur during switching; the system is protecting them from longer outages.
• Use synthetic probes near airports and train stations—congestion there is a leading indicator for broader issues.

FAQ

Q: How is smart switching different from traditional roaming steering?
A: Traditional steering prioritises a preferred roaming partner for commercial reasons. Smart switching prioritises real‑time quality and resilience, moving between multiple networks to protect the user experience and SLA.

Q: Will frequent switching drain battery?
A: Properly tuned policies avoid flapping. Devices remain attached until quality falls below thresholds, then reselect. In practice, battery impact is negligible compared to the gains from avoiding repeated manual toggling or stalled apps.

Q: Does the IP address change when the device switches?
A: It can. Moving to a different core or breakout may change IP. For most travel use cases that’s fine. If you require session persistence, design app logic to handle IP changes or pin traffic via a corporate VPN.

Q: Can we restrict networks for compliance or cost?
A: Yes. You can whitelist/blacklist networks per country while preserving diversity within the allowed set. Document these constraints in the SLA so expectations remain clear.

Q: What happens in areas with limited technology (e.g., only 4G available)?
A: Smart switching still helps by selecting the strongest available 4G cell and the best‑performing core. Where 5G is present, policies can prefer 5G where it improves latency and stability.

Q: How does this work across regions like Western Europe and North America?
A: Regional eSIMs such as Esim Western Europe and Esim North America include multi‑MNO access in each country, enabling the same smart switching behaviour as you cross borders.

The partner advantage

Multi‑network smart switching converts a roaming product into a resilient service with measurable SLA uplift. It protects travellers from localised outages, evening congestion and poor peering, while reducing your support burden. With clear SLA targets, a simple policy, and disciplined measurement, you can prove value fast—and price accordingly.

Next step: Explore packaging, SLAs and co‑marketing materials in our Partner Hub. If you’d like to discuss enterprise rollouts, visit For Business.

Integrating Simology’s eSIM into your app or site should be quick, safe and predictable. This guide shows you how to stand up a working flow end‑to‑end: pull a live catalogue, create a checkout, and handle activation webhooks to deliver eSIM credentials. You’ll get example endpoints, headers, sample payloads, sandbox tips, and robust error and retry strategies so you can go live with confidence.

We assume you’re building for travellers and want a clean, reliable purchase and activation journey. The same patterns apply whether you’re selling a single-country plan like Esim United States or regional bundles such as Esim Western Europe and Esim North America. If you’re still shaping your plan range, explore available markets on Destinations and see what resonates with your audience. When you’re ready to partner, head to the Partner Hub or our For Business page to get access.

What you’ll build

A minimal, production‑ready integration includes:

• Catalog: Fetch plans (SKU, coverage, allowance, validity, price) and display them.
• Checkout: Create an order/checkout session and direct the user to pay.
• Webhooks: Receive order status and eSIM activation credentials securely.
• Activation: Present LPA QR or SM‑DP+ + activation code in your UI.
• Post‑purchase: Poll or subscribe to status updates; offer top‑ups if supported.

Prerequisites

• A Simology partner account with API credentials: request access via the Partner Hub.
• Sandbox environment enabled (for test cards and simulated activations).
• Public HTTPS webhook endpoint (TLS 1.2+, supports POST, returns 2xx on success).
• Server ability to store secrets and verify signatures.
• Optional: SDK installed (Node.js or Python) or curl for initial testing.

Tip: While you prototype, use live product copy from Destinations. For regional content and FAQs, see Esim France, Esim Italy and Esim Spain.

Environments and authentication

Typical environment split:

• Sandbox base URL (example): https://sandbox-api.simology.io
• Production base URL (example): https://api.simology.io

Authentication:

• Use the HTTP header: Authorization: Bearer YOUR_API_KEY
• Send JSON: Content-Type: application/json
• Use idempotency for POSTs: Idempotency-Key: a-unique-uuid-per-intent

Pro tips: - Rotate keys regularly; keep them server-side only. - Scope keys to least privilege; separate sandbox and production keys. - Log the response header request_id (if provided) for faster support.

Step 1: Fetch the eSIM catalogue

Endpoint (example): - GET /v1/catalog?country=US - GET /v1/catalog?region=western-europe

Example request:

GET /v1/catalog?country=US HTTP/1.1 Host: sandbox-api.simology.io Authorization: Bearer sk_sandbox_123 Accept: application/json

Example response:

{  "items": [    {      "sku": "US-5GB-30D",      "name": "United States 5 GB / 30 days",      "region": "US",      "coverage": ["US"],      "data_allowance_mb": 5120,      "validity_days": 30,      "price": { "amount": 14.99, "currency": "USD" },      "activation_method": "lpa",      "esim_type": "data",      "terms_url": "https://simology.io/esim-united-states",      "available": true    }  ],  "updated_at": "2025-01-10T09:12:44Z" }

Implementation notes: - Cache catalogue responses for several minutes; invalidate on webhook or daily refresh. - Use query params to filter by country/region to reduce payloads. - Map regional SKUs to your UX—e.g., “Western Europe” → Esim Western Europe.

Pro tips: - Localise currencies client-side only if your payment provider requires it; keep SKU and currency from the API authoritative. - Surface coverage and validity clearly; travellers value transparency.

Step 2: Create a checkout session (order)

Endpoint (example): - POST /v1/checkout/sessions

Example request:

{  "customer": {    "email": "alex@example.com",    "country": "GB"  },  "items": [    { "sku": "US-5GB-30D", "quantity": 1 }  ],  "success_url": "https://yourapp.example/checkout/success?session_id={SESSION_ID}",  "cancel_url": "https://yourapp.example/checkout/cancel",  "metadata": {    "user_id": "u_789",    "source": "ios-app"  } }

Example response:

{  "id": "cs_abc123",  "payment_url": "https://pay.sandbox.simology.io/cs_abc123",  "status": "pending",  "expires_at": "2025-01-10T09:27:44Z" }

• Redirect the user to payment_url.
• On success, Simology will send a webhook (see next step) such as checkout.completed or order.paid.

Error example:

{  "error": {    "code": "sku_unavailable",    "message": "Requested SKU is not available in the selected region.",    "request_id": "req_9x8y7z"  } }

Pro tips: - Always include a unique Idempotency-Key on POSTs to prevent duplicate orders. - Do not fulfil on the browser redirect alone; wait for the signed webhook.

Step 3: Webhooks for checkout and activation

Expose a POST endpoint, e.g., https://yourapp.example/webhooks/simology

Expected events (names may vary by integration): - checkout.completed — customer returned from payment - order.paid — funds confirmed; fulfilment can begin - activation.ready — eSIM credentials ready for delivery - order.failed or payment.failed — handle gracefully

Security: - Simology signs webhook payloads. Expect a header like: - Simology-Signature: t=1736500000,v1=hex-hmac-sha256 - Verify HMAC using your webhook secret and the raw request body + timestamp t. - Reject if signature invalid or timestamp skew > 5 minutes.

Example webhook: order.paid

{  "type": "order.paid",  "id": "evt_123",  "created": "2025-01-10T09:20:02Z",  "data": {    "order_id": "ord_456",    "session_id": "cs_abc123",    "items": [      { "sku": "US-5GB-30D", "quantity": 1, "unit_price": 14.99, "currency": "USD" }    ],    "customer": { "email": "alex@example.com" }  } }

Example webhook: activation.ready

{  "type": "activation.ready",  "id": "evt_789",  "created": "2025-01-10T09:21:10Z",  "data": {    "order_id": "ord_456",    "line": {      "iccid": "8988307000001234567",      "smdp_plus": "LPA:1$sm-dp-plus.simology.net$ACT-CODE-1234",      "qr_url": "https://sandbox-api.simology.io/v1/qr/ord_456.png",      "valid_from": "2025-01-10T09:21:10Z",      "expires_at": "2025-02-09T23:59:59Z"    }  } }

Retries: - Respond 2xx on success within 5 seconds. - Non-2xx triggers automatic retries with exponential backoff (e.g., 1m, 5m, 30m, hourly up to 48h). - Webhooks are idempotent; use the event id to deduplicate.

Pro tips: - Store the full webhook event before processing; reprocess safely if needed. - Use a separate signing secret per environment; rotate on a schedule.

Step 4: Deliver and activate the eSIM

Once you receive activation.ready: - If you display QR in-app: render qr_url or generate your own QR from the LPA string (smdp_plus). Confirm the screen brightness/instructions for scanning. - If you deliver manually: present the SM‑DP+ address and activation code clearly.

UI checklist: - Show coverage and validity (mirror your catalogue details, e.g., Esim North America). - Provide concise device instructions (Settings > Mobile Data > Add eSIM). - Remind users to keep primary SIM for calls/SMS if needed, using data on eSIM. - Offer a link back to plan details (e.g., Esim United States) for FAQs.

Step 5: Post‑activation status and top‑ups

Common endpoints (examples): - GET /v1/orders/{order_id} — check latest status. - GET /v1/lines/{iccid} — inspect data used/remaining. - POST /v1/topups — add data to an existing line.

Example line status:

{  "iccid": "8988307000001234567",  "status": "active",  "data": {    "used_mb": 1200,    "remaining_mb": 3920  },  "valid_until": "2025-02-09T23:59:59Z" }

Pro tips: - Cache status for 30–60 seconds to avoid rate limits. - If you surface data usage, include a timestamp and note that roaming networks can report with slight delay.

Errors, rate limits and observability

HTTP status patterns: - 400 validation_error — your request is malformed (missing field, invalid SKU). - 401/403 auth_error — bad or expired credentials, wrong environment key. - 404 not_found — order/line ID not recognised. - 409 conflict — duplicate idempotency key with different payload. - 429 rate_limited — back off using Retry-After header. - 5xx server_error — transient; retry with backoff and jitter.

Canonical error body:

{  "error": {    "code": "rate_limited",    "message": "Too many requests. Try again later.",    "request_id": "req_123",    "retry_after": 30  } }

Best practices: - Always log request_id and error.code. - Implement circuit breakers for persistent 5xx. - Respect Retry-After on 429; apply exponential backoff with jitter. - Use unique Idempotency-Key per action (e.g., “create checkout for cart 123”). - Monitor webhook delivery success rate and age of last processed event.

SDK quick start

While you can integrate with raw HTTP, SDKs speed up auth, idempotency and webhook verification. The shapes below reflect the examples above; adapt to your language and tooling.

Node.js (example):

import { Simology } from "@simology/sdk"; const sim = new Simology({ apiKey: process.env.SIMOLOGY_API_KEY, baseUrl: "https://sandbox-api.simology.io" }); const catalog = await sim.catalog.list({ country: "US" }); const session = await sim.checkout.create({  customer: { email: "alex@example.com", country: "GB" },  items: [{ sku: "US-5GB-30D", quantity: 1 }],  success_url: "https://yourapp.example/success?session_id={SESSION_ID}",  cancel_url: "https://yourapp.example/cancel" });

Webhook verification (pseudo):

app.post("/webhooks/simology", express.raw({ type: "application/json" }), (req, res) => {  const signature = req.header("Simology-Signature");  const event = sim.webhooks.verify(req.body, signature, process.env.SIMOLOGY_WEBHOOK_SECRET);  // process event.type ...  res.sendStatus(200); });

Python (example):

from simology import Simology sim = Simology(api_key=os.getenv("SIMOLOGY_API_KEY"), base_url="https://sandbox-api.simology.io") catalog = sim.catalog.list(country="US")

Tip: Keep the webhook route using raw body to preserve signature integrity.

Security and privacy essentials

• Store only what you need (e.g., order_id, sku, iccid). Avoid storing full QR images if the LPA string is sufficient.
• Encrypt secrets at rest; restrict access via IAM.
• Validate webhook payload against expected schema before acting.
• Do not render raw error messages to end users; translate to helpful guidance.

Go‑live checklist

• Sandbox to production switch with environment flags.
• API key rotation plan and secret storage verified.
• Idempotency implemented on all POST operations.
• Webhook endpoint verified with signature checks and 2xx acks.
• Observability: logs capture request_id, event.id, order_id, iccid.
• Rate limit handling and backoff tested.
• Happy path and failure path user messaging in place.
• Regional catalogue mapped to your content (e.g., Esim France, Esim Italy).

FAQ

• How do sandbox and production differ? Sandbox uses test payment and simulated activation events. Payload shapes mirror production, but no real provisioning occurs. Use separate API keys and webhook secrets per environment.
• Can I test activation without scanning a QR? Yes. Use the LPA string (SM‑DP+ and activation code) from activation.ready to test your UI. In sandbox, you can display it without provisioning a real profile.
• What happens if my webhook endpoint is down? Simology retries with exponential backoff for a defined window (for example, up to 48 hours). Keep processing idempotent and return 2xx only after you have safely stored/handled the event.
• How should I handle plan regions in my UX? Keep your SKUs aligned with clear coverage descriptions (country vs region). Link to destination pages like Esim United States or Esim Western Europe for clarity, and aggregate them under Destinations.
• Can I issue refunds or cancellations via API? Many setups support POST /v1/refunds or cancelling unpaid checkouts. Always wait for webhook confirmation (refund.processed) before altering customer entitlements.
• Do you support top‑ups and usage queries? Yes in most cases—use the lines and topups endpoints as shown. Cache usage responses briefly and inform travellers about reporting delays when roaming.

Next step: Ready to get credentials and sandbox access? Visit the Partner Hub to kick off your integration.