TechnicalProduct

Five insurers behind one checkout

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.

Five providers, one contract in the middle, fifteen-odd systems downstream. The middle column is the part that made the other two survivable.

Zurich, Tune Protect, Guard Genius, Liberty and Kurnia each expose their own API.
Each has its own idea of what a motor policy is, and its own failure modes.
None of them agree on much.

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.

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.
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.
Failed-transaction alerting, so operations hears about a broken payment before the customer does.

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.
They are also most of what a customer actually experiences after handing over money.

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.

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.