Chargeback Reason Codes: passende SaaS-Nachweise auswählen
Mit KI besprechen
Öffnet eine KI mit einer Frage zur öffentlichen Artikel-URL. Prüfen Sie deren Antwort und Quellen.
Die Seite muss veröffentlicht sein. Ein Zugriff oder vorausgefüllter Text ist nicht garantiert; kopieren Sie bei Bedarf die Frage. Es werden nur die öffentliche URL und diese Frage übergeben.
Ein Chargeback Reason Code bezeichnet die Art des Zahlungseinwands. Er zeigt einem SaaS-Team, welche Frage die Nachweise beantworten müssen. Er belegt weder die Richtigkeit der Beschwerde noch, dass der Händler widersprechen sollte. Halten Sie Netzwerkcode, Anbieterkategorie und tatsächliche Kundenerklärung gemeinsam fest.
In diesem Artikel
Was sagt ein Chargeback Reason Code aus?
Ein Reason Code ordnet die Beschwerde ein, die das Zahlungsnetzwerk bearbeitet. Bei einer Kündigung geht es darum, ob diese Verlängerung stattfinden durfte. Bei einer nicht erhaltenen Leistung geht es um die Bereitstellung des gekauften Dienstes. Ein Betrugseinwand stellt eine andere Frage zur Beteiligung an der Zahlung. Ein erfolgreicher Login beantwortet diese drei Fragen nicht gleichermaßen.
Stripe fasst Netzwerkcodes zu Kategorien des Zahlungsanbieters zusammen. Bewahren Sie beide Angaben auf: Die Kategorie hilft bei der Zuweisung der Prüfung, während Netzwerkcode und konkrete Fallanweisungen die Antwort bestimmen. Lesen Sie auch die beigefügte Kundenerklärung. Hinter einem kurzen Etikett kann eine genaue Beschwerde über eine fehlende Funktion, frühere Kündigung oder zugesagte Erstattung stehen.
Bei B2C-SaaS braucht es die Verbindung zwischen persönlichem Konto und Abo. Bei B2B-SaaS identifizieren Sie zusätzlich abgerechnetes Unternehmen, zahlende Person, Workspace und das Mitglied, dessen Aktivität erscheint. Die Nutzung durch einen Kollegen darf nicht stillschweigend zur Aussage über das Verhalten des Zahlers werden.
Eine praktische Auswahl von Visa-Codes
Die folgende Auswahl unterstützt die Händlerprüfung. Sie ist kein vollständiger Codekatalog und ersetzt keine aktuellen Fallanweisungen. Die Zuordnung folgt Stripes Visa-Kategorien; die vorgeschlagenen Prüfschritte sind redaktionelle Empfehlungen von Evidenz.
Seitlich scrollen für alle Spalten.
| Code / Einwand | Zu prüfende Unterlagen | Was diese Unterlagen nicht belegen |
|---|---|---|
| 10.4 / Betrug ohne vorgelegte Karte | Verbindung von Zahlung und Konto, relevante Authentifizierung, Kundenkommunikation und vom Anbieter bestätigte Historie. | Eine übereinstimmende IP-Adresse oder ein Login belegt allein weder Identität noch Absicht des Karteninhabers. |
| 13.1 / Leistung nicht erhalten | Gekaufte Berechtigung, Bereitstellung, Zugangsfehler, aussagekräftige Aktivität und Support zur Lieferung. | Ein eingerichtetes Konto belegt nicht, dass die zugesagte Funktion arbeitete. |
| 13.2 / Gekündigte wiederkehrende Zahlung | Kündigungsanfrage, Supportzusage, Wirksamkeitsdatum, Verlängerung und Bearbeitungsverlauf. | Eine späte Verwaltungsänderung hebt eine frühere Kündigungszusage nicht auf. |
| 13.3 / Leistung nicht wie beschrieben | Angebot und Tarif beim Kauf, tatsächliche Funktion, Beschwerde, Störung und Abhilfeversuch. | Beleg oder erfolgreicher Login beantworten keine Beschwerde über eine fehlende Funktion. |
| 13.6 / Gutschrift nicht verarbeitet | Erstattungszusage, Referenz, Betrag, Status und tatsächliche Geldbewegungen. | Eine Anfrage oder ausstehende Erstattung ist keine abgeschlossene Rückzahlung. |
| 12.6.1 / Doppelte Verarbeitung | Beide Zahlungskennungen, Rechnungen, Autorisierungen, Einzüge und Leistungszeiträume. | Zwei Kontoauszugszeilen bedeuten nicht zwingend zwei abgeschlossene Belastungen. |
Wenden Sie dieselbe Prüfsorgfalt bei anderen Netzwerken an, aber verwenden Sie deren eigene Bezeichnungen und Anforderungen. Übertragen Sie eine Visa-Nummer nicht wegen ähnlicher Formulierungen auf einen Mastercard-Fall. Adyens Referenz trennt die Netzwerkcodes und die Unterlagen für den jeweiligen Einwand.
Vor dem Schreiben Einwand und Unterlagen verbinden
Formulieren Sie den Einwand in einem Satz. Erfassen Sie anschließend Tatsachen, die ihn stützen oder schwächen, die jeweilige Originalquelle und verbleibende Lücken.
Fiktives Beispiel: Ein Unternehmen beanstandet die Workspace-Verlängerung im Oktober, weil der Support im September die Kündigung zugesagt hat. Das Finanzteam findet eine bezahlte Rechnung, das Produktteam einen Oktober-Login. Beides klärt nicht, ob die Verlängerung richtig war. Entscheidend sind das Kündigungsgespräch und der Umfang der Zusage.
Eine brauchbare Zuordnung lautet etwa: „Der Support sagte die Kündigung dieses Abos vor der Verlängerung zu; Gespräch S-17 enthält die Zusage; Abrechnungsereignis B-22 zeigt die Umsetzung nach dem Einzug.“ Das Ergebnis muss diesen Widerspruch erhalten. Die Bezeichnung als Betrug würde eine durch die Unterlagen nicht belegte Anschuldigung hinzufügen.
Das fiktive Nachweispaket zeigt die Situation mit Belegauszügen, zeitlichem Verlauf und einem Ergebnis, das die Beschwerde des Kunden stützt.
Was tun, wenn Kategorie und Kundenerklärung auseinandergehen?
Bewahren Sie die Kategorie des Anbieters unverändert im Fall auf und dokumentieren Sie die Abweichung. Die prüfende Person muss sowohl die Zuordnung als auch den tatsächlichen Einwand verstehen. Klären Sie eine mögliche Fehlzuordnung über den vorgesehenen Fallkanal des Zahlungsanbieters. Erfinden Sie keinen anderen Netzwerkcode und setzen Sie nicht voraus, dass Sie ihn ändern können.
Das betrifft Formulierungen wie „Diese Verlängerung habe ich nicht autorisiert“, wenn daneben ein Supportgespräch über die Kündigung steht. Prüfen Sie die vollständige Beschwerde vor dem Entwurf. Eine Antwort über die Nutzung kann den Grund verfehlen, aus dem der Kunde die Zahlung für falsch hält.
Der Leitfaden zum Akzeptieren oder Anfechten unterstützt die Entscheidung. Die Untersuchung ist auch dann nützlich, wenn das begründete Ergebnis lautet, den Fall zu akzeptieren.
Wo CE3.0 dazugehört
Compelling Evidence 3.0 ist ein bestimmter Visa-Nachweisweg für Betrugsfälle. Verwenden Sie den Namen nicht als allgemeines Qualitätsmerkmal für ein gut geordnetes Paket. Frühere Zahlungen beantworten für sich genommen weder den Einwand einer gekündigten Verlängerung noch einer fehlenden Erstattung. Prüfen Sie Code und Anbietereignung vor der Vorbereitung dieses Wegs.
Der CE3.0-Leitfaden erklärt die Prüfung früherer Zahlungen und datumsabhängiger Anforderungen, ohne eine Abo-Historie mit automatischer Eignung gleichzusetzen.
Eine nachvollziehbare Erklärung übergeben
Evidenz wird für B2B- und B2C-SaaS-Teams entwickelt, die Zahlungen, Kontoaktivität und Supportunterlagen in einer Kunden-Timeline benötigen. Bei der Prüfung eines Reason Codes liegt der vorgesehene Nutzen in der Verbindung zwischen einer vorgeschlagenen Aussage und ihrem Beleg, einschließlich widersprechender Tatsachen.
Die Entscheidung bleibt beim verantwortlichen Team und die Einreichung beim autorisierten Verfahren des Zahlungsanbieters. Bewahren Sie Netzwerkcode, Kategorie, Kundenerklärung, Belegreferenzen, Entscheidung, Frist und tatsächlich eingereichte Version gemeinsam auf. So bleibt der Fall verständlich, ohne jede Beschwerde zur gleichen Schreibaufgabe zu machen.
Quellen und Einordnung
Quellenstand
Veröffentlicht von Evidenz. Die Beispiele erläutern den Prüfablauf. Prüfen Sie aktuelle Vorgaben und den konkreten Fall in den verlinkten Quellen.