Kort svar: Test betalingsflowet i tre lag, hver gang der ændres noget: (1) testmiljø – gennemført køb, afvist kort, annullering og refusion med testnøgler; (2) go-live-bevis – ét rigtigt køb med egen telefon 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 betalingskatastrofer er ikke eksotiske fejl – de er ændringer, ingen testede.
„Vi har lige opdateret betalingspluginnet – det virker nok.“ Det er sætningen før de fleste 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 rutine på 20 minutter – og de scenarier, folk glemmer.
Ved enhver ændring, der rører kæden: opdatering af betalings- eller abonnementsplugin, skift af gateway, nye betalingsmetoder, WooCommerce-hovedopdateringer, temaskift der rammer checkout – og ændringer i cache/optimering, for forkert cache på checkout er en klassisk betalingsdræber. Dertil én fast, kalendersat test om måneden: den fanger de ændringer, du ikke vidste var sket (automatiske plugin-opdateringer, ændringer hos udbyderen).
Testmiljøet beviser logikken – ikke produktionen. Efter skift til produktionsnøgler: køb en billig vare med dit eget kort eller MobilePay, og følg pengene hele vejen: ordren i Woo → transaktionen i gatewayens portal → udbetalingen i banken (evt. dagen efter) → posteringen i regnskabet via afstemningen. Først når hele kæden er set med egne øjne, er go-live bevist. Refunderér testkøbet bagefter – så har du også testet refusionen i produktion.
Callbacks under pres: firewall- eller Cloudflare-ændringer kan blokere gatewayens serverbeskeder, så ordrer hænger som „afventer betaling“ – symptomerne står i denne guide. Rabatkoder + betaling: en kupon, der sætter totalen til nul, opfører sig anderledes i betalingslaget. Testtilstand glemt: hele shoppen kører på testnøgler – derfor er go-live-beviset ikke valgfrit. Mobil på mobilnet: test på 4G, ikke kun kontorets wi-fi; DNS- og certifikatproblemer viser sig dér først.
Læg tjeklisten i kalenderen (månedligt + ved ændringer), og skriv resultatet ned med dato – fem linjer i en driftslog er nok til, at fejlsøgning senere tager minutter i stedet for timer. Overvåg derudover betalingsflowet automatisk: en advarsel, når der ikke er kommet ordrer i x timer i åben butik, fanger nedbrud før kunderne klager – se beredskabsguiden. Og kør shoppen på en platform, hvor checkout-undtagelser, HTTPS og HTTP/3 er sat rigtigt op fra start: WooCommerce hosting hos Hostious.
Tjeklisten virker kun, hvis den KØRES – så sæt den i system: ét fuldt testkøb den første hverdag i måneden, plus efter hver opdatering af betalings-, fragt- eller checkout-plugins, plus før hver kampagneperiode. Skriv resultatet i én linje i driftsloggen („testkøb OK – kort/MobilePay/faktura“) – så kan du senere se, HVORNÅR noget sidst virkede, hvilket halverer fejlsøgningen, når det ikke gør.
Supplér med én automatisk overvågning: en alarm, hvis der ikke er kommet ordrer i X timer i et tidsrum, hvor der plejer at være (grænsen afhænger af din volumen). Det er den billigste forsikring mod det dyreste 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 de opstår i virkeligheden; alarmen fanger dem, der opstår alligevel. Tilsammen koster de ti minutter om måneden – og har betalt sig selv hjem første gang, de fanger én weekend.
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.
Ved enhver ændring, der rører betalinger, checkout eller cache – og én fast månedlig test, der fanger ændringer, du ikke selv har lavet.
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.
