same-method規則與返回源

1）底線以及為什麼需要它

• AML/ATF：不要將退貨變成另一個道具上的「匿名付費隧道」。
• Frod/ODR的減少：「錢錯了」的爭議較少。
• 操作：簡化對賬,減少手動案例。
• 卡規則：符合網絡要求「信用回到原來的資金工具」。

2）卡（Visa/Mastercard/……）： 如何工作

Void/Authorization Reversal（清算前）：回扣授權-金錢在同一張卡上「解凍」。
退款（信用/提供）：清算後-同一PAN/DPAN的貸款。
Apple/Google Pay：退回DPAN/網絡令牌 →發行人路由到當前卡（包括重新發行時）。
推到卡OCT-不等於反射：這是卡上的付款；僅用於已記錄的異常和dop. KYC。

• 已關閉/重新發行卡-發行人通常會「重定向」信貸到繼承卡/帳戶。返回仍然是頭盔作為還款。
• 退款>原始付款-禁止；在KYC/SoF之後通過允許的付費導軌進行部分還款，其余部分。
• Split-tender（從2個來源付款）：每個來源的退款比例相同。

3）銀行A2A（SEPA/ACH/FPS/RTP/PIX）

理想：將信用卡轉賬到充值來源的IBAN/帳戶（或發件人的UPI/PIX ID）。
ACH（US）：「來源返還」通常是作為相同的路由+帳戶的信用來實現的；退貨（R碼）不是退貨,而是導軌故障/退貨。
RTP/FPS/PIX：快速和決賽；如果這些軌道的原始付款-退款通常作為對同一收件人/alias的新貸款（這是正常的same-method實現）。

• 帳戶已關閉/道具無效-在受益人確認（micro-deposit/test payout）和KYC暫停後允許使用替代導軌。
• Cross-border SWIFT：如果原始付款是本地付款,並且退款需要x-border-請記錄額外的FX/fee disclosure和同意。

4）電子錢包和APM（Skrill/Neteller/Payz/PayPal和本地）

規則：退回到存款來自的同一錢包/帳戶。
從錢包內的卡中脫穎而出：反射返回錢包，而不直接返回用戶卡（提供商策略）。
代金券/eCash （Paysafecard, Neosurf, Multibanco-ref）：通常不退還來源-向商人的錢包/資產負債表（或KYC的替代付款）貸款。

• 鎖定/丟失訪問-EDD/SoF和所有權確認後的替代導軌。
• 合作夥伴限制器（AUP）-僅以商店信用/內部平衡的形式返回。

5）憑證/現金/準緩存

1.在發貨/貸款之前取消-好的，什麼都不會翻譯。

2.入賬後-退回內部資產負債表/錢包，然後僅退回KYC/SoF後的命名銀行帳戶（沒有「現金退回」）。

在ToS中透明指定：代金券充值不會返回代金券。

6）部分退貨，超限和多源

部分還款：從原始來源到原始付款額。一些部分是允許的。
返回金額>輸入的來源是通過允許的付費導軌（KYC/SoF/限制）的余額。
多個來源（例如70％的地圖+30％的錢包）：反射成比例地回到相同的來源。

7）時間窗口和優先事項

優先級1：「void/authorization reversal」（如果仍然可以的話）是最幹凈的回滾。
優先級2：源導軌上的「重新啟動到源」。
優先級3：備用付款方式（僅適用於已記錄的例外情況+step-up和審核）。

8）解決方案引擎（policy engine）： 如何設計

Входные данные: `paymentId`, `sourceType` (card/A2A/wallet/voucher), `sourceRef` (PAN token, IBAN, walletId), `amount`, `fx`, `status`, `settlementState`, `kycLevel`, `riskScore`, `beneficiaryId`.

1.Если `canVoid(paymentId)` → Void.

2.否則，如果「isRefundableToSource（paymentId）」→ Refund（sourceRef）。

3.如果「sourceRef invalid/closed」 → Step-Up（KYC/SoF）→ 通過allow list（銀行/推到卡/電子錢包）提供付費鐵路→原因日誌。

4.如果voucher/eCash →內部信用。平衡；不可能直接相反。

5.Split-tender在其份額中→每個「sourceRef」的重構。

6.制裁/RER/年齡/地域禁令中的硬性禁令。

非功能性：等效性（「refundKey」），Web hooks的去勢性，explain-Logic（為什麼選擇該方法），規則轉換。

9）狀態，對賬和人工制品

返回狀態：「請求→ pending → refunded | failed | canceled」。

Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.

Recon：根據PSP/bank+full recon註冊表進行的每日自動記錄；Alerta：「沒有註冊的成功」，「雙重返還」，「返回其他來源」。

10） UX和通信

在退貨屏幕上,顯示收件人： 「退貨到卡•3456/錢包@user/帳戶 DE……」

如果需要異常,我們解釋說： "源源不可用。為了確保您的安全，我們將在確認數據（≈N分鐘/小時）後提供退款到命名銀行帳戶。"

支票/信件：金額、日期、方法、「refundId」、UTR/ARN、ETA（卡-最多X天，A2A-T+0/1，錢包-瞬間/T+1）。
常見問題：憑證是不可逆的；Apple/Google Pay自動返回綁定卡。

11）異常矩陣（信號和步驟）

12）外匯和貨幣

以交易原始貨幣退款；如果需要轉換-使用相同的FX源（PSP/銀行）並顯示課程/傭金。
不要使客戶的經濟狀況惡化（未經明確同意不得以其他貨幣退款）。

13） iGaming的功能

獎金/獎金退款：遊戲規則>退款政策；只提供部分資金。
Self-exclusion/RG：在鎖定帳戶時-將余額退還給源；在檢查完成之前禁止其他付款。
準緩存：嚴格禁止以重新裝配為幌子從卡/憑證到新道具的「溢出」。

14） KPI和控制

退款成功率（在線註冊→註冊）。
Median/P95方法進行計時。
Alternate-payout rate（例外比例）-保持<X%。
返回後的ODR（重復爭議）。
對賬錯誤：「雙重返還」，「錯誤的來源」。
支持按退貨/1k訂單加載。

15）實施支票

1.源目錄（card/A2A/wallet/voucher）及其適合RTS的狀態。

2.策略引擎： 規則void→refund→alt-payout, explain-logs, version.

3.PSP/銀行集成：「void/refund」，Web hooks（簽名/NMAS），等效性。
4.Recon： daily+full、Alerts on rushcherons和「refund to other source」。
5.UX：明確顯示退貨收件人ETA，例外原因；信件/支票模板。
6.AML/KYC：替代付款，SoF/SoW，deny案例的步驟。
7.測試套件：void窗口,部分返還,split-tender, 封閉卡/IBAN,憑證,Apple/Google Pay, PSP降級。

二.總結

Same-method/refund-to-source規則是安全性、合規性和可預測性的關鍵。做一個void → refund →（嚴格在需要時）替代支付，保持策略引擎中的規則與explain-Logs，確保等效性，webhook和recon，透明地通信目標和ETA。例外情況僅適用於KYC/SoF步調和明確的審計跟蹤。因此，您可以降低風險，支持成本和爭議量，同時保持用戶的信任。