A visa processing system is the stack that takes a traveler from “this trip needs a document” to “the document is issued”: requirements data, application intake and validation, government submission, status tracking, and payment. Any business selling travel across borders already touches part of that stack, even if its only involvement is emailing a passenger a link. The question worth spending time on is which of the five layers you run yourself and which you buy.
This guide takes each layer in turn, sets out which kinds of business need which, and lists what to ask of any system claiming to provide them. For the traveler-side mechanics of a single application, see our guide on how an electronic visa works.
The five layers
1. Requirements data
The first layer answers a narrow question: what does this passport need for this route? Not “what does Vietnam require”, but what a Brazilian passport holder flying to Hanoi via Doha requires, including whatever the Doha stop carries in its own right. Nationality, destination, purpose of travel, length of stay and every transit point feed the answer. This is why a country-level table works until the first itinerary with a connection in it, and then quietly stops working.
The difficulty is keeping it current. Governments change fees, open and close electronic schemes, add nationalities, suspend others, and almost never publish any of it in a form a machine can read. Requirements data is therefore a running operation: someone has to watch the sources, and freshness is the whole value of the layer. Our own requirements checker is the public face of this one.
2. Intake and validation
Intake is the form the traveler fills in, the photo they upload, and the passport page they photograph in a taxi. Validation is everything that catches an error before a government sees it: a photo that fails a pixel or background specification, a name that does not match the passport’s machine-readable zone, a passport expiring inside the destination’s validity window, a date sequence that contradicts the ticket.
This layer decides approval rates. Most refusals of electronic permits are mechanical, which means they are catchable at the point of entry. A system with shallow validation passes them through and finds out days later, as a government rejection, by which time the consular fee is spent and the traveler is closer to departure.
3. Government submission
Submission is filing the application with the destination’s own system, and it is the operational core that nobody outside the business ever sees. Some governments publish a modern portal. Some publish one that times out after eight minutes, accepts cards only from a shortlist of issuers, or rejects uploads above a size limit it does not state. Some still expect a courier and a paper form. All of them change without notice, and a change that breaks filing for one destination stops every application queued behind it.
The work here is operational, and it never finishes. It comes down to people who notice at 09:00 that a portal has moved, and who know which of the queued applications have to be refiled before the day is out.
4. Status and communication
Once an application is filed, two audiences need to know where it is: the traveler, who wants to know whether the visa will arrive before the flight, and the business, which wants the same fact in machine-readable form to update an order or brief a support agent. This layer is webhooks, status endpoints, and the messages that go out on approval, refusal or a request for further documents.
Underinvesting here is expensive: every application without a status feed becomes a support ticket asking where the visa is. Our API documentation shows the shape this takes.
5. Payment and settlement
Every application carries at least two amounts: the consular fee the government charges, and a service fee for handling. Keeping them separate on the receipt is the honest arrangement, and it is what separates a legitimate service from the lookalike sites that fold an undisclosed markup into the government fee. SimpleVisa passes consular fees through at cost and states its own service fee alongside them.
The harder half is what happens afterwards. Governments refuse applications and keep the fee. Travelers cancel trips, dispute charges and ask for refunds. Whoever is merchant of record carries that exposure and the card-network obligations attached to it, which is the first thing to establish about any visa system.
Which layers a business actually needs
Few businesses need all five. What you need follows from where the visa question surfaces in your product.
| Business | Needs | Can leave alone |
|---|---|---|
| Online travel agency | Requirements at search and confirmation, plus a checkout it can attach to a booking | Submission, status, payment, traveler support |
| Agency counter or call centre | One screen an agent can work from, at a wholesale rate it can resell at its own price | Portals, per-country rules, document handling |
| Airline | Requirements at booking, and document verification at check-in | The application itself, in most cases |
The pattern holds. The layers a travel business wants to own sit close to the traveler and the booking. The ones it wants to hand over are those that mean staffing a relationship with eighty governments.
Building it yourself
Building is a reasonable choice at sufficient volume, and it is worth being clear about what it involves. Requirements data means a permanent research function, because coverage decays from the day it is published. Submission means integrating with government systems that were never designed for integration, then maintaining those integrations against changes you learn about from a failure. The twentieth destination is no cheaper to add than the fifth.
The part that surprises people is compliance. Running intake means passport scans, biometric photographs and dates of birth land in your systems, in scope for your security review, your retention policy and your regulator. Handling payment puts the consular fee and the refusal case on your merchant account. Both are manageable, and both are more work than the engineering.
Buying moves that work elsewhere and replaces it with a smaller job: evaluating vendors on the layers above. The commercial side of the decision is covered in our guide to visa ancillary revenue.
What to evaluate in any system
- Data freshness, with receipts. Ask when the requirement records for three specific destinations were last verified, and against which source. A vendor that maintains its own coverage can answer in a sentence.
- Validation depth. Ask what the system rejects before filing, particularly on photographs and passport validity. Approval rates live here.
- Transit handling. Give it a real itinerary whose connection carries a requirement of its own, and see whether the answer includes it.
- Merchant of record. Establish who appears on the traveler’s card statement, who issues the refund, and who answers the chargeback.
- Refusal handling. Ask what happens when a government says no: who tells the traveler, who refiles, what is refunded and what is not.
- Access model. Whether you can get sandbox credentials and read the documentation today, or whether a sales call sits between you and the first API response.
How SimpleVisa is arranged
We run all five layers. Requirement data covers 190+ destinations, resolved per passport and per route with transit stops included; more than 80 of those we process end to end, from intake through government submission to the issued document. Partners take the layers they want: requirements alone, requirements plus an attached checkout, an agent console for counter and phone orders, or the Platform licence, where the partner is merchant of record. Consular fees pass through at cost in every model, and getting a sandbox key does not involve talking to a salesperson first. The surfaces are described on our product page.
Whichever way the decision goes, the five layers are the useful unit of analysis. Work out which ones you want to own, then check what any given system actually covers. Whatever it leaves out becomes yours to staff.