WooCommerce betaling fejler: kort, gateway, 3DS eller callback

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: 2. oktober 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.

Bekræft hvilket betalingsforløb der fejler

1. Find ordre-ID og præcist tidspunkt. Hvis der ikke blev oprettet en ordre, start i checkoutguiden.
2. Læs de private ordrenoter i kronologisk orden. Notér gatewayens transaktions- eller intent-ID uden at offentliggøre det.
3. Find samme forsøg i gatewayens eget dashboard. Afgør, om der er nul, én eller flere transaktioner.
4. Åbn gatewayens log under WooCommerce → Status → Logs. Aktivér kun udvidet logging i den periode, hvor du tester, og undgå at dele følsomme payloads.
5. Hvis flowet bruger 3D Secure eller ekstern redirect, kontrollér browserens Netværk-fane før og efter tilbagekomsten til shoppen.

Byg én tidslinje i stedet for tre løse screenshots

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, årsag, kontrol og næste skridt

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

Løs fejlen i den mindst risikable rækkefølge

1. Stop med live kort og skift til et kontrolleret testflow

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.

2. Klassificér en afvisning korrekt

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.

3. Kontrollér tilgængelighed, valuta og miljø

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.

4. Følg 3D Secure hele vejen tilbage

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.

5. Undersøg JavaScript og optimering

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.

6. Kontrollér callback eller webhook

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.

7. Konflikttest kun på staging

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.

Kontrolleret sandbox-test, der kan gentages

Opret et ufarligt testprodukt med en lav 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:

1. Succes uden ekstra challenge, hvis gatewayen understøtter det.
2. Kontrolleret afvisning med en kendt decline-kode.
3. 3D Secure-succes og eventuelt en afbrudt/challenge-fejl.
4. Callback forsinket eller genleveret, hvis gatewayens sandbox kan gøre det sikkert.

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”.

Beslutningsgren efter gatewayens facit

• Ingen transaktion findes hos gatewayen: fejlen ligger før eller under oprettelsen – JavaScript, request, credentials, metode-tilgængelighed eller netværk.
• Transaktionen er afvist med dokumenteret kode: behandl den som en kontrolleret bank-/risikoafvisning, medmindre samme officielle testkort burde lykkes.
• Transaktionen er godkendt, men ordren er ubetalt: stop nye betalinger på den ordre, afstem beløb/valuta/ID og undersøg callbacken.
• Der findes flere gatewaytransaktioner for én ordre: følg guiden til dobbeltordrer og afklar idempotens, før du genafspiller noget.
• Ordren er “Behandler”, men gatewayen har ingen godkendelse: sæt ikke blot status tilbage. Find den kode eller manuelle handling, der markerede ordren betalt uden gatewaybevis.

Før/efter-verifikation i fuld konfiguration

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.

Verifikation

• Kør gatewayens officielle succes-, afvisnings- og eventuelle 3D Secure-test.
• Bekræft præcis én transaktion og præcis én WooCommerce-ordre pr. test.
• Kontroller, at succes giver forventet ordrestatus og transaktions-ID i ordrenoten.
• Kontroller, at afvisning ikke reducerer lager eller sender en falsk betalingsbekræftelse.
• Kontroller callback/webhookens 2xx-respons og at efterfølgende leveringer ikke opretter dubletter.
• Slå midlertidig debuglogging fra igen, når beviset er indsamlet.

Rollback

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.

Hvornår skal du eskalere?

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.

Ofte stillede spørgsmål om betalingsfejl

Hvor ser jeg, hvorfor en betaling fejlede?

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.

Kunden siger, pengene er trækket, men ordren står som fejlet – hvad nu?

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.

Kan cache eller optimering ødelægge betalinger?

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.

Læs også

• WooCommerce fejl og fejlfinding
• WooCommerce checkout virker ikke
• WooCommerce-ordre afventer betaling
• Dobbeltordrer i WooCommerce
• WooCommerce webhook virker ikke

Dokumentér betalingsforløbet uden at dele betalingsdata

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.