ダッシュボード決済KPI

TL；DR（ドクター）

1つのダッシュボード-3つのレイヤー：ファネルの健全性（試み→Auth→Capture）、財務効率（TtW/TtR、 Cost/GGR、 FX）、およびインフラストラクチャの信頼性（Webhook/レイテンシー/決済）。秘密は、正しい計算ベース、必須セグメンテーション（国×プロバイダ×方法× BIN × ticket_size × risk）、しきい値SLO、既製のプレイブックです。

1）誰のために、どのような質問を閉じる

CEO/GM（毎日、3-5分）： "支払い変換と引き出し速度は正常ですか？お金を受け入れる費用は管理されているのでしょうか"

支払いのヘッド/財務省（毎時）： "プロバイダ/国/方法による劣化はどこにありますか？即時支払いに十分な流動性はありますか？"

詐欺/リスク（毎日）： "詐欺防止のAR？3DSを放棄します。ソフトは低下しますか？"

サポート/オペレーション（オンライン）： "引き出しと返品のためのETAとは何ですか？ウェブフックはどこにぶら下がっているのか"

ファイナンス/リコン（D+1）： "時間通りの決済？手数料とFXは計画に合っていますか？"

2）主な指標と正確な定義

2.1支払の漏斗

試行-支払いを開始しました。
Auth Approved-承認された承認。
キャプチャ-正常にオフに書き込まれました。

• '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出力と返品

支払い成功率=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）=（exec_px − mid_px）/mid_px × 10 000

2.4統合の信頼性

Webhook配信P95（繁体字）、成功％

API レイテンシーp 95/p99（認証/キャプチャ/払い戻し/支払い）

決済の適時性=宣言されたT+N/期間のすべてのバッチに来たバッチ

2.5 3DS/friction（カード用）

3DSチャレンジシェア=チャレンジ/3DS_Total

Frictionless Share=Frictionless/ 3DS_Total

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_returnew_ring'、''。

• 国×プロバイダ、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.セグメント選択と故障原因（ISOトップコード/レール上）の表示を伴うファネル（Attempt→Auth→Capture）。

3.'country × provider'によるHeatmap ARと、トップボリューム用の個別のBINヒートマップ。

4.3DSパネル：挑戦/摩擦なし/放棄+ベンチラインとの比較。

5.支払い&払い戻しの健康：成功％、P95 （TtW/TtR）、 Refund_to_Source％。

6.費用&FX：方法による費用/GGR、場所によるFXの滑り/料金。

7.統合の信頼性：Webhook配信p95/成功％、 APIレイテンシp95/p99、重複レート、レポート配信SLA。

8.インシデントパネル：アクティブアラート（第8条を参照）、feiloversおよびtreasuryノートのステータス（L0、 prefund）。

5） SLOおよび警報（通路）

• 'AR_gross' 3DS2カード：82-92％（セグメント別）；'AR_net' ≥ 80％
• 'Capture_Success' ≥ 98。5％（1時間あたり）
• 'Webhook p95' ≤ 3'、Success ≥ 99。9%
• 「Payout TtW p95」インスタント≤ 120％；（T+1）-100％当日D+1
• '返金TtR p95'カード≤ T+1 bp；インスタント≤ 60分
• '返金エラー％'<0。3%
• 「決済の適時性」≥ 99％
• 「コスト/GGR」-方法に従って個々のターゲット回廊

• 'AR_gross→3 pp'から7日間の中央値（country/PSP/BIN）→P1/P0
• 'Capture_Success <98％'→P1
• 'Webhook p95> 5 c'または重複>0→P1
• 「Payout TtW p95> SLO」の成功率<99％→P1
• '返金エラー％>0。3％'и-'二重払い戻し>0'→P0
• 「決済オンタイム<99％」→P1
• P2→メソッドを使用して廊下から'コスト/GGR'

各アラートは、runbook 'aカード（アクション/エスカレーション/feilover）を開きます。

6）数式と計算ベース（詳細）

すべての共有-明示的なベースを持つ：型の'分母'を示します。
タイムズ-UTC；p-quantiles： PERCENTILE_CONT。

'AR_clean' （operational）='Auth_Approved/（ ）'

'Net_Conversion'='キャプチャされた_Tx/ Auth_Attempted_Tx'

'Refund_to_Source％'='Refund_to_Original_Method/ Total_Refunds'

'Idle Cash％' （Treasury mini widget）='（Balance − Target_Balance ）/Balance'

7） UXパターン

上記はKPIプレート、以下はファネル+ヒートマップ、以下は統合とファイナンスです。
数式/ベース/例外を含むチューリップ（例えば「、アンチフラウド後」）。
比較行：p7の中央値と「昨日「/」最後の月曜日「。
クリックでドリルダウン：ヒートマップから障害BIN→Issuer→kodyテーブルまで。
RCAのスナップショット：死後のためのボタン「ピン」現在のビュー。

8） Playbooks（作り付けの行為カード）

オートドロップ→スイッチスマートルーティング、BINに3DS-challengeを上げ、リトレイを制限します。
Webhookの遅延→ポーリングを有効にし、自動リファンド/危険な自動支払いを凍結し、idempotenceを増加させます。
ペイアウト劣化→レールファイラー、財務省トップアップ、VIP優先順位付け。
決済遅延→StressRes、 「Suspense」マーク、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

インデックス：'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払い戻し&払い戻しの健康

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/declow-codes、 3DS-friction、発行者によるレイテンシ。
プロバイダのスコアカード：SLAメトリクス、インシデント、クレジット、コスト/GGR。
財務スナップショット：L0/L1残高、プレファンド、ストレスレス、TtF補充。
Recon View：決済タイミング、エイジングノンステッチバッチ、料金精度。

12）データ品質i治理

バージョン管理付きKPIの辞書（数式/ベース/例外）。
単一TZ=UTC、 p量子はCONTのみ。
イベントの独特性とwebhookのデッドアップ。
時間/金額/FX公差ポリシー（調整/レイテンシ）。
CIでのデータテスト：空でない分割基盤、タイムスタンプモノトニー、NULL分数。

13）実装： チェックリスト

• KPI/数式/ベースは辞書で定義され、固定されます。
• ingestionおよびevent/registry normalization構成。
• ビルトショーケース'payments_flat'、 'webhooks'、'決済'、'treasury'。
• ヒートマップ、ファネル、レイテンシー、ペイアウト/払い戻しパネルを実装。
• 確立されたSLOとアラートのしきい値；Playbookに関連付けられています。
• アクセスロール：Cレベル（読み取り専用サマリー）、Ops/Fraud（ドリルダウン）。
• プロバイダスコアカードに基づくプロバイダによる毎週のQBR。
• UATテストスイート：デモデータセット、p-quantleチェック、データベースの正確性、アラート。

14）頻繁なエラー

ミキシングベース（'attempt'と'capture'）→誤った結論。
'ticket_size'セグメンテーション→歪んだAR画像はありません。
3DSの放棄を無視してください→プロバイダの「誇張された」問題。
コントロールのwebhook重複→ダブルアクションの欠如。
決済・手数料の不完全なショーケース→コスト/GGRは見積もることができません。
SLOとプレイブックがなければ、ダッシュボードは「アクションなしのショーケース」に変わります。

概要

ダッシュボード決済KPIは、グラフだけでなく、運用ツールです。それはファネル、お金とインフラストラクチャを接続し、明確な数式とセグメンテーションに依存し、自動信号を与え、すぐにアクションを提案します。その結果、上記のAR_net、廊下のTtW/TtR、制御下のコスト/GGR、インシデントは迅速にローカライズされ、プロバイダとの対話は数字に基づいています。