Per-Tour vs Per-Guest eSIM Billing: Which Reconciles Cleaner for Tour Operators (2026)

Q: Which model do most tour operators use?

Small operators (<50 tours/year, family-run adventure companies, single-country DMCs): per-tour, because their whole accounting is per-tour. Mid-market operators (50–500 tours/year, multi-country adventure, cultural, expedition): mixed — per-tour for bundled connectivity, per-guest for optional add-ons. Large operators (500+ tours/year, e.g. G Adventures, Intrepid, Contiki): per-guest almost exclusively because it integrates with their existing per-booking reconciliation system.

Q: How does YonoSIM handle both models?

POST /v1/orders accepts a metadata field where you pass either {tourId: 'BX2024-Q3-045'} for per-tour billing, or {tourId, guestId, bookingId} for per-guest billing. YonoSIM's monthly usage report groups line items by whichever metadata key you specified, so your finance system pulls the exports in whichever shape your reconciliation flow expects. No provider-side flip required — the decision is purely in your integration code.

Q: What happens to billing on a cancelled booking?

Per-guest billing: refund is trivial — POST /v1/orders/:id/refund on the specific cancelled guest's eSIM order, YonoSIM credits the corporate balance, your finance system reconciles the credit against the guest's booking. Per-tour billing: refund is trickier because the eSIM was provisioned for a tour, not a specific guest — you either pro-rate the tour-level cost (accounting fiction, works if margins allow) or issue no refund on the guest's share of connectivity (usually acceptable for a fully-canceled guest since the eSIM was never sent to them).

Q: Does automatic no-usage refund work with both models?

Yes. YonoSIM's 30-day no-usage sweep fires on any order regardless of metadata shape. Under per-guest billing, refunds map cleanly to the guest's booking. Under per-tour billing, refunds credit the corporate balance and are typically re-attributed via ops-team monthly close (or absorbed as a small margin improvement on the tour, since the per-tour price already assumed 100% attach). The auto-refund is what makes per-tour billing safe to run — without it, unused eSIMs would compound as pure loss.

Q: Which model gives cleaner per-tour P&L visibility?

Per-tour, if your accounting is set up that way. The point of per-tour billing is that the tour operator's monthly close report shows connectivity cost as a single line per tour departure — same category as fuel, guide fees, permits. Per-guest billing produces the same total number but scattered across booking-level line items, which requires a rollup query to derive per-tour cost. If your ops team is already comfortable with rollup queries in Sabre/TrekSoft/RezMagic, per-guest is fine.

Summary

Match your eSIM billing to your existing tour accounting. If your finance team already reconciles per-tour (fuel, guide fees, permits per departure), use per-tour eSIM billing. If they reconcile per-guest (tour price, add-ons per booking), use per-guest. YonoSIM supports both via a metadata field on POST /v1/orders — the decision is purely which reconciliation shape your ops team wants for month-end close.

The decision tree in one table

If your ops team...	Use this model	Metadata shape
...runs monthly P&L per tour departure	Per-tour	`{ tourId }`
...runs monthly P&L per guest booking	Per-guest	`{ tourId, guestId }`
...offers optional add-on eSIM at booking	Per-guest	`{ tourId, guestId, isOptional: true }`
...runs tours under 20 guests bundled	Per-tour	`{ tourId }`
...runs tours 20+ guests with high cancellation rate	Per-guest	`{ tourId, guestId }`

Per-tour billing example: one line per departure

A 12-guest cultural tour in Vietnam issues one bulk eSIM order at booking-cutoff, ~14 days before departure. All 12 eSIMs provisioned in one script run:

// bulk-provision-per-tour.ts
const TOUR_ID = 'BX2024-Q3-045';
const guests = await getGuestsForTour(TOUR_ID);

for (const guest of guests) {
  await fetch('https://api.yonosim.com/v1/orders', {
    method: 'POST',
    headers: { Authorization: `Bearer ${process.env.KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({
      planId: 'apac_5gb_30d',
      customerEmail: guest.email,
      metadata: { tourId: TOUR_ID, tourName: 'Vietnam Cultural 12-day' },
    }),
  });
}
// End-of-month report groups by tourId → one line per tour departure

Month-end close report shape: Tour BX2024-Q3-045: connectivity $168 (12 × $14). Fits alongside fuel $520, guide $1,800,permits $340 — one row per line item per tour.

Per-guest billing example: line per booking

Same tour, per-guest model. Each POST is fired inside the booking-confirmation handler for that specific guest:

// on-booking-confirmed.ts
export async function onBookingConfirmed(booking: Booking) {
  await fetch('https://api.yonosim.com/v1/orders', {
    method: 'POST',
    headers: { Authorization: `Bearer ${process.env.KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({
      planId: 'apac_5gb_30d',
      customerEmail: booking.guest.email,
      metadata: {
        tourId: booking.tourId,
        guestId: booking.guest.id,
        bookingId: booking.id,
      },
    }),
  });
}
// End-of-month report groups by guestId → one line per booking

Month-end close report shape: Booking B45091 (guest Sarah H, tour BX2024-Q3-045): connectivity $14. Fits alongside tour price $2,890, single supplement $340, optional day-trip add-on $85 — one row per line item per booking.

Cancellation handling

The biggest operational difference between the two models is what happens on cancellation:

Per-guest: trivially reversible. POST /v1/orders/:id/refund on the cancelled guest's specific eSIM order → YonoSIM credits the corporate balance → your finance system reconciles the credit against the cancelled booking → guest sees the refund on their card. Total ops overhead: zero (webhook handler does it).
Per-tour: pro-rate or absorb. The eSIM was provisioned for the tour, not tied to a specific guest. Options: (1) auto-refund on any eSIM that stays unactivated past the tour departure date — YonoSIM's good-faith refund policy handles this natively for cancellations that happen before departure, (2) absorb into tour margin — usually acceptable because per-tour pricing already assumed 100% attach and the small cancellation-driven waste is a rounding error.

FAQ

QWhat's the actual accounting difference between per-tour and per-guest billing?

APer-tour billing generates one line item per tour departure — e.g. 'Tour BX2024-Q3-045 connectivity: $168 (12 guests × $14)'. It matches how you already reconcile per-tour costs (fuel, guide fees, permits) so the ops-team can eyeball a P&L per tour. Per-guest billing generates one line per guest per tour — e.g. 'Guest 4501 connectivity for tour BX2024-Q3-045: $14' × 12 lines. It matches how you reconcile per-guest costs (tour price, add-ons, refunds) so refunds and cancellations reconcile cleanly at the guest level.

QWhich model do most tour operators use?

ASmall operators (<50 tours/year, family-run adventure companies, single-country DMCs): per-tour, because their whole accounting is per-tour. Mid-market operators (50–500 tours/year, multi-country adventure, cultural, expedition): mixed — per-tour for bundled connectivity, per-guest for optional add-ons. Large operators (500+ tours/year, e.g. G Adventures, Intrepid, Contiki): per-guest almost exclusively because it integrates with their existing per-booking reconciliation system.

QHow does YonoSIM handle both models?

APOST /v1/orders accepts a metadata field where you pass either {tourId: 'BX2024-Q3-045'} for per-tour billing, or {tourId, guestId, bookingId} for per-guest billing. YonoSIM's monthly usage report groups line items by whichever metadata key you specified, so your finance system pulls the exports in whichever shape your reconciliation flow expects. No provider-side flip required — the decision is purely in your integration code.

QWhat happens to billing on a cancelled booking?

APer-guest billing: refund is trivial — POST /v1/orders/:id/refund on the specific cancelled guest's eSIM order, YonoSIM credits the corporate balance, your finance system reconciles the credit against the guest's booking. Per-tour billing: refund is trickier because the eSIM was provisioned for a tour, not a specific guest — you either pro-rate the tour-level cost (accounting fiction, works if margins allow) or issue no refund on the guest's share of connectivity (usually acceptable for a fully-canceled guest since the eSIM was never sent to them).

QDoes automatic no-usage refund work with both models?

AYes. YonoSIM's 30-day no-usage sweep fires on any order regardless of metadata shape. Under per-guest billing, refunds map cleanly to the guest's booking. Under per-tour billing, refunds credit the corporate balance and are typically re-attributed via ops-team monthly close (or absorbed as a small margin improvement on the tour, since the per-tour price already assumed 100% attach). The auto-refund is what makes per-tour billing safe to run — without it, unused eSIMs would compound as pure loss.

QWhich model gives cleaner per-tour P&L visibility?

APer-tour, if your accounting is set up that way. The point of per-tour billing is that the tour operator's monthly close report shows connectivity cost as a single line per tour departure — same category as fuel, guide fees, permits. Per-guest billing produces the same total number but scattered across booking-level line items, which requires a rollup query to derive per-tour cost. If your ops team is already comfortable with rollup queries in Sabre/TrekSoft/RezMagic, per-guest is fine.

Bottom line

Pick per-tour if your finance already reports per-departure (small + mid-market adventure ops). Pick per-guest if your finance reports per-booking (large operators, optional-add-on model, high cancellation rate). YonoSIM's metadata field supports both natively — the decision is your side, not the provider's. Back to the Tour operators hub.