Visa processing has moved through three architectures: the consulate queue, the government web portal, and the API layer that now lets any travel business embed the process inside its own booking flow. Each shift changed who does the work rather than what the work is. Governments still set the rules, still want the same passport page and the same photograph against the same background, and still make the decision. What moved is where the form gets filled in, who catches the errors before submission, and who answers the traveler when a week has passed and nothing has happened.
Era one: the consulate queue
For most of the last century a visa was a physical file. The applicant booked an appointment at a consulate or an outsourced application centre, arrived with printed forms, bank statements and photographs cut to a specific size, and handed over the passport itself. Agencies with volume ran couriers: someone carried a batch of passports across a city, queued, and carried them back days later. Turnaround was measured in weeks, and the binding constraint was appointment capacity.
That made visas an offline service with a per-file labour cost. The handling fee an agency charged was, in substance, payment for somebody's morning in a queue, and scaling meant hiring.
Era two: the government portal
Governments began taking applications online directly, one country at a time. Australia's Electronic Travel Authority arrived in 1996 and is generally credited as the first. The United States made ESTA mandatory in 2009, Turkey opened its e-Visa system in 2013, India followed in 2014, Canada's eTA became compulsory in 2016, and the United Kingdom began phasing in its ETA from 2023. What each of these actually produces is covered in how an electronic visa works.
This removed the courier and the queue, then pushed the remaining work onto whoever was filling in the form. Every portal is its own product, built by a different ministry under different constraints, and no two behave alike. Photo specifications differ in pixel dimensions, background colour and head-height ratio. Session timeouts range from generous to punishing. Some portals reject a surname containing an apostrophe. Some return a decision in minutes and some go quiet for a fortnight.
A traveler meets one portal once and absorbs the friction as a bad afternoon. A business filing a hundred applications a month meets forty portals repeatedly, and that friction compounds into a staffing problem. The portal era concentrated the operational burden on whoever files often.
Era three: the API layer
The current architecture puts one integration in front of many portals. A travel business calls a single endpoint with a passport nationality and a route, and gets back the documents that route requires. It submits through the same interface, and the vendor handles the country-specific form mapping, the photo resizing, the payment to the government, the retries when a portal is down at three in the morning, and the parsing of whatever comes back.
The per-country quirks did not disappear. They were absorbed by a party that pays the cost once and spreads it across every partner, which is the entire economic argument for the layer. What a travel business actually integrates is described on the product page, and the endpoint detail sits in the developer documentation.
What actually got automated
- Validation before submission. Field checks and photograph analysis run before an application reaches a government: the wrong background colour, the truncated middle name, the passport expiring two months after the return flight. This is the largest single lever on approval rates, because most refusals are triggered by a paperwork fault the applicant could have fixed in thirty seconds.
- Requirement lookups. The photocopied requirement sheet, usually months out of date, became a query. A booking system asks what a Brazilian passport holder needs for Vietnam with a stop in Doha and gets a structured answer while the traveler is still on the page, transit leg included.
- Status reporting. Webhooks push state changes into the partner's own system, so an agent sees submitted, processing and issued without logging into anything. It is the dullest item here and it removes the most support tickets, because "where is my visa" is the most common question any visa operation receives.
What did not get automated
Vendors tend to be vague here, so it is worth being exact.
- Governments still decide. No API approves a visa. It prepares, submits and tracks. Adjudication happens inside a ministry, on the ministry's timetable, against criteria it does not publish.
- Human review still exists. Machine checks catch format problems. They do not catch an illegible scan, a travel history that needs a covering letter, or an applicant whose circumstances fit none of the dropdowns. A person reads those.
- Stuck applications still need somebody. When a portal returns an error nobody has seen before, or an application sits untouched past every published timeline, the fix is a human who knows that portal, that consulate and often that specific mailbox.
What changed for each kind of travel business
Travel agencies
Agents stopped re-typing customer data into government portals. What remains is advisory work: telling a client the trip needs a visa, knowing when a timeline is too tight, handling the awkward cases. The typing, the payments to forty separate government gateways and the reconciliation afterwards moved into software.
Online travel agencies
Visas became an attachable product. Someone who has just booked a flight to India is at their most motivated to deal with the visa, and an OTA that stays silent at that moment sends them to a search engine where a lookalike site is waiting with a markup. Offering the application inside the booking flow keeps the customer and earns a fee on a sale that has already happened.
Airlines
Requirements moved from the gate to the booking screen. A carrier that surfaces document rules when the ticket is sold has fewer passengers turned away at check-in. Denied boarding costs twice: the rebooking, and the fine many destination governments levy for carrying an inadmissible passenger.
The honest limits
Rules change without notice. A ministry publishes a circular on the Thursday, a fee changes on the Monday, and there is no feed to subscribe to. Technology shortens the gap between a change happening and your systems reflecting it. It has no influence on whether the change happens at all.
Which is why a credible claim about requirement data rests on a verification routine, and the routine is dull: monitor the official sources on a schedule, diff what changed against what you published, and have somebody confirm anything ambiguous before it reaches a traveler. Ours is described in how three people track sixty governments.
It is a fair question to put to any vendor: how often is each country checked, who checks it, and what happens between a government changing something and the update landing in the API response. If the answer describes a schedule and a named process, the data is probably current. If it only names a technology, assume otherwise.