RDR „akzeptiert“ in Ihrem Namen automatisch eine Voranfechtung von Visa, basierend auf den Regeln, die Sie im Rahmen Ihrer Registrierung festlegen. Regeln bestehen aus Bedingungen, die die Attribute der angefochtenen Transaktion widerspiegeln, zum Beispiel der Transaktionsbetrag oder die Bestellkennung. Während der Regelbewertung führt das Ergebnis entweder zu der Antwort „Akzeptieren“ oder „Ablehnen“.
- Werden die Bedingungen der Regeln erfüllt, dann beschließen Sie, die Haftung für die Voranfechtung zu „akzeptieren“ und Visa zu ermächtigen, den vollständigen Transaktionsbetrag automatisch an den/die Karteninhaber/in zu erstatten und so eine Rückbuchung zu verhindern.
- Wenn keine der Bedingungen erfüllt werden, entscheiden Sie sich dafür, die Haftung für die Voranfechtung „abzulehnen“, was zu einer Rückbuchung führt.
- Die RDR-Abdeckung ist vollständig automatisiert. Sobald Ihre Regeln eingerichtet sind, müssen Sie keine weiteren Maßnahmen ergreifen, um eine Zahlungsanfechtung zu verhindern.
In diesem Leitfaden erfahren Sie alles, was Sie wissen müssen, um Ihre Regeln korrekt einzurichten und Rückbuchungen über RDR zu vermeiden.
Informationen zu RDR-Regeln
Die Regeln setzen sich aus den folgenden Hauptelementen zusammen:
- Regelname
- Regelattribute
- Regeloperatoren
- Regelwerte
Regelname
- Vom Händler erstellte und in Berichten angegebene Kennung.
- Sichtbar für den an der Anfrage beteiligten Aussteller und Acquirer.
Regelattribute
Attribut |
Definition |
Personal Account Number BIN |
6-stellige Aussteller-BIN |
Transaktionsdatum |
Datum, an dem die Transaktion erfolgt ist (z. B. Format: TT/MM/JJJJ) |
Transaktionsbetrag |
Gesamtbetrag der Transaktion (z. B. Format: 10,00) |
Transaktionswährungscode |
ISO-Währungscode der Transaktion (z. B. USD) |
Bestellkennung |
Eindeutige Bestellkennung, die jeder Transaktion zugewiesen wird. Wird vom Acquirer an den Aussteller übermittelt, um die Kundenbestellung für eine automatisierte Abwicklung zu kennzeichnen. |
Kategorie der angefochtenen Zahlung |
Von Visa definierter Code zur Klassifizierung der angefochtenen Zahlung (z. B. 10 – Betrug, 11 – Autorisierung, 12 – Verarbeitungsfehler, 13 – Verbraucheranfechtungen. In der nachfolgenden Tabelle finden Sie alle Kategorien für angefochtene Zahlungen) |
Code der Anfechtungsbedingung |
Subcode der Anfechtungskategorie zur weitergehenden Klassifizierung der angefochtenen Zahlung
|
Regeloperatoren
Operatoren |
Definition |
Contains |
Das Attribut muss den angegebenen Wert enthalten. |
EqualTo |
Das Attribut muss gleich dem angegebenen Wert sein. |
GreaterThan |
Das Attribut muss größer als der angegebene Wert sein. |
GreaterThanOrEquals |
Das Attribut muss größer als oder gleich dem angegebenen Wert sein. |
IsBlank |
Das Attribut enthält keinen Wert. Kann „True“ oder „False“ sein. |
LessThan |
Das Attribut muss kleiner als der angegebene Wert sein. |
LessThanOrEquals |
Das Attribut muss kleiner als oder gleich dem angegebenen Wert sein. |
NotEqualTo |
Das Attribut ist nicht gleich dem angegebenen Wert. |
StartsWith |
Das Attribut muss mit dem angegebenen Wert beginnen. |
IsIn |
Das Attribut muss die ausgewählten möglichen Werte enthalten.
|
IsNotIn |
Das Attribut darf nicht die ausgewählten möglichen Werte enthalten.
|
Regelwerte
Attribut |
Format |
Mögliche Werte |
Mögliche Operatoren |
Personal Account Number BIN |
Die Nummer |
Sollte eine 6-stellige Aussteller-BIN sein. |
Contains, EqualTo, IsBlank, NotEqualTo, StartsWith |
Transaktionsdatum |
Datum |
Datum im Format TT/MM/JJJJ |
EqualTo, NotEqualTo, GreaterThan GreaterThanOrEquals, IsIn, IsNotIn, LessThanOrEquals, LessThan |
Transaktionswährung Code |
Dropdown oder Freiform |
Alphanumerisch Währungscodes ISO 4217 Wählen Sie die Transaktionswährung im Dropdownmenü aus. Sie können mehrere Werte für „IsIn“ und „IsNotIn“ auswähen. |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
Bestellkennung |
Alphanumerisch |
Sollte die eindeutige Bestellkennung sein, die jeder Transaktion zugewiesen wird. |
Contains, EqualTo, IsBlank, IsIn, IsNotIn, NotEqualTo, StartsWith |
Kategorie der angefochtenen Zahlung |
Dropdown oder Freiform |
Wählen Sie aus den folgenden Optionen: 10-Betrug 11-Autorisierung 12-Verarbeitungsfehler 13-Verbraucher/in |
Contains, EqualTo, NotEqualTo, IsBlank, IsIn, IsNotIn |
Code der Anfechtungsbedingung |
Dropdown oder Freiform |
Wählen Sie aus der nachfolgenden Tabelle den zutreffenden Code aus |
Contains, EqualTo, NotEqualTo |
Überlegungen zur Einrichtung von Regeln
Hier sind einige Grundsätze, die Sie beim Festlegen Ihrer Regeln beachten sollten:
- Für jede Händler-BIN/CAID-Kombination müssen Regeln definiert werden.
- Jede BIN/CAID kann bis zu 10 verschiedene Regeln haben. Eine Regeln kann bis zu 7 Bedingungen haben.
- Alle Felder in der Regel (Attribut, Operator, Wert) sind Pflichtfelder. Bitte lassen Sie keine Felder leer.
- Einige Attribute können ungefähre Übereinstimmungsoperatoren wie „StartsWith“ oder „Contains“ nutzen. Der Mindestwert für diese Attribute beträgt mindestens ein Zeichen oder eine Ziffer.
- Als Best Practice wird empfohlen, den Freiformeintrag (sofern vorhanden) nicht zusammen mit ungefähren Übereinstimmungsoperatoren wie „Contains“ und „IsIn“ zu verwenden. Dies könnte dazu führen, dass mehrere Fälle mit ähnlichen Übereinstimmungen akzeptiert werden.
- Regeln werden aufeinanderfolgend ausgewertet (zuerst wird Regel eins ausgewertet, dann Regel zwei usw.). Wenn es fünf Regeln gibt und die Bedingungen der ersten Regel erfüllt sind, werden die verbleibenden Regeln nicht ausgewertet.
- Wenn die Bedingungen einer Regel erfüllt sind, wird die Voranfechtung „akzeptiert“ und eine Rückerstattung wird an den/die Karteninhaber/in ausgestellt.
- Bei einer Regel mit mehreren Bedingungen müssen alle Bedingungen erfüllt sein, damit die Haftung „akzeptiert“ wird.
- Wenn keine der Bedingungen aller von Ihnen erstellten Regeln erfüllt, wird die Voranfechtung „abgelehnt“ und es kommt zu einer Rückbuchung.
- Für jeden „akzeptierten“ RDR-Fall wird der Name der ausgelösten Regel dem Acquirer des Händlers und dem Aussteller des Karteninhabers/der Karteninhabern mitgeteilt, um sie darüber zu informieren, warum die Anfechtung beigelegt wurde.
Best Practices für das Regelmanagement
- Geben Sie keine widersprüchlichen Kategorien für angefochtene Zahlungen und Bedingungscodes an (z. B. eine Kategorie für angefochtene Zahlungen = „10“ und einen Statuscode für die Anfechtung = „12.1“).
- Eine Regel darf nicht mit einer anderen Regel in Konflikt stehen (z. B. „Transaktionsdatum IsGreaterThan 01.01.2020“, in einer Regel und „Transaktionsdatum IsLessThan 01.01.2020“ in einer anderen)
- Wenn der Transaktionsbetrag eine Bedingung in einer Regel ist, sollte für den Transaktionswährungscode eine entsprechende Bedingung bestehen.
- Regelnamen sollten kurz, eindeutig und klar genug sein, damit in der RDR-Kommunikation auf sie verwiesen werden kann. Der Name sollte nicht mehr als 30 Zeichen enthalten.
Kategorie der angefochtenen Zahlung und Bedingungscodes
10. Betrug |
11. Autorisierung |
12. Verarbeitungsfehler |
13. Verbraucheranfechtungen |
10.1 EMV-Haftungsverlagerung – Fälschungsbetrug 10.2 EMV-Haftungsverlagerung – Nicht-Fälschungsbetrug 10.3 Sonstiger Betrug – Zahlung mit Karte 10.4 Sonstiger Betrug – Distanzzahlung 10.5 Betrugsüberwachungsprogramm von Visa |
11.1 Bulletin zur Wiederherstellung von Karten 11.2 Abgelehnte Autorisierung 11.3 Keine Autorisierung |
12.1 Verspätete Vorlage 12.2 Falscher Transaktionscode 12.3 Falsche Währung 12.4 Falsche Kontonummer 12.5 Falscher Betrag 12.6 Doppelt verarbeitet/Anderweitig bezahlt |
13.1 Nicht erhaltene Waren/Dienstleistungen 13.2 Wiederkehrend storniert 13.3 Nicht wie beschrieben oder mangelhafte Waren/Dienstleistungen 13.4 Gefälschte Ware 13.5 Falsche Darstellung 13.6 Gutschrift nicht verarbeitet 13.7 Stornierte Waren/Dienstleistungen 13.8 Ursprüngliche Kredittransaktion nicht genehmigt 13.9 Nichterhalt von Bargeld oder Ladetransaktionswert |