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

Regeloperatoren

Regelwerte

---

Überlegungen zur Einrichtung von Regeln

Hier sind einige Grundsätze, die Sie beim Festlegen Ihrer Regeln beachten sollten:

1. Für jede Händler-BIN/CAID-Kombination müssen Regeln definiert werden.
2. Jede BIN/CAID kann bis zu 10 verschiedene Regeln haben. Eine Regeln kann bis zu 7 Bedingungen haben.
3. Alle Felder in der Regel (Attribut, Operator, Wert) sind Pflichtfelder. Bitte lassen Sie keine Felder leer.
4. 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.
5. 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.
6. 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.
7. Wenn die Bedingungen einer Regel erfüllt sind, wird die Voranfechtung „akzeptiert“ und eine Rückerstattung wird an den/die Karteninhaber/in ausgestellt.
8. Bei einer Regel mit mehreren Bedingungen müssen alle Bedingungen erfüllt sein, damit die Haftung „akzeptiert“ wird.
9. Wenn keine der Bedingungen aller von Ihnen erstellten Regeln erfüllt, wird die Voranfechtung „abgelehnt“ und es kommt zu einer Rückbuchung.
10. 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

1. 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“).
2. 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)
3. Wenn der Transaktionsbetrag eine Bedingung in einer Regel ist, sollte für den Transaktionswährungscode eine entsprechende Bedingung bestehen.
4. 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