Códigos de resposta do emissor e processamento
1) Por que entender os códigos de resposta
O código de resposta do emissor identifica a ação seguinte: repetir, repetir com o SCA/3DS, routar de outra forma, não repetir ou escalar o usuário. A classificação correta de códigos aumenta o Approval Rate (AR), reduz o custo e reduz a proporção de transações em disputa.
2) Taxonomia de códigos (representação geral)
Os códigos aparecem em autorizações (auth) do Equador/PSP, são exibidos no ISO 8583 e/ou guias de esquema. Há bastante grupo prático no iGaming:- Sucesso
'00' - Approved (ou '85' em implementações individuais).
Softlines (condições de tempo/correção)
`51` — Insufficient funds.
'91' - Issuer or switch inoperative (indisponibilidade temporária).
'96' - System malfuncion (erro geral).
'62/65' - Restrições/Exceeds withdrawal frequency (limites, liminares diurnos).
'R1/R3' ou códigos de esquema soft-decline SCA necessário/3DS needed.
Hard declins (razões permanentes/finais para esta tentativa)
'05' - Do not honorário (muitas vezes de fato hard se não marcado como 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 (erro de configuração).
3) Matriz de soluções (regras de processamento)
Abaixo, a matriz prática «código → ação» para o e-commerce (MCC 7995), onde 3DS2/SCA e COF/MIT são críticos.
4) Playbooks de retrações e backoff
Idempotidade: cada repetição deve ter idempotency-key e capturar a máquina de tentativa state.
4. 1 Modelo geral backoff (soft)
1º fracasso de repetição em 10-15 min
2º → em 1-2 h
3º → 24 h, depois parada
Se soft-decline = ESCA required → 3DS2 sem esperar.
4. 2 Repetições para assinaturas (MIT/COF)
Fila de retries MIT separada (não atrapalhar o CIT).
Backoff + jitter (dispersão acidental) exponencial para evitar «tempestade» às 00:00.
Armazenar vínculo com o CIT inicial (liability/PSD2).
5) Smart-roting por código/BIN/PSP
Se '91/96' para clusters BIN específicos, passe para PSP-B superior ao AR para esses emissores.
Para '05' depois do 3DS - experimente a rede tocen + outro PSP (às vezes ajuda a sensibilidade do emissor antifrode).
Suporte a tabela de estabilidade: emissor x PSP x 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_alternative6) Relação com 3DS/SCA
Soft-decline devido a SCA reconheça de forma clara e não perca esforços em retraias «cegas».
No CIT, execute o EMV 3DS 2. x; MIT subsequente - sem SCA em links corretos.
Transmita o máximo de contexto (device, account age, velocity) - aumenta a chance de frictionless.
7) Pattern Ux para aumentar a conversão
Estados compreensíveis: «Fundos insuficientes», «Banco temporariamente indisponível» e «Banco de confirmação necessário».
Botão Repetir com timer (para '91/96').
A oferta de alternativa é A2A/carteiras locais, valor parcial, outro PSP.
As assinaturas incluem notificações suaves com «atualizar a forma de pagamento» (link para card updater).
8) Disputas e charjbeks: O que é importante nos códigos
O 3DS sucess (ECI/CAVV) reduz o risco de frod/charjbeck e transfere a responsabilidade.
Os códigos '59/41/43' são de alto risco, preparem provas e antifrode.
'05' sem 3DS frequentemente vai para 'nenhuma autorização do titular'; uma repetição com 3DS reduz o risco de display.
Conduza artefatos: dsTransID/ECI/CAVV, logs SCA, prova de serviço.
9) Componentes arquitetônicos de processamento
Payments Orquestrator: regras, idempotidade, state-machine, smart-roting, 3DS-redefinição.
Serviço BIN: país/esquema/tipo de mapa → política de routing e limites.
3DS Server: versão 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
Card Updater: VAU/ABU/Atualizações Equeiros.
Observabilidade: métricas AR/Loss reasons, alertas de «05/91/96» no corte BIN/emissores.
10) Métricas e alertas
KPI:- AR por código e grupo (soft/hard).
- Soft-decline → um retrai de sucesso% (geral e com 3DS).
- Proporção de '05' após 3DS (→ anormalmente alta para ver routing/antifrode).
- '91/96' em BIN/países (SLO em disponibilidade de emissores/PSP).
- Tempo até a repetição bem sucedida (p50/p95).
- Costa per approved txn (considerando as tentativas repetidas).
- Spike '91/96'> X% em 15 min no cluster BIN.
- '05' crescimento> Y% após o sucesso do 3DS.
- Sucesso de retrações
11) Erros frequentes
Não há distinção SCA-soft vs geral '05'.
Múltiplas repetições sem idempotidade → duplas em ledger.
Ignorar limites de geo e emissor ('62/65').
Logar PAN/CVV em vez de tokens (violação PCI).
«Um PSP para todos os casos», sem roteamento para emissores.
12) Folha de cheque de implementação
- Dicionário de código mapping (ISO/esquemas/PSP) → taxonomia unificada (soft/hard/SCA).
- Máquina state e idimpotência para tentativas (chaves, TTL).
- Políticas backoff e limites de tentativa (separados para CIT/MIT).
- Movimento automático em 3DS2 para SCA-soft; Preservação dos artefactos.
- Smart-roting por BIN/país/emissor e saúde PSP.
- Dashboards AR/declins e alertas de espaçamento de códigos.
- Modelos UX para causas de rejeição e ofertas de alternativas.
- Integração com card updater e network tocens.
- Playbooks de displicência por grupos de razões.
- Políticas PCI: safe PAN, camuflagem, loging sem dados sensíveis.
13) Resumos
Os códigos de resposta são a linguagem do emissor. Traduza-o em ações compreensíveis: onde repetir, onde ir imediatamente para o 3DS, onde mudar o PSP e onde parar e oferecer uma alternativa. Um orquestrador forte com classificação correta soft/hard, regras backoff, smart-routing e observabilidade aumenta a conversão e reduz o custo das transações processadas no iGaming.