WooCommerce checkout virker ikke: diagnose fra browser til serverlog

Kort svar: Test først checkout som gæst i et privat vindue, og se derefter den fejlede checkout-anmodning i browserens Netværk-fane. Hvis svaret er en 4xx/5xx-fejl, HTML i stedet for JSON eller slet intet svar, har du allerede indsnævret problemet til henholdsvis blokering, serverfejl eller JavaScript. Ændr ikke betalingsopsætningen, før du har gemt URL, statuskode, tidspunkt og den tilhørende loglinje.

Fagligt gennemgået: 28. august 2026

Kontrolgrundlag: WordPress 7.1, WooCommerce 11.0.1, PHP 8.4.23 og Chrome 151 på isoleret staging samt aktuel produktdokumentation. Den konkrete butik skal stadig testes med sin egen gateway, checkouttype og pluginopsætning.

Et checkoutproblem er ikke én fejl. Nogle kunder ser en endeløs spinner, andre mangler betalingsmetoder, og andre igen kan trykke på “Afgiv ordre” uden at komme videre. Det hurtigste diagnoseforløb begynder derfor ikke med at deaktivere plugins. Det begynder med at fastholde det præcise symptom og finde den anmodning, som ikke gennemføres.

Sådan bekræfter du, at fejlen ligger i checkout

1. Opret en ufarlig testvare med lav pris eller brug gatewayens testtilstand på staging. Brug aldrig rigtige kortdata i en test.
2. Åbn et privat browservindue, læg varen i kurven, og gennemfør præcis det forløb, som fejler.
3. Notér tidspunkt, browser, enhed, land, valgte fragtmetode og betalingsmetode.
4. Åbn udviklerværktøjerne. Se både Konsol og Netværk, mens du gentager fejlen.
5. Ved klassisk checkout filtrerer du efter wc-ajax og især opdatering af ordreoversigten og selve checkoutkaldet. Ved blok-checkout ser du efter Store API-kald under /wc/store/.
6. Kontrollér, om der blev oprettet en ordre, og læs dens private ordrenoter. Se derefter WooCommerce → Status → Logs ved samme tidspunkt.

Gem kun et skærmbillede med testdata. Kundenavn, adresse, e-mail, telefon, kortoplysninger, tokens, nøgler og hele webhook-payloads skal beskæres eller erstattes af testdata, før billedet bruges offentligt.

Symptom, sandsynlig årsag og næste kontrol

Løsning i den sikreste rækkefølge

1. Afgræns fejlen, før du ændrer noget

Test mindst to forløb: gæst og indlogget kunde. Hvis kun én betalingsmetode fejler, er det ikke et generelt checkoutproblem. Hvis alle metoder fejler før en ordre oprettes, er frontend, validering eller checkout-endpointet et bedre sted at lede.

Sammenlign også en enkel fysisk vare uden kupon med den kurv, der fejler. Fragt, moms, abonnementer og tilvalg kan ændre, hvilke plugins og beregninger der bliver aktiveret.

2. Kontrollér WooCommerce-sider og URL'er

Under WooCommerce → Indstillinger → Avanceret skal den rigtige checkoutside være valgt. Under WordPress → Indstillinger → Generelt skal WordPress-adresse og webstedsadresse bruge samme endelige domæne og HTTPS-form. Et miks af www og ikke-www, eller HTTP og HTTPS, kan bryde sessioner og AJAX.

Gem ikke indstillingerne bare for at “prøve”. Dokumentér den nuværende værdi, og ret kun en faktisk uoverensstemmelse.

3. Læs den fejlede browseranmodning

Statuskoden bestemmer næste trin:

• 2xx med forventet JSON: Backend gennemførte requesten på HTTP-niveau. Læs JSON-responsens ordre-, betalings- eller valideringsstatus, og undersøg derefter eventuel JavaScript-fejl.
• 2xx med HTML eller anden forkert datatype: Et cachelag, en advarsel, en fejlskabelon eller forkert routing har forurenet endpointets svar.
• 400: Requesten mangler et krævet felt eller indeholder data, som checkout ikke kan behandle. Brug JSON-fejlkoden og feltfejlene som facit.
• 403: Requesten er ikke tilladt. Kontrollér nonce eller cart token, session, WAF og den konkrete sikkerhedsregel uden at deaktivere beskyttelsen globalt.
• 409: Kurven eller en anden ressource er ændret siden klientens state. Store API kan returnere den aktuelle kurv sammen med konflikten; synkronisér den viste state, og gensend ikke ordren blindt.
• 422: Brug kun denne fortolkning, når den konkrete gateway dokumenterer statuskoden og den samme årsag fremgår af gatewayloggen. 422 er ikke en generel WooCommerce-core-diagnose.
• 5xx: Noget fejlede på server-, upstream- eller gatewayniveau. Find samme tidspunkt i WooCommerce-loggen og serverens PHP-/webserverlog.

Ret den komponent, der kan knyttes til beviset. En tilfældig cache-purge kan skjule problemet kortvarigt uden at forklare det.

4. Udeluk cache og JavaScript-optimering på staging

Kurv, checkout og Min konto skal være dynamiske. Bekræft, at de ikke leveres fra fuld sidecache, og at WooCommerce-sessioncookies giver bypass. Hvis menu, felter eller knappen bryder efter delay, defer, minificering eller kombination af JavaScript, skal du slå én funktion fra ad gangen på staging og genkøre samme test.

Når den ansvarlige funktion er fundet, genaktiveres optimeringen med den mindst mulige undtagelse. Undlad brede undtagelser for hele domænet, hvis én konkret fil eller side er nok.

5. Kontrollér checkouttype og udvidelseskompatibilitet

En gateway eller checkoutudvidelse kan fungere med klassisk checkout og fejle med Checkout-blokken. Opret en testside på staging med den alternative officielle checkouttype, og gennemfør samme kurv. Det er en diagnose, ikke en permanent nedgradering. Hvis forskellen er reproducerbar, skal den inkompatible udvidelse opdateres eller erstattes, eller checkouttypen fastholdes med en dokumenteret begrundelse.

6. Lav en kontrolleret konflikttest

Tag backup, og brug staging. Skift først til et standardtema. Deaktivér derefter alle ikke-nødvendige plugins, men behold WooCommerce og den gateway, som testen kræver. Gentag præcis samme ordre. Hvis fejlen forsvinder, aktiveres komponenterne igen i logiske grupper og derefter enkeltvis.

På en butik med live trafik må du ikke deaktivere gateway, tema, lagerintegration eller checkoutudvidelser for at teste. Det kan koste ordrer og gøre efterfølgende logbevis ubrugeligt.

7. Eskalér serverfejl med et brugbart bevis

Ved 5xx, timeouts eller manglende loopback skal hosting eller udvikler have: UTC-tidspunkt, request-URL uden følsomme parametre, statuskode, request-ID hvis tilgængeligt, den relevante anonymiserede loglinje og trinene til at reproducere. “Checkout virker ikke” er ikke nok til at finde en PHP-worker, firewallregel eller langsom databaseforespørgsel.

Et praktisk mikroeksempel: Hvis gæstecheckout giver 403, mens samme kurv virker for en indlogget testkunde, er gatewayen næppe første mistænkte. Sammenlign i stedet nonce eller cart token, sessioncookie og WAF-event for de to requests. Den ene forskel er mere værd end ti tilfældige pluginændringer.

Sådan verificerer du rettelsen

• Gennemfør en ny testordre som gæst og som indlogget testkunde.
• Test både mobilbredde og desktop samt mindst to moderne browsere.
• Bekræft, at checkoutkaldet svarer med den forventede 2xx-status og korrekt datatype.
• Kontrollér, at der kun oprettes én ordre, og at ordrenoterne viser det forventede betalingsforløb.
• Kontrollér lagerreduktion, kvitteringsside og relevante mails i testforløbet.
• Genaktiver de optimeringer, du ikke har bevist som fejlårsag, og test igen.

Rollback

Rul kun den konkrete rettelse tilbage: gendan den tidligere checkoutside, optimeringsindstilling, gatewayversion eller kodeændring fra den noterede backup. Purge berørte cachelag efter rollback, og gentag den samme testordre. Hvis rollback ikke genskaber den tidligere adfærd, er der sandsynligvis mere end én ændring i spil.

Hvornår skal hosting, gateway eller udvikler hjælpe?

Kontakt gatewayen, når dens dashboard eller log afviser betalingen eller callbacken. Kontakt plugin-/temaudvikleren, når fejlen kan reproduceres med deres komponent alene. Kontakt hosting ved 5xx, timeouts, blokerede loopbacks eller dokumenterede ressourcegrænser. Har du brug for driftshjælp til en dansk WooCommerce-løsning, kan du se WooCommerce hosting hos Hostious.

Ofte stillede spørgsmål om checkout-fejl

Hvorfor virker WooCommerce checkout ikke, når resten af shoppen gør?

Fordi checkout er dynamisk og afhænger af AJAX, session, betalingsgateway og ofte flere scripts. Cache, JavaScript-optimering eller en gatewayfejl kan derfor ramme checkout alene, mens produktsiderne ser fine ud.

Er det cachen, der ødelægger min checkout?

Tit, ja. Checkout, kurv og mine-konto-sider må aldrig fuldside-caches, og checkout-scripts må ikke delayes. Tjek at dine cache-regler undtager de sider, og test i et privat vindue efter purge.

Hvad gør jeg, hvis betalingen fejler hos gatewayen?

Læs gatewayens egen log først – 3DS-afvisninger og callback-fejl står der, ikke i WordPress. Virker webhooken ikke, skal dens URL kunne nås udefra uden at blive blokeret af firewall eller vedligeholdelsestilstand.

Læs også

• WooCommerce fejl og fejlfinding
• WooCommerce betaling fejler
• WooCommerce-kurven bliver tom
• WooCommerce-kurven opdaterer ikke
• Find en plugin- eller temakonflikt uden at ramme live-sitet

Dokumentér din egen checkoutfejl

En god fejlsag kan læses som én sammenhængende tidslinje. Brug eksempelvis disse fire udsnit:

1. Privat testcheckout med ufarlig testvare og tydeligt symptom.
2. DevTools Netværk med det relevante checkoutkald markeret; alle kunde- og tokenfelter beskåret.
3. WooCommerce Status med versionsrækken og eventuelle relevante advarsler.
4. Før/efter-visning af den præcise indstilling, der løste den reproducerede fejl.

Supplér billederne med tekniske signaler:

1. HAR-udsnit eller requestoversigt med metode, endpoint, status og content-type.
2. Anonymiseret logudsnit med samme UTC-tidspunkt og request-/ordre-ID.
3. Eftertest med én oprettet testordre, korrekt status og ingen ny fatal logpost.

Kundenavn, adresse, e-mail, cookies, tokens og betalingsdata skal være fjernet. “Checkout virker nu” er ikke i sig selv en kontrol; samme testvare, betalingsmetode og browsersekvens skal gennemføres igen, så før og efter kan sammenlignes.