Платежный сбой. Почему первые секунды решают всё

Полностью исключить технические сбои невозможно. Но можно заранее построить инфраструктуру и процессы так, чтобы отдельный отказ не превращался в многочасовой простой. Последствия сбоя зависят не только от того, насколько быстро техническая команда восстановит систему. Не менее важно, что компания успеет сделать для клиента в первые минуты и даже секунды. Сохранится ли заказ, появится ли другой способ оплаты и получит ли пользователь понятное объяснение происходящего.

Что нужно предусмотреть до сбоя

Автоматическое переключение на резервный канал

Если недоступен основной банк-эквайер или платежный провайдер, трафик, в идеале, должен перенаправляться без участия дежурного инженера. Чем больше действий требуется согласовывать вручную, тем больше времени бизнес теряет.

Но одного лишь факта наличия второго провайдера недостаточно.

Резерв должен быть действительно независим от основного контура. Если оба шлюза находятся в одном дата-центре, используют одного оператора связи или «завязаны» на один и тот же расчетный банк, такой резерв защитит далеко не от всех сценариев.

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

Наконец, резерв должен регулярно использоваться. Канал, через который реальные платежи последний раз проходили год назад, сложно считать полноценным резервом. Часть трафика полезно планово переводить на него еще до возникновения аварии.

По нашим наблюдениям за партнерскими интеграциями, компаний, у которых резерв действительно способен автоматически подхватить трафик, пока немного — не более 20%. Это экспертная оценка, а не результат исследования рынка, но на практике именно необходимость ручных переключений часто превращает минуты простоя в часы.

Альтернативный способ завершить оплату

Это может быть QR-код СБП, оплата по сохраненной карте или ссылка, по которой клиент сможет вернуться к покупке позже. Такой сценарий должен быть встроен в клиентский путь заранее, а не придумываться уже во время аварии.

Сохранение заказа

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

Четкое распределение ответственности

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

Регулярные учения

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

Был, например, случай, когда один из модулей несколько лет работал штатно, а затем остановился из-за переполнения разрядов: разработчик когда-то не предполагал, что внутренний счетчик достигнет предельного значения. Транзакции зависли, пользователи перестали получать уведомления, а дежурная смена получила множество разнородных аллертов, которые пришлось вручную сводить к одной первопричине. Именно поэтому стресс-тесты должны включать не только наиболее вероятные, но и тяжелые нетиповые сценарии.

Первые минуты: сохранить платеж и клиента

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

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

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

Читайте также

ИИ-помощник, который знает вашу конфигурацию. Обзор one-s-mcp

IT-World расскажет, как заставить ИИ-помощников приносить пользу в 1С, а не выдумывать нерабочий код. Российский one-s-mcp передает нейросети точную схему вашей конфигурации. Результат: разработчики сдают задачи с первого раза, а аналитики сами получают любые цифры из базы.

Здесь время действительно имеет значение. Совместное исследование FreedomPay, Dynatrace и Retail Economics, опубликованное в январе 2026 года, оценило терпение американского покупателя при сбое оплаты примерно в семь минут. Российского аналога такого исследования нет, поэтому переносить цифру напрямую на наш рынок нельзя, но сам порядок величин показателен: окно, в котором клиента еще относительно легко удержать, измеряется минутами, а не часами.

По нашим наблюдениям за сотнями партнерских интеграций, в первые три-пять минут пользователь обычно просто повторяет попытку. После пяти-десяти минут в сервисах с коротким циклом принятия решения — например, доставке еды, такси или каршеринге — доля клиентов, которые уходят к альтернативному сервису, может достигать 30-40%. Это также экспертная оценка, а не отраслевая статистика, но она хорошо показывает, почему первые минуты настолько важны.

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

Первые часы: найти причину и проверить деньги

После первичного переключения начинается более глубокая диагностика.

Технической команде необходимо собрать логи, определить момент возникновения сбоя, его масштаб и затронутые компоненты. При этом важно не ориентироваться только на полный отказ. Система может формально оставаться доступной, но часть операций перестанет проходить — например, из-за частичной деградации сетевого оборудования. Такой инцидент заметить сложнее, хотя для клиента результат тот же: платеж не состоялся.

Для платежного сервиса восстановить доступность недостаточно. Не менее важная задача — проверить целостность транзакций.

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

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

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

Первые сутки: стабилизация и разбор последствий

После возвращения сервиса в штатный режим инцидент не заканчивается.

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

Отдельно стоит оценить три вида последствий.

Прямые потери

Объем транзакций, которые не состоялись во время простоя.

Операционные потери

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

Отложенные потери

Это клиенты, которые не вернулись к покупке или выбрали другой сервис. Именно эту часть ущерба оценить сложнее всего, поэтому ее часто недооценивают.

Читайте также

Максим Березин: «Импортозамещение виртуализации стало необходимостью для снижения рисков»

Как меняется роль виртуализации в стратегиях компаний, какие решения на уровне виртуальной среды помогают сократить затраты на ИТ, как реализуется защита ИТ-периметра и какие инструменты помогают ускорить миграцию, IT-World рассказывает Максим БЕРЕЗИН, директор по развитию бизнеса Orion soft.

Для крупных компаний цена продолжительного ИТ-простоя, в целом, может быть очень высокой. Например, по данным ITIC за 2024 год, более чем у 90% опрошенных средних и крупных компаний час простоя обходится дороже $300 тыс. Это глобальная оценка и она относится ко всем видам ИТ-простоя, а не только платежным системам, поэтому применять ее непосредственно к конкретному бизнесу нельзя. Но она хорошо показывает, почему отказоустойчивость давно перестала быть исключительно задачей технического подразделения.

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

Когда нужно подключать регулятора

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

Для банков и других регулируемых финансовых организаций могут действовать требования Банка России и ФинЦЕРТ. Для компьютерных инцидентов на объектах критической информационной инфраструктуры предусмотрено взаимодействие с НКЦКИ. Если произошла утечка персональных данных, возникает отдельная обязанность по взаимодействию с Роскомнадзором.

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

Четыре ошибки, которые увеличивают время простоя

На практике одни и те же проблемы повторяются достаточно часто.

Резерв есть только на бумаге

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

Резервный сценарий никогда не проверяли целиком

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

Компания готовится только к типовым отказам

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

Ответственность размыта между участниками интеграции

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

Что проверить до того, как что-то сломается

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

• Резерв не зависит от основного контура — другой дата-центр, независимые каналы связи, по возможности другой расчетный банк.
• Емкость резерва проверена на пиковой нагрузке, а не только на средних объемах.
• Через резерв регулярно проходят реальные операции, а не только тестовые платежи.
• У клиента есть альтернативный способ оплаты — например, СБП, сохраненная карта или ссылка на отложенную оплату.
• Корзина и содержание заказа сохраняются, даже если платеж не прошел.
• Текст сообщения об ошибке подготовлен заранее и объясняет клиенту, что произошло и что делать дальше.
• Определены ответственные за взаимодействие с банками, провайдерами, клиентами и при необходимости регуляторами.
• Проверка целостности транзакций встроена в процедуру восстановления, а не проводится задним числом.
• Аварийные сценарии регулярно отрабатываются, а после каждого серьезного инцидента корректируются архитектура или регламент.

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

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