The choice between a visa API and a white-label app is really a choice about engineering budget and brand control. The API puts the visa moment inside your own product at the cost of building it: your developers own the interface, the error states and the release schedule. The white-label route ships this quarter with no code, and the provider's machinery stays visible at the edges: a subdomain, a name on the card statement, a support address you do not control. Most businesses should start where their constraint is. If engineers are what you are short of, start hosted. If conversion is what you are short of, start with the API.
Four models, not two
Comparisons frame this as a binary. Most providers sell a spectrum, and the two options in the middle are where a lot of travel brands end up.
Hosted or co-branded storefront
The provider hosts a visa application flow on a subdomain of your domain, wearing your logo and colours. You link to it from the booking confirmation page, the pre-trip email, the help centre, an agent's WhatsApp message. No code. The traveler leaves your product to apply and returns by email. It is the fastest thing here to launch and the easiest to walk away from if the numbers disappoint.
Embeddable components
Drop-in widgets (a requirements lookup, a checkout, a status panel) that you mount inside your own pages with a script tag and a few lines of configuration. The traveler stays in your booking flow while the provider renders the parts that touch passport data and payment. Most comparisons forget this middle path, and it answers the common case: you want the visa prompt on the passenger details page without building a document-upload interface. Elements is our version.
Full API
You call endpoints for requirements, application creation, document upload and status, and you build every pixel the traveler sees. Done properly, the provider is invisible except in the fine print. This is the only model that lets you put a visa in the same cart as seats, bags and insurance, and the only one where a conversion experiment is entirely yours to run.
Agent console
A category of its own, and one that API-led comparisons ignore. Counter staff and phone agents work nothing like a consumer checkout: they take a request from a customer on the line, often for a family of four, and need one screen that holds every file in progress and bills the agency account. If a good share of your sales happen human to human, this belongs in the evaluation.
The dimensions that decide it
Six things separate them. The rest is detail you can settle later.
| Dimension | Hosted storefront | Components | Full API | Agent console |
|---|---|---|---|---|
| Engineering effort | None | A script tag and a container | Front-end and back-end work | None |
| Time to live | Same day | Days | Weeks | Same day |
| Brand control | Your logo on their page | Your page, their widget | Complete | Your staff, their screen |
| Merchant of record | The provider | The provider | Either, depending on the licence | You, at a wholesale rate |
| Traveler data in your systems | None | None | Whatever you choose to store | None |
| Revenue model | Share of the service fee | Share of the service fee | Share, or a licence and a per-application rate | Wholesale rate, you set retail |
The honest trade-offs
The API buys conversion and costs weeks
Keeping the traveler inside your flow is the biggest single lever on attach rate: no redirect, no second checkout, no round trip through email. You also own the experience including its failures. When a passport photo is rejected for a shadow across the face, the traveler reads a message your team wrote and the ticket arrives in your queue. Budget for the happy path, then budget again for the states nobody sketches at kick-off: expired sessions, half-finished applications, a passport that differs from the one on the booking. Read the provider's documentation before you commit; ours is on the developer pages.
The hosted storefront ships today and shows its seams
A hosted storefront can be live the same afternoon, which is why it wins whenever the deadline is the binding constraint. The seams are worth naming before your brand team finds them: checkout happens on a subdomain, the confirmation email comes from an address that is not yours, and the provider is named on the card statement because card networks require the merchant of record to be named. For many businesses that is a fair trade for a revenue line that cost nothing to open. For an airline with a brand team, it is a conversation. Our hosted storefront page sets out where the line falls.
Components split the difference
You get booking-flow conversion without owning the application interface. The requirements answer and the checkout appear where the traveler already is, while document upload, validation rules and government submission stay with the provider. What you give up is the last few percent of control: layout is configurable within limits, and the copy inside the widget is written by someone else.
Nobody stays where they start
The realistic path runs in one direction. Launch hosted to find out whether your travelers buy visas at all. Add components on the two or three pages where the traffic actually is. Move to the API when volume justifies the engineering time. That sequence stays cheap only when one provider runs all of the models: then they are stations on one line, sharing an account, a catalogue and a settlement flow, and a move is mostly a change of surface. When each model comes from a different vendor, the same move is a re-platforming, with a new contract, a new integration and traveler records that may not come with you.
What to ask before you choose
- Can we change models without a new contract? If moving from hosted to API means a fresh agreement and another legal review, the plan to grow into it carries a cost nobody has priced.
- Does the price change per model, and in which direction? Some providers charge more for the API and treat it as the premium tier; some charge less because you are doing the work. Ask for both numbers at your expected volume, and whether consular fees are passed through at cost. Ours are; the arithmetic is on the pricing page.
- Who supports the traveler in each model? The answer moves with the merchant of record. Once you become the merchant, the "where is my visa" email becomes yours too.
- Who handles refunds and chargebacks? Ask about a government rejection specifically, the case that produces the angriest messages.
- What leaves with us? Application history, traveler records, requirement data. Ask before you sign.
Where to start
If you cannot name an engineering team with capacity this quarter, start hosted and prove the demand first. If you have the team and the visa moment sits inside a booking flow you control, components get you most of the conversion in days and the API gets you the rest. If your sales happen at a counter or on the phone, evaluate an agent console first. Our product overview shows how the four surfaces relate.