8 октября GPTunneL сообщил о кратковременной недоступности оплаты через «Т-Банк» с 15:30 до 16:11 мск. Проблема затронула прием платежей российскими картами через эквайринг, оплату через СБП и выставление счетов B2B-клиентам. Как следует из сообщения GPTunneL, остальные функции платформы в этот период оставались доступны, а после восстановления банковского сервиса платежи снова стали проходить стабильно.

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

Что известно о сбое.

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

Внешние наблюдения описывают сбой шире, чем только платежный сценарий GPTunneL. vc.ru писал, что обращения пользователей начали появляться около 11:00 мск: часть клиентов не могла войти в приложения «Т-Банка» и «Т-Бизнеса», а также видела уведомление о возможной недоступности некоторых функций. Банк сообщал о восстановлении к 14:19 мск. Эти отметки не совпадают с интервалом недоступности оплаты, который указал GPTunneL. Публикации не позволяют установить, был ли это один протяженный инцидент с несколькими этапами или разные нарушения в течение дня.

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

Почему GPTunneL остался доступен.

В тот же день сервис столкнулся и с отдельным инфраструктурным эпизодом в «Яндекс Облаке». По оценке GPTunneL, он затронул около 1% инфраструктуры платформы. Компания указала, что последствия были обработаны автоматически, а при необходимости подключались резервные серверы. К 08:26 мск облачный провайдер сообщил о переключении нагрузки, хотя зона ru-central1-b на тот момент оставалась недоступной.

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

Что учитывать командам AI-продуктов.

Первый вывод — статус-страница должна разделять недоступность продукта, платежей и отдельных способов пополнения. Формулировка «сервис не работает» в подобной ситуации была бы неточной: в GPTunneL не падали сайт и основные функции, но часть пользователей не могла провести оплату. Отдельный статус платежного контура позволяет снизить число обращений в поддержку и не заставляет клиентов искать проблему в своей карте, сети или браузере.

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

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

Подобные эпизоды уже происходили и в банковской инфраструктуре. «Медуза» ранее сообщала о сбое у «Т-Банка» 15 июля, а также напоминала о массовых проблемах с банковскими приложениями и СБП в начале апреля. Причины этих случаев в приведенных материалах не установлены, поэтому объединять их в единую цепочку нельзя. Однако для разработчиков вывод остается прикладным: внешняя платежная зависимость требует мониторинга, прозрачной коммуникации и процедур восстановления даже тогда, когда ядро AI-продукта продолжает работать.