Коди відповідей емітента та обробка

1) Навіщо розуміти коди відповідей

Код відповіді емітента визначає наступну дію: повторити, повторити з SCA/3DS, маршрутизувати інакше, не повторювати або ескалувати користувачеві. Коректна класифікація кодів підвищує Approval Rate (AR), знижує вартість і зменшує частку спірних транзакцій.

2) Таксономія кодів (загальне уявлення)

• Успіх

«00» - Approved (або «85» в окремих реалізаціях).

Soft declines (тимчасові/виправні умови)

`51` — Insufficient funds.
«91» - Issuer or switch inoperative (тимчасова недоступність).
'96'- System malfunction (загальна помилка).
'62/65'- Restrictions/Exceeds withdrawal frequency (ліміти, денні пороги).
'R1/R3'або схемні коди soft-decline по SCA потрібно/3DS needed.

Hard declines (постійні/остаточні причини для даної спроби)

«05» - Don't honor (часто фактично hard, якщо не позначений як SCA-soft).
`14` — Invalid card number.
`54` — Expired card.
`57` — Transaction not permitted to cardholder.
`59` — Suspected fraud.
`43/41` — Stolen/Lost card.
'03/04/13'- Invalid merchant/withdrawal/amount (помилка параметрів).

3) Матриця рішень (правила обробки)

Нижче - практична матриця «код → дія» для e-commerce (MCC 7995), де 3DS2/SCA і COF/MIT критичні.

4) Плейбуки ретраїв і backoff

Ідемпотентність: кожен повтор повинен мати idempotency-key і фіксувати state-машину спроб.

4. 1 Загальний шаблон backoff (soft)

1-а невдача → повтор через 10-15 хв

2-а → через 1-2 год

3-я → через 24 год, потім зупинка

Якщо soft-decline = SCA required → відразу 3DS2 без очікування.

4. 2 Повтори для підписок (MIT/COF)

Окрема черга MIT retries (не заважати CIT).
Експоненціальний backoff + jitter (випадковий розкид), щоб уникнути «шторму» в 00:00.
Зберігати прив'язку до initial CIT (liability/PSD2).

5) Smart-routing за кодами/BIN/PSP

Якщо'91/96'за конкретними BIN-кластерами, перемикайте на PSP-B, у якого вище AR для цих емітентів.
Для'05'після 3DS - спробуйте network token + інший PSP (іноді допомагає чутливість антифроду емітента).
Підтримуйте таблицю стійкості: емітент × PSP × 3DS-режим → AR/latency.

IF code in {91,96} AND bin_country == "X" THEN route = PSP_B
ELSE IF code == SCA_REQUIRED THEN enforce_3DS = true
ELSE IF code == 05 AND was_3DS == false THEN retry_with_3DS
ELSE IF code in HARD THEN stop_and_prompt_alternative

6) Взаємозв'язок з 3DS/SCA

Soft-decline через SCA розпізнавайте однозначно і не витрачайте спроби на «сліпі» ретраї.
На CIT запускайте EMV 3DS 2. x; наступні MIT - без SCA при коректних посиланнях.
Передавайте максимум контексту (device, account age, velocity) - підвищує шанс frictionless.

7) UX-патерни для підвищення конверсії

Зрозумілі статуси: «Недостатньо коштів», «Банк тимчасово недоступний», «Потрібне підтвердження в банку».
Кнопка «Повторити» з таймером (для'91/96').
Пропозиція альтернативи: А2А/локальні гаманці, часткова сума, інший PSP.
У підписках - м'які нотифікації з «оновити спосіб оплати» (link на card updater).

8) Спори і чарджбеки: що важливо за кодами

3DS success (ECI/CAVV) знижує ризик фроду/чарджбека і переносить відповідальність.
Коди «59/41/43» - високоризикові: готуйте докази і антифрод-логи.
'05'без 3DS часто йде в «немає авторизації власника»; повтор з 3DS зменшує ризик диспуту.
Ведіть артефакти: dsTransID/ECI/CAVV, логи SCA, доказ надання послуги.

9) Архітектурні компоненти обробки

Payments Orchestrator: правила, ідемпотентність, state-машина, smart-routing, 3DS-переініціація.
BIN-сервіс: країна/схема/тип карти → політика роутингу та лімітів.
3DS Server: версії 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
Card Updater: VAU/ABU/еквайєрські оновлення.
Observability: метрики AR/Loss reasons, алерти по сплесках'05/91/96'в розрізі BIN/емітентів.

10) Метрики та алерти

• AR за кодами і за групами (soft/hard).
• Soft-decline → успішний ретрай% (загальний і з 3DS).
• Частка «05» після 3DS (аномально висока → дивимося роутинг/антифрод).
• '91/96'по BIN/країнам (SLO по доступності емітентів/PSP).
• Час до успішного повтору (p50/p95).
• Cost per approved txn (враховуючи повторні спроби).

• Спайк'91/96'> X% за 15 хв в кластері BIN.
• '05'зростання> Y% після успішного 3DS.
• Успіх ретраїв

11) Часті помилки

Відсутність розрізнення SCA-soft vs загальний'05'.
Множинні повтори без ідемпотентності → дублі в ledger.
Ігнорування гео-обмежень і лімітів емітента («62/65»).
Логування PAN/CVV замість токенів (порушення PCI).
«Один PSP на всі випадки» без роутингу за емітентами.

12) Чек-лист впровадження

• Словник маппінгу кодів (ISO/схеми/PSP) → єдина таксономія (soft/hard/SCA).
• State-машина і ідемпотентність для спроб (ключі, TTL).
• Backoff-політики і ліміти спроб (окремо для CIT/MIT).
• Автоперехід в 3DS2 при SCA-soft; збереження артефактів.
• Smart-routing по BIN/країні/емітенту і здоров'ю PSP.
• Дешборди AR/declines і алерти за спайками кодів.
• UX-шаблони для причин відмови і пропозицій альтернатив.
• Інтеграція з card updater і network tokens.
• Плейбуки диспутів за групами причин.
• Політики PCI: PAN-safe, маскування, логування без чутливих даних.

13) Резюме

Коди відповідей - це «мова» емітента. Переведіть його в зрозумілі дії: де повторювати, де відразу йти в 3DS, де перемикати PSP, а де зупинятися і пропонувати альтернативу. Сильний оркестратор з правильною класифікацією soft/hard, backoff-правилами, smart-routingом і спостережуваністю стабільно підвищує конверсію і знижує вартість оброблених транзакцій в iGaming.