Travel brands rarely ask “should we care about visas?” anymore. The real question is which integration model gets you to controlled eligibility, fulfilled applications, and usable status, without over-building or under-owning the journey.
This page is a decision framework for VP Product, Head of Ancillaries, CTOs, and procurement at OTAs, airlines, and tour operators. It is not a full options encyclopedia (the layers of a processing system are on the visa processing system guide) and not a white-label how-to (see how to offer white-label visa services without writing code).
It is also not legal or immigration advice. Governments issue visas. Your choice of API vs white-label changes UX, data ownership, and ops load. It does not change the authority that decides.
Competitors sell both models as a matrix. Sherpa Solutions contrasts requirements surfaces, embeds, and deeper builds with revenue language. Your job is to pick the maturity level that matches engineering capacity and channel control.
The three models in one table
| Dimension | Government-portal redirect / deep-link | White-label / hosted / embed | Full API / native embed |
|---|---|---|---|
| Time-to-live | Hours to days | Days to about one or two sprints | Multi-sprint (checkout, webhooks, and ops) |
| Eng lift | Minimal | Low to medium (config, branding, callbacks) | Medium to high (native UX, PSS/DCS hooks) |
| Brand control | Weak. The traveler leaves your flow. | Strong co-brand / your chrome | Strongest (your UI) |
| Data ownership | Little status visibility | Partner status in back-office / webhooks | Full orchestration in your systems |
| Compliance depth | You point. You still own CX fallout. | The processor handles filing ops. You own promises in copy. | Same processing reality. You own more UX and fail policy. |
| Ancillary control | Low (someone else’s checkout) | Commission / fee share is common | Full retail pricing and attach logic |
| Best first use | Long-tail / rare origin-destination pairs | Fast revenue, multi-brand, limited engineering | High volume, DCS/CRM automation |
“Embed” (a widget inside your pages) sits between a classic white-label redirect and a full API: the vendor maintains the UX, and you keep the passenger in-session. Treat it as the white-label family unless you also consume eligibility and status APIs for your own logic. Our hosted version of that family is the co-branded storefront.
Choose white-label when…
- Engineering bandwidth is scarce and you need attach revenue or documentation help in days to a few weeks, not a quarter.
- You want a co-branded apply-and-status journey without standing up visa ops or document-validation UX.
- You run multi-brand or affiliate distribution and need one processor behind several storefronts.
- Complex or long-tail destinations would distract your core booking roadmap.
- Airport / DCS automation is a later phase. Manage-booking and email chase are enough for now.
White-label wins on time-to-revenue and ops outsourcing. It loses when you need custom no-board logic, deep CRM branching, or a fully native checkout that never hands the passenger to a hosted step. For the tactical playbook, use the hosted storefront and the no-code how-to linked above.
Choose API when…
- You need native UX in checkout, app, or DCS: the same design system, the same localisation, the same A/B tests.
- Status must feed CRM, PSS, disruption tools, or automated referral / no-board rules.
- Volume and orchestration justify building screens once and driving them from structured events.
- You already have (or will hire) product ownership for ancillaries and failure paths.
- Procurement expects sandbox controls, idempotent writes, and signed webhooks as table stakes.
API wins on control and automation. It costs engineering time and forces you to design incomplete-doc and refusal UX yourself, or to reuse vendor components carefully. The capability list is eVisa API for OTAs and airlines: what you actually need. The shorter mechanics explainer remains how eVisa APIs work.
Hybrid patterns that work
Most mature travel sellers do not pick a single forever model.
- API eligibility everywhere, white-label or hosted collection for long-tail. One requirements truth in search and booking. Hosted apply where destination complexity is high.
- API eligibility plus hosted document collection. You own messaging and attach. The vendor owns photo and document validation screens.
- Staged roadmap: white-label, then API. Ship revenue and CX under the brand in phase 1. Replace hosted steps with native API screens at checkout and check-in in phase 2.
- Airline pattern. White-label or embed for passenger self-service. API status into manage-booking and DCS for ops. See how airlines cut denied boardings with visa data.
Hybrids fail when status truths diverge: the passenger sees “approved” in the portal while check-in still shows unknown. One status contract across surfaces is non-negotiable.
Cost and risk framing (non-legal)
Support load: redirecting to a government portal does not remove your contact centre from the journey. It often makes you the only human left when the portal fails. Industry narratives, for example Sherpa on DIY eVisa costs, quantify contact-centre and INAD exposure with explicit assumptions. Use them as illustrations, then replace them with your own unit costs.
Carrier exposure: airlines absorb fines, repatriation, escorts, and disruption for inadmissible passengers. IATA’s INAD overview discusses typical state penalty ranges and associated costs. A later IATA Knowledge Hub piece on ETAs cites study figures including an all-in cost around $25,000 per case for surveyed carriers. Those are external benchmarks, not your route’s guaranteed unit cost. Model yours with the INAD / denied-boarding cost calculator.
OTA exposure: you may not pay the fine, but you own refunds, rebooking CX, and brand blame when documentation fails after you sold the trip.
Disclaimer: this section is operational framing only. Not legal advice. Fines and carrier obligations vary by state and contract. Counsel decides liability language.
10-question decision worksheet
Score each 1–5 with your SimpleVisa account team, or with internal stakeholders. A higher total leans toward API. A lower total leans toward white-label or hybrid-first. There is no magic threshold. Use it to force trade-offs into the open.
| # | Question | Low (1) → High (5) |
|---|---|---|
| 1 | How soon must we show attach revenue? | Months of runway → days or weeks |
| 2 | Engineering capacity for native UX and webhooks? | None this quarter → dedicated squad |
| 3 | Need status in CRM / PSS / DCS? | Email only → automated ops |
| 4 | Multi-brand / affiliate complexity? | Single brand → many storefronts |
| 5 | Share of bookings needing an eVisa or ETA? | Rare → core of the international mix |
| 6 | Appetite to own incomplete-doc UX? | Prefer vendor screens → must be native |
| 7 | Check-in / gate fail-policy maturity? | Ad hoc → documented per origin-destination |
| 8 | Procurement needs (sandbox, DPA, security pack)? | Light → heavy questionnaire |
| 9 | Desire to set traveler retail price? | Accept vendor retail → full control |
| 10 | 12-month vision: hosted OK forever, or native-only? | Hosted is fine → native mandate |
Interpretation sketch: if questions 3, 5, 6, and 7 skew high, prioritise API (possibly hybrid). If 1, 2, and 4 skew toward speed and multi-brand, start white-label. If 10 says “native eventually,” write the staged roadmap into the statement of work so you do not rebuild contracts later.
FAQ
Is white-label “less compliant” than API?
Not inherently. Filing quality depends on the processor’s ops and validation, not on whether the UI is hosted. What changes is how much fail policy and messaging you implement yourself.
Can we run API and white-label with the same vendor?
Often yes. Eligibility API plus hosted apply is a common hybrid. Insist on one status model and shared booking references.
Where does government-portal redirect fit?
As a third column: fastest, least control, weakest ancillary capture. Fine for edge destinations. Risky as the default for high-volume eVisa and ETA routes.
Should airlines and OTAs choose differently?
Airlines usually need stronger check-in and DCS hooks sooner. OTAs often start with white-label or embed for attach, then API for post-booking automation. The worksheet above encodes that without locking a single answer.
Next step
- Book a readiness call for a model recommendation against your channels and engineering capacity.
- Demo both surfaces: white-label or embed, and API eligibility plus status, for the same sample itinerary.
- Deepen the chosen path: eVisa API for OTAs and airlines, white-label how-to, and the cost model.
Disclaimer: decision support for product and commercial planning only. Not legal or immigration advice. Visa and entry decisions are made by government authorities. Competitor descriptions reflect their public pages at the linked URLs.