Skip to content
Faidhi Fahmi.Contact
All selected works
TechnicalProduct

Five insurers behind one checkout

Organisation
iLyF · Easy, Instant Insurances
Role
Co-founder & Chief Product Officer · Integration owner
Period
Malaysia

iLyF sells other people’s insurance. Everything ugly about five different providers had to be absorbed before it reached the screen.

At a glance

Situation
Five insurers, each with its own API, its own idea of what a motor policy is and its own failure modes, all needing to sit behind one consumer checkout.
Stakes
One slow or broken provider could stall the quote screen, double-charge a retry, or fail a payment silently. Each failure meant losing a customer at the moment of purchase.
My role
Co-founder and Chief Product Officer. Owned the integration layer end to end, from insurer conversations through the technical specification and normalisation contract.
Constraints
Provider APIs, timelines and forced migrations outside our control, with 15–20 other third-party integrations running alongside.
What changed
  • Integrations held above 99.9% reliability
  • A forced provider API migration was absorbed inside a month with no customer disruption
Read this if
Your product depends on partner systems you do not control, and their problems keep becoming your customers’ problems.
insurance provider integrations
5insurance provider integrations
third-party integrations alongside them
15–20third-party integrations alongside them
integration reliability
99.9%+integration reliability
for a forced API migration, no disruption
Under a monthfor a forced API migration, no disruption

How the system actually worked

Five insurers behind one checkoutThree columns. On the left, five insurance providers: Zurich, Tune Protect, Guard Genius, Liberty and Kurnia, each with its own interface. All five feed into the middle column, which is the integration layer: one normalised quote and bind contract, idempotency keys on every write, and a circuit breaker that refuses to call a provider that has stopped answering. Failed transactions alert operations. From there, fifteen to twenty downstream systems are driven: payment gateway, cover note issuance, road tax delivery, messaging, and analytics.5 INSURANCE PROVIDERSZurichTune ProtectGuard GeniusLibertyKurniaWHAT I BUILT IN BETWEENOne normalised quote and bind contract1Idempotency keys on every write2Timeouts, retries,circuit breaking3Failed-transaction alerting to ops415–20 DOWNSTREAM INTEGRATIONSPayment gatewayCover note issuanceRoad tax deliveryWhatsAppSMSpushAnalyticserror trackingOne contract, one retry policy, one place to look when it breaks

Scroll the figure sideways to read it, or turn your phone.

  1. Five providers, five different contracts, five different failure modes. Normalising them into one quote-and-bind shape is what stopped that variety reaching the checkout.
  2. Idempotency keys on every write. A retried bind cannot charge a customer twice, which is the failure that actually costs trust.
  3. The circuit breaker refuses. When a provider stops answering, the checkout degrades to the four that are up instead of hanging on the one that is down.
  4. Every failed transaction alerts operations rather than sitting in a log. Someone finds out from the system, not from the customer.
Five providers, one contract in the middle, fifteen-odd systems downstream. The middle column is the part that made the other two survivable.

Stack & practices

  • Insurer APIs
  • Payment gateway
  • Idempotency keys
  • Circuit breaking
  • WhatsApp
  • SMS
  • Sentry

Got a problem shaped like this one?

A short conversation is usually enough to see if there's a fit.

Email meRead another case study