Why Does Partner Onboarding Matter So Much in the eSIM Industry?
Getting onboarding right is the difference between a reseller partnership that scales smoothly and one that generates a flood of support tickets on day one. The eSIM market is growing fast — according to the GSMA, there were approximately 300 million eSIM-capable devices in active use globally by the end of 2024, a figure projected to surpass 900 million by 2028. That trajectory means the stakes for a clean partner launch have never been higher.
A poorly onboarded partner doesn't just hurt their own revenue — it creates real problems for end travelers who land in a new country expecting instant connectivity. Whether your customers are heading to a high-traffic destination like Australia or somewhere more niche, the quality of their activation experience flows directly from how well the reseller relationship was set up.
This checklist walks through every stage methodically: branding, legal, sandbox, and go-live. Bookmark it, share it with your technical contact, and work through it sequentially.
What Should You Prepare Before Onboarding Even Starts?
Before you touch a single API credential or sign a contract, the pre-onboarding preparation phase determines how quickly everything else moves. Partners who arrive at kick-off with complete documentation consistently complete onboarding 40–60% faster than those who gather materials reactively.
Here's what to have ready before your first onboarding call:
Business Documentation
- Company registration certificate — a current copy (issued within the last 12 months)
- VAT or tax identification number (jurisdiction-specific)
- Proof of trading address — utility bill or bank statement dated within 90 days
- Beneficial ownership declaration — required for AML compliance in most markets
- Bank account details for commission settlement or prepaid top-ups
Technical Readiness
- Confirm your platform is HTTPS-only — no HTTP endpoints will be whitelisted in production
- Identify your primary technical contact and their time zone
- Decide whether you'll use the hosted storefront (white-label) or direct API integration
- If API: confirm your preferred language/framework (REST/JSON is standard; webhooks require a publicly accessible endpoint)
Brand Assets
Gather these before the branding stage (detailed below):
- Logo files in SVG and PNG (transparent background, minimum 500 × 500 px)
- Brand color hex codes (primary, secondary, accent)
- Typography preferences or font files if custom
- Approved tagline or brand descriptor
How Does the Branding Stage Work?
The branding stage ensures that every customer touchpoint — from the storefront header to the QR code email — reflects your brand rather than the underlying platform. Done well, it creates a seamless white-label experience; done poorly, it confuses customers and erodes trust.
White-Label Storefront Configuration
Most eSIM wholesale platforms offer a hosted storefront that can be skinned with your branding in under 48 hours. The typical configuration items are:
| Element | What to Provide | Notes |
|---|---|---|
| Logo | SVG + PNG, transparent BG | Displayed in header and emails |
| Primary color | Hex code | Buttons, links, highlights |
| Secondary color | Hex code | Backgrounds, cards |
| Favicon | 32 × 32 px ICO or PNG | Browser tab icon |
| Custom domain | e.g. esim.yoursite.com | CNAME DNS record required |
| Support email | Branded address | Shown in activation emails |
| Terms URL | Link to your own T&Cs | Embedded in checkout flow |
Custom Domain Setup
Setting up a custom domain (e.g., esim.yourcompany.com) requires adding a CNAME record in your DNS provider. Propagation typically takes 24–48 hours. SSL certificates are provisioned automatically via Let's Encrypt once the CNAME resolves — you don't need to supply your own certificate unless you have a specific compliance reason to do so.
Tip: Test your custom domain from multiple geographic locations using a tool like DNSChecker.org before declaring the branding stage complete.
Transactional Email Templates
Every automated email your customers receive — purchase confirmation, QR code delivery, data top-up notification — should carry your brand. Provide:
- From name (e.g., "YourBrand Connectivity")
- From address (must be a verified sending domain)
- Email header image (600 px wide, max 150 px tall)
- Footer text including your registered business name and address (legally required in most jurisdictions)
Branding Stage Sign-Off Checklist
- Logo renders correctly at all breakpoints (desktop, tablet, mobile)
- Custom domain resolves with valid SSL
- Brand colors applied consistently across storefront, emails, and error pages
- Support contact details are accurate
- Footer legal text matches your jurisdiction's requirements
- Partner has reviewed and approved a staging preview
What Legal Agreements Do You Need to Sign?
Legal sign-off is the gate that protects both parties. Rushing through it — or skipping proper review — creates liability exposure that can surface months later, particularly around data privacy and consumer protection.
Core Agreements
1. Reseller / Distribution Agreement This is the master contract governing the commercial relationship. Key clauses to review carefully:
- Pricing and margin structure — fixed wholesale price vs. revenue share, minimum purchase commitments
- Territory restrictions — which countries or regions you're authorized to sell in
- Exclusivity clauses — whether you have exclusive rights in a given market segment
- Termination provisions — notice periods, grounds for immediate termination, data return obligations
- Liability caps — typically limited to fees paid in the prior 12 months
2. Data Processing Agreement (DPA) Under the EU's GDPR and equivalent laws (UK GDPR, Australia's Privacy Act 1988, Canada's PIPEDA), any arrangement where personal data flows between two organizations requires a DPA. This is not optional — fines for operating without a valid DPA can reach €20 million or 4% of global annual turnover under GDPR (European Commission, GDPR enforcement).
The DPA should specify:
- Categories of personal data processed (name, email, device IMEI/EID)
- Purposes of processing
- Sub-processor list (e.g., payment processors, SMS gateways)
- Data retention periods
- Cross-border transfer mechanisms (Standard Contractual Clauses if data moves outside the EEA)
3. Acceptable Use Policy (AUP) Acknowledgment You'll be asked to confirm that you won't use the platform for prohibited activities: SIM-boxing, traffic pumping, or resale in sanctioned territories. This is a standard one-page acknowledgment.
4. Service Level Agreement (SLA) Understand what uptime guarantees apply to the API and storefront, what the escalation path is for outages, and how credits are calculated for downtime events.
Legal Stage Sign-Off Checklist
- Reseller Agreement reviewed by legal counsel and signed by authorized signatory
- DPA executed (both parties)
- AUP acknowledgment submitted
- SLA terms understood and accepted
- Insurance requirements met (some platforms require minimum professional indemnity coverage)
- VAT/tax treatment confirmed for your jurisdiction (B2B reverse charge vs. local VAT)
How Do You Use the Sandbox Environment Effectively?
The sandbox is where integrations are validated before they touch real money or real customers. Treat it seriously — a thorough sandbox phase is the single most effective way to prevent go-live failures. As one industry benchmark notes, partners who complete a structured sandbox checklist report 70% fewer post-launch support escalations compared to those who skip straight to production.
What the Sandbox Provides
- Test API credentials — separate from production, with no real charges
- Simulated eSIM profiles — fake EIDs that behave like real profiles for API response testing
- Webhook simulation — trigger events (purchase, activation, data exhaustion) to test your notification handling
- Test payment methods — use provided test card numbers; no real transactions occur
API Integration Testing
If you're building a direct API integration rather than using the hosted storefront, work through these test scenarios in order:
1. Authentication
- Confirm OAuth 2.0 token generation works with your test credentials
- Verify token refresh logic (tokens typically expire after 3,600 seconds)
- Test behavior when an expired token is used — confirm your code handles 401 responses gracefully
2. Product Catalog
- Fetch the full product catalog and confirm it parses correctly
- Test filtering by region or country (e.g., retrieve only plans for Japan or Southeast Asia)
- Confirm your UI renders plan names, data allowances, validity periods, and prices accurately
3. Order Creation
- Place a test order for a single eSIM
- Confirm the order response includes the
order_idandesim_id - Test duplicate order prevention (submit the same idempotency key twice — the second call should return the original order, not create a new one)
4. QR Code / LPA String Delivery
- Confirm the QR code image URL is returned in the order response
- Test that the LPA activation string (format:
LPA:1$smdp.example.com$MATCHING_ID) is also available as a text fallback - Verify that your email template renders the QR code at the correct size (minimum 200 × 200 px for reliable scanning)
5. Order Status & Webhooks
- Poll the order status endpoint and confirm state transitions:
PENDING→ACTIVE→IN_USE→EXHAUSTED - Register your webhook endpoint and trigger each event type
- Confirm your server returns HTTP 200 within 5 seconds — most platforms will retry failed webhooks up to 5 times with exponential backoff
6. Top-Up and Renewal
- Test the top-up flow for an existing eSIM
- Confirm the data balance updates correctly after a top-up event
- Test what happens when a customer attempts to top up an already-expired profile
7. Error Handling
Test these error scenarios explicitly — they're the ones that cause production incidents:
| Error Code | Scenario | Expected Behavior |
|---|---|---|
| 400 | Malformed request body | Return user-friendly error, log raw response |
| 401 | Expired/invalid token | Trigger token refresh, retry once |
| 404 | eSIM profile not found | Show "order not found" message, prompt support contact |
| 409 | Duplicate order | Return existing order silently |
| 429 | Rate limit exceeded | Implement exponential backoff, queue retry |
| 500 | Platform server error | Show generic error, alert on-call engineer |
Non-API Testing (Hosted Storefront Partners)
If you're using the white-label storefront rather than a custom API integration, your sandbox testing focuses on the user journey:
- Browse catalog → select plan → add to cart → checkout (test card) → confirmation email received
- QR code in email is scannable with a real device (use an eSIM-compatible phone in test mode)
- Customer account creation and login work correctly
- Order history page displays correctly
- Support contact link in confirmation email routes to your support address, not a platform default
Sandbox Stage Sign-Off Checklist
- All API endpoints tested against documented spec
- All error codes handled gracefully in your UI
- Webhook delivery confirmed for all event types
- QR code rendering validated on iOS and Android
- End-to-end purchase flow completed without errors
- Load test performed (simulate 10× expected peak traffic)
- Security review: no API credentials exposed in client-side code or public repositories
What Does a Controlled Go-Live Look Like?
Go-live isn't a single moment — it's a staged rollout that lets you catch issues with real traffic before they affect your entire customer base. According to GSMA's Mobile Economy report, eSIM adoption is accelerating fastest in markets with high smartphone penetration, which means your early customers will likely be tech-savvy enough to notice — and report — any rough edges quickly.
Pre-Launch Final Checks
Run through this list in the 48 hours before you open to customers:
Technical
- Production API credentials rotated from sandbox credentials (never use sandbox keys in production)
- Webhook endpoint switched to production URL
- Custom domain SSL certificate valid and auto-renewal confirmed
- Error monitoring (e.g., Sentry, Datadog) configured for production environment
- Runbook documented: what to do if the platform API is unreachable
Commercial
- Pricing reviewed and confirmed (test that displayed prices match API-returned prices exactly)
- Payment gateway live and tested with a real £1/$1 transaction (then refunded)
- Refund and cancellation flow tested end-to-end
- Currency display correct for your target market
Support
- Support team briefed on common eSIM activation issues (see No Service After Installing an eSIM: 10 Checks to Do First for the most frequent troubleshooting scenarios)
- Knowledge base or FAQ page live on your site
- Escalation path to platform support documented (account manager contact, emergency line)
Legal / Compliance
- Privacy policy updated to reflect eSIM data processing
- Cookie consent banner covers any new analytics added during integration
- Terms of service updated with eSIM-specific cancellation terms
Soft Launch: The 5% Rollout
Don't open to 100% of your traffic on day one. A soft launch — where only a small percentage of visitors see the eSIM product — lets you:
- Confirm real payment processing works at low volume
- Validate that activation emails arrive within the expected timeframe (typically under 60 seconds)
- Catch any region-specific issues (some countries have device restrictions that don't appear in sandbox)
- Gather initial customer feedback before scaling
A practical soft launch sequence:
| Phase | Traffic % | Duration | Success Criteria |
|---|---|---|---|
| Internal | 0% (team only) | 2–3 days | Zero critical bugs, all flows complete |
| Soft launch | 5–10% | 3–5 days | Error rate < 0.5%, CSAT ≥ 4/5 |
| Expanded | 25–50% | 3–5 days | Error rate < 0.2%, support volume manageable |
| Full launch | 100% | Ongoing | KPIs tracking to forecast |
Go-Live Monitoring
For the first 72 hours after full launch, monitor these metrics in near-real-time:
- Order success rate — target > 99%
- QR code delivery time — target < 60 seconds from payment
- Activation rate — the percentage of purchased eSIMs that are actually installed; a low rate often signals a UX issue in the post-purchase flow
- Support ticket volume — any spike above 2% of orders indicates a systemic issue
- API error rate — alert if > 0.1% of API calls return 5xx errors
Post-Launch: The First 30 Days
The go-live checklist doesn't end at launch. The first 30 days are critical for catching issues that only emerge at scale:
- Week 1: Daily review of support tickets; categorize by issue type
- Week 2: First revenue reconciliation — confirm commissions or margins match expectations
- Week 3: Review activation rates by destination; low activation in specific countries may indicate a device compatibility issue or a need for better customer education
- Week 4: Full performance review with your account manager; agree KPIs for month two
How Should You Handle Customer Support for eSIM Issues?
Your support team is the last line of defense between a frustrated traveler and a negative review. The most common post-purchase issues — and how to handle them — follow predictable patterns.
The majority of eSIM support tickets fall into three categories: activation failures (device compatibility or incorrect APN settings), connectivity issues after installation, and billing questions. Equipping your team with clear resolution paths for each dramatically reduces handle time.
Common Issues and First-Response Scripts
"I scanned the QR code but nothing happened"
- Confirm the device is eSIM-compatible and unlocked
- Check that the customer is on Wi-Fi during installation (cellular data isn't available yet)
- Confirm iOS: Settings → Cellular → Add eSIM | Android: Settings → Network → SIM → Add eSIM
- If the QR code has already been scanned once, it's consumed — a replacement profile may need to be issued
"My eSIM is installed but I have no data"
- Confirm the plan hasn't already expired or been exhausted
- Check APN settings — this is the most common culprit (see Private APN & Enterprise Security: When and Why to Use It for advanced APN configuration scenarios)
- Confirm data roaming is enabled on the eSIM line (not just the primary SIM)
- Restart the device after confirming settings
"I'm not receiving OTP codes from my bank"
- The customer's home number is likely on a different SIM line — ensure their banking app's registered number still has signal
- Refer them to Banking & OTP Abroad: App Settings That Keep Codes Coming for a step-by-step guide
Escalation Matrix
| Severity | Example | First Response SLA | Escalation Path |
|---|---|---|---|
| P1 | Platform API down, no orders completing | 15 minutes | Platform emergency line |
| P2 | QR codes not delivering | 1 hour | Account manager + platform support |
| P3 | Individual activation failure | 4 hours | Standard support ticket |
| P4 | Billing discrepancy | 24 hours | Finance + account manager |
FAQ
How long does the full partner onboarding process take?
Most partners complete all four stages — branding, legal, sandbox, and go-live — in two to six weeks. The timeline depends heavily on how quickly legal review is completed and whether your technical team has prior API integration experience. Partners who prepare documentation in advance and dedicate a full-time technical resource consistently land at the shorter end of this range.
Do I need a developer to integrate with the eSIM platform?
Not necessarily. If you choose the hosted white-label storefront option, the integration is primarily configuration rather than coding — setting up a CNAME record, uploading brand assets, and reviewing email templates. A developer is required only if you're building a custom API integration into your own platform or app.
What devices are compatible with eSIMs sold through the platform?
eSIM support requires both hardware (an embedded SIM chip) and software (carrier unlock). Most flagship smartphones released after 2018 support eSIM, including iPhone XS and later, Google Pixel 3 and later, and Samsung Galaxy S20 and later. Devices must also be unlocked from their original carrier. Your platform's compatibility checker is the authoritative source — Simology's eSIM Compatibility Checker is a useful reference for common device queries.
Can I sell eSIMs for any country in the world?
Coverage depends on the wholesale agreements your platform has in place. Simology covers 190+ countries, including popular destinations like Japan and Australia, as well as regional plans covering areas like Asia. Your reseller agreement will specify any territory restrictions — review that clause carefully before marketing to customers in specific regions.
What happens if a customer's eSIM doesn't activate after purchase?
First, work through the standard troubleshooting checklist: device compatibility, unlock status, Wi-Fi connection during installation, and correct APN settings. If the issue persists, the platform's support team can inspect the profile status on the backend. In most cases, a replacement profile can be issued within a few hours. Document the failure reason — patterns in activation failures often point to a specific device model or destination network issue that can be proactively addressed.
Is a Data Processing Agreement (DPA) always required?
Yes, in any jurisdiction with modern privacy law — which now covers the vast majority of your potential customer base. GDPR applies to any customer in the EU or UK regardless of where your business is based. Australia's Privacy Act, Canada's PIPEDA, and California's CCPA impose similar obligations. Operating without a valid DPA exposes both parties to regulatory fines and voids your liability protections under the reseller agreement.
How do I test that my webhook endpoint is working correctly?
Most platforms provide a webhook testing tool in the sandbox dashboard that lets you trigger specific event types manually. Confirm your endpoint returns HTTP 200 within 5 seconds for each event type. Also verify your server logs the raw payload before processing it — this makes debugging much easier when an unexpected event format arrives in production.
What should I monitor in the first 72 hours after go-live?
Focus on four metrics: order success rate (target > 99%), QR code delivery time (target < 60 seconds), activation rate (percentage of purchased eSIMs actually installed), and support ticket volume (alert if > 2% of orders generate a ticket). Any metric outside these thresholds in the first 72 hours warrants immediate investigation before scaling traffic further.
Bringing It All Together
A well-executed partner onboarding isn't just an administrative exercise — it's the foundation of a reseller business that can scale confidently. The four stages (branding, legal, sandbox, go-live) exist because each one protects something different: your brand equity, your legal exposure, your technical reliability, and your customer experience.
The partners who launch most successfully share a few traits: they treat the sandbox as seriously as production, they involve legal counsel early rather than at the last minute, and they plan a staged rollout rather than a big-bang launch. With the global eSIM market on track to connect nearly a billion devices by 2028, getting the foundation right now positions you to capture a meaningful share of that growth.
If you're at the early stages of evaluating an eSIM reseller partnership, start with the pre-onboarding documentation checklist above. If you're mid-process and hitting a specific blocker — branding, a DPA question, or a webhook issue — jump to that section and work through the relevant sign-off checklist. Either way, you've got everything you need to move forward with confidence.
