GH GambleHub

Profil płatności KPI: auth, capture, refund

TL; DR

Pętla płatnicza jest mierzona jako lejek: „Próba → Auth → Przechwytywanie → Rozliczenie/Zwrot”. Kluczowe wskaźniki to nie tylko wskaźnik zatwierdzenia, ale także czysty AR (po zwalczaniu oszustw i 3DS), przechwytywanie sukcesu, czas na umorzenie/zapisanie, koszt/FX, błędy dotyczące idempotencji i jakość zwrotów (TtR i szybkość). Ten, kto posiada AR, TtW, Cost/GGR, jest zwycięzcą, przeciwko sporom, bez łamania profilu ryzyka.


1) Słownik etapów i wydarzeń

Próba - próba płatności (inicjacja).
Auth - autoryzacja (bank/portfel/szyny potwierdziły możliwość umorzenia).
Przechwytywanie - faktyczne odpisanie (pełne/częściowe).
Osiedle - rozliczenia i osiedla.
Zwrot - zwrot (pełny/częściowy), „TtR = czas na zwrot kredytu”.
Nieważność - cofnij do przechwytywania (jeśli jest obsługiwany).
3DS/Step-up - tarcie przy autoryzacji.
Miękki spadek/twardy spadek - odzyskiwalne/nieściągalne awarie.

💡 Маба иверений: "kraj, dostawca, metoda, działanie (depozyt/wypłata/zwrot), urządzenie/os, ticket_size, risk_segment, kyc_tier, bin/asn'.

2) hierarchia KPI (drzewo docelowe)

Górny poziom

Wskaźnik zatwierdzenia brutto (AR_gross) = Auth/próba

Wskaźnik zatwierdzenia netto (AR_net) = wychwytywana/próba

Koszt/GGR = (Opłaty + FX + Operacje )/GGR

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

Zdrowie refundacji: Stawka zwrotu, TtR p95, stopa błędu zwrotu

Poziom pośredni

3DS Challenge Share, Frictionless Share, Porzuć 3DS

Miękki spadek szybkości odzyskiwania (Retray/Smart Routing)

Częściowy udział w przechwytywaniu, przechwytywanie opóźnień

Zwrot do źródła%, Duplikat/Idempotence Incydenty

Niższy poziom (diagnostyka)

Błędy według kodów (ISO/rail), p95 API latency, SLA webhooks, udział „Nie honorować”, „niewystarczające fundusze”, „Podejrzane oszustwo”, „Błąd systemu”.


3) Wzory (dokładne definicje)

3. 1 Zezwolenie

"AR _ brutto = 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'

Wymagane są sekcje: "BIN × country", "provider × method", "device/os'," ticket _ size "(na przykład, ≤ 50 €, 50-200 €,> 200 €).

3. 2 Przechwytywanie

"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)”

"Nieważność _ Stawka = pustki/ Auth_Approved'

3. 3 Koszty i FX

"Koszt _ na _ Tx = Fee_fixed + AmountFee_pct + FX_Spread'

„Koszt/GGR = اCost/GG”

"Netto _ Dochody = GGR - اCost - Fraud_Loss - Disputes_Cost'

3. 4 Refundacje

"Refundacja _ Stawka = Refunded_Tx/ Captured_Tx'

"Zwrot _ kwota _ stosunek = Refunded_Amount/ Captured_Amount'

„TtR _ p95 = p95 (refund_credit_at - refund_initiated_at)”

"Zwrot _ Błąd _ Stawka = Refund_Failed/ Refund_Attempted'

"Zwrot _ do _ Source _% = Refund_to_Original_Method/ Total_Refunds'

„Double _ Refund _ Incidents” - idempotent collision counter (must = 0)


4) Cele/poziomy odniesienia (dostosowane do konkretnego portfela)

AR_gross: karty 3DS2 - 82-92% (BIN/kraj), A2A - 90% + (inicjacja), bony - 95% + (wykup).
Capture_Success: 98. 5% + (z żywymi hakami i rekolekcjami).
TtC p95: ≤ 5 min (karty z automatycznym przechwytywaniem), ≤ 90 s (natychmiastowy A2A/RTP).
Błąd zwrotu pieniędzy: <0. 3%; TtR p95: ≤ T + 1 bank. dzień (karty), ≤ 60 s (szyny błyskawiczne).
Refund_to_Source%: ≥ 95% (w przypadku podtrzymywania szyn).
Idempotencja Incydenty: = 0; Hak SLA: ≥ 99. 9%, p95 <3 c.

(Nie „rynkowe poziomy odniesienia”, ale praktyczne korytarze docelowe dla wewnętrznych SLO.)


5) Segmentacja i przypisanie

Należy rozważyć KPI w kontekście: "country", "method _ group", "provider", "BIN", "device/os'," ticket _ size "," risk _ segment "," kyc _ tier "," affiliate "," new _ vs _ returning ".

Kohorta AR: AR według kohorty pierwszej płatności (D0/D7/D30).
Trasa AR: AR na trasach 'PSP _ A → PSP _ B failover'.
AR świadomy ryzyka: AR według segmentu ryzyka (po przyspieszeniu).
BIN-heatmap: emitenci podatni na zagrożenia → oddzielne zasady retray/3DS.


6) Model danych (płaska warstwa dla BI)

Minimalne „zdarzenie-mieszkanie”:

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

Klucz - idempotent 'payment _ key' do etapu i 'idempotence _ key' do zwrotu.


7) plasterki SQL (przykład)

7. 1 Dzienny AR i przechwytywanie

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 Zdrowie refundacji

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. Tarcie 3 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) Deska rozdzielcza (wymagane widżety)

1. Lejek: Próba → Auth → Przechwytywanie (absolutne i konwersje).
2. AR heatmap: ма „country × provider” „BIN × country”.
3. Jakość 3DS: Challenge/Frictionless/Abandon.
4. Przechwytywanie Latency p50/p95 Webhook SLA.
5. Zdrowie refundacji: stawka zwrotu, TtR p95, błąd zwrotu, Refund_to_Source%.
6. Koszt/GGR: według metod i dostawców.
7. Panel alarmowy: najwyższe kody awarii, degradacja AR/latencji.


9) SLO, alerty i playbooks

SLO/Alerts (przykład):
  • "AR _ brutto"> 3 pp do 7-dniowej mediany "→ ALERT P1 (sprawdź BIN/dostawca/ASN).
  • 'Capture _ Success <98% (godzinowo)' lub 'Webhook p95> 5 c' → ALERT P1 (PSP Retray/Incydent).
  • 'TtR _ p95> target' metodami natychmiastowymi → ALERT P2 (sprawdź kolejkę/limity).
  • 'Refund _ Error _ Rate> 0. 5% 'lub' Double _ Refund> 0 '→ ALERT P0 (automatyczne zamrażanie refand, ręczne sprawdzanie).
Playbooks:
  • Degradacja BIN: włączenie alternatywnego nabywcy, zwiększenie udziału 3DS-challenge dla BIN, przekwalifikowanie z parametrami „INE”.
  • System Soft Declines: smart routing → PSP_B, limit retry to N, zmień politykę 3DS.
  • Opóźnienia przechwytywania: przekłady siły, weryfikacja podpisywania haków webowych, zwiększona idempotencja TTL.
  • Błędy zwrotu: włączyć klucze idempotentne, ograniczyć równoległy częściowy zwrot, ręcznie QA dla duplikatów.

10) Zarządzanie ryzykiem i przestrzeganiem przepisów w KPI

Raport AR_clean po usunięciu 'Fraud _ Preblocked' i 'Abandon _ 3DS' - to jest Twój operacyjny AR, nie mieszaj się z efektem zwalczania nadużyć finansowych.
Refund_to_Source% - kluczowe KPI regulacyjne; ustalić wyjątki jako zatwierdzone przez komp.
Stawka sporu/obciążenia zwrotnego wiąże się z captured_amount, a nie próbami.


11) Częste błędy

Podsumowanie różnych baz (próba vs auth vs przechwytywanie) w jednym ułamku.
Brak segmentacji przez 'ticket _ size' → fałszywe wnioski AR.
Brak 'User Abandon' na 3DS → „sztucznie” niski AR.
No 'idempotency _ key' on zwrot → podwójne/straty finansowe.
Mieszanie wypłat i refundacji w tym samym metryku TtW/TtR.


12) Lista kontrolna wdrażania

  • Uzgodniony schemat zdarzeń i ujednolicone definicje KPI.
  • Heatmap według BIN/kraju i routing przez dostawcę.
  • Tarcie 3DS i rezygnacja z deski rozdzielczej.
  • Haki SLA, przekładki, idempotencja (auth/capture/refund).
  • Sprawozdawczość przez zwrot zdrowia i Refund_to_Source%.
  • AR, Capture_Success, alerty degradacji TtR, błędy zwrotu.
  • Miesięczny przegląd R&O: Koszt/GGR, spory, Spready FX, Dostawca-SLA.

13) Podsumowanie

Mocna pętla płatnicza to przezroczysty lejek z właściwą bazą dla każdej akcji, ścisłą dyscypliną wydarzeń, segmentacją i automatycznymi odtwarzaczami. Prawidłowa infrastruktura KPI przekształca infrastrukturę płatności w dźwignię wzrostu: AR_net, TtC/TtR, Cost/GGR, Spory, na niezmiennym lub ulepszonym bezpieczeństwie.

Contact

Skontaktuj się z nami

Napisz do nas w każdej sprawie — pytania, wsparcie, konsultacje.Zawsze jesteśmy gotowi pomóc!

Rozpocznij integrację

Email jest wymagany. Telegram lub WhatsApp są opcjonalne.

Twoje imię opcjonalne
Email opcjonalne
Temat opcjonalne
Wiadomość opcjonalne
Telegram opcjonalne
@
Jeśli podasz Telegram — odpowiemy także tam, oprócz emaila.
WhatsApp opcjonalne
Format: kod kraju i numer (np. +48XXXXXXXXX).

Klikając przycisk, wyrażasz zgodę na przetwarzanie swoich danych.