გადახდის KPI დაშბორდი

TL; DR

ერთი დაშბორდი - სამი ფენა: Attempt - Auth - Capture, ფინანსური ეფექტურობა (TtW/TtR, Cost/GGR, FX) და ინფრასტრუქტურის საიმედოობა (Webhook/Latence/Settlement). საიდუმლო არის სწორი გაანგარიშების ბაზები, სავალდებულო სეგმენტი (country × provider × method × BIN × ticket _ size × risk), SLO ბარიერი და მზა playbuks დერეფნების გასვლისას.

1) ვისთვის და რა კითხვებს ვხურავთ

CEO/GM (ყოველდღიურად, 3-5 წუთი): "გადახდის კონვერტაცია და დასკვნების სიჩქარე ნორმალურია? ფულის მიღების ღირებულება კონტროლდება?"

Head of Payments/Treasury (ყოველ საათში): "სად არის დეგრადაცია პროვაიდერის/ქვეყნის/მეთოდით? არის საკმარისი ლიკვიდობა მყისიერი გადახდებისთვის?"

Fraud/Risk (ყოველდღიურად): "AR ანტიფროდის გათვალისწინებით? Abandon на 3DS и Soft declines?»

მხარდაჭერა/ოპერაციები (ონლაინ): "რა არის ETA დასკვნა და დაბრუნება? სად ჩამოიხრჩო ვებჰუკები?"

Finance/Recon (D + 1): "Settlement დროულად? კომისიები და FX შეესაბამება გეგმას?"

2) ძირითადი მეტრიკა და ზუსტი განმარტებები

2. 1 გადახდის ძაბრი

Attempt - ინიცირებული გადახდები.
Auth Approved დამტკიცებულია ავტორიზაციით.
Captured - წარმატებით დაიშალა.

• `AR_gross = 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 დასკვნები და ზარალი

Payout Success % = Success_Payouts / Attempted_Payouts

TtW p95 = p95(payout_credited_at - payout_initiated_at)

Refund Rate = Refunded_Tx / Captured_Tx

TtR p95 = p95(refund_credit_at - refund_initiated_at)

Refund Error % = Refund_Failed / Refund_Attempted

Refund _ to _ Source% - თავდაპირველი მეთოდის დაბრუნების წილი

2. 3 ღირებულება და FX

Cost/Tx = Fee_fixed + AmountFee_pct + FX_Spread

Cost/GGR = ΣCost / GGR

FX Slippage (bps) = (exec_px − mid_px)/mid_px × 10 000

2. 4 ინტეგრაციის საიმედოობა

Webhook Delivery p95 (сек), Success %

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

Settlement Timeliness = ბრძოლები, რომლებიც მოვიდნენ გამოცხადებულ T + N/ყველა ბრძოლაში პერიოდისთვის

2. 5 3DS/ხახუნი (ბარათებისთვის)

3DS Challenge Share = Challenge / 3DS_Total

Frictionless Share = Frictionless / 3DS_Total

Abandon on 3DS = 3DS_Started − 3DS_Completed

3) ჭრილობები და ფილტრები (მინიმალური ნაკრები)

Фильтры в шапке: `date 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) მთავარი ეკრანის მარკირება (Layout)

1. ზედა Land KPI (გუშინ/დღეს, შედარება P7 საშუალო):

`AR_net`, `Capture_Success`, `Payout Success%`, `TtW p95`, `TtR p95`, `Cost/GGR`, `Webhook p95`, `Settlement Timeliness`.

2. Funnel (Attempt - Auth - Capture) სეგმენტის არჩევით და წარუმატებლობის მიზეზების ჩვენებით (რელსებზე ISO/ტოპ კოდები).

3. Heatmap AR 'country × provider' და ცალკეული BIN heatmap უმაღლესი მოცულობისთვის.

4. 3DS პანელი: Challenge/Frictionless/Abandon + შედარება ბენჩის ხაზთან.

5. Payout & Refund Health: Success%, p95 (TtW/TtR), ошибки, Refund_to_Source %.

6. Cost & FX: Cost/GGR მეთოდების მიხედვით, FX slippage/fees საიტებზე.

7. ინტეგრაციის საიმედოობა: Webhook delivery p95/Success%, API latency p95/p99, Duplicate rate, ანგარიში მიწოდების SLA.

8. ინციდენტის პანელი: აქტიური ალერტები (იხ. § 8), ფეილოვერების სტატუსი და ხაზინის ნოტები (ნაშთები L0, prefund).

5) SLO და ალერტები (დერეფნები)

• 'AR _ gross' ბარათები 3DS2: 82-92% (სეგმენტის მიხედვით); 'AR _ net' 80%
• `Capture_Success` ≥ 98. 5% (საათობრივი)
• `Webhook p95` ≤ 3 с, Success ≥ 99. 9%
• `Payout TtW p95` instant ≤ 120 с; (T + 1) - D + 1 დღეში 100%
• 'Refund TtR p95' ბარათები T + 1 bd.; instant ≤ 60 с
• `Refund Error %` < 0. 3%
• `Settlement Timeliness` ≥ 99%
• 'Cost/GGR' - ინდივიდუალური სამიზნე დერეფანი მეთოდით

• 'AR _ gross "> 3 პროცენტული პუნქტი 7-დღიანი საშუალო (ქვეყანაში/PSP/BIN), P1/P0
• `Capture_Success < 98%` (час) → P1
• 'Webhook p95> 5 c' ან დუბლიკატები> 0, P1
• `Payout TtW p95 > SLO` или Success%<99% → P1
• `Refund Error% > 0. 3%` или `Double Refund > 0` → P0
• `Settlement on-time < 99%` → P1
• 'Cost/GGR' დერეფნის გასასვლელი P2 მეთოდით

თითოეული ალერტი ხსნის runbook ბარათს (მოქმედებები/ესკალაცია/ფეილოვერი).

6) ფორმულები და გაანგარიშების ბაზა (დეტალები)

ყველა წილი - აშკარა ბაზით: მიუთითეთ tultipe 'denominator'.
დრო - UTC- ში; p-quantile: PERCENTILE _ CONT.

'AR _ clean' (ოპერაციული) = 'Auth _ Approved/( Auth _ Attempted - Fraud _ Preblocked - Abandon _ 3DS) "

`Net_Conversion` = `Captured_Tx / Auth_Attempted_Tx`

`Refund_to_Source %` = `Refund_to_Original_Method / Total_Refunds`

'Idle Cash%' (ხაზინის მინი ვიჯეტში) = '(Balance - Target _ Balance )/Balance'

7) UX ნიმუშები

KPI- პლატფორმის თავზე, ქვემოთ - funnel + heatmaps, ქვემოთ - ინტეგრაცია და ფინანსები.
ტულტიპები ფორმულა/ბაზა/გამონაკლისი (მაგალითად, „ანტიფროდის შემდეგ“).
შედარებითი ხაზი: p7 საშუალო და „გუშინ „/“ გასულ ორშაბათს “.
Drill-down კლიშეზე: heatmap- დან BIN - Issuer ცხრილში, უარის თქმის კოდები.
Snaphots for RCA: ღილაკი „დაფიქსირება“ მიმდინარე ხედი პოსტ-mortem- ისთვის.

8) Playbuks (ჩაშენებული მოქმედების ბარათები)

Auth drop- ს შეუძლია შეცვალოს smart-routing, BIN 3DS-challenge გაზარდოს და შეზღუდოს retrais.
Webhook შეფერხებები შეიძლება შეიცავდეს პოლინგს, გაყინვას მანქანების რეფანდები/საშიში მანქანები, გაძლიერდეს იდემპოტენტურობა.
Payout- ის დეგრადაცია - სარკინიგზო ფალილოვერი, სამგზავრო ტოპ - უპი, VIP პრიორიტეტი.
შეფერხება StressRes, შენიშვნა „Suspense“, ესკალაცია PSP- ში.
Refund შეცდომები/დუბლები - refund-freeze, cryption, ძალიან დუბლი.

(ბარათი შეიცავს შემოწმების ჩამონათვალს და ესკალაციის კონტაქტებს.)

9) მონაცემთა მოდელი (მინიმალური საკმარისი)

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

ინდექსები: 'provider', 'method _ code', 'country', 'bin', 'event _ ts'.

10) SQL ნაჭრები (მაგალითი)

10. 1 ძაბრი და 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 Refund & Payout Health

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 Cost/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) დამატებითი ეკრანები

BIN Drilldown: AR/decline-codes, 3DS ხახუნის, გამცემი ლატენტებით.
Provider Scorecard: SLA მეტრიკა, ინციდენტები, სესხები, Cost/GGR.
Treasury Snapshot: L0/L1 ნაშთები, prefund, StressRes, TtF შევსება.
Recon View: Settlement Timeliness, არაკეთილსინდისიერი ბრძოლები, Fee Accuracy.

12) მონაცემთა ხარისხი

KPI ლექსიკონი ვერსიით (ფორმულა/ბაზა/გამონაკლისი).
ერთი TZ = UTC, p - მხოლოდ CONT.
მოვლენების იდემპოტენტურობა და ვებჰუკების დედობა.
დროის/თანხის ტოლერანტული პოლიტიკა/FX (გადამოწმების/ლატენტობისთვის).
მონაცემთა ტესტები CI- ში: არა ცარიელი გამყოფი ბაზები, დროებითი ეტიკეტების ერთფეროვნება, NULL- ის წილი.

13) განხორციელება: შემოწმების სია

• განსაზღვრულია KPI/ფორმულა/ბაზა და ჩაწერილია ლექსიკონში.
• კონფიგურაცია და მოვლენების/რეესტრების ნორმალიზება.
• აშენდა ფანჯრები 'payments _ flat', 'webhooks', 'settlements', 'treasury'.
• ხორციელდება heatmaps, funnel, latency, payout/refund panels.
• SLO და ალერტას ბარიერები; უკავშირდება playbooks.
• წვდომის როლები: C-level (read-only summary), Ops/Fraud (drill-down).
• ყოველკვირეული QBR პროვაიდერებზე დაყრდნობით Provider Scorecard.
• UAT ტესტების ნაკრები: dataset დემო, p- კვანტილების შემოწმება, ბაზების სისწორე, ალერტები.

14) ხშირი შეცდომები

ბაზების ('attempt' vs 'capture') ნაზავი ყალბი დასკვნებია.
არ არსებობს სეგმენტი 'ticket _ size' - დამახინჯებული AR სურათი.
აბანდონის უგულებელყოფა 3DS- ზე არის „გადაჭარბებული“ პრობლემა პროვაიდერთან.
Webhook duplicates- ის კონტროლის არარსებობა ორმაგ მოქმედებებს წარმოადგენს.
არასრული settlement/fees ფანჯარა შეუძლებელია Cost/GGR- ის შეფასება.
SLO და playbooks- ის გარეშე, დაშბორდი იქცევა „ფანჯარაში მოქმედების გარეშე“.

რეზიუმე

გადახდის KPI დაშბორდი არის ოპერაციული ინსტრუმენტი და არა მხოლოდ გრაფიკა. ის აკავშირებს ძაბრს, ფულს და ინფრასტრუქტურას, ეყრდნობა მკაფიო ფორმულებსა და სეგმენტებს, იძლევა ავტომატურ სიგნალებს და დაუყოვნებლივ გთავაზობთ მოქმედებებს. შედეგად: AR _ net უფრო მაღალია, დერეფნებში TtW/TtR, Cost/GGR კონტროლდება, ინციდენტები სწრაფად ხდება ლოკალიზებული, ხოლო პროვაიდერებთან დიალოგი შენდება ციფრებზე.