Same-Method-Regel und Rückkehr zur Quelle
1) Die Essenz und warum es notwendig ist
Same-method/Refund-to-Source (RTS) - das Prinzip, nach dem Rückgaben und „Rollbacks“ von Geldern auf die gleiche Weise und an die gleiche Quelle wie die ursprüngliche Einzahlung/Zahlung (gleiche Karte/Konto/Brieftasche) durchgeführt werden. Die Ziele sind:- AML/ATF: Rückgaben nicht in einen „anonymen Payout-Tunnel“ auf andere Requisiten verwandeln.
- Betrugs-/ODR-Rückgang: Weniger Kontroversen „Das Geld ist in die falsche Richtung gegangen“.
- Operational: vereinfachte Abstimmung, weniger manuelle Fälle.
- Regelkarten: Erfüllung der Netzwerkanforderungen „credit back to original funding instrument“.
2) Karten (Visa/Mastercard/...): Wie es funktioniert
Void/Authorization Reversal (vor dem Clearing): Autorisierungs-Rollback - das Geld wird auf derselben Karte „aufgetaut“.
Refund (Credit/Presentment): nach dem Clearing - Kredit für die gleiche PAN/DPAN.
Apple/Google Pay: Rückgabe an DPAN/Netzwerk-Token → der Emittent leitet auf die aktuelle Karte weiter (auch bei Neuausstellung).
Push-to-Card OCT - nicht gleich Refand: Dies ist eine Zahlung auf die Karte; nur bei festgelegter Ausnahme und zusätzlichem KYC verwenden.
- Die Karte ist geschlossen/neu ausgestellt - der Emittent wird das Guthaben in der Regel auf die ererbte Karte/das ererbte Konto „umleiten“. Die Rückgabe ist ohnehin der Helm als Refund.
- Rückgabe> der ursprünglichen Zahlung - verboten; teilweise refund machen, den Rest über die erlaubte Payout-Schiene nach KYC/SoF.
- Split-Tender (Zahlung aus 2 Quellen): Retouren im gleichen Verhältnis für jede Quelle.
3) Bank A2A (SEPA/ACH/FPS/RTP/PIX)
Ideal: Überweisung auf dieselbe IBAN/dasselbe Konto, von dem die Aufladung kam (oder auf die UPI/PIX-ID des Absenders).
ACH (US): „refund to source“ wird in der Regel als Kredit für das gleiche Routing + Konto realisiert; Retouren (R-Codes) sind kein Refand, sondern Schienenfehler/Retouren.
RTP/FPS/PIX: schnell und endgültig; wenn die ursprüngliche Zahlung auf diesen Schienen erfolgt - die Rückerstattung erfolgt häufig als neue Gutschrift an denselben Empfänger/Alias (dies ist eine normale Implementierung der gleichen Methode).
- Konto geschlossen/Requisiten ungültig - alternative Schiene nach Bestätigung des Begünstigten (Micro-Deposit/Testauszahlung) und KYC-Step-up erlaubt.
- Cross-border SWIFT: Wenn die ursprüngliche Zahlung lokal war und die Rückerstattung x-border erfordert - zusätzliche FX/Fee-Disclosure und Zustimmung.
4) E-Wallets und APM (Skrill/Neteller/Payz/PayPal und lokal)
Regel: Rückkehr in die gleiche Brieftasche/Konto, von dem die Einzahlung kam.
Top-up von der Karte innerhalb der Brieftasche: Der Refand wird an die Brieftasche zurückgegeben und nicht direkt an die Karte des Benutzers (Anbieterrichtlinie).
Gutscheine/eCash (Paysafecard, Neosurf, Multibanco-ref): Häufiger nicht erstattungsfähig an der Quelle - Guthaben im Geldbeutel/Merchant-Guthaben (oder alternative Auszahlung bei KYC).
- Gesperrter/verlorener Zugang - alternative Schiene nach EDD/SoF und Besitznachweis.
- Affiliate Limits (AUP) - Retouren sind nur in Form von Store-Credit/internem Guthaben möglich.
5) Gutscheine/Bargeld/Quasi-Bargeld
Die natürliche Quelle „Bargeld“ ist oft nicht umkehrbar. Vernünftige Politik:1. Stornierung vor Ausgabe der Ware/Gutschrift - ok, nichts wird übertragen.
2. Nach der Gutschrift - Rückkehr zum internen Guthaben/Wallet mit anschließender Auszahlung nur auf das benannte Bankkonto nach KYC/SoF (kein „Cash Back“).
Transparent im ToS angeben: Gutscheinnachschub wird nicht auf dem Gutschein zurückgegeben.
6) Teilrückläufer, Übergrenze und Multi-Quelle
Teilrefund: zur ursprünglichen Quelle bis zum Betrag der ursprünglichen Zahlung. Mehrere teilweise - zulässig.
Rückzahlungsbetrag> von der Quelle eingezahlt - Saldo über die erlaubte Payout-Schiene (KYC/SoF/Limits).
Mehrere Quellen (z. B. 70% Karte + 30% Brieftasche): Refands proportional zurück zu den gleichen Quellen.
7) Zeitfenster und Prioritäten
Priorität 1: 'void/authorization reversal' (falls noch möglich) ist der „sauberste“ Rollback.
Priorität 2: „refund to source“ auf der Originalschiene.
Priorität 3: Alternative Auszahlung (nur bei festgelegter Ausnahme + Step-up und Audit).
8) Lösungsmotor (Policy Engine): Wie man entwirft
Входные данные: `paymentId`, `sourceType` (card/A2A/wallet/voucher), `sourceRef` (PAN token, IBAN, walletId), `amount`, `fx`, `status`, `settlementState`, `kycLevel`, `riskScore`, `beneficiaryId`.
Regeln:1. Если `canVoid(paymentId)` → Void.
2. Andernfalls, wenn 'isRefundableToSource (paymentId)' → Refund (sourceRef).
3. Wenn 'sourceRef invalid/closed' → Step-Up (KYC/SoF) Payout-Rails per Allow-Sheet (Bank/Push-to-Card/E-Wallet) anbieten →, → die Ursache protokolliert.
4. Wenn voucher/eCash den Kredit intern →. Bilanz; Ein direkter Rückwärtsgang ist nicht möglich.
5. Split-tender → den Refand für jeden 'sourceRef' in seinem Anteil.
6. Hard-deny bei Sanktionen/RER/Alters-/Geo-Verbote.
Nicht-funktional: Idempotenz ('refundKey'), Dedup von Web-Hooks, Explain-Logik (warum die Methode gewählt wurde), Versionierung von Regeln.
9) Status, Abstimmung und Artefakte
Rückgabestatus: „requested → pending → refunded | failed | canceled“.
Артефакты: `refundId`, `originalPaymentId`, `sourceType/ref`, `amount/currency`, `fxRate`, `UTR/ARN/Trace`, `reasonCode`, `actor`.
Recon: täglicher Auto-Recon über PSP/Bank-Register + Full-Recon; Alerta: „Erfolg ohne Register“, „doppelter Refund“, „Rückkehr zu einer anderen Quelle“.
10) UX und Kommunikation
Zeigen Sie auf dem Rückgabebildschirm den Adressaten an: „Rückgabe an die Karte • • 3456/wallet @ user/account DE“....
Wenn eine Ausnahme erforderlich ist, erklären wir: "Die ursprüngliche Quelle ist nicht verfügbar. Zu Ihrer Sicherheit bieten wir nach Bestätigung der Daten (≈N Minuten/Stunden) eine Rückerstattung auf ein personalisiertes Bankkonto an ".
Schecks/Briefe: Betrag, Datum, Methode, 'refundId', UTR/ARN, ETA (Karten - bis zu X Tage, A2A - T + 0/1, Geldbörsen - sofort/T + 1).
FAQ: Gutscheine sind nicht reversibel; Apple/Google Pay wird automatisch auf die verknüpfte Karte zurückgesetzt.
11) Ausnahmematrix (Signale und Schritte)
12) FX und Währung
Rückgabe in der ursprünglichen Währung der Transaktion; Wenn eine Konvertierung erforderlich ist, verwenden Sie dieselbe FX-Quelle (PSP/Bank) und zeigen Sie die Kurse/Gebühren an.
Verschlechtern Sie nicht die Wirtschaft für den Kunden (geben Sie nicht in einer anderen Währung ohne ausdrückliche Zustimmung zurück).
13) Funktionen für iGaming
Rückerstattung von Boni/Freispielen: Spielregeln> Rückgaberecht; Geld nur in einem Teil der eingezahlten Mittel.
Selbstausschluss/RG: wenn das Konto gesperrt ist - Rückerstattung des Restbetrags an die Quelle; alternative Zahlungen sind bis zum Abschluss der Kontrollen verboten.
Quasi-Cache: striktes Verbot des „Überlaufens“ von Karte/Gutschein auf neue Requisiten unter dem Deckmantel eines Refands.
14) KPIs und Kontrolle
Refund success rate (Online → Einschreibung nach dem Register).
Median/P95 von Time-to-Refund nach Methoden.
Auszahlungsrate (Ausschlussanteil) - <X% halten.
ODR nach Rückgabe (wiederholte Streitigkeiten).
Abstimmungsfehler: „doppelter Refund“, „falsche Quelle“.
Support Load bei Rücksendungen/1k Bestellungen.
15) Checkliste Umsetzung
1. Quellenverzeichnis (card/A2A/wallet/voucher) und deren RTS-Eignungsstatus.
2. Policy Engine: Regeln void→refund→alt -payout, explain-logs, Versionierung.
3. Integration von PSPs/Banken: 'void/refund', Web Hooks (Signatur/NMAS), Idempotenz.
4. Recon: täglich + voll, Warnungen über Fehlsynchronisierungen und „Refund auf eine andere Quelle“.
5. UX: explizite Darstellung des Retourenziels, ETA, Ausschlussgründe; Brief-/Scheckvorlagen.
6. AML/KYC: Step-up für alternative Auszahlungen, SoF/SoW, Deny-Cases.
7. Testkit: void window, partial refund, split-tender, closed card/IBAN, Voucher, Apple/Google Pay, PSP degradation.
Zusammenfassung
Die same-method/refund-to-source Regel ist der Schlüssel zu Sicherheit, Compliance und Berechenbarkeit. Machen Sie void → refund → (streng nach Bedarf) eine alternative Auszahlung, halten Sie die Regeln in der Policy-Engine mit Explain-Logs, stellen Sie Idempotenz, Webhooks und Recon sicher, kommunizieren Sie den Adressaten und die ETA transparent. Ausnahmen gibt es nur beim KYC/SoF-Step-up und einem klaren Prüfpfad. Auf diese Weise reduzieren Sie Risiken, Supportkosten und das Streitvolumen, während Sie das Vertrauen der Benutzer erhalten.