Abrechnungsdeskriptoren: die günstigste Chargeback-Prävention

Ein Kunde schaut auf seine Kartenabrechnung, sieht eine Zeile, die er nicht erkennt, und tippt in seiner Banking-App auf „Widersprechen”. Die Bank erfasst es als Betrug. Für ein Abo-Geschäft ist das einer der häufigsten Wege, auf denen eine völlig berechtigte Belastung zum Chargeback wird, und die Lösung kostet nichts: Ändern Sie den Text in dieser Zeile.

Dieser Text ist der Statement Descriptor (auch Abrechnungsdeskriptor oder Soft Descriptor genannt). Dieser Ratgeber erklärt, was er ist, welche Regeln bei Stripe und Braintree gelten, wie Sie einen guten für Abos schreiben und was Kunden sonst hilft, eine Belastung zu erkennen. Quellen: Stripes Statement Descriptors, What is a statement descriptor, Why customers see descriptors that don’t match und Account-Checkliste; Braintrees Descriptors und Referenz Transaction: Sale; sowie Visas überarbeitete Enhanced-Descriptor-Richtlinie (alle abgerufen im November 2026).

Warum Deskriptoren Streitfälle auslösen

Der Deskriptor ist oft die einzige Information, die ein Kunde über eine Belastung hat, wenn er auf seine Abrechnung schaut. Drei Situationen erzeugen Streitfälle nach dem Muster „Das kenne ich nicht”:

1. Der Deskriptor zeigt die juristische Person, nicht die Marke. „ACME HOLDINGS LTD” sagt niemandem etwas, der „Planwise” abonniert hat.
2. Ein Unternehmen, mehrere Produkte. Wenn Sie drei Apps unter einem Konto betreiben und alle Belastungen denselben Namen zeigen, können Kunden nicht erkennen, für welches Abo sie zahlen.
3. Die Belastung kommt lange nach der Anmeldung. Eine Jahresverlängerung kommt elf Monate, nachdem der Kunde zuletzt an Sie gedacht hat. Ein klarer Name ist die einzige Erinnerung.

Diese Streitfälle kommen meist als Betrug herein (Visa 10.4, Mastercard 4863 „Karteninhaber erkennt die Belastung nicht”). Selbst wenn Sie sie gewinnen, zählen sie zu Ihren Dispute-Quoten bei den Netzwerken. Sie zu verhindern ist viel günstiger.

Die Regeln bei Stripe

Stripes Dokumentation zu Statement Descriptors legt für Kartenzahlungen diese Grenzen fest:

Regel	Grenze
Gesamtlänge	5 bis 22 Zeichen
Zeichen	Nur lateinische Zeichen; mindestens ein Buchstabe
Verbotene Zeichen	Spitze Klammern, einfache und doppelte Anführungszeichen und der Stern
Inhalt	Muss Ihren Geschäftsnamen (DBA), Ihre URL oder Ihren juristischen Namen widerspiegeln; darf nicht nur aus Zahlen bestehen

Präfix und dynamisches Suffix

Bei Stripe können Sie ein statisches Präfix (im Dashboard „shortened descriptor” genannt) mit einem dynamischen Suffix pro Zahlung kombinieren:

• Das Präfix hat 2 bis 10 Zeichen.
• Stripe verbindet Präfix und Suffix mit einem Stern und einem Leerzeichen, und dieses Trennzeichen zählt zu den 22 Zeichen. Bei einem Präfix mit 7 Zeichen bleiben 13 Zeichen für das Suffix.
• Dynamische Suffixe funktionieren nur bei Kartenzahlungen.
• Bei Kartenzahlungen werden nur die ersten 22 Zeichen übertragen; alles Längere wird abgeschnitten.

Bei Abos gehört das Produkt oder der Plan ins Suffix: PLANWISE* PRO ANNUAL.

Was der Kunde tatsächlich sieht

Stripes Support-Artikel zu abweichenden Deskriptoren erklärt, dass manche Banken statt Ihres Deskriptors einen „freundlichen” Händlernamen anzeigen, gebildet aus mehreren Datenpunkten der Transaktion, und dass Stripe auf diese Zuordnung keinen Einfluss hat. Stripes Account-Checkliste ergänzt, dass Banken auch andere Kontoinformationen anzeigen können, etwa Geschäftsname, Adresse, E-Mail oder Telefonnummer. Prüfen Sie, dass die öffentlichen Geschäftsdaten in Ihrem Zahlungsdienstleister-Konto (Support-Telefon, Support-URL) solche sind, die Kunden sehen dürfen, und dass sie funktionieren.

Die Regeln bei Braintree

Braintree unterstützt dynamische Deskriptoren pro Transaktion, aber sie sind nicht auf jedem Konto standardmäßig aktiviert. Die Referenz Transaction: Sale beschreibt das Namensformat:

Firmenteil	Produktteil	Gesamt mit Stern
3 Zeichen	bis zu 18	22
7 Zeichen	bis zu 14	22
12 Zeichen	bis zu 9	22

Braintree dokumentiert außerdem ein Telefon- und ein URL-Feld für Deskriptoren und weist darauf hin, dass die genauen Längen- und Zeichenregeln von Ihrem Prozessor abhängen und dass manche Prozessoren eine URL akzeptieren, andere nur eine Telefonnummer. Prüfen Sie Ihre Kontoeinstellungen, bevor Sie sich auf ein Format verlassen.

Wie ein guter Abo-Deskriptor aussieht

Prinzipien

1. Beginnen Sie mit dem Namen, den Kunden kennen. Die Marke in Ihrer App, Ihren E-Mails und Ihrem App-Icon, nicht die Holding.
2. Ergänzen Sie Produkt oder Plan, wenn Platz ist. Besonders, wenn Sie mehr als ein Produkt verkaufen oder Monats- und Jahrespläne haben.
3. Halten Sie ihn lesbar. Vermeiden Sie Abkürzungen, die niemand errät.
4. Seien Sie konsistent. Verwenden Sie denselben Deskriptor in Erinnerungen, Belegen und Hilfeartikeln, damit ein Kunde, der danach sucht, Sie findet.

Beispiele

Schwach	Besser	Warum
ACME HOLDINGS LTD	PLANWISE* PRO MONTHLY	Marke und Plan statt juristischer Person
AHL*SUB 88213	PLANWISE* TEAM ANNUAL	Keine internen Codes
PLANWISE	PLANWISE* RENEWAL	Signalisiert eine wiederkehrende Belastung
WWW.PLNWS.IO	PLANWISE.COM	Eine Domain, die der Kunde eintippen kann

Stellen Sie sicher, dass jedes Beispiel zu den Zeichenregeln Ihres Prozessors passt; der Stern in diesen Beispielen ist Stripes Trennzeichen, kein Zeichen, das Sie in das Präfix eingeben.

Testphasen

Wenn eine kostenlose Testphase umgewandelt wird, überrascht die erste Belastung am ehesten. Visa verlangte früher für diese erste Belastung nach einer Testphase einen erweiterten Deskriptor; die überarbeitete Richtlinie (Dezember 2020) hat ihn optional gemacht. Auch als Option hilft ein Suffix wie TRIAL END oder FIRST CHARGE bei dieser Zahlung, wenn Ihr Prozessor ein Suffix pro Zahlung erlaubt. Visas Regeln für Testphasen verlangen weiterhin mindestens sieben Tage vor dieser Belastung eine Erinnerung mit Kündigungslink.

Sagen Sie Kunden, was sie sehen werden

Der Deskriptor wirkt am besten, wenn der Kunde ihn schon einmal gesehen hat. Platzieren Sie ihn:

• auf der Checkout-Seite: „Auf Ihrer Abrechnung erscheint dies als PLANWISE* PRO.”
• in der Willkommensmail und jedem Beleg.
• in Erinnerungen zu Verlängerung und Testphasenende. Siehe Erinnerungen zur Verlängerung von Jahresplänen.
• in einem Hilfeartikel, dessen Titel der Deskriptor selbst ist, damit ein Kunde, der nach „PLANWISE PRO Belastung” sucht, ihn findet.

Stripes Best Practices zur Betrugsprävention empfehlen ebenfalls, Kunden auf Ihrer Website zu sagen, was sie auf ihrer Abrechnung sehen werden.

Prüfen Sie, wie es aussieht

Gehen Sie nicht davon aus. Machen Sie für jedes Produkt und jeden Plan einen echten Kauf mit Ihrer eigenen Karte und schauen Sie sich dann an:

• die vorgemerkte Transaktion in Ihrer Banking-App;
• die gebuchte Transaktion ein paar Tage später;
• die Monatsabrechnung.

Banken und Apps zeigen Deskriptoren unterschiedlich an, und manche ersetzen sie durch einen freundlichen Namen. Wenn Sie nicht sehen, was Sie eingestellt haben, kontaktieren Sie Ihren Zahlungsdienstleister.

Messen Sie den Effekt

Vergleichen Sie nach einer Änderung des Deskriptors in den folgenden Monaten:

• den Anteil der Streitfälle mit Reason Codes „nicht erkannt” oder Betrug bei bestehenden Kunden;
• Support-Tickets mit der Frage „Was ist das für eine Belastung?“;
• Inquiries und Retrievals (bei Netzwerken, die sie noch nutzen).

Streitfälle kommen Wochen nach der Belastung, geben Sie der Änderung also mindestens zwei Abrechnungszyklen, bevor Sie urteilen.

Checkliste für Deskriptoren

• Markenname, den Kunden kennen, nicht die juristische Person.
• Suffix mit Produkt oder Plan, wo unterstützt.
• Innerhalb der Längen- und Zeichenregeln Ihres Prozessors.
• Öffentliches Support-Telefon und URL eingetragen und funktionsfähig.
• Deskriptor im Checkout, in Belegen und Erinnerungen und im Hilfecenter genannt.
• Mit einer echten Karte getestet.
• Eigener Deskriptor pro Produkt, wenn Sie mehrere verkaufen.

Den Rest des Präventionsplans finden Sie unter Chargebacks bei Abos verhindern.

Umsetzung mit NoChurn

NoChurn legt Ihren Deskriptor nicht fest; das bleibt in Stripe oder Braintree. NoChurn zeigt jeden Streitfall mit seinem Grund, damit Sie sehen, ob Streitfälle wegen „nicht erkannt” und Betrug nach Ihrer Änderung zurückgehen, und sammelt automatisch Beweise, wenn trotzdem ein Streitfall kommt (Antworten im Kündigungsflow, gesendete E-Mails, Nutzung, die Sie per API senden, Helpdesk-Gespräche nur lesend), mit einer von der KI entworfenen Antwort, die ein Mensch vor dem Versand prüft. Siehe Chargebacks.