same-method rule and return to source

1) The essence and why it is needed

• AML/ATF: do not turn the return into an "anonymous payout tunnel" on another prop.
• Fraud/ODR reduction: Less "money went the wrong way" controversy.
• Operating system: simplified reconciliation, fewer manual cases.
• Rule cards: compliance with network requirements "credit back to original funding instrument."

2) Cards (Visa/Mastercard/...): how it works

Void/Authorization Reversal (before clearing): authorization rollback - money will "defrost" on the same card.
Refund (Credit/Presentment): after clearing - credit for the same PAN/DPAN.
Apple/Google Pay: return to DPAN/network token → the issuer routes to the current card (including when reissued).
Push-to-Card OCT - not equal to refand: this is a payment to the card; Use only when exception and KYC are committed.

• Closed/reissued card - the issuer, as a rule, will "redirect" the loan to the legacy card/account. The refund is still a helmet as a refund.
• Return> original payment - prohibited; make a partial refund, the balance through the authorized payout rail after KYC/SoF.
• Split-tender (payment from 2 sources): returns in the same proportion per source.

3) Bank A2A (SEPA/ACH/FPS/RTP/PIX)

Ideal: credit transfer to the same IBAN/account where the replenishment came from (or to the UPI/PIX identifier of the sender).
ACH (US): "refund to source" is usually implemented as a loan for the same routing + account; returns (R-codes) are not refand, but rail failure/return.
RTP/FPS/PIX: fast and final; if the original payment on these rails - the refund often goes as a new loan to the same recipient/alias (this is a normal same-method implementation).

• The account is closed/details are invalid - alternative rail is allowed after confirmation of the beneficiary (micro-deposit/test payout) and step-up KYC.
• Cross-border SWIFT: if the original payment was local and the refund requires an x-border - record additional FX/fee disclosure and consent.

4) e-wallets and APM (Skrill/Neteller/Payz/PayPal and local)

Rule: return to the same wallet/account from which the deposit came.
Top-up from the card inside the wallet: the refand is returned to the wallet, and not directly to the user's card (provider policy).
Vouchers/eCash (Paysafecard, Neosurf, Multibanco-ref): more often non-refundable to the source - a loan is made to the wallet/merchant balance (or an alternative payout at KYC).

• Blocked/lost access - alternate rail after EDD/SoF and proof of ownership.
• Partner delimiters (AUPs) - returns are only possible in the form of store-credit/internal balance.

5) Vouchers/cash/quasi-cash

1. Cancellation before the issue of goods/credit - ok, nothing is translated.

2. After enrollment - return to the internal balance/wallet, followed by withdrawal only to a registered bank account after KYC/SoF (no "cash back").

Specify transparently in ToS: voucher refills are not returned for a voucher.

6) Partial returns, over-limit and multi-source

Partial refund: to the original source up to the original payment amount. Several partial ones are acceptable.
Amount to be returned> deposited by the source - balance through the authorized payout-rail (KYC/SoF/limits).
Several sources (for example, 70% card + 30% wallet): refands proportionally back to the same sources.

7) Time windows and priorities

Priority 1: 'void/authorization reversal' (if possible) - the "cleanest" rollback.
Priority 2: 'refund to source' on the original rail.
Priority 3: alternative payout (only for fixed exception + step-up and audit).

8) policy engine: how to design

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

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

2. Otherwise, if'isRefundableToSource (paymentId) '→ Refund (sourceRef).

3. If 'sourceRef invalid/closed' → Step-Up (KYC/SoF) → suggest payout rails on the allow list (bank/Push-to-Card/e-wallet) → the reason log.

4. If voucher/eCash → credit int. balance sheet; direct reverse is not possible.

5. Split-tender → a refand for each 'sourceRef' in its share.

6. Hard-deny under sanctions/PEP/age/geo prohibitions.

Non-functional: idempotency ('refundKey'), web hooks, explain logic (why the method was chosen), rule versioning.

9) Statuses, reconciliation and artifacts

Return statuses: 'requested → pending → refused | failed | canceled'.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.

Recon: daily auto-recon by PSP/bank registers + full-recon; alerts: "success without a registry," "double refund," "return to another source."

10) UX and Communications

On the return screen, show the addressee: "Return to card • • 3456/wallet @ user/DE account...."

If an exception is required, we explain: "The source is not available. For your security, we will offer a return to your personal bank account after confirming the data (≈N minutes/hours). "

Checks/letters: amount, date, method, 'refundId', UTR/ARN, ETA (cards - up to X days, A2A - T + 0/1, wallets - instantly/T + 1).
FAQ: vouchers are non-reversible; Apple/Google Pay are automatically returned to the linked card.

11) Exception matrix (signals and steps)

12) FX and currency

Return in the original transaction currency; if conversion is needed - use the same FX source (PSP/bank) and show rates/fees.
Do not worsen the economy for the client (do not return in a different currency without explicit consent).

13) Features for iGaming

Bonus/freespin returns: rules of the game> return policy; money only in part of the funds deposited.
Self-exclusion/RG: when blocking an account - return the balance to the source; alternative payments are prohibited until inspections are completed.
Quasi-cache: a strict ban on "overflow" from a card/voucher to a new prop under the guise of a refand.

14) KPI and control

Refund success rate (online → registry enrollment).
Median/P95 time-to-refund by method.
Alternate-payout rate - keep <X%.
ODR after return (repeated disputes).

Reconciliation errors: "double refund," "wrong source."

Support load on returns/1k orders.

15) Implementation checklist

1. Source directory (card/A2A/wallet/voucher) and their RTS suitability statuses.
2. Policy engine: void→refund→alt rules -payout, explain-logs, versioning.
3. Integration of PSP/banks: 'void/refund', web hooks (signature/NMAS), idempotency.

4. Recon: daily + full, alerts to out of sync and "refund to another source."

5. UX: explicit display of return destination, ETA, reasons for exceptions; Letter/check templates

6. AML/KYC: step-up for alternative payouts, SoF/SoW, deny cases.
7. Test kit: void window, partial refund, split-tender, closed card/IBAN, voucher, Apple/Google Pay, PSP degradation.

Resume Summary

The same-method/refund-to-source rule is key to security, compliance, and predictability. Make void → refund → (strictly if necessary) alternative payout, keep the rules in the policy engine with explain logs, ensure idempotency, webhooks and recon, transparently communicate the addressee and ETA. Exceptions - only with step-up KYC/SoF and clear audit trail. This way you reduce risks, support costs and disputes while maintaining user confidence.