WooCommerce checkout werkt niet na update: fix in 90 min

WooCommerce checkout werkt niet na update is de melding die ik in 2026 het vaakst binnenkrijg van webshop-eigenaren die zelf hun updates draaien. Vorige week donderdag belt een klant uit Hulst: cart werkt, verzendkosten worden berekend, maar zodra de klant op “Doorgaan naar betaling” klikt gebeurt niks.

Of erger: een leeg wit vlak. Of een 500-fout met alleen een cryptische “Er is een fout opgetreden” in het Nederlands. Omzet lekt weg per uur.

In dit stuk laat ik zien hoe ik dat aanpak, welke logs je moet lezen, en hoe je hetzelfde in cPanel, Plesk, DirectAdmin en RunCloud doet. Reken op 60 tot 120 minuten van diagnose tot fix, mits je toegang hebt tot je hostingpaneel of SSH.

Wat er gebeurt als WooCommerce checkout werkt niet na update

Voor je één plugin uitschakelt is het handig om te weten wat er waarschijnlijk gebeurt. De checkout is het meest gecompliceerde stuk van je webshop: hij combineert WooCommerce core, minstens één payment gateway, vaak twee of drie extra plugins (verzendkosten, BTW, factuurvelden) en een cache-laag. Er zijn drie klassen problemen die ik in de praktijk het vaakst tegenkom.

1. HPOS-synchronisatie loopt uit de pas. Sinds WooCommerce 8.2 (oktober 2023) is High-Performance Order Storage de standaard voor nieuwe installaties, en in 2026 draait vrijwel elke actieve webshop erop. HPOS gebruikt eigen tabellen (wp_wc_orders, wp_wc_order_addresses) in plaats van wp_posts. Staat de compatibiliteitsmodus aan en stopt het sync-proces halverwege, dan gaat het mis. De checkout probeert dan een order aan te maken die in twee tabellen tegelijk moet landen. Het resultaat is een fatale race condition.

2. Payment gateway-plugin loopt achter op WooCommerce core. Mollie, Stripe, MultiSafepay, Buckaroo en Adyen brengen allemaal hun eigen release-schema uit. Als je WooCommerce update naar 9.5 maar de Mollie-plugin nog op een versie zit die de nieuwe WC_Payment_Gateway_CC API niet gebruikt, valt de gateway-klasse niet meer te instantiëren. Result: cart werkt, checkout laadt, maar bij “Nu betalen” krijg je een lege response of 500.

3. Cache of minificatie sloopt de dynamische checkout-scripts. WooCommerce checkout is dynamisch: cart-inhoud, fees en gateway-selectie updaten via AJAX. WP Rocket, LiteSpeed Cache en W3 Total Cache sluiten cart en checkout standaard uit, zoals WP Rocket documenteert. Maar na een update zet een cache-plugin “delay JavaScript execution” of “combine JS” soms weer aan. En een custom checkout pakt de exclusie niet automatisch op, denk aan Cartflows, FunnelKit of WPO Custom Checkout Fields.

Als je twijfelt welke van de drie het is: log je in wp-admin en scroll naar de wc-logs, dan is dat na 5 minuten duidelijk. Dat is stap 2. Eerst het probleem reproduceren.

Stap 1: Reproduceer in incognito met een echte gateway

Voor je gaat sleutelen, bevestig je eerst het probleem in een omgeving zonder cookies, extensies of admin-toolbar. Open een incognito-venster met Ctrl+Shift+N in Chrome, of Cmd+Shift+N op macOS. Plaats een product in de cart, ga naar checkout, vul een echt adres in en kies je gateway.

Twee dingen om te noteren.

• Op welke stap breekt het? Cart-pagina, checkout-pagina laadt maar velden reageren niet, checkout submit maar geen redirect naar gateway, redirect naar gateway maar order blijft op “pending payment” hangen. Elk van deze wijst naar een andere root cause.
• Wat zegt de browser-console (F12 → Console)? Rode errors met “TypeError”, “404 wc-ajax”, “Failed to load resource” wijzen op een script- of AJAX-endpoint-probleem. Groene console met alleen een lege response is vaker een PHP-fatal server-side.

Belangrijk: test met een echte gateway die je gebruikt (Mollie iDEAL 2.0 in sandbox, Stripe test-mode) en niet alleen met “Cash on delivery” of “Bank transfer”. Die shortcircuit de gateway-code en verbergt juist het probleem dat je zoekt.

Stap 2: wc-logs openen en fatal-errors lezen

WooCommerce schrijft errors automatisch weg in /wp-content/uploads/wc-logs/. De bestandsnaam is fatal-errors-YYYY-MM-DD-{hash}.log, en per plugin krijg je ook aparte logs (bijvoorbeeld mollie-YYYY-MM-DD-{hash}.log, woocommerce-gateway-stripe-YYYY-MM-DD-{hash}.log). WooCommerce documenteert dat je deze logs ook in de admin kunt bekijken.

WordPress admin → WooCommerce → Status → Logs → 
kies "fatal-errors-{datum}" uit de dropdown → View

Als de admin zelf onbereikbaar is (500-fout op wp-admin), moet je via het hostingpaneel of SSH bij de logs. Daarover meer verderop in de per-paneel sectie.

Kijk in de fatal-errors log naar drie patronen.

PHP Fatal error: Uncaught Error: Class 'WC_Mollie_Helper_Api' not found 
in /wp-content/plugins/mollie-payments-for-woocommerce/...

Klassieke gateway-versie mismatch. De Mollie-plugin verwacht een klasse die niet meer bestaat (of nog niet bestaat) in de huidige core. Fix: update de gateway, of rollback WooCommerce core één minor versie.

PHP Fatal error: Uncaught wcpay\Internal\DependencyManagement\ContainerException

WooPayments-specifiek. Meestal een cache van de service container die na een update niet is geflusht. Fix: verwijder /wp-content/uploads/wc-payments-cache/ en refresh.

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted 
in /wp-includes/meta.php

Geen code-bug, maar PHP-memory-limiet. Checkout laadt meer meta-velden dan het geheugen aankan. Fix: verhoog memory_limit in wp-config.php.

// In wp-config.php, bovenaan
define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '768M');

Als je log leeg is of niet bestaat, is dat op zich ook informatie: dan is er geen PHP-fatal maar iets in de frontend of AJAX-laag. Ga verder met stap 5 en 6.

Stap 3: HPOS-compatibiliteit controleren

Sinds WooCommerce 8.2 draait HPOS standaard aan voor nieuwe installaties. Voor stores die van vóór 8.2 komen, staat er meestal een “compatibility mode” die beide storage-systemen tegelijk vult totdat je klaar bent om posts-storage uit te schakelen. Als die sync stokt door een update, gebeurt precies wat mijn Hulst-klant zag: cart oké, checkout dood.

Check je huidige state.

WooCommerce → Status → Tools → 
scroll naar "Custom order tables" sectie →
klik "Verify base database tables"

Als er meldingen komen dat tabellen ontbreken of niet gesynchroniseerd zijn, klik dan “Sync incremental orders” (of “Regenerate order lookup table”). Bij grote stores kan dat 5 tot 30 minuten duren. Ondertussen NIET updaten.

Voor een quick sanity-check via WP-CLI.

# Check of HPOS aan staat
wp option get woocommerce_custom_orders_table_enabled

# Check of compatibility mode aan staat
wp option get woocommerce_custom_orders_table_data_sync_enabled

# Verifieer de tabellen
wp db query "SHOW TABLES LIKE 'wp_wc_orders'"
wp db query "SELECT COUNT(*) FROM wp_wc_orders"

# Vergelijk met legacy posts-count
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='shop_order'"

Als de counts drastisch uit elkaar lopen (bijvoorbeeld 1.200 in wp_wc_orders maar 3.400 in wp_posts), is je sync incompleet. Loop hem opnieuw.

wp wc hpos sync

Bij zeer grote stores overweeg een tijdelijke rollback naar posts-storage tot je een staging-cyclus hebt gedaan.

WooCommerce → Settings → Advanced → Features → 
"High-Performance Order Storage" → 
switch naar "WordPress Posts Storage" (bij problemen, tijdelijk)

Dat is dus geen definitieve oplossing, maar koopt je tijd om de root cause te fixen zonder omzet te verliezen.

Stap 4: Payment gateway isoleren

Als HPOS in orde is en de wc-logs een gateway-specifieke fatal tonen, isoleer je die door tijdelijk een niet-online gateway aan te zetten. Ga naar WooCommerce → Settings → Payments, activeer “Cash on delivery” of “Direct bank transfer” (rembours of overschrijving), en test opnieuw in incognito.

• Werkt de checkout nu wel? Bevestigd: het is een gateway-probleem. Update de plugin, of rollback naar de vorige versie via WP Rollback / WP-CLI.
• Blijft de checkout dood? Het probleem zit in WooCommerce core of een niet-gateway-plugin (verzendkosten-plugin, BTW-plugin, custom fields-plugin).

Rollback van een gateway via WP-CLI.

# Huidige versie checken
wp plugin get mollie-payments-for-woocommerce --field=version

# Deactiveer eerst (belangrijk voor gateways)
wp plugin deactivate mollie-payments-for-woocommerce

# Installeer specifieke versie
wp plugin install mollie-payments-for-woocommerce --version=7.9.0 --force

# Activeer opnieuw
wp plugin activate mollie-payments-for-woocommerce

Voor de Mollie-plugin moet je na de iDEAL 2.0-deadline (1 maart 2025) minimaal op 7.5+ zitten. Voor de officiële Stripe-plugin zit je in 2026 op de 9.x-lijn voor correcte SCA/3DS2-afhandeling.

Stap 5: Cache en minificatie uitsluiten

Cart, checkout en account-pagina’s mogen nooit gecached worden. Dat is een harde regel omdat ze user-specifieke content bevatten (cart-inhoud, kortingscodes, adressen). WP Rocket sluit deze pagina’s automatisch uit als de standaard WooCommerce-pagina’s zijn ingesteld in WooCommerce → Settings → Advanced → Page setup. Andere cache-plugins doen dit doorgaans ook, mits ze de WooCommerce-integratie herkennen.

Wat vaak fout gaat na een update.

• Je hebt een custom checkout-URL (/afrekenen/ in plaats van /checkout/) en de cache-plugin herkent die niet meer.
• Je gebruikt Cartflows, FunnelKit of een custom builder-checkout op een eigen URL.
• “Delay JavaScript execution” was uit maar staat na de update weer aan.
• Combine JS/CSS heeft nu een verkeerde volgorde-conflict.

Voor WP Rocket ga je naar Settings → Advanced Rules → “Never Cache URL(s)” en voeg je de custom checkout-URL toe.

/afrekenen/
/mijn-account/
/cart-custom/

Voor LiteSpeed Cache: LiteSpeed Cache → Cache → Excludes → “Do Not Cache URIs” → voeg dezelfde paden toe.

Voor JavaScript delay exclusies voeg je gateway-scripts toe. In WP Rocket → File Optimization → JavaScript → “Delay JavaScript execution” → in de exclusion-list.

mollie
stripe
woocommerce-blocks
wc-checkout
wcpay

En Cloudflare als je die draait: Rules → Page Rules → maak een rule “URL matches *yourdomain.nl/checkout*” → “Cache Level: Bypass” en “Disable Performance”.

Stap 6: JS-conflict, SSL en mixed content debuggen

Als bovenstaande stappen niets opleveren, zit het probleem in de frontend-laag. Open opnieuw checkout in incognito, F12, tabblad Console. Let op deze meldingen.

• Mixed content warnings. Je pagina laadt via HTTPS maar een script komt via HTTP binnen. Payment gateway-JS wordt door de browser geblokkeerd. Fix: check je siteurl via wp option get siteurl.
• CSP / Content-Security-Policy violations. Als je een security-header-plugin (Wordfence Response of custom .htaccess) hebt, kan die na een update de gateway-domeinen (js.stripe.com, api.mollie.com) blokkeren. Voeg ze toe aan script-src en connect-src.
• SSL certificate expired. Checkout redirect naar gateway, maar de gateway weigert je callback-URL omdat het certificaat verlopen is. Check via openssl s_client -connect jouwsite.nl:443 -servername jouwsite.nl 2>/dev/null | openssl x509 -noout -dates.

Voor SSL-verlengen bij Let’s Encrypt (auto-renew stukgelopen na server-update).

# certbot renewal test
sudo certbot renew --dry-run

# geforceerde renewal
sudo certbot renew --force-renewal

wc-logs benaderen per hostingpaneel

Als je wp-admin niet in kan of je hebt geen “Status → Logs”-permissies, dan lees je de logs direct van disk. Per paneel iets anders.

Via DirectAdmin (Antagonist, Vimexx, mijn.host)

1. Log in → File Manager.
2. Navigeer naar public_html/wp-content/uploads/wc-logs/.
3. Sorteer op “Last modified” descending → open het meest recente fatal-errors-*.log bestand.
4. Voor live tail (SSH-toegang nodig, meestal onder “Terminal” of “SSH Access”).

tail -f /home/username/public_html/wp-content/uploads/wc-logs/fatal-errors-*.log

Via Plesk (Argeweb, en op VPS bij TransIP en Combell)

1. Domains → jouwsite.nl → Files.
2. Navigeer naar httpdocs/wp-content/uploads/wc-logs/.
3. Klik het log-bestand aan → “View” of “Edit”.
4. Voor SSH: Plesk → jouwsite.nl → SSH Access (indien enabled).

Via cPanel (o.a. Neostrada)

1. Log in → File Manager.
2. Navigeer naar domains/jouwsite.nl/public_html/wp-content/uploads/wc-logs/.
3. Klik het meest recente fatal-errors-*.log bestand → View.

Via Hostinger hPanel

1. Files → File Manager.
2. domains/jouwsite.nl/public_html/wp-content/uploads/wc-logs/.
3. Open het bestand, of via de Hostinger AI-assistent: “Show me my WooCommerce fatal errors”.

Via RunCloud, ServerAvatar, GridPane (managed VPS)

SSH-in of gebruik de web-shell in het paneel.

cd /home/runcloud/webapps/jouwsite/wp-content/uploads/wc-logs

# Snelste eerste blik
ls -lah | tail -20

# Live volgen tijdens een test-checkout
tail -f fatal-errors-*.log

# Zoek in alle logs van vandaag
grep -i "fatal\|exception\|mollie\|stripe" fatal-errors-*.log

WP-CLI equivalenten

Als je überhaupt WP-CLI hebt, is dit vaak sneller dan door mappen klikken.

# Meest recente 50 regels uit alle fatal-error logs
find wp-content/uploads/wc-logs -name "fatal-errors-*.log" -mtime -1 -exec tail -50 {} \;

# Clear alle transients (vaak nodig na fatal-fix)
wp transient delete --all

# Clear WooCommerce specifieke transients
wp wc tool run clear_transients

En als alternatief direct in de database (voor als WP-CLI niet werkt maar phpMyAdmin wel).

DELETE FROM wp_options 
WHERE option_name LIKE '_transient_%' 
OR option_name LIKE '_site_transient_%';

Zorg dat je een backup hebt voor je deze query draait.

Drie concrete scenario’s uit mijn praktijk

Scenario A: Mollie iDEAL orders blijven op “pending payment” na WC 9 update

Symptoom: de order blijft op “pending payment” staan na een geslaagde iDEAL-betaling.

De klant wordt naar de bank geredirect, betaalt en komt terug op de thank-you-pagina. Daarna gebeurt er niets. Voorraad wordt niet afgeboekt, mail niet verzonden.

Diagnose: Kijk in /wp-content/uploads/wc-logs/mollie-YYYY-MM-DD-*.log. Je ziet dan zoiets.

Webhook call for Mollie transaction tr_xxx failed with HTTP 403 Forbidden

Oorzaak: Na de WooCommerce-update heeft je hosting of een security-plugin (Wordfence, iThemes Security, All-In-One Security) de Mollie webhook-endpoint geblokkeerd. Het wc-api/mollie_return-endpoint retourneert 403 tegen Mollie’s servers. Dat is een bekend issue in de Mollie community.

Fix:

1. Test de webhook-URL vanaf een externe machine: curl -I https://jouwsite.nl/?wc-api=mollie_return_ideal. Als je een 403 krijgt, is de endpoint geblokkeerd.
2. Check .htaccess op recent toegevoegde Deny from– of RewriteRule ... [F]-regels.
3. Wordfence: dashboard → Firewall → Blocked → whitelist Mollie IP-ranges (34.64.0.0/10 en de gepubliceerde Mollie-ranges).
4. Cloudflare: Security → WAF → Custom rules → maak een “Skip” rule voor URI Path contains /wc-api/mollie_return (allow).
5. Na de fix, in WooCommerce → status → logs → mollie-log: nieuwe webhook-calls zouden nu 200 OK moeten geven.

Scenario B: Stripe checkout 500 error na WordPress core-upgrade

Symptoom: Klant komt tot de betaalstap, klikt “Nu betalen”, ziet een 500 error of blank pagina. De Stripe checkout modal verschijnt niet.

Diagnose: In wc-logs/fatal-errors-*.log.

PHP Fatal error: Uncaught TypeError: WC_Stripe_Payment_Request::add_ajax_events(): 
Argument #1 must be of type WC_Payment_Gateway, null given

Oorzaak: WordPress core 6.7 introduceerde strictere type-checks in wp_ajax_* hooks. Een Stripe-plugin ouder dan 8.4 geeft een null door waar nu een object verwacht wordt.

Fix:

# Update Stripe-plugin naar 9.x-lijn
wp plugin update woocommerce-gateway-stripe

# Als update niet beschikbaar is (bijv. licentie verlopen), tijdelijk 
# een oudere Stripe API-versie forceren via functions.php:

// child-theme/functions.php (tijdelijk)
add_filter('wc_stripe_api_version', function() {
    return '2024-06-20'; // conservatieve fallback
});

Belangrijker: verleng je Stripe-plugin licentie of overweeg de gratis versie uit de wordpress.org repository. Ook zorg dat 3DS2/SCA-authenticatie in je Stripe-dashboard is geactiveerd (Radar → Rules → Check that 3DS2 is enabled voor EU-kaartverkeer).

Scenario C: WooPayments plugin conflict met cache-plugin

Symptoom: Checkout laadt, betaalmethoden verschijnen kort en verdwijnen dan weer. Of: klant klikt betalen en de pagina laadt oneindig.

Diagnose: Browser console toont.

Uncaught (in promise) TypeError: Cannot read properties of undefined 
(reading 'processCheckoutResponse')

Oorzaak: WooPayments (WCPay) gebruikt zijn eigen JS-bundle die na de update door de cache-plugin verkeerd wordt gedelayed of gecombineerd.

Fix:

1. In WP Rocket → File Optimization → JavaScript → Delay JS execution → voeg toe aan exclusion-list: wcpay, woocommerce-payments, blocks-checkout.
2. In WP Rocket → Cache → Advanced → Never Cache Cookies → voeg toe: wp_woocommerce_session_, woocommerce_cart_hash.
3. Verwijder de service-container-cache handmatig.

rm -rf wp-content/uploads/wc-payments-cache/
wp cache flush
wp transient delete --all

1. Als het nog fout gaat: deactiveer WooPayments, wacht 30 seconden, activeer opnieuw. Dat forceert een fresh container-init.

Preventie: dit voorkomt herhaalde checkout-uitval

Symptoom-fix is één ding. Structurele preventie voorkomt dat je hier over drie maanden weer zit.

1. Staging-omgeving verplicht voor elke checkout-rakende update. De meeste Nederlandse hostings (Antagonist, TransIP, Hostinger, Combell, SiteGround) leveren 1-klik-staging. Test iedere WooCommerce-update, elke gateway-update en elke WordPress core-major eerst daar. Doe minimaal drie test-orders per gateway (iDEAL, creditcard, factuur/overschrijving). Pas na dat pas "Deploy to production".

2. Regressietest-checklist na elke update. Ik gebruik voor klanten deze minimale lijst.

• [ ] Cart telt correct op inclusief BTW.
• [ ] Checkout-form velden reageren.
• [ ] Verzendkosten worden dynamisch berekend.
• [ ] Elke betaalmethode individueel test-doorlopen tot thank-you-pagina.
• [ ] Order verschijnt in WooCommerce → Orders met status "Processing".
• [ ] Bevestigingsmail arriveert bij testklant.
• [ ] Voorraad wordt afgeboekt.
• [ ] Webhook-callback komt binnen (check wc-logs/mollie-*.log of wcpay-*.log).

3. Payment gateway status monitoring. Zet een externe uptime-check op de checkout-URL met een keyword-match. UptimeRobot, Better Uptime of Sematext waarschuwen zodra "Nu betalen" niet meer op de pagina staat. Kost je 0 tot 15 euro per maand en scheelt ontdekkingstijd van uren naar minuten.

4. HPOS actief houden vanaf dag één. Op nieuwe webshops zet ik HPOS meteen aan en zet ik compatibility-mode uit zodra de eerste 10 test-orders binnen zijn. Op bestaande shops: eerst compat-mode aan, dan 30 dagen laten sync-lopen, dan legacy uitschakelen. Geen half-en-half met "we doen het later wel", want juist die tussenstaat breekt bij updates.

5. Auto-updates uit voor checkout-kritische plugins. Payment gateways, cache-plugins en checkout-builders (Cartflows, FunnelKit) zet ik op handmatig. Voor security-plugins en WP minor releases kan auto aan.

// wp-config.php
define('WP_AUTO_UPDATE_CORE', 'minor');

Per-plugin: WP-admin → Plugins → onder Mollie / Stripe / WooPayments klik "Disable auto-updates".

Wanneer een echte webmaster inschakelen

Doe deze diagnostiek zelf als je binnen 90 minuten bij een oorzaak bent. Daarna weegt de omzetderving zwaarder dan een uurtarief. Bel in deze gevallen iemand in.

• Je checkout meer dan 2 uur down is en je omzet lekt.
• Je geen backup hebt van vóór de update (rollback is dan hoog-risico).
• Fatal-errors verwijzen naar core WooCommerce-classes (WC_Order, WC_Cart) in plaats van naar een gateway.
• Je HPOS-migratie halverwege vast zit en je orders in twee tabellen ongelijk verdeeld hebt.

Voor mijn klanten kost een checkout-outage meestal 1,5 tot 3 uur werk (€128 tot €210 tegen €70 per uur), inclusief root cause, fix, regressietest en preventie-plan voor de volgende update.

Vast door dit type incident?

Is je checkout down en verlies je omzet per uur, stuur me dan een korte mail via /contact/. Zet er een screenshot van de fatal-error-log bij en vermeld welke gateway je gebruikt.

Ik kijk binnen 2 uur tijdens kantoortijden mee, spoedhulp buiten kantoor in overleg. Ik factureer alleen de daadwerkelijk bestede tijd tegen €70 per uur. Na de fix krijg je een schriftelijke root-cause-analyse en een preventie-checklist.

Meer over hoe ik werkzaam voor Zeeuwse en Vlaamse ondernemers zie je op /diensten/ en /webshop-onderhoud/.