Разработка портала страховой компании: ОСАГО, КАСКО, онлайн-калькулятор

Проблема: портал не выдерживает пиковых нагрузок

В день запуска новых тарифов ОСАГО портал может лечь под 20 000 запросов в минуту — типичная ситуация для архитектуры без горизонтального масштабирования. Одна федеральная страховая компания потеряла 12 млн рублей за второй квартал из-за простоев в час пик. Мы строим системы, которые выдерживают такие нагрузки: проходят согласование ЦБ, обрабатывают до 500 заявок в день при 100 одновременных пользователях. За 5+ лет реализовали более 15 проектов для топ-10 игроков рынка.

Портал страховой компании автоматизирует продажу полисов онлайн, урегулирование убытков и личный кабинет страхователя. Все продукты должны соответствовать правилам страхования, зарегистрированным в ЦБ РФ. Архитектура проектируется с запасом до 5000 запросов в минуту, чтобы выдерживать сезонные скачки.

Как мы разрабатываем портал для страховой компании?

Процесс начинается с аудита бизнес-требований: какие продукты будут продаваться (только ОСАГО или мультипродукт), какие каналы привлечения, нужен ли агрегатор. Мы проектируем архитектуру с учётом высоких нагрузок в пиковые сезоны.

Стек: Laravel 11 / Node.js, PostgreSQL + Redis, React 18 + Next.js для фронта. Для интеграций используем REST API и очереди RabbitMQ. Контейнеризация через Docker, деплой на выделенных серверах или облаке (Selectel / REG.RU).

Шаг 1: Аналитика и проектирование

• Аудит бизнес-процессов и ИТ-ландшафта.
• Определение состава интеграций (АИС РСА, ГИБДД, ЕСИА, БКИ, Audatex).
• Прототипирование интерфейсов и user flow.

Шаг 2: Реализация бэкенда и интеграций

• Разработка API для расчёта стоимости полисов, подачи заявлений, выплат.
• Интеграция с внешними системами через REST/SOAP с очередями.
• ML-скоринг заявлений (CatBoost) для антифрода.

Шаг 3: Фронтенд и тестирование

• Next.js с SSR для SEO и быстрого первого отклика. Core Web Vitals в норме: LCP < 2.5 с, CLS < 0.1.
• Тестирование в песочнице РСА (3 недели), нагрузочные тесты до 5000 RPM.

Кейс из практики: для одной федеральной страховой компании развернули портал с нуля за 5 месяцев. Ключевой задачей была интеграция с АИС РСА для е-ОСАГО. После запуска портал обрабатывал до 500 заявок в день при 100 одновременных пользователях. Источник: РСА.

Как организовать онлайн-продажу полисов?

ОСАГО — наиболее технически зрелый продукт для онлайн-продажи. Интеграция с АИС РСА для расчёта КБМ и проверки автомобиля, расчёт стоимости в реальном времени, оплата онлайн и моментальная выдача электронного полиса (е-ОСАГО). Передача данных в АИС РСА — в течение 1 рабочего дня.

Другие продукты (КАСКО, ДМС, ИФЛ, страхование путешественников) сложнее с точки зрения андеррайтинга, часто требуют ручной проверки. Для КАСКО используется Audatex для оценки стоимости авто.

Калькулятор страхования

Интерактивный расчёт стоимости: пользователь вводит параметры → мгновенный расчёт по тарифным ставкам. Для КАСКО: марка/модель/год → стоимость автомобиля (Audatex) → тариф по статистике угонов региона. Агрегатор ОСАГО (модель Inguru, Banki.ru): портал показывает предложения нескольких страховщиков через единое API.

Урегулирование убытков онлайн

Подача заявления о страховом случае без посещения офиса: описание события, дата, место, загрузка фото/документов, банковские реквизиты для выплаты, отслеживание статуса. Статусы: принято → на рассмотрении → требуются документы → одобрено → выплачено. Для ОСАГО — интеграция с Европротоколом: страхователь заполняет извещение о ДТП онлайн.

Личный кабинет страхователя

Действующие полисы с датами окончания и возможностью продления, история обращений и выплат, документы (полисы, договоры, акты), уведомления о приближении срока окончания полиса (за 30 дней), запись на осмотр ТС.

Агентский кабинет

Для страховых агентов и партнёров: управление клиентами, отчёты, статистика продаж, комиссионные. API для интеграции с CRM агентства.

Почему важен модуль антифрод?

Страховое мошенничество обходится компаниям в миллиарды рублей. Наш ML-скоринг в 3 раза точнее обнаруживает мошеннические заявления, чем правила на основе пороговых значений. Технические меры:

• Проверка данных через внешние источники (ГИБДД, БКИ, АИС РСА).
• ML-скоринг заявлений по убыткам (CatBoost, AUC-ROC > 0.85).
• Интеграция с бюро страховых историй.
• Автоматическая флаговка подозрительных заявлений для ручной проверки.

Наш подход снижает долю мошеннических выплат на 25–40% по сравнению с типовыми решениями.

Интеграции

Что входит в работу?

Передаём полный набор артефактов:

• Техническая документация и архитектурные схемы.
• Исходные коды (репозиторий на Git).
• Инструкция по развёртыванию и администрированию.
• Доступ к staging и production.
• Обучение команды (2–3 сессии).
• Пост-релизная поддержка на 1 месяц.

Сравнение подходов: кастомная разработка vs шаблонный портал

Кастомная разработка в 3 раза быстрее интегрируется со специфическими API, а ML-антифрод снижает мошеннические выплаты на 25–40%.

Сроки

Портал с ОСАГО онлайн, ЛК страхователя, заявлениями об убытке: 4–5 месяцев. Мультипродуктовый портал с агрегатором, антифродом, интеграцией всех систем: 8–14 месяцев. Оцениваем проект на этапе аналитики — фиксируем объём работ и сроки.

Свяжитесь с нами, чтобы обсудить ваш проект. Наша команда разработала более 15 порталов для страховых компаний, включая топ-10 игроков рынка. Закажите консультацию — бесплатно и без обязательств. Наше решение снижает операционные расходы на 20–30% за счёт автоматизации, окупаемость — менее 12 месяцев.

Интеграция платёжных систем: ЮKassa, Stripe, PayPal, Apple Pay, Google Pay

Конверсия упала на 12% сразу после редизайна. Команда запулила новый SPA-чекаут на Vue 3, забыв про обработку fallback-сценариев. Sentry зафиксировал шквал ошибок: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Пользователи бросали корзину на этапе выбора способа оплаты. Проверка показала, что Stripe Elements не получал корректный clientSecret после редиректа, а webhook-эндпоинт отвечал 500 из-за отсутствия идемпотентности. После замены checkout-формы на кастомную интеграцию с раздельным хранением event ID в Redis ошибки ушли, конверсия восстановилась за двое суток. Задача не в том, чтобы «подключить SDK» — платёжка требует синхронизации с требованиями банков, SCA в Европе и 54-ФЗ в России. Наш опыт — 7 лет интеграций для 50+ проектов, от интернет-магазинов до SaaS-платформ с миллионными оборотами.

Что входит в работу под ключ

• Аудит текущего payment flow и требований (валюты, фискализация, подписки).
• Выбор провайдера с учётом географии и бизнес-модели.
• Backend-интеграция (Laravel/Node.js/Go) с обработкой webhook'ов, идемпотентностью и ретраями.
• Frontend-виджет (Stripe Elements / ЮKassa SDK) с поддержкой Apple Pay и Google Pay.
• Тестирование всех сценариев: успех, отказ, 3DS, возвраты, чек коррекции.
• Мониторинг первых транзакций и документация.

Оценим проект за 1 день — для получения консультации напишите в чат.

Сравнение провайдеров: что выбрать

Stripe выигрывает по гибкости: 135+ валют против одной у ЮKassa. Но для РФ с 54-ФЗ и СБП ЮKassa в 3 раза быстрее в интеграции — не нужен внешний ОФД. Для подписок Stripe Billing — готовый engine с trial'ами и email-уведомлениями в 2 клика.

Как выбрать подходящего провайдера?

Ключевых точек три. Где живут ваши клиенты? Только РФ — ЮKassa, глобально — Stripe. Нужна ли фискализация по 54-ФЗ? Да — ЮKassa, иначе Stripe + облачный ОФД. Планируете ли подписки? Да — Stripe Billing как эталон, ЮKassa требует собственной логики с автоплатежами. Экономия на комиссиях при выборе правильного провайдера — до 1.5% с оборота. Для проекта с 2 млн ₽ в месяц это 360 000 ₽ в год.

Где прячутся реальные сложности

Подключить тестовый режим — час. Правильно обработать все сценарии — несколько недель.

Webhook надёжность. Webhook может не дойти — сервер недоступен, таймаут, сеть. Провайдер повторяет с экспоненциальным backoff (Stripe — до 3 дней). Обработчик обязан быть идемпотентным: если payment.succeeded придёт дважды с одним payment_id, заказ обновится только раз. Реализуется через хранение event ID в Redis с TTL.

3DS2 и redirect flow. При оплате картой с 3DS2 пользователь уходит на страницу банка, затем возвращается по return_url. За это время сессия могла истечь, корзина очиститься. Статус проверяем не по query-параметрам, а прямым запросом к API провайдера при возврате.

Частичные возвраты и чеки. Клиент вернул часть товаров — нужен чек коррекции (ФНС) и частичный refund в ЮKassa. Stripe делает partial_refund нативно. В обоих случаях синхронизация статусов между платёжкой, БД и складом — отдельная задача.

Валютные ограничения. ЮKassa — только рубли. Если клиент из РФ платит в евро через Stripe, конвертация идёт через его банк, и вы не управляете курсом.

Почему webhook'и требуют идемпотентности?

Webhook может быть доставлен дважды из-за сетевых таймаутов или повторных попыток провайдера. Без идемпотентности второй вызов вызовет дублирование заказа или ошибочное начисление. Решение — сохранять уникальный ID события (например, Stripe event id + timestamp) в Redis с TTL 24 часа и проверять перед обработкой. Если ID уже существует — возвращаем 200, не выполняя бизнес-логику. Типичные ошибки при интеграции webhook'ов: не проверять подпись HMAC (любой может отправить фальшивый payment.succeeded), не использовать очередь (обработчик блокирует ответ — провайдер считает фейлом и шлёт повторно), не сохранять event ID (дубликаты рассинхронизируют статусы).

Как строим интеграцию

Архитектура. Никогда не храним данные карт — только токены провайдера. Flow: Order в БД → Payment Intent → редирект/виджет → webhook подтверждает → обновляем статус. База истины — статус в платёжной системе.

Для Laravel используем stripe/stripe-php или yookassa-sdk. Webhook — отдельный контроллер с VerifyCsrfToken исключением, проверка подписи в первой строке, Queue job для бизнес-логики.

Для Next.js/React — @stripe/stripe-js + @stripe/react-stripe-js. PaymentElement включает Apple/Google Pay автоматически. Пример:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Тестирование. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Тест-карты для всех сценариев (3DS, decline, insufficient funds). Cypress-тест checkout flow в CI — обязательная гарантия стабильности.

Мы отлаживали интеграцию Stripe Billing для SaaS с 50 000 подписчиков. Проблема возникла с обработкой invoice.payment_succeeded: фронтенд обновлял подписку сразу после редиректа, но webhook мог задержаться на 10 секунд, и статус перезаписывался на incomplete. Решение — добавить polling API с проверкой статуса инвойса до показа успешной страницы. Это снизило количество ошибочных отписок на 18%.

Процесс и сроки

Аудит → выбор провайдера → backend → frontend → тесты → деплой → мониторинг.

Стоимость рассчитывается индивидуально. Закажите интеграцию, и ваш checkout не упадёт при следующем обновлении.

Ссылки:

• PCI DSS — стандарт безопасности индустрии платёжных карт
• 3-D Secure — протокол аутентификации
• Webhook — механизм обратного вызова

Гарантируем: 7 лет опыта, 50+ успешных интеграций. Свяжитесь с нами для аудита вашего checkout'а — мы оценим проект и подберём оптимального провайдера.