Повторить оплату или остановиться: как не превратить отказ в двойное списание

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

Первый вопрос: отказ подтверждён?

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

Stripe указывает, что сетевой сбой не доказывает отсутствие выполненной операции. Для допустимого повтора того же запроса используются тот же ключ идемпотентности и параметры в пределах установленного окна; неопределённый результат требует сверки. Конкретные правила зависят от версии API. Источник: Stripe, Advanced error handling.

Soft и hard полезны только вместе с кодом

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

В справочнике Stripe требование дополнительной аутентификации ведёт к соответствующему действию клиента, истёкший срок карты требует другой карты, а общий отказ может потребовать обращения к эмитенту. Рекомендации различаются по коду, поэтому единое правило «повторять любой отказ» неверно. Источник: Stripe, Decline codes.

Пример небольшой безопасной политики

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

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

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

Два счётчика вместо одного лимита

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

Для допустимого следующего действия сохраняйте основание: конкретный ответ, применённое правило, время и проверенное состояние заказа. Это позволяет объяснить решение после инцидента. Запись «повтор разрешён автоматически» не показывает, было ли разрешение применимо именно к этой операции.

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

Где поставить защиту от дублирования

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

Даже транспортный успех требует проверки бизнес-результата. Adyen поясняет, что HTTP 200 может сопровождать отказ в авторизации; результат описывают платёжные поля ответа. Поэтому код HTTP нельзя использовать как единственный признак оплаченного заказа. Источник: Adyen, Refusal reasons.

Оцените цену восстановления на подходящей группе

Вернёмся к 15 заказам, которые в учебном примере допускают повтор. Допустим, по одной дополнительной попытке восстановили шесть заказов. Успешность этого шага составляет 6 / 15 = 40%, а на один восстановленный заказ пришлось 15 / 6 = 2,5 дополнительных попытки. Это показатели конкретной подходящей группы, не общий процент восстановления всех ста исходных случаев.

Сравните результат с качеством завершения. Нет ли повторного списания, отменённого заказа, лишней выдачи товара или неверного сообщения клиенту? Заказ, который технически стал успешным, но потребовал возврата из-за дублирования, нельзя без оговорки записывать в чистую пользу политики.

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

Что сообщить клиенту после остановки

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