Відхилений платіж — це результат для аналізу, а не команда ще раз надіслати той самий запит. Спочатку визначте етап збою та поточний стан транзакції, потім обирайте наступну дію.
Корисний аналіз відхилень поєднує клієнтський сценарій, події платформи та відповідь провайдера. Наведена схема допомагає платіжній команді відокремити помилки запиту, проблеми автентифікації, відмови емітента й невизначені технічні результати, а не ховати їх в одному загальному відсотку відхилень.
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 року. Назви кодів і допустимі дії залежать від провайдера та платіжного методу; використовуйте документацію фактичного маршруту.