Regulatory, MoR, and disclosures

How insurance distribution works when you embed Expedition Insure, who the merchant of record (MoR) is for the insurance charge, and the customer disclosures you must preserve verbatim. For partner and operator teams, compliance reviewers, and AI-agent builders who need to know what they are — and are not — responsible for.

For the integration mechanics this page assumes — the iframe, the ei:* events, and the server-side Origin allowlist — start with the embed integration guide. For what personal data crosses the boundary, GDPR/CCPA posture, and how to get a DPA, see data, privacy, and DPA.

Not legal advice. This page describes how the integration behaves today, grounded in the running system. It is not a contract and not a regulatory opinion. For licensing specifics, a signed agreement, or jurisdiction-specific commitments, email help@expedition.insure.

1. Distribution and licensing posture

Expedition Insure operates the quote-and-bind flow end to end. When a traveler gets a quote and buys a policy through the embed, the insurance relationship, the carrier-facing distribution, and the charge are all handled by Expedition Insure — not by you.

What that means for your integration:

• You are a referrer, not a distributor of record. Your site or agent surfaces the quote flow and (optionally) earns a commission on attributed sales. The licensed distribution activity — presenting carrier products, binding coverage, collecting premium — happens inside our frame and on our backend.
• Traveler-facing insurance activity stays in our frame. The quote form, the options list, and the in-iframe checkout all run on our origin (expedition.insure), loaded into a sandboxed <iframe>. Your page never presents coverage terms or takes the insurance payment directly.
• Attribution, not authority. Your publishable key (pk_op_...) attributes a quote to your operator account server-side. That attribution drives commission and read-back scope — it does not make your account the seller of record.

Your own jurisdiction is your responsibility. Whether you may promote insurance, and what notices you must show, depends on where you and your travelers are. This page describes how the embed is structured; it does not tell you whether you are licensed to refer in your market. Confirm that independently, and raise specifics at help@expedition.insure.

2. Merchant of record — the insurance charge is ours

Expedition Insure is the merchant of record for the insurance charge. When a traveler buys a policy, the premium is charged on our Stripe account, on a separate PaymentIntent dedicated to insurance — never on your payment rail.

Traveler          Our iframe (expedition.insure)         Money
────────          ──────────────────────────────         ─────
trip booking ───▶ your own checkout / rail        ───▶  your account
insurance    ───▶ /embed/checkout (Stripe Elements) ─▶  Expedition Insure (MoR)
                  separate PaymentIntent, our Stripe

Consequences for integrators:

• You never touch the insurance money or card data. Card details are entered into Stripe’s own Elements iframe (loaded from js.stripe.com) inside our frame. The charge settles to Expedition Insure. Your trip charge, if any, stays entirely on your own rail.
• The insurance line is ours on the statement. Because we are MoR, the insurance charge appears under Expedition Insure, and we own refunds, chargebacks, and tax handling for that charge.
• Commission is settled separately, out of band. Today the only implemented payout model is separate_pi: insurance is paid on its own PaymentIntent, and your commission is tracked in our ledger and paid by a periodic invoice. A Stripe Connect netting model is not implemented — see the integration guide for the commission ledger and commissionRateBps.

Reconcile on the webhook, not the UX signal. payment.succeeded is a UX-only ei:* event posted from the iframe and can be missed (closed tab, lost message). The authoritative post-sale signal is the server-to-server policy.issued webhook — that is what writes the commission ledger row. Reconcile commission and fulfillment against policy.issued, never against payment.succeeded. See webhook events for the signed payload.

3. Required customer disclosures

Expedition Insure has two AI-fronted surfaces, and they carry different disclosures — do not conflate them:

• The embedded insurance widget (this documentation) is a self-service, AI-assisted quoting flow that Expedition Insure operates inside our own iframe. It quotes, compares, and sells policies; we handle the experience and the sale end to end.
• The public MCP server (MCP & agentic commerce) is a general-purpose AI assistant surface for agents answering questions and buying on a traveler’s behalf — a different product with its own framing.

For the embedded quoting flow, three disclosures must reach the traveler, and you must not strip, edit, or paraphrase them. Inside our frame they are shown for you. If you surface quote content outside our frame — for example you relay an estimate in your own UI — you are responsible for carrying them through, verbatim.

Preserve this standard disclosure language exactly:

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.

The three required points, each preserved verbatim:

Disclosure	Why it is required
AI-assisted quote tool, not a licensed advisor. The embedded quoting flow is an AI-assisted tool, not a licensed insurance advisor, and is not giving advice.	The traveler must not mistake automated help for licensed advice.
Estimates are non-binding. Pre-purchase premium and coverage figures are estimates; the bound policy is the source of truth.	Quoted figures can differ from the final carrier price; only the issued policy binds.
A human is available. Offer a human at help@expedition.insure.	The traveler must always have a path to a person.

Carry the email address through unchanged. The human-contact offer must resolve to help@expedition.insure. Do not substitute your own support channel for the insurance-advice path — route insurance questions to us.

Estimate versus bound price

The pre-purchase numbers your page can see are estimates, and the field names say so. The quote.selected and payment.succeeded events carry premiumCents (the premium in integer minor units). Treat any figure shown before the policy.issued webhook as an estimate:

• Build against premiumCents (integer minor units) — divide by 100 for display.
• The figure in the policy.issued webhook is the bound, settled premium. If you display a price to the traveler after purchase, use the webhook value, not the earlier estimate.

4. Coverage language — quote verbatim, no editorializing

Coverage figures and policy wording are carrier-approved. When you display any coverage content — limits, inclusions, exclusions, plan names — reproduce it verbatim from what the embed returns. Do not paraphrase, summarize, or restyle it.

Specifically:

• No editorializing in coverage descriptions. Do not add “we recommend,” “the best option,” “you should pick,” or any ranking, judgment, or persuasion to coverage copy. State coverage as written; let the traveler choose.
• No invented coverage claims. Never assert that a scenario is covered, or describe what a policy “would” pay, beyond the exact wording the carrier supplies. If a traveler needs an interpretation, route them to a human at help@expedition.insure.
• This applies to AI agents too. An agent relaying options must present coverage figures as returned and must not generate its own coverage summaries, recommendations, or eligibility conclusions.

Why this is strict. Coverage language is regulated insurance copy. Paraphrasing or editorializing it can create a misleading-sales exposure for both of us. The safe pattern is mechanical: show the returned figures, link to the policy wording, and offer a human.

5. What you own versus what we own

Responsibility	You (operator / agent)	Expedition Insure
Surfacing the quote flow	✅	—
Presenting carrier products and binding coverage	—	✅
The insurance charge (merchant of record)	—	✅
Your trip charge, if any	✅	—
Showing the required disclosures verbatim where you relay quote content	✅	✅ (inside our frame)
Refunds, chargebacks, and tax on the insurance charge	—	✅
Notice and consent on your own page (see data, privacy, and DPA)	✅	—
Commission tracking and payout	—	✅

6. Getting it in writing

For a signed referral or commission agreement, a DPA, licensing specifics, or any jurisdiction-specific commitment, email help@expedition.insure. Include your legal entity name, the integration tier you’re using, and the markets you operate in so we can scope the agreement to your integration.

This page is descriptive; the signed agreement is the binding instrument.