Cancellation Policies and Product Variations — Capability Documentation

Cancellation is where booking platforms quietly leak revenue, customer trust, and staff time. A flexible fare that gives a full refund the morning of departure. A non-refundable saver that the reservations team refunds anyway because the rules are buried somewhere only one staff member remembers. A weather day that turns into a multi-day support backlog because there's no template for issuing credits at scale.

JetSetGo's approach makes cancellation a deliberate revenue lever rather than a hidden cost. The platform supports multiple cancellation policies per product, surfaced to the customer at the moment of booking through the product-variation selection — so the customer chooses which policy applies (typically by paying more for more flexibility), and the operator captures the extra revenue from customers who genuinely value the flexibility.

This doc covers what the policy engine models, how policies attach to products through variations, the time-banded refund tier mechanics, and what happens operationally when the cancellation actually fires.

Who this matters to

• Operators who currently lose revenue to flexible-fare refunds with no compensating premium charged for that flexibility.
• Operators who manually handle every cancellation because the rules are too varied to encode in a one-size-fits-all field.
• Operators selling through multiple channels with different OTA cancellation requirements that need to coexist with their direct-website rules.
• Operators whose customers ask for "the flexible option" but who don't currently offer a structured way to sell it.
• Operators running weather-affected or seasonally disrupted services who need a repeatable flow for issuing credits across many bookings at once.

The variations model — multiple policies for the same product

JetSetGo lets operators offer the same underlying product (a tour, a ferry sailing, a cruise berth, a cabin night, a coach seat) under multiple variations. Each variation is its own bookable option that shares the same physical service but carries its own combination of:

• Price. Variations are priced independently. A "Fully Flexible" variation costs more than a "Non-Refundable Saver" for the same seat.
• Cancellation policy. The defining feature in most operator catalogues. Different variations point at different cancellation policies.
• Bundled add-ons (optionally). A premium variation can include normally-priced add-ons at no extra charge — a coffee included with the Premium Ferry Fare, a luggage allowance included with the Flexible Coach Fare, a complimentary breakfast included with the Premium Cabin.
• Inventory restrictions (optionally). A variation can cap how many of itself sell on a service without affecting the overall capacity — useful for limiting how many "Value Deal" tickets get released.
• Channel restrictions (optionally). A variation can be available on some channels and not others — for example, a trade-only variation that doesn't appear on the public website.

At the booking step, the customer sees the available variations side by side ("Standard $35 — 50% refund up to 24h", "Flexible $45 — full refund up to 1h before"). The customer picks one. The platform records which variation was selected; the policy that variation points at governs the booking from there.

The revenue lever is real: customers who plan to definitely travel pick the cheaper non-refundable option; customers who want insurance pick the flexible option and pay the premium. Without variations, operators usually pick one position (all-flexible loses money to refunds, all-non-refundable loses customers to platforms that offer flexibility) — variations let operators sell both at once.

How cancellation policies are structured

A cancellation policy is a named operator-defined refund rule. Each policy has a clear customer-facing name ("Fully Flexible", "Standard — Save 20%", "Non-Refundable", "Group Charter Terms") and one or more time-banded refund tiers that decide what gets refunded based on how close to the service the customer cancels.

A tier defines:

• A time window — measured in hours before the service departs. "More than 168 hours before departure" (more than a week). "Between 48 and 24 hours before departure". "Less than 12 hours before departure".
• A refund percentage — what fraction of the booking total to refund inside that window. 100% (full refund), 75%, 50%, 25%, 0% (no refund). Operators decide.
• A fee deduction (optionally) — a flat administrative fee deducted from the refund regardless of percentage. Useful for covering processing costs.
• A credit-vs-refund decision (optionally) — whether the refund is paid as cash or issued as a credit valid for a future booking. Operators can configure both for the same tier (the customer gets the choice at cancel time) or force one over the other.

A typical "Flexible" policy might look like:

A typical "Non-Refundable Saver" policy might look like:

The tiers don't have to follow a fixed schema. Operators define however many bands they want, with whatever windows match how their customers actually behave.

Multiple policies per product, per variation

The relationship is straightforward: each product variation points at one cancellation policy. The customer's choice of variation is implicitly a choice of cancellation policy. The system records both.

This means a single ferry service can carry:

• A Standard fare pointing at a "Standard" policy (50% refund up to 24h, 0% thereafter).
• A Flexible fare pointing at a "Fully Flexible" policy (100% up to 1h before).
• A Non-Refundable Saver pointing at a "Non-Refundable" policy (0% refund any time).
• A Trade Account Group Booking pointing at a "Group Charter Terms" policy with longer windows and different deductions.

All four are bookable on the same sailing through the same inventory. The platform tracks which variation each customer picked and applies the right policy at cancel time. The reservations team doesn't have to remember which fare maps to which rule — the system surfaces it automatically when the customer initiates a cancellation.

Operator-initiated cancellation — disruptions and force majeure

The customer-initiated path is one half of the picture. The other is when the operator cancels a service: bad weather, mechanical issue, low bookings forcing a route consolidation, a regulatory closure. The platform supports operator-initiated cancellation at the service level, where the rules differ from the customer-initiated tiers above.

When an operator cancels a service:

• All bookings on that service are affected at once. The operator doesn't have to process each booking individually.
• The refund rule is configured separately from the customer-initiated tiers. Operator cancellations typically default to 100% refund regardless of how close to departure the cancellation happens — the customer's policy choice doesn't penalise them when the operator is the party cancelling. Operators can override this for force-majeure scenarios where industry-standard practice is credit-only or re-accommodation rather than refund.
• Credit issuance can be done at the service level too — a weather day that issues 100% credits across every passenger on the affected sailing, with credits valid for a year.
• Re-accommodation is the related operational flow — moving passengers from a cancelled sailing to the next available one. The platform supports both refund-and-re-book and direct re-accommodation patterns.

The audit trail records every state change. Who cancelled, when, with what reason, what refunds or credits issued, what payment mechanism. For operators in regulated environments (council-funded ferries, route-licensed coach services, accredited tour licensing) this audit data is what passes the audit. For operators in commercial environments, it's what the bookkeeper uses.

Per-fare-type rules within a single policy

A single cancellation policy can also vary its tiers per fare type within the policy. Where the operator wants the "Standard" policy to refund 100% to children but only 75% to adults, that's encoded in the same policy. Where a freight-trade vehicle fare has different windows than the same policy's passenger fare, that's encoded too.

This avoids exploding the policy count — instead of "Standard Passenger", "Standard Child", "Standard Freight", "Standard Vehicle", the operator runs one "Standard" policy with internal tier variations per fare type.

Where refunds actually go — credit vs cash vs voucher

Refunds aren't a single transaction type. The platform supports:

• Original-payment-method refund. Refund the original card; the customer sees a credit back to the same payment method they originally used. This is the path that matches customer expectation and minimises support load.
• Operator credit / voucher. The refund value is held as an operator-issued credit, redeemable against a future booking. Operators can configure the validity period (12 months is common), whether it's transferable (some are; most aren't), and which products the credit can be applied to.
• Bank transfer or invoice credit for trade-account customers, where the original payment was on credit terms and the refund needs to flow through the accounting system.
• No refund (forfeit) with audit trail. Some policies and some tiers issue no refund. The platform records the cancel event and the zero-refund outcome so it's auditable later.

The mechanism per tier is operator-configurable. Many operators run "credit only" in the closest-to-departure tiers (encouraging re-booking rather than a hard refund) and "cash refund" in the further-out tiers (where the customer's reason for cancelling is more likely to be unrelated to the operator).

A worked example — a multi-product tour operator's policy stack

Consider a tour operator running day tours, multi-day liveaboard trips, and a vehicle-ferry connection. Their policies might look like this:

Day tour standard fare (default variation):

• More than 48 hours: 100% refund
• 24–48 hours: 50% refund
• 0–24 hours: 0% refund or 50% credit (customer's choice)

Day tour saver (cheaper variation):

• More than 14 days: 50% credit
• 0–14 days: 0% refund

Day tour flexible (premium variation, also includes a coffee voucher):

• More than 1 hour: 100% refund
• 0–1 hour: 100% credit

Liveaboard standard:

• More than 30 days: 100% refund minus $50 admin fee
• 14–30 days: 50% refund minus $50
• 7–14 days: 25% credit only
• 0–7 days: 0% refund

Liveaboard flexible (premium, includes wetsuit hire):

• More than 7 days: 100% refund
• 1–7 days: 50% refund
• 0–1 day: 25% refund

Vehicle-ferry vehicle fare:

• More than 4 hours: 100% refund
• 0–4 hours: 75% credit only

The customer picks the variation that matches their certainty about travelling. The flexible variations command a premium that covers the operator's expected refund cost; the saver variations sit below the standard rate and lock the customer in.

When the weather cancels a liveaboard sailing, the operator runs a service-level cancellation that overrides the variation-specific rules: every passenger across every variation gets a 100% credit valid for 12 months, issued in one operator action. The audit trail captures the weather-cancellation event and shows the credit issued to each customer.

What the policy engine doesn't try to be

• It isn't insurance. The platform supports refund policies; if customers want third-party travel insurance for non-covered scenarios, that's a separate product the operator can sell as an add-on.
• It isn't a chargeback dispute system. Refunds are operator-initiated through the platform. Card disputes are handled by the payment processor, not here, though the platform's audit trail provides the evidence operators need to respond.
• It isn't a regulatory framework substitute. Where consumer-protection rules (statutory cooling-off periods, mandatory force-majeure refunds in some jurisdictions) override what the policy says, those overrides happen outside the platform. The platform supports whatever the operator configures; staying compliant with applicable consumer law is the operator's responsibility.

How this composes with other capabilities

• Pricing engine — variations are part of pricing too. The same variation that sets the cancellation policy also sets the price difference between Standard, Flexible, and Saver.
• Channel management / inventory allocation — different variations can be available on different channels. The OTA can sell the Standard and the Saver but not the Flexible if the operator chooses to keep flexibility direct-only.
• Durational and multi-sector services — when a reservation spans multiple services (a multi-night cruise, a multi-leg journey), the cancellation policy operates on the whole reservation, not each underlying service.
• Multi-modal packages — packages can carry their own variation-level policies; cancelling a package refunds across all the legs at the package's policy, not the legs' individual policies.

Where to go next

• Tour operator software — the broader pillar where variations and policies carry the most revenue weight.
• Ferry booking system — variations on ferry fares (passenger + vehicle).
• Cruise booking platform — cancellation handling for multi-night accommodated services.
• Pricing engine — the variation system from the pricing side.

Book a demo →

Cancel anytime. You own your data.