Post-Purchase Insurance & Warranty Sales

Paid pluginsize Mplanned, not built

Indicative price, not an offer: $9-25/mo + commission (insurance partners take 15-25% of premium)

Generated from docs/plan/paid/post-purchase-insurance-warranty-sales/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid module that offers damage protection and extended warranties at post-purchase (in confirmation email, shipping notification, or 7-day followup). Partners (e.g., Insurify, Redo) handle underwriting and claims; AstroBaaS manages SKU catalog, customer offers, and commission settlement. Merchants earn 0% commission (customer fully pays insurance provider); commission is transparent.

The problem

A merchant selling electronics leaves margin on the table by not offering damage insurance. A customer buys a €200 laptop; offering €15 insurance at checkout would increase AOV by €15 and provide customer peace of mind. Most customers never ask for insurance, but post-purchase reminders convert 2–5% of customers who didn’t see the pre-purchase offer.

What it does

• Insurance product catalog: merchant configures insurers (name, commission %, coverage details, claim process link)
• Insurance SKUs per product: product ‘laptop’ can have insurance option ‘device protection €15 (3-year coverage)’ as a line item
• Post-purchase offer: after order confirmation, email contains ‘Add device protection for €15’ link, customer can 1-click add
• Followup offer: 7 days after purchase, send email ‘Protect your €200 laptop for €15’ (opt-out toggle in settings)
• Insurance in order: order.items[] can include insurance line item, tracked separately from product
• Claim submission: customer clicks ‘claim’ link in order history → modal opens with claim form (damage photos, description), forwarded to insurer
• Settlement: insurer pays merchant weekly; commission is calculated (0% to merchant, 100% customer pays = no revenue share complexity)
• Audit log: track insurance offers made, accepted, and claims filed

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Underwriting (insurer handles eligibility; AstroBaaS just passes data)
• Claims handling (insurer adjudicates; AstroBaaS provides customer submission form only)
• Premium collection (customer pays insurer directly; AstroBaaS doesn’t hold funds)

Data model

Add insurance_offerings table: { id, shop_id, insurer_id, product_id, coverage_name, coverage_price_minor_units, coverage_duration_months }. Add insurance_claims table: { id, order_id, product_id, claim_status (‘submitted’, ‘under_review’, ‘approved’, ‘denied’), claim_filed_at, insurer_reference }. Schema migration: new tables.

API

• POST /admin/insurance/offerings — add insurance product to catalog
• GET /products/:id/insurance-options — list available insurance offerings for product
• POST /orders/:id/add-insurance — customer 1-click adds insurance to order (post-purchase)
• POST /account/insurance-claims — customer submits claim (photos, description, order_id)
• GET /admin/insurance/claims — list all claims and status

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Add ‘Insurance’ section in Commerce > Settings (paid only). Insurer list: name, commission %, API endpoint (for claims submission). Product assignment: ‘product laptop’ → ‘device protection €15, 3 years’. Post-purchase offer toggle: ‘email reminder 7 days after purchase’ + customizable email template. Claims dashboard: shows submitted claims, status, insurer response. Revenue: show commission owed to merchant (likely €0 since customer pays insurer).

The seam — why this is paid

Paid module owns the insurance integration, claim submission, and insurer APIs. Core owns the order data model and line item structure. Merchants without this module cannot offer insurance (it requires insurer credential).

Paid module owns insurance product catalog, underwriting rules, and claims API integration; core cannot issue insurance

Dependencies

• Order system (insurance is a line item on orders)
• Email system (post-purchase reminder emails)
• Third-party insurer API (to submit claims)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Merchant adds insurance offering: ‘Redo Device Protection, €15, 36 months, product laptop-001’
• Customer buys laptop without insurance; receives confirmation email 7 days later with ‘Add protection for €15’ link
• Clicking link opens modal, 1-click adds insurance to order (charge customer €15, add line item to order)
• Customer files claim: submits photo of cracked screen, claim forwarded to insurer with order_id
• Claim status is tracked in account/orders dashboard: ‘Claim submitted to Redo on Sep 1, status: under_review’

Risks

If post-purchase offer email is sent too late (>30 days), customer has already discarded packaging (reduces claim eligibility). If claim submission is forwarded to wrong insurer (check order.insurance_insurer_id before posting), insurer rejects it.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.