Cancelling an insurance policy online — refund straight to your card
Cancelling a policy used to mean a trip to the office. I wired our customer cabinet to a new cancellation service built by my teammate, so now a customer picks a policy, sees the exact refund, enters a card, and tracks the request — all online.
Until recently, cancelling an insurance policy at our company meant going to an office with paperwork. We decided that should be a five-minute online task instead. My teammate built the server side that talks to the insurance core; I built everything the customer sees and connected the two.
What a customer can do now
Inside the personal cabinet there is a step-by-step cancellation wizard:
- Pick the policy you want to cancel from your real list of policies.
- See the exact refund amount — calculated live for your policy, before you commit to anything.
- Enter the card and bank details where the money should be returned.
- Submit and track it — the request appears in "My requests" with a status you can follow until the money is on its way.
The whole flow speaks three languages (Uzbek, Russian, English) and switches instantly, like the rest of the cabinet.
How the wiring works, in plain words
The new service my teammate built can answer three questions: "how much would this person get back?", "okay, do it", and "how is it going?". My job was to ask the right question at the right moment and turn the raw answers into something a person understands: the refund preview on screen, a clear success card after submitting, and a live status afterwards.
The interesting part is that a page like this is really a conversation between the customer and a system neither of us controls — so every screen had to be designed around what that system might say.
Two days of waiting, three hours of wiring
There was a catch: the server side wasn't ready when I was. I ended up waiting almost two days for the service to land — the kind of dependency that can quietly kill a feature's momentum.
Instead of sitting idle, I built my whole side against the agreed contract in advance: every screen, every state, every error case, ready to plug in. So when the service finally arrived, the actual wiring took me about 3–4 hours — and the feature went from "nothing to connect to" to fully working the same day. Handling a blocked dependency well is, honestly, half the job on a team.
When things don't go the happy path
Most of the real work was handling the answers nobody plans for:
- "A request for this policy already exists." Instead of a scary error, the page shows a calm card explaining that, with the existing request's status.
- "This policy already had an insurance payout." By the rules it can't be cancelled — so the page explains exactly why, instead of failing silently.
- A subtle one I'm proud of: the page used to flash the card form for two seconds before discovering a request already existed. I added a short "checking your policy…" moment first, so the screen never jumps or lies to the user.
Where the request lives afterwards
A submitted cancellation doesn't disappear into a void. It shows up in "My requests", in one merged list together with insurance claims — same table, same translated statuses. Clicking it opens a tracking page with a simple two-step progress line: under review → completed. If the service that lists cancellations is ever unavailable, the page quietly shows everything else instead of breaking — the customer never sees an empty screen because one part had a bad day.