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步调和明确的审计跟踪。因此，您可以降低风险，支持成本和争议量，同时保持用户的信任。