KPI du circuit de paiement : auth, capture, refund

TL; DR

Le circuit de paiement est mesuré comme un entonnoir : 'Attempt → Auth → Capture → Settle/Refund'. Les mesures clés ne sont pas seulement le taux Approval, mais aussi le taux AR net (après l'antifrod et 3DS), le succès de capture, le temps avant le prélèvement/crédit, le coût/FX, les erreurs d'idempotence et la qualité des retours (TtR et rate). C'est celui qui gagne qui garde le AR↑, le TtW↓, le Cost/GGR↓, le Disputes↓, sans briser le profil de risque.

1) Dictionnaire des étapes et des événements

Attempt est une tentative de paiement (initiation).
Auth - autorisation (banque/portefeuille/rails ont confirmé la possibilité de radiation).
Capture - prélèvement réel (total/partiel).
Settle - compensation et calculs.
Refund est un retour (complet/partiel), 'TtR = time to refund credit'.
Void - Annuler avant capture (si pris en charge).
3DS/Step-up est une friction d'autorisation.
Soft Decline/Hard Decline - pannes récupérables/non récupérables.

💡 База измерений: `country, provider, method, action(deposit/payout/refund), device/os, ticket_size, risk_segment, kyc_tier, bin/asn`.

2) Hiérarchie KPI (arbre des objectifs)

Niveau supérieur

Gross Approval Rate (AR_gross) = Auth/Attempt

Net Approval Rate (AR_net) = Captured/Attempt

Cost/GGR = (Fees + FX + Ops)/GGR

TTW/TtC : Time-to-Wallet (conclusions), TtC (capture) p95

Refund Health: Refund Rate, TtR p95, Refund Error Rate

Niveau moyen

3DS Challenge Share, Frictionless Share, Abandon on 3DS

Taux de récupération de Decline Soft (retrai/itinéraire intelligent)

Partial Capture Share, Capture Latency

Refund to Source %, Duplicate/Idempotency Incidents

Niveau inférieur (diagnostic)

Erreurs de code (ISO/rail), p95 latence API, SLA webhooks, proportion de 'Do Not Honor', 'Insufficient Funds', 'Suspected Fraud', 'System Error'.

3) Formules (définitions précises)

3. 1 Autorisation

`AR_gross = Auth_Approved / Auth_Attempted`

`AR_clean = Auth_Approved / (Auth_Attempted - Fraud_Preblocked - User_Abandon_3DS)`

`3DS_Challenge_Share = 3DS_Challenge / 3DS_Total`

`3DS_Frictionless_Share = 3DS_Frictionless / 3DS_Total`

`Abandon_on_3DS = 3DS_Started - 3DS_Completed`

Coupes obligatoires : 'BIN × country', 'provider × method', 'device/os', 'ticket _ size' (par exemple, ≤€50, 50-200 €,> 200 €).

3. 2 Pertes (capture)

`Capture_Success = Captured_Tx / Capture_Attempted_Tx`

`Net_Conversion = Captured_Tx / Auth_Attempted_Tx` (= AR_net)

`Partial_Capture_Share = Partial_Captures / Captured_Tx`

`Capture_Latency_p95 = p95(capture_timestamp - auth_timestamp)`

`Void_Rate = Voids / Auth_Approved`

3. 3 Coût et FX

`Cost_per_Tx = Fee_fixed + AmountFee_pct + FX_Spread`

`Cost/GGR = ΣCost / GGR`

`Net_Revenue = GGR - ΣCost - Fraud_Loss - Disputes_Cost`

3. 4 Retours (refund)

`Refund_Rate = Refunded_Tx / Captured_Tx`

`Refund_Amount_Ratio = Refunded_Amount / Captured_Amount`

`TtR_p95 = p95(refund_credit_at - refund_initiated_at)`

`Refund_Error_Rate = Refund_Failed / Refund_Attempted`

`Refund_to_Source_% = Refund_to_Original_Method / Total_Refunds`

'Double _ Refund _ Incidents 'est un compteur de collisions idempotentes (doit = 0)

4) Objectifs/repères (personnalisables pour un portefeuille spécifique)

AR_gross : cartes de 3DS2 - 82-92 % (par BIN/pays), A2A - 90 % + (initiation), bons - 95 % + (redeem).
Capture_Success: 98. 5 % + (avec webhooks et retraits en direct).
TtC p95 : ≤ 5 min (cartes auto-capture), ≤ 90 secondes (instant A2A/RTP).
Refund Error: < 0. 3%; TtR p95 : ≤ T + 1 banque. jour (s), ≤ 60 secondes (instant rails).
Refund_to_Source %: ≥ 95 % (où les rails sont supportés).
Idempotency Incidents: = 0; Webhook SLA: ≥ 99. 9%, p95 < 3 c.

(Pas des « repères du marché », mais des couloirs cibles pratiques pour les SLO internes.)

5) Segmentation et attribution

Considérez KPI en coupe : 'country', 'method _ group', 'provider', 'BIN', 'device/os', 'ticket _ size', 'risk _ segment', 'kyc _ tier', 'affiliate', 'new _ vs _ returning'.

Cohort AR : AR par cohortes de premier paiement (D0/D7/D30).
Route AR : AR sur les itinéraires « PSP_A→PSP_B failover ».
Risk-aware AR : AR par segment de risque (après step-up).
BIN-heatmap : les émetteurs vulnérables → des règles distinctes pour les retraits/3DS.

6) Modèle de données (couche plane pour BI)

Minimum « event-flat » :


payment_id, user_id, country, provider, method_code, action(deposit/refund),
attempt_ts, auth_status, auth_code, auth_ts,
three_ds(flow, started_ts, completed_ts, challenge_flag),
capture_status, capture_amount, capture_ts, partial_flag,
refund_status, refund_amount, refund_initiated_ts, refund_credit_ts,
fees_fixed, fees_pct, fx_spread, currency, amount,
risk_segment, kyc_tier, bin, asn, device_os, ticket_bucket

La clé est l'idempotent 'payment _ key' par étape et 'idempotency _ key' par refund.

7) tranches SQL (exemple)

7. 1 Quotidien AR et Capture

sql
WITH base AS (
SELECT
DATE_TRUNC('day', attempt_ts) d,
country, provider, method_code,
COUNT() FILTER (WHERE auth_status='ATTEMPTED') AS auth_attempted,
COUNT() FILTER (WHERE auth_status='APPROVED') AS auth_approved,
COUNT() FILTER (WHERE capture_status='CAPTURED') AS captured_tx
FROM payments_flat
WHERE action='deposit'
GROUP BY 1,2,3,4
)
SELECT d, country, provider, method_code,
auth_approved::decimal / NULLIF(auth_attempted,0) AS ar_gross,
captured_tx::decimal / NULLIF(auth_attempted,0)  AS ar_net
FROM base;

7. 2 Refund Santé

sql
SELECT
DATE_TRUNC('day', refund_initiated_ts) d,
country, provider, method_code,
COUNT() FILTER (WHERE refund_status='ATTEMPTED') AS refund_attempted,
COUNT() FILTER (WHERE refund_status='SUCCESS')  AS refund_success,
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (refund_credit_ts - refund_initiated_ts))) AS ttr_p95_sec
FROM payments_flat
WHERE action='refund'
GROUP BY 1,2,3,4;

7. 3 frottements 3DS

sql
SELECT country, provider,
COUNT() FILTER (WHERE three_ds.flow IS NOT NULL) AS three_ds_total,
COUNT() FILTER (WHERE three_ds.challenge_flag)  AS three_ds_challenge,
COUNT() FILTER (WHERE three_ds.flow='FRICTIONLESS') AS three_ds_frictionless
FROM payments_flat
WHERE action='deposit'
GROUP BY 1,2;

8) Dashboard (widgets obligatoires)

1. Funnel : Attempt → Auth → Capture (en absolu et conversions).
2. AR heatmap: по `country×provider` и `BIN×country`.
3. 3DS Quality: Challenge/Frictionless/Abandon.
4. Capture Latency p50/p95 и Webhook SLA.
5. Refund Health: Refund Rate, TtR p95, Refund Error, Refund_to_Source %.
6. Cost/GGR : par méthodes et fournisseurs.
7. Alerts panel : top codes d'échec, dégradation AR/latency.

9) SLO, alertes et playbooks

SLO/Alerte (exemple) :

« AR_gross↓> 3 pp à la médiane de 7 jours » → ALERT P1 (vérifier BIN/fournisseur/ASN).
Capture _ Success <98 % (heure) ou Webhook p95> 5 c '→ ALERT P1 (Retrai/Incident chez PSP).
« TtR _ p95> cible » selon les méthodes instant → ALERT P2 (vérifier la file d'attente/les limites).
`Refund_Error_Rate > 0. 5 % 'ou' Double _ Refund> 0 '→ ALERT P0 (gel des refands automatiques, vérification manuelle).

Pleybuki :

Dégradation BIN : Inclure un acquéreur alternatif, augmenter la proportion de 3DS-challenge pour le BIN, rétroaction avec des paramètres 'ECI'.
Système Soft Declines : routage intelligent → PSP_B, limiter la répétition à N, modifier la politique 3DS.
Délais de capture : force-retrai, vérification de la signature des webhooks, augmentation du TTL d'idempotence.
Erreurs de refund : activer les clés idempotent, limiter les partial-refund parallèles, QA manuel sur les doublons.

10) Gestion du risque et de la conformité dans les KPI

Rapportez- AR_clean après la suppression de 'Fraud _ Preblocked' et 'Abandon _ 3DS' est votre AR opérationnel, ne mélangez pas avec l'effet antifrod.
Refund_to_Source % - KPI réglementaire clé ; fixez les exceptions comme bou-approved.
Dispute/Chargeback Rate, attachez-vous à un captured_amount plutôt qu'à une tentative.

11) Erreurs fréquentes

Sommation des différentes bases (attempt vs auth vs capture) en une fraction.
L'absence de segmentation par 'ticket _ size' → de fausses conclusions sur AR.
Ne tient pas compte de 'User Abdon' sur 3DS → « artificiellement » faible AR.
Non 'idempotency _ key' sur refund → doublons/pertes financières.
Mélange de payout et de refund dans une seule métrique TtW/TtR.

12) Chèque de vérification de mise en œuvre

Schéma d'événements harmonisé et définitions uniques des indicateurs clés de performance.
Heatmap par BIN/pays et routage par fournisseurs.
Dashboard à friction 3DS et abdon.
SLA webhooks, rétroactions, idempotence (auth/capture/refund).
Rapports sur Refund Health et Refund_to_Source %.
Alerts sur la dégradation AR, Capture_Success, TtR, erreurs refund.
Examen mensuel de R&O : Cost/GGR, Disputations, spreads FX, fournisseur-SLA.

13) Résumé

Un circuit de paiement fort est un entonnoir transparent avec une base correcte pour chaque part, une discipline rigoureuse des événements, une segmentation et des playbooks automatiques. Les bons KPI transforment l'infrastructure de paiement en un levier de croissance : AR_net↑, TtC/TtR↓, Cost/GGR↓, Disputes↓, avec une sécurité constante ou améliorée.