Five insurers behind one checkout
- Organisation
- iLyF — Easy, Instant Insurances
- Role
- Owner of the integration layer, commercial through technical
- Period
- Malaysia
iLyF sells other people’s insurance. Everything ugly about five different providers had to be absorbed before it reached the screen.
- 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
Scroll the figure sideways to read it, or turn your phone.
- 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.
- Idempotency keys on every write. A retried bind cannot charge a customer twice, which is the failure that actually costs trust.
- 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.
- Every failed transaction alerts operations rather than sitting in a log. Someone finds out from the system, not from the customer.
Context
Zurich, Tune Protect, Guard Genius, Liberty and Kurnia each expose their own API, their own idea of what a motor policy is, and their own failure modes. None of them agree on much.
What was actually needed
A customer should never see any of that. They pick a car, they see prices, they pay, they get a cover note. The difference between five integrations and one product is entirely in what sits between them.
What I did technically
I managed the integrations end to end — the commercial conversations, the technical specification, and the layer that normalised five policy models into a single quote-and-bind contract. Around it I built the operational plumbing: idempotency keys on every write so a retry never double-charges, timeouts and circuit breaking so one slow provider cannot take down the quote screen, and failed-transaction alerting so operations hears about a broken payment before the customer does.
Decisions that mattered
Automating the things that generate support tickets rather than the things that demo well. Cover note issuance, payment confirmation, road tax delivery tracking and failed-transaction alerts are unglamorous, and they are most of what a customer actually experiences after handing over money.
What changed
Fifteen to twenty third-party integrations running alongside the five insurers, above 99.9% reliability. When one provider forced an API migration, we completed it inside a month with no customer disruption — because the normalisation layer meant only one side of the boundary had to move.
The insight I kept
An integration is a relationship, not an endpoint. The technical work was the easier half. The half that determined whether it stayed reliable was knowing who to call at the insurer when something changed on their side without warning.
Stack & practices
- Insurer APIs
- Payment gateway
- Idempotency keys
- Circuit breaking
- SMS
- Sentry