Kort svar: Find først ud af, om betalingen blev afvist, slet ikke blev sendt eller faktisk blev gennemført hos gatewayen uden at opdatere WooCommerce. Sammenhold ordrenoter, gatewayens transaktionsoversigt og WooCommerce-loggen ved samme tidspunkt. Test derefter i gatewayens sandbox med officielle testdata. Sæt aldrig en ordre til “Behandler” alene for at fjerne fejlen; bekræft betalingen hos gatewayen først.
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. Gatewayens egne testdata og transaktionslog er facit i den konkrete butik.
“Betalingen fejlede” kan dække over mindst fire forskellige hændelser. Banken kan have afvist kortet. Gatewayen kan mangle gyldige nøgler eller understøttelse for butikkens valuta. Kunden kan være strandet i 3D Secure. Eller betalingen kan være godkendt, mens callbacken til WooCommerce blev blokeret. De fire situationer skal løses forskelligt.
På denne side
Omsæt forsøget til en kort hændelseskæde med samme tidszone:
| Led | Identifikator | Status | Bevis |
|---|---|---|---|
| WooCommerce-ordre | Testordre-ID | Afventer/Fejlet/Behandler | Ordrenote og oprettelsestid |
| Gatewayforsøg | Intent-/transaktions-ID | Oprettet/afvist/godkendt | Gatewayens testlog |
| 3D Secure | Samme gatewayforsøg | Startet/gennemført/afbrudt | Redirect-/requesttidslinje |
| Callback/webhook | Delivery-/event-ID | HTTP-status og behandling | Begge systemers logs |
I WooCommerce 11.0.1 findes betalingsmetoder under WooCommerce → Indstillinger → Betalinger, mens de tilgængelige logfiler findes under WooCommerce → Status → Logs. Gatewayplugins kan tilføje egne menupunkter og logkilder, så gem både WooCommerce- og gatewaypluginversion. UI-stien er nyttig dokumentation, men gatewayens transaktionsstatus er stadig facit for, om penge er reserveret eller hævet.
Brug UTC i den tekniske tidslinje, hvis gatewayen gør det, og tilføj kun lokal tid som læsevenlig reference. Ellers kan et 3D Secure-retur kl. 14.02 fejlagtigt blive koblet til en callback kl. 12.02 UTC som to forskellige forsøg.
| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Kortet afvises med en konkret fejl | Bank/issuer, saldo, CVC eller risikovurdering | Gatewayens decline-kode | Kunden bruger anden metode eller kontakter banken |
| Alle kort afvises efter en ændring | Forkerte nøgler, test/live-mix eller valuta | Gatewayindstillinger og miljø | Ret den dokumenterede uoverensstemmelse |
| Betalingsfelter mangler | JavaScript, checkouttype eller gatewayens eligibility | Konsol og gatewaystatus | Udeluk konflikt på staging |
| Kunden godkender 3D Secure, men kommer ikke videre | Return URL, session eller blokeret script | Netværk og gatewaylog | Ret redirect/callback-flowet |
| Gateway viser betaling, ordren står ubetalt | Webhook/callback når ikke WooCommerce | Gatewaylevering og ordrenoter | Ret callback og afstem ordren manuelt med bevis |
| Der oprettes ingen ordre | Checkout fejler før betalingskaldet | Checkout-request | Brug den generelle checkoutdiagnose |
Brug staging og gatewayens testtilstand. Bekræft, at både publicerbare og hemmelige testnøgler tilhører samme konto og miljø. Kopiér aldrig nøgler ind i en screenshot-, support- eller artikeldraft. Hvis staging er en kopi af produktion, skal live webhooks, mails og automatiske ordrejobs isoleres, før du tester.
En konkret decline-kode fra gatewayen er ikke i sig selv en fejl i WooCommerce. Test med gatewayens officielle testscenarier. Hvis en godkendt testbetaling virker, mens en bestemt kundes kort afvises, skal du ikke ændre checkoutkode eller sikkerhed for at omgå bankens beslutning.
Ved generiske fejl sammenligner du tidsstempel, ordre-ID og gatewayens request-ID. Ordrenoterne kan være kortfattede; gatewayloggen har ofte den tekniske årsag. Del aldrig fuldt kortnummer, CVC, secret keys eller komplette kundeoplysninger.
Bekræft at betalingsmetoden er aktiveret, at kontoen er godkendt til butikkens land og valuta, og at krav som HTTPS er opfyldt. Se også efter regler, der kun viser metoden ved bestemte lande, beløb, produkttyper eller leveringsmetoder.
Efter en nøgleændring testes både en succes og en kontrolleret afvisning. En succes alene viser ikke, at fejltilbagemeldingen og ordrestatus fungerer.
Registrér disse fire punkter: checkout sender betalingsforsøget, gatewayen opretter transaktionen, kunden gennemfører autentificeringen, og browser eller webhook får ordren opdateret. Hvis browseren mister sessionen efter redirect, sammenlign domæne, HTTPS, SameSite/cookies og cacheadfærd. Hvis autentificeringen lykkes hos gatewayen, men WooCommerce ikke opdateres, undersøg callback/webhook i stedet for at bede kunden betale igen.
Manglende kortfelter, en grå betalingsknap eller fejl efter klik kan skyldes, at gatewayens script er forsinket, kombineret eller blokeret. Find den konkrete fil og fejl i konsollen. På staging deaktiveres én optimeringsfunktion ad gangen. Genaktiver derefter alt, som ikke er bevist relevant, og lav den smalleste mulige undtagelse.
Sammenlign leveringsforsøget hos gatewayen med WooCommerce-log og ordrenoter. En 401/403 peger ofte på adgangs- eller firewallblokering. En 404 peger på forkert URL eller routing. En 5xx-fejl kræver serverlog ved samme tidspunkt. Tillad ikke hele gatewayens IP-område eller slå WAF fra permanent uden at kende det præcise krav.
Behold WooCommerce og den aktive gateway, skift til et standardtema, og deaktiver øvrige udvidelser i en dokumenteret rækkefølge. Gentag det samme sandbox-scenarie efter hver ændring. Hvis fejlen kun findes med en bestemt udvidelse, gem konsolfejl, request og versionsnumre til leverandøren.
Opret et ufarligt testprodukt med fast pris, lagerstyring slået fra og ingen fysisk levering. Brug et unikt testordrenavn eller internt notefelt, som ikke indeholder rigtige kundeoplysninger. Staging skal have deaktiveret kundemails, live webhooks, fragtbookning, økonomisystem og andre automatiske sideeffekter.
Kør derefter mindst disse scenarier med gatewayens officielle testdata:
For hvert scenarie noteres forventet gatewaystatus, forventet WooCommerce-status, antal transaktioner, lagerændring og udsendte mails. Et eksempel på en bestået afvisning er ikke blot en rød besked: der skal være nul godkendte transaktioner, ingen betalingsbekræftelse og ingen uberettiget ordrestatus som “Behandler”.
Når årsagen er fundet, genaktiveres tema, cache, sikkerhed og alle nødvendige plugins på staging. Gentag præcis samme testprodukt, valuta, browser og gatewaytestscenario. Sammenlign:
| Signal | Før rettelse | Efter rettelse |
|---|---|---|
| Checkoutrequest | Status/Console-fejl | Forventet gatewayrequest |
| Gatewayforsøg | Mangler/afvist/ufuldendt | Forventet testsvar |
| WooCommerce-ordre | Forkert eller fastlåst status | Status matcher betalingsresultat |
| Callback | 4xx/5xx/mangler | 2xx og dokumenteret behandling |
| Sideeffekter | Forkert mail/lager/dublet | Præcis forventet antal |
Ryd kun relevante stagingcaches mellem runder, og notér det. Hvis resultatet kun holder med al scriptoptimering deaktiveret, skal den konkrete gatewayasset eller checkoutside afgrænses; “slå al performance fra” er ikke en færdig rettelse.
Flyt først ændringen til produktion i et driftsvindue. Brug ikke et rigtigt betalingskort som første produktionstest uden en på forhånd aftalt ordre-, refundering- og afstemningsprocedure.
Gem de oprindelige gatewayindstillinger uden hemmelige værdier i rapporten. Hvis en opdatering eller konfigurationsændring forværrer flowet, gendan den tidligere pluginversion fra backup eller den tidligere indstilling, og gentag samme sandbox-test. Skift ikke tilbage til live, før staging igen viser korrekt succes, afvisning og callback.
Gatewayen skal have gateway-request-ID, tidspunkt, test/live-miljø og decline-/leveringskode. Udvikleren skal have reproduktion, konsolfejl og versionsliste. Hosting skal have statuskode og serverlog ved blokeret callback eller timeout. Har du brug for en WooCommerce-driftspartner, kan du læse om WooCommerce hosting hos Hostious.
Er det din egen side, der timer ud midt i betalingen, er det ressourcer frem for gateway. Se WooCommerce hosting med dedikerede ressourcer.
Start i ordrens ordrenoter og i gatewayens transaktionslog – ikke i WordPress-fejlloggen. Afvisninger fra kortudsteder og 3D Secure står hos gatewayen med præcis årsag.
Slå transaktionen op hos gatewayen. Findes den som gennemført, mangler WooCommerce blot callbacket – opdatér ordren manuelt og undersøg, hvorfor webhooken ikke kom frem. Refunder aldrig før afstemning.
Ja. Fuldside-cache på checkout eller delayed JavaScript kan blokere gatewayens scripts. Undtag checkout fra cache og JS-optimering, og test et køb i privat vindue efter hver ændring.
Gem sandbox-indstillingen uden nøgler, anonymiserede ordrenoter, gatewayens testtransaktion og DevTools-requesten ved et eventuelt 3D Secure-retur. Udsnittene skal kunne forbindes med tidspunkt og en ufarlig testreference, men må ikke vise kortnummer, CVC, secret keys, tokens eller rigtige kundeoplysninger.
Skriv forsøget som en kort tidslinje med ordre-ID, gateway-ID og UTC-tid. Kør både et godkendt og et kontrolleret afvist sandboxscenarie, og notér callbackstatus og den forventede ordrestatus. Dermed dokumenterer du ikke blot, at en betaling kan lykkes, men også at en afvisning håndteres uden forkert status eller gentagne hævninger.
