Сбой Яндекс Go в Узбекистане — что делать бизнесу

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

Если вы ищете «сбой Яндекс Go в Узбекистане», практическая задача для бизнеса такая: из-за сбоя у другой компании корзина покупателя не должна пропасть у вас. Есть условие: ваша система приёма заказов на сайте, в мобильном приложении или Telegram и её база должны работать.

Заказ сохранён — не значит, что деньги поступили. Эту разницу должны видеть на экране и клиент, и менеджер. Иначе клиент может заплатить повторно, а сотрудник — учесть неподтверждённый платёж как поступление денег.

Сбой Яндекс Go в Узбекистане: не выдавайте догадки за причины

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

Адреса для проверки: по Yandex Go — ссылка с датой 11 октября 2026 года, по Yandex Uzbekistan — ссылка за 12 октября, по Uzum Market — ссылка за 10 октября. Сама ссылка ничего не доказывает. Пока её содержание не проверено, не представляйте причину сбоя или время восстановления как установленный факт.

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

Старой новостью нельзя объяснить текущий сбой Uzum Market. Проверяйте актуальное состояние в приложении сервиса или в официальном подтверждённом канале связи; при необходимости обращайтесь в поддержку. Для бизнес-интеграции выясняйте состояние именно того API или партнёрского кабинета, которым пользуетесь вы.

Приложение открылось — ещё не значит, что все операции работают. Ошибка на одном телефоне тоже не доказывает общий сбой. Проверьте местное интернет-соединение и устройство, затем убедитесь, что собственный сервер вашего бизнеса работает.

Вместо «ничего не работает» сообщите оператору, какая именно операция не выполняется. Заказ не сохраняется? Не приходит подтверждение оплаты? Запрос на доставку остаётся без ответа? Пока не ясно, что остановилось, правильную меру не выбрать.

Сначала сохраняйте заказ в своей базе

Кнопка «Оформить заказ» на сайте или в мобильном приложении должна сначала сохранять запись в базе под контролем бизнеса. Передача во внешний сервис — следующий шаг. Даже если ответа от него нет, запись заказа должна остаться у вас.

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

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

При приёме заказов через Telegram нужен тот же порядок. Мало того, что бот получил сообщение: подтверждение «Ваш заказ сохранён» отправляется клиенту только после записи в базу. Сообщение в личном чате менеджера не заменяет официальную запись заказа.

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

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

Если ответ на платёж не пришёл, показывайте статус «проверяется»

Отсутствие ответа на платёжный запрос не означает, что деньги не списаны. Провайдер мог выполнить операцию, но его ответ не дошёл до вашей системы. Не пишите «Платёж не прошёл» сразу после истечения времени ожидания.

Храните статусы заказа и оплаты отдельно. «Заказ принят» означает, что бизнес сохранил запись. В статусе «Ожидается подтверждение оплаты» поступление денег ещё не подтверждено. Этот статус не должен разрешать отгрузку товара со склада.

В документации Payme Business для разработчиков в Merchant API предусмотрены отдельные методы проверки и выполнения транзакции. Стройте интеграцию по правилам того API, которым пользуетесь. Общая рекомендация не заменяет порядок работы с транзакциями, установленный провайдером.

Клиенту не должно приходиться искать «платёж завис что делать». Напишите на экране, что автоматическая проверка продолжается, и покажите способ связаться с оператором. Если результат неизвестен, не размещайте кнопку, которая подталкивает клиента заплатить ещё раз.

Вариант сообщения: «Ваш заказ сохранён. Подтверждение оплаты пока не поступило, мы проверяем статус. Если деньги списаны с карты, не платите повторно. Отправьте оператору номер заказа. Сообщим вам, когда выясним результат.»

Сообщение можно показать на выбранном клиентом узбекском, русском или английском языке. Выбирайте язык под аудиторию. В каждой версии одинаково объясняйте статус платежа и следующий шаг для клиента.

В интерфейсе менеджера тоже должен быть виден статус «проверяется». Иначе сайт просит клиента подождать, а сотрудник отдела продаж отправляет новую ссылку на оплату. Не обещайте, что платёж обязательно пройдёт. Безопаснее предложить другой способ оплаты после того, как станет известен результат предыдущей операции.

Повторный запрос не должен создавать новый заказ или платёж

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

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

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

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

Проверяйте и уведомления об оплате. Сначала подтвердите, что уведомление пришло от подлинного отправителя. Затем проверьте соответствие заказа и суммы; только после этого переводите запись в статус «оплачен». Если то же уведомление придёт снова, второе задание на отгрузку со склада создаваться не должно.

При обращении «Деньги списали дважды» оператор должен по номеру заказа видеть связанные с ним транзакции. Автоматически возвращать деньги до завершения проверки тоже опасно: возврат — отдельная финансовая операция. Не запрашивайте у клиента код безопасности карты или секретные данные подтверждения для проведения проверки.

Сервис восстановился — не отправляйте всю очередь без проверки

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

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

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

Учитывайте и то, сколько времени задание провело в очереди. За это время товар могли продать, а клиент — отменить заказ. После восстановления сервиса проверяйте актуальный статус заказа, прежде чем выполнять старое задание.

Запись продажи в 1C не означает выполнения фискальной операции. Программные сервисы ARCA предусматривают интеграцию фискального оборудования с 1C и ERP через API. Отдельно обозначьте зависимость от фискального сервиса в технической схеме. При повторной обработке фискальной операции также соблюдайте правила соответствующего сервиса.

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

Бюджет технического аудита зависит от связей между системами

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

Модель расчёта для условного магазина: начальный бюджет = часы аудита × ставка аудита + часы разработки × ставка разработки + часы тестирования × ставка тестирования. Ставки и объём работ берите из предложения подрядчика. В ежемесячные расходы входят инфраструктура и согласованная плата за обслуживание. Эта формула — не рыночная цена и не ценовое предложение Celion.

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

Отправьте технической команде или каждому подрядчику, который готовит предложение, эти вопросы:

• Где сохраняется заказ? Если внешний API не отвечает, сможет ли менеджер найти заказ с сайта и из Telegram?
• Какая зависимость останавливает приём? Используют ли Telegram-бот и сайт один сервер или одну базу?
• Как отображается платёж с неизвестным результатом? Есть ли на экранах клиента и оператора статус, который не подталкивает к повторной оплате?
• Как блокируются повторные запросы? Отдельно опишите порядок выявления повторов для заказа, платежа и записи в CRM.
• Как проверяется восстановление? Кто сверяет записи с данными провайдера? Кто отвечает за платежи с расхождениями?
• Что входит в предложение? Указаны ли отдельно тестирование сбоев, инструкция для оператора и расходы на последующий мониторинг?

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

Сначала проведите аудит обработки заказов

Чтобы обсудить с Celion объём работ по техническому аудиту и API-интеграции, покажите, как проходит заказ на вашем сайте или в мобильном приложении. Чётко поставьте задачу аудита: где сохраняется заказ, когда внешний сервис не отвечает, и кто и как проверяет результат платежа?

Связаться с нами