KPI پرداخت داشبورد

TL ؛ دکتر متخصص

یک داشبورد - سه لایه: سلامت قیف (تلاش → Auth → ضبط)، بهره وری مالی (TtW/TtR، هزینه/GGR، FX) و قابلیت اطمینان زیرساخت (Webhook/Latency/Settlement). راز مبانی محاسبه صحیح، روش تقسیم بندی اجباری (ارائه دهنده کشور BIN، ticket _ size risk)، SLO آستانه و playbooks آماده در هنگام خروج از راهروها است.

1) برای چه کسی و چه سوالات ما نزدیک است

مدیر عامل شرکت/GM (روزانه، 3-5 دقیقه): "تبدیل پرداخت و سرعت خروج طبیعی است ؟ آیا هزینه پذیرش پول تحت کنترل است ؟

رئیس پرداخت/خزانه (هر ساعت): "تخریب توسط ارائه دهنده/کشور/روش کجاست ؟ آیا نقدینگی کافی برای پرداختهای فوری وجود دارد ؟

تقلب/خطر (روزانه): "AR با ضد تقلب ؟ ترک на 3DS и نرم کاهش می یابد ؟

پشتیبانی/عملیات (آنلاین): "ETA برای خروج و بازگشت چیست ؟ وب سایت ها کجا آویزان هستند ؟"

امور مالی/Recon (D + 1): "حل و فصل در زمان ؟ کمیسیون و FX مناسب این طرح ؟"

2) معیارهای اصلی و تعاریف دقیق

2. 1 قیف پرداخت

تلاش - پرداخت آغاز شده است.
Auth تایید شده - مجوزهای تایید شده.
گرفته شده - با موفقیت نوشته شده است.

• 'AR _ gross = Auth_Approved/ Auth_Attempted'
• 'AR _ net = Captured_Tx/ Auth_Attempted'
• 'تسخیر _ موفقیت = Captured_Tx/ Capture_Attempted_Tx'
• 'Capture _ Latency _ p95 = p95 (capture_ts - auth_ts)'

2. 2 خروجی ها و بازده ها

پرداخت موفقیت% = Success_Payouts/ Attempted_Payouts

TtW p95 = p95 (payout_credited_at - payout_initiated_at)

نرخ بازپرداخت = Refunded_Tx/ Captured_Tx

TtR p95 = p95 (refund_credit_at - refund_initiated_at)

خطای بازپرداخت% = Refund_Failed/ Refund_Attempted

Refund_to_Source% - نسبت بازگشت به روش اصلی

2. 3 هزینه و FX

هزینه/tx = Fee_fixed + AmountFee_pct + FX_Spread

هزینه/GGR = هزینه Σ/GGR

لغزش FX (bps) = ( )/10000

2. 4 قابلیت اطمینان از ادغام

وبهوک تحویل p95 (сек), موفقیت%

تاخیر API p95/p99 (auth/ضبط/بازپرداخت/پرداخت)

بهنگام بودن حل و فصل = دسته که به اعلام آمد T + N/همه دسته برای دوره

2. 5 3DS/friction (برای کارت)

چالش 3DS به اشتراک گذاشتن = چالش/ 3DS_Total

اشتراک بدون اصطکاک = بدون اصطکاک/ 3DS_Total

3DS = 3DS_Started − 3DS_Completed

مهم: جدا کردن AR عملیاتی (پس از ضد تقلب و رها کردن کاربر) از «خام» - این دو معیار متفاوت با اهداف متفاوت هستند.

3) بخش ها و فیلترها (حداقل مجموعه)

Фильтры в шапке: 'محدوده تاریخ (UTC)'، 'کشور'، 'ارائه دهنده'، 'روش _ گروه'، 'BIN'، 'دستگاه/os'، 'سطل بلیط _ اندازه (≤€50/€ 50-200/> €200)'، 'بخش ریسک'، 'kyc _ tier'، 'جدید _ در مقابل _ بازگشت'، 'وابسته'.

• ارائه دهنده × کشور، BIN × کشور، روش × ارائه دهنده، دستگاه/os، ticket_size.

4) طرح بندی صفحه اصلی

1. صفحه KPI بالا (برای دیروز/امروز، در مقایسه با میانه P7):

'AR _ net'، 'Capture _ Success'، 'Payout Success٪'، 'TtW p95'، 'TtR p95'، 'Cost/GGR'، 'Webhook p95'، 'Settlement Timeliness'.

2. قیف (تلاش → Auth → ضبط) با انتخاب بخش و نمایش علل شکست (کدهای بالای ISO/بر روی ریل).

3. AR Heatmap توسط «ارائه دهنده × کشور» و یک heatmap جداگانه BIN برای حجم بالا.

4. پانل 3DS: چالش/اصطکاک/رها کردن + مقایسه با خط نیمکت.

5. پرداخت و بازپرداخت سلامت: موفقیت٪، p95 (TtW/TtR)، ошибки، Refund_to_Source٪.

6. هزینه و FX: هزینه/GGR توسط روش، FX لغزش/هزینه های سایت.

7. قابلیت اطمینان ادغام: تحویل وب سایت p95/موفقیت٪، تاخیر API p95/p99، نرخ تکراری، SLA تحویل گزارش.

8. پانل حادثه: هشدار فعال (§ 8 را ببینید)، وضعیت feilovers و یادداشت های خزانه داری (باقی مانده L0، prefund).

5) SLO و هشدار (راهرو)

• کارتهای 3DS2 «AR _ gross»: 82-92٪ (به تفکیک بخش) ؛ «AR _ net» ≥ 80٪
• 'ضبط _ موفقیت' ≥ 98. 5٪ (ساعتی)
• 'Webhook p95' ≤ 3 с، موفقیت ≥ 99. 9%
• 'پرداخت TtW p95' فوری ≤ 120 с ؛ (T + 1) - 100٪ در روز D + 1
• 'بازپرداخت TtR p95' کارت ≤ T + 1 bp ؛ ≤ فوری 60 с
• 'خطای بازپرداخت%' <0. 3%
• «بهنگام بودن حل و فصل» ≥ 99%
• 'هزینه/GGR' - راهرو هدف فردی با توجه به روش

• 'AR_gross↓> 3 pp' به 7 روز متوسط (کشور/PSP/BIN) → P1/P0
• 'Capture _ Success <98٪' (час) → P1
• 'Webhook p95> 5 c' or تکراری> 0 → P1
• «پرداخت TtW p95> SLO» или موفقیت٪ <99٪ → P1
• 'خطای بازپرداخت%> 0. 3٪ 'или' بازپرداخت دو> 0 '→ P0
• «حل و فصل در زمان <99٪» → P1
• 'هزینه/GGR' out of corridor using P2 → روش

هر هشدار کارت runbook 'a (اقدامات/تشدید/feilover) را باز می کند.

6) فرمول ها و پایه های محاسبه (جزئیات)

همه سهام - با یک پایه صریح: نشان می دهد 'مخرج' در نوع.
زمان - در UTC ؛ P-چندک: PERCENTILE_CONT.

'AR _ clean' (عملیاتی) = 'Auth _ Approved/( )'

'Net _ Conversion' = 'گرفته شده _ Tx/ Auth_Attempted_Tx'

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

'Idle Cash%' (in treasury mini widget) = '(تعادل − Target_Balance )/تعادل'

7) الگوهای UX

در بالا یک صفحه KPI است، در زیر قیف + heatmaps است، در زیر ادغام و امور مالی است.
Tultips با فرمول/پایه/استثنا (به عنوان مثال، «پس از antifraud»).
خط مقایسه ای: P7 میانه و «دیروز «/» دوشنبه گذشته «.
تمرین با کلیک: از heatmap به گسل BIN → صادر کننده → جدول کودی.
عکس های فوری برای RCA: دکمه «پین» نمایش فعلی برای پس از مرگ.

8) Playbooks (ساخته شده در کارت های عمل)

Auth قطره → سوئیچ هوشمند مسیریابی، افزایش 3DS-challenge به BIN، محدود کردن بازپرداخت.
Webhook تاخیر → فعال کردن رای گیری, مسدود خودکار refands/خطرناک خودکار پرداخت, افزایش idempotence.
تخریب پرداخت → راه آهن feiler، خزانه داری بالا، اولویت بندی VIP.
حل و فصل تاخیر → StressRes، علامت «تعلیق»، تشدید در PSP.
بازپرداخت خطاها/تکراری → بازپرداخت یخ، آشتی، معکوس تکراری.

(کارت شامل یک چک لیست و مخاطبین تشدید است.)

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

شاخص ها: توسط «ارائه دهنده»، «روش _ کد»، «کشور»، «بن»، «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 وبلاگ 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 بازپرداخت و پرداخت سلامت

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 هزینه/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/کاهش، 3DS-friction، تأخیر توسط صادرکنندگان.
کارت امتیازی ارائه دهنده: معیارهای SLA، حوادث، اعتبارات، هزینه/GGR.
عکس فوری خزانه داری: تعادل L0/L1، prefund، StressRes، دوباره پر کردن TtF.
Recon View: زمان حل و فصل، Butches بدون پیری، دقت هزینه.

12) i治理 کیفیت داده

فرهنگ لغت KPI ها با نسخه (فرمول/پایه/استثنا).
تنها TZ = UTC، p-quantles تنها CONT.
Idempotency از حوادث و dedup از webhooks.
سیاست تحمل زمان/مقدار/FX (برای آشتی/تأخیر).
تست داده ها در CI: پایگاه های مقسوم علیه غیر خالی، یکنواختی برچسب زمانی، کسر NULL.

13) پیاده سازی: چک لیست

• KPI ها/فرمول ها/پایگاه ها در فرهنگ لغت تعریف و ثابت شده اند.
• مصرف و عادی سازی رویداد/رجیستری پیکربندی شده است.
• ساخته شده ویترین «پرداخت _ تخت»، «وبهوک»، «شهرک»، «خزانه داری».
• پیاده سازی نقشه های حرارتی، قیف، تاخیر، پانل های پرداخت/بازپرداخت.
• SLO و آستانه هشدار ایجاد شده است ؛ مرتبط با playbooks
• نقش دسترسی: سطح C (فقط خواندنی خلاصه)، عملیات/تقلب (مته پایین).
• QBR هفتگی توسط ارائه دهنده بر اساس کارت امتیازی ارائه دهنده.
• مجموعه آزمون UAT: مجموعه داده نسخه ی نمایشی, چک P-چندک, صحت پایگاه داده, هشدار.

14) خطاهای مکرر

مخلوط کردن پایه ها («تلاش» در مقابل «ضبط») → نتیجه گیری نادرست.
بدون تقسیم بندی «ticket _ size» → تصویر AR تحریف شده.
چشم پوشی از رها کردن در 3DS → یک مشکل «بیش از حد» با ارائه دهنده.
عدم کنترل webhook تکراری → اقدامات دوگانه.
ویترین ناقص برای حل و فصل/هزینه → هزینه/GGR را نمی توان برآورد کرد.
بدون SLO ها و playbooks، داشبورد به یک «ویترین بدون عمل» تبدیل می شود.

خلاصه

KPI های پرداخت داشبورد یک ابزار عملیاتی هستند، نه فقط نمودارها. این قیف، پول و زیرساخت را متصل می کند، به فرمول های روشن و تقسیم بندی متکی است، سیگنال های اتوماتیک را می دهد و بلافاصله اقدامات را پیشنهاد می دهد. در نتیجه: AR_net بالا، TtW/TtR در راهروها، هزینه/GGR تحت کنترل، حوادث به سرعت محلی می شوند و گفتگو با ارائه دهندگان بر اساس اعداد است.