Fehlgeschlagene Zahlungen

Fehlgeschlagene Zahlungen sind ein regelmäßig vorkommender Vorgang im Subscription Business.

Ursachen können zum Beispiel mangelnde Kontodeckung, abgelaufene Kreditkarten, Rücklastschriften, abgelehnte PayPal-Zahlungen, nicht ausgeführte Überweisungen oder technische Probleme bei Zahlungsanbietern sein.

tebio bildet fehlgeschlagene Zahlungen transparent ab, dokumentiert Zahlungsversuche, unterstützt die Nachverfolgung offener Forderungen und kann externe Systeme über Webhooks informieren.

Dieser Artikel erklärt, wie fehlgeschlagene Zahlungen in tebio behandelt werden und welche Unterschiede zwischen Prepaid- und Postpaid-Szenarien bestehen.

Grundprinzip

Eine fehlgeschlagene Zahlung bedeutet, dass ein erwarteter oder ausgelöster Zahlungsvorgang nicht erfolgreich abgeschlossen wurde.

Das kann unterschiedliche Auswirkungen haben:

eine Bestellung wird nicht abgeschlossen
eine Subscription wird nicht aktiviert
eine Verlängerung wird nicht durchgeführt
eine Rechnung bleibt offen
ein Mahnprozess wird ausgelöst
ein externer Service wird gesperrt oder eingeschränkt
ein Support- oder Finance-Prozess wird notwendig

Welche Folge ein Zahlungsfehler hat, hängt insbesondere von folgenden Faktoren ab:

Faktor	Bedeutung
paymentStrategy	Prepaid oder Postpaid
Zahlungsmethode	Kreditkarte, PayPal, SEPA-Lastschrift, Überweisung oder andere Methode
Produktkonfiguration	Aktivierung, Verlängerung, Sperrung oder Kündigung
Zahlungsstatus	offener, erfolgreicher oder fehlgeschlagener Zahlungsversuch
Rechnungstatus	offene, bezahlte oder überfällige Rechnung
Dunning-Konfiguration	automatische Zahlungserinnerung oder manueller Mahnprozess
Webhooks	Benachrichtigung externer Systeme über Zahlungsereignisse

Unterschiede zwischen Prepaid und Postpaid

Der Umgang mit fehlgeschlagenen Zahlungen unterscheidet sich deutlich zwischen Prepaid und Postpaid.

Prepaid: Zahlung vor Leistung

Bei Prepaid-Modellen muss die Zahlung erfolgreich abgeschlossen sein, bevor die Leistung vollständig bereitgestellt oder verlängert wird.

Typische Fälle:

Kunde zahlt direkt im Checkout
Kunde nutzt Kreditkarte, PayPal oder eine andere direkte Online-Zahlungsmethode
Subscription wird erst nach erfolgreicher Zahlung aktiviert
Verlängerung setzt erfolgreiche Vorauszahlung voraus

Wenn eine Prepaid-Zahlung fehlschlägt, wird die Leistung in der Regel nicht aktiviert oder nicht verlängert.

Typische Auswirkungen:

Bestellung bleibt ausstehend oder wird abgebrochen
Subscription wird nicht aktiviert
Verlängerung wird nicht durchgeführt
Kunde muss Zahlungsmethode aktualisieren oder erneut bezahlen
externe Systeme werden über den Fehler informiert, sofern Webhooks konfiguriert sind

Beispiel:

Ein Kunde bucht eine digitale Subscription über eine Hosted Page und bezahlt per Kreditkarte. Die Kreditkarte wird abgelehnt. In diesem Fall wird die Bestellung nicht erfolgreich abgeschlossen und die Subscription nicht aktiviert.

Postpaid: Leistung vor Zahlung

Bei Postpaid-Modellen wird die Leistung zunächst erbracht und später abgerechnet.

Typische Fälle:

Rechnung mit Zahlungsziel
Zahlung per Überweisung
SEPA-Lastschrift nach Rechnungserstellung
B2B-Abrechnung
monatlicher Billrun
nutzungsbasierte Abrechnung

Wenn eine Postpaid-Zahlung fehlschlägt, bleibt die Rechnung in der Regel weiterhin bestehen. Der offene Betrag muss weiterhin beglichen werden.

Typische Auswirkungen:

Rechnung bleibt offen oder wird überfällig
Zahlungstransaktion wird als fehlgeschlagen dokumentiert
Dunning oder manueller Klärungsprozess kann starten
Finance-Team prüft offene Forderung
Kunde wird zur Zahlung aufgefordert
externe Systeme können per Webhook informiert werden

Beispiel:

Eine Rechnung wurde erstellt und per SEPA-Lastschrift eingezogen. Die Bank meldet einige Tage später eine Rücklastschrift. Die Zahlung ist fehlgeschlagen, die Rechnung bleibt jedoch weiterhin offen.

Typische Ursachen fehlgeschlagener Zahlungen

Fehlgeschlagene Zahlungen können unterschiedliche Ursachen haben.

Ursache	Typisches Beispiel
Mangelnde Kontodeckung	SEPA-Lastschrift wird zurückgegeben
Abgelaufene Kreditkarte	Kartenzahlung wird vom Anbieter abgelehnt
Ungültige Zahlungsdaten	Mandat, IBAN oder Kartendaten sind fehlerhaft
Widerspruch des Kunden	Kontoinhaber widerspricht einer Lastschrift
Technisches Problem	Zahlungsanbieter ist temporär nicht erreichbar
Manuelle Überweisung fehlt	Kunde zahlt nicht innerhalb des Zahlungsziels
Zahlungsanbieter lehnt ab	Betrugsprüfung, Limit oder Anbieterregel verhindert Zahlung
Zahlungsmethode nicht mehr gültig	gespeicherte Zahlungsmethode kann nicht mehr genutzt werden

Die genaue Ursache hängt von der Zahlungsmethode und vom Zahlungsanbieter ab.

Zahlungsstatus und Transaktionsstatus

Jeder Zahlungsversuch wird in tebio als Zahlung oder Zahlungstransaktion dokumentiert.

Wenn ein Zahlungsversuch endgültig fehlschlägt, erhält die Transaktion einen entsprechenden Fehlerstatus. Je nach Statusmodell kann dies zum Beispiel ein Status wie CLOSED_FAILED sein.

Ein fehlgeschlagener Zahlungsstatus bedeutet:

Der konkrete Zahlungsversuch war nicht erfolgreich.
Es ist kein Geld eingegangen.
Die zugrunde liegende Rechnung kann weiterhin offen sein.
Ein neuer Zahlungsversuch oder eine andere Zahlungsmethode kann erforderlich sein.
Ein Mahn- oder Klärungsprozess kann starten.

Wichtig: Für eine fehlgeschlagene Zahlung kann keine Erstattung über tebio ausgelöst werden, weil kein erfolgreicher Zahlungseingang stattgefunden hat.

Fehlgeschlagene Zahlungen im Portal prüfen

Fehlgeschlagene Zahlungen können im tebio Business-Portal nachvollzogen werden.

Typische Prüfpunkte:

Öffnen Sie den betroffenen Kunden.
Prüfen Sie die Rechnungen des Kunden.
Öffnen Sie die betroffene Rechnung.
Prüfen Sie den Zahlungsstatus.
Öffnen Sie die Zahlungs- oder Transaktionsdetails.
Prüfen Sie Rückmeldungen des Zahlungsanbieters.
Prüfen Sie den Ereignisverlauf.
Prüfen Sie, ob bereits Nachrichten oder Mahnungen versendet wurden.

Je nach Konfiguration und Zahlungsart können zusätzliche Informationen sichtbar sein, zum Beispiel:

Zahlungsanbieter
Transaktionsreferenz
Fehlergrund
Rückgabecode
Zeitpunkt des Zahlungsversuchs
verwendete Zahlungsmethode
nächster geplanter Schritt

Dunning: Zahlungserinnerung und Mahnwesen

Wenn eine Zahlung fehlschlägt oder eine Rechnung nach Ablauf des Zahlungsziels offen bleibt, kann ein Mahnprozess erforderlich sein.

Dieser Prozess wird häufig als Dunning bezeichnet.

Ziel des Dunning-Prozesses ist es, den Kunden strukturiert an die offene Zahlung zu erinnern und die offene Forderung nachvollziehbar weiterzuverfolgen.

Automatisierte Zahlungserinnerungen

tebio kann je nach Konfiguration automatische Nachrichten auslösen.

Typische Dunning-Stufen sind:

erste Zahlungserinnerung
zweite Zahlungserinnerung oder Mahnung
weitere Mahnstufe oder manueller Folgeprozess

Nachrichtenvorlagen können dynamische Informationen enthalten, zum Beispiel:

Kundennummer
Rechnungsnummer
offener Betrag
Fälligkeitsdatum
Zahlungsinformationen
Link zum Kundenportal
Hinweis zur Aktualisierung der Zahlungsmethode

Damit automatische Erinnerungen versendet werden, müssen Kommunikationskanäle, Ereignisauswahl und Nachrichtenvorlagen passend eingerichtet sein.

Manuelle Mahnprozesse

Nicht jedes Unternehmen nutzt ein vollständig automatisiertes Mahnwesen.

Gerade bei B2B-Kunden kann ein manueller oder halbautomatischer Prozess sinnvoll sein.

Typische Vorgehensweise:

offene Rechnungen im Business-Portal filtern
betroffene Kunden prüfen
Zahlungshistorie ansehen
Vertrieb oder Finance-Team einbeziehen
Kunden individuell kontaktieren
Zahlung manuell erfassen oder neuen Zahlungslauf auslösen
Vorgang im Ereignisverlauf nachvollziehen

Ein manueller Prozess ist besonders sinnvoll, wenn Kundenbeziehungen individuell betreut werden oder Zahlungsprobleme zuerst kaufmännisch geklärt werden sollen.

Zahlung erneut versuchen

Ob eine fehlgeschlagene Zahlung erneut versucht werden kann, hängt von Zahlungsmethode, Zahlungsanbieter und Prozesskonfiguration ab.

Typische Möglichkeiten:

Kunde aktualisiert die Zahlungsmethode.
Kunde zahlt per Überweisung.
Finance-Team erfasst einen Zahlungseingang manuell.
Ein neuer Zahlungseinzug wird ausgelöst.
Kunde startet den Zahlungsprozess erneut über eine Hosted Page oder das Kundenportal.
Der Zahlungsanbieter führt eigene Retry-Mechanismen aus.

Wichtig ist, vor einem erneuten Zahlungsversuch die Ursache zu prüfen.

Beispiele:

Bei abgelaufener Kreditkarte muss der Kunde die Karte aktualisieren.
Bei Rücklastschrift wegen mangelnder Deckung kann ein erneuter Einzug erst nach Klärung sinnvoll sein.
Bei falscher IBAN müssen Zahlungsdaten korrigiert werden.
Bei fehlender Überweisung ist ein Mahnprozess oder eine Zahlungserinnerung sinnvoll.

Zahlungsmethode aktualisieren

In Self-Service-Szenarien kann der Kunde seine Zahlungsmethode selbst aktualisieren, sofern das Kundenportal oder eine passende Hosted Page bereitgestellt wird.

Typische Anwendungsfälle:

Kreditkarte ist abgelaufen.
Kunde möchte von Kreditkarte auf SEPA wechseln.
SEPA-Mandat muss neu erteilt werden.
PayPal-Zahlung konnte nicht bestätigt werden.
Kunde möchte eine andere Zahlungsart verwenden.

Nach Aktualisierung der Zahlungsmethode kann je nach Prozess ein neuer Zahlungsversuch erforderlich sein.

Service-Sperrung und Leistungszugang

Bei digitalen Produkten oder SaaS-Angeboten soll ein externer Service nach fehlgeschlagener Zahlung möglicherweise gesperrt oder eingeschränkt werden.

Typische Maßnahmen:

Zugang wird deaktiviert
Nutzer wird in einen Read-Only-Modus versetzt
bestimmte Funktionen werden gesperrt
Verlängerung wird blockiert
Subscription wird pausiert oder gekündigt
Support- oder Finance-Team wird informiert

tebio kann externe Systeme über Zahlungsereignisse informieren. Das externe System entscheidet dann, wie der Leistungszugang angepasst wird.

Wichtig: Nicht jeder fehlgeschlagene Zahlungsversuch sollte sofort zur Sperrung führen. Oft ist eine Karenzzeit, eine Erinnerung oder eine mehrstufige Eskalation sinnvoll.

Webhooks

Webhooks informieren externe Systeme über Zahlungsereignisse und Folgeprozesse.

Typische Ereignisse können sein:

Zahlung fehlgeschlagen
Zahlung erfolgreich
Rechnung erstellt
Rechnung überfällig
Subscription verlängert
Subscription nicht verlängert
Subscription pausiert oder deaktiviert

Ein typisches Muster:

tebio erkennt eine fehlgeschlagene Zahlung.
tebio dokumentiert das Ereignis.
tebio sendet einen Webhook an ein externes System.
Das externe System prüft den Status der betroffenen Rechnung oder Subscription über die API.
Das externe System aktualisiert den Leistungszugang, das CRM oder das interne Monitoring.

Die konkreten Ereignistypen und Payloads sind in der API-Referenz beschrieben.

Reconciliation und offene Posten

Fehlgeschlagene Zahlungen sind eng mit dem Abgleich offener Posten verbunden.

Bei erfolgreicher Zahlung wird eine Zahlung mit einer offenen Rechnung abgeglichen.

Bei fehlgeschlagener Zahlung bleibt der offene Posten bestehen.

Typische Folgen:

Rechnung bleibt offen
Zahlungsstatus wird aktualisiert
Finanz-Journal dokumentiert den Vorgang
Dunning kann starten
Finance-Team muss prüfen
spätere Zahlung kann erneut abgeglichen werden

Reconciliation stellt sicher, dass Rechnung, Zahlung und Buchungsstatus konsistent bleiben.

Beispiel: Kreditkarte im Prepaid-Checkout schlägt fehl

Ein Kunde möchte eine Subscription über eine Hosted Page buchen.

Kunde wählt Produkt und Zahlungsmethode Kreditkarte.
Zahlungsanbieter lehnt die Karte ab.
Bestellung wird nicht erfolgreich abgeschlossen.
Subscription wird nicht aktiviert.
Kunde erhält eine Fehlermeldung im Checkout.
Kunde kann eine andere Zahlungsmethode verwenden oder Kartendaten aktualisieren.

In diesem Szenario entsteht typischerweise keine offene Postpaid-Forderung, weil die Leistung noch nicht erbracht wurde.

Beispiel: SEPA-Rücklastschrift bei Postpaid-Rechnung

Ein Geschäftskunde erhält eine monatliche Rechnung.

tebio erstellt die Rechnung im Billrun.
SEPA-Lastschrift wird ausgelöst.
Bank gibt die Lastschrift zurück.
Zahlungstransaktion wird als fehlgeschlagen dokumentiert.
Rechnung bleibt offen.
Kunde wird erinnert oder gemahnt.
Finance-Team prüft den Vorgang.
Kunde zahlt per Überweisung oder die Lastschrift wird nach Klärung erneut versucht.
Zahlung wird mit der offenen Rechnung abgeglichen.

Beispiel: SaaS-Zugang nach fehlgeschlagener Zahlung einschränken

Ein SaaS-Anbieter nutzt tebio für Subscription Management und Billing.

Eine Zahlung schlägt fehl.
tebio sendet ein Zahlungsereignis per Webhook.
Das SaaS-Backend ruft die betroffene Subscription über die API ab.
Das SaaS-Backend markiert den Account als zahlungsauffällig.
Nach einer konfigurierten Karenzzeit wird der Account eingeschränkt.
Nach erfolgreicher Zahlung wird der Zugang wieder freigeschaltet.

Dieses Muster verhindert, dass das SaaS-System ausschließlich auf lokale Zahlungsdaten angewiesen ist.

Typische Fehler vermeiden

Fehlgeschlagene Zahlung mit stornierter Rechnung verwechseln

Eine fehlgeschlagene Zahlung bedeutet nicht, dass die Rechnung ungültig ist.

Bei Postpaid bleibt die Rechnung in der Regel offen und muss beglichen oder fachlich korrigiert werden.

Sofort sperren ohne Karenzzeit

Eine sofortige Sperrung nach dem ersten fehlgeschlagenen Zahlungsversuch kann zu unnötigen Supportfällen führen.

Prüfen Sie, ob eine Zahlungserinnerung oder Karenzzeit sinnvoll ist.

Prepaid und Postpaid gleich behandeln

Bei Prepaid wird die Leistung häufig nicht aktiviert, wenn die Zahlung fehlschlägt.

Bei Postpaid besteht dagegen oft bereits eine offene Forderung.

Webhooks nicht verarbeiten

Wenn externe Systeme auf Zahlungsstatus reagieren müssen, sollten Webhooks verarbeitet werden.

Polling allein ist oft weniger effizient und kann Statusänderungen verzögert erkennen.

Fehlende Idempotenz bei Zahlungsereignissen

Webhook-Ereignisse können mehrfach zugestellt werden.

Externe Systeme sollten Zahlungsereignisse idempotent verarbeiten und keine doppelten Sperrungen, Freischaltungen oder Buchungen auslösen.

Keine Prüfung der Zahlungsdetails

Der HTTP- oder Portalstatus allein reicht häufig nicht aus.

Prüfen Sie Transaktionsdetails, Rückmeldungen des Zahlungsanbieters und den Ereignisverlauf.

Best Practices

Unterscheiden Sie klar zwischen Prepaid und Postpaid.
Prüfen Sie fehlgeschlagene Zahlungen im Kontext der betroffenen Rechnung oder Subscription.
Nutzen Sie Dunning-Vorlagen für transparente Kundenkommunikation.
Verarbeiten Sie Zahlungsereignisse über Webhooks.
Verwenden Sie Karenzzeiten, bevor digitale Leistungen gesperrt werden.
Lassen Sie Kunden Zahlungsmethoden im Self-Care / Kundenportal aktualisieren.
Testen Sie fehlgeschlagene Zahlungen im Playground.
Protokollieren Sie Zahlungsfehler in externen Systemen nachvollziehbar.
Stimmen Sie Service-Sperrung, Mahnwesen und Finance-Prozesse aufeinander ab.

API-Hinweis

Für API-Integrationen sind insbesondere folgende Bereiche relevant:

Bereich	Bedeutung
Payment	Zahlungsversuche, Zahlungsstatus und Transaktionsdetails
Invoice / Receipt	offene oder bezahlte Abrechnungsdokumente
Subscription	Status der laufenden Leistung und mögliche Folgeaktionen
Customer	Kundendaten und Zahlungsmethoden
Webhooks	Benachrichtigung externer Systeme über Zahlungsereignisse
Event History	Nachvollziehbarkeit von Zahlungs- und Folgeprozessen
Journal	buchhalterische Dokumentation von Zahlung und offenen Posten

Die genauen Statuswerte, Endpunkte, Webhook-Ereignisse und Payloads sind in der API-Referenz beschrieben.