支払のプロフィールKPI： auth、捕獲、払い戻し

TL；DR（ドクター）

支払いループはファネルとして測定されます：'試み→Auth→Capture→Settle/Refund'。重要な指標は、承認率だけでなく、純粋なAR（不正防止と3DS後）、キャプチャの成功、書き込み/登録時間、コスト/FX、 idempotencyエラー、リターンの品質（TtRとレート）です。Risk Profileを破らずに、ARを保持している方（TtW）、 Cost/GGRを保持している方（Cost/GGR）が勝って、紛争に立ち向かいます）。

1）ステージやイベントの辞書

試行-支払い試行（開始）。
認証-承認（銀行/財布/レールは、書き込みの可能性を確認しました）。
キャプチャ-実際の書き込み（完全/部分）。
決済-清算と決済。
返金-返品（完全/部分）、'TtR=クレジットを返金する時間'。
Void-キャプチャを取り消す（サポートされている場合）。
3DS/Step-up-認可の摩擦。
ソフトダウンロード/ハードダウンロード-リカバリ可能/リカバリ不可能な障害。

「国、プロバイダー、方法、アクション（入金/払い戻し/払い戻し）、デバイス/OS、 ticket_size、 risk_segment、 kyc_tier、 bin/asn」。

2） KPI階層（ターゲットツリー）

アッパーレベル

総承認率（AR_gross）=認証/試行

Net Approval Rate （AR_net）=キャプチャ/試行

コスト/GGR=（手数料+FX+Ops ）/GGR

TTW/TtC： タイムツーウォレット、TtC（キャプチャ）p95

返金の健康： 返金率、TtR p95、返金エラー率

中級レベル

3DSチャレンジシェア、摩擦のないシェア、3DSでの放棄

ソフトダウンリカバリレート（リトレイ/スマートルーティング）

部分的なキャプチャシェア、キャプチャレイテンシー

ソース％、重複/Idempotencyインシデントへの返金

低レベル（診断）

コードによるエラー（ISO/rail）、 p95 APIレイテンシー、SLA Webhook、 'Do Not Honor'、 'Insufficient Funds'、 'Suspected Fraud'、 'System Error'。

3）数式（正確な定義）

3.1認可

'AR_gross=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'

セクションは必須です：'BIN × country'、 'provider × method'、 'device/os'、 'ticket_size'（例えば、≤ €50、€50-200、>€200）。

3.2キャプチャ

'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）'

'Void_Rate=Voids/ Auth_Approved'

3.3コストとFX

'Cost_per_Tx=Fee_fixed+AmountFee_pct+FX_Spread'

'Cost/GGR=Σ Cost/GGR'

'Net_Revenue=GGR-Σ Cost-Fraud_Loss-Disputes_Cost'

3.4払い戻し

'払い戻し_レート=Refunded_Tx/ Captured_Tx'

'Refund_Amount_Ratio=Refunded_Amount/ Captured_Amount'

'TtR_p95=p95 （refund_credit_at-refund_initiated_at）'

'Refund_Error_Rate=Refund_Failed/ Refund_Attempted'

'Refund_to_Source_％=Refund_to_Original_Method/ Total_Refunds'

'Double_Refund_Incidents'-idempotent collision counter（必須=0）

4）目標/ベンチマーク（特定のポートフォリオでカスタマイズ可能）

AR_gross： 3DS2カード-82-92％ （BIN/国）、 A2A-90％+（開始）、バウチャー-95％+（交換）。
Capture_Success： 98。5％+（ライブWebフックとリトリート付き）。
TtC p95： ≤ 5分（自動キャプチャ付きカード）、≤ 90秒（インスタントA 2A/RTP）。
返金エラー：<0。3%;TtR p95： ≤ T+1銀行。日（カード）、≤ 60秒（インスタントレール）。
Refund_to_Source%： ≥ 95％（レールがサポートされている場合）。
Idempotency Incidents：=0；Webhook SLA： ≥ 99。9％、 p95 <3 c。

（「市場ベンチマーク」ではなく、内部SLOのための実用的なターゲット回廊）

5）セグメンテーションとアトリビューション

'country'、 'method_group'、 'provider'、 'BIN'、 'device/os'、 'ticket_size'、 'risk_segment'、 'kyc_tier'、 'affiliate'、 'new_vs_returning'のコンテキストでKPI Iを考えます。

コホートAR：ファーストペイメントコホート（D0/D7/D30）によるAR。
ルートAR： 'PSP_A→PSP_Bフェイルオーバー'ルートのAR。
リスクアウェアAR：リスクセグメント別AR（ステップアップ後）。
BIN-heatmap：脆弱な発行者→個別のretray/3DS規則。

6）データモデル（BIのための平らな層）

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

キー-ステージへのidempotent 'payment_key'と払い戻しへの'idempotency_key'。

7） SQLスライス（例）

7.1毎日のARとキャプチャ

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払い戻しの健康

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.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）ダッシュボード（必須ウィジェット）

1.ファネル：Attempt→Auth→Capture（絶対と変換）。
2.ARヒートマップ：「国×プロバイダ」「BIN ×国」。
3.3DS品質：挑戦/摩擦のない/放棄。
4.レイテンシーP 50/P95をキャプチャします。
5.返金の健康：返金率、TtR p95、返金エラー、Refund_to_Source％。
6.コスト/GGR：メソッドとプロバイダによる。
7.アラートパネル：障害のトップコード、AR/レイテンシーの劣化。

9） SLO、アラート、プレイブック

• 'AR_gross→3 pp〜7-day median'→ALERT P1 （BIN/provider/ASNをチェック）。
• 'Capture_Success <98％（毎時）'または'Webhook p95> 5 c'→ALERT P1 （PSPリトレイ/インシデント）。
• メソッドinstant→ALERT P2 （check queue/limits）による'TtR_p95> target'。
• 'Refund_Error_Rate> 0。5％'または'Double_Refund> 0'→ALERT P0（自動リファンドフリーズ、手動チェック）。

• BIN劣化：代替アクワイアラーを含める、BINの3DS-challengeの割合を増加させる、'ECI'パラメータで再試行する。
• システムソフトの低下：スマートルーティング→PSP_B、リトライをNに制限、3DSポリシーを変更します。
• キャプチャ遅延：強制リトレイ、Webhookの署名の検証、TTL idempotencyの増加。
• 返金エラー：idempotentキーの有効化、並列部分払い戻しの制限、重複に対する手動QA。

10） KPIにおけるリスクとコンプライアンス管理

「Fraud_Preblocked」と「Abandon_3DS」を削除した後のレポートのAR_clean-これはあなたの運用ARであり、不正防止効果と混合しないでください。
Refund_to_Source%-主要な規制KPI；comp-approvedとして例外を修正しました。
紛争/チャージバック率は、試みではなく、captured_amountにバインドします。

11）頻繁なエラー

1分の1の異なった基盤（試み対auth vsの捕獲）の合計。
'ticket_size'→ARによる誤った結論によるセグメンテーションの欠如。
3DS→「人工的に」低いARで「ユーザー放棄」が見つかりません。
返金→2倍/金銭的損失に'idempotency_key'はありません。
同じTtW/TtRメトリックでペイアウトと払い戻しを混在させます。

12）実装チェックリスト

• 合意されたイベントスキーマと統一されたKPI定義。
• BIN/国によるヒートマップとプロバイダによるルーティング。
• 3DSの摩擦とダッシュボードの放棄。
• SLA webhooks、 retrays、 idempotency （auth/capture/refund）。
• 払い戻しの健康とRefund_to_Source%による報告。
• AR、 Capture_Success、 TtR劣化アラート、払い戻しエラー。
• 月例R&Oレビュー：コスト/GGR、紛争、FXスプレッド、プロバイダ-SLA。

13）概要

強力な支払いループは、各シェア、厳格なイベント規律、セグメンテーション、自動プレイブックの正しいベースを持つ透明なファネルです。正しいKPIは、決済インフラを成長レバーに変えます：不変または改善された安全性で、AR_net：、 TtC/TtR：、 Cost/GGR：、紛争：。