Feilsøkingsguide

WooCommerce-checkout fungerer ikke? Start her.

De fleste kassefeil skyldes én av sju ting, og du kan sjekke alle sammen selv på under en halvtime. Denne siden går gjennom dem i den rekkefølgen som løser flest saker raskest. Finner du feilen, er den din. Finner du den ikke, vet du i det minste hva du skal fortelle den du ber om hjelp.

Til sjekklista Jeg trenger hjelp nå

Gjør dette først, før du endrer noe som helst

Ta backup av databasen før du rører en eneste innstilling. Feilsøking betyr at du skrur ting av og på, og uten backup har du ingen vei tilbake hvis noe blir verre. Skriv deretter ned tre ting: nøyaktig hva kunden ser (helst et skjermbilde), når problemet startet, og hva som ble endret rett før. Ble en plugin oppdatert? Byttet du webhotell? Kom det en WordPress-oppdatering? Nesten alle kassefeil starter rett etter en endring, og den endringen er som regel svaret. Har du disse tre opplysningene klare, går feilsøkingen mye raskere, uansett om du gjør den selv eller får hjelp.

Sjekklista

De sju vanligste årsakene, i den rekkefølgen du bør sjekke dem

Start øverst og jobb deg nedover. Rekkefølgen er ikke tilfeldig: de første punktene tar minst tid og løser flest saker. Test kassen på nytt etter hvert punkt, slik at du vet nøyaktig hva som fikset det.

1. Cache som ligger og lyver om kassen

Dette er den vanligste årsaken, og den raskeste å utelukke, og ett av punktene i Black Friday-sjekklisten før et salg med mye trafikk. Kurv, kasse og min konto skal aldri caches, fordi innholdet er forskjellig for hver eneste besøkende. Blir de likevel cachet, ser kunden en gammel versjon: tom handlekurv, feil totalsum, betalingsmåter som ikke stemmer, eller en side som bare ikke laster ferdig. Slik sjekker du: tøm all cache (i cache-pluginen din, og i Cloudflare hvis du bruker det), og prøv kassen på nytt i et privat nettleservindu. Virker det nå, var det cache. Da må du få på plass riktige unntak for /kurv/, /kasse/ og /min-konto/ i cache-pluginen, ellers kommer feilen tilbake. Bruker du Cloudflare, sjekk at du ikke har en Cache Rule som treffer kassen. Dette er også hovedmistenkt hvis feilen dukket opp rett etter en flytting av webhotell eller en ny cache-plugin.

2. En plugin eller temaoppdatering som krasjer med kassen

Nest vanligst, og typisk når feilen startet «helt av seg selv» over natta. Automatiske oppdateringer er ofte skrudd på uten at noen husker det. Slik sjekker du, helst på staging hvis du har det: deaktiver alle plugins unntatt WooCommerce og betalingsløsningen din, og test kassen. Virker den, skru på én plugin om gangen og test etter hver eneste. Den som får feilen tilbake, er synderen. Virker kassen fortsatt ikke med alt avskrudd, bytt midlertidig til et standardtema (Storefront eller Twenty Twenty-Four) og test igjen. Virker det da, ligger feilen i temaet ditt. Har du ikke staging og butikken har trafikk, gjør dette utenfor åpningstid, eller be om hjelp. Å skru av plugins i en live butikk midt på dagen skaper nye problemer.

3. JavaScript-feil som stopper «Fullfør bestilling»-knappen

Symptomet er tydelig: kunden fyller ut alt, trykker på knappen, og ingenting skjer. Ingen feilmelding, ingen bevegelse. Da har som regel et skript krasjet før WooCommerce rakk å sende skjemaet. Slik sjekker du: åpne kassen i Chrome, trykk F12, velg fanen Console, og fyll ut kassen som en kunde. Røde feilmeldinger som dukker opp i det du trykker på knappen, er sporet. Du trenger ikke forstå meldingen, men les hvilken fil den kommer fra. Står det et plugin-navn eller temanavn i filstien, har du funnet hvem som forstyrrer. Vanlige syndere er chat-widgeter, sporingsskript, popup-plugins og alt som legger seg oppå kassen. Skru av den ene tingen og test på nytt. Henger kassen med et snurrehjul i stedet, se når WooCommerce-kassen henger i innlasting.

4. Vipps, Klarna eller Stripe som ikke kommer tilbake

Kunden blir sendt til Vipps, betaler, og havner så på en feilside, eller blir stående og spinne. Pengene er trukket, men ordren finnes ikke i butikken. Her er det som regel returen som ryker, ikke selve betalingen. Slik sjekker du: logg inn i Vipps sin merchant-portal (eller Stripe, eller Klarna) og se om transaksjonen faktisk er registrert. Er den det, virker betalingen, og problemet ligger i webhooken tilbake til butikken. Sjekk deretter at retur-URL og webhook-URL i betalingsinnstillingene er riktige, og at de peker på https og på riktig domene. Har du nylig byttet domene, lagt på www, eller flyttet til nytt webhotell, er dette nesten helt sikkert årsaken. Sjekk også om en sikkerhetsplugin eller brannmur blokkerer innkommende kall fra betalingsleverandøren. Viktig: ikke refunder noe før du har sett hele bildet. Refusjon før du har rekonstruert ordren gjør opprydningen vanskeligere. Trenger du å gå dypere på betalingslaget, har vi en egen guide for betaling som feiler, med det som er spesifikt for kort, Klarna og Nexi, og en egen guide for Vipps.

5. Fraktmetoder som ikke dukker opp

Kunden fyller inn adressen og får beskjed om at det ikke finnes frakt til dem, eller kassen stopper der. Nesten alltid oppsett, ikke feil i koden. Slik sjekker du: gå til WooCommerce, Innstillinger, Frakt. Finnes det en fraktsone som faktisk dekker Norge, og har den minst én fraktmetode i seg? En sone uten metode er den vanligste tabben. Sjekk deretter om produktene har en fraktklasse som ingen metode dekker, og om du har vektbaserte regler der et produkt mangler vekt. Bruker du en integrasjon mot Bring, Posten eller Helthjem, sjekk om API-nøkkelen fortsatt er gyldig. De utløper, og da forsvinner fraktalternativene uten noen tydelig feilmelding. Bruker du Bring Fraktguiden, gå gjennom sjekklista for Bring Fraktguiden. Vil du heller at vi finner feilen, se frakt som ikke vises i kassen.

6. Ordre går gjennom, men bekreftelsen kommer aldri

Kunden betaler, ordren ligger i WooCommerce, men ingen e-post kommer fram. Kunden tror kjøpet feilet og bestiller på nytt, eller ringer deg. Dette er strengt tatt ikke en kassefeil, men det oppleves som det. Årsaken er nesten alltid e-postoppsettet: WordPress sin innebygde mail-funksjon er upålitelig på delt webhotell, og e-post uten riktig SPF- og DKIM-oppsett havner i søppelpost. Slik sjekker du: send en testordre til din egen adresse og se om den kommer fram, også i søppelpost. Kommer den ikke, installer en SMTP-plugin og send e-posten via en ordentlig e-posttjeneste i stedet for direkte fra webserveren. Sjekk samtidig at avsenderadressen bruker ditt eget domene, ikke en gmail-adresse, for da blir den ofte avvist. Mer om hvorfor WooCommerce ikke sender e-post, og om hvordan vi fikser levering, SPF, DKIM og DMARC.

7. Mva som beregnes feil i siste steg

Totalsummen endrer seg uventet i kassen, eller mva blir lagt på der den ikke skulle. For norske butikker er dette som regel VOEC-oppsettet eller B2B-kunder som skal ha fritak. Slik sjekker du: gå til WooCommerce, Innstillinger, Avgift, og se om avgiftsklassene faktisk stemmer med hvordan du selger. Sjekk deretter om prisene dine er lagt inn med eller uten mva, og om innstillingen sier det samme. Uoverensstemmelse mellom de to er den klassiske feilen, og den viser seg først i kassen, ikke på produktsiden. Selger du til utlandet, sjekk at avgiftsreglene per land er satt opp, og at kundens landvalg faktisk treffer riktig regel.

Kjenner du igjen symptomet?

Hopp rett til det som ligner mest på din situasjon

Er ett av symptomene under akkurat det du ser, peker det som regel mot et lite antall årsaker. Da kan du hoppe over sjekklista og gå rett på.

Ingenting skjer når kunden trykker på knappen

Ingen feilmelding, ingen ny side, bare stillhet. Se punkt 3 i sjekklista: dette er JavaScript-feil i ni av ti tilfeller. Åpne konsollen i nettleseren og se hva som er rødt i det du trykker. Er konsollen helt ren, se punkt 2 i stedet, fordi da er det trolig en plugin som blokkerer skjemaet uten å kaste feil. Et eksempel fra vår egen praksis: kassen som lastet i det uendelige på grunn av én regel i .htaccess.

Kunden er belastet, men ordren finnes ikke

Dette haster mest av alt på denne siden, fordi kunden har betalt for noe du ikke vet at du skylder dem. Se punkt 4. Kort versjon: bekreft i betalingsportalen at pengene faktisk er trukket, ikke refunder ennå, opprett ordren manuelt i WooCommerce så kunden får bekreftelsen sin, og finn deretter ut hvorfor webhooken ikke kom fram. Rekonstruksjonen redder kundeforholdet, webhook-fiksen hindrer at det skjer igjen i morgen.

Kassen er tom selv om kunden la varer i handlekurven

Handlekurven tømmer seg selv, eller kassen sier at den er tom. Se punkt 1 først, fordi cache på kassesider gir nøyaktig dette symptomet. Er cache utelukket, handler det om sesjoner: sjekk om butikken kjører på både med og uten www, eller både http og https, for da mister nettleseren sesjonen mellom sidene.

Det virker for meg, men kundene klager

Den vanskeligste varianten, og en klassisk felle. Du tester som innlogget administrator, i din vanlige nettleser, med ting allerede i cachen. Kunden er utlogget, på mobil, kanskje i Safari. Test på nytt i privat vindu, utlogget, på en telefon. Klarer du ikke å gjenskape feilen, be en kunde om et skjermbilde og spør hvilken nettleser og enhet de bruker. Uten gjenskaping er all videre feilsøking gjetting.

Alt virket i går, ingen har rørt noe

Noen har som regel rørt noe, det var bare ikke et menneske. Sjekk om automatiske oppdateringer er skrudd på for plugins eller WordPress-kjernen, og se på datoene. Sjekk også om webhotellet har oppgradert PHP-versjonen, som de gjør uten særlig varsel. Se deretter punkt 2. Fant du en oppdatering som traff samme døgn som feilen, har du sannsynligvis funnet årsaken.

Bare noen kunder får problemer, ikke alle

Det mønsteret er verdifull informasjon, ikke et mysterium. Er det bare mobilbrukere, se punkt 3, siden det ofte er et skript som oppfører seg annerledes på touch. Er det bare kunder i utlandet, se punkt 5 og 7, altså frakt- og avgiftsregler per land. Er det bare bedriftskunder, se punkt 7 om mva-fritak. Er det bare enkelte produkter, sjekk fraktklasse og lagerstatus på nettopp de produktene.

Når du bør slutte å feilsøke selv

Egen feilsøking er verdt det opp til et punkt. Etter det koster tapt omsetning og risikoen for å gjøre skade mer enn hjelpen ville gjort. Her er de fire tegnene på at du har nådd det punktet.

Kunder er belastet uten å få ordre

Dette er det ene punktet der du ikke bør vente. Hver time som går, er det flere kunder som har betalt for noe du ikke vet at du skylder dem, og oppryddingen blir vanskeligere jo lenger det står. Rekonstruer ordrene, og få webhooken fikset raskt.

Du har gått gjennom hele lista uten å finne noe

Har du sjekket alle sju punktene og kassen fortsatt ikke virker, ligger feilen sannsynligvis dypere: i serverlogger, i en konflikt mellom to plugins som bare oppstår sammen, eller i noe på webhotellet. Da er videre gjetting dyrere enn å få noen til å lese loggene.

Butikken taper mer enn hjelpen koster

Regn på det. Omsetter du normalt for noen tusen kroner om dagen, koster et døgn med ødelagt kasse mer enn en fiks. Da er det ikke sparing å bruke to dager til på å prøve selv, det er en dyrere måte å løse det på.

Du er usikker på om du gjør det verre

Er du i ferd med å redigere filer du ikke helt forstår, eller skru av ting i en live butikk uten backup, stopp. Å gjøre en kassefeil om til en nedlagt butikk er fullt mulig, og det er en dyrere reparasjon enn den du startet med.

Slik gjør du feilsøkingen billigere for deg selv

Uansett hvem du ber om hjelp, oss eller noen andre, går jobben raskere og koster mindre hvis du har dette klart på forhånd. Det meste av tiden i en kassesak går til å finne ut hva som faktisk skjer.

Skriv ned symptomet slik kunden ser det

Ikke din tolkning av hva som er galt, men hva som faktisk skjer på skjermen. Skjermbilde er bedre enn beskrivelse. Feilmeldingen ordrett er bedre enn en omskriving av den.

Finn ut når det startet, og hva som skjedde rett før

Dato og helst klokkeslett. Sjekk oppdateringsloggen for plugins og WordPress. Nesten alle kassefeil har en utløsende endring, og den endringen sparer flere timers leting.

Noter hva du allerede har prøvd

Ellers gjør den som hjelper deg de samme testene på nytt, og du betaler for det. Har du utelukket cache og plugin-konflikt, er det verdifull informasjon som forkorter jobben.

Ha tilgangene klare

WordPress-admin, webhotell eller FTP, og gjerne tilgang til betalingsportalen. Å vente på passord mens butikken står, er den dyreste formen for venting som finnes.

Si fra om butikken tar imot ordrer akkurat nå

Det avgjør hvordan feilsøkingen legges opp. En butikk som taper salg hvert minutt håndteres annerledes enn en som er i ferd med å lanseres, og den forskjellen bør sies med én gang.

Det folk lurer på når kassen har stoppet

Hvorfor kommer kundene til kassen, men fullfører aldri?

Skjer det for alle, er det som regel teknisk: JavaScript-feil som stopper knappen, en betalingsmåte som ikke vises, eller validering som avviser gyldige opplysninger. Se punkt 3 og 4 i sjekklista. Skjer det bare for noen, og resten kommer gjennom, er det oftere friksjon enn feil: frakt som først dukker opp i siste steg, tvungen kontoopprettelse, eller for mange felter. Det første krever en kodefiks, det andre krever endringer i selve kjøpsflyten. Det er verdt å vite hvilken av de to du har, før du betaler noen for å fikse feil type problem.

Kunden har betalt med Vipps, men ordren mangler. Hva gjør jeg akkurat nå?

Fire steg, i denne rekkefølgen. Bekreft først i Vipps sin merchant-portal at betalingen faktisk er gjennomført. Ikke refunder, selv om det føles ryddig, for det gjør rekonstruksjonen vanskeligere. Opprett så ordren manuelt i WooCommerce med riktig kunde, riktige produkter og riktig sum, og merk den som betalt, slik at kunden får bekreftelsen sin. Finn til slutt ut hvorfor webhooken ikke nådde fram, ellers skjer det samme med neste kunde. Punkt 4 i sjekklista går gjennom hvor du ser etter.

Kan cache virkelig ødelegge kassen?

Ja, og det er den vanligste enkeltårsaken vi ser. Kurv, kasse og min konto viser forskjellig innhold til hver enkelt besøkende, så de skal aldri caches. Blir de likevel lagret, får kunden servert en gammel versjon av siden: tom handlekurv, feil sum, eller betalingsmåter som ikke stemmer. De fleste cache-plugins utelukker disse sidene automatisk, men unntaket blir ofte borte ved flytting til nytt webhotell, ved bytte av cache-plugin, eller når noen legger inn en Cache Rule i Cloudflare uten å tenke på kassen.

Bør jeg skru av plugins for å teste når butikken er live?

Helst ikke midt på dagen. Skrur du av plugins i en live butikk, kan du skape nye feil mens du leter etter den gamle, og kunder som er inne akkurat da får en dårlig opplevelse. Har du staging, gjør testingen der. Har du ikke staging, gjør det på det roligste tidspunktet i døgnet, ta backup først, og skru ting tilbake på med én gang du har svaret. Er butikken travel og feilen alvorlig, er dette et av de tydeligste tegnene på at det lønner seg å be om hjelp i stedet.

Hvordan vet jeg om feilen ligger hos betalingsleverandøren og ikke hos meg?

Logg inn i portalen til betalingsleverandøren og se om transaksjonene registreres der. Kommer de fram, virker selve betalingen, og problemet ligger mellom leverandøren og butikken din, altså i retur-URL eller webhook. Kommer de ikke fram i det hele tatt, stopper det tidligere, i oppsettet eller i nøklene. Sjekk også driftsmeldingene til leverandøren, for de har nedetid av og til, og da er det ingenting galt hos deg. Det er verdt å utelukke før du bruker en kveld på å lete i egen kode.

Kassen virker for meg, men kundene sier den ikke gjør det. Hvem har rett?

Kundene, som regel. Du tester innlogget som administrator, i en nettleser som allerede har butikken i cache, sannsynligvis på desktop. Kunden er utlogget, kanskje på mobil, kanskje i Safari, kanskje med en annonseblokker. Test på nytt i privat vindu, utlogget, på telefon. Får du fortsatt ikke gjenskapt feilen, spør en kunde om skjermbilde, nettleser og enhet. Feil du ikke klarer å gjenskape, kan du heller ikke være sikker på at du har fikset.

Hva koster det å få noen til å fikse det?

Hos oss starter en kassefiks på 3 990 kr for ett tydelig problem på én betalingsløsning, med fastpris avtalt før arbeidet starter og 14 dagers garanti mot at samme feil dukker opp igjen. Mer sammensatte saker, flere betalingsløsninger samtidig eller uklare symptomer, ligger høyere. Du finner nivåene og hva som inngår på siden om å fikse WooCommerce-kassen. Er problemet noe helt annet enn kassen, se WooCommerce-feilsøking i stedet.

Hvordan unngår jeg at dette skjer igjen?

To ting løser det meste. Skru av automatiske oppdateringer av plugins, og test oppdateringer på staging før de går i produksjon. De aller fleste «alt virket i går»-sakene starter med en automatisk oppdatering ingen fulgte med på. Sett deretter opp en enkel overvåking som varsler deg hvis kassen slutter å svare, slik at du oppdager det før kundene gjør det. Begge deler inngår i WooCommerce-vedlikehold, men du kan fint sette det opp selv også.

Fant du ikke feilen?

Har du gått gjennom lista uten å komme til bunns i det, ser vi på det for deg. Fortell hva kundene opplever og hva du allerede har utelukket, så slipper vi å gjøre de samme testene om igjen. Vi bekrefter henvendelsen innen 1 time i arbeidstiden, og gir fastpris før noe arbeid starter.

Se hva en kassefiks koster Send oss en e-post