Règle same-method et retour à la source

1) L'essence et pourquoi il est nécessaire

• AML/ATF : ne pas transformer un retour en « tunnel payout anonyme » en un autre accessoire.
• Baisse de la frod/ODR : moins de controverse « l'argent est parti au mauvais endroit ».
• Opération : rapprochement simplifié, moins de cas manuels.
• Règles de cartes : conformité aux exigences du réseau « credit back to original funding instrument ».

2) Cartes (Visa/Mastercard/...) : comment ça marche

Void/Autorisation Reversal (avant compensation) : annulation de l'autorisation - l'argent sera « décongelé » sur la même carte.
Refund (Credit/Presentment) : après compensation, crédit pour le même PAN/DPAN.
Apple/Google Pay : retour au DPAN/jeton réseau → l'émetteur route vers la carte actuelle (y compris lors du transfert).
Push-to-Card OCT - pas égal à refand : c'est un paiement par carte ; à utiliser uniquement en cas d'exclusion et de dope. KYC.

• La carte est fermée/transférée - l'émetteur va généralement « rediriger » le crédit vers la carte/compte héritier. Le retour est quand même un casque comme un refund.
• Retour> paiement initial - non autorisé ; refund partiel, le reste est par le rail de payout autorisé après KYC/SoF.
• Split-tender (paiement à partir de 2 sources) : remboursements dans la même proportion par source.

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

Idéal : virement sur le même IBAN/compte d'où vient la reconstitution (ou sur l'ID UPI/PIX de l'expéditeur).
ACH (US) : le « refund to source » est généralement réalisé comme un crédit pour le même routing + compte ; les retours (codes R) ne sont pas un refand, mais une panne/retour de rail.
RTP/FPS/PIX : rapide et finale ; si le paiement initial sur ces rails est un retour souvent comme un nouveau prêt au même bénéficiaire/alias (c'est la réalisation normale de same-method).

• Le compte est fermé/les accessoires ne sont pas valides - un autre rail est autorisé après confirmation du bénéficiaire (micro-dépôt/test payout) et step-up KYC.
• Cross-border SWIFT : si le paiement d'origine était local et que le retour nécessite un x-border, enregistrez la disclosure supplémentaire FX/fee et le consentement.

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

Règle : retour au même portefeuille/compte à partir duquel le dépôt est venu.
Top-up de la carte à l'intérieur du portefeuille : refand retourne au portefeuille et non directement à la carte utilisateur (politique du fournisseur).
Bons/eCash (Paysafecard, Neosurf, Multibanco-ref) : plus souvent non remboursables par source - un prêt à portefeuille/bilan du merchant (ou un paiement alternatif sous KYC) est fait.

• Accès bloqué/perdu - rail alternatif après EDD/SoF et confirmation de propriété.
• Limiteurs d'affiliation (AUP) : le remboursement n'est possible que sous la forme d'un solde store-credit/interne.

5) Bons/cash/quasi cache

1. Annulation avant l'émission de la marchandise/crédit - ok, rien n'est transféré.

2. Une fois crédité - retour au solde/portefeuille interne, suivi d'un retrait sur un compte bancaire nommé seulement après KYC/SoF (pas de « cash back »).

Indiquer de manière transparente en ToS : les recharges de bons ne sont pas remboursées sur le bon.

6) Retours partiels, superlimites et multi-sources

Refund partial : à la source d'origine jusqu'au montant du paiement d'origine. Quelques partielles sont admissibles.
Le montant de retour> versé par la source est le solde via le rail payout autorisé (KYC/SoF/limites).
Plusieurs sources (carte à 70 % + portefeuille à 30 %, par exemple) : refandes proportionnelles aux mêmes sources.

7) Fenêtres temporaires et priorités

Priorité 1 : « void/autorisation reversal » (si vous pouvez encore) est le retour le plus « propre ».
Priorité 2 : 'refund to source'par le rail d'origine.
Priorité 3 : payout alternatif (uniquement sur l'exception fixée + step-up et audit).

8) Moteur de solution (moteur de politique) : comment concevoir

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

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

2. Sinon, si 'isRefundableToSource (paymentId)' → Refund (sourceRef).

3. Si 'sourceRef invalid/closed' → Step-Up (KYC/SoF) → offrir payout rails par feuille d'allow (bancaire/Push-to-Card/e-wallet) → le journal de cause.

4. Si voucher/eCash → crédit interne. équilibre ; l'inverse direct n'est pas possible.

5. Split-tender → refand sur chaque 'sourceRef' dans sa part.

6. Hard-deny dans les sanctions/RER/interdictions d'âge/géo.

Non fonctionnel : idempotentialité ('refundKey'), déduplication des hooks web, explain-logique (pourquoi la méthode est sélectionnée), versioning des règles.

9) Statuts, rapprochements et artefacts

Statut de retour : 'Requested → pending → refunded | failed | canceled'.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
Recon : daily auto-recon sur les registres PSP/banque + full-recon ; alertes : « succès sans registre », « double refund », « retour à une autre source ».

10) UX et communications

Sur l'écran de retour, montrez le destinataire : « Retour à la carte • • 3456/portefeuille @ user/compte DE »....
Si vous voulez une exception, expliquez : "La source d'origine n'est pas disponible. Pour votre sécurité, nous vous proposons un retour sur votre compte bancaire après confirmation des données (≈N minutes/heures) ".
Chèques/lettres : montant, date, méthode, 'refundId', UTR/ARN, ETA (cartes jusqu'à X jours, A2A - T + 0/1, portefeuilles - instantanément/T + 1).
FAQ : les bons sont irréversibles ; Apple/Google Pay retournent automatiquement à la carte liée.

11) Matrice des exceptions (signaux et étapes)

12) FX et monnaie

Retour dans la devise d'origine de la transaction ; si vous avez besoin d'une conversion, utilisez la même source FX (PSP/banque) et montrez les cours/commissions.
Ne dégradez pas l'économie pour le client (ne remboursez pas dans une autre monnaie sans consentement explicite).

13) Caractéristiques pour iGaming

Remboursement de bonus/frispins : règles du jeu> politique de remboursement ; l'argent ne représente qu'une partie des fonds déposés.
Self-exclusion/RG : lorsque le compte est bloqué, le solde est renvoyé à la source ; les paiements alternatifs sont interdits jusqu'à la fin des contrôles.
Quasi cache : interdiction stricte de « déborder » de la carte/bon à de nouveaux accessoires déguisés en refand.

14) KPI et contrôle

Taux de réussite remboursable (en ligne → inscription au registre).
Median/P95 time-to-refund par méthode.
Taux alternatif-payout (proportion d'exceptions) - garder <X %.
ODR après retour (controverses répétées).
Erreurs de rapprochement : "double refund'," mauvaise source ".
Charge de support par retour/1k commandes.

15) Chèque de mise en œuvre

1. Annuaire des sources (card/A2A/wallet/voucher) et leurs statuts d'aptitude RTS.
2. Policy engine : règles void→refund→alt -payout, explain-logs, versioning.
3. Intégration PSP/banques : "void/refund', Web hooks (signature/NMAS), idempotence.
4. Recon : daily + full, alertes sur les dissynchrones et « refund sur une autre source ».
5. UX : affichage explicite du destinataire du retour, ETA, motifs des exceptions ; modèles de lettres/chèques.
6. AML/KYC : step-up pour les paiements alternatifs, SoF/SoW, deny-case.
7. Jeu de test : void window, refund partiel, split-tender, carte fermée/IBAN, bon, Apple/Google Pay, dégradation PSP.

Résumé

La règle same-method/refund-to-source est la clé de la sécurité, de la conformité et de la prévisibilité. Faites void → refund → (strictement si nécessaire) une alternative payout, gardez les règles dans un moteur de politique avec explain-logs, assurez l'idempotence, webhooks et recon, communiquez le destinataire et ETA de manière transparente. Exceptions - seulement avec KYC/SoF step-up et une piste d'audit claire. De cette façon, vous réduisez les risques, les coûts de support et le volume des litiges tout en maintenant la confiance des utilisateurs.