Códigos de respuesta del emisor y procesamiento

1) Por qué entender los códigos de respuesta

El código de respuesta del emisor define la siguiente acción: repetir, repetir con SCA/3DS, enrutar de otra manera, no repetir o escalar al usuario. La correcta clasificación de códigos aumenta la Tasa Approval (AR), reduce el costo y reduce la proporción de transacciones controvertidas.

2) Taxonomía de códigos (representación general)

• Éxito

'00' - Approved (o '85' en implementaciones individuales).

Soft declines (condiciones temporales/correctivas)

`51` — Insufficient funds.
'91' - Issuer o switch inoperativo (inaccesibilidad temporal).
'96' - Malfunction del sistema (error total).
'62/65' - Restricciones/Exceeds withdrawal frequency (límites, umbrales diurnos).
'R1/R3' o códigos de esquema soft-decline según SCA requerido/3DS needed.

Hard declines (razones permanentes/definitivas para este intento)

'05' - Do not honor (a menudo en realidad duro si no está etiquetado 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 (error de parámetros).

3) Matriz de soluciones (reglas de procesamiento)

A continuación, una matriz práctica de «código → acción» para e-commerce (MCC 7995), donde 3DS2/SCA y COF/MIT son críticos.

4) Playbucks retraye y backoff

Idempotencia: cada repetición debe tener idempotency-key y fijar el state-machine de los intentos.

4. 1 Plantilla general de backoff (soft)

1er fallo → repetición después de 10-15 minutos

2ª → después de 1-2 h

3ª → después de 24 horas, luego parada

Si soft-decline = SCA required → 3DS2 inmediatamente sin esperar.

4. 2 Repeticiones para suscripciones (MIT/COF)

Cola de retornos MIT independiente (no interfiera con CIT).
Retroceso exponencial + jitter (dispersión aleatoria) para evitar una «tormenta» a las 00:00.
Almacenar la referencia a la CIT inicial (liability/PSD2).

5) Smart-routing por código/BIN/PSP

Si '91/96' para clústeres BIN específicos, cambie a PSP-B, que tiene una AR superior para estos emisores.
Para '05' después de 3DS - pruebe red token + otro PSP (a veces ayuda la sensibilidad antifraude del emisor).
Mantenga la tabla de sostenibilidad: emisor × modo 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) Relación con 3DS/SCA

Soft-decline, debido a SCA, reconoce de forma inequívoca y no malgastes intentos en retratos «ciegos».
En CIT, ejecute EMV 3DS 2. x; MIT subsiguientes - sin SCA con referencias correctas.
Pasar el máximo de contexto (device, account age, velocity) - aumenta la probabilidad de frictionless.

7) Patrones UX para mejorar la conversión

Estados comprensibles: «Fondos insuficientes», «El banco no está disponible temporalmente», «Requiere confirmación en el banco».
Botón Repetir con temporizador (para '91/96').
Oferta alternativa: A2A/billeteras locales, suma parcial, otro PSP.
En las suscripciones, las notificaciones suaves con «actualizar el método de pago» (link on card updater).

8) Disputas y charjbacks: lo que es importante por códigos

El éxito 3DS (ECI/CAVV) reduce el riesgo de frod/charjback y transfiere la responsabilidad.
Los códigos '59/41/43' son de alto riesgo: prepara pruebas y registros antifraude.
'05' sin 3DS suele entrar en «no hay autorización del titular»; repetición con 3DS reduce el riesgo de dispersión.
Mantener los artefactos: dsTransID/ECI/CAVV, registros SCA, prueba de la prestación del servicio.

9) Componentes de mecanizado arquitectónico

Payments Orchestrator: reglas, idempotencia, state-machine, smart-routing, reiniciación 3DS.
Servicio BIN: país/esquema/tipo de tarjeta → política de routing y límites.
3DS Server: versiones 2. 1/2. 2/2. 3, web/mobile SDK, decoupled.
Tokenization: network tokens (VTS/MDES/и т. п.) + vault-fallback.
Actualización de tarjetas: actualizaciones VAU/ABU/Ecuador.
Observabilidad: métricas AR/Loss reasons, alertas por ráfagas de '05/91/96' en el corte BIN/emisores.

10) Métricas y alertas

• AR por códigos y por grupos (soft/hard).
• Soft-decline → un éxito retray% (general y con 3DS).
• Lóbulo '05' después de 3DS (anormalmente alto → ver routing/antifraude).
• '91/96' por BIN/países (SLO sobre disponibilidad de emisores/PSP).
• Tiempo hasta la repetición exitosa (p50/p95).
• Coste per approved txn (considerando los intentos repetidos).

• Spike '91/96'> X% en 15 minutos en un clúster BIN.
• '05' crecimiento> Y% después de un 3DS exitoso.
• Éxito de los retiros

11) Errores frecuentes

Falta de distinción SCA-soft vs general '05'.
Repeticiones múltiples sin idempotencia → tomas en el ledger.
Ignora las restricciones geográficas y los límites del emisor ('62/65').
Lógica PAN/CVV en lugar de tokens (infracción de PCI).
«Un PSP para todos los casos» sin routing por emisores.

12) Lista de verificación de implementación

• Diccionario de Mapping Code (ISO/diagrama/PSP) → una taxonomía única (soft/hard/SCA).
• Máquina de estado e idempotencia para intentos (llaves, TTL).
• Políticas de backoff y límites de intento (separados para CIT/MIT).
• Corte automático en 3DS2 con SCA-soft; preservación de artefactos.
• Smart-routing por BIN/país/emisor y salud PSP.
• Los dashboards de AR/declines y alertas sobre los adhesiones de códigos.
• Plantillas UX para causas de rechazo y propuestas de alternativas.
• Integración con tarjetas actualizadoras y tokens de red.
• Pantallas de reproducción por grupos de razones.
• PCI Policy: PAN-safe, enmascaramiento, lógica sin datos sensibles.

13) Resumen

Los códigos de respuesta son el «idioma» del emisor. Tradúzcalo en acciones comprensibles: dónde repetir, dónde ir a 3DS de inmediato, dónde cambiar de PSP, y dónde parar y ofrecer una alternativa. Un orquestador fuerte con la clasificación correcta de soft/hard, reglas de backoff, routing inteligente y observabilidad aumenta constantemente la conversión y reduce el costo de las transacciones procesadas en iGaming.