Sell the visa in the same checkout as the trip.
By the time someone reaches your payment step, your booking already knows the route, the dates and each traveler's nationality. That is everything a visa answer needs. Elements render the answer inside your own pages and take the order there, so the question never has to leave your funnel.
Four moments, and you can take them one at a time.
A visa question that goes unanswered on the page gets answered somewhere else. Usually on Google, usually on a lookalike site charging a markup over the government fee, and by then the traveler has left your flow. These are the four places to answer it first. Each one is an independent mount, and nothing later depends on anything earlier.
One badge per route
The badge element takes a nationality and a destination and renders a single line saying this route needs a document. On a route that needs nothing it renders nothing at all, so a clean itinerary stays clean.
The full requirements grid
This is the step where you already ask for nationality. Pass it along with the route and the layovers, and requirements answers per passport per country, with the slowest document called out first.
Attach before payment
The visa sits with bags and seats as something to add. The checkout element runs inside our iframe: passport scan, applicant details and card. Your own payment step is not modified.
Status where they already look
Confirmation page, manage-my-booking, order emails. The status element shows the same live timeline the traveler would see on our site, so your support team stops guessing.
The third moment, drawn out
One traveler, one layover long enough to leave the airport, one document and one all-clear. The visa card is the part your release adds; the rest of the page is yours.
Fictional brand. Everything inside the dashed outline comes from the requirements element; choosing to add opens checkout in a drawer on the same page. The full component list and the mount reference are on the Elements page.
What this costs your engineering team.
One script tag, 18 KB gzipped, no dependencies. Styles are scoped in both directions, so nothing of ours reaches your page and nothing of yours reaches the element. Sandbox keys are issued at signup, which means the first check can run before anyone books a call.
Four lines to a first check
A visa answer depends on the passport, the destination and every stop in between. Pass the layover with its duration and whether the traveler leaves the airport, and the transit rule is resolved explicitly. That is the case a lookup-only tool tends to miss.
Everything the element renders also sits on the public API, so a team that wants its own UI can call the same endpoints and skip the library entirely.
sv.mount('#visa', { element: 'requirements', nationality: 'FR', destination: 'KE', layover: ['QA'] });
Coverage per country, with the documents and processing times behind each one, is public on the destinations list.
The $39 service fee, and where it splits.
Revenue share is the model most booking flows start on, and it is free to join. SimpleVisa is merchant of record for the visa order, which is the detail that keeps this out of your finance and compliance queues.
$39 per application
One service fee per document, shared with you on volume terms. Consular fees are passed through at cost, so the traveler pays the same government price they would find on their own.
See the fee split →Nothing moves in your flow
The visa is charged on our licence as its own transaction, with SimpleVisa as merchant of record. Your gateway is not involved and the order never lands in your chargeback ratio.
One row per order
Every order appears in the partner console with its status and your share the moment it happens, and the monthly statement carries the per-order detail behind the number.
Look inside the console →Passport scans and card details are typed into our iframe and posted straight to us, so there is nothing new for your security review to scope. When a government is slow, or a traveler wants a refund, that conversation is ours as well: support and refunds sit on the SimpleVisa licence. The hosting and GDPR answers your legal team will ask for are on the trust center.
Scoping the business case before the integration? The version for OTA commercial teams works out what the fee is worth against traffic you already have.
What product teams ask before the first ticket.
Four that come up in every integration call, answered the way we would answer them on the call.
What happens on a route that needs no visa?
The badge renders nothing and the grid says so in plain words. A document-free itinerary is a real answer we return, per traveler and per country on the route, with the same confidence as a required one.
Who takes the traveler's payment?
On Revenue share, we do. The visa is a separate charge on the SimpleVisa licence, so your gateway stays out of it and the order never touches your chargeback ratio. If you want the charge on your own gateway under your own brand, that is the Platform licence.
What shows in our checkout if requirements are unknown?
An explicit unknown. The element falls back to an advisory line pointing at the government source, and no order can be started against it. An unknown is never rendered as a clean bill of health.
Our checkout is frozen for the next two quarters.
Then start after the booking instead. A hosted storefront on your own subdomain, linked from the confirmation email and manage-my-booking, needs no release inside your flow.
On that last one, the two routes around a frozen checkout are a storefront after the booking and a hosted checkout on your own domain. Both go live without a deploy in your flow.
Sandbox keys come with the account.
Mount requirements against test data this afternoon and swap the key when your release train allows. If the commercial case has to land first, a demo covers the fee split and what your team sees in the console.