Most RoamWorks partners sell RoamWorks SIM packs and eSIM as they are. A hotel or a rental counter does not need its own name on a SIM. A large platform is different. It has its own app, its own customers, and a reason to keep the travel experience under its own name.
This guide is for those platforms: booking platforms, airlines, and banks. A hosted store is fast. An API gives you control. Most platforms start with one model and add the other later. See the co-branded eSIM store and the eSIM API.
Start with the customer journey
Ask one question: where does the traveler buy?
- If the traveler buys on a page you control and you want a fast launch, use a co-branded store or a checkout link.
- If the traveler buys inside your app, use the API or SDK.
- If the traveler buys at a desk or a counter, sell RoamWorks SIM packs or a digital eSIM voucher. A co-branded store adds little there.
The answer decides the integration. It also decides the support path and the data you need to pass.
The three models
| Model | What the traveler sees | What you run | Fits |
|---|---|---|---|
| Co-branded store | Your name next to RoamWorks, your plan list, your retail price | The store link or domain, the launch plan, first-line support | A platform with a large audience but no engineering team for a build |
| Checkout link | A checkout page that opens from your app or email | The placement and the handoff | A fast test of demand before a full build |
| API or SDK | The eSIM flow inside your own product | Your app, your checkout, your support desk, and the integration | A travel app with an existing booking flow and development capacity |
Co-branded store
A co-branded store carries the platform name, the plan list, and the retail price. The traveler sees the platform name and the RoamWorks name together. The line "Co-branded with RoamWorks" stays.
The platform does not hold stock or run a provisioning system. The store handles the plan choice, payment, and eSIM delivery. The platform sets the commercial model and the support path.
This model fits:
- Online travel platforms that want a store before they build an API.
- Airlines with a travel shop and a small product team.
- Banks and loyalty programs that want a travel benefit and a simple launch.
API and SDK
The API puts the plan catalogue, order, and eSIM status inside your own product. The traveler stays in your app. Your team controls the interface, the checkout, and the data that the traveler sees.
The API needs more work than a hosted store:
- A catalogue call that maps RoamWorks plans to your own products.
- An order call with your reference and the traveler's trip.
- A status call and a webhook for the eSIM and the QR code.
- A test environment and a launch plan.
- A support path for a failed install.
An SDK can wrap the same calls in an iOS or Android app and install the eSIM in one tap where the phone allows it. The QR code stays as the fallback. The SDK suits an app with a travel section and a team that can ship a release.
Who controls what
Write the split into the partner agreement before the build:
- The platform controls the customer relationship, the retail price, the brand, and the first-line support.
- RoamWorks controls the plan catalogue, the provisioning, the eSIM delivery, and the technical support behind the platform.
- The agreement sets who answers first, who handles a refund, and who owns the customer data.
A clear split prevents a support ticket from bouncing between two teams.
Data and privacy
The platform should pass only the data that the order needs: the destination, the trip dates, the plan, the order reference, and the contact for delivery. Do not send card data to the eSIM API. Keep the payment in your own checkout and your own payment process.
A platform that sends personal data to a partner needs a data processing agreement. The privacy policy must name the categories of data, the purpose, the retention period, and the rights of the traveler. The ICO guidance is a useful checklist for the data questions, even when the platform operates outside the UK.
The commercial model
A co-branded store or an API can work in two ways:
- The platform buys at a partner price and sets the retail price.
- The platform refers the sale to RoamWorks and earns a share of each sale. The agreement sets the share. Do not state a figure.
The right model depends on who owns the customer, who takes the payment, and who answers the support request. A resale model gives the platform more control and more work. A referral model is faster and lighter.
Common mistakes
- A store with no plan for the first support question.
- A price that changes between the plan card and the checkout.
- No phone check before the traveler pays.
- A launch with no test order.
- A data flow with no processing agreement.
- A promise that the eSIM works on every phone.
A simple decision rule
| Your situation | Start with |
|---|---|
| A large customer base, no app team yet | Co-branded store or checkout link |
| A booking flow with destination and dates | API or SDK |
| A physical counter or front desk | RoamWorks SIM packs or a digital voucher |
| A first test of demand | Checkout link, then a store or an API |
Sources and checked
- PCI Security Standards Council, PCI DSS, checked 27 October 2026.
- Information Commissioner's Office, UK GDPR guidance and resources, checked 27 October 2026.
- RoamWorks product and integration notes, checked 27 October 2026.
Talk to us about the model for your platform. Bring the customer journey, the data you hold, and the support path. The contact page starts the fit call.