SLA con proveedores de pago

TL; DR

SLA fuerte = KPI mensurables vinculados al efecto de negocio (AR, TtW, TtR, latency, webhook SLA, settlement timeliness), además de compromisos de proceso (escaladas, RFO/RCA, cambios) y los incentivos financieros (créditos de servicio). Monitorim con sus propias métricas y datos del proveedor, verificamos en el ciclo diario y mantenemos listas de reproducción de Feilover.

1) Términos y alcance

SLA (Service Level Agreement) es un compromiso contractual para la calidad del servicio.
SLO (Service Level Objective): niveles específicos de objetivo por métricas (hora/día/mes).
PSP/Acquirer/APM/Bank/RTP - tipos de proveedor; El SLA puede variar en los rieles.
Métodos/acciones: 'deposition/auth/capture', 'refund', 'payout/withdrawal', 'webhooks',' settlement '.

Volumen de SLA: API/panel, procesamiento de pagos, notificaciones, informes/registros, soporte, cambios (gestión de cambios), seguridad y cumplimiento.

2) Diccionario de métricas SLA

2. 1 Disponibilidad y rendimiento

API Uptime% (granularidad de minutos/cinco minutos)

Auth/Capture Latency p95/p99 (сек)

Webhook Delivery p95 (сек) и Success % (≥99. 9%)

Timeliness de Settlement: proporción de batches inscritos en el T + N declarado (≥99%)

2. 2 Conversión y calidad

Approval Rate (AR) por segmentos: 'country × BIN × method × device' (variativamente, como un «corredor de referencia» con excepciones)

Soft Decline Recovery Support (soporte para retraídas, enrutamiento)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Fiabilidad de los datos e informes

Report Delivery SLA: реестры `transactions/settlements/fees` до `HH:MM UTC` (≥99. 5%)

Schema Stability/Change Notice: notificación con ≥30 días de antelación

Webhooks vs Reports Consistency: discrepancias ≤0. 05%

2. 4 Incidentes y soporte

MTTA/MTTR (tiempo de respuesta/recuperación) por nivel de prioridad

RFO/RCA (Reason For Outage/Root Cause Analysis) ≤ 5 días hábiles

Nota de mantenimiento planificado ≥ 7 días (crítica - ≥14)

3) Valores objetivo recomendados (puntos de referencia)

(Personalizable para el método/mercado; las tarjetas/instant/APM varían.)

API de uptime (mensual): ≥ 99. 95% (contorno crítico)

Latency p95: Auth ≤ 1. 0 s, Capture ≤ 1. 5 s, Webhooks ≤ 3 s

Corredor AR (referencia): no por debajo de la mediana por mercado/BIN en su matriz - 2-3 p.p. (fijar el método de cálculo)

Refund TtR p95: mapas ≤ T + 1 bd., instant rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% en el día declarado

Settlement Timeliness: ≥ 99% en T + N declarado

Report Delivery: ≥ 99. 5% antes del tiempo acordado

4) Medición y base de pruebas

Lado del merchant (usted): API telemetría (app-level timers), lógica 'request _ id', logs webhooks, eventos internos 'auth/capture/refund/payout', su propio Uptime/Latency dashboard.
Lado del proveedor: página de estado, informes técnicos sobre incidentes, informes de SLA, descargas por AR/latencia, estado de configuración.
Conciliación: reconcile diariamente sus eventos con los informes PSP (ver «Conciliación»...), control estadístico AR/latencia (corredores).
Zona horaria única: UTC, sincronización ntp.

5) Incentivos financieros y préstamos

• La degradación de Uptime/Latency/Webhook → un porcentaje fijo de créditos fee.
• La morosidad de Settlement → un crédito del% de la cantidad/comisión retrasada.
• Trastornos crónicos del corredor AR → revisión de routing/comisión/plan conjunto.
• Cap/Collar: límite superior de créditos/mes, excepciones (fuerza mayor, acciones regulatorias).
• Non-performance Exit: derecho a rescindir en N infracciones consecutivas.

6) Proceso de incidentes y escaladas

Clases de P0-P3 (P0 - inaccesibilidad total/fallos masivos).
Objetivos MTTA/MTTR: por ejemplo, P0 MTTA ≤ 15 min, MTTR ≤ 2 h.
Canales: chat/teléfono de guardia, sistema de tickets, página de estado.
RCA (≤5 p. d.) con un plan de prevención: medidas técnicas, de proceso, de enrutamiento.
Comunicación para sapport: plantillas de mensajes para jugadores (retrasos/alternativas).

7) Gestión de cambios (Change Management)

Notice ≥ 30 días para: esquema API/registros, parámetros 3DS, rutas, calendario settlement, modelos de comisiones.
Pruebas conjuntas en Sandbox + piloto 5-10% de tráfico.
Plan Rollback y «feature-flag» a tu lado.

8) Seguridad y cumplimiento en SLA

Encriptación en tránsito/descanso, certificación (PCI DSS/SOC), vulnerabilidades y plazos para resolverlas.
Cribado sancionador/AML, PEP, SoF/SoW - características respaldadas por el proveedor y sus SLA.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notification: ≤ 24 horas en un incidente de seguridad.

9) Monitoreo y dashboards

1. Uptime/Latency (p50/p95/p99) por método y región.

2. Webhook SLA: tiempo de entrega, fracción de éxito, drebezg/duplicados.

3. AR/Soft Declines en el corte 'BIN × country × provider'.

4. Refund/Payout Health: Success %, TtR/TtW p95.

5. Settlement Timeliness y Aging de batches desconocidos.

6. Panel de Incident: MTTA/MTTR, RCA abierto, memo de crédito.

10) Modelo de datos para análisis SLA (mínimo)

ts_utc, provider, method_code, action(auth/capture/refund/payout/webhook/settlement),
latency_ms, status, is_success,
bin, country, device_os,
webhook_delivery_sec, webhook_retry_count,
settlement_date, settlement_status,
incident_id, severity, mtta_sec, mttr_sec

11) Cortes SQL (ejemplo)

11. 1 Uptime/Latency

sql
SELECT
DATE_TRUNC('hour', ts_utc) AS h,
provider, method_code, action,
COUNT() FILTER (WHERE is_success)=1. 0 / COUNT() AS success_rate,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY latency_ms) AS p95_ms
FROM sla_events
WHERE action IN ('auth','capture')
GROUP BY 1,2,3,4;

11. 2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', ts_utc) h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY webhook_delivery_sec) AS wb_p95,
AVG(CASE WHEN webhook_retry_count=0 THEN 1 ELSE 0 END) AS wb_success
FROM sla_events
WHERE action='webhook'
GROUP BY 1,2;

11. 3 Settlement Timeliness

sql
SELECT settlement_date, provider,
AVG(CASE WHEN settlement_status='ON_TIME' THEN 1 ELSE 0 END) AS on_time_share
FROM sla_events
WHERE action='settlement'
GROUP BY 1,2;

12) Plantilla de elementos SLA (muestra)

text
1. Availability
- Monthly API Uptime ≥ 99. 95% (5-min granularity).
- Exclusions: Planned Maintenance (≤ 2h/month, 00:00–06:00 UTC, 7d notice).

2. Performance
- Auth p95 latency ≤ 1. 0 s; Capture p95 ≤ 1. 5 s.
- Webhook delivery p95 ≤ 3 s, success ≥ 99. 9%, no duplicates.

3. Financial Operations
- Settlement T+N on-time ≥ 99%; reports delivered by 07:00 UTC D+1 (≥ 99. 5%).

4. Incident Management
- P0: MTTA ≤ 15 min, MTTR ≤ 2 h; P1: 30 min / 4 h.
- RCA within 5 business days with preventive actions.

5. Data & Changes
- 30-day advance notice for API/report schema changes.
- Backward compatibility window ≥ 60 days.

6. Remedies
- Service credits per breach (tiered), cap 25% monthly fees.
- Termination right upon 3 consecutive P0 breaches.

13) Playbucks Feolover

Degradación de Auth/Latency

Acciones: habilite el enrutamiento inteligente en PSP alternativo, aumente la 3DS-challenge en BIN vulnerables, retrés soft-decline con backoff.

Webhook retrasos/duplicados

Acciones: cambiar a polling, activar la idempotencia en los manejadores, congelar temporalmente los refandos automáticos.

Settlement ha sido detenido

Acciones: activar StressRes del Tesoro, reducir temporalmente los límites de pago instantáneo, escalar en PSP, crédito-memo.

Problemas de payouts

Acciones: cambiar al carril de respaldo (SEPA/RTP/otro PSP), habilitar 'payout-lock' para alto riesgo, priorización VIP.

14) Gestión de proveedores y QBR

QBR (revisión quarterly business): AR/Latency/Webhook/Settlement/KPI-créditos, plan de mejoras, hoja de ruta fich.
Benchmarking: tabla comparativa de proveedores por SLO, incidentes, costo (Costo/GGR), calidad de la información.
Scorecard: 0-5 para cada sección del SLA.

15) Lista de comprobación de implementación de SLA

• Se han definido métricas, fórmulas y segmentación (UTC, p95/p99, bases de cálculo).
• Se han personalizado la recolección/dashboards y la conciliación diaria con los informes PSP.
• MTTA/MTTR, escaladas, contactos 24/7, página de estado.
• Se fijan los créditos de servicio y el derecho de rescisión en caso de discapacidad crónica.
• Change-notice ≥ 30 días, pruebas de sandbox y un plan de rollback.
• Seguridad/cumplimiento: PCI/SOC, breach ≤ 24h, DPA/retention.
• Failover playbucks e integración con el orquestador de enrutamiento.
• QBR/scorecard, calibración regular de corredores AR.

16) Errores frecuentes

Definiciones borrosas (qué considerar «éxito», dónde contar p95) → disputas y SLA «de papel».
La ausencia de sus métricas → la dependencia de los informes del proveedor.
No hay incentivos financieros → SLA no funciona.
Mezclar AR con efecto antifraude → fijar lo que se incluye en la base de cálculo.
Ignore el calendario settlement y el tiempo de espera → los saltos de caja y los saltos de caja.

Resumen

Un SLA de trabajo no es un conjunto de frases genéricas, sino un contrato que se cosecha con números y procesos: SLO claros en disponibilidad/velocidad/conversiones/conclusiones/informes, validados por su telemetría, con memo de crédito por infracciones y listas de reproducción de Feilover. Este SLA alinea las expectativas, reduce el tiempo de reacción y apoya explícitamente los objetivos de monetización: AR arriba, TtW/TtR abajo, los retrasos de caja son raros y los incidentes son manejables.