HPOS und Checkout Blocks: was bei Zahlungsplugins kompatibel sein muss

Zwei Achsen statt eines Kompatibilitätsschalters

Eine Zahlungsmethode kann im Checkout richtig aussehen und spätere Bestelländerungen dennoch falsch behandeln. Sie kann auch Bestellungen korrekt speichern und im blockbasierten Checkout überhaupt nicht erscheinen. Diese Fehler sind verschieden. Das pauschale Etikett „WooCommerce-kompatibel“ hilft Händlern nur begrenzt, das Risiko einer Änderung einzuschätzen.

WooCommerce beschreibt HPOS als Bestellspeicherung mit eigenen Tabellen. Checkout Blocks besitzen eigene Integrationspunkte für Zahlungsmethoden. Daraus folgt: Eine Erklärung zur Speicherung beweist keinen funktionierenden Checkout. Umgekehrt beweist ein funktionierender Button keine korrekte Speicherung.

Beginne deshalb mit zwei Fragen: Welche Speicherkonfigurationen wurden geprüft, und welche Checkout-Erfahrungen wurden getestet? Die Antworten gehören in Versionshinweise und Supportinformationen. Ein nicht unterstützter Aufbau sollte nicht erst während einer echten Kundenzahlung sichtbar werden.

Bestellspeicherung als Plattformvertrag

WooCommerce sollte für sein Bestellmodell verantwortlich bleiben. Ein Gateway sollte die unterstützten Bestell-APIs verwenden, statt vorauszusetzen, dass eine bestimmte Tabelle in jeder Konfiguration die Bestellung repräsentiert. Sonst wirkt eine Zahlung erfolgreich, während eine Erstattung oder Hintergrundaufgabe eine andere Ansicht der Bestellung liest.

Bei einer Prüfung verfolgen wir den gesamten Lebenszyklus: Erstellung, Zahlungsbestätigung, Bestellnotizen, Statusänderungen, Erstattungen und Abgleich. Für jeden Schritt fragen wir, wo Daten gelesen und geschrieben werden und ob dieser Weg zum unterstützten Plattformmodell passt.

Kompatibilitätserklärungen sind nützliche Kommunikation, bleiben aber Erklärungen. Nachweise entstehen durch Tests der relevanten Speicherarten und durch die Kontrolle tatsächlicher Datensätze. Wenn eine Version eine Konfiguration unterstützt, muss ihr Abnahmeplan diese ausdrücklich enthalten. Eine gesetzte Kennzeichnung ersetzt keine Prüfung.

Ein Checkout braucht mehr als ein Logo

Der Checkout muss Verfügbarkeit vermitteln, nötige Eingaben erfassen, eine zusammenhängende Anfrage absenden und den nächsten Schritt erklären. Eine sichtbare Zahlungsmethode ohne funktionierenden Gesamtablauf ist keine vollständige Integration. Gleiches gilt für Fehlermeldungen, nach denen Kunden nicht wissen, ob sie nochmals bezahlen sollen.

Prüfe klassischen und blockbasierten Checkout getrennt, wenn beide unterstützt werden sollen. Teste einen Kauf, Eingabefehler, Ablehnung, Abbruch auf der Anbieterseite und Rückkehr nach Verbindungsverlust. Kontrolliere nach jedem Versuch die Beziehung zwischen Warenkorb, Bestellung und Zahlungsreferenz.

Wallets und Express-Optionen bringen zusätzliche Voraussetzungen mit. Ihre Anzeige kann von Anbieter, Konto, Gerät, Browser und Händlereinstellungen abhängen. Eine Integration sollte erwartete Nichtverfügbarkeit von einer Fehlkonfiguration unterscheiden. Versprich nicht, dass alle Kunden auf jedem Gerät sämtliche Optionen sehen.

Eine brauchbare Kompatibilitätsmatrix schreiben

Eine kleine konkrete Matrix ist hilfreicher als ein großes unbelegtes Versprechen. Erfasse Plugin-, WordPress-, WooCommerce- und PHP-Version, Checkout-Typ, Speicherart, Theme und relevante Erweiterungen. Ergänze Anbieterumgebung und Zahlungsart, damit andere den Ablauf nachvollziehen können.

Nenne für jede unterstützte Kombination die tatsächlich getesteten Abläufe. „Checkout geladen“ ist etwas anderes als „Kartenzahlung mit Challenge abgeschlossen, Bestätigung erhalten und Erstattung verarbeitet“. Ein Ergebnis sollte auch benennen, was außerhalb der Prüfung blieb, statt sämtliche Bedingungen in einer grünen Zelle zu verstecken.

Nicht jede denkbare Kombination lässt sich testen. Lege einen dokumentierten Supportbereich fest und priorisiere tatsächliche Kundenkonfigurationen. Neue Themes oder Erweiterungen gehören nicht automatisch zum Supportversprechen, nur weil sie dieselbe Plattform verwenden. Erweitere die Matrix, sobald belastbare Nachweise vorliegen.

Shop-Bedingungen machen Annahmen sichtbar

Ein sauberer Entwicklungs-Shop ist hilfreich, bildet aber nicht jeden Live-Shop ab. Steuern, Versand, Rabatte, Währungsgenauigkeit, Caches, Sicherheitswerkzeuge und Bestell-Erweiterungen verändern das Umfeld einer Zahlung. Die Prüfung sollte sich auf Kombinationen konzentrieren, die das Produkt tatsächlich unterstützen möchte.

Nutze eine Staging-Umgebung mit dem vorgesehenen Aufbau, bereinigten Testdaten und der Testumgebung des Zahlungsanbieters. Vergleiche angezeigten Betrag und Währung mit der Serveranfrage. Prüfe Gastkäufe und angemeldete Kunden, soweit unterstützt, sowie Änderungen an Checkout-Daten vor dem Absenden.

Caches verdienen besondere Aufmerksamkeit. Warenkorb, Kundensitzung und Zahlungsantwort sind keine öffentlichen Marketingseiten. Auch Sicherheitsregeln für Browseraufrufe können einen Server-Callback stören. Untersuche den konkreten Pfad und seine Antwort, statt Schutzmaßnahmen pauschal auf der ganzen Website abzuschalten.

Nachweise an die konkrete Version binden

Ein brauchbarer Versionsnachweis umfasst das geprüfte Paket, seine Integritätsinformationen, Voraussetzungen und ein verständliches Änderungsprotokoll. Die Supportmatrix muss genau dieses Paket beschreiben. Wer nach einem erfolgreichen Test etwas anderes neu baut, schwächt die Aussagekraft der bisherigen Prüfung.

Updates benötigen einen eigenen Abnahmetest. Beginne mit einer unterstützten älteren Version, behalte deren Einstellungen und prüfe den Weg zur neuen Version. Untersuche das Ergebnis vor dem Live-Einsatz. Eine erfolgreiche Neuinstallation beweist keine sichere Aktualisierung eines bestehenden Shops.

Ein Auslieferungsplan sollte erklären, wie die Verteilung eines problematischen Pakets gestoppt wird und bestehende Installationen untersucht werden. Wiederherstellung hängt von der Änderung ab: Eine Datenmigration lässt sich nicht immer durch den Austausch von Plugin-Dateien rückgängig machen. Grenzen müssen klar sein, bevor Rollback als allgemeines Sicherheitsnetz gilt.

Was das heute für VivaGo bedeutet

VivaGo ist unser Zahlungsplugin für WooCommerce in Entwicklung. Wir veröffentlichen diese Kriterien, um unseren Ansatz zur Kompatibilität zu erläutern, nicht um eine fertige Supportmatrix anzukündigen. Geprüfte Versionen, Checkout-Typen, Anbieterfunktionen und Konfigurationsgrenzen werden die getestete Veröffentlichung begleiten.

Für Shop-Betreiber lautet die praktische Frage: Wurde genau diese Produktversion mit meinem Checkout und meiner Bestellspeicherung geprüft, und was geschah bei einer verspäteten Zahlungsbestätigung? Das ist eine bessere Entscheidungsgrundlage als die unbegrenzte Behauptung, ein Plugin funktioniere mit jedem WooCommerce-Shop.

Wenn du das geplante Produkt beurteilst, teile uns die für deinen Shop wichtigen Versionen und Erweiterungen mit. Das macht die Kompatibilitätsdiskussion konkret. Es ersetzt weder Tests noch eine verbindliche Funktionszusage, liefert aber eine reproduzierbare Konfiguration für die Bewertung.

Quellen und weiterführende Dokumentation

• WooCommerce: compatibility and interoperability for extensions
• WooCommerce: HPOS extension recipe book
• WooCommerce: Checkout block payment method integration