Skip to main content

Pre-Launch Checklist: Minimum Requirements & Final Checks

Before your embedded insurance integration goes live, it must meet the minimum requirements on this page. They exist to keep the offer fair and clear for travellers and to satisfy the regulatory expectations that apply to insurance distribution in most territories.

This page is not legal advice

Insurance distribution rules differ by territory (for example the IDD and IPID requirements in the EU/UK, or provincial licensing in Canada). You are responsible for confirming what applies in each market you sell into. Sitata reviews every integration before launch — when in doubt, ask us early rather than after you have built.

Minimum display requirements

1. The disclaimer must sit next to the product display

Every product carries a disclaimer in its payload (see Listing Products). It must be rendered on the same screen as the product offer, visibly and before the traveller commits to purchase — not behind a link, not on a later step, not in an email afterwards.

In a tiered product arrangement the disclaimer is identical for every tier, so showing it once for the set satisfies this requirement — you do not need to repeat it per tier.

2. Product documents must be downloadable next to the product display

Each product's product_documents (policy wording, brochure, IPID, terms of business, regulatory disclosures) must be available for download near the product display, before purchase. The traveller has to be able to read what they are buying at the moment they decide to buy it.

  • Render every unique document applicable to the customer for the selected products, and never filter by document type — policy wording, brochure, IPID, terms of business and any other type the API returns must all appear.
  • Where a document exists in several regional or language variants, show the variant that applies to this customer: the regionally-applicable version, in the customer's language (fall back to English when their language isn't available). Sitata's own reference integrations select documents exactly this way, so a matching display shows the same set that ends up attached to the policy after purchase.
  • Each document carries a display title (for example "Policy Wording") — show that title as the link text.
  • Do not size your layout for a single document: your sandbox environment may expose only one, but production products often carry several, and all of them must be listed.
  • As with the disclaimer, a tiered set shares the same documents — each tier carries its own copy, so deduplicate by the document's identifier and list each document once for the set.
  • Link the documents the API serves. Do not download, re-host or cache copies: document URLs are refreshed by the API, and a stale copy can misstate coverage.

3. The insurance offer must not be confusable

A traveller must always be able to tell what is insurance, what it costs, and that it is theirs to decline:

  • The offer is clearly separate from your travel product — never presented as an inseparable part of a trip, fare or package price.
  • Purchasing insurance is opt-in. No pre-ticked boxes, no default-added premiums, no declining flows designed to shame or mislead.
  • The total premium, including all taxes and fees, is shown before payment and equals exactly what the traveller is charged.
  • Coverage is described using the wording Sitata provides. Do not paraphrase benefits, invent coverage names, or make comparative or superlative claims ("full coverage", "best protection") that the policy wording does not support.

These are not regulatory minimums, but integrations that follow them convert better and generate fewer support questions:

  • Show what the traveller is buying. Display a handful of key benefits with their coverage amounts on the product card. The benefits worth surfacing are flagged prominent: true in the product payload and carry their limits — travellers typically care most about emergency medical, trip cancellation, and baggage, but pick what fits your audience.
  • You don't have to show every tier. In a tiered arrangement it is fine to present one or two tiers instead of all of them — A/B test what converts best for your audience. Whichever tiers you show, each one's benefits, price, disclaimer and documents must still meet the minimums above.

Transparency requirements

  • Who is behind the policy. The product display or its documents must make clear who underwrites the product and Sitata's role in it. Never present the insurance as underwritten by you.
  • Support and complaints. The traveller must be able to find how to reach support and how to complain — the receipt and policy documents cover this, so deliver them intact.
  • Cancellation rights. Where the policy provides a review/cooling-off period, do not obscure it; it is stated in the policy wording you are required to make available.
  • Obtain the traveller's affirmative acceptance of the disclaimer and policy documents (for example an unticked checkbox adjacent to them) before taking payment.
  • If you deliver documents electronically only, make that clear at purchase.
  • Only collect the traveller data the purchase requires, and handle it in line with your privacy policy and applicable data-protection law.

Final checks before deployment

Run through this list in your staging integration, for every market and language you are launching:

  • Disclaimer renders beside the product display, before purchase.
  • All product_documents for the selected products are listed and each link opens the correct PDF.
  • Insurance is opt-in; removing it from the cart works and is obvious.
  • The price shown (including taxes) equals the amount charged.
  • A full test purchase succeeds (Quoting → Purchasing) and the traveller receives their policy: receipt with documents, or your own fulfilment via the subscription webhook if you are whitelabelled.
  • The subscription payload's cached documents and certificates are reachable from your post-purchase surfaces (use the stable download_path links if you store them in your own systems — the signed certificate_url expires within the hour).
  • Cancellation/refund flow tested end to end.
  • Production credentials swapped in; no sandbox keys, URLs or test products remain.
  • Sitata has reviewed and approved the integration for the territories you are launching in.

If any item on this page is unclear for your integration, contact us before launch — territory-specific requirements (licensing, IPID formatting, mandatory local wording) may add to this list, and it is far cheaper to address them before your first sale than after.