KPI płatności deski rozdzielczej

TL; DR

Jedna deska rozdzielcza - trzy warstwy: zdrowie lejka (próba → Auth → przechwytywanie), wydajność finansowa (TtW/TtR, Cost/GGR, FX) i niezawodność infrastruktury (Webhook/Latency/Settlement). Tajemnicą są prawidłowe podstawy obliczeniowe, obowiązkowa segmentacja (country × provider × metoda × BIN × ticket _ size × risk), progowe SLO i gotowe playbooki podczas opuszczania korytarzy.

1) Dla kogo i jakie pytania zamykamy

CEO/GM (dziennie, 3-5 min): "Konwersja płatności i szybkość wypłaty są normalne? Czy koszt przyjęcia pieniędzy jest pod kontrolą?"

Szef ds. Płatności/Skarbu Państwa (co godzinę): "Gdzie jest degradacja według dostawcy/kraju/metody? Czy istnieje wystarczająca płynność do natychmiastowych płatności?"

Oszustwo/ryzyko (dziennie): "AR z zwalczania nadużyć finansowych? Abandon на 3DS „Miękkie spadki?”

Wsparcie/operacje (online): "Co to jest ETA do wycofania i zwrotu? Gdzie wiszą haki?"

Finance/Recon (D + 1): "Rozliczenie na czas? Prowizje i FX pasują do planu?"

2) Główne metryki i dokładne definicje

2. 1 Lejek płatniczy

Próba - zainicjowane płatności.
Auth Approved - zatwierdzone zezwolenia.
Schwytany - z powodzeniem odpisany.

• "AR _ brutto = Auth_Approved/ Auth_Attempted'
• "AR _ net = Captured_Tx/ Auth_Attempted'
• "Capture _ Success = Captured_Tx/ Capture_Attempted_Tx'
• „Capture _ Latency _ p95 = p95 (capture_ts - auth_ts)”

2. 2 Wyjścia i zwroty

Sukces wypłaty% = Success_Payouts/ Attempted_Payouts

TtW p95 = p95 (payout_credited_at - payout_initiated_at)

Stawka zwrotu = Refunded_Tx/ Captured_Tx

TtR p95 = p95 (refund_credit_at - refund_initiated_at)

Błąd zwrotu% = Refund_Failed/ Refund_Attempted

Refund_to_Source% - odsetek powrotów do pierwotnej metody

2. 3 Koszty i FX

Koszt/Tx = Fee_fixed + AmountFee_pct + FX_Spread

Koszt/GGR = Α Cost/GGR

FX Poślizg (bps) = (exec_px − mid_px )/ mid_px × 10 000

2. 4 Niezawodność integracji

Webhook Dostawy p95 (сей), Sukces%

API Latency p95/p99 (auth/capture/refund/payout)

Terminowość rozliczeń = Partie, które przyszły do zadeklarowanego T + N/wszystkie partie na okres

2. 5 3DS/friction (dla kart)

3DS Challenge Share = Challenge/ 3DS_Total

Frictionless Share = Frictionless/ 3DS_Total

Porzucenie 3DS = 3DS_Started − 3DS_Completed

3) Sekcje i filtry (minimalny zestaw)

Милктра кабка: "data range (UTC)", "country", "provider", "method _ group", "BIN", "device/os'," ticket _ size bucket (≤ 50 €/50-200 €/> 200 €) "," risk _ segment "," kyc _ tier ", 'new _ vs _ returning', 'affiliate'.

• country × provider, BIN × country, method × provider, device/os, ticket_size.

4) Układ ekranu głównego

1. Górna płyta KPI (dla wczoraj/dzisiaj, porównanie do mediany p7):

„AR _ net”, „Capture _ Success”, „Payout Success%”, „TtW p95”, „TtR p95”, „Cost/GGR”, „Webhook p95”, „Settlement Timeliness”.

2. Lejek (Próba → Auth → Przechwytywanie) z wyborem segmentu i wyświetlaniem przyczyn awarii (ISO top kody/na szyny).

3. Mapa ciepłownicza AR według „kraju × dostawcy” oraz oddzielna mapa grzewcza BIN dla najwyższej objętości.

4. Panel 3DS: Challenge/Frictionless/Abandon + porównanie do linii ławki.

5. Payout & Refundacja Zdrowie: Sukces%, p95 (TtW/TtR), овибка, Refund_to_Source%.

6. Koszt & FX: Koszt/GGR metodą, FX poślizg/opłaty według strony.

7. Niezawodność integracji: Dostawa Webhook p95/Sukces%, Latency API p95/p99, Duplikat rate, Zgłoś dostawy SLA.

8. Panel incydentów: aktywne wpisy (patrz § 8), status feiloverów i noty skarbowe (resztki L0, prefund).

5) SLO i wpisy (korytarze)

• „AR _ brutto” 3DS2 karty: 82-92% (według segmentów); „AR _ net” ≥ 80%
• „Capture _ Success” ≥ 98. 5% (co godzinę)
• "Webhook p95" ≤ 3 ", sukces ≥ 99. 9%
• "Wypłata TtW p95" natychmiastowa ≤ 120 "; (T + 1) - 100% w dniu D + 1
• "Refundacja TtR p95pcards ≤ T + 1 pb; błyskawicznie ≤ 60 "
• 'Błąd zwrotu%' <0. 3%
• „Terminowość rozliczeń” ≥ 99%
• „Koszt/GGR” - indywidualny korytarz docelowy według metody

• "AR _ brutto"> 3 pp "do 7-dniowej mediany (kraj/PSP/BIN) → P1/P0
• 'Capture _ Sukces <98%' (маz) → P1
• 'Webhook p95> 5 c' lub duplikaty> 0 → P1
• 'Payout TtW p95> SLO' ила Sukces% <99% → P1
• 'Błąd zwrotu%> 0. 3% 'ила' Podwójny zwrot pieniędzy> 0 '→ P0
• „Rozrachunek na czas <99%” → P1
• "Koszt/GGR 'out korytarza za pomocą metody P2 →

Każdy alert otwiera kartę runbook'a (akcje/eskalacja/feilover).

6) Wzory i podstawy obliczeniowe (szczegóły)

Wszystkie akcje - z wyraźną podstawą: wskazać „mianownik” w typie.
Czasy - w UTC; p-kwantyle: PERCENTILE_CONT.

„AR _ clean” (operacyjny) = „Auth _ Approved/( Auth_Attempted − Fraud_Preblocked − Abandon_3DS)”

"Net _ Conversion" = "Captured _ Tx/ Auth_Attempted_Tx'

'Refund _ to _ Source%' = 'Refund _ to _ Original _ Method/ Total_Refunds'

„Bezczynna gotówka%” (w mini widgecie skarbowym) = „(Saldo − Target_Balance )/Balant”

7) wzory UX

Powyżej jest płyta KPI, poniżej jest lejek + mapy grzewcze, poniżej jest integracja i finanse.
Tultips ze wzorem/podstawą/wyjątkami (na przykład „po antyfraud”).
Linia porównawcza: p7 mediana i „wczoraj „/” ostatni poniedziałek „.
Wiertło-down klikając: od mapy grzewczej do błędu BIN → Emitent → kody tabeli.
Migawki dla RCA: Przycisk „pin” aktualny widok pośmiertny.

8) Playbooks (wbudowane karty akcji)

Auth drop → przełącznik smart-routing, podnieść 3DS-challenge do BIN, ograniczyć przekładnie.
Opóźnienia Webhook → włączyć sondaż, zamrozić auto-refands/niebezpieczne automatyczne płatności, zwiększyć idempotencję.
Degradacja wypłaty → feiler kolejowy, doładowanie skarbu, priorytety VIP.
Opóźnienie rozliczenia → Res, znak „Suspense”, eskalacja w PSP.
Zwrot błędów/duplikatów → zwrot-zamrożenie, uzgodnienie, cofnięcie duplikatów.

(Karta zawiera listę kontrolną i kontakty eskalacyjne).

9) Model danych (minimum wystarczające)

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

events/webhooks:
provider, event_kind, event_ts, delivered_ts, retries, duplicate_flag, idempotency_key

settlements/reports:
provider, batch_id, settlement_date, amount_settled, currency, fee_amount, status

treasury/pockets (mini-widget):
pocket_id, counterparty, currency, balance, target_balance, low_watermark, updated_at

Indeksy: według 'dostawcy', 'method _ code', 'country', 'bin', 'event _ ts'.

10) plasterki SQL (przykład)

10. 1 Lejek i AR

sql
WITH base AS (
SELECT
DATE_TRUNC('hour', attempt_ts) AS h,
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 h, 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;

10. 2 Webhook SLA

sql
SELECT
DATE_TRUNC('hour', event_ts) AS h, provider,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (delivered_ts - event_ts))) AS wb_p95_sec,
AVG(CASE WHEN retries=0 AND NOT duplicate_flag THEN 1 ELSE 0 END) AS wb_success
FROM webhooks
GROUP BY 1,2;

10. 3 Zwrot i wypłata zdrowia

sql
SELECT
DATE_TRUNC('day', COALESCE(refund_initiated_ts, payout_initiated_ts)) d,
method_code, provider,
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,
COUNT() FILTER (WHERE payout_status='ATTEMPTED') AS payout_attempted,
COUNT() FILTER (WHERE payout_status='SUCCESS')  AS payout_success,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (payout_credited_ts - payout_initiated_ts))) AS ttw_p95_sec
FROM payments_flat
GROUP BY 1,2,3;

10. 4 Koszt/GGR

sql
SELECT
DATE_TRUNC('day', capture_ts) d,
method_code, provider,
SUM(fees_fixed + amountfees_pct + fx_spread) AS total_cost,
SUM(capture_amount) AS total_captured,
(SUM(fees_fixed + amountfees_pct + fx_spread) / NULLIF(SUM(total_captured),0)) AS cost_to_captured
FROM payments_flat
WHERE capture_status='CAPTURED'
GROUP BY 1,2,3;

11) Dodatkowe ekrany

BIN Drilldown: AR/kody spadkowe, 3DS-friction, opóźnienia emitentów.
Dostawca Scorecard: SLA Metrics, Incydenty, Kredyty, Koszt/GGR.
Migawka skarbu: salda L0/L1, prefunda, Res, uzupełnienie TtF.
Widok Recon: Rozrachunek czasu, Starzenie się bez szwów Butches, Dokładność opłaty.

12) Jakość danych

Słownik KPI z wersją (formuły/podstawy/wyjątki).
Pojedynczy TZ = UTC, p-kwantyle tylko CONT.
Idempotencja wydarzeń i dedup webhooks.
Polityka tolerancji czasu/kwoty/FX (dla pojednania/opóźnienia).
Testy danych w CI: niepuste podstawy podziału, monotonia znacznika czasowego, frakcja NULL.

13) Wdrożenie: lista kontrolna

• KPI/formuły/podstawy są zdefiniowane i ustalone w słowniku.
• konfiguracja normalizacji spożycia i zdarzeń/rejestru.
• Wbudowane prezentacje "payments _ flat", "webhooks'," settlements "," treasury ".
• Wdrożone mapy ciepłownicze, lejek, opóźnienia, panele wypłat/refundacji.
• ustalone progi SLO i alarmowe; związane z playbooks.
• Role dostępu: poziom C (streszczenie tylko do odczytu), operacje/oszustwa (wiertarka).
• Tygodniowy QBR przez dostawcę w oparciu o Scorecard dostawcy.
• UAT test suite: demo dataset, p-quantile check, database correctness, alerts.

14) Częste błędy

Mieszanie baz ('próba' vs 'capture') → fałszywe wnioski.
Brak segmentacji 'ticket _ size' → zniekształcony obraz AR.
Ignoruj porzucenie 3DS → „zawyżony” problem z dostawcą.
Brak kontroli webhook duplikaty → podwójne działania.
Niekompletny pokaz rozliczeń/opłat → Koszt/GGR nie może być oszacowany.
Bez SLO i odtwarzaczy, deska rozdzielcza zamienia się w „prezentację bez akcji”.

Podsumowanie

KPI płatności deski rozdzielczej są narzędziem operacyjnym, nie tylko wykresy. Łączy lejek, pieniądze i infrastrukturę, opiera się na wyraźnych formułach i segmentacji, daje automatyczne sygnały i natychmiast sugeruje działania. W rezultacie: AR_net powyżej, TtW/TtR w korytarzach, Koszt/GGR pod kontrolą, incydenty są szybko zlokalizowane, a dialog z dostawcami opiera się na liczbach.