Incidencias en los pagos

TL; DR

Un incidente en los pagos es una operación administrada: clasifica rápidamente → estabiliza UX (Feilover/Degrade) → ahorra dinero (idempotencia/reglas de bloque) → comunica → recupera → bloquea RCA de forma transparente. Los principales SLO son: MTTA, MTTR, TtW/TtR, AR, Webhook p95, tolerancia cero a la doble carga/refundición.

1) Matriz de gravedad (Severity & Impact)

Disparadores: alertas SLA/tesorería/conciliación, picos de sapport, monitoreo AR/latency/webhooks.

2) Roles y canal de comunicación

Incident Commander (IC) es el propietario de la línea de tiempo y las soluciones.
Payments Tech Lead - enrutamiento, idempotencia, flags.
Treasury Lead - liquidez, prefundación, reservas stress.
Risk/AML - sanciones, reglas de bloque, SoF/SoW.
Comms Manager - Plantillas de partners/sapport, status update.
Recon/Finance - conciliación, storno/registros, estimaciones de pérdidas.

Sede: # payments-incident-warroom (chat), Zoom-bridge + documento en vivo de la línea de tiempo (UTC).

3) Ciclo universal (para cualquier incidente)

1. Nat & Triage → confirmar métricas/cobertura, asignar Sev.
2. Stabilize UX → Feilover Routing, degradación de Fich, congelación de autocaravanas peligrosas.
3. Money Safety → incluir idempotencia/bloques (refund/payout), fijar registros.
4. Comunicación → actualización interna (15/30/60 min), mensajes externos (estado/ETA/solución de problemas).
5. Recover → retroceso paso a paso/apertura, verifique SLO.
6. Reconcile → comparar ledger/PSP/banco, calcular el impacto financiero.
7. RCA (≤5 p. d.) → raíz, acciones, evitadores, tareas.

4) Scripts típicos y Runbook 'y

4. 1 Auto Drop/Latency Spike (tarjetas/A2A)

Síntomas: AR↓, soft declines↑, p95 auth> 1-2 s.

• Smart-routing: PSP_A→PSP_B, aumentar la 3DS-challenge en los BIN vulnerables.
• Restringir retraídas (backoff + jitter), proteger la idempotencia 'auth _ key'.
• Segmento-toggle: alto-riesgo en un escenario «estricto»; reducir los límites de alto ticket.
• Comunicaciones: «nota sobre la degradación», recomendar un método alternativo.
• Recuperación: retorno escalonado de la cuota de tráfico, control AR en el corte BIN × GEO.

4. 2 Webhooks Delay / Duplicate

Síntomas: p95> 3-5 c, omisiones capture/refund/payout, duplicados.

• Cambiar a polling; reforzar la idempotencia TTL.
• Congelar auto-refundiciones y pagos de automóviles arriesgados.
• Anti-toma: store-once por 'idempotency _ key/provider _ txid'.
• Realizar el procesamiento catch-up; conciliación con los registros PSP.
• Recuperación: habilitar webhooks, comparar consistencia con informes.

4. 3 Payout Fail / TtW Degradation

Síntomas: Success%↓, TtW p95↑, devoluciones/tiempos de espera.

• Feilover en el carril de respaldo (RTP/SEPA/otro PSP).
• Treasury: Prefund top-up payout-pool, StressRes activación.
• Payout-lock para alto riesgo, priorización VIP.
• Comunicaciones: ETA y alternativas, transparencia de los estados en la cuenta personal.

4. 4 Refund Errors / Double Refund Risk

Síntomas: Refund error rate↑, devoluciones controvertidas/duplicadas.

• Refund-freeze global en la ruta del coche, sólo manual con derechos.
• Idempotencia rígida 'payment _ id + amount + reason'; row-lock para el resto.
• Volver a conciliar el informe PSP; tomas en el guardabosques, casos en el DLQ.
• Kommunikatsii:模板 para tarjetas (T + 1-T + 5 bd.), instant - hasta 60 p.

4. 5 Settlement Delay / PSP Batch Mismatch

Síntomas: D + N no acreditado, diff en sumas/fee.

• Treasury: habilitar StressRes, limitar los pagos instantáneos.
• Recon: marcar batch «SUSPENSE», levantar ticket PSP, solicitar statement.
• FX/Fees: aceptar la «verdad» temporal (política) o esperar el ajuste.
• Comunicaciones: Q&A para sapport (seguridad de fondos, plazos de liquidación).

4. 6 Crypto On/Off-Ramp Degradation

Síntomas: TtH↑, slippage↑, escasez de liquidez del sitio.

• SOR→alternativnyy CEX/OTC, reducir el tamaño del lote (TWAP).
• Traducción de las entradas a stable/fiat, límite de exposición depeg.
• Kill-switch cuando hay una discrepancia oráculo> límite bps.

4. 7 Voucher/Wallet Anomalies

Síntomas: Invalid PIN spike, velocity, geo tazón.

• Límites/couldown, enlace redeem al dispositivo, payout-lock + turnover.
• Solicitud de cheques/SoF, recarga de hojas de flujo (email/device/ASN/retailer).

5) Chequeos de acciones

5. 1 Cinco primeros minutos (P0/P1)

• Asignar IC, abrir war-room.
• Fijar Sev, cobertura, inicio de la línea de tiempo (UTC).
• Incluir banderas de seguridad (idempotencia, freeze de los procesos automáticos deseados).
• Ejecute el Failover/Degradación de funciones.
• Primer apdate interno (contexto, medidas, sigue ETA).

5. 2 Antes de cerrar el incidente

• SLO restaurado (AR/latency/webhooks/TtW/TtR).
• Se realizó una conciliación (internal↔PSP↔bank), no hay «agujeros negros».
• Se evalúa el impacto financiero, se formalizan los registros.
• Apdate/post externo en el canal de estado.
• Se ha designado un propietario de RCA y tareas de prevención.

6) Monitoreo, alertas y dashboards

• 'AR_gross↓> 3 p.p. (a p7 mediana)' → P1/P0 de alcance.
• `Auth p95>1. 5 s / Webhook p95>5 s / Capture Success<98%` → P1.
• `Payout TtW p95> SLO` или `Success%<99%` → P1.
• `Refund Error>0. 3%` или `Double Refund>0` → P0.
• `Settlement on-time<99%` / `Report Delivery SLA breach` → P1.

1. Fanel Attempt→Auth→Capture (comparación a la línea de base).

2. Heatmap AR по BIN×GEO×PSP.

3. Webhook p50/p95, duplicados, drebezg.

4. Payout/Refund Health (Success%, TtW/TtR).

5. Treasury: balance L0, Prefund, StressRes.

6. Recon: Mismatch Rate, Aging DLQ.

7) Comunicaciones (plantillas)

8) Conciliación y dinero (después de la estabilización)

Ahuyentar la conciliación automática: provider_txid/idem_key/amount/time-bucket.
Resaltar DLQ: orphan/duplicate/amount mismatch/fee drift.
Formalizar storno/correcciones en el ledger, volver a calcular Costo/GGR y Fraud Loss.
Tesorería: cerrar medidas temporales (StressRes, payout-lock), rebalance de grupos.

9) Plantilla RCA (Root Cause Analysis)

Contexto: fecha/hora (UTC), Sev, cobertura, métricas.
Síntomas: lo que vio (gráficos/capturas de pantalla).
Causa: raíz (esos/procesos/contraparte).
Lo que funcionó/no funcionó: feilover, banderas de fin de semana, comunicaciones.
Efecto financiero: cargos/impagos/comisiones/préstamos de SLA.

• Los siguientes: límites, idempotencia, retraídas, pruebas.
• Procesos: actualización de playbook, QBR con PSP, cambios SLA.
• Dedlines y propietarios de tareas.

10) Automatización e integración

Plataforma Feature-flag: routing instantáneo/degradación por país/BIN/método.
Runbook-bot: comandos '/failover PSP_A→B', '/freeze refunds', '/enable polling '.
Anomaly-detector: desviación estadística de AR/latencia con conocimiento de estacionalidad.
Macros posteriores: apertura automática de la plantilla RCA, recopilación de registros/gráficos, comprobación de lista de verificación.

11) Calendario Drill y UAT

Mensual: «Auth drop» drill (15 min desde el bebé hasta el fake-over).
Trimestralmente: «Webhook outage» + «Refund double-strike» (idempotencia).
Cada seis meses: "Settlement delay + Treasury stress' (StressRes).
Paquete UAT: casos de prueba de idempotencia, feilover, conciliación, comunicaciones.

12) Métricas de éxito de playbook (KPI operativos)

MTTA/MTTR: mediana/p95 por P0/P1.
Percent auto-failover within 10 min.
Incidents preventing double charge/refund (=100%).
Post-incident recon complete ≤ D+1.
Service credits recovered / month (по SLA).
User impact minutes (suma por incidente).

13) Errores frecuentes y cómo evitarlos

Activación de failover tardía (no hay umbrales automáticos).
No hay «freeze» en el auto-refando cuando se rebusca webhooks.
No hay row-lock/versioning → refund parcial> residuo.
Comunicaciones sin hechos/AETA → escalada en el sapport.
No hay ligamento con el Tesoro → TtP/TtW sale de SLO.
Omitir la conciliación → «agujeros negros» en los ingresos.

14) Aplicaciones (bloques de referencia dentro de su wiki)

SLA con proveedores de pago - umbrales de alertas y préstamos.
Conciliación de pagos e informes PSP: procedimientos recon/DLQ.
Tesorería: liquidez y reservas - StressRes/Prefunding.
KPI del circuito de pago: fórmulas AR/TtW/TtR/Refund Health.
Refandos parciales y completos - idempotencia y política.

Resumen

Un playbook de trabajo es un script runbook 'y + automatización + disciplina post-mortem. Reduce el MTTR, protege el dinero (idempotencia/conciliación/tesorería), minimiza el daño al usuario y mejora sistémicamente las relaciones con PSP por SLA. El resultado es AR arriba, TtW/TtR en los pasillos, cero tomas, previsible flow de dinero.