對賬付款和PSP報告

TL;DR

對賬是使用PSP/收購商/銀行報告對您的Ledger和事件（auth/capture/refund/payout）進行每日自動縫合。成功的關鍵是： 單一的數據模型，確定性匹配密鑰，嚴格的冪等性，總和/FX/時間的推力，有爭議案件的DLQ隊列以及自動校正的花花公子。KPI: Recon Mismatch Rate↓, Aging of Unreconciled↓, Auto-match%↑.

1）為什麼，我們檢查什麼

目標：確認收入和傭金，發現倍數/損失，在日子和貨幣上正確定位，對來源進行再融資控制，與審計/監管機構保持一致。

對照對象：

Deposits: `auth → capture → settle`
Refunds：完整/分區、狀態和金額
Payouts/Withdrawals：方法外付款
Fees＆Adjustments：PSP傭金，互換計劃，校正
Chargebacks/Disputes：超出您的計劃
FX/轉換：課程,利差,固定時刻

2）數據來源

Internal Events（您的）：事件總線/Kafka, 「payments_flat」、「refunds」、「payouts」,您的Ledger。

PSP Reports (SFTP/API/webhook dump):

交易（操作摘錄）

Settlements/Batches（T+N入學人數細目）

Fees/Statements（傭金，調整）

Chargebacks/Disputes

Payouts/OCT/RTP/SEPA登記冊

銀行統計：MT940/CSV/ISO20022 CAMT，貸款整頓。

💡 存儲：landing → raw → normalized → matched.所有傳入文件-具有校驗和和轉換。

3）映射鍵（匹配鍵）

優先鍵樹（精度降低）：

1.provider_txid ↔ provider_txid（唯一PSP ID）

2.idempotency_key/ merchant_reference（如果PSP穩定）

3.(amount, currency, timestamp_bucket, last4/bin, auth_code)

4.Fuzzy層：± tolerans的總和/時間，BIN/issuer國家，狀態家庭

建議：

同時存儲兩者：「payment_id」和「provider_txid」。
對於partial/refund-添加「sequence_index」或「refund_line_id」。
Для payouts — `payout_batch_id + line_id`.
對於FX是「exec_id」（轉換）和課程來源。

4）數據模型（歸一化層）

json
{
"source": "INTERNAL    PSP_TX    PSP_SETTLEMENT    BANK",
"provider": "Acquirer_A",
"payment_id": "pay_123",
"provider_txid": "psp_tx_789",
"kind": "AUTH    CAPTURE    REFUND    PAYOUT    FEE    SETTLEMENT    CHARGEBACK",
"sequence": 0,
"amount": 100. 00,
"currency": "EUR",
"fee_amount": 1. 20,
"fx_rate": 1. 0000,
"fx_src": "PSP    ECB    BANK",
"status": "APPROVED    CAPTURED    SUCCESS    FAILED    SETTLED",
"event_ts": "2025-11-03T12:00:00Z",
"settlement_date": "2025-11-05",
"account": "PSP_MERCHANT_CARD_A",
"matching_keys": {
"provider_txid": "psp_tx_789",
"merchant_ref": "mr_456",
"idem_key": "idem_abc"
},
"hash_row": "sha256(...)"
}

5）核對過程（ETL/編排）

1.Ingest：拿起PSP報告（SFTP/API）,驗證方案/簽名,保存在「原始」中。
2.Normalize：將字段映射到統一格式（currency ISO、decimals、UTC時區）。
3.Match：一種用於與tolerans進行密鑰樹匹配的算法。
4.後對決：我們形成diff（差異）和journal entries for leder/校正。
5.定位：縫合「PSP_SETTLEMENT ↔ BANK」（入賬），分布在白天/蹦床上。
6.報告：dashboard，Alerts；在DLQ中因手動分析/自動重新設計而引起爭議。

相同性：每個文件/頁面為「ingest_id」。重新加載不會改變結果。

6）Tolerance（tolerances）和規則

時間：「± 15分鐘」用於交易，「± 1天」用於定居。
總和：'≤ 0。FX/fee差異的01'基本貨幣或'≤ 10 bps'。
FX：如果匯率來源不同，我們允許與銀行發生差異；捕獲「fx_src」。
Partial/Multiple：分區/返還線上的總和應等於內部余額。

7）差異處理（diff taxonomy）

diff類型	說明說明	行動
MISSING_INTERNAL	在PSP中，我們沒有	創建orphan case,檢查webhooks/retrai
MISSING_PSP	我們有，PSP沒有	檢查狀態/重復,PSP聯系人
AMOUNT_MISMATCH	金額不同>tolerance	自動校正/日誌,必要時升級
FEE_MISMATCH	各委員會之間的差異	將PSP視為「真相」（政策）或要求信用筆記
STATUS_DRIFT	我們有CAPTURE，PSP有AUTH	檢查webhooks捕獲/定位
DUPLICATE	線條雙打	「provider_txid/idempotency_key」的dedup'
FX_DRIFT	課程不同	設置官方來源,調整P&L
REFUND_OVER	Refund > captured	緊急塊,手動分析,反向校正日誌

8） Ledger&Accounting（布線）

Capture: `DR Accounts Receivable / CR Revenue` и `DR Cash (upon settle) / CR Accounts Receivable`

Fee: `DR Fees / CR Cash or Payable`

退款： 反向布線與部分成正比

Chargeback： 單獨賬戶和爭議準備金

FX reval： 根據「fx_src_policy」課程每天重新評估AR/緩存余額'

9） KPI和目標

Auto-match%=自動映射行/所有行（目標≥ 95%）

Recon Mismatch Rate=diff行/所有行（≤ 1-2%）

Aging of Unreconciled： p50/p95 days in DLQ （p95 ≤ 3 dn）

Settlement Timeliness： 與D-Day銀行縫合的蹦床比例（≥ 99%）

Fee Accuracy： 提供商傭金的差異（≤ 0.1%的營業額）

Duplicate/Orphan Incidents： 瞄準0

10） SQL切片

10.1基本provider_txid匹配

sql
WITH i AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM internal_norm
),
p AS (
SELECT provider, provider_txid, kind, amount, currency, event_ts
FROM psp_norm
)
SELECT
COALESCE(i. provider_txid, p. provider_txid) AS txid,
COALESCE(i. provider, p. provider) AS provider,
i.kind AS kind_internal, p. kind AS kind_psp,
i.amount AS amount_internal, p. amount AS amount_psp,
i.currency, p. currency,
CASE
WHEN i.provider_txid IS NULL THEN 'MISSING_INTERNAL'
WHEN p. provider_txid IS NULL THEN 'MISSING_PSP'
WHEN ABS(i. amount - p. amount) > 0. 01 THEN 'AMOUNT_MISMATCH'
ELSE 'MATCHED'
END AS recon_status
FROM i
FULL OUTER JOIN p USING (provider, provider_txid);

10.2 Settlement ↔ Bank

sql
SELECT s. settlement_date, s. batch_id, s. currency,
s. amount_settled, b. amount_bank,
(b. amount_bank - s. amount_settled) AS diff
FROM psp_settlements s
LEFT JOIN bank_statements b
ON b. value_date = s. settlement_date
AND b. currency = s. currency
AND ABS(b. amount_bank - s. amount_settled) <= 0. 5;

10.3 Aging DLQ

sql
SELECT diff_type,
COUNT() AS cnt,
PERCENTILE_CONT(0. 5) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p50_age,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY AGE(NOW(), created_at)) AS p95_age
FROM recon_dlq
GROUP BY diff_type
ORDER BY cnt DESC;

11）鐵路/案例功能

地圖：「auth」和「capture」之間的差異，後來的「settlement」調整，間距/電路匹配是單獨的線條。
A2A/Open 銀行/RTP：即時確認，但「反向」是可能的；鉆探「payout」和退貨。
錢包：通常是完美的「provider_txid」，快速的「refund」；跟隨球隊。
憑證：沒有對稱的返還-在政策和報告中正確反映。
Crypto：ake-chane hash ↔ provider_txid；N confirms；考慮到網絡的傭金和可能的重建；課程在轉換時。

12）操作花花公子

MISSING_INTERNAL激增：檢查webhook/Retraes的丟失，重新播放ingestion，啟用polling API。
AMOUNT_MISMATCH一個PSP：比較四舍五入/VAT/fee模型，要求糾正聲明。
定居點不與銀行縫合：檢查價值日期，銀行傭金，T+N延遲；暫時放入「Suspense帳戶」。
質量REFUND_OVER：立即停止自動反射，同步性審計，手動校正。
FX_DRIFT：記錄政策課程來源（ECB/PSP/BANK），重新計算P＆L差額。

13）控制與安全

等效性ingestion：「file_id+checksum」和下載日誌。
可用性（RBAC）和4眼控制：手動校正/日記接線。
審核跟蹤：所有比賽/演示/更正-在不變日誌中。
數據質量：電路，強制性字段，貨幣/滑軌驗證。

14）Dashbord和Alerts

小部件：自動匹配%、Mismatch Rate、Aging DLQ、Settlement Timeliness、Fee Accuracy、頂級PSP diff、diff類型卡。

Alerts：

「Auto-match% <90%」按供應商/日→ P1
'Aging p 95>3 dn' → P2
`AMOUNT_MISMATCH spike` → P1
按金額/貨幣計算的「Bank≠Settlement」 → P0

15）測試案例（UAT/Prod）

1.重新加載同一文件→ 0個副作用（等效性）。
2.部分重構（3行）→總和匹配，順序匹配。
3.FX轉換：tolerance內的課程差異→正確的匹配。
4.報告中的重復provider_txid → dedup和alert。
5.失蹤的webhook捕捉→ polling關閉插槽，狀態對齊。
6.帶有fee線路的定居點戰鬥在Revenue/Fee/Net上→正確的細分。

16）經常出錯以及如何避免

比較基的混合（compare'attempt'vs' capture）→保持相同的粒度。
博客中缺少「provider_txid」 →比賽的準確性丟失。
忽略時間區→定點日期的偏移。
沒有DLQ/轉發 →「永恒」差異。
沒有日誌的手動編輯→審計不一致。
模糊的tolerans →羽毛比賽或「all in DLQ」。

17）實施控制清單

統一歸一化方案和PSP/方法/帳戶指南
映射密鑰樹（txid → merchant_ref → fuzzy）
Tolerans 按金額/時間/FX，課程來源政策
Idempotent ingestion, DLQ, retraies, Alertes
Settlement↔Bank核對，Suspense帳戶政策
Dashbord KPI,財務/審計報告
Playbooks和SLA分析diff案例

總結

和解是一門工程學科：正常化，可靠的密鑰，tolerans，自動匹配和透明校正。有了這樣的輪廓，您將穩定收入和傭金，盡量減少「黑洞」，加快周期關閉並進行審計而不會感到痛苦：Auto-match%↑，Mismatch↓，Aging↓。

對賬付款和PSP報告

TL;DR

總結

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案