Kort svar: “Afventer betaling” betyder, at WooCommerce har modtaget ordren, men endnu ikke har fået bekræftet betalingen. Slå først transaktionen op hos gatewayen. Hvis den ikke findes eller er afvist, må ordren ikke sættes til betalt. Hvis betalingen findes, sammenholder du ordrenoter, gatewayens webhook/callback-log og WooCommerce-loggen ved samme tidspunkt og retter kommunikationsfejlen, før ordren afstemmes.
Fagligt gennemgået: 28. august 2026
Kontrolgrundlag: WordPress 7.1, WooCommerce 11.0.1 og PHP 8.4.23 på isoleret staging samt aktuel produktdokumentation. En virkelig ordre må kun ændres efter afstemning mod den anvendte gateways transaktionsstatus.
Statussen er korrekt, når kunden forlader betalingsvinduet, eller når gatewayen endnu ikke har bekræftet pengene. Den er et problem, når gatewayen har gennemført betalingen, men WooCommerce aldrig modtager eller behandler bekræftelsen. Derfor er første opgave afstemning, ikke statusredigering.
På denne side
Afventer betaling betyder, at ordren findes, men WooCommerce ikke har en betalingsbekræftelse. På hold bruges typisk, når betaling eller manuel kontrol stadig afventes, men lageret kan allerede være reduceret efter gatewayens proces. Mislykket beskriver et forsøg, som er afvist eller udløbet. En butik kan have udvidelser, der tilføjer egne statuser, så læs altid ordrenoterne og gatewayens dokumenterede flow.
Statusnavnet alene fortæller heller ikke, om banken viser en midlertidig reservation. Gatewayens endelige transaktionsstatus og afstemningsdata er facit. Kunden skal ikke opfordres til at betale igen, mens en eksisterende charge er uafklaret.
| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Ingen transaktion hos gatewayen | Kunden forlod flowet eller checkout fejlede tidligt | Gatewaydashboard og checkoutlog | Bevar pending/annullér efter butikkens proces |
| Afvist transaktion | Kort eller risikovurdering blev afvist | Gatewayens decline-kode | Kunden prøver anden metode |
| Betaling gennemført, ingen ny ordrenote | Webhook/callback mangler | Gatewaylevering | Ret URL, firewall eller pluginfejl |
| Callback er 2xx, ordre stadig pending | Handler/plugin behandler ikke hændelsen | WooCommerce-/gatewaylog | Konflikttest og leverandørsupport |
| Mange gamle pending-ordrer | Normal abandonment eller manglende oprydningsjob | Alder, gatewayfordeling og cron | Skel normal adfærd fra systemfejl |
| Lager forbliver reserveret | Hold stock/cron eller betalingsflowets regler | Lagerindstilling og scheduled actions | Ret jobkøen; ryd ikke blindt |
Lav en lille tabel med ordre-ID, WooCommerce-status, gatewaystatus, beløb, valuta og transaktions-ID. Hvis beløb eller valuta ikke matcher, skal ordren eskaleres frem for at blive automatisk opdateret. Ved to betalinger skal guiden om dobbeltordrer bruges.
En manuelt ændret status kan udløse mail, lagerreduktion, bogføring, fulfillment eller abonnement. Skift derfor kun status efter dokumenteret betaling og efter butikkens afstemningsprocedure.
Ordrenoter viser ofte, om gatewayen oprettede et betalingsforsøg, om kunden blev sendt ud af shoppen, og om en callback senere opdaterede status. Mangler alle gatewaynoter, kan flowet være stoppet før pluginet modtog data. Er der en fejl- eller transaktionsreference, bruges den til at finde samme hændelse i gatewayloggen.
Find det konkrete leveringsforsøg. En forkert destination, 403 fra WAF, 404 fra routing eller 5xx fra PHP forklarer, hvorfor WooCommerce aldrig fik bekræftelsen. Hvis gatewayen genforsøger automatisk, skal du først rette modtagelsen og observere det næste testforsøg. Genafspil kun en hændelse, når gatewayen understøtter det, og du har kontrolleret idempotens, så samme betaling ikke behandles to gange.
En live-shop med testnøgle, en test-webhook mod live-domænet eller en gammel destination efter migrering kan skabe pending-ordrer. Kontroller konto-ID, miljø og callbackdomæne uden at kopiere hemmelige nøgler ud af indstillingssiden. Ret kun den dokumenterede uoverensstemmelse.
Nogle gateways og lagerprocesser bruger WP-Cron eller Action Scheduler til opfølgning. Se WooCommerce → Status → Planlagte handlinger og filtrér på relevante hooks og den berørte periode. Enkeltstående handlinger, som er få minutter forsinkede, er ikke automatisk en fejl. En voksende kø eller handlinger, der er mere end et døgn forfaldne, kræver den separate kødiagnose.
Reproducer med gatewayens sandbox, standardtema, WooCommerce og gatewayplugin. Deaktiver derefter øvrige komponenter i dokumenterede trin. Staging må ikke pege på live webhooks, sende kundemails eller udføre live betalinger.
Hvis problemet begyndte efter domæneskift, kloning eller gatewaygenforbindelse, skal alle notification-/webhookdestinationer kortlægges. En gateway kan stadig sende til et gammelt domæne, mens den nye shop opretter ordren. En stagingkopi kan omvendt modtage live events og opdatere en ordre, som ikke findes i produktion.
Lav en tabel med miljø, domæne, konto-ID, nøgletype og callbackdestination. Skriv aldrig selve nøglen. Der må kun være én godkendt live-modtager for hvert eventflow, medmindre integrationen udtrykkeligt er designet til flere.
Tilføj en privat ordrenote, som henviser til det verificerede gateway-ID og den godkendte handling, uden kort- eller persondata. Notér hvem der afstemte, tidspunkt og om mail/lager/fulfillment allerede var udløst. Det gør det muligt at skelne en manuel driftsbeslutning fra en automatisk gatewayopdatering senere.
Forestil dig en testordre, der blev oprettet kl. 10.14. Gatewayen viser en godkendt sandboxbetaling kl. 10.15, men den sidste WooCommerce-ordrenote er “Afventer betaling”. I gatewayens delivery-log står callbacken som 403 kl. 10.15. Her er ordrestatussen kun symptomet; den dokumenterede fejl er den afviste callback.
Den sikre rækkefølge er at gemme de tre tidsstempler, finde det matchende WAF-event og tillade netop den dokumenterede callbacksti efter gatewayens krav. Derefter oprettes en ny sandboxordre. Først når callbacken får det forventede svar, en ny ordrenote tilføjes, og ordren skifter automatisk, er årsagen rettet. Den gamle ordre kan derefter afstemmes efter butikkens godkendte procedure.
Det modsatte eksempel er lige så vigtigt: Gatewayen har ingen transaktion, og browserloggen viser, at kunden lukkede 3D Secure-vinduet. Her vil en manuel ændring til “Behandler” skabe en falsk betalt ordre. Den korrekte handling er at bevare historikken og lade kunden gennemføre et nyt, entydigt betalingsforsøg.
Sorter ikke kun efter alder. Start med ordrer, hvor gatewayen viser en reservation eller gennemført betaling, fordi der kan være en kunde, lagerreservation og bogføringspost, som kræver hurtig afstemning. Derefter kommer ordrer med uklar status. Gamle ordrer uden noget betalingsforsøg kan normalt følge butikkens almindelige abandonmentproces.
Arbejd i små batches og før en kontrolkolonne for betaling, lager, mail og fulfillment. Hvis en statusændring udløser en uventet sideeffekt, stands resten af batchen. Et masseklik på “Behandler” gør ikke blot diagnosen sværere; det kan også sende gamle ordrebekræftelser eller starte leverancer, som aldrig er betalt.
Skeln også mellem en autorisation og en endeligt hævet betaling. Nogle betalingsmetoder reserverer beløbet først og capture sker senere. Sammenlign derfor gatewayens præcise status, capture-beløb og valuta med butikkens normale flow. En reservation er ikke automatisk grundlag for at markere ordren som færdigbetalt, og en senere udløbet reservation skal ikke behandles som en refundering.
Kør en sandboxordre gennem succes, afvisning og afbrudt redirect. Succes skal ende i forventet betalt status med én transaktionsreference. Afvisning eller afbrydelse må ikke blive markeret betalt. Webhook/callback skal give godkendt svar og en ordrenote ved samme test. Kontrollér også, at lagerreservation frigives efter den konfigurerede proces.
Gendan tidligere gateway-/webhookindstilling, hvis den nye test fejler, og kør samme sandboxforløb igen. Manuelle ordrestatusændringer rulles ikke blindt tilbage; de kan allerede have udløst eksterne processer. Afstem først mail, lager, fulfillment og betaling.
Gatewayen skal involveres ved uoverensstemmelse mellem transaktion og webhook. Hosting skal involveres ved dokumenteret 403/5xx/timeout mod callback eller fastlåst cron. Pluginudvikleren skal have anonymiseret log, ordrestatus-tidslinje og reproduktion. Se WooCommerce hosting hos Hostious ved behov for driftsmæssig fejlsøgning.
Er årsagen timeout frem for opsætning, er butikken for langsom til at svare på gatewayens kald i tide. Se WooCommerce hosting med dedikerede ressourcer.
Ikke nødvendigvis. Det betyder, at WooCommerce ikke har FÅET BESKED om betalingen. Kunden kan have gennemført købet, mens callbacket fra gatewayen aldrig nåede frem.
Typisk fordi callback-URL’en blokeres af firewall, vedligeholdelsestilstand eller løbeseddel-redirects – eller fordi den peger på en gammel adresse efter flytning. Gatewayens leveringslog viser status.
Kun når du har verificeret betalingen hos gatewayen. Ellers risikerer du at sende varer uden betaling. Afstem først – skift status bagefter, og notér hvorfor i ordrenoterne.
Saml dokumentationen omkring én anonymiseret testordre: ordrenoter i kronologisk rækkefølge, transaktionsstatus hos gatewayen, callbackens leveringsstatus og eventuelle Scheduled Actions filtreret på det relevante hook. Skjul kundedata, tokens og nøgler, men behold tidspunkt, ordre-ID og en testreference, så hændelserne kan forbindes.
Notér også lagerets tilstand før og efter testen. Når rettelsen er lavet, skal en ny testordre bevæge sig fra den forventede startstatus til den korrekte slutstatus uden manuel indgriben. Hvis betalingen er godkendt, men status stadig ikke ændres, er testen ikke bestået, selv om checkout viser en takkeside.
