GH GambleHub

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“.
💡 Grundthese: Wir bringen zurück, woher wir kamen. Ist dies nicht möglich, erfassen wir eine begründete Ausnahme mit den Dop.kontrollen (KYC/SoF) und einer verständlichen Kommunikation.

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.

Ausnahmen auf den Karten:
  • 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).

Ausnahmen von A2A:
  • 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).

Ausnahmen für E-Wallet:
  • 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)

💡 Originalbetrag Teilrefund + Auszahlung KYC/SoF für den Rest
DrehbuchWas zu tun istStep-Up/Dop. Prüfungen
Karte geschlossen/neu ausgestelltRefund wie gewohnt sendenNein (Emittent leitet)
DPAN (Apple/Google Pay)Refund auf Token (wird funktionieren)Nein
IBAN geschlossenNeues Namenkonto anfordernKYC+SoF, test payout
Gutschein/eCashKredit intern. Guthaben/WalletNein, aber ToS/Bestätigung
Split-tenderProportionale RefandsNein
Sanktionen/RER/Geo-VerbotDenyCase-management/AML

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.

Contact

Kontakt aufnehmen

Kontaktieren Sie uns bei Fragen oder Support.Wir helfen Ihnen jederzeit gerne!

Telegram
@Gamble_GC
Integration starten

Email ist erforderlich. Telegram oder WhatsApp – optional.

Ihr Name optional
Email optional
Betreff optional
Nachricht optional
Telegram optional
@
Wenn Sie Telegram angeben – antworten wir zusätzlich dort.
WhatsApp optional
Format: +Ländercode und Nummer (z. B. +49XXXXXXXXX).

Mit dem Klicken des Buttons stimmen Sie der Datenverarbeitung zu.