WooCommerce checkout werkt niet: een systematisch troubleshooting-plan

"De checkout werkt niet" is zes verschillende problemen die toevallig dezelfde zin delen. De klant die een blanco pagina ziet, de klant van wie de kaart bij de gateway wordt geweigerd, de klant van wie de pagina laadt maar de "Plaats bestelling"-knop niets doet, en de klant die een 403 krijgt: dat zijn allemaal verschillende oorzaken. Het eerste werk is uitvinden welke faalwijze je nu eigenlijk hebt. Zodra je dat weet, is het diagnosepad kort. Sla die identificatie over en je bent uren bezig met fixes die nooit gingen werken.

Wat "checkout werkt niet" eigenlijk betekent

De zin dekt minstens zes verschillende fouten, elk met een andere oorzaak en een andere fix:

• Blanco pagina of eindeloze spinner. De checkoutpagina rendert niets, of de "Plaats bestelling"-knop begint te draaien en stopt nooit. Meestal een JavaScript-conflict of een fatale PHP-fout tijdens het versturen van de checkout.
• Het winkelmandje is leeg op de checkoutpagina. Producten die in het mandje zaten zijn verdwenen op weg naar de checkout. Bijna altijd een sessie-cookieprobleem, vaak veroorzaakt door een CDN of WAF die cookies stript.
• Geen betaalmethode op de checkout. De klant komt op de checkout, vult zijn adres in en vindt geen manier om te betalen. Meestal een Block Checkout-incompatibiliteit of een SSL-configuratieprobleem.
• 403 Forbidden bij het versturen van de bestelling. De klant vult het formulier in, klikt op "Plaats bestelling", en krijgt een 403-pagina. Bijna altijd een Web Application Firewall (WAF) die het verzoek vlagt.
• Betaling faalt bij de gateway. De bestelling wordt aangemaakt in WooCommerce maar de gateway wijst de betaling af. De oorzaak ligt bij de gateway, niet in WooCommerce.
• Bestelling wordt aangemaakt maar nooit bevestigd. De bestelling staat in WooCommerce maar de klant ziet een fout of geen bevestiging. Meestal een transactionele e-mail of een gebroken bedankt-pagina-redirect.

Weet je nog niet welke variant het is? Werk dan eerst de volgende sectie door voor je iets gaat fixen.

Identificeer eerst het symptoom

Match wat de klant precies ziet aan een van deze patronen, en spring vervolgens naar de sectie in de rechterkolom. Begin niet met fixen voordat je het symptoom hebt geïdentificeerd; de verkeerde fix kost uren.

Met de beslisboom hierboven los je de meeste gevallen binnen een minuut op. Twee rijen sturen je rechtstreeks door naar een specifiek zusterartikel omdat de oorzaak een eigen diagnosepad heeft dat niet in deze hub thuishoort. Gebruik de secties hieronder voor de faalwijzen die deze hub volledig behandelt.

Sluit eerst caching op elke laag uit

Server-level caching is veruit de meest voorkomende oorzaak van mysterieuze checkoutproblemen, en de aanname dat "ik heb mijn browsercache geleegd" of "ik heb de WP Rocket-cache geleegd" voldoende is, is precies waarom deze problemen weken kunnen blijven hangen voor ze correct worden gediagnosticeerd.

WooCommerce zet de DONOTCACHEPAGE-constante op de winkelmandje-, checkout- en mijn-account-pagina's. Elke WordPress-cacheplugin die deze constante respecteert, slaat die pagina's over. Het probleem ontstaat zodra een cachelaag buiten WordPress zit en de constante nooit ziet: nginx fastcgi_cache, Varnish, Cloudflare APO of LiteSpeed server-level cache. WooCommerce's caching configuration guide is expliciet over welke URL's en cookies van elke cachelaag uitgesloten moeten worden.

Hoe controleer je dit

1. Open de checkoutpagina in een incognitovenster.
2. Open de Network-tab (F12 > Network) en herlaad de pagina.
3. Klik op het hoofd-document en bekijk de Response Headers op x-cache, cf-cache-status, age, x-proxy-cache of x-nginx-cache.
4. Zie je x-cache: HIT of cf-cache-status: HIT, of toont age een getal boven 0, dan wordt de checkoutpagina gecached. Dat is je probleem.

Een veelvoorkomende variant: de checkoutpagina laadt prima maar het versturen geeft "result":"failure" of een security-check-fout. Dat is een verlopen nonce op een gecachte checkoutpagina. WordPress-nonces gebruiken een tick-gebaseerd verloopsysteem met een levensduur van 24 uur opgesplitst in twee blokken van 12 uur. Als een server-cache de checkout-HTML opslaat en hem 13 uur later serveert, is de nonce in die HTML al ongeldig.

Hoe los je het op

Sluit de cart-, checkout-, mijn-account- en ?wc-ajax=-URL's uit van je server-cache. Sluit ook verzoeken uit die een van deze cookies dragen:

Na het toepassen van de uitsluiting: leeg de hele cache en test in een nieuw incognitovenster. Je weet dat het werkte als de checkoutpagina x-cache: MISS of cf-cache-status: BYPASS teruggeeft, en de age-header afwezig of 0 is. De WooCommerce winkelmandje-werkt-niet-gids behandelt nginx- en Cloudflare-uitsluitingsregels in detail.

Classic checkout vs. block checkout

WooCommerce 8.3 (november 2023) maakte de Cart-, Checkout- en Order Confirmation-blokken de standaard checkout-ervaring voor nieuwe installaties. Bestaande winkels die naar 8.3 of later zijn geüpgraded, behielden hun classic shortcode-checkout. De twee systemen gedragen zich anders en falen anders. Weten welke variant jouw winkel draait, bepaalt welke fix toepasbaar is.

Hoe weet je welke variant je hebt

1. Ga in wp-admin naar Pagina's en bewerk de Checkout-pagina.
2. Zie je één blok met de naam "Checkout" met verzend-, factuur- en betalingssecties als visuele lay-out gerenderd, dan draait je winkel de block checkout.
3. Zie je een Shortcode-blok met [woocommerce_checkout], dan draai je de classic checkout.

Verschillen in faalwijzen

De twee systemen falen op verschillende manieren:

• Classic checkout gebruikt jQuery en PHP-hooks. Faalt zodra een JavaScript-fout de click-handler breekt, een fatale PHP-fout optreedt tijdens de AJAX-submit, of een PHP-filter van een plugin de checkout-velden verkeerd aanpast.
• Block checkout gebruikt een JavaScript-API en React. Faalt als een uitbreiding niet als compatibel met het blok is aangemerkt (en stilletjes wordt verborgen in plaats van zichtbaar kapot te zijn), als een oudere betaalmethode de Block Checkout payment method API niet heeft geïmplementeerd, of als een JavaScript-optimalisatieplugin scripts uitstelt of combineert en daarmee de React-initialisatie breekt.

Werkte een checkout-uitbreiding een jaar geleden nog en is hij gestopt na een grote WooCommerce-update? Dan is de blokmigratie de meest waarschijnlijke oorzaak. Check de changelog van de uitbreiding op vermeldingen van "block compatibility" of "Cart and Checkout block support".

Tijdelijke workaround: schakel naar classic

Verdenk je de block checkout? Schakel tijdelijk naar classic om het probleem te isoleren:

1. Bewerk de Checkout-pagina in wp-admin.
2. Verwijder het Checkout-blok.
3. Voeg een Shortcode-blok toe met [woocommerce_checkout].
4. Sla op en test in een incognitovenster.

Verdwijnt het probleem onder classic checkout, dan is de blokmigratie het issue. De classic shortcode wordt voorlopig nog ondersteund zonder aangekondigde deprecatie, dus dit is een geldige tussenoplossing terwijl je wacht tot een uitbreiding blokondersteuning toevoegt.

Doe een schone-lei conflicttest (Health Check Troubleshooting Mode)

Is caching uitgesloten en het symptoom blijft? Dan is een plugin- of themaconflict de volgende verdachte. De verleiding is om alle plugins op de live site te deactiveren en naar een standaardthema te schakelen. Doe dat niet op een live winkel. Daarmee stuur je de checkout van elke bezoeker net zo lang in de kapotte staat als jouw test duurt. De algemene WordPress plugin-conflict-gids behandelt folder-rename-bisectie en debug-log-uitlezen voor gevallen waar wp-admin zelf onbereikbaar is; het WooCommerce-specifieke pad hieronder gebruikt de veiligere Health Check-aanpak omdat de winkel nog live moet blijven.

De Health Check & Troubleshooting-plugin laat je de conflicttest draaien op een manier die alleen jouw eigen admin-sessie raakt. Bezoekers blijven de normale site zien. WooCommerce documenteert deze aanpak in de officiële troubleshooting-gids.

Belangrijke waarschuwing voor je begint

WooCommerce is hier expliciet over: "Troubleshooting Mode does not put a payment gateway into sandbox mode; if an order is placed while the site is in troubleshooting mode, live payment will be taken." Vrij vertaald: een testbestelling die je tijdens dit proces afmaakt, belast een echte kaart. Gebruik een testkaart of je eigen kaart en boek terug, of test alleen tot (niet door) de gateway-redirect.

Stappen

1. Installeer Health Check & Troubleshooting via Plugins > Nieuwe plugin.
2. Ga naar Gereedschap > Site Health > Troubleshooting.
3. Klik op Enable Troubleshooting Mode. Jouw admin-sessie ziet nu een uitgeklede site; bezoekers zien nog de normale.
4. Onder Plugins is alleen WooCommerce standaard nog actief. Activeer ook de actieve betaalmethode-plugin.
5. Test de checkout. Voeg een product toe, vul factuurgegevens in en ga door tot de betaalstap (rond de betaling niet af tenzij je een testkaart gebruikt).
6. Werkt de checkout nu wel, dan ligt de oorzaak bij een van de gedeactiveerde plugins. Activeer plugins één voor één opnieuw en hertest na elke, tot de fout terugkomt.
7. Faalt de checkout nog steeds met alleen WooCommerce actief, schakel dan via de Theme-tab in Troubleshooting Mode naar Storefront of Twenty Twenty-Five. Test opnieuw. Werkt het nu wel, dan is het thema de oorzaak.
8. Klaar? Klik op Disable Troubleshooting Mode. Je normale site komt direct terug.

Je weet dat de conflicttest geslaagd is op het moment dat je één specifieke plugin of het thema hebt aangewezen als trigger. Geen van beide? Dan is de oorzaak geen plugin- of themaconflict; ga door naar de volgende sectie.

Mandje-inhoud verdwijnt voor de checkout

Heeft de klant een vol mandje op de winkelpagina maar leeg op de checkout? Dan ging het al fout voor de checkout überhaupt laadde. De sessie-cookie die de browser aan het server-side mandje koppelt, is verloren gegaan.

Veelvoorkomende oorzaken: een CDN dat alle cookies uit responses stript, een WAF-regel die cookies blokkeert die aan een patroon voldoen, een cookie-consent-banner die alle cookies blokkeert tot toestemming is gegeven, of een browser-privacy-extensie die sessie-cookies stript.

Dit is een eigen onderwerp en de WooCommerce winkelmandje-werkt-niet-gids behandelt diagnose en fix volledig: hoe je bevestigt dat cookies wel of niet worden gezet, welke CDN- en WAF-instellingen ze raken, en hoe je ze classificeert als functioneel onder een consent-banner.

Geen betaalmethode op de checkout

De klant komt op de checkoutpagina maar ziet geen manier om te betalen. De vijf gangbare oorzaken: Block Checkout-incompatibiliteit (een oudere gateway heeft geen blokondersteuning geïmplementeerd), ontbrekende SSL (gateways verbergen zichzelf zonder HTTPS), modusfout (live keys met testmodus geselecteerd, of andersom), pluginconflicten die de gateway-JavaScript blokkeren, en geografische restricties die het land van de klant stilletjes uitsluiten.

Dit probleem heeft een eigen artikel omdat het apart genoeg is. De WooCommerce betaalmethode niet zichtbaar-gids loopt elke oorzaak langs met diagnose en fix, inclusief de specifieke blokcompatibiliteit van grote gateways (Stripe, PayPal Payments, Mollie) en de gateway-specifieke logbestanden die je moet uitlezen.

Lees de error log voor fatale PHP-fouten tijdens checkout

Is de checkoutpagina blanco, draait de spinner eindeloos, of geeft de AJAX-response HTML in plaats van JSON terug? Dan is een fatale PHP-fout tijdens de checkout-submit een sterke verdachte. WooCommerce's endless loading spinner-gids markeert dit expliciet: zodra de AJAX-endpoint HTML in plaats van JSON teruggeeft, is een index.html in de WordPress-root of een PHP-fout in de response de oorzaak.

Waar vind je de fout

Het snelste pad hangt af van je hosting:

1. WordPress debug log (aanbevolen). Activeer WP_DEBUG, WP_DEBUG_LOG en WP_DEBUG_DISPLAY = false in wp-config.php. De WordPress debug log activeren en uitlezen-gids loopt dit veilig door; in het bijzonder waarom je expliciet WP_DEBUG_DISPLAY = false moet zetten om geen fouten naar bezoekers te printen.
2. Hosting-paneel error log viewer. De meeste cPanel- en Plesk-installaties laten de PHP-error-log zien in het hostingpaneel. cPanel's "Errors" en Plesk's "Logs"-tab tonen dezelfde data als de debug log.
3. WooCommerce-log. Ga naar WooCommerce > Status > Logs. Gateway-specifieke fouten worden hier los van PHP-fouten vastgelegd.

Waar moet je naar kijken

Reproduceer de mislukte checkout en lees direct daarna de meest recente loginvoer. Fatale PHP-fouten zien er zo uit:

PHP Fatal error:  Uncaught Error: Call to undefined function some_function() in
/wp-content/plugins/some-plugin/checkout-handler.php:42

Het pad in de bestandsverwijzing wijst aan welke plugin of welk thema verantwoordelijk is. Vandaaruit is de fix óf het updaten van de plugin (een recente WooCommerce-update brak waarschijnlijk een oude hook), óf de ontwikkelaar contacten met de exacte fout.

Verwijst de fout naar een WooCommerce core-bestand in plaats van een plugin? Dan is een pluginfilter of -action die deprecated WooCommerce-code aanroept de meest waarschijnlijke oorzaak. Dezelfde diagnose wijst de schuldige plugin aan: lees de stack trace onder de fatal error-regel.

PHP-versiecompatibiliteit op oudere betaalmethode-plugins

WooCommerce vereist op dit moment minimaal PHP 7.4 en raadt PHP 8.1 of hoger aan. De meeste moderne hosters draaien standaard PHP 8.1, 8.2 of 8.3. Dat is de juiste keuze voor performance en security.

Het is ook waar oudere betaalmethode-plugins stilletjes breken. Plugins die voor PHP 8.0 zijn geschreven, gebruiken soms:

• Impliciete string-naar-int-conversies waar PHP 8.x nu over waarschuwt of die het weigert.
• Deprecated functiehandtekeningen (de each()-functie, verwijderd in PHP 8.0).
• Verplichte parameters gedeclareerd na optionele parameters, wat PHP 8.0 deprecate'et en PHP 8.4 verwijdert.
• Vertrouwen op PHP 7-foutafhandeling die in PHP 8 fataal wordt.

Het symptoom: een oudere custom of niche-betaalmethode werkte onder PHP 7.4 en stopte na een PHP 8.x-upgrade door de hoster. De checkout-submit produceert een fatale fout in de PHP-log. De fix is de gateway-plugin updaten (moderne releases van Stripe, PayPal Payments en Mollie ondersteunen allemaal PHP 8.x), of als er geen update is: tijdelijk terug naar PHP 7.4 schakelen terwijl je een migratie naar een onderhouden alternatief plant.

Je vindt de PHP-versie van je winkel onder WooCommerce > Status > Server Environment > PHP version. Wisselen doe je via de PHP-selector van je hostingpaneel (cPanel's "MultiPHP Manager" of Plesk's "PHP Settings"). Test na elke wijziging de checkout in een incognitovenster.

Order Attribution en WAF's (geïntroduceerd in WooCommerce 8.5)

Order Attribution Tracking is geïntroduceerd in WooCommerce 8.5 (januari 2024) en staat standaard aan op nieuwe en bestaande winkels. Het registreert waar een bestelling vandaan komt (organisch zoeken, betaalde advertentie, verwijzer, direct) via cookies gebaseerd op de Sourcebuster-bibliotheek, en toont die data in het bestelling-admin.

De compatibiliteitsissue: sommige Web Application Firewall-rulesets vlaggen Order Attribution-cookie-inhoud als verdacht en geven een 403 op de checkout-submit. Comodo WAF en de OWASP Core Ruleset hebben allebei false positives op deze cookies geproduceerd. De klant vult de checkout in, klikt op "Plaats bestelling", en krijgt een 403 Forbidden of een generieke "Sorry, this request looks dodgy"-blokkade.

Hoe bevestig je dat Order Attribution de oorzaak is

1. Ga in wp-admin naar WooCommerce > Instellingen > Geavanceerd > Functies.
2. Zoek Order Attribution en zet het uit.
3. Test de checkout in een incognitovenster.
4. Verdwijnt de 403, dan triggeren Order Attribution-cookies een WAF-regel.

Hoe los je het op zonder de feature uit te zetten

WooCommerce 9.0 introduceerde het filter wc_order_attribution_use_base64_cookies, dat de cookie-payload Base64-codeert om de substrings te vermijden die de meeste WAF-regels triggeren. Voeg dit snippet toe aan een site-specifieke plugin of het functions.php van je thema (te bewerken via Weergave > Themabestanden bewerken of de bestandsbeheerder van je hostingpaneel):

// Codeer Order Attribution-cookies in Base64 om WAF false positives te vermijden
add_filter('wc_order_attribution_use_base64_cookies', '__return_true');

Zet Order Attribution weer aan in WooCommerce > Instellingen > Geavanceerd > Functies en test opnieuw. De cookies zijn nu Base64-gecodeerd en de meeste WAF's slaan ze niet meer aan.

Blijft de 403? Dan matcht de WAF op een andere regel. Stuur je hostingprovider de request-URL, het tijdstip van een gereproduceerde fout en het WAF-merk (Cloudflare, Sucuri, Wordfence, hostingbundeld). Zij vinden de gematchte regel in de WAF-log en kunnen die tunen of het request-patroon whitelisten.

Wanneer browsercache legen niet helpt (en wat wel)

Een hardnekkige aanname in WooCommerce-supportthreads: "ik heb mijn browsercache geleegd en de checkout werkt nog steeds niet." Browsercache en server-cache zijn twee verschillende dingen, en bijna elke cache-gerelateerde checkoutfout zit aan de serverkant.

De browsercache slaat jouw lokale kopie van statische assets (CSS, JS, afbeeldingen) op. Legen ervan dwingt een verse download bij de origin af. Dat helpt zodra een verouderd CSS-bestand een knop verbergt, maar het doet niets als het issue een server-cache, een CDN-edge of een verlopen nonce in gecachte HTML is.

Om server-caching uit te sluiten doe je in plaats van de browsercache legen het volgende:

1. Open een incognitovenster (privé browsen). Dat omzeilt zowel de browsercache als elke ingelogde sessie.
2. Voeg ?nocache=1 toe aan de checkout-URL, of een andere unieke querystring waar de cachelaag niet op matcht. Veel caches behandelen URL's met querystrings als niet-cacheable. Werkt de checkout met de parameter en faalt hij zonder, dan is server-cache de oorzaak.
3. Inspecteer response-headers in DevTools (F12 > Network) zoals beschreven onder "Sluit eerst caching op elke laag uit".

De cache van je WordPress-cacheplugin (WP Rocket, WP Super Cache, LiteSpeed Cache, W3 Total Cache) legen is nodig maar niet genoeg. Draai je ook nginx fastcgi_cache, Varnish, Cloudflare of LiteSpeed server-level cache, dan heeft elk een eigen purge-mechanisme en moet elk apart geleegd worden. De cache-sectie van het hostingpaneel heeft meestal een "Purge all"-knop voor welke server-cache er ook gebundeld is.

Een tweede aanname die het noemen waard is: WooCommerce's eigen testmodus (in de gateway-instellingen) blokkeert dat betalingen doorgaan, maar blokkeert niet dat de checkoutpagina laadt. Een checkoutfout op een winkel in testmodus is dus niet "omdat de winkel in testmodus staat": de pagina moet nog steeds correct renderen.

Wanneer escaleren

Wijst geen van de secties hierboven de oorzaak aan, of heb je hem geïdentificeerd maar kun je hem niet zelf fixen (een hosting-side WAF die je niet beheert, een server-cachelaag die je provider beheert), verzamel dan de volgende informatie voor je je hostingprovider of ontwikkelaar contacteert:

• Het exacte symptoom uit de beslistabel bovenaan dit artikel.
• WordPress-versie, WooCommerce-versie en PHP-versie (zichtbaar onder WooCommerce > Status > Systeemstatus).
• Een volledige export van WooCommerce > Status > Get system report. Dat lijst elke plugin, thema, gateway-configuratie en kerninstelling in één blok op.
• Een screenshot van de browser-console (F12 > Console) met de fouten tijdens de falende actie.
• Een screenshot van de Network-tab (F12 > Network) gefilterd op wc-ajax, met request-URL, HTTP-status en response-body.
• Een kopie van het relevante debug.log-fragment dat de tijdstippen van een gereproduceerde fout dekt.
• Of het probleem na een specifieke gebeurtenis begon (een WordPress-update, een WooCommerce-update, een plugin-update, een hostingmigratie, een SSL-wijziging, een CDN-wijziging).
• Of het probleem alle klanten, alle browsers of een specifieke subset raakt.
• Bevestiging welk type checkout de winkel gebruikt (block of classic) en of je de andere al hebt getest.

Het eerste antwoord van elke provider of ontwikkelaar die deze informatie niet heeft, is "probeer plugins uit te zetten", wat het traagst denkbare diagnosepad is. Het systeemrapport vooraf meesturen scheelt een dag.

Hoe voorkom je herhaling

• Test na elke grote WooCommerce-update (8.x naar 9.x, 9.x naar 10.x) de volledige flow op staging voordat de update productie raakt. Voeg toe aan winkelmandje, ga naar de checkout, rond de betaling af met een testkaart, controleer de bestelling onder WooCommerce > Bestellingen.
• Pin updates van betaalmethode-plugins achter handmatige review. Twee recente WooCommerce Stripe-releases (9.4.0 in april 2025 en 9.5.0 in mei 2025) braken de checkout en vereisten hotfix-releases. Een automatisch geüpdate productie-gateway is een single point of failure.
• Documenteer je cacheconfiguratie zodat de volgende persoon die een mandje-issue diagnosticeert geen tijd verspilt aan het ontdekken dat er nginx fastcgi_cache voor WordPress draait. Een korte notitie in een runbook of wp-content/uploads/-README die elke cachelaag noemt en uitlegt hoe je hem leegt, betaalt zichzelf de eerste keer al terug.
• Test na elke WAF- of CDN-wijziging de checkout end-to-end. WAF-regelwijzigingen blijven stil tot een echte klant tegen een 403 oploopt.
• Houd PHP-versies up-to-date. PHP 8.1 bereikt zijn einde van security-support in november 2026, dus plan een verhuizing naar 8.2 of 8.3 ruim van tevoren en test gateway-compatibiliteit op de nieuwe versie eerst op staging.