Bestellungen und Bank abgleichen: Zahlungen erkennen, die Ihr Shop zu haben glaubt und Sie nicht haben
Dass eine Bestellung „Zahlung eingegangen“ anzeigt, heißt nicht, dass das Geld auf Ihrem Konto ist. Wir erklären, warum Bestellungen, Zahlungsanbieter und Bank auseinanderlaufen, wie Sie sie jede Woche abgleichen und was zu tun ist, wenn eine bezahlte Bestellung auftaucht, deren Geld niemand erhalten hat.
Das Backoffice zeigt „Zahlung eingegangen“, und die Bestellung geht ins Lager. Das ist der Normalfall, und fast immer stimmt es auch. Aber diesen Status schreibt Ihr Shop, nicht Ihre Bank: Er gibt wieder, was der Shop glaubt, dass passiert ist. Das Geld bestätigen zwei andere Stellen, das Dashboard des Zahlungsanbieters und der Kontoauszug, und wenn niemand sie mit den Bestellungen vergleicht, kann eine Abweichung monatelang bestehen.
Das ist keine theoretische Ausnahme. Wir haben Shops gesehen mit „bezahlten“ Bestellungen, deren Geld auf dem Konto eines anderen gelandet war, Shops mit zwei Bestellungen pro Zahlung und Shops mit Zahlungen, aus denen nie eine Bestellung wurde. In allen Fällen hätte ein wöchentlicher Abgleich das innerhalb weniger Tage aufgedeckt.
Warum Bestellungen, Zahlungsanbieter und Bank auseinanderlaufen
Umgeleitete Zahlungen
Das ist der schwerwiegendste Fall. Jemand mit Zugriff auf die Dateien des Shops —über ein gestohlenes FTP-Passwort oder ein verwundbares Modul— verändert das Zahlungsmodul so, dass der Kunde bei einem Zahlungsanbieter des Angreifers bezahlt. Die Bestellung wird mit dem Namen des legitimen Moduls angelegt, der Status ist der übliche, und im Backoffice sieht alles normal aus. Es gibt nur einen Unterschied: Im Dashboard Ihres Zahlungsanbieters existiert diese Transaktion nicht.
Die einfache Variante: Die IBAN für die Banküberweisung wird in der Konfiguration geändert. Der Kunde zahlt, die Bestellung bleibt offen, der Kunde besteht darauf, bezahlt zu haben, und Sie finden den Zahlungseingang nicht.
Doppelte oder verlorene Benachrichtigungen
Der Zahlungsanbieter teilt Ihrem Shop über eine Benachrichtigung mit, dass die Zahlung abgeschlossen ist (IPN, Webhook oder die Rückkehr des Kunden in den Shop). Kommen zwei gleichzeitig an, können Sie am Ende zwei Bestellungen für eine einzige Zahlung haben, jede mit eigener Rechnung und abgebuchtem Bestand. Kommt keine an, haben Sie den umgekehrten Fall: eine Zahlung ohne Bestellung und einen Kunden, der bezahlt hat und nichts bekommt.
Manuelle Änderungen und Erstattungen außerhalb des Shops
- Ein Mitarbeiter markiert eine Überweisungsbestellung als bezahlt, bevor er den Zahlungseingang sieht.
- Im Dashboard des Zahlungsanbieters wird eine Erstattung ausgelöst, und die Bestellung bleibt bezahlt.
- Eine Rückbuchung (Chargeback) kommt herein, und die Bestellung bekommt davon nichts mit.
Auszahlungen sind keine Bestellungen
Zahlungsanbieter zahlen nicht Bestellung für Bestellung aus: Sie rechnen in Sammelauszahlungen ab und ziehen Gebühren, Erstattungen und Rückbuchungen ab. Deshalb lässt sich die Bank nicht direkt mit den Bestellungen abgleichen; der Zwischenschritt über den Zahlungsanbieter ist nötig.
Die zwei Abgleiche, die nötig sind
Abgleichen heißt, drei Quellen in zwei Schritten gegenüberzustellen:
- Bestellungen ↔ Transaktionen des Zahlungsanbieters. Jede mit Karte, Bizum oder PayPal bezahlte Bestellung muss ihre Transaktion im Dashboard haben, mit demselben Betrag. Und jede eingezogene Transaktion muss ihre Bestellung haben.
- Transaktionen ↔ Gutschriften auf dem Bankkonto. Die Summe der Transaktionen eines Zeitraums, abzüglich Gebühren, Erstattungen und Rückbuchungen, muss dem entsprechen, was Ihnen der Zahlungsanbieter überwiesen hat.
Der erste Schritt deckt Umleitungen und Duplikate auf. Der zweite deckt unerwartete Gebühren, Einbehalte und ausbleibende Auszahlungen auf.
Der wöchentliche Abgleich, Schritt für Schritt
- Exportieren Sie die bezahlten Bestellungen der Woche mit Referenz, Gesamtbetrag, Zahlungsmodul und Transaktionsnummer. In PrestaShop steht diese Nummer meist bei der Zahlung der Bestellung (Tabelle
ps_order_payment, Feldtransaction_id), manche Module speichern sie aber in eigenen Tabellen. - Exportieren Sie die Transaktionen aus dem Dashboard jedes Zahlungsanbieters für denselben Zeitraum, mit Nummer, Betrag und Status.
- Gleichen Sie über die Transaktionsnummer ab, nicht über den Betrag. Zwei Bestellungen zu 49,90 €, über den Betrag abgeglichen, gelten als korrekt, auch wenn eine davon gefälscht ist.
- Erstellen Sie drei Listen: Bestellungen ohne Transaktion, Transaktionen ohne Bestellung und Beträge, die nicht übereinstimmen.
- Gleichen Sie die Auszahlungen des Zahlungsanbieters mit den Gutschriften auf dem Kontoauszug ab.
- Notieren Sie, was Sie mit jeder Abweichung gemacht haben. An eine unerklärte Abweichung erinnert sich nächste Woche niemand mehr.
| Was Sie finden | Wahrscheinliche Ursache | Was zu tun ist |
|---|---|---|
| Bezahlte Bestellung ohne Transaktion beim Zahlungsanbieter | Umgeleitete Zahlung oder manuell geänderter Status | Nicht versenden; die Dateien des Zahlungsmoduls prüfen und wer den Status geändert hat |
| Zwei Bestellungen, eine Transaktion | Doppelte Benachrichtigung | Die überzählige stornieren und ihren Bestand zurückbuchen; ihre Rechnung mit einer Stornorechnung aufheben, falls sie schon nummeriert wurde |
| Zwei Transaktionen, zwei Bestellungen aus demselben Warenkorb | Doppelte Belastung | Über die Erstattung entscheiden; sonst reklamiert der Kunde |
| Eingezogene Transaktion ohne Bestellung | Verlorene Benachrichtigung | Die Bestellung anlegen oder die Zahlung erstatten und den Kunden informieren |
| Abweichender Betrag | Teilerstattung außerhalb des Shops, falsch addierte Versandkosten | Bestellung und Rechnung korrigieren |
Überweisung, Nachnahme und manuelles Bizum
Bei Zahlungsarten ohne automatische Benachrichtigung wird die Bestellung bezahlt, weil ein Mensch das entscheidet. Die Regel ist einfach: Als bezahlt markiert wird nur mit dem Kontoauszug vor Augen, nie weil der Kunde einen Screenshot des Belegs schickt, der sich in einer Minute fälschen lässt. Und prüfen Sie ab und zu, ob die IBAN, die Ihr Shop in der Bestellbestätigung und in den E-Mails anzeigt, wirklich Ihre ist.
Anzeichen dafür, dass etwas umgeleitet wird
- Transaktionsnummern mit einem anderen Format als dem für diesen Zahlungsanbieter üblichen.
- Ein Zahlungsanbieter, der in den Auszahlungen weniger einnimmt, als die Bestellungen angeben.
- Kunden, die angeben, bezahlt zu haben, und deren Zahlung in keinem Dashboard auftaucht.
- Dateien des Zahlungsmoduls mit einem Änderungsdatum, das zu keinem Update passt.
- Änderungen an der Konfiguration der Zahlungsanbieter, an die sich niemand im Team erinnert.
Warum es auch darum geht, den Shop aktuell zu halten
Um Zahlungen umzuleiten, muss jemand auf Ihren Server schreiben können. Die häufigsten Wege sind gestohlene Zugangsdaten für FTP oder das Hosting-Panel und Module mit bekannten Sicherheitslücken, die niemand aktualisiert hat. Ein Shop mit aktuellem PrestaShop, PHP und aktuellen Modulen und mit überprüften Zugangskonten macht es dem Angreifer deutlich schwerer. Der Abgleich deckt das Problem auf; das Update verringert, wie oft es überhaupt passiert.
Checkliste
- Abgleich Bestellungen ↔ Zahlungsanbieter jede Woche, über die Transaktionsnummer.
- Abgleich Zahlungsanbieter ↔ Bank bei jeder Auszahlung.
- Überweisungen nur mit Kontoauszug als bezahlt markieren.
- Regelmäßige Prüfung der IBAN und der Schlüssel der Zahlungsanbieter in der Konfiguration.
- Warnung, wenn sich die Dateien der Zahlungsmodule ändern.
- Protokoll jeder Abweichung und ihrer Klärung.
So lösen Sie es in PrestaShop
RKR Order Guard verhindert doppelte Bestellungen, wenn zwei Benachrichtigungen des Zahlungsanbieters gleichzeitig eintreffen, und durchsucht den Verlauf nach den bereits vorhandenen, die es danach einordnet, ob es eine oder zwei Zahlungen gibt: Die überzählige wird auf Storniert gesetzt und ihr Bestand zurückgebucht, über Erstattungen entscheidet ein Mensch. Außerdem überwacht es umgeleitete Zahlungen auf zwei Ebenen: Es prüft die Transaktionsnummer jeder Bestellung (per Signatur bei Redsys, anhand des Formats der Kennung bei PayPal, PayPlug und Stripe) und speichert den Fingerabdruck der Dateien Ihrer Zahlungsmodule, um Sie zu warnen, wenn sie sich ohne Update ändern. Die Warnung erscheint in der Bestellansicht, dort, wo derjenige arbeitet, der sie versendet. RKR Security Alert ergänzt die Überwachung: Es speichert einen Schnappschuss der Konfiguration, der Module und der Mitarbeiter, stuft Änderungen an den Zahlungsanbietern als kritisch ein, auch wenn sie direkt per SQL vorgenommen werden, und benachrichtigt Sie per Telegram.