Testkøb før go-live: tjeklisten for hele betalingsflowet

Kort svar: Test betalingsflowet i tre lag, hver gang der ændres noget: (1) testmiljø – gennemført køb, afvist kort, afbrudt køb og refusion med testnøgler; (2) go-live-bevis – ét rigtigt køb efter skift til produktionsnøgler, fulgt hele vejen til bankudbetalingen; (3) overvågning – så du opdager det, når flowet knækker en tirsdag aften. De fleste betalingsnedbrud skyldes ikke eksotiske fejl, men ændringer, ingen testede.

Fagligt gennemgået: 2. oktober 2026

„Vi har lige opdateret betalingspluginnet – det virker nok.“ Det er sætningen før mange betalingsnedbrud. Betalingsflowet er shoppens mest kritiske funktion og samtidig det, færrest tester systematisk, fordi det føles besværligt. Her er tjeklisten, der gør det til en fast rutine, og de scenarier, folk oftest glemmer.

Før du ændrer noget: Test helst på en staging-kopi af shoppen med gatewayens testnøgler. Tester du på live-sitet, så hold styr på, hvornår testtilstand er slået til, og slå den fra igen med det samme – en shop, der står i testtilstand, tager imod ordrer uden at modtage penge.

1. Ved hvornår der skal testes

Test ved enhver ændring, der rører kæden fra kurv til betaling:

• Opdatering af betalings-, abonnements-, fragt- eller checkout-plugins.
• Skift af gateway eller nye betalingsmetoder.
• Større WooCommerce-opdateringer og temaskift, der rammer checkout.
• Ændringer i cache, optimering, firewall eller CDN – forkert cache på checkout er en klassisk betalingsdræber.
• Før hver kampagneperiode.

Dertil én fast test om måneden, sat i kalenderen. Den fanger de ændringer, du ikke vidste var sket: automatiske plugin-opdateringer og ændringer hos betalingsudbyderen.

2. Kør tjeklisten i testmiljøet

• Gennemført køb – med testkort og testversionen af MobilePay, hvis gatewayen tilbyder den, på både mobil og desktop. Ordrestatus skal skifte korrekt, og lageret skal tælle ned.
• Afvist betaling – brug udbyderens testkort til afvisning. Kunden skal få en forståelig besked, og ordren må ikke stå som betalt.
• 3D Secure – brug et testkort, der kræver godkendelse, og test både godkendt og afbrudt godkendelse; se 3D Secure-guiden.
• Afbrudt køb – luk betalingsvinduet midt i flowet. Kurven skal overleve, og der må ikke ligge en ordre, der står som „afventer betaling“ for evigt.
• Refusion – hel og delvis – fra ordresiden, som beskrevet i refusionsguiden. Beløb og status skal stemme i både WooCommerce og gatewayens portal.
• Ordremails – bekræftelse og refusionsmail skal lande i indbakken (test fx Gmail og Outlook) med korrekt moms; se kvitteringsguiden.
• Abonnement, gavekort og depositum – hvis du bruger dem: førstekøb, gentræk eller indløsning og delvise refusioner.

Testkortene står i din gateways dokumentation, og hver udbyder har sine egne. Som eksempel bruger Stripe disse kortnumre i testtilstand (vilkårlig fremtidig udløbsdato og CVC):

4242 4242 4242 4242   gennemført betaling
4000 0000 0000 0002   afvist betaling
4000 0025 0000 3155   kræver 3D Secure-godkendelse

Testkort virker kun med testnøgler og aldrig i produktion. Brug dem derfor kun i testmiljøet.

3. Tjek logs og cache undervejs

De fleste betalingsplugins skriver til WooCommerce-loggen under WooCommerce → Status → Logs. Slå gatewayens debug-log til under testen, og kig efter fejl, når et køb opfører sig forkert. Slå den fra igen bagefter, så loggen ikke vokser unødigt.

Bekræft samtidig, at kurv og checkout ikke serveres fra cache. Svar-headerne skal vise, at siden ikke er cachet:

curl -sI https://dinbutik.dk/kassen/ | grep -i -E "cache-control|x-litespeed-cache|cf-cache-status"

Ser du et cache-hit på checkout, skal cache-undtagelserne rettes, før du går videre. Adressen på kassesiden afhænger af din opsætning.

4. Bevis go-live med ét rigtigt køb

Testmiljøet beviser logikken – ikke produktionen. Efter skift til produktionsnøgler køber du en billig vare med dit eget kort eller MobilePay og følger pengene hele vejen:

1. Ordren i WooCommerce står med korrekt status.
2. Transaktionen ses i gatewayens portal.
3. Udbetalingen lander i banken (ofte først efter en eller flere bankdage).
4. Posteringen stemmer i regnskabet via afstemningen.

Først når hele kæden er set med egne øjne, er go-live bevist. Refundér testkøbet bagefter – så har du også testet refusionen i produktion.

5. Test det, folk glemmer

• Callbacks: firewall-, Cloudflare- eller botbeskyttelsesregler kan blokere gatewayens serverbeskeder, så ordrer hænger som „afventer betaling“ – symptomerne står i denne guide.
• Rabatkoder og betaling: en kupon, der sætter totalen til nul, opfører sig anderledes i betalingslaget.
• Glemt testtilstand: hele shoppen kører på testnøgler – derfor er go-live-beviset ikke valgfrit.
• Mobil på mobilnet: test over mobilnettet, ikke kun kontorets wi-fi. Fejl i DNS, certifikater eller tunge scripts viser sig ofte dér først.
• Dobbeltklik: klik to gange på „Afgiv ordre“ og tjek, at der ikke opstår to ordrer; se guiden om dobbeltordrer.

6. Ryd op efter testen

Testkøb efterlader spor, som kan forvirre resten af forretningen, hvis de bliver liggende:

• Lager: refunderede eller annullerede testordrer skal give varerne tilbage på lager. Tjek, at lagertallet er det samme som før testen.
• Ordreliste og statistik: markér testordrer med en ordrenote, så de ikke forveksles med rigtige kunder, og så de kan sorteres fra i salgstallene.
• Regnskab: sørg for, at både testkøbet og refusionen er bogført, så afstemningen går i nul. Er shoppen koblet til et regnskabsprogram, kan testordren være sendt videre automatisk.
• Integrationer: lager-, fragt- og nyhedsbrevssystemer kan have modtaget testordren. Tjek, at der ikke er bestilt en pakkelabel eller oprettet en kunde, der ikke skulle være der.
• Testtilstand: bekræft til sidst, at gatewayen står i produktion, og at debug-loggen er slået fra.

7. Gør testen til en fast rutine

Tjeklisten virker kun, hvis den bliver kørt. Sæt den i system: ét fuldt testkøb den første hverdag i måneden, efter hver relevant opdatering og før hver kampagne. Skriv resultatet i én linje i driftsloggen, fx „testkøb OK – kort/MobilePay/faktura“, med dato. Så kan du senere se, hvornår noget sidst virkede, og fejlsøgningen bliver langt kortere, når det ikke gør.

Supplér med én automatisk overvågning: en alarm, hvis der ikke er kommet ordrer i et bestemt antal timer i et tidsrum, hvor der plejer at være salg. Grænsen afhænger af din volumen. Det er en billig forsikring mod det dyre scenarie – en checkout, der har været død siden fredag aften, uden at nogen opdagede det før mandag. Testkøbet fanger fejlene, før kunderne møder dem, og alarmen fanger dem, der opstår alligevel. Se også beredskabsguiden og guiden om at overvåge checkout og formularer.

Læs også

• Hub: Betalinger i danske webshops
• WooCommerce betaling fejler: kort, gateway, 3DS eller callback
• Ordrer bliver stående som „Afventer betaling“
• Beredskab ved gateway-nedbrud
• Staging i WordPress: test ændringer før de går live
• WooCommerce hosting hos Hostious – staging fra Woo StartUp, så du kan teste betalinger uden at røre live-shoppen

Ofte stillede spørgsmål om test af betalingsflow

Kan jeg teste betalinger uden at bruge rigtige penge?

Ja – brug udbyderens testmiljø og testkort til hele tjeklisten. Men afslut altid med ét rigtigt køb efter go-live: kun det beviser produktionsopsætningen.

Hvor ofte bør jeg teste betalingsflowet?

Ved enhver ændring, der rører betalinger, checkout eller cache – og én fast månedlig test, der fanger ændringer, du ikke selv har lavet.

Hvad er det vigtigste enkelt-tjek?

Det rigtige køb efter go-live, fulgt hele vejen til bankudbetalingen. Det afslører både glemt testtilstand, blokerede callbacks og afstemningsfejl i én øvelse.

Hvor finder jeg testkort til min betalingsløsning?

I din gateways udviklerdokumentation. Hver udbyder har sine egne testkort til gennemført betaling, afvisning og 3D Secure, og de virker kun sammen med testnøgler – aldrig i produktion.