SLA avec les fournisseurs de paiement

TL; DR

Un SLA fort = des KPI mesurables liés à l'effet d'entreprise (AR, TtW, TtR, latency, webhook SLA, settlement timing), plus des engagements de processus (escalade, RFO/RCA, changements) et des incitations financières (crédits de service). Nous surveillons nos propres métriques et données de fournisseur, vérifions dans un cycle quotidien et gardons les playbacks de faussaire prêts.

1) Termes et champ d'action

SLA (Service Level Agreement) - obligations contractuelles pour la qualité du service.
SLO (Service Level Objective) - niveaux cibles spécifiques par métrique (heure/jour/mois).
PSP/Acquirer/APM/Bank/RTP - types de fournisseurs ; Les SLA peuvent varier selon les rails.
Méthodes/actions : 'deposit/auth/capture', 'refund', 'payout/withdrawal', 'webhooks', 'settlement'.

Volume SLA : API/panel, traitement des paiements, notifications, rapports/registres, support, modifications (changement de gestion), sécurité et conformité.

2) Dictionnaire de métriques SLA

2. 1 Disponibilité et performances

API Uptime % (granularité minute/cinq minutes)

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

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

Temps d'attente : proportion de trampolines créditées dans le T + N déclaré (≥99 %)

2. 2 Conversion et qualité

Taux approval (AR) par segment : 'country × BIN × method × device' (variatif comme « corridor de référence » avec exceptions)

Soft Decline Recovery Support (support des retraits, routage)

Refund Success % и TtR p95

Payout Success % и TtW p95

Duplicate/Idempotency Incidents = 0

2. 3 Fiabilité des données et des rapports

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

Schema Stabilité/Changement Avis : préavis de ≥30 jours

Webhooks vs Reports Consistency : différences de ≤0. 05%

2. 4 Incidents et soutien

MTTA/MTR (délai de réponse/récupération) par niveau de priorité

RFO/RCA (Reason For Outage/Root Cause Analysis) ≤ 5 jours ouvrables

Avis de maintenance planifiée ≥ 7 jours (critique - ≥14)

3) Valeurs cibles recommandées (repères)

(Personnalisable pour la méthode/le marché ; cartes/instant/APM diffèrent.)

API uptime (mensuelle) : ≥ 99. 95 % (contour critique)

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

AR Corridor (référence) : Pas plus bas que la médiane du marché/BIN dans votre matrice - 2-3 pp (fixer la méthode de calcul)

Refund TtR p95 : cartes ≤ T + 1 b.d., instant rails ≤ 60 s

Payout TtW p95 (instant): ≤ 120 s; (T + 1) - 100 % le jour déclaré

Temps d'attente : ≥ 99 % dans le T + N déclaré

Report Delivery: ≥ 99. 5 % jusqu'à l'heure prévue

4) Mesure et base de données probantes

Côté merchant (vous) : API de télémétrie (app-level timers), loging "request _ id', logs de webhooks, ivents internes" auth/capture/refund/payout ", dashboard propre Uptime/Latency.
Côté fournisseur : page de statut, rapports d'incident, rapports SLA, déchargement AR/latency, settlement-statement.
Rapprochement : reconcile quotidien de vos événements avec les rapports PSP (voir « Rapprochement »...), contrôle statistique AR/latitude (couloirs).
Zone temporelle unique : UTC, synchronisation ntp.

5) Incitations financières et prêts

• Dégradation Uptime/Latency/Webhook → % fixe de crédits fee.
• Le retard de Settlement → un prêt en % du montant/des frais retardés.
• Perturbation chronique du corridor AR → révision de l'itinéraire/commission/plan conjoint.
• Cap/Collar : plafond des crédits/mois, exceptions (force majeure, mesures réglementaires).
• Non-performance Exit : droit de résilier avec N violations consécutives.

6) Processus d'incidents et d'escalade

Classes de P0-P3 (P0 - indisponibilité totale/pannes massives).
Objectifs MTTA/MTR : par exemple, P0 MTTA ≤ 15 min, MTR ≤ 2 h.
Chaînes : chat de garde/téléphone, système de tiquet, page de statut.
RCA (≤5 p. d.) avec plan de prévention : mesures techniques, de traitement, de routage.
Communication pour le Sapport : modèles de messages pour les joueurs (retards/alternatives).

7) Gestion des changements

Notice ≥ 30 jours sur : schéma API/registres, paramètres 3DS, itinéraires, calendrier de settlement, modèles de commissions.
Tests conjoints dans Sandbox + pilote 5-10 % du trafic.
Plan Rollback et « feature-flag » de votre côté.

8) Sécurité et conformité en SLA

Cryptage en transit/repos, certification (PCI DSS/SOC), vulnérabilités et délais pour y remédier.
Sanction/AML, PEP, SoF/SoW - les fonctions soutenues par le fournisseur et leur SLA.
Data Processing Addendum (DPA), retention и DSAR.
Notification de rupture : ≤ 24 heures en cas d'incident de sécurité.

9) Monitoring et dashboards

1. Uptime/Latitude (p50/p95/p99) par méthode et par région.

2. Webhook SLA : délai de livraison, proportion de succès, drebezg/doublons.

3. AR/Soft Declines dans la coupe 'BIN × country × provider'.

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

5. Settlement Time and Aging des trampolines sans chant.

6. Incident Panel : MTTA/MTR, ouvert par RCA, prêt-mémoire.

10) Modèle de données pour l'analyse SLA (minimum)

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) tranches SQL (exemple)

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) Modèle d'article SLA (échantillon)

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) Pleybooks de feilover

Dégradation Auth/Latitude

Actions : inclure le routage intelligent sur le PSP alternatif, augmenter les 3DS-challenge sur les BIN vulnérables, les retraits soft-decline avec bacoffe.

Webhook retards/doublons

Actions : passer à la polling, activer l'idempotence sur les manipulateurs, geler temporairement les auto-refands.

Settlement arrêté

Actions : activer les StressRes du Trésor, réduire temporairement les limites de paiement instantané, l'escalade dans le PSP, le crédit-mémoire.

Problèmes payants

Actions : commuter sur le rail de secours (SEPA/RTP/autre PSP), activer 'payout-lock'pour le haut risque, priorité VIP.

14) Gestion des fournisseurs et QBR

QBR (quarterly business review) : AR/Latency/Webhook/Settlement/KPI, plan d'amélioration, feuille de route fich.
Benchmarking : tableau comparatif des fournisseurs par SLO, incidents, coût (Cost/GGR), qualité des rapports.
Scorecard : 0-5 pour chaque section de l'ALS.

15) Chèque de mise en œuvre SLA

• Les métriques, les formules et la segmentation sont définies (UTC, p95/p99, bases de calcul).
• La collecte/dashboard et le rapprochement quotidien avec les rapports PSP sont personnalisés.
• Prescrit par MTTA/MTR, escalade, contacts 24/7, page de statut.
• Les crédits de service et le droit de résiliation pour les infractions chroniques sont consacrés.
• Avis de changement ≥ 30 jours, tests de sandbox et plan de rollback.
• Sécurité/conformité : PCI/SOC, breach ≤ 24h, DPA/retraite.
• Pleybooks feilover et intégration avec l'orchestrateur de routage.
• QBR/scorecard, étalonnage régulier des corridors AR.

16) Erreurs fréquentes

Définitions floues (que considérer comme « succès », où compter p95) → controverses et SLA « papier ».
L'absence de vos métriques → la dépendance aux rapports du fournisseur.
Pas d'incitations financières → SLA ne fonctionne pas.
Mélanger l'AR avec l'effet antifrod → fixer ce qui est inclus dans la base de calcul.
Ignorer le calendrier de settlement et la temporisation → les sauts de caisse et les sauts de caisse.

Résumé

Un SLA de travail n'est pas un ensemble de phrases communes, mais un contrat basé sur des chiffres et des processus : un SLO clair sur la disponibilité/vitesse/conversion/conclusions/reporting, confirmé par votre télémétrie, avec un memo de crédit pour les violations et des plaquettes de faussaire prêtes à l'emploi. Un tel SLA aligne les attentes, réduit le temps de réaction et soutient directement les objectifs de monétisation : AR plus haut, TtW/TtR plus bas, les retards de caisse sont rares et les incidents sont gérables.