Axcess Insurance just embedded auto policies into Drive's ride-hailing app and pulled $14 million in annual premium revenue in its first year. Here's how your claims team can replicate that architecture. Axcess Insurance just embedded auto policies into Drive's ride-hailing app and pulled $14 million in annual premium revenue in its first year. Here's how your claims team can replicate that architecture.

I've reviewed dozens of embedded insurance pilots at carriers and MGAs over the past three years. The pattern is consistent: the ones that launched fast were the ones that stopped trying to rebuild their legacy distribution stack, and the ones that failed were the ones that treated embedded as a technology project instead of a product.

Embedded insurance is insurance woven into a non-insurance digital experience — point-of-sale, at checkout, inside an app's workflow — rather than presented as a separate purchase on an insurance carrier's own website. The insurer doesn't acquire the customer. The merchant does. The insurer fulfills the policy. Revenue comes from premium share, referred by the platform.

This tutorial covers the technical and operational steps to stand up an embedded ecommerce insurance product. I'm writing from the perspective of a CTO building this for a regional property and casualty carrier. The same architecture applies to MGAs, but the compliance responsibilities shift.

What embedded insurance actually is (and what it isn't)

Embedded insurance sits inside another company's transaction flow. A travel booking site offers trip cancellation coverage at checkout. A marketplace seller buys fraud protection when they list a product. A e-scooter rental app charges a daily micro-premium for theft and liability.

It is not a white-label policy page you drop into an iframe. That's digital shelf placement, not embedding. True embedding requires API-driven underwriting, real-time premium calculation, policy issuance, and claims intake to happen within the merchant's user interface — often without the end user ever knowing they've left the merchant's site.

The two primary models are co-branded and white-label. In a co-branded model, your carrier logo appears alongside the merchant's. The customer knows they're buying insurance from you. In a white-label model, the merchant presents the product as their own. Claims handling and customer service may still flow through your infrastructure, but the front end hides your brand entirely.

White-label products command higher revenue shares — merchants typically demand 15 to 25 percent of gross written premium — but they carry deeper compliance risk. State insurance departments do not care about your branding agreement. If the policy is non-compliant, the issuer is liable regardless of whose logo is on the screen.

Step 1: Define the product and merchant fit

Before writing any code, you need a product that fits a specific merchant's transaction moment. The wrong pairing is the single biggest cause of embedded insurance failure. A product that interrupts a checkout flow with a lengthy application form will have a conversion rate near zero. A product that offers a single click, pre-populated from transaction data, converts at 8 to 14 percent depending on category.

Product selection criteria: Transaction alignment. The insurance must cover a risk that exists at the point of sale. Returns protection at checkout. Delay coverage when booking travel. Device insurance when buying electronics.

Data availability. Can the merchant share the transaction value, product SKU, customer location, and purchase timestamp via API? If the merchant has no structured data, your underwriting engine cannot price in real time. Premium size threshold. Micro-premiums under $5 per transaction require automation at every step. Manual underwriting, even partial, kills the economics. Set a minimum ticket size of $3 to $5 premium per policy.

1. Regulatory simplicity. Start with products that are either federally exempt (credit insurance) or available in at least 30 states. Travel, gadget, and returns protection meet this bar. Personal auto is not a good starting product for embedded channels. I've seen carriers try to embed commercial property insurance into a B2B procurement platform. The underwriting took 47 fields. The merchant's checkout flow took 3 fields. The product never launched. Start small. Expand after the channel proves itself.
2. Step 2: Choose your integration architecture There are four architectures for connecting your policy admin system to a merchant's platform. The right choice depends on your existing technology stack and how much control you need over the user experience.
3. Architecture 1: Direct API to PA. Your embedded insurance platform calls the policy admin system directly for quote, bind, and endorsement operations. This gives you full control but requires deep integration work with whatever legacy PA you operate. Most regional carriers use Guidewire or Duck Creek for core. Neither exposes clean REST APIs for real-time embedded transactions without a middleware layer.
4. Architecture 2: Middleware through an integration platform. Deploy a lightweight middleware service between the merchant API and your PA. The middleware handles protocol translation, message queuing, and error handling. This is the most common approach for carriers with legacy cores. You build or buy the middleware. It talks to the merchant in REST/JSON and to the PA in SOAP or a proprietary format.

Architecture 3: Managed embedded insurance platform. Use a vendor like Sure, Next Insurance Platform, or Trovicor. These platforms sit between you and the merchant, handling policy issuance, billing, and claims intake through their own APIs. You provide pricing and underwriting rules. They handle the rest. This is the fastest path to market — typically 8 to 12 weeks from kickoff to production — but you cede significant control over the customer experience and pay a platform fee of 3 to 8 percent of gross written premium.

Architecture 4: InsurTech-as-a-service wrapper. Some vendors offer a full insurTech stack wrapped around your existing license. Think Shift Technology or Lemonade's B2B division. You white-label their technology, they handle compliance and licensing nuances. This is expensive and rare for regional carriers. More common for national MGA entrants.

Architecture Time to production

Upfront cost range Ongoing % of GWP

Best for Direct API to PA

6–10 months $250K–$600K

0% (internal opex) Carriers with modern PA stacks

Model C: Full self-serve through merchant app. The merchant builds a claims interface into their own app or website. Customers file, upload photos, track status, and receive payout without ever seeing your brand. This model requires the most development investment from both parties but delivers the smoothest customer experience. It is the standard for white-label embedded products.

Claims SLA targets for embedded insurance should be tighter than traditional channels. Low-value claims — under $100 — should settle within 48 hours. Anything longer erodes the perceived value of the product and increases refund requests. Set your adjuster targets accordingly: 24 hours for sub-$50 claims, 48 hours for sub-$100, 5 business days for anything above.

Step 6: Handle state licensing and compliance

This is where embedded insurance programs fail legally. State insurance departments regulate where insurance can be sold, not how it is sold. If your product is authorized in Texas, you can sell it to a Texas resident whether they buy it through your website, a phone agent, or a ride-hailing app. But you must have authority in that state before any policyholder resides there.

1. Compliance checklist: Product approval. File your policy form and rates with each state's insurance department. Rates must be filed prior to use in most states. Some states allow usage-based filing with retrospective audit.
2. Appointment of agents. If the merchant is considered your agent, they must be appointed in each state where policies are issued. Many embedded merchants resist this requirement. The alternative is to structure the relationship as a wholesale broker arrangement, which has different licensing requirements but still demands appointment in most jurisdictions.
3. Disclosure requirements. Each state has specific disclosure language requirements for insurance products. The merchant's checkout page must include insurer name, policy number, coverage terms, and complaint contact information — usually in a collapsible section or linked modal, not buried in terms of service.
4. Privacy and data sharing. GDPR applies if you have any EU customers. State privacy laws (CCPA, CDPA, UCPA) apply to California, Colorado, Connecticut, Utah, and Virginia residents. Your data processing agreement with the merchant must specify what customer data you receive, how you use it, and how long you retain it. Do not skip this. State attorneys general are actively auditing embedded insurance data practices.
5. The most common compliance failure I see is carriers assuming their existing product approvals cover embedded sales. They do not, unless the filing explicitly permits sale through third-party platforms. Review your product filings. If they reference "direct to consumer" or "agent-produced" channels only, you need a filing amendment before launching.

Step 7: Set up revenue sharing and billing Embedded insurance revenue models fall into three categories:

{
  "quote_id": "QT-2024-0847291",
  "product_code": "RET-PROTECT-STD",
  "premium": 4.97,
  "currency": "USD",
  "coverage_limit": 500.00,
  "deductible": 25.00,
  "term_days": 30,
  "underwriter": "auto_rule_engine",
  "decision": "approve",
  "risk_flags": [],
  "expires_at": "2024-11-15T18:30:00Z"
}

GWP share. The merchant receives a percentage of gross written premium. This is the standard model. Typical rates: 10 to 20 percent for co-branded products, 15 to 25 percent for white-label. High-volume merchants with exclusive placement demand the upper end. New merchants accepting any carrier that connects may accept the lower end.

Per-policy fee. The merchant receives a fixed amount per policy issued. Common in micro-insurance where premium volumes are small. A $2 per-policy fee on a $5 premium product leaves you with $3 gross margin per policy, which may not cover acquisition and servicing costs.

Rebate model. The merchant discounts the insurance premium at checkout and receives the difference as a referral fee. This model aligns incentives but complicates rate filings. Premium discounts must be reflected in your filed rates, or you are violating rate stabilization statutes in most states.

1. Revenue share calculations must account for reinstatement premiums, cancellation adjustments, and loss ratio reserves. A policy cancelled within the free-look period (typically 10 to 30 days depending on state) generates zero revenue but may have already triggered a merchant payout. Your billing system needs logic to claw back or offset these amounts.
2. Here is a simplified billing reconciliation query you would run weekly: Step 8: Launch and monitor
3. Do not launch to production without a phased rollout. Even if your sandbox testing was flawless, production traffic patterns differ. Merchant transaction volumes spike unpredictably. Payment processors throttle requests. Policy admin systems queue bindings during peak hours. Launch sequence:
4. Staged merchant rollout. Onboard one merchant in one state first. Run for 30 days. Monitor quote response times, bind success rates, and claims filing accuracy. Fix issues before expanding. Horizontal scale. Add merchants in the same state. Monitor error rates across integration pairs. A failure in one merchant's API integration should not cascade to others.
5. Geographic expansion. Add new states only after the current state's combined ratio stabilizes above 85 percent. Embedded insurance loss ratios run higher than direct channel in year one. Expect 5 to 8 percentage points worse than your established book. This is normal. It compresses as fraud detection and risk scoring mature.

Product expansion. Add new insurance products only after the first product's claims process is fully automated. Manual claims handling does not scale with product complexity. Key metrics to track from day one:

app.post('/api/v1/quote', authenticateMerchant, async (req, res) => {
  const { product_sku, transaction_value, shipping_zip, customer_email } = req.body;

  // Validate inputs
  if (!transaction_value || transaction_value < 25) {
    return res.status(400).json({ error: 'Minimum transaction value is $25' });
  }

  // Risk scoring
  const riskScore = await riskEngine.evaluate({
    sku: product_sku,
    value: transaction_value,
    zip: shipping_zip
  });

  let decision = 'approve';
  let premium = calculatePremium(transaction_value, riskScore);

  if (riskScore.score > 0.85) {
    decision = 'manual_review';
    premium = null;
  }

  res.json({
    quote_id: generateQuoteId(),
    premium,
    decision,
    risk_score: riskScore.score,
    expires_at: Date.now() + 900000 // 15 min TTL
  });
});

Metric Target

app.post('/api/v1/bind', authenticateMerchant, async (req, res) => {
  const { quote_id, customer_details } = req.body;

  const policy = await policyAdmin.issue({
    quote_id,
    insured: customer_details,
    product_code: req.product_code
  });

  await billing.scheduleRemittance(policy.policy_id, policy.premium);
  await notifications.sendConfirmation(policy.policy_id, customer_details.email);

  res.json({
    policy_id: policy.id,
    status: 'issued',
    effective_date: policy.effective_date,
    certificate_url: policy.certificate_url
  });
});

Benchmark Renegotiation trigger

Quote response time <2 seconds

1.4 seconds avg >3 seconds for 5%+ of requests

Bind success rate >95%

91% industry avg <90% for 2 consecutive weeks

Claim cycle time (sub-$50) <24 hours

36 hours avg >48 hours median

Merchant NPS >50

42 industry avg <35 for 90-day rolling window

Combined ratio (year 1) <100%

94–97% typical >105% for 2 consecutive quarters

• If your bind success rate drops below 90 percent, investigate merchant-side integration failures before assuming your underwriting engine is the bottleneck. In my experience, 60 percent of early-stage embedded program failures trace back to merchant API errors, not carrier-side issues, and the merchant's system is often updating their own checkout flow independently, and a schema change breaks your integration without any.
• Resource requirements and timeline Here is a realistic resource estimate for a regional carrier building an embedded insurance program from scratch using the middleware architecture approach:
• Role Headcount
• Duration Cost estimate

Engineering lead / architect 1

Full program $180K–$220K

Backend developers 2

Months 1–6 $240K–$320K

Frontend developer (merchant portal) 1

Months 2–5 $120K–$160K

Compliance / licensing specialist 1

Months 1–8 $100K–$140K

SELECT
  m.merchant_name,
  COUNT(p.policy_id) AS policies_issued,
  SUM(p.premium) AS gross_premium,
  SUM(p.premium * m.revenue_share_pct) AS merchant_payout,
  SUM(p.premium) - SUM(p.premium * m.revenue_share_pct) AS net_premium,
  SUM(CASE WHEN p.status = 'cancelled' THEN p.premium ELSE 0 END) AS cancellations
FROM policies p
JOIN merchants m ON p.merchant_id = m.id
WHERE p.issued_date BETWEEN ? AND ?
GROUP BY m.merchant_id;

Product manager 1

Full program $140K–$180K

Infrastructure / DevOps 1

1. Months 1–4 $120K–$160K
2. Claims operations lead 1
3. Months 4–9 $110K–$150K
4. Third-party platform fees (if applicable) N/A

Monthly $15K–$40K/month