Kort svar: Afgør først, om der findes to WooCommerce-ordrer, to gatewaytransaktioner eller blot to webhook-/ordrenoter. Sammenlign ordre-ID, beløb, kunde, kurv, tidspunkt og gatewayreference. Refunder ikke og slet ikke noget, før betalingen er afstemt. Når scenariet er kendt, undersøger du dobbelt klik, langsomt checkout, gentagne callbacks, staging eller en integrationskonflikt med den samme reproducerbare test.
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. Virkelige betalinger skal altid afstemmes i gatewayen før refundering eller ordreændring.
En “dobbeltordre” kan være en helt legitim anden bestilling, to ordrer med kun én betaling, eller en reel dobbeltdebitering. Fejlen bliver dyrere, hvis man gætter. Start med en revisionssikker afstemning.
På denne side
WooCommerce tildeler hver ordre et internt ID eller et vist ordrenummer. Gatewayen tildeler betalingen sin egen reference, og hver webhooklevering kan have endnu et delivery-/event-ID. To ordrenumre er derfor ikke bevis for to hævninger, og to webhookleveringer er ikke bevis for to ordrer.
Lav en række pr. hændelse og forbind dem via de referencer, systemerne faktisk gemmer. Hvis et sekventielt ordrenummerplugin bruges, skal du arbejde med både det viste nummer og WooCommerces interne ordre-ID, så support og logs taler om samme objekt.
| WooCommerce | Gateway | Tolkning | Første handling |
|---|---|---|---|
| To ordrer | To betalinger | Mulig dobbeltbestilling eller dobbelt submit | Bekræft kundens hensigt og sammenlign tidslinjer |
| To ordrer | Én betaling | Den ene ordre er sandsynligvis ubetalt | Find hvilken ordre transaktionen tilhører |
| Én ordre | To betalinger | Gateway-/retryproblem eller separat betaling | Eskalér straks til gateway og afstem |
| Én ordre | Én betaling, flere noter | Gentaget webhook/event kan være idempotent | Kontroller om samme delivery-ID blev genbehandlet |
| Symptom | Sandsynlig årsag | Kontrol | Næste skridt |
|---|---|---|---|
| To ordrer inden for sekunder, samme kurv | Dobbeltklik eller langsomt svar | Browser-/server-timing og gatewaylog | Ret performance/submitadfærd |
| To ordrer efter en synlig fejl | Kunden gentog efter timeout | Statuskode og tidspunkt | Ret det langsomme/fejlede checkoutkald |
| Dubletter startede efter gatewayopdatering | Pluginregression eller callbackændring | Versionshistorik og test på staging | Rollback eller leverandørfix |
| Event leveres flere gange | Gateway retry efter manglende 2xx | Delivery log og modtagersvar | Ret endpoint og idempotens |
| Ordrer kommer fra live og staging | Staging er ikke isoleret | Domæne, miljø og webhookdestination | Deaktivér live-processer på staging |
| Flere ordrer har forskellige varer/tider | Muligvis bevidste køb | Kundebekræftelse | Behandl ikke som teknisk dublet uden bevis |
Hvis der er to betalinger, skal butikkens godkendte refund-/kundeserviceproces bruges. Refunder ikke ud fra ordrelisten alene; find hver transaktion hos gatewayen. Hvis kun én betaling findes, må den betalte ordre kobles til den korrekte transaktionsreference, mens den ubetalte ordre håndteres uden at udløse levering.
Slet ikke dubletordren. Ordrenoter, timestamps og metadata er bevis for årsagen og for bogføring.
Reproducer i sandbox på staging. Registrer tiden fra klik til synlig kvittering samt checkoutrequestens server-tid. Et langsomt eller timeoutende svar får kunder til at klikke igen. Ret langsom PHP, eksterne API-kald, synkrone mails eller databaseproblemer frem for blot at skjule knappen.
En visuel “vent”-tilstand på knappen kan forbedre oplevelsen, men er ikke et tilstrækkeligt værn mod retries. Backend og gatewayintegration skal kunne modtage gentagne hændelser uden at oprette nye betalinger eller ordrer.
Gateways kan sende den samme hændelse igen, hvis modtageren ikke svarer som forventet. Sammenlign event-/delivery-ID og request body-hash i anonymiseret form. Hvis den samme event behandles flere gange, skal integrationen registrere og ignorere allerede behandlede event-ID'er efter leverandørens kontrakt.
Tilføj ikke egen idempotenskode direkte på live uden test. Det kan blokere legitime efterfølgende statusændringer.
Staging skal bruge testnøgler, test-webhooks og ikke sende live mails, fulfillment eller abonnementsjobs. Efter en kloning gennemgås alle gatewaydestinationer og scheduled actions. En gammel kopi med live credentials er både en ordre- og sikkerhedsrisiko.
Brug standardtema, WooCommerce og gatewayplugin. Gentag samme sandboxordre flere gange med normal og simuleret langsom netværksrespons. Aktivér derefter checkout-, abonnement-, fraud- og optimeringsudvidelser enkeltvis. Gem versionsnummer og den første kombination, der skaber dubletten.
En kunde klikker “Afgiv ordre”, ser en timeout og prøver igen 40 sekunder senere. WooCommerce viser ordre 1042 og 1043 med samme varer. Gatewayen viser kun én godkendt transaktion, og transaktionsreferencen findes på ordre 1042. Ordre 1043 har ingen gatewayreference og står som afventer betaling. Det er to ordrer, men ikke en dobbeltdebitering.
I det tilfælde er første opgave at sikre, at kun ordre 1042 kan gå til pluk og bogføring. Derefter undersøges det første checkoutkalds svartid og den manglende kvittering. En automatisk refundering af ordre 1043 ville være forkert, fordi der ikke findes en betaling at refundere.
Et andet forløb kan ligne det i ordrelisten, men kræver en anden løsning: én ordre har én transaktion og fem ens webhooknoter. Hvis alle noter refererer til samme event-ID, og lager samt mail kun blev behandlet én gang, har integrationens idempotens sandsynligvis virket. Her skal retryårsagen findes, men ordren må ikke klassificeres som dobbelt.
Følg dubletten videre end betaling: lagerreduktion, faktura, fragtlabel, licenslevering, abonnement og e-mail. Den første handling, der ikke kan rulles tilbage automatisk, bestemmer inddæmningen. To ordrer med én betaling kan stadig have skabt to fragtlabels; én ordre med to betalinger kan have reduceret lageret én gang.
Lav derfor en sideeffektstabel pr. ordre og transaktion. Markér “ikke udløst”, “udløst én gang”, “udløst flere gange” eller “ukendt”. Den tabel gør kundeservice og teknik enige om, hvad der skal rettes manuelt, og hvad der skal løses i koden.
Hvis reelle kunder debiteres dobbelt, kan det være nødvendigt midlertidigt at pause den berørte betalingsmetode eller fjerne den fra checkout. Det er en forretningskritisk beslutning og skal koordineres med butiksejeren. Bevar mindst én alternativ betalingsmulighed, hvis den er testet og godkendt.
Før pausen gemmes antal berørte ordrer, tidsrum, plugin-/gatewayversion og de relevante anonymiserede logs. Ryd ikke cache, logs eller webhookhistorik før indsamlingen. Ellers forsvinder tidslinjen, som skal afgøre refundering og ansvar.
Når rettelsen er testet, genåbnes metoden i et kontrolleret tidsvindue med overvågning af de første test- og liveordrer efter butikkens godkendte procedure.
Se også efter legitime gentagelseskøb. To ordrer med samme kunde og beløb kan være bevidste, hvis varerne, leveringsadressen, en kundekommentar eller tidsafstanden er forskellig. Spørg neutralt og uden at antyde fejl: “Vi kan se to bestillinger og vil sikre, at begge er ønskede.” Annullér ikke den ene automatisk ud fra et simpelt match på e-mail og totalsum. En teknisk dublet bør have en stærk tidsmæssig og data-mæssig sammenhæng, ikke blot ligne den anden ordre i listen.
Gem kundens bekræftelse i sagens private notat.
Gendan den tidligere gateway-/checkoutversion eller konfiguration fra backup, hvis test viser regression. En gennemført refund eller fulfillment kan ikke blot “rulles tilbage” i WordPress; afstem alle eksterne systemer og følg bogføringsproceduren.
Kontakt gatewayen ved to betalinger, uklare genforsøg eller samme idempotensnøgle med flere hævninger. Kontakt udvikleren ved en reproducerbar plugin-/tema-kombination. Kontakt hosting ved timeout eller dokumenteret serveroverbelastning. Se WooCommerce hosting hos Hostious for driftsrelateret hjælp.
Sjældent. Oftest er der to ordrer i WooCommerce, men kun én gennemført betaling. Afstem begæge ordrer mod gatewayens transaktioner, før du refunderer noget som helst.
Dobbeltklik på køb-knappen, langsomme svar der får kunden til at prøve igen, webhooks der genafspilles, eller et staging-miljø der deler betalingsopsætning med live. Mønstret i tidspunkterne afslører årsagen.
Sørg for hurtig checkout uden timeout, deaktivér gatewayen på staging, og lad knappen låse efter første klik. Kommer dubletterne fra webhooks, skal genafspilning håndteres idempotent.
Gem de to anonymiserede ordreoversigter, gatewayens testtransaktioner, webhookens leveringstidslinje og browserens timing ved ordreafgivelsen. Brug både WooCommerces interne ordre-ID, det viste ordrenummer og gatewayens reference; de tre værdier er ikke nødvendigvis ens.
Sæt hændelsen ind i fire-scenarie-matricen ovenfor, og match event- eller delivery-ID på tværs af loggene. Efter rettelsen køres mindst tre separate sandboxordrer. De skal give tre ordrer, tre tilsvarende betalingsforsøg og ingen ekstra lager-, mail- eller fulfillmenthændelser. Gem timing før og efter, så en forbedring ikke kun bygger på, at fejlen tilfældigvis ikke viste sig én gang.
