クリプトカジノ
トレントギア
決済ゲートウェイとの統合：フロー、リターン、和解
完全な記事
1） iGamingにおける支払いオーケストレーションの役割
キャッシュレジスタはプラットフォームの「動脈」です。預金を受け取り、キャッシュアウトを開始し、リターン/チャージバックを処理し、ウォレット（Ledger）と同期します。ここでエラーまたは遅延が発生すると、金融およびコンプライアンスのリスクにすぐに変わります。アーキテクチャのタスクは、障害が発生した場合に迅速かつ確実に正しいキャッシュフローです。
2） PSPによる基本フロー（状態マップ）
2.1デポジット（ステータスカード）
1.create_intent （INITIATED）→プラットフォーム側に支払い意図を作成します。
2.authorize （AUTHORIZED）→hold in PSP（オプション-一度にキャプチャ）。
3.3-DS/AVS/KYCフック→追加のリスク/規制チェック。
4.キャプチャ（キャプチャ）→デビット；ウォレット・クレジット。
5.failed/expired/canceled→補償と意図の終了。
2.2キャッシュアウト（退会）
request→RG/AMLの検証→payout_initiated→payout_settled/failed。
VIP/大量、速度制限、ジオルールの4つの目の確認。
2.3無効/払い戻し
void：キャプチャを取り消します（オフ）。
払い戻し：キャプチャ後の部分的/完全なリターン。
カードスキームの場合-別のステータス「送信/処理」。
不変性：プレイヤーのバランスの真実は財布です。PSPの設計は直接バランスを変えません；'walletコマンドを使用するだけです。「クレジット/デビット」はidempotencyである。
3） Idempotence、キーおよび後退
各書き込み操作には「X-Idempotency-Key」と「X-Trace-Id」が含まれます。
キー構成はビジネスパラメータにバインドされます（例： 'intent_id+amount+currency'）
同じキー→同じ結果（古いボディで200）で繰り返す。
指数関数的なバックオフ+ジッタ、ハード'タイムアウト/期限'で後退します。
4） 3-DS、 AVSの速度、antifraud
3-DS 2。x：好ましくはデバイスフィンガープリントによるチャレンジフロー；ECI/CAVV/DSTransIDをログに記録します。
AVS/CVV：テレメトリーとルーティングルールに検証コードを含める。
速度：量/量/カード/ASN/デバイス （1h/24h/7d）による制限。
行動のキュー：地理/タイムゾーンの不一致、多くのカード/いくつかの預金、高速キャッシュアウト。
5） PSPのルーティングおよびカスケード
ルール：地理、BIN範囲、カードの種類、コスト、変換、リスク率。
カスケード：バスケット（idempotentトークン）を失うことなく、失敗時にPSP1→PSP2。
A/B/マルチアームバンディット：変換とコストの最適化。
フェイルオープン/クローズ：疑わしいエラーの場合は、safe-default（たとえば、別の商人を繰り返します）を使用しますが、ダブルキャプチャには使用しません。
6） API契約（参照フラグメント）
6.1入金意思の作成
POST/v1/キャッシャー/インテント
ヘッダー：X-Idempotency-Key、 X-Trace-Id
{
「player_id":"p_123,」「量「：{「量」：50。00、 "currency"： "EUR"}、 "method'：" card"、"metadata"：{"brand_id"："A"、"region"："EU"}
}
→201 {「intent_id":"pi_001,""status":"INITIATED」}6.2承認/キャプチャ
POST/ v1/cashier/intents/pi_001/authorize
→200 {「status「：「AUTHORIZED「、「psp_ref「：」psp_aa1」、」 eci」：」 05」、」 cavv」：」……」}
POST/ v1/cashier/intents/pi_001/capture
→200 {「status「：「CAPTURE「、「capture_id」：」 cap_001」}6.3無効/払い戻し
POST/ v1/cashier/captures/cap_001/refunds
{「refund_id":"rf_001,」「量「：{「量」：10。00、 「currency」：」 EUR」}}
→202{「ステータス「：「返金_提出済み」}6.4 PSP Webhooks→プラットフォーム（HMAC/EdDSAによって署名）
POST/webhooks/psp
X署名：sha256=……
{
"イベント"："支払い。キャプチャ、""psp_ref":"psp_aa1,""intent_id":"pi_001,"量"：{"minor_units'： 5000、" currency"："EUR"}、"occurred_at":"2025-10-23T12:05:01Z,""idempotency_key":"cap_001"
}受信者は、署名/timestamp/nonce、重複排除'event_id'をチェックし、'intent_id'と相関させる必要があります。
7）財布との同期（元帳）
キャプチャ後：command 'wallet。クレジット'（idempotently）→プレイヤーの残高。
払い戻し：'財布。debit'（または'wallet。hold_release' voidの場合）。
キャッシュアウト：'財布。debit'→'payout 'PSP；webhook 'payout_settled'の後-佐賀を閉じる。
Saga 「deposit」： 「authorize→capture→credit」と失敗の補償。
「払い戻し/払い戻し」saga： 'request→submitted→settled/failed'とやり直しと重複排除。
8）和解-マネーコントロールの中心
8.1毎日の和解
PSP決済レポート（商人/日付/通貨）を取得します。
プラットフォームレジストリにマップ：'intents/captures/refunds/payouts' ↔' wallet entries'。
カテゴライズ：- match： ok、 timing： delay mіzh reports、 missing_psp： in the platform is、 in the PSP is not、 missing_platform： in the PSP is、 in the platform is not、 in the platform is not、 amount_mismatch： amount/currency/feeの違い。
- タイミングの自動ルール、ミスマッチのためのチケット/エスカレーション。
8.2テクニカルプロセス
レポートはスケジュール（リトレイ+インテグリティ制御）でSFTP/APIによってプルされます。
解析→正規化→決定的マッピング（'psp_ref'、 'intent_id'、 'capture_id'）。
調整は不変量によってOLAP （ClickHouse/BigQuery）で実行されます。
BIショーケース：コンバージョン、故障の理由、チャネルコスト、クロージング時間。
8.3アラート
'％mismatch'> X p。 p。、 'missing_platform' spike、 'amount_mismatch' growth、 'deposit_success' channel/geo variance、 extending transactions> Ndays。
9）チャージバック/紛争
ライフサイクル：通知→証拠→表現→仲裁。
証拠パケット（KYC、 IP/ASN、デバイス、3-DS結果、使用ログ）を保存します。
リスク/不正防止との密接な関係：カード/デバイス/ASNはルーティングレベルで禁止されます。
KPI：双方向性、費用対効果、クローズまでの時間。
10）テレメトリーとSLO
p95認可：≤ 3 s、 p99： ≤ 6-8 s （3-DS/バンクによって異なります）。
地理/PSPによる入金成功率：目標≥ 85％（現実的なガイドライン）。
和解の遅れ：レポートはT+1日≤閉じました。老化していない 払い戻しのターンアラウンド：送信のための≤ T+1、登録のための≤ T+5（スキームに従って）。 メトリクス：コードによるエラーレート、3-DS/AVSによる失敗、declow-matrix （bank/code）、成功あたりのコスト、webhook-lag、再試行嵐。 11）安全性とコンプライアンス mTLSからPSP+へのOAuth2/requestの署名キー/ブランド/地域ごとの証明書。 PCI DSS： PANトークン化、決してCVV、ゾーンセグメンテーションを保存しません。 WORM監査：crete操作（手動払い戻し/無効、商人の変更）。 RG/AML：キャプチャ/ペイアウト前のフィート；サンクリスト/POP；SAR/STRレポート。 PIIレジデンシー：地域のログ/レポート；BIでのRLS/マスキング。 12）可視性とロギング 'trace_id'、 'psp_ref'、 'intent_id/capture_id/refund_id'、コードと期間を持つ構造化ログ（JSON）。 HTTP/gRPC/DB/キューのOpenTelemetry；エラー/金銭的異常のための100％サンプリング。 NOCダッシュボード：チャネル変換、p95、コード障害、webhook-lag、 DLQ。 13）カオスとDRの実践 PSP秋： autocascade/」新しいキャプチャを一時停止「 Delay Webhook： deadup+pull-APIによる再調整。 Out-of-order：プラットフォーム上のidempotencyとstatus machine。 地域停止：資産責任/資産、RPO ≤ 5分、RTO ≤ 30分。 14）チェックリスト 15）アンチパターン（赤い旗） ウォレットへの明示的なコマンドなしでPSP Webhookによってバランスが変わります。 idempotency→double write-off/creditsなし。 ゲームプロバイダのiFrame内に内蔵のキャッシュレジスタ（RG/AML/テレメトリー制御の損失）。 複数のブランド/地域のための共通の商人のキー。 T+1の和解なし、手動Excelマッピング。 BI/規制報告は、OLTPキャッシュデスクから直接報告されます。 3-DS/AVSエラーはログ化/分析されません。 符号なしのwebhooks/windowの検証→リプレイ。 データベース内の支払い/残高ステータスの手動編集。 16）ボトムライン 1.Idempotent moneyコマンドとsagas （authorize/capture/refund/payout）。 2.PSPルーティングと3-DS/AVS/velocityと実際のテレメトリーによるカスケード。 3.毎日の和解と不一致の厳密な会計。 4.セキュリティとコンプライアンス（mTLS、署名、PCI、 RG/AML、 WORM）。 これらの基盤を構築したことで、プラットフォームは預金の変換を増加させ、テイクとチャージバックのリスクを減らし、トラフィックのピーク時や外部プロバイダーが失敗した場合でも、自信を持って監査を通過します。
プラットフォーム/オペレーター
PSP統合/キャッシュデスクバックエンド