Zustandsübergänge einer Bestellung — und was 6.7 daran ändert
Drei Aktionsnamen für Zahlungszustände sind in 6.7 verschwunden. Wer sie benutzt, bekommt keinen Fehler beim Update, sondern beim nächsten Zahlungseingang.
Eine Shopware-Bestellung hat nicht einen Zustand, sondern fünf. Und einer davon hat sich in 6.7 verändert — auf eine Art, die kein Update-Log meldet.
Die fünf Automaten
| Automat | Zustände | Übergänge (6.7) |
|---|---|---|
order.state | 4 | 6 |
order_delivery.state | 6 | 16 |
order_transaction.state | 12 | 62 |
order_transaction_capture.state | 3 | 4 |
order_transaction_capture_refund.state | 5 | 10 |
| Summe | 30 | 98 |
Die Zustände sind in 6.6.10.6 und 6.7.13.1 identisch: fünf Automaten, 30 Zustände. Die Übergänge nicht — 103 in 6.6, 98 in 6.7.
Alle fünf Änderungen stecken im Zahlungsautomaten.
Was genau passiert ist
Ein Übergang hat einen Aktionsnamen. Über diesen Namen wird er ausgelöst — über die API, aus einem Plugin, aus einer Flow-Aktion.
| Aktionsname | 6.6.10.6 | 6.7.13.1 |
|---|---|---|
authorize | 4 | 4 |
cancel | 9 | 9 |
chargeback | 2 | 2 |
do_pay | 4 | — entfallen |
fail | 5 | 5 |
paid | 7 | 9 |
paid_partially | 6 | 7 |
pay | 4 | — entfallen |
pay_partially | 4 | — entfallen |
process | — nicht vorhanden | 4 |
process_unconfirmed | 5 | 5 |
refund | 4 | 4 |
refund_partially | 3 | 3 |
remind | 2 | 2 |
reopen | 8 | 8 |
Drei Namen sind weg, einer ist neu:
do_pay→process. Eine reine Umbenennung, die vier Übergänge ziehen mit.pay→ geht inpaidauf.paidwächst von 7 auf 9 Übergänge; zwei Ziele gab es unter diesem Namen schon.pay_partially→ geht inpaid_partiallyauf. Von 6 auf 7.
Unter dem Strich: 12 Übergänge entfernt, 7 hinzugefügt, netto fünf weniger.
Warum das gefährlich ist
Das Update meldet nichts. Die Migration läuft durch, der Shop startet, alle Seiten laden. Die Tabelle ist einfach anders befüllt.
Der Fehler entsteht erst, wenn etwas einen Übergang mit einem entfallenen Namen auslösen will. Und das passiert nicht beim Testen der Startseite, sondern beim ersten echten Zahlungseingang.
Typische Stellen, an denen so ein Aufruf steckt:
- Ein Zahlungsanbieter-Plugin, das nach einer erfolgreichen Zahlung den Zustand setzt.
- Eine Warenwirtschaft, die Zahlungseingänge zurückmeldet.
- Ein eigenes Skript für den Bankabgleich.
- Eine Flow-Aktion, die einen Zahlungszustand setzt — was der Flow Builder dabei kann und wo seine Grenzen liegen, steht in Flow Builder: Auslöser, Aktionen und Grenzen.
Die Prüfung, die fünf Minuten dauert
Vor dem Sprung auf 6.7 den eigenen Code und die Konfiguration nach drei Zeichenketten durchsuchen:
do_pay
pay_partially
"pay"
Beim dritten ist Vorsicht nötig: pay ist ein kurzes Wort und kommt in
paid, payment und payable vor. Sinnvoll ist die Suche nach dem
vollständigen Aufruf, etwa transaction.state/pay oder actionName: 'pay'.
Findet sich nichts, ist die Sache erledigt. Findet sich etwas, ist es eine Änderung von zwei Zeichen — solange sie vor dem Update passiert.
Der Zusammenhang mit der primären Transaktion
Beide Befunde betreffen dieselbe Stelle: wie eine Integration an die richtige Zahlungstransaktion kommt und was sie damit tun darf. Dass 6.7 einen expliziten Verweis auf die maßgebliche Transaktion einführt, ihn aber noch nicht füllt, steht in Die primäre Transaktion einer Bestellung.
Zusammen ergibt das eine kleine Prüfliste für jede Bestellintegration vor 6.7:
| Prüfung | Fundstelle |
|---|---|
Aktionsnamen do_pay, pay, pay_partially | dieser Text |
| Zugriff auf „die letzte Transaktion" | primäre Transaktion |
| Vollständiges Zurückschreiben gelesener Datensätze | schreibgeschützte Felder |
Schreiben auf customer.default_payment_method_id | Schema-Delta |
Grenzen dieser Messung
Verglichen wurden die Zustandstabellen zweier frisch aufgesetzter Installationen. Nicht gemessen wurde, wie sich ein echtes Update auf einen Bestand auswirkt — insbesondere, ob eine Migration bestehende Verweise auf die alten Aktionsnamen irgendwo mitzieht.
Nicht gemessen wurde außerdem das Verhalten zur Laufzeit: Wir haben die Tabellen gelesen, nicht versucht, einen Übergang mit einem entfallenen Namen auszulösen. Dass ein solcher Aufruf scheitert, folgt aus dem Datenmodell, nicht aus einem Testlauf.
Wenn eine Integration daran angepasst werden muss, gehört das zu App- und Plugin-Entwicklung.
Häufige Fragen
- Wie viele Zustandsautomaten hat eine Bestellung?
- Fünf: die Bestellung selbst, die Lieferung, die Zahlungstransaktion sowie Einzug und Erstattung. Zusammen 30 Zustände — in 6.6 und 6.7 identisch.
- Welche Aktionsnamen sind in 6.7 entfallen?
- do_pay, pay und pay_partially. An die Stelle von do_pay tritt process; pay und pay_partially gehen in den bereits vorhandenen Namen paid und paid_partially auf.
- Merke ich das beim Update?
- Nein. Das Update läuft durch. Der Fehler entsteht erst, wenn etwas versucht, einen Übergang mit einem entfallenen Namen auszulösen — also beim nächsten Zahlungsvorgang.
- Wo kann so ein Aufruf stecken?
- In einem Zahlungsanbieter-Plugin, in einer ERP-Anbindung, die Zahlungen zurückmeldet, in einem eigenen Skript oder in einer Flow-Aktion, die einen Zustand setzt.