Zahlungs- und Versandart gemeinsam im Checkout testen
Zahlungs- und Versandart gemeinsam im Checkout testen
~5 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Beide Bausteine sind einzeln fertig - Kapitel 62-65 die Zahlungsart, Kapitel 66-68 die Versandart. Weil beide auf demselben Punktestand operieren und über denselben Observer buchen, lohnt sich ein gemeinsamer, end-to-end durchgeführter Testlauf, bevor Kapitel 70 die typischen Fehler durchgeht.
Einmalig vorbereiten
Neue Datenbankspalte (Kapitel 63), neuer Data Patch (Kapitel 63), neue Konfigurationsgruppen (Kapitel 64/67) - all das braucht ein reguläres Setup-Upgrade, gefolgt vom Leeren des Konfigurations- und Full-Page-Caches:
cd src
bin/magento setup:upgrade
bin/cache-clean config full_page
Im Admin unter Stores > Configuration > Sales > Payment Methods bzw. Shipping Methods beide neuen Bausteine aktivieren, und einem Test-Kunden über die Konsole aus Kapitel 9 (mironsoft:loyalty:recalculate) oder direkt per SQL einen Punktestand oberhalb des konfigurierten points_cost (Versand) und ausreichend für mindestens einen Testartikel (Zahlung) zuweisen.
Testszenario 1: nur Versand über Punkte
- Artikel in den Warenkorb legen, zur Kasse gehen, Versandadresse eintragen.
- Im Versandart-Schritt muss "Kostenloser Versand durch Punkte" (Kapitel 67) neben den regulären Versandarten erscheinen, mit Preis 0.
- Bestellung mit einer regulären Zahlungsart abschließen.
- Nach Abschluss: Ledger-Historie des Kunden (Kapitel 51/45) muss einen neuen
TYPE_REDEEM-Eintrag in Höhe des konfiguriertenpoints_costzeigen,loyalty_points_balanceentsprechend reduziert.
Testszenario 2: Punkte decken die gesamte Bestellsumme
- Einen günstigen Testartikel in den Warenkorb legen, dessen Preis komplett von den verfügbaren Punkten gedeckt wird.
- Im Zahlungsart-Schritt zunächst "Alle Punkte einlösen" (Kapitel 65) anklicken - die angezeigte Bestellsumme muss auf 0 sinken.
- Erst DANACH darf "Mit Treuepunkten bezahlt" (Kapitel 62-64) in der Zahlungsart-Liste erscheinen - vorher war
isAvailable()(Kapitel 64) korrektfalse. - Bestellung abschließen, ohne dass ein echtes Zahlungs-Gateway kontaktiert wird.
- Ledger-Historie: ein
TYPE_REDEEM-Eintrag für die Zahlung,sales_order.loyalty_points_redeemed(Kapitel 63) korrekt befüllt.
Testszenario 3: beides gleichzeitig
Punkte teilweise einlösen (Zahlung) UND die Versandart über Punkte wählen (Versand), in derselben Bestellung. Nach Abschluss müssen in der Ledger-Historie GENAU ZWEI neue TYPE_REDEEM-Einträge für dieselbe order_id stehen (Kapitel 67s bookRedemption(), zweimal aufgerufen), und loyalty_points_balance um die Summe beider Beträge reduziert - nicht nur um einen der beiden.
Tipp: Der eigene Log-Kanal aus Kapitel 34 (var/log/mironsoft_loyalty.log) ist bislang nur an ExpirePoints verdrahtet - RedeemPointsOnOrderPlaced nutzt bewusst den Standard-Logger-Kanal (exception.log/system.log), genau wie AwardPointsOnOrderPlaced und ReversePointsOnCreditmemoSave aus Kapitel 34. Für die Fehlersuche in diesem Kapitel also:
bin/log mironsoft_loyalty.log
Achtung: Ein häufiger Fehlschluss beim manuellen Testen: Ein leerer Warenkorb-Cache (Kapitel 40, Prämienkatalog) hat mit Zahlungs-/Versandart-Sichtbarkeit nichts zu tun - bin/cache-clean config reicht für System-Konfigurationsänderungen aus Kapitel 64/67. Bleibt eine neu aktivierte Zahlungs- oder Versandart trotzdem unsichtbar, ist die Ursache fast immer eine der in Kapitel 70 gesammelten Fallen, kein Cache-Problem.
Alle drei Szenarien grün - Block 8 funktioniert vollständig. Kapitel 70 sammelt abschließend die Fehler, die beim Bau dieser neun Kapitel am häufigsten passieren.