Онлайн-расторжение страхового полиса с возвратом средств прямо на банковскую карту

До недавнего времени расторжение страхового полиса в нашей компании требовало личного визита в офис и оформления документов. Мы решили, что такая процедура должна занимать всего несколько минут и выполняться полностью онлайн. Мой коллега разработал серверную часть, которая взаимодействует с основной страховой системой, а я реализовал весь пользовательский интерфейс и связал его с новым сервисом.

Что теперь может сделать клиент

В личном кабинете появился пошаговый процесс расторжения полиса:

1. Выбрать полис, который необходимо расторгнуть, — из списка своих действующих полисов.
2. Увидеть точную сумму возврата — рассчитанную специально для выбранного полиса ещё до подтверждения операции.
3. Указать реквизиты банковской карты, на которую будут перечислены средства.
4. Отправить заявку и отслеживать её статус — в разделе «Мои заявки» вплоть до завершения возврата средств.

Весь процесс полностью поддерживает три языка — узбекский, русский и английский — и переключается мгновенно, как и остальные разделы личного кабинета.

Как всё работает простыми словами

Новый сервис, разработанный моим коллегой, умеет отвечать на три основных вопроса: «какую сумму клиент получит при расторжении полиса?», «подтвердить расторжение» и «на каком этапе находится заявка?». Моя задача заключалась в том, чтобы обращаться к сервису в нужный момент и превращать технические ответы сервера в понятный пользовательский интерфейс: отображать предварительный расчёт суммы возврата, показывать понятное подтверждение после отправки заявки и обновлять её текущий статус.

Самое интересное в подобных страницах заключается в том, что они постоянно взаимодействуют с внешней системой, поведение которой невозможно полностью контролировать. Поэтому каждый экран пришлось проектировать с учётом всех возможных вариантов ответа сервера.

Два дня ожидания — несколько часов интеграции

Возникла одна сложность: когда моя часть работы была практически готова, серверный сервис ещё находился в разработке. Мне пришлось ждать почти два дня, пока API станет доступным, — подобные зависимости могут незаметно погубить темп работы над функцией.

Вместо того чтобы откладывать работу, я заранее реализовал весь пользовательский интерфейс по согласованному контракту API: подготовил все экраны, состояния и обработку ошибок. Поэтому, когда серверная часть наконец появилась, сама интеграция заняла всего около 3–4 часов, и уже в тот же день функция полностью заработала. Этот опыт ещё раз показал мне, что умение эффективно работать с внешними зависимостями — важная часть командной разработки.

Когда всё идёт не по идеальному сценарию

Основная сложность оказалась не в «счастливом пути», а в обработке нестандартных ситуаций:

• «Для этого полиса уже существует заявка.» Вместо технической ошибки пользователь видит понятное сообщение с текущим статусом уже созданной заявки.
• «По этому полису уже была страховая выплата.» Согласно правилам такой полис больше нельзя расторгнуть, поэтому система объясняет причину, а не просто показывает ошибку.
• Небольшое улучшение, которым я особенно доволен: раньше страница сначала показывала форму ввода банковской карты, а спустя пару секунд выяснялось, что заявка уже существует. Я добавил промежуточное состояние «Проверяем данные полиса…», благодаря чему интерфейс больше не «прыгает» и никогда не вводит пользователя в заблуждение.

Что происходит после отправки заявки

После отправки заявка не исчезает без следа. Она автоматически появляется в разделе «Мои заявки», где отображается вместе со страховыми случаями в едином списке — с едиными статусами и переводами. При открытии заявки пользователь видит страницу отслеживания с простым прогрессом: «На рассмотрении → Завершено». Даже если сервис, отвечающий за список заявок на расторжение, временно недоступен, страница продолжает корректно работать и показывает остальные данные — из-за сбоя одного сервиса пользователь никогда не остаётся перед пустым экраном.