SLA con provider di pagamento

TL; DR

Forte SLA = misurabili KPI collegati a effetti aziendali (AR, TtW, TtR, latency, webhook SLA, settlement timelover), più obblighi processuali (escalation, RFO/RCA, cambiamenti) e incentivi finanziari (service credits). Monitor con le proprie metriche e i dati del provider, incrociando il ciclo giornaliero e mantenendo le playbook del feelover finite.

1) Termini e portata

SLA (Service Level Agreement) - obblighi contrattuali per la qualità del servizio.
SLO (Service Level Objective) - target specifici per metriche (ore/giorno/mese).
PSP/Aquirer/APM/Bank/RTP - tipi di provider; SLA può variare per binari.
Metodi/azioni: «deposit/ach/capture», «refund», «payout/withdrawal», «webhooks», «settlement».

Volume SLA: API/dashboard, elaborazione dei pagamenti, notifica, rapporti/registri, supporto, modifiche, sicurezza e compilazione.

2) Dizionario di metriche SLA

2. 1 Disponibilità e prestazioni

API Uptime% (granolarità minuti/minuti)

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

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

Numero di battaglie iscritte al T + N dichiarato (≥99%)

2. 2 Conversione e qualità

Approval Rate (AR) per segmenti: 'country x BIN x method x device' (variabile comè corridoio di riferimento "con eccezioni)

Soft Decline Recovery Support (supporto per il retro, il routing)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Affidabilità dei dati e dei report

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

Schema Stability/Change Notice: notifica di ≥30 giorni

Webhooks vs Reports Consistency: . 05%

2. 4 Incidenti e supporto

MTTA/MTTR (tempo di risposta/ripristino) per livello di priorità

RFO/RCA (Reason For Outage/Root Cause Analysis) 5 giorni lavorativi

Planned Manentenance Notice 7 giorni (critico - )

3) Target consigliati (punti di riferimento)

(Personalizzare il metodo/mercato; le carte/instant/APM variano.)

Uptime API (mensile): ≥ 99. 95% (tracciato critico)

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

AR Corridor: non inferiore alla mediana di mercato/BIN nella vostra matrice - 2-3 pp (fissa il metodo di calcolo)

Rifund p95 mappe T + 1 b.d., instant rails 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100% nel giorno dichiarato

Settlement Timelava: ≥ 99% in T + N dichiarato

Report Delivery: ≥ 99. 5% fino a tempo determinato

4) Misurazione e base di prova

Il lato del merchant è la telemetria API (app-level timers), la logica «richiest _ id», i loghi di webhoop, gli iventi interni «auth/capture/refund/payout», il proprio Uptime/Latency dashboard.
Il lato provider è la pagina di stato, i calcoli degli incidenti, i report SLA, i download per AR/latency, settlement-statement.
Scorciatoia i tuoi eventi giornalieri con report PSP (vedere «Crocifissione»...), controllo statistico AR/latency (corridoi).
Unica zona temporale UTC, sincronizzazione ntp.

5) Incentivi finanziari e prestiti

• Il degrado Uptime/Latency/Webhook è fisso% crediti fee.
• Il ritardo di Settlement corrisponde a un prestito del% della somma/commissione trattenuta.
• Violazioni croniche del corridoio AR, revisione del routing/commissione/piano congiunto.
• Cap/Collar: limite massimo di crediti/mes, eccezioni (forza maggiore, regolatori).
• No-performance Exit - Diritto di annullare in N violazioni consecutive.

6) Processo di incidenti e escalation

Classi P0-P3 (P0 - Totale indisponibilità/guasti di massa).
Target MTTA/MTTR: ad esempio P0 MTTA da 15 min, MTTR da 2 h.
I canali sono chat/telefono, sistema ticket, stato-pagina.
RCA (≤5 PD) con piano di prevenzione: misure tecniche, processuali, di routing.
Comunicazione per lo zapport: modelli di messaggio per i giocatori (ritardi/alternative).

7) Gestione delle modifiche

Notice ≥ 30 giorni per: schema API/registro, parametri 3DS, percorsi, calendario settlement, modelli di commissione.
Test congiunti in Sandbox + pilota 5-10% traffico.
Rollback piano e «feature-flag» dalla tua parte.

8) Sicurezza e compilazione in SLA

Crittografia in transito/a, certificazione (PCI DSS/SOCC), vulnerabilità e tempi di risoluzione.
Screening sanzionatorio/AML, PEP, SoF/SoW: funzioni supportate dal provider e dalla loro SLA.
Data Processing Addendum (DPA), retention и DSAR.
Breach Notifica: 24 ore in caso di incidente di sicurezza.

9) Monitoraggio e dashboard

1. Uptime/Latency (p50/p95/p99) per metodi e regioni.

2. Tempo di consegna, percentuale di successo, dribosaggio/duplicati.

3. AR/Soft Declins nel tagliò BIN x country x provider ".

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

5. Settlement Timelovere Aging battelli non superati.

6. Insert Panel: MTTA/MTTR, RCA aperto, credito-memo.

10) Modello di dati per gli analisti SLA (minimo)

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) Tagli SQL (esempio)

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) Modello di SLA (modello)

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) Playbook del feelover

Degrado Auth/Latency

Azioni includere smart-routing su PSP alternativo, aumentare 3DS-challenge su BIN vulnerabili, retrai soft-decline con bacoff.

Webhook ritardi/duplicati

Azioni: passare al polling, attivare l'idampotenza sui processori, congelare temporaneamente i rifandi automatici.

Settlement trattenuto

Azioni: attivare il Tesoro, ridurre temporaneamente i limiti dei pagamenti immediati, l'escalation in PSP, il credito memo.

Problemi payouts

Azioni: passare al binario di riserva (SEPA/RTP/altro PSP), attivare «payout-lock» per l'high-risk, priorità VIP.

14) Gestione dei provider e QBR

QBR (quarterly business review): AR/Latency/Webhook/Settlement/KPI-prestiti, piano di miglioramento, road map.
Benchmarking: tabella comparativa dei provider per SLO, incidenti, costi (Cost/GGR), qualità dei report.
Scorecard: 0-5 per ogni sezione SLA.

15) Assegno foglio di implementazione SLA

• Definite metriche, formule e segmentazioni (UTC, p95/p99, base di calcolo).
• I report PSP sono stati compilati per la raccolta e la riconciliazione giornaliera.
• MTTA/MTTR, escalation, contatti 24/7, stato-pagina.
• Garantito servizio credits e diritto di disdire per violazioni croniche.
• Cambio-notice di 30 giorni, test sandbox e piano rollback.
• Protezione/compilazione: PCI/SOCC, breach ≤ 24h, DPA/retention.
• Playbook di feelover e integrazione con l'orchestratore di instradamento.
• QBR/scorecard, calibrazione regolare dei corridoi AR.

16) Errori frequenti

Le definizioni sfocate (come «successo», dove conta p95) sono controverse e «cartacee» SLA.
La mancanza di metriche dipende dai rapporti del provider.
Non ci sono incentivi finanziari per la SLA.
Miscelare AR con effetto antifrode → fissa ciò che compare nella base di calcolo.
Ignorare il calendario settlement e il timesone → i firmware e le interruzioni di cassa.

Riepilogo

La SLA di lavoro non è un insieme di frasi condivise, ma un contratto con numeri e processi: SLO chiaro per disponibilità/velocità/conversione/output/report, confermato dalla tua telemetria, con credito-memo per violazioni e playbook finiti. Questa SLA riequilibra le aspettative, riduce i tempi di reazione e supporta esplicitamente gli obiettivi di monetizzazione: AR più alto, più basso, ritardi di cassa rari e incidenti gestibili.