Возврат — самая нервная часть работы с любым сервисом, который имеет дело с деньгами и сторонними API. Если что-то идёт не по плану, клиент остаётся один на один с тикетом, формой обратной связи и ощущением, что про него забыли. Мы потратили I квартал 2026 года на то, чтобы переписать поток возвратов с нуля — и теперь все деньги по сорванным заказам возвращаются сами, без участия человека с нашей или вашей стороны.
Этот пост — про то, что конкретно поменялось, как теперь выглядит жизнь заказа, который пошёл не по плану, и какие гарантии мы зашили в систему так, чтобы их нельзя было «забыть» соблюсти.
Почему вообще пришлось переделывать
Старая система держалась на трёх костылях. Во-первых, статус «частично выполнен» подсвечивался только в админке — клиент в кабинете видел просто «выполнен». Во-вторых, возврат можно было запустить только вручную через тикет. В-третьих, сам пересчёт суммы был сложнее, чем нужно: считали процент по факту, потом верифицировали глазами, потом пересчитывали с учётом скидки за провайдера. К концу 2025 года средний срок возврата вырос до 19 часов, а доля заказов, где клиент просто не дождался возврата и ушёл, — до 4,2%.
Это была не проблема намерения, а проблема архитектуры: ручные шаги в pipeline всегда вырастают в задержки и ошибки. Решение — убрать их вообще.
Что поменялось
- Возврат стартует автоматически в ту же минуту, как заказ помечается «частично выполнен» или «отменён»
- Уведомление о возврате приходит в Telegram и на email одновременно, не последовательно
- В кабинете каждое списание и каждый возврат отображается отдельной строкой в «Операциях» — с суммой, временем, привязкой к заказу и кнопкой «открыть заказ»
- Максимальный срок возврата на баланс — 24 часа, средний по апрелю — 2 часа 11 минут
- Если возврат задержался свыше 12 часов, бонус +5% к следующему пополнению начисляется автоматически — без обращения в поддержку
Как это устроено внутри
Каждый заказ теперь живёт под наблюдением фонового воркера, который раз в минуту опрашивает провайдера на предмет финального статуса. Как только статус приходит — «выполнен», «выполнен частично», «отменён», «ошибка» — воркер сам считает, сколько денег нужно вернуть, и инициирует обратную транзакцию. Если у заказа было 10 000 заявленных единиц, а провайдер фактически прислал 7 800, на баланс падает разница (2 200 × цена за единицу), и в «Операциях» появляется строка «Возврат · заказ #N · 7 800/10 000».
Это не «улучшение» — это переход с реактивной модели (клиент пришёл → разобрались) на проактивную (система увидела → вернула). Для пользователя разница в том, что про возврат можно вообще не думать. Поддержка теперь подключается только в граничных случаях — например, когда провайдер споткнулся на ссылке и нужно решить, перезапускать заказ или возвращать всю сумму.
Что это значит для клиентов
- 1Не нужно следить за заказами и проверять, всё ли вернулось — система делает это сама
- 2Не нужно писать тикеты ради процедуры — поддержка остаётся только для нестандартных кейсов
- 3Можно опираться на 24-часовой SLA в собственных финансовых регламентах — мы выдерживаем его в среднем на порядок строже
- 4Внутренняя финансовая отчётность стала чище: одна транзакция на одну операцию, ничего не «висит»
«Лучшая поддержка — та, к которой не пришлось обращаться. Возвраты должны работать как электричество в розетке: ты нажимаешь — оно идёт, без оформления заявок.»
Что дальше
В мае выкатим вторую часть — автоматический «retry» для заказов, которые отвалились из-за временной недоступности провайдера. Сейчас такой заказ просто возвращается на баланс. После обновления система сначала попробует переподключиться к запасному провайдеру (для большинства тарифов их несколько), и только если резерв тоже не справился — оформит возврат. Для клиента это значит, что доля выполненных заказов вырастет ещё на 2–3 процентных пункта без каких-либо изменений с его стороны.
Если что-то в новой механике работает не так, как описано — пишите. Мы заведомо проще принимаем правки в проактивные системы, чем правим устные обещания «в следующий раз будет лучше».
