Refunds, cancellations & claims

This page explains what happens after a sale when something changes: the customer cancels their trip, cancels the insurance, files a claim, or asks for a refund. It covers the effect on the policy and premium, how your commission is treated, the (current) manual process where automation doesn’t yet exist, and exactly where your support responsibility ends.

For the events you receive and how money is represented, read /reference/webhooks/ and /operate/commission-and-payouts/ first. For the in-iframe checkout signals referenced below, see /reference/events/.

The short version. There is one outbound webhook — policy.issued. There is no cancellation or refund webhook today, so cancellations, refunds, and commission clawbacks are handled manually by Expedition Insure. Customers never claim through you: claims go to the carrier (or to us at help@expedition.insure), never to the operator.

1. Two different “cancellations”

“Cancel” means two unrelated things. Keep them separate — they have different effects on the policy and the premium.

Scenario	What the customer is cancelling	Effect on the policy	Effect on the premium
Customer cancels the trip	The expedition itself (e.g. the voyage is called off)	The policy stays in force; the customer may file a claim for their prepaid, non-refundable trip costs under trip-cancellation coverage	Premium is not refunded — it bought the coverage that now pays out
Customer cancels the insurance	The Expedition Insure policy	The policy is voided or refunded per the carrier’s free-look / cancellation terms	May be refunded in whole or part, depending on carrier terms and timing

The distinction matters because a cancelled trip is usually a claim, not a refund — the policy did its job. A cancelled policy is a refund/void question. Route the customer accordingly (see §4).

CFAR (cancel for any reason)

Some plans include or offer a CFAR upgrade. CFAR lets the customer cancel the trip for reasons not otherwise covered and recover a percentage of prepaid costs as a claim — it does not refund the insurance premium. CFAR has strict eligibility (purchase windows, cancellation-deadline rules, percentage caps) set by the carrier.

Quote CFAR terms verbatim. Never paraphrase or summarize a carrier’s CFAR percentage, deadlines, or eligibility. If a customer asks “is CFAR included?”, point them to the carrier-approved plan wording or to us at help@expedition.insure — do not improvise the answer.

2. What happens to your commission

Your commission is tracked in a per-sale ledger row created when an attributed payment succeeds. Each row carries a status. Refunds and voids affect that status — and therefore what you’re owed.

Ledger status	Meaning	Counts toward what you’re owed?
provisional	Recorded at payment, before carrier confirmation	Yes (owed)
confirmed	Premium confirmed at carrier issuance	Yes (owed)
paid_out	Settled to you (out-of-band, monthly)	No (already paid)
voided	Reversed — e.g. refund or policy cancellation	No

The commission base is the gross attributed premium (quote.actualPremium, whole dollars), multiplied by your commissionRateBps (basis points). A promotional credit reduces what Expedition Insure collects, not what you’re owed.

Clawback on a refund or void

When a policy is refunded or cancelled, the commission for that sale is reversed — the ledger row moves to voided and no longer counts toward your commissionOwedUsd. If it had already been paid out to you, the amount is reconciled against a future payout (a clawback).

3. [needs-product-work] the current manual process

There is no cancellation or refund webhook today. The only outbound event is policy.issued. There is no policy.cancelled, policy.refunded, or commission.voided.

sale            →  policy.issued  webhook  →  you receive it
refund / cancel →  (no webhook)            →  you are NOT notified automatically

Until those events exist, here is how a cancellation or refund is handled end-to-end:

1. The customer (or you) requests the change. A trip-cancellation claim, a policy cancellation, or a refund request comes in. The customer contacts the carrier (claims) or Expedition Insure at help@expedition.insure (refunds, policy cancellations).
2. Expedition Insure processes the refund or void against the carrier’s terms and the original Stripe payment. Expedition Insure is the Merchant of Record, so the refund is issued on our payment rail.
3. The commission ledger is reconciled manually. The affected ledger row is moved to voided and the clawback is applied to your next payout. There is no automated trigger and no notification.
4. You reconcile your own records by polling. Because no webhook fires, re-read your attribution and commission figures from the portal/API after the change — see /operate/commission-and-payouts/. Treat your stored totals as a cache that may be stale until you re-poll.

Don’t rely on payment.succeeded for reconciliation. The payment.succeeded event from the in-iframe checkout is a UX-only signal — it can be missed and is not authoritative for money. The authoritative post-sale signal is the policy.issued webhook; for refunds and voids there is no signal at all yet, so reconcile by polling. See /reference/webhooks/.

What you should build for now

• Dedupe and store by eventId. policy.issued is delivered at-least-once with retries; persist each policy keyed on eventId.
• Don’t infer cancellations from silence. The absence of a follow-up event does not mean a policy is still active. Re-poll your commission totals on a schedule.
• Surface a support contact. Put help@expedition.insure in front of any customer asking to cancel or claim, rather than handling it yourself.

4. Claims — who the customer contacts

A claim is a request for the policy to pay out (medical, trip cancellation, delay, baggage, CFAR, etc.). The operator is never the claims handler. Your support boundary stops at routing the customer to the right place.

customer has a claim
        │
        ├─ medical / trip-cancellation / delay / baggage / CFAR
        │        → the CARRIER named on their policy documents
        │          (claims contact + policy number are on the policy)
        │
        └─ can't find their policy, general question, refund/policy cancellation
                 → Expedition Insure: help@expedition.insure

Who	Handles	How the customer reaches them
Carrier	The claim itself — adjudication, payout, documentation	Claims contact + policy number on the customer’s policy documents
Expedition Insure	Policy lookup, document re-sends, refunds, policy cancellation, “who is my carrier?“	help@expedition.insure
You (the operator)	Routing only — point the customer to the carrier or to us	Your existing support channel

Your support boundary

• Do route customers: tell them to use the claims contact on their policy documents, or email help@expedition.insure if they’re stuck.
• Do not adjudicate claims, quote payout amounts, confirm coverage applies to a specific situation, or promise a refund. You are not the insurer and not a licensed advisor.
• Do not paraphrase coverage or CFAR terms when a customer asks whether something is covered. Quote carrier-approved wording verbatim or hand off to us.

Required disclosure. The embedded experience is an AI-assisted quote tool, not a licensed advisor; estimates are non-binding. Always offer a human at help@expedition.insure. Keep this disclosure intact in any support copy you write around the embed.

Related

• /reference/webhooks/ — the policy.issued payload, signing, and at-least-once delivery.
• /reference/events/ — the payment.succeeded / payment.failed UX signals from the iframe.
• /operate/commission-and-payouts/ — how commission is calculated, owed, and paid out.