Attach rate is a small number multiplied by a large one, which is why it ends up on the slide with no working shown. The useful version of that conversation skips the benchmark and starts with the arithmetic, so here it is, worked from the top on a book of 60,000 bookings a year.
Attach rate is applications divided by total bookings. The denominator is everything you sell, including the domestic hop and the intra-Schengen weekend where no traveler needs anything at all. That choice does most of the work in this calculation, so it is worth settling before any of the rest.
Start with the denominator
A visa requirement is a function of two things: the passport and the route, transit stops included. Long-haul departures into destinations running an e-visa or an electronic authorisation produce most of them. The rest of the book produces nothing, and no amount of placement work will change that.
This is also why two sellers with identical volume can have very different ceilings. A book weighted towards Europe with a European passenger base has a thin eligible slice. A book with long-haul departures out of a mixed-nationality market has a thick one, and the same 4% target is a different amount of work in each case. Before you set a number, look at what your top twenty route and nationality pairs actually require, because that is the pool everything else is drawn from.
The same integration can therefore be reported two ways. Against every booking you sell, a healthy visa line lands in low single digits. Against only the bookings where somebody genuinely needs a document, the same applications look several times better. Both figures are honest. Mixing them in one review is how a team ends up arguing about performance when it is actually arguing about definitions.
The worked example below uses the first definition, because that is the one a commercial director has to defend: 4% of everything, not 4% of a slice chosen after the fact.
The pool, and who it belongs to
On the revenue-share model the traveler pays a $39 service fee per application, so 2,400 applications produce a $93,600 pool across the year. The partner's share of that pool is set by volume terms, which is why the table stops at the pool. Your own line comes out of the calculator on the pricing page once your volumes are in it.
The consular fee sits outside all of this. It is collected at cost and paid to the government at cost, and it never enters anyone's margin. Keep the two lines apart when you model this. Conflating them is the quickest route to a revenue figure you later have to walk back.
What makes the arithmetic unusual for an ancillary is the cost side, which for the partner is empty:
What moves the number
Four inputs, in roughly the order they matter. The shape of this list is the part we see repeat across integrations, whatever the absolute numbers do.
Where the requirement appears. A requirement shown in search results or on the itinerary page gets acted on. The same sentence in a confirmation email is read once, in the minute after payment, when the traveler is thinking about everything except paperwork. Placement is the largest single input here and it is not close.
Nationality captured before payment. The requirement depends on the passport, and billing country is a poor stand-in for it. If you only learn nationality at check-in, you cannot tell the traveler anything useful while they are still in a position to buy.
Transit stops resolved. An itinerary with a stop that carries its own requirement is where most requirement tools return nothing. It is also where the traveler has no idea there is a question to ask, which makes it the cheapest attach in the book once you can answer it.
Pre-trip re-contact. The week-of-travel email and the itinerary view pick up the people who ignored the subject entirely at booking. It is the easiest placement to add and the one most books are still missing.
These compound in one direction only. Nationality capture makes the search-level placement possible, the search-level placement makes transit resolution visible, and the pre-trip email works on whoever survived all three. A team that adds the reminder first and the nationality field last will spend a quarter wondering why the reminder underperformed.
Attach rate is a placement metric long before it is a product metric.
Getting from one placement to four
A first integration is usually a single placement: a checkout link on the confirmation page. That lands in low single digits, and it should. One placement, opened once, arriving at the moment the traveler has just finished paying for something else.
The 4% in the table describes a booking flow that surfaces requirements earlier: at search, so the document is visible while the itinerary is still being chosen, and on the itinerary itself, which people reopen in the week before departure. Across the integrations we run, the distance between the confirmation-only setup and the search-level setup is wide enough that placement work outperforms anything you could do to the visa product itself.
Seats and bags attach at rates a visa line will never reach, and that comparison flatters them until you look underneath. Both carry a cost of goods and an operational path for when something goes wrong. The visa line carries neither for the partner, which makes contribution per booking the honest way to line these products up against each other.
Agencies working on Desk run a simpler version of the same sum. They buy at wholesale, $29 an application sliding to $19 at volume, and set their own retail price, so margin is retail minus wholesale on every sale and the attach question moves from placement work to what gets said at the counter.
What to instrument
Most attach-rate arguments are really measurement arguments. Four fields settle them:
Every GET /v1/requirements call already tells you whether the passport and route produce a requirement. Store that flag on the booking and you can report attach against eligible bookings and against the whole book without estimating either. The same response drives the requirements checker on our own site.
When attach goes flat, the cause is almost always upstream of the checkout. Nationality is missing on a large share of bookings, or the requirement is rendering on a page that gets one open. Both show up in the four fields above, and both are changes to your booking flow, which is where the fix has to happen. Work them in that order and the arithmetic at the top of this note looks after itself.