SLA com provedores de pagamentos

TL; DR

Forte SLA = KPI medível atrelado a efeitos empresariais (AR, TtW, TtR, latency, webhook SLA, senslement timeless), além de compromissos processuais (escalações, RFO/RCA, mudanças) e estímulos financeiros (service credits). Monitorizando com suas próprias métricas e dados do provedor, verificando no ciclo diário e mantendo os playbooks do feelover prontos.

1) Termos e alcance

SLA - obrigações contratuais de qualidade do serviço.
SLO (Service Level Objectiva) - Níveis de destino específicos por métrica (hora/dia/mês).
PSP/Aquirer/APM/Bank/RTP - tipos de provedor; O SLA pode variar de caminho.
Métodos/ações: 'deposit/h./capture', 'refund', 'payout/withdrawal', 'webhooks', 'masslement'.

Volume de SLA: API/painel, processamento de pagamentos, notificação, relatórios/registros, suporte, alterações (mudança de gestão), segurança e complacência.

2) Dicionário de métricas SLA

2. 1 Disponibilidade e desempenho

API Uptime% (granularidade de cinco minutos/minutos)

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

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

Senslement Timeliness: proporção de batches inscritos no T + N declarado (≥99%)

2. 2 Conversão e qualidade

Approval Rate (AR) por segmento: 'country x BIN x method x device' (variável como 'corredor de arbitragem' com exceções)

Soft Decline Recovery Apoio (suporte a retais, rotação)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Confiabilidade de dados e relatórios

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

Schema Statity/Mudança Notice: notificação de ≥30 dias

Webhooks vs Reports Consistency: divergências de ≤0. 05%

2. 4 Incidentes e apoio

MTTA/MTTR (tempo de resposta/recuperação) por nível de prioridade

RFO/RCA ≤ 5 dias úteis

Planned Maintenance Notice ≥ 7 dias (crítico - ≥14)

3) Metas recomendadas (indicações)

(Ajustáveis ao método/mercado; mapas/instantâneo/APM variam.)

Uptime API (mensal): ≥ 99. 95% (caminho crítico)

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

AR Corredor (árbitro): No máximo, a mediana de mercado/BIN na sua matriz é 2-3 p.p (fixar o método de cálculo)

Refund TtR p95: cartões ≤ T + 1 b.d., momento rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% no dia declarado

Senslement Timeliness: ≥ 99% no T + N declarado

Report Delivery: ≥ 99. 5% até o tempo estipulado

4) Medição e base de provas

Lado merchant (você): telemetria API (app-level timers), loging 'request _ id', logs de webhooks, ivents internos 'auth/capture/refund/payout', seu próprio Uptime/Latency dashboard.
O lado do provedor é o status da página, contagem de ocorrência, relatórios de SLA, descarga por AR/latency, masslement-statement.
Confecção: recepcilho diário de seus eventos com relatórios PSP (consulte «Confecção»...), controle estatístico AR/latency (corredores).
Uma única zona temporal: UTC, sincronização ntp.

5) Incentivos financeiros e crédito

• A degradação do Uptime/Latency/Webhook → um% de crédito fee fixo.
• O atraso do Masslement → um empréstimo de% do valor/comissão atrasado.
• Violações crônicas do corredor AR → revisão do roteiro/comissão/plano conjunto.
• Cap/Collar: limite superior de crédito/mes, exceções (força maior, regulação).
• Exit Não-Performance: Direito de cancelar violações consecutivas em N.

6) Processo de incidentes e escalações

Classes P0-P3 (P0 - total indisponibilidade/falha em massa).
Alvo MTTA/MTTR: por exemplo, P0 MTTA ≤ 15 min, MTTR ≤ 2 h.
Canais: bate-papo/telefone, sistema tíquete, página de status.
RCA («≤5») com um plano de prevenção com medidas técnicas, processuais, rotativas.
Comunicação para safort: modelos de mensagens para jogadores (atrasos/alternativas).

7) Gerenciamento de alterações

Notice ≥ 30 dias para: esquema de API/registros, parâmetros 3DS, rotas, calendário de senslement, modelos de comissão.
Testes conjuntos em Sandbox + piloto 5-10% tráfego.
O plano Rollback e a «função-flag» estão do seu lado.

8) Segurança e Complacência em SLA

Criptografia em trânsito/paz, certificação (PCI DSS/SOC), vulnerabilidades e prazos de resolução.
Screening sancionado/AML, PEP, SoF/SoW - funções suportadas pelo provedor e seu SLA.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notificação: ≤ 24 horas em um incidente de segurança.

9) Monitoramento e dashboards

1. Uptime/Latency (p50/p95/p99) por métodos e regiões.

2. Webhook SLA: tempo de entrega, proporção de sucesso, drible/duplicação.

3. AR/Soft Declins em 'BIN x country x provider'.

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

5. O Senslement Timeliness e o Aging Batches.

6. Invident Painel: MTTA/MTTR, RCA aberto, mmo de crédito.

10) Modelo de dados para SLA-analistas (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 (exemplo)

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) Modelo de itens SLA (amostra)

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) Playbooks do feelover

Degradação Auth/Latency

Ações: incluir smart-roting em PSP alternativo, aumentar 3DS-challenge em BIN vulneráveis, retrai soft-decline com bacoff.

Webhook atrasos/duplicados

Ações: ir para o meio-campo, ativar a idempotidade nos processadores, congelar temporariamente os refandos automáticos.

Senslement detido

Acção do StressRes do Tesouro, redução temporária dos limites de pagamento instantâneo, escalação em PSP, crédito mmo.

Problemas de payouts

Ações: mudar para o caminho de reserva (SEPA/RTP/outro PSP), ativar 'payout-lock' para high-risk, priorizar VIP.

14) Gerenciamento de provedores e QBR

QBR (quarterly business review): AR/Latency/Webhook/Senslement/KPI-empréstimos, plano de melhorias, cartão de viagem Fiech.
Benchmarking: tabela de comparação de provedores de SLO, Incidentes, Custo/GGR, Qualidade de Relatórios.
Scorecard: 0-5 para cada seção da SLA.

15) Folha de cheque de implementação do SLA

• São definidas métricas, fórmulas e segmentação (UTC, p95/p99, base de cálculo).
• Os relatórios PSP estão configurados para coletar/se e fazer um relatório diário.
• MTTA/MTTR, escalações, contatos 24/7, status-página.
• Estão consagrados o serviço credits e o direito de rescisão em violações crônicas.
• Mudança-notice ≥ 30 dias, testes sandbox e plano rollback.
• Segurança/complicação: PCI/SOC, breach ≤ 24h, DPA/retenção.
• Playbooks de feelover e integração com o orquestrador de roteiro.
• QBR/scorecard, calibragem regular dos corredores AR.

16) Erros frequentes

Definições desfocadas (o que considerar um «sucesso», como p95) → disputas e «papel» SLA.
A ausência de suas métricas → dependente dos relatórios do provedor.
Sem incentivos financeiros, o SLA não funciona.
Misture AR com efeito antifrode → construa o que está na base de cálculo.
Ignorar o calendário de senslement e o timeson → quebra-quebra e quebra de caixa.

Currículo

O SLA de trabalho não é um conjunto de frases gerais, mas um contrato com números e processos: nítidos SLO de disponibilidade/velocidade/conversão/conclusões/relatórios, comprovado pela sua telemetria, com crédito-mmo por violações e playbooks de feelback prontos. Tal SLA alinha as expectativas, reduz o tempo de reação e apoia diretamente os objetivos de monetização: AR mais alto, TtW/TtR mais baixo, atrasos de caixa raros e incidentes controláveis.