GH GambleHub

決済サイクルとカットオフ

1）概念ベース

決済-PSP/Acquirerと商人（オペレータ）の間の決済で、成功した取引のためのお金が商人口座に転送されます。
カットオフ-特定の請求サイクル（通常はプロバイダのタイムゾーンで固定時間）に陥る業務の毎日の「スライス」。
T+N-投稿資金の遅延の典型的な表記法：T-カットオフ日、N-実際の登録前の営業日数。

例：
  • カード（Visa/Mastercard）：多くの場合、T+2/T+3バンキング日、カットオフ23：00 UTC（約）。
  • A2A/Open銀行：T+0からT+1。
  • SEPAクレジット転送：T+1/T+2（インスタント-T+0）。
  • ACH（米国）：T+2/T+3；同じ日のACH-T+0/T+1。
  • RTP（米国）：T+0ですが、レポートのカットオフは可能です。
  • 暗号：実際にはネットワーク上のT+0ですが、PSPは独自の資金調達ウィンドウ（T+0/1）を適用できます。

2）カットオフがどのように機能し、何がそれに入るか

1.プロバイダはコレクションウィンドウを修正します（例：00：00-23：00 UTC）。
2.このウィンドウのすべての決済/キャプチャされたトランザクションはバッチになります。
3.返品、チャージバック、修正はパッケージに集計され、総額と純資金を計算します。
4.カットオフ時に決済ファイルが生成され、T+Nタイマーが登録前に開始されます。

重要：キャプチャなしの承認はパッケージに含まれていません。結論を取り消しました-またありません。

3）決済の種類： 総対ネット、準備金、手数料

グロス決済-グロスキャプチャ量が転送されます（別の手数料を差し引いて）。
ネット決済-プロバイダは手数料、チャージバック、払い戻し、ローリングリザーブを保持し、純額をリストします。
ローリングリザーブ-リスクをカバーするために、N日間の売上高の％（例えば、180日間は10％）を源泉徴収します。
負のキャリーオーバー-「ネット」が1日あたりマイナスになると、赤字が転送され、次のサイクルで支払われます。

推薦：両方の平面の店舗復号化-運用総額（トランザクションによる）と資金調達ネット（プロバイダファイルによる）。

4）タイムゾーン、ローカル出力およびDST

カットオフは、プロバイダのタイムゾーンによって決定されます。
DST（夏時間）を考慮してください-スライスは現地時間に対して± 1時間シフトできます。
受信銀行の管轄内の祝日/週末は、T+NのNに影響します（例えば、T+2の銀行日は休日の周りにT+4になります）。
練習：UTC内のすべての技術時間を正規化し、'provider_tz_cutoff_at'と'local_tz_posted_at'を同時に保存します。

5）決済カレンダー（資金調達カレンダー）とSLA

四半期の決済のカレンダーを作成します：
  • 各方法/PSPのための締切りの時間そしてtz、
  • 標準的なT+Nおよび例外（休日）、
  • 予想金額（予測）、
  • SLAレシート：例えば「、12：00 Europe/Kyiv on day T+2」。

SLAの偏差→Ops/Financeへのアラートとチケット。

6）ネット預金とアウトプットとの関係

ND（ネット貢献）は決済取引にカウントされます（関連記事を参照）。
結論（引き出し）は、PSPからの入金には参加しませんが、商人のキャッシュデスクに影響を与えます。
流動性計画：決済による流入-支払い/税金/運営費用による流出。

7）和解とプロバイダーのアーティファクト

各バッチのための最低セット：
  • 'batch_id/ settlement_id'、 tzプロバイダのカットオフ日、
  • 'capped_deposits'、' refunds'、'chargeback_debits'、 'chargeback_credits'、' fees'、'reserve_delta'、'net_funding'、
  • メソッド/マーチャントアカウント（'MID'、 'descriptor'、 'MCC'）による復号化、
  • トランザクション参照（'provider_tx_id'、 'rrn'、 'arn'-カードの場合）、
  • file （s）： CSV/XML/JSON+human readable statement （PDF/HTML）。
和解は2つの方向に進みます：

1.トランザクションからファイルまで（ファイルにあると思ったものはすべて？）

2.ファイルからトランザクション（ファイル内のすべてが店頭にありますか？ステータスは一致しますか？）

8）支払の柵の指定（一般に）

マップ：頻繁なプレゼンテーション遅延シナリオ；遅い'チャージバック'が可能です（ケースの場合は120〜540日まで）。交換&スキーム料金はファイルに表示され、NDでは差し引かれません。
SEPA/ACH：バッチは銀行窓によって決まります；キャンセル/返品には独自のコードがあります。
Banking/A2Aを開く：T+0/1、しかし、ファイルはポストファクトムに行くことができます。マッチのための厳密なRPP/Unique IDの必要性。
RTP/Instant：お金はすぐに来るが、レポートファイルは予定通りです。
Crypto：オンチェーン決済インスタント、プロバイダは'ペイアウトウィンドウ'を作ります。'fx_at_settle'を保存します。

9）会計（FI/会計）

9.1.Accrualとキャッシュメソッド

マネジメントレポートでは、しばしばaccrualが使用されます。"settled_at'の時点で収益/動きを認識します。
Treasury/DDS-cacheメソッド：領収書'funded_at'の事実を認識します。

9.2.典型的な配線（簡略化）

'DEPOSIT_CAPTED'の場合：
  • JT： PSPとの決済における現金（AR： PSP）
  • KT：プレイヤーコミットメント（財布/プレーヤーバランス）
資金調達（ネット）が到着したとき：
  • Dt：銀行（レジ係のオフィス）
  • Kt： PSPで決済の現金
  • JT：費用（PSP料金）、JT：規定（変更された場合）

traceのためにsheafのtransaction_id→batch_id→funding_id'を保存します。

10）リスク管理とアラート

欠落したファイル：X： YY-P1の前に決済ファイルはありません。
資金調達遅延：T+N期限切れ、お金なし-P1。
デルタしきい値：分散'our_gross'と'file_gross'> 0。5％-P2；範囲外の'fees'-P2。
ネガティブキャリーオーバー：一連のネガティブネットパック-調査。
休日の影響：カレンダーを考慮した自動予測。事実が予測の80％未満の場合-チケット。

11）データモデル（簡略化）


finance. payment_transactions (
id, user_id, method, provider, mid, mcc,
type, status, amount_original, currency_original,
amount_reporting, reporting_currency, fx_rate_at_settle,
authorized_at, captured_at, settled_at,
provider_tx_id, arn, rrn, meta
)

finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)

finance. funding_receipts (
funding_id, provider, bank_account,
received_at, value_date,
currency, amount_received,
batch_id, statement_ref, meta
)

-- Binding showcase:
finance. recon_links (
id, transaction_id, batch_id, funding_id, link_type, created_at
)

12） SQLテンプレートの例

12.1.カットオフレコーディング

sql
INSERT INTO finance. settlement_batches (
batch_id, provider, mid, method,
provider_cutoff_at, provider_tz,
period_start_at, period_end_at,
gross_captured, refunds, cb_debits, cb_credits,
fees, reserve_delta, net_funding_expected,
file_name, file_hash, file_type, meta
)
VALUES (:batch_id,:provider,:mid,:method,
:cutoff_at,:tz,
:start_at,:end_at,
:gross,:refunds,:cb_deb,:cb_cr,
:fees,:reserve_delta,:net_expected,
:file_name,:file_hash,:file_type,:meta::jsonb);

12.2.トランザクションからファイルへの調整

sql
WITH tx AS (
SELECT provider, mid, method,
SUM(CASE WHEN type='DEPOSIT' AND status IN ('CAPTURED','SETTLED') THEN amount_reporting ELSE 0 END) AS gross,
SUM(CASE WHEN type='REFUND' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS refunds,
SUM(CASE WHEN type='CHARGEBACK_DEBIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_deb,
SUM(CASE WHEN type='CHARGEBACK_CREDIT' AND status='SETTLED' THEN amount_reporting ELSE 0 END) AS cb_cr
FROM finance. payment_transactions
WHERE settled_at >=:start_at AND settled_at <:end_at
GROUP BY 1,2,3
)
SELECT b. batch_id, b. provider, b. mid, b. method,
tx. gross AS our_gross, b. gross_captured AS file_gross,
tx. refunds AS our_refunds, b. refunds AS file_refunds,
tx. cb_deb AS our_cb_deb, b. cb_debits AS file_cb_deb,
tx. cb_cr AS our_cb_cr, b. cb_credits AS file_cb_cr
FROM finance. settlement_batches b
LEFT JOIN tx
ON tx. provider=b. provider AND tx. mid=b. mid AND tx. method=b. method
WHERE b. provider_cutoff_at BETWEEN:cutoff_from AND:cutoff_to;

12.3.収益予測（キャッシュフローT+N）

sql
SELECT provider, mid, method,
DATE(provider_cutoff_at) AS t_date,
net_funding_expected,
CASE
WHEN EXTRACT (DOW FROM provider_cutoff_at)::int IN (5,6) THEN provider_cutoff_at + INTERVAL '3day' -- conditional example
ELSE provider_cutoff_at + INTERVAL '2 day'
END AS expected_funding_at
FROM finance. settlement_batches
WHERE provider_cutoff_at BETWEEN:from AND:to;

13）プロセスとSLO

SLO 1：インポート決済ファイル-T+0、まで08：00ヨーロッパ/キエフ。

SLO 2： 最初の和解-09：00まで、分散>0。5%.

SLO 3：キャッシュフロー予測の更新-午前10時まで。
SLO 4：1日の終了-すべての資金調達試合はDWHに導かれます。

14）エッジケースとそれらを処理する方法

遅いプレゼンテーション：トランザクションが次のバッチに入った-「ソースの事実」（'presented_in_batch_id'）を保持します。
部分的なキャプチャ：承認ごとに複数のキャプチャ-バッチで正しく集計します。
Multi-MID： 1つのプロバイダ、地理/ブランド別の異なるMID-1つのバッチに混在しないでください。
再処理：ファイルがジャムされたとき-'batch_revision'と完全な再検討のバージョン。
FXレース：コース-'sreted_at'；別の通貨での資金調達-'fx_at_funding'とデルタを開始します。

15）ダッシュボードとKPI

資金調達ETA：レシートの予想日時と実際の日時。
ヒットレートSLA：時間通りに到着するファイルの割合。
プロバイダ、メソッド、MIDによるDelta gross/net。
手数料量の％、準備残高、負のキャリーオーバーストリーク。
休日の影響：休日との週ごとの実際のvsの予測。

16）ベストプラクティス（短い）

1.UTCまでの時間を正規化しますが、カットオフのprovider_tzを維持します。
2.別の運用総額と資金調達ネット；NDと資金を混同しないでください。
3.銀行の休日を事前に入力した資金調達カレンダーを実装します。
4.SLA/deltasへの決済ファイル+アラートのインポートと調整を自動化します。
5.batch_revisionと決定論的再処理を実装する。
6.「トランザクション↔バッチ↔資金調達」リンク。
7.ARN/RRNとカード取得フィールドを保存する-紛争にとって重要です。
8.週末/祝日、準備金、手数料を考慮したキャッシュフロー予測。

17）実装チェックリスト

データと図

  • 'payment_transactions'、' settlement_batches'、'funding_receipts'、'recon_links'をТаблицыします。
  • タイムゾーンフィールドはUTC+provider_tzです。
  • FX： 'fx_rate_at_settle'、 'fx_at_funding'。

インポートと検証

  • CSV/XML/JSONパーサ+ファイルハッシュ。
  • 金額/通貨/日付の検証。'provider_tx_id/ARN'にマッチします。
  • ハンドラ「late presentation」、 「partial capture」、 「reversal」。

操作とアラート

  • SLAモニターのカットオフ、ファイルの欠落、資金調達の遅れ。
  • デルタしきい値アラート（総額、手数料、ネット）。
  • 休日の影響と負のキャリーオーバーレポート。

18） FAQ

Q： T+2がT+4になったのはなぜですか？
A：特派員銀行または受信銀行で週末/休日がありました。см.資金調達カレンダー。

Q：ネットの計算よりネットファイルの方が少ないです。何を見ますか？
A：料金、reserve_delta、遅延払い戻し/チャージバック、コースの正確性を確認してください。

Q：あなたはどのように暗号をアカウントしていますか？
A： 'sreted_at'と同等のフィアットによって；資金はUSDT/fiatに来ることができます-別の'fx_at_funding'を維持してください。

Q：すべてのプロバイダに共通のカットオフを1つ持つことは可能ですか？
A：いいえ、各PSPにはtz/hourがあります。スライスの上に集約ディスプレイを作成します。

概要

決済サイクルとカットオフは、金融ロジスティクスの「骨格」です。T+N、タイムゾーン、休日、準備金、手数料の正しい会計が可能：
  • プロバイダを正確に検証し、
  • 流動性を予測し、支払いをカバーします、
  • SLAに準拠し、運用上のリスクを低減します、
  • 金融やコンプライアンスと同じ言語を話すことができます。

単一の資金調達カレンダー、厳格なデータモデル、自動化された調整を実装することで、キャッシュフローを予測可能かつ管理可能にします。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします！

Telegram
@Gamble_GC
統合を開始

Email は 必須。Telegram または WhatsApp は 任意。

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式：+国番号と電話番号（例：+81XXXXXXXXX）。

ボタンを押すことで、データ処理に同意したものとみなされます。