# Chargeback-Fristen: Maßgeblich ist der aktuelle Fall [Von Evidenz](https://evidenz.dev/de) 4 Minuten Lesezeit Für Chargebacks gibt es keine einheitliche Antwortfrist. Maßgeblich sind Datum und Uhrzeit im aktuellen Fall beim Zahlungsanbieter. Die Zeitzone muss erkennbar bleiben. Ein gespeicherter Entwurf ist keine eingereichte Antwort. Eine frühere interne Freigabe lässt Zeit, fehlerhafte Dateien oder eine gescheiterte Übermittlung zu korrigieren. Die Antwortfrist eines Chargebacks bestimmt, bis wann die Stellungnahme zu einem konkreten Zahlungsstreit beim Zahlungsanbieter eingereicht werden muss. Sie ist weder die Frist für eine Reklamation durch den Karteninhaber noch der Termin für die Entscheidung der Bank. Öffnen Sie den aktuellen Fall, bevor Sie die Bearbeitung planen. Eine vertraute Anzahl von Tagen ersetzt das tatsächliche Fälligkeitsdatum nicht. ## Ist das Chargeback-Zeitlimit dieselbe Frist wie die Antwortfrist? Nein. Die Frist des Kunden für eine Anfechtung, Ihre Anbieterfrist für Nachweise und die Prüfzeit der Bank betreffen unterschiedliche Ereignisse. Ein Artikel darüber, wie lange ein Karteninhaber eine Zahlung beanstanden kann, nennt damit noch keine Antwortfrist für Ihr SaaS-Team. Maßgeblich bleibt die Frist des aktuellen Falls. Auch eine spätere [Pre-Arbitration-Nachricht](https://evidenz.dev/de/articles/chargeback-pre-arbitration) benötigt eigenen Stand, angeforderte Aktion und Anbieteranweisung. Übernehmen Sie nicht einfach das ursprüngliche Antwortdatum. ## Frist und Fallkennung zusammen erfassen Halten Sie die Dispute-ID, die betroffene Zahlung, den aktuellen Status, die Antwortfrist und den Zeitpunkt der Prüfung fest. Benennen Sie eine verantwortliche Person mit Einreichungsrechten im richtigen Anbieter-Konto sowie eine Vertretung mit den nötigen Zugriffsrechten. [Stripe beschreibt eine begrenzte Antwortfrist, die vom Kartennetzwerk abhängt.](https://docs.stripe.com/disputes/responding) Das API-Beispiel enthält die fallbezogene Frist als [`evidence_details.due_by`](https://docs.stripe.com/disputes/api). Verwenden Sie diesen Wert, statt vom Eingang einer Benachrichtigungs-E-Mail ein festes Zeitfenster abzuzählen. Die Nachricht kann verspätet gelesen oder an das falsche Team weitergeleitet worden sein. Erfassen Sie auch das Anbieter-Konto. Bei mehreren Konten kann selbst eine richtige Dispute-ID in das falsche Dashboard führen. Eine Benachrichtigung sollte den konkreten Fall öffnen und zeigen, wer den nächsten Schritt übernimmt. Fristfelder unterscheiden sich zwischen Systemen. [Die Disputes-API von Checkout.com stellt `evidence_required_by` zusammen mit Zahlungs- und Falldaten bereit.](https://api-reference.checkout.com/tag/disputes) Eine anbieterübergreifende Warteschlange sollte Quellfeld und Fallkennung auch bei einer gemeinsamen Fristspalte erhalten. Erfinden Sie kein einheitliches Standardintervall für Fälle verschiedener Zahlungsanbieter. ## Uhrzeit und Zeitzone eindeutig machen Ein Kalendereintrag mit dem Text „Freitag“ lässt vieles offen. In welcher Zeitzone? Um wie viel Uhr? Wurde die Dashboard-Anzeige bereits in die Ortszeit der betrachtenden Person umgerechnet? Bewahren Sie bei API-Zeitstempeln den ursprünglichen Wert auf und zeigen Sie daneben sowohl UTC als auch die Ortszeit der zuständigen Person an. Kennzeichnen Sie die Zeitzone in exportierten Aufgabenlisten und bei Übergaben. Verarbeiten Sie einen Unix-Zeitstempel nicht versehentlich als Millisekundenwert, wenn der Anbieter Sekunden liefert. **Beispiel zur Veranschaulichung.** Ein Anbieter nennt den 6. November 2026 um 17:00 UTC als Frist. In Berlin ist es an diesem Tag dann 18:00 Uhr. Eine interne Prüfung um 17:00 Uhr Berliner Zeit lässt damit nur eine Stunde Puffer, keinen ganzen Arbeitstag. Das Beispiel erklärt die Umrechnung und nennt keinen allgemeinen Stichtag eines Anbieters. Zeigt ein Dashboard nur ein Datum, prüfen Sie die Erläuterung oder fragen Sie beim Anbieter nach der Auslegung. Setzen Sie nicht ohne Grundlage Mitternacht voraus. Gerade bei wiederkehrenden Kalendereinträgen sind feste Zeitverschiebungen wegen der Sommerzeit unzuverlässig. ## Vorbereitung und Einreichung trennen Verwenden Sie unterschiedliche Bearbeitungsstände: Untersuchung läuft, Nachweise zur Prüfung bereit, Einreichung freigegeben und Übermittlung bestätigt. Eine Datei im gemeinsamen Ordner belegt zunächst nur, dass diese Datei existiert. Legen Sie den internen Freigabetermin vor die externe Frist. Wie groß der Puffer sein sollte, hängt von Besetzung und Einreichungsprozess ab; er ist keine Vorgabe des Kartennetzwerks. Die prüfende Person braucht Zeit, eine falsche Zahlung, einen fehlenden Anhang, einen unlesbaren Export oder einen Uploadfehler zu erkennen. Die Abläufe unterscheiden sich. [Shopify Payments beschreibt die automatische Übermittlung vorhandener Antwortdaten am Fälligkeitstag.](https://help.shopify.com/en/manual/payments/chargebacks/resolve-chargeback) Auch in diesem Verfahren sollte das Team prüfen, was versandt wird. Übertragen Sie dieses Verhalten nicht ungeprüft auf andere Zahlungsanbieter oder eigene Integrationen. ## Kundengespräche gesondert weiterführen Während der Vorbereitung kann der Kunde eine Erstattung besprechen oder den [Chargeback zurücknehmen lassen](https://evidenz.dev/de/articles/withdrawn-chargeback). Halten Sie diese Gespräche fest. Schließen Sie die Antwortaufgabe aber erst, wenn der aktuelle Fall und die Anweisungen des Anbieters das rechtfertigen. Eine zugesagte Rückmeldung des Kunden verlängert die Einreichungsfrist nicht. Bleiben die Nachweise unvollständig, muss die verantwortliche Person rechtzeitig über Annahme oder Anfechtung entscheiden. Ein offenes Supportgespräch sollte diese Entscheidung nicht versehentlich vorwegnehmen. ## Prüfen, was der Anbieter angenommen hat Öffnen Sie den Fall nach der Einreichung erneut im Dashboard oder rufen Sie ihn über die API ab. Bewahren Sie Bestätigung, Fallstatus, Einreichungszeit und die versandte Fassung der Nachweise auf. Bei einer API-Anbindung sind ein erfolgreicher Datei-Upload und die erfolgreiche Einreichung der Stellungnahme zwei verschiedene Schritte. Scheitert eine Anfrage oder bleibt ihr Ergebnis unklar, prüfen Sie vor einem erneuten Versuch den aktuellen Fall. Ein lokaler „gesendet“-Vermerk genügt nicht. Die Aufgabe ist erst abgeschlossen, wenn der Datensatz beim Anbieter diesen Stand bestätigt. Ist die Frist abgelaufen, prüfen Sie den tatsächlichen Status und den verfügbaren Supportweg. Versprechen Sie nicht, dass ein verspäteter Anhang oder eine Kunden-E-Mail den Fall wieder öffnet. Halten Sie die Fehlerursache fest, damit sich die Übergabe, Benachrichtigung oder Übermittlung verbessern lässt. Der [Leitfaden zur Chargeback-Antwort](https://evidenz.dev/de/articles/respond-to-chargebacks) erklärt die Auswahl der Nachweise; dieser Ablauf sorgt dafür, dass die Entscheidung rechtzeitig im Fall ankommt. ### Der verantwortlichen Person einen brauchbaren Verlauf übergeben Evidenz ist darauf ausgerichtet, Teams in B2B- und B2C-SaaS-Unternehmen die Kundenhistorie verständlich zu machen, die vor Ablauf der Antwortfrist geprüft werden muss. Abrechnung, Supportzusagen, Kontoänderungen und relevante Aktivität gehören in eine dem Konto zugeordnete Untersuchung, in der offene Fragen klar benannt sind. Der Nutzen für die verantwortliche Person ist eine Übergabe, die die vorgeschlagene Antwort und ihre Nachweise erklärt, statt eine weitere Suche über mehrere Systeme auszulösen. Maßgeblich für das Handeln bleiben die aktuelle Frist und die Einreichungsbestätigung des Zahlungsanbieters. ## Quellen und Einordnung Quellenstand Oktober 2026 Veröffentlicht von Evidenz. Die Beispiele erläutern den Prüfablauf. Prüfen Sie aktuelle Vorgaben und den konkreten Fall in den verlinkten Quellen. - [Stripe: Respond to disputes](https://docs.stripe.com/disputes/responding) - [Stripe: Use the API to respond to disputes](https://docs.stripe.com/disputes/api) - [Shopify: Resolving a chargeback or inquiry](https://help.shopify.com/en/manual/payments/chargebacks/resolve-chargeback) - [Checkout.com: Disputes API reference](https://api-reference.checkout.com/tag/disputes) Kundenkontext ist unser Ausgangspunkt. Evidenz wird für B2B- und B2C-SaaS entwickelt: eine gemeinsame Kundenhistorie aus Abo-Abrechnung, Konten, Support und digitaler Produktnutzung. Melden Sie sich für Neuigkeiten zum frühen Zugang an. [Zur Warteliste](https://evidenz.dev/de#hero) ## Weiterlesen [6 Minuten Lesezeit ### Chargeback beantworten: SaaS-Stellungnahme mit Muster und Belegen](https://evidenz.dev/de/articles/respond-to-chargebacks)[5 Minuten Lesezeit ### Chargeback-Nachweise so aufbereiten, dass sie verständlich bleiben](https://evidenz.dev/de/articles/preparing-dispute-evidence-files)[4 Minuten Lesezeit ### Der Kunde hat den Chargeback zurückgenommen. Warum ist der Fall noch offen?](https://evidenz.dev/de/articles/withdrawn-chargeback) Canonical page: https://evidenz.dev/de/articles/dispute-response-deadlines