Kort svar: Bekræft først, at webhooken er aktiv, har det rigtige topic og peger på den korrekte HTTPS-adresse. Udløs én testhændelse, og find dens delivery-ID i WooCommerce → Status → Logs under
webhooks-delivery. HTTP-status og modtagersvar afgør næste trin. Del aldrig webhook-secret eller fulde payloads. Genafspil kun testen, hvis modtageren er idempotent og ikke kan oprette en ekstra ordre, betaling eller forsendelse.
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. Signatur og genafspilning skal valideres mod den konkrete modtagers implementering.
En webhook kan fejle fire steder: hændelsen bliver ikke udløst, WooCommerce sætter ikke leveringen i kø, HTTP-kaldet når ikke modtageren, eller modtageren afviser data/signatur. Fejlsøg i den rækkefølge. Ellers risikerer du at ændre secrets for en webhook, der aldrig blev trigget.
På denne side
Notér headernavne og de ufølsomme ID'er, som modtageren bruger til sporing: delivery-ID, topic, resource-ID og eventuelt webhook-ID. Signaturværdien, secret, authorization, cookies og hele payloaden er ikke publiceringsmateriale.
Modtageren bør logge delivery-ID, beregnet behandlingsresultat og egen request-ID. Så kan en WooCommerce-levering kobles til præcis én modtagerhændelse uden at gemme kundens komplette ordredata i fejlsøgningsloggen.
I WooCommerce 11.0.1 findes webhooklisten under WooCommerce → Indstillinger → Avanceret → Webhooks. Logvisningen ligger under WooCommerce → Status → Logs, hvor en relevant webhooks-delivery-kilde vælges. Menunavne kan ændre sig med admin-sprog og gateway-/loggingopsætning, så versionsnummeret skal følge screenshots og supportsag.
webhooks-delivery.| Fund | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| Ingen delivery-log | Forkert topic, webhook paused/disabled eller køproblem | Status, testevent og Scheduled Actions | Ret trigger/kø |
| 2xx, men ingen behandling | Modtageren kvitterer før intern fejl eller ignorerer event | Modtagerlog med delivery-ID | Ret mapping/handler |
| 301/302 | Destination omdirigerer | Location-header | Brug endelig endpoint-URL |
| 401/403 | Auth, signatur, WAF eller adgangsregel | Modtager-/WAF-log | Ret præcist krav |
| 404 | Forkert sti eller deploy | Destination og routing | Opdatér endpoint |
| 429 | Rate limit | Retry headers og volumen | Throttle/batch efter integrationsdesign |
| 5xx/timeout | Modtagerfejl eller langsom handler | Applikationslog og responstid | Ret modtageren før replay |
| Webhook bliver automatisk disabled | Gentagne leveringsfejl | Seneste leveringer | Ret årsagen, aktivér og test én gang |
En aktiv webhook sender et ping første gang, den gemmes aktiv. WooCommerce kan deaktivere den efter gentagne fejlleveringer. Ret ikke bare status til Aktiv igen; læs de seneste leveringer og ret 4xx/5xx-årsagen først.
Brug den endelige HTTPS-endpoint-URL uden redirect. Omdirigeringer kan ændre metode, headers eller body i nogle klient-/proxykæder og gør logafstemning sværere.
Vælg en hændelse med et unikt test-resource-ID. Gem delivery-ID, statuskode, forsøgsnummer og tidspunkt. Hvis samme event har flere deliveries, afgør om WooCommerce genforsøgte efter en fejl, eller om kilden faktisk udløste eventet flere gange.
WooCommerce sender en HMAC-SHA256-signatur af den rå request body i webhook-headeren. Modtageren skal beregne signaturen over de nøjagtige bytes, før JSON normaliseres eller body genkodes, og sammenligne sikkert. Secret skal opbevares som hemmelighed og må ikke logges.
Hvis signaturen fejler, kontroller at begge systemer bruger samme secret, samme rå body og base64-format. Rotér secret via en plan, hvor gammel og ny modtager ikke skaber et leveringshul.
Slå ikke firewall eller signaturkontrol globalt fra. Lav den smalleste dokumenterede regel.
Webhooklevering kan indgå i baggrundskøen. Se Scheduled Actions efter relevante webhook-hooks, pending/failed-status og handlingslog. Kør ikke hele køen. Hvis mange forskellige jobtyper er forfaldne, er Action Scheduler-guiden den rigtige ejer.
Før replay skal modtageren kunne genkende et allerede behandlet delivery-/event-/resource-ID. Test først med en ufarlig ressource. En replay må ikke oprette endnu en betaling, ordre, faktura, forsendelse eller lagerbevægelse.
Brug en syntetisk ressource, som ikke kan udløse livebetaling, mail, fragt eller regnskab. Til et ordre-topic kan det være en tydeligt mærket testordre med .test-mailadresse, testprodukt og gatewayens sandbox. Blokér eller omdirigér alle andre udgående integrationer på staging.
Hvis der ikke kommer en delivery-log, kontrolleres webhookstatus, topic og Scheduled Actions. Hvis delivery findes, men modtageren intet ser, ligger bruddet mellem WooCommerce HTTP-klient, DNS/TLS/proxy/WAF og receiver. Hvis modtageren logger requesten, men WooCommerce ser timeout, kan receiveren have behandlet eventet før forbindelsen blev afbrudt; replay kræver derfor idempotenskontrol.
Gem den rå request body som en adgangsbeskyttet testfixture, og beregn HMAC med den konfigurerede secret i modtagerens testmiljø. Log kun bestået/fejlet, algoritme, delivery-ID og et internt fixture-hash – aldrig secret eller den fulde signaturværdi. Kør også en negativ kontrol ved at ændre én byte i fixturekopien; verifikationen skal da fejle.
Hvis positiv og negativ kontrol begge består, er signaturkontrollen ikke reel. Hvis begge fejler, sammenlign rå bytes før parsing, secretversion og base64-håndtering. Normalisering af JSON, linjeskift eller tegnsæt før HMAC kan ændre resultatet.
| Signal | Før rettelse | Efter rettelse | Bestået når |
|---|---|---|---|
| Trigger | Ingen eller forkert event | Ét forventet event | Topic matcher ændringen |
| WooCommerce delivery | Mangler/4xx/5xx/timeout | Forventet 2xx | Ingen redirect og log kan matches |
| Receiverlog | Mangler eller afviser | Samme delivery-ID behandles | Ressource og schema valideres |
| Signatur | Fail/ikke testet | Positiv pass, negativ fail | Secret forbliver skjult |
| Sideeffekt | Mangler eller dubleres | Præcis én forventet handling | Antal og ressource-ID stemmer |
| Replay | Ukendt risiko | Kontrolleret gentagelse | Ingen ekstra sideeffekt |
Kør mindst to nye events efter rettelsen. Det første kan være påvirket af gammel kø eller cache; det andet viser, om webhooken forbliver aktiv og stabil. Brug nye resource-ID'er, men samme testprocedure.
Nogle modtagere svarer 200, straks når requesten er lagt i deres interne kø. Det er et korrekt integrationsmønster, men WooCommerce kan kun se HTTP-kvitteringen. Derfor skal den interne receiverlog også vise, om eventet senere blev behandlet, afvist eller sendt til dead-letter-kø.
Omvendt kan modtageren gennemføre handlingen og derefter returnere timeout/5xx. WooCommerce eller gatewayen kan så retry samme event. Det er grunden til, at modtagerens idempotens skal verificeres, selv når normaltrafikken ser fejlfri ud.
En integration kan bryde efter en WooCommerce-/pluginopdatering, selv om endpointet fortsat svarer 2xx. Sammenlign den anonymiserede payloadstruktur i testmiljøet med modtagerens schema og påkrævede felter. Fiks mapping eller versionskontrakt; hardcod ikke en kundespecifik payload.
Gem en minimal skemafixture for hver understøttet topic/version: feltnavne, typer og hvilke felter modtageren faktisk kræver. Persondata og værdier fjernes. Efter opdatering køres fixturet gennem modtagerens validering, før livehændelser åbnes. Et ukendt ekstra felt bør normalt ikke vælte integrationen; et manglende påkrævet felt skal give en tydelig, sporbar fejl uden at kvittere falsk for behandling.
Filtrér efter det relevante hook og tidsvindue. En fremtidig Pending-handling er ikke en fejl, og en enkelt manuel “Run” beviser ikke, at køen arbejder automatisk. Kontroller planlagt tidspunkt, faktisk start, afslutning og actionlog. Hvis flere forskellige hooktyper er forfaldne, skal køens runner/cron og serverkapacitet løses før webhooken genaktiveres i volumen.
Kør ikke alle forfaldne handlinger som test. Det kan sende gamle mails, callbacks eller lagerjobs. Brug én syntetisk handling eller vent på næste planlagte testevent, og dokumentér at den bliver hentet automatisk.
Gendan tidligere destination, topic eller secret-konfiguration fra sikker backup. Ved secret-rollback skal begge systemers rotationsvindue koordineres. Stop webhooken midlertidigt, hvis modtageren skaber skadelige dubletter; dokumenter pausen og køen, før den aktiveres igen.
Modtagerens udvikler skal have delivery-ID, status, tidspunkt og redigeret payloadstruktur. Hosting skal have request-ID og WAF-/proxybevis ved 403/timeout. WooCommerce-/pluginudvikler skal have reproducerbart manglende trigger- eller queueforløb. Se WooCommerce hosting hos Hostious ved server-/køproblemer.
I WooCommerce → Status → Logs under webhooks-delivery. Hvert forsøg har HTTP-status og svar fra modtageren – det er dit primære fejlsøgningsværktøj.
Efter gentagne fejlede leveringer sættes den på pause. Ret modtager-URL’en eller dens svar (den skal returnere 2xx hurtigt), og aktivér webhooken igen.
Ja, men gør det kontrolleret: genafspil kun de fejlede leveringer, og sørg for at modtagersystemet håndterer dubletter (idempotens), så en gentaget hændelse ikke skaber dobbelte ordrer eller lagertræk.
Gem webhookens topic og destination uden secret, WooCommerces filtrerede delivery-log og modtagerens log med delivery-ID. Skjul signaturværdi, secret, persondata og payloadfelter, som ikke er nødvendige for diagnosen.
Dokumentationen skal vise den samme levering fra begge systemer: event-ID, tidspunkt, HTTP-status, latenstid og modtagerens behandling. Ved signaturfejl gemmes kun resultatet af kontrollen og oplysninger om, at de rå bytes blev brugt. Afslut med én kontrolleret 2xx-test, én bevidst afvist test og en genlevering af samme testevent, som ikke må skabe en dublet.