Коды ответов эмитента и обработка

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` — Do not 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`).
Предложение альтернативы: A2A/локальные кошельки, частичная сумма, другой 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.
• Успех ретраев < Z% неделя-к-неделе.

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.