Stripe bezahlt, aber WooCommerce zeigt „Zahlung ausstehend“?

In Stripe steht eine erfolgreiche Zahlung. Im Shop wartet dieselbe Bestellung weiterhin auf Geld oder wurde inzwischen storniert. Bevor du den Kunden erneut bezahlen lässt oder die Bestellung freigibst, müssen Zahlung und Bestellung eindeutig zusammengeführt werden. Diese Anleitung hilft dir, die widersprüchlichen Anzeigen einzuordnen und die entscheidenden Belege zu sichern.

Ein dokumentierter Fall betrifft Adaptive Pricing im offiziellen WooCommerce Stripe Gateway: Zahlungen wurden erfolgreich verarbeitet, während die zugehörigen Bestellungen offen blieben. Der Bericht nennt Gateway-Versionen 11.0.1 und 11.1.1 sowie fehlende Bestellreferenzen im PaymentIntent. Er belegt einen konkreten Fehlerablauf, keine allgemeine Betroffenheit aller Installationen. Q1

Passt diese Anleitung zu deinem Problem?

Prüfe zunächst diese vier Fragen:

• Gibt es eine konkrete WooCommerce-Bestellung und einen dazu passenden Stripe-Zahlungsvorgang?
• Stimmen Betrag, Währung, Zeitpunkt und Verkaufsumgebung überein?
• Steht der Stripe-PaymentIntent tatsächlich auf succeeded?
• Bleibt die Bestellung trotzdem auf „Zahlung ausstehend“ oder wurde sie nachträglich storniert?

Steht die Stripe-Zahlung dagegen auf requires_capture, ist der Betrag zunächst autorisiert. Das ist ein anderer Zustand als eine abgeschlossene Zahlung. Auch processing bedeutet noch nicht, dass das Ergebnis feststeht. Ein erfolgreiches SetupIntent richtet wiederum eine Zahlungsmethode ein; es beweist keine Zahlung für die Bestellung. Q6

Prüfe zusätzlich die Beträge und spätere Bearbeitungen: requires_capture kann auch zu einer Teileinziehung gehören. Ein PaymentIntent kann nach einer Rückzahlung weiterhin succeeded anzeigen; die späteren Änderungen sind am Zahlungsobjekt beziehungsweise im Dashboard zu prüfen. Der Status allein ist deshalb keine vollständige Saldenprüfung. Q7

Warum Zahlung und Bestellung auseinanderlaufen können

Der Zahlungsvorgang und die Aktualisierung deiner Bestellung sind getrennte Schritte. Für die Diagnose brauchst du deshalb sowohl den Stripe-Datensatz als auch die Verarbeitung im Shop. Ein grüner Verbindungsstatus oder eine erfolgreiche HTTP-Antwort ersetzt diesen Abgleich nicht.

Im untersuchten Adaptive-Pricing-Fall kamen bestimmte Zahlungsereignisse mit HTTP 200 an, obwohl die Bestellung nicht zugeordnet wurde. Gleichzeitig fehlte die Anmeldung für checkout.session.completed. Das erklärt, weshalb „Webhook zugestellt“ und „Bestellung richtig aktualisiert“ getrennt geprüft werden müssen. Q1

Lege für deinen eigenen Fall drei Stationen nebeneinander: den Zahlungsvorgang, seine Ereigniszustellung und die Bestellnotizen. Suche die erste Station, an der eine eindeutige Verbindung fehlt. So wird aus „Stripe funktioniert nicht“ eine überprüfbare Frage: Ist die Zahlung noch offen, fehlt ein Ereignis, oder verarbeitet der Shop das Ereignis ohne passende Bestellung?

Ersthilfe: einen betroffenen Vorgang nachvollziehbar sichern

1. Starte bei einem konkreten Auftrag. Notiere Bestellnummer, Status, Betrag, Währung und Zeitpunkt mit Zeitzone. Wähle einen eindeutig betroffenen Vorgang. Eine vollständige Kundendatenliste hilft für diese erste Prüfung nicht.

2. Prüfe den Zahlungszustand direkt in Stripe. Halte PaymentIntent-ID, gegebenenfalls Checkout-Session-ID und den angezeigten Zustand fest. Achte darauf, dass du das richtige Konto und Live- beziehungsweise Testdaten betrachtest. Verwende für öffentlich geteilte Unterlagen Platzhalter; Zugangsschlüssel gehören nicht in ein Supportformular.

3. Vergleiche die Bestellnotizen. Gibt es eine Transaktionsreferenz? Wann wurde die Bestellung angelegt, zuletzt verändert oder storniert? Halte Abweichungen fest, ohne den Status bereits zu ändern. Für eine Prüfung ist die ursprüngliche Ereignisfolge wertvoller als ein nachträglich „bereinigter“ Datensatz.

4. Prüfe das tatsächlich verwendete Checkout-Verfahren. Dokumentiere die Adaptive-Pricing-Einstellung im Gateway und diejenige im Stripe-Konto getrennt. Im Originalfall genügte die Änderung im Stripe-Dashboard zunächst nicht, weil die Plugin-Einstellung separat zu betrachten war. Q1

5. Prüfe die Zustellung des konkreten Ereignisses. Welche Event-ID gehört zur Zahlung? An welchen Endpunkt wurde sie geschickt? Welchen Antwortstatus gab es? Ist der benötigte Ereignistyp abonniert? WooCommerce dokumentiert getrennte Live- und Testverbindungen sowie eine Funktion zum erneuten Konfigurieren der Webhooks. Nutze deren Anleitung passend zur installierten Version; lösche keine Endpunkte anderer Integrationen. Q4

6. Stelle die Shop-Logs daneben. Der Stripe-Gateway-Leitfaden beschreibt das Fehlerlogging und die Zuordnung über Bestell- und Zahlungsreferenzen. Sichere einen begrenzten Zeitraum um den Vorfall, einschließlich der Zeitzone. Fehlt das Logging für den alten Vorfall, kennzeichne diese Beweislücke. Q5

7. Entscheide erst nach dem Abgleich über den einzelnen Auftrag. Bei einer bestätigten Zahlung muss geklärt sein, welche Bestellung erfüllt werden soll und ob bereits eine Rückzahlung oder andere Bearbeitung erfolgte. Bei einer bloßen Autorisierung ist zunächst der vorgesehene Zahlungsablauf zu prüfen. Eine Massenänderung aller offenen Bestellungen ist dafür ungeeignet.

Gibt es bereits einen veröffentlichten Fix?

Stand 4. November 2026 war der zugehörige Wiederherstellungsansatz in PR #5634 noch offen und dem Meilenstein 11.2.0 zugeordnet. Das offizielle Pluginverzeichnis führte Stripe Gateway 11.1.1 vom 16. Oktober 2026. Eine Zielversion in einem Entwicklungsauftrag ist noch keine veröffentlichte Reparatur. Q2 Q3

Für deine Installation bedeutet das: Erfasse zuerst die Version des Stripe Gateways. Die Versionsnummer von WooCommerce selbst beantwortet diese Frage nicht. Vor einem Update solltest du dessen tatsächlichen Changelog und die passende Zahlungsart prüfen. Ein bisher erfolgreicher Test ersetzt außerdem nicht den Abgleich der schon betroffenen Bestellungen.

Häufige Fragen

Soll der Kunde einfach noch einmal bezahlen?

Zuerst den vorhandenen Zahlungsvorgang prüfen. Solange dessen Ergebnis unklar ist, schafft eine weitere Zahlung zusätzlichen Abstimmungsbedarf. Wenn die Zahlung erfolgreich war, sollte die weitere Bearbeitung auf diesen Vorgang Bezug nehmen.

Reicht HTTP 200 beim Webhook als Entwarnung?

Nein. Im beschriebenen Fall gab es erfolgreiche HTTP-Antworten ohne passende Statusänderung im Shop. Entscheidend ist, ob genau diese Zahlung genau dieser Bestellung zugeordnet und verarbeitet wurde. Q1

Kann ich alle betroffenen Bestellungen auf „Abgeschlossen“ setzen?

Das wäre keine belastbare Diagnose. Prüfe jede Bestellung auf Zahlungszustand, Zuordnung und bereits erfolgte Bearbeitung. Zahlungsabgleich und Entscheidung über die Auftragsabwicklung gehören zusammen; der gleiche Status ist nicht automatisch für alle Produkte und Geschäftsabläufe richtig.

Hilft es, Adaptive Pricing auszuschalten?

Das kann als gezielter, vorher dokumentierter Vergleichstest sinnvoll sein. Es ordnet aber keine alten Zahlungen rückwirkend zu. Prüfe die betreffende Einstellung und teste einen definierten Ablauf, statt mehrere Checkout-Optionen gleichzeitig zu verändern.

Warum ist requires_capture keine sichere Zahlungseingangsbestätigung?

Dieser Status steht für einen noch ausstehenden Einzug nach der Autorisierung. Bei succeeded ist der PaymentIntent-Zahlungsablauf erfolgreich abgeschlossen. Diese Unterscheidung gehört vor jede Entscheidung über einen vermeintlich bezahlten Auftrag. Q6

Welche Angaben helfen bei einer Anfrage?

Nenne Gateway-Version, Checkout-Verfahren, betroffenen Zeitraum und die beiden angezeigten Zustände. Ergänze einen bereinigten Logausschnitt und eine anonymisierte Zuordnung zwischen Bestellung, PaymentIntent und gegebenenfalls Checkout Session. Kundennamen, Kartenangaben und Geheimschlüssel sind dafür nicht erforderlich.

Fall beschreiben

Beschreibe, was Stripe anzeigt, was WooCommerce anzeigt und seit welcher Änderung die Abweichung auftritt. Ein einzelner sauber dokumentierter Auftrag ist ein guter Ausgangspunkt. Daraus lässt sich festlegen, welche Verbindung als Nächstes geprüft werden muss und welche Informationen noch fehlen.