So funktioniert die AnfechtungspräventionÖffentliche Vorschau
Erfahren Sie mehr über die Vorteile und Anforderungen der Lösung von Stripe zur Anfechtungsprävention mit Verifi und Ethoca.
Stripe verfügt über Integrationen mit den von Verifi (einer Visa-Lösung) und Ethoca (einer Mastercard-Lösung) angebotenen Lösungen zur Prävention von angefochtenen Zahlungen.
Lösungen von Verifi und Ethoca
Die Verifi-Lösung umfasst Order Insights (OI) und Rapid Dispute Resolution (RDR), und Ethoca umfasst Ethoca Alerts. Dank unserer Integrationen können Sie diese Produkte ohne manuelle Einrichtung verwenden, um Ihre Anfechtungsquote zu senken und Ihre Umsatzbindung zu erhöhen. Weitere Informationen zu Preisen finden Sie auf der Produktübersichtsseite.
Rapid Dispute Resolution (RDR) – die Schnelle Beilegung einer Zahlungsanfechtung
Mit RDR können Sie ein Regelwerk erstellen, um eingehende Zahlungsanfechtungen bei Visa-Transaktionen gegen eine Gebühr pro Zahlungsanfechtung beizulegen (z. B. alle potenziell betrügerischen Zahlungsanfechtungen unter 10 USD). Die Hauptvorteile von RDR sind:
- Beigelegte Zahlungsanfechtungen werden nicht auf Ihre Gesamtanfechtungsquote angerechnet, sodass Sie nicht am Überwachungsprogramm teilnehmen müssen.
- Für diese beigelegten Zahlungsanfechtungen fällt keine separate Gebühr an.
Die Teilnahme am Visa Acquirer-Überwachungsprogramm (VAMP) ist hilfreich, da es Ihre Quoten für Zahlungsanfechtungen sowie die Anfechtungs-Feeds senkt. Außerdem können Sie so Netzwerkstrafen und Rückstellungen für Zahlungsvolumen bei Stripe vermeiden.
Notiz
Verifi unterstützt derzeit keine teilweise Beilegung von Zahlungsanfechtungen. Das bedeutet, dass RDR Zahlungsanfechtungen nur dann beilegt, wenn der/die Karteninhaber/in den vollen Betrag der ursprünglichen Transaktion anficht.
Ethoca-Warnungen
Ethoca Alerts ermöglicht es Nutzern und Nutzerinnen, Regelsätze zu erstellen, um Rückbuchungen zu verhindern, indem automatische Beilegungen eingerichtet werden. Ethoca Alerts ist für Mastercard-Transaktionen verfügbar und beigelegte Zahlungsanfechtungen werden nicht auf die Anfechtungsquoten angerechnet. Dies hilft Händlern, die Überwachungsprogramme von Mastercard für Rückbuchungen wie ECM, HECM und EFM zu verlassen, indem sie die Anfechtungsquoten reduzieren und die Bußgelder senken.
Notiz
Die von Ihnen festgelegten Regeln gelten nur für Rückbuchungen, die nach der Registrierung eingeleitet werden. Nach der Registrierung erhalten Sie möglicherweise weiterhin Benachrichtigungen über Rückbuchungen, die von Karteninhabern und -inhaberinnen vor Ihrer Registrierung initiiert wurden.
RDR- und Ethoca Alerts-Anforderungen
Für beide Lösungen ist kein separater Integrationsaufwand erforderlich. Für den Onboarding-Prozess müssen Sie jedoch Beilegungsregeln über Radar einrichten, um auf die Beilegung einer Zahlungsanfechtung zuzugreifen und zu definieren, welche Transaktionen zurückerstattet werden sollen. Erfahren Sie mehr über das Festlegen von Regeln über Radar.
Order Insight (OI)
Wenn Karteninhaber/innen ihre digitale Banking-App überprüfen oder ihren Aussteller anrufen und melden, dass ihnen eine Visa-Abbuchung nicht bekannt ist, und sie bei OI angemeldet sind, kann der/die Kundendienstmitarbeiter/in des Ausstellers eine API-Anfrage (eine Suche) an Stripe senden, um detaillierte Beschreibungen der gekauften Artikel (wie Produktbeschreibungen, Menge, Versandadresse oder IP-Adresse) bereitzustellen. Die zusätzlichen Daten helfen dem/der Karteninhaber/in, die Abbuchung anzuerkennen, und die Weiterverfolgung von Zahlungsanfechtungen zu verhindern. OI verwendet auch Visa-Regeln wie Compelling Evidence 3.0 (CE 3.0). CE 3.0 ermöglicht es Ihnen, Ausstellern Daten über frühere erfolgreiche Transaktionen mit demselben/derselben Karteninhaber/in als Antwort auf eine Abfrage zu senden. Der Aussteller ist dann verpflichtet, den/die Karteninhaber/in daran zu hindern, die Zahlungsanfechtung überhaupt einzureichen. Weitere Informationen finden Sie unter Compelling Evidence 3.0 mit OI.
Es ist weniger wahrscheinlich, dass Karteninhaber/innen eine Zahlungsanfechtung einreichen, wenn sie die Zahlung anerkennen können. Die Chance, eine Zahlungsanfechtung erfolgreich abzuwenden, wenn Sie eine Abfrage veranlassen, hängt von der Qualität der Daten ab, die Stripe bereitstellen kann. Stripe ruft in Ihrem Namen automatisch alle verfügbaren Daten zu einer Zahlung ab und sendet sie an den/die Aussteller/in. Stripe verwendet die Daten, die Sie zum Zeitpunkt der Abbuchung zur Verfügung stellen. Sie müssen keine Integrationen erstellen und keinen Echtzeitdienst bereitstellen. Nachfolgend finden Sie eine Liste der Felder, die als Teil der Suchantwort zulässig sind. Durch die Verwendung des OI-Dienstes weisen Sie Stripe an, diese Daten an Aussteller/innen und letztlich an Karteninhaber/innen weiterzugeben. Verifi kann diese Felder gelegentlich aktualisieren, und Ihre weitere Nutzung des OI-Dienstes hängt davon ab, dass Sie sich an die neuen betrieblichen Anforderungen anpassen.
Notiz
Damit eine Zahlungsanfechtung für eine Blockierung im Rahmen der CE 3.0-Regeln infrage kommt, müssen Stripe vorherige Transaktionsdaten vorliegen. Unter Compelling Evidence 3.0 mit OI erfahren Sie, welche Daten für CE 3.0-Blockierungen erforderlich sind. Wenn keine vorherigen Transaktionsdaten verfügbar sind, sendet Stripe dennoch alle weiteren verfügbaren Daten.
Wenn Sie die Prävention von Zahlungsanfechtungen nutzen, erklären Sie sich damit einverstanden, den angemessenen Aufforderungen von Stripe nachzukommen und bei Bedarf zusätzliche Daten bereitzustellen.
| Objekt | Feld | Beschreibung |
|---|---|---|
| Zahlungsbeleg | orderDate | Bestelldatum |
| orderNumber | Eindeutige Kennung für die Bestellung, vom Unternehmen definiert | |
| invoiceNumber | Rechnungsnummer (alternativ zur Bestellnummer) | |
| subTotalAmount | Netto-Zwischensumme des Kaufs, inklusive Versandkosten | |
| shippingAndHandlingAmount | Mit dem Kauf zusammenhängender Versand- und Bearbeitungsbetrag | |
| orderTotalAmount | Gesamtbetrag der Bestellung | |
| Zahlungsinformationen | paymentMethod | Maskierte Darstellung der Karte und Kartennummer des ursprünglichen Kaufs, wie auf dem physischen oder digitalen Beleg angezeigt. Beschränkt auf die letzten 4 Ziffern der Karten-PAN. |
| billingName | Vor- und Nachname auf der Karte | |
| paymentTotalAmount | Zahlungsbetrag des Kaufs | |
| cvvChecked | Validierung des Karten-Sicherheitscodes zum Zeitpunkt des Kaufs | |
| Gekauftes Produkt | productDescription | Detaillierte Beschreibung des gekauften Produkts (Ware oder Dienstleistung) |
| unitPriceAmount | Betrag des Einzelposten | |
| quantity | Menge des gekauften Produkts | |
| Kundeninformationen | firstName | Vorname der Kundin/des Kunden |
| lastName | Nachname der Kundin/des Kunden | |
| lengthOfRelationship | Dauer der geschäftlichen Beziehung der Kundin/des Kunden mit dem Unternehmen in Monaten | |
| accountId | Von der Karteninhaberin/dem Karteninhaber registrierte Kennung zur eindeutigen Identifizierung ihres/seines Kontos beim Unternehmen. Dies muss dem/der Karteninhaber/in zugeordnet werden können (keine interne Systemkennung) und es muss sich um etwas handeln, das dem Unternehmen bei der Kontoerstellung zur Verfügung gestellt wurde. Beispiele sind ein eindeutiger Nutzername, eine E-Mail-Adresse, eine Telefonnummer oder ein ähnlicher Wert. | |
| emailAddress | E-Mail, die die Kundin/der Kunde angegeben hat | |
| Rechnungsadresse | address1 | Adresse plus zusätzliche Adresszeilen wie Nummer der Suite und Wohnung |
| address2 | Adresse plus zusätzliche Adresszeilen wie Nummer der Suite und Wohnung | |
| Stadt | Name der Stadt | |
| Region | Region oder Bundesland | |
| postalCode | Postleitzahl | |
| Land | Ländercode | |
| Händlerinformationen | merchantName | Name des Unternehmens oder der Muttergesellschaft des Unternehmens. Dem/der Verbraucher/in ist dieser möglicherweise bekannt oder auch nicht. |
| merchantUrl | Unternehmens-URL des Unternehmens. Könnte sich von der websiteUrl unterscheiden, von der aus die Kundin/der Kunde den Kauf getätigt hat. | |
| merchantContactPhone | Geschäftliche Telefonnummer des Kundenservice. Dies sollte die Nummer sein, unter der Verbraucher/innen Sie kontaktieren, um Fragen zu Käufen zu klären. | |
| merchantAddress | Firmenadresse | |
| termsAndConditions | Übersicht der Stornorichtlinie für Unternehmen | |
| storeDetails | Ein Unternehmen hat möglicherweise mehrere Geschäfte oder Standorte, in bzw. an denen Einkäufe getätigt werden. Die Angaben zum Geschäft sollten deutlich Aufschluss darüber geben, wo der Kauf abgewickelt wurde, bzw. die Details zum Online-Webstore nennen. | |
| Store-Details | storeName | Name des Geschäfts oder Webshops, in dem der Kauf getätigt wurde |
| storeContactPhone | Geschäftliche Telefonnummer des Kundenservice | |
| Lieferadresse | address1 | Adresse plus zusätzliche Adresszeilen wie Nummer der Suite und Wohnung |
| address2 | Adresse plus zusätzliche Adresszeilen wie Nummer der Suite und Wohnung | |
| Stadt | Name der Stadt | |
| Region | Region oder Bundesland | |
| postalCode | Postleitzahl | |
| Land | Land ISO 3166-1 Code alpha-3 | |
| Lieferdaten | shippingCarrier | Paketdienst |
| trackingNumber | Tracking-Nummer der Sendung oder Lieferung | |
| Gerät | ipAddress | Dem Gerät zugeordnete IP-Adresse |
Compelling Evidence 3.0 mit OI
Compelling Evidence 3.0 (CE 3.0) ist ein Programm, das Unternehmen Vorteile bietet, indem es aggressivere Tools zur Abwehr und Beilegung von Zahlungsanfechtungen aufgrund von Missbrauch durch Erstanbieter (Friendly Fraud, freundlicher Betrug) bei Visa-Transaktionen bereitstellt, die als 10.4 Sonstiger Betrug – Distanzzahlung kategorisiert sind. Die CE 3.0-Regeln legen fest, welche Beweise nach einer Zahlungsanfechtung vorgelegt werden können, um Ihre Chancen zu verbessern, dass eine Zahlungsanfechtung zu Ihren Gunsten entschieden wird. Weitere Informationen finden Sie in unserem Support-Artikel.
Wenn Sie für OI registriert sind, können Sie auch CE 3.0 vor der Zahlungsanfechtung verwenden, um die Einreichung der Anfechtung vollständig zu blockieren. Dabei werden den Ausstellern/Austellerinnen bei einer Abfrage die erforderlichen vorherigen Transaktionsdaten zur Verfügung gestellt. Wenn frühere Transaktionen zwischen Ihnen und dem/der Karteninhaber/in bestehen, wählt Visa automatisch die 2 bis 5 letzten vorherigen Transaktionen aus, die nicht auf Betrug zurückzuführen sind, und fordert Daten zu allen an. Stripe stellt dann automatisch alle verfügbaren Informationen bereit.
Wenn mindestens zwei frühere Transaktionen mit vollständigen Produktbeschreibungen bestehen, die übereinstimmende IP-Adressen und mindestens eine übereinstimmende E-Mail-Adresse oder Zustelladresse für Kundinnen/Kunden aufweisen, muss der/die Aussteller/in die Zahlungsanfechtung blockieren. Dadurch wird die Zahlungsanfechtung nie eingereicht und es fallen keine Anfechtungsgebühren für Sie an oder Ihre Anfechtungsquote steigt nicht.
OI-Anforderungen
Der Onboarding-Ablauf im Stripe-Dashboard erfasst alle Datenelemente, die Stripe benötigt, um mit den OI-Suchvorgängen in Ihrem Namen zu beginnen. Dazu gehören der Firmenname, die Unternehmen-URL, die Firmentelefonnummer und die E-Mail-Adresse. Um Zahlungsanfechtungen mit der besten Wahrscheinlichkeit abzuweisen, richten Sie Ihre Stripe-Integration so ein, dass zum Transaktionszeitpunkt möglichst viele der oben genannten Felder bereitgestellt werden. Damit Stripe Anfechtungen in Ihrem Namen mit CE 3.0 verlässlich und effektiv blockieren kann, stellen Sie sicher, dass alle Ihre Transaktionen folgende Elemente enthalten: IP-Adresse, E-Mail-Adresse der Kundin/des Kunden, Produktbeschreibungen und, wenn möglich, Versand- oder Kundenadresse.