Отклонённый платёж — это результат для анализа, а не команда ещё раз отправить тот же запрос. Сначала определите этап сбоя и текущее состояние транзакции, затем выбирайте следующее действие.
Полезный анализ отказов объединяет клиентский сценарий, события платформы и ответ провайдера. Эта схема помогает платёжной команде отделить ошибки запроса, проблемы аутентификации, отказы эмитента и неопределённые технические результаты, а не прятать их в одном общем проценте отклонений.
1. Определите, на каком этапе остановился платёж
Успешный HTTP-ответ не подтверждает одобрение платежа. Документация Adyen прямо объясняет, что обработанный запрос может вернуть HTTP 200, хотя платёж отклонён. Читайте платёжный результат и связанные события статуса, а не только транспортный код.
Постройте путь от отправки платёжных данных клиентом до подтверждения бизнес-результата платформой. Для каждого инцидента определяйте последний подтверждённый этап. Брошенная оплата до запроса авторизации отличается от отказа эмитента после его отправки. В отчётности эти случаи должны быть отдельными.
2. Классифицируйте результат до выбора действия
| Группа результатов | Первый вопрос | Практическое следующее действие |
|---|---|---|
| Ошибка запроса или настройки | Был ли запрос корректным для нужного метода и валюты? | Исправить запрос или настройки и проверить документированным тестовым сценарием |
| Требуется аутентификация | Завершил ли клиент нужный сценарий аутентификации? | Пройти поддерживаемый провайдером сценарий вместо простого повтора запроса |
| Отказ эмитента | Какое действие рекомендует ответ эмитента или провайдера? | Следовать указанию; не повторять, если это прямо запрещено |
| Технический или неизвестный результат | Известно ли конечное состояние из другого источника? | Проверить существующую транзакцию и события статуса до создания нового платежа |
Общий ответ do_not_honor не устанавливает единственную причину сбоя. Справка Stripe отделяет его от конкретного результата authentication_required. Сохраняйте это различие в заметках поддержки вместо предположения, что каждый отказ вызван риск-правилом.
3. Соберите доказательства для конкретного вопроса
Передайте поддержке одну согласованную запись инцидента. Скриншот общего сообщения об ошибке редко объясняет, какой этап не сработал.
- Внутренний идентификатор заказа или платежа, идентификатор провайдера, время с часовым поясом, сумма и валюта.
- Платёжный метод, релевантный рынок или сегмент страны эмитента, маршрут и среда — без лишних персональных данных.
- Точные коды результата и отказа, итог аутентификации, события статуса и число попыток.
- Ожидаемый и фактический результат, связанный релиз или изменение настроек.
Используйте маскированные идентификаторы и журналы с ограниченным доступом. Не храните CVV после авторизации: PCI SSC относит его к чувствительным данным аутентификации. Подробные причины отказа должны оставаться в авторизованных операционных инструментах, а не в сообщении клиенту.
4. Отделите повтор запроса от новой платёжной попытки
Тайм-аут не доказывает, что платёж не состоялся. Сначала проверьте существующую операцию. Если провайдер поддерживает идемпотентные запросы, повторяйте ту же операцию по документированным правилам ключа и параметров; документация API Stripe объясняет, как это предотвращает дублирование.
- Определите результаты, требующие действия клиента, и случаи повторного рассмотрения по указаниям провайдера.
- Соблюдайте прямой запрет повтора, а не считайте любой отказ временным.
- Связывайте историю попыток с исходным заказом, чтобы повторные запросы не выглядели независимыми продажами.
- Проверьте актуальные правила и ограничения провайдера до внедрения автоматического графика повторов.
Идемпотентность защищает операцию от случайного дублирования. Она не превращает отказ эмитента в одобрение и не является основанием обходить требование аутентификации.
5. Измеряйте результат для клиента, а не только запросы
Начните с чётких знаменателей. Ниже — варианты определений для вашей отчётности, которые нужно задокументировать; это не утверждения о результатах конкретного провайдера.
| Показатель | Пример определения | Что помогает понять |
|---|---|---|
| Авторизации с первой попытки | Одобренные первые отправленные авторизации / все первые отправленные авторизации | Как часто одобряют исходную отправленную попытку |
| Итоговый успех авторизации | Заказы с одобренной авторизацией / заказы хотя бы с одной отправленной авторизацией в определённом окне наблюдения | Помогают ли следующие попытки тому же заказу |
| Завершение аутентификации | Завершённые обязательные сценарии аутентификации / начатые обязательные сценарии | На каком этапе аутентификации клиенты прекращают действие |
Сравнивайте одинаковые сегменты: метод, рынок, группу страны эмитента, валюту и отчётный период. Отделите брошенную оплату от результатов отправленных авторизаций. Считайте успешно авторизованный заказ один раз, даже после нескольких запросов, и определите учёт событий, приходящих с задержкой.
6. Дайте клиенту следующий шаг, а команде — журнал решений
Показывайте понятное сообщение, соответствующее поддерживаемому следующему действию: например, завершить аутентификацию или попробовать другой доступный метод оплаты. Не раскрывайте внутренние решения антифрод-правил. Дайте авторизованной поддержке доказательства для разбора конкретного события.
Фиксируйте классификацию, ответственного, выбранное действие и результат. Исследуя повторяющуюся проблему, меняйте одну релевантную переменную за раз и сравнивайте те же сегменты за определённый период. Цель — надёжное объяснение и подходящий путь восстановления, а не больше повторов ради повторов.
Источники и материалы для чтения
- Adyen — причины отклонений: https://docs.adyen.com/development-resources/refusal-reasons/
- Stripe — коды отклонений: https://docs.stripe.com/declines/codes
- Stripe — идемпотентные запросы: https://docs.stripe.com/api/idempotent_requests
- PCI Security Standards Council — FAQ 1318: https://www.pcisecuritystandards.org/faqs/1318/
Публичные источники проверены 13 октября 2026 года. Названия кодов и допустимые действия зависят от провайдера и платёжного метода; используйте документацию фактического маршрута.