Feilsøkingsguide

Betalingen feiler i kassen? Finn ut hvor den stopper.

En betaling kan stoppe fire steder: før kunden sendes til betalingsløsningen, hos betalingsløsningen, på veien tilbake til butikken, eller når pengene skal trekkes. Hvor den stopper, avgjør hva du skal sjekke. Denne guiden går gjennom de sju vanligste årsakene for kort, Vipps, Klarna og Nexi, i den rekkefølgen som løser flest saker raskest.

Til sjekklista Jeg trenger hjelp nå

Før du gjør noe: finn ut hvor betalingen stoppet

Logg inn hos betalingsløsningen din, altså Stripe Dashboard, Klarna Merchant Portal, Nexi Checkout Portal eller Vipps MobilePay Business Portal, og se om betalingen ligger der. Er den registrert som gjennomført hos leverandøren, mens ordren i WooCommerce mangler eller står som «venter på betaling», virker selve betalingen. Da er det meldingen tilbake til butikken som ikke kom fram, og da skal du ikke refundere. Opprett heller ordren manuelt så kunden får bekreftelsen sin, og finn deretter ut hva som blokkerer meldingen. Er betalingen ikke registrert hos leverandøren i det hele tatt, stoppet det tidligere, og da er det nøklene, oppsettet eller selve kassen du skal se på. Ta backup av databasen før du endrer en eneste innstilling, og skriv ned tre ting: hva kunden ser, når det startet, og hva som ble endret rett før.

Sjekklista

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

Start øverst. De første punktene tar minst tid og forklarer flest saker. Test en bestilling på nytt etter hvert punkt, gjennom hver betalingsmåte du tilbyr, slik at du vet hva som faktisk løste det.

1. Er det betalingsløsningen som har driftsproblemer, og ikke deg?

Dette tar under et minutt og sparer deg for en hel kveld med leting i din egen butikk. Alle betalingsløsningene har driftsmeldinger: Vipps MobilePay, Klarna og Stripe har egne statussider, og Nexi har en teknisk statusside for Checkout. Sjekk dem, og se om andre norske butikker melder om det samme. Er det driftsavvik hos leverandøren, er det ingenting galt hos deg, og det eneste fornuftige er å vente. Har du en butikk med mye trafikk, legg en midlertidig melding i kassen om at betalingsmåten er ustabil, og sørg for at kundene har minst én annen betalingsmåte å velge. Butikker som bare tilbyr én betalingsmåte, er de som taper mest på en time med nedetid hos leverandøren.

2. Kunden har betalt, men ordren står som «venter på betaling»

Dette er den klart vanligste betalingsfeilen, uansett leverandør. Slik oppstår den: kunden godkjenner betalingen hos leverandøren, og skal så sendes tilbake til butikken. Mange lukker fanen eller appen før det skjer. For nettopp dette sender leverandøren en egen melding direkte til butikken din, en callback eller webhook, som skal oppdatere ordren automatisk. Kommer ikke den meldingen fram, blir ordren stående som ubetalt selv om pengene er trukket. Årsaken er nesten alltid at noe i butikken blokkerer innkommende kall: en sikkerhetsplugin som Wordfence, en brannmur hos webhotellet, en regel i Cloudflare, eller en regel i .htaccess. Klarna og Nexi sender meldingen til adresser under /wc-api/, som må være åpne, og begge krever at pene permalenker er skrudd på i WordPress. Stripe bruker bare adressen https://dittdomene.no/?wc-api=wc_stripe, og i innstillingene for Stripe skal webhook-status stå som konfigurert i både live-fanen og testfanen. Er signeringshemmeligheten feil, avviser utvidelsen meldingen uten å oppdatere ordren, men sender som regel svarkode 204 tilbake, som Stripe regner som vellykket levering. Da ser leveringen grei ut i Stripe Dashboard, mens Stripe-loggen i WooCommerce viser «Webhook validation failed». For PayPal finnes det en egen «Webhooks Status» under fanen Connection, med knappene Resubscribe og Simulate. Slik sjekker du: åpne WooCommerce, Status og Logger, velg loggen for betalingsløsningen, og se etter avviste kall rundt tidspunktet for bestillingen. De fleste leverandørene viser også hvert forsøk med svarkode i sin egen portal. Er det Vipps, går Vipps-guiden gjennom nøyaktig dette.

3. Feil nøkler, eller testnøkler i produksjon

Alle betalingsløsningene har to sett nøkler: ett for test og ett for produksjon. Stripe skiller dem med pk_test og sk_test mot pk_live og sk_live. Klarna har egne nøkler for testmiljøet playground og for produksjon, og de gjelder per region, så nøkler fra feil region eller feil Klarna-plugin gir samme symptom. Nexi har egne testnøkler og livenøkler for Merchant ID, Checkout key og Secret key, og de må limes inn uten mellomrom foran eller bak. Vipps har fire opplysninger i to versjoner. Symptomet på testnøkler i produksjon er at alt ser riktig ut i oppsettet, mens ingen ekte betalinger går gjennom, eller at betalingsvinduet er tomt. Sjekk at testmodus er skrudd av, og at nøklene i WooCommerce faktisk er produksjonsnøklene. Nøkler kan også slutte å virke hvis de er byttet i leverandørens portal uten at de er oppdatert i WooCommerce. Har butikken nettopp blitt satt opp, eller har noen jobbet på den i et testmiljø, er dette det første du skal utelukke. Skal du teste kassen før et stort salg, uten ekte kortdata i live-modus, se Black Friday-sjekklisten.

4. Betalingsmåten vises ikke i kassen i det hele tatt

Får kundene aldri opp betalingsmåten som valg, er det som regel oppsett og ikke feil. Sjekk i denne rekkefølgen: at pluginen er aktivert og betalingsmåten er skrudd på under WooCommerce, Innstillinger og Betalinger, at butikkvalutaen er norske kroner, og at nøklene er lagt inn. Sjekk deretter det som er spesifikt for leverandøren. Klarna viser seg ikke før kunden har valgt et land Klarna støtter, krever at WooCommerce har en publisert vilkårsside, og krever at serveren kan gjøre eksterne kall, noe du ser under WooCommerce, Status og Systemstatus som «Remote post» og «Remote get». Bruker du en plugin for flere valutaer, må betalingsmåten være satt opp inne i den også. Vises betalingsmåten for deg som administrator, men ikke for kundene, se etter regler som skjuler betalingsmåter basert på kundegruppe, land, handlekurvsum eller beløpsgrenser i selve pluginen.

5. Beløpet stemmer ikke: desimaler, mva og avrunding

Mange norske butikker setter WooCommerce til null desimaler, fordi prisene er hele kroner. Betalingsløsningene regner derimot i øre, og når mva på hver ordrelinje rundes av til hele kroner, stemmer ikke summen av linjene med totalen lenger. Nexi avviser da betalingen med HTTP 400 og meldingen «Amount does not match sum of orderitems». Klarna logger «BAD_VALUE: order_lines[0].total_tax_amount» når avgiftsoppsettet er feil, typisk en avgiftsregel på null prosent som ikke skulle vært der, eller avrunding som ikke går opp. Symptomet for kunden er en feilmelding i samme øyeblikk betalingen skal starte, før leverandøren i det hele tatt er involvert. Slik sjekker du: gå til WooCommerce, Innstillinger og Generelt, og sett antall desimaler til to. Gå deretter til Avgift og se om prisene er lagt inn med eller uten mva, og om innstillingen sier det samme. Selger du til utlandet, sjekk at avgiftsreglene per land faktisk treffer riktig regel.

6. Reservasjonen utløper, eller ordren står som «på vent» uten at pengene trekkes

Kort, Vipps og Klarna reserverer beløpet først, og trekker det når butikken fanger betalingen. Det kan skje automatisk ved bestilling, eller manuelt når varen sendes. Problemet oppstår når innstillingen for når du fanger, ikke passer måten du faktisk sender varer på. Fanger du for sent, utløper reservasjonen, og du står igjen med en ordre som ser betalt ut, men som aldri gir penger på konto. Fanger du for tidlig på fysiske varer, trekker du penger før du har sendt noe. Selger du noe som leveres umiddelbart, bør du fange automatisk. Sender du fysiske varer noen dager senere, må rutinen for manuell fanging faktisk følges. Klarna-ordrer som blir stående som «på vent» og ikke lar seg fullføre, skyldes ofte innstillingen for fanging ved fullført ordre i Klarna sin ordrehåndtering. Skru den av, oppdater statusen manuelt i WooCommerce, og fang beløpet i Klarna sin portal. Ser du flere ordrer med utløpte reservasjoner, er det som regel rutinen og ikke teknikken som må endres.

7. Skript, tema eller cache som ødelegger betalingssteget

Kunden fyller ut alt, og så skjer ingenting: betalingsvinduet er tomt, knappen gjør ingenting, eller siden laster bare på nytt. Da har som regel noe krasjet i nettleseren før betalingen rakk å starte. Åpne kassen i Chrome, trykk F12, velg fanen Console, og fyll ut kassen som en kunde. Røde meldinger som dukker opp i det du trykker på knappen, er sporet. Klarna gir en tydelig melding hvis temaet ditt laster klarna.js manuelt i tillegg til pluginen: «Another Klarna Web SDK was already included in the page». Et tomt betalingsvindu fra Nexi peker som regel på nøkler med mellomrom eller på en annen plugin som forstyrrer. Tilpassede kassemaler som fjerner standardfelt eller flytter valgknappene for betalingsmåte, oversettelsesplugins som ikke har unntak for kassen, og cache som treffer kassen, gir samme type symptom. Slik isolerer du det: bytt midlertidig til et standardtema, skru av alle plugins unntatt WooCommerce og betalingsløsningen, og test i et privat vindu, utlogget, på mobil. Virker det da, skru på én ting om gangen til feilen kommer tilbake. Har butikken trafikk, gjør dette utenfor åpningstid eller på staging.

Kjenner du igjen symptomet?

Hopp rett til det som ligner mest

Måten feilen viser seg på, sier mye om hvor du bør lete. Kjenner du igjen en av disse, kan du hoppe over deler av sjekklista.

Kunden er belastet, men det finnes ingen ordre

Gå til punkt 2. Dette er meldingen tilbake til butikken som er blokkert, og det er den vanligste betalingssaken som finnes. Kort versjon: bekreft betalingen i leverandørens portal, ikke refunder, opprett ordren manuelt så kunden får bekreftelsen, og finn deretter ut hva som blokkerer meldingen. Fikser du bare den ene ordren uten å finne blokkeringen, skjer det samme med neste kunde i morgen.

Ordrer blir stående som «venter på betaling»

Samme underliggende årsak som over, bare sett fra admin-siden. Ser du flere slike ordrer over tid, og noen av dem faktisk er betalt hos leverandøren, er meldingen tilbake blokkert. Se punkt 2. Er ingen av dem betalt, er det derimot vanlig at kunder starter en betaling og ombestemmer seg underveis i BankID eller i appen, og da er det ikke en feil i det hele tatt. WooCommerce kan kansellere slike ubetalte ordrer automatisk etter et gitt antall minutter, under Innstillinger, Produkter og Lager.

Betalingsmåten er skrudd på, men vises ikke i den nye kassen

Butikker som er satt opp med WooCommerce 8.3 (november 2023) eller nyere, får en kasse bygget med blokker som standard, og en betalingsplugin som bare støtter den klassiske kassen, vises ikke der. Er det den eneste betalingsmåten, får kunden beskjed om at ingen betalingsmåter er tilgjengelige. Slik sjekker du: åpne Sider og Kasse i redigeringen og klikk på betalingsvalgene i kasseblokken. Varsler WooCommerce om en utvidelse som ikke støtter blokkene, har du svaret, og i sidepanelet kan du da bytte tilbake til den klassiske kassen. Gjør det samme med handlekurven. Den varige løsningen er en versjon av pluginen som støtter blokkene, så sjekk endringsloggen. Vises betalingsmåten ikke i den klassiske kassen heller, gå til punkt 4.

Ordren sto ubetalt, og ble betalt av seg selv timer senere

Bruker du Stripe, feilet som regel det første forsøket på å varsle butikken, mens et senere forsøk kom gjennom. I live-modus prøver Stripe på nytt i opptil tre dager, med stadig lengre mellomrom. Finn årsaken med punkt 2, ellers skjer det igjen. Én årsak som er lett å overse, er en omdirigering, for eksempel fra http til https eller til www. Stripe regner den som en feilet levering, så adressen i Stripe må være den endelige. Under Webhooks i Workbench i Stripe Dashboard ser du hvert forsøk med svarkode, og med Resend kan du sende en melding på nytt i opptil 15 dager.

Betalingsvinduet er tomt, eller Klarna laster ikke

To kandidater. Nøkler med mellomrom, testnøkler i produksjon eller nøkler fra feil region, se punkt 3. Eller et skript som krasjer før vinduet rekker å laste, se punkt 7. Konsollen i nettleseren avgjør hvilken av de to det er: en rød melding peker på punkt 7, en ren konsoll peker på punkt 3.

Kunden får «betalingen mislyktes» med én gang

Kommer feilmeldingen i samme sekund som betalingen skal starte, før kunden har sett leverandøren i det hele tatt, er det som regel beløpet eller nøklene. Se punkt 5 om desimaler og avrunding først, deretter punkt 3. Loggen under WooCommerce, Status og Logger forteller nesten alltid hva leverandøren svarte, og der står den faktiske feilmeldingen.

Alt virker i testmodus, men ikke når butikken er live

Punkt 3, nesten uten unntak. Nøklene som er lagt inn, er testnøklene, testmodus er fortsatt på, eller produksjonsnøklene ble aldri hentet. For Nexi kan det i tillegg være at kontoen ikke er godkjent for live ennå, eller at valutaen eller betalingsmåten ikke er aktivert på kontoen. Bekreft det i portalen før du leter videre i butikken.

Betalingsmåten vises for meg, men ikke for kundene

Gå til punkt 4. Du tester innlogget som administrator, kanskje med et annet land eller en annen valuta i profilen din enn kundene har. Se etter regler som skjuler betalingsmåter etter kundegruppe, land eller handlekurvsum, og sjekk beløpsgrensene i pluginen. Test alltid i et privat vindu, utlogget, med en vanlig kundeadresse i Norge.

Ordren står som «på vent» og lar seg ikke fullføre

Gå til punkt 6. Beløpet er reservert, men ikke fanget, og betalingsløsningen holder ordren til det skjer. For Klarna er det ofte innstillingen for fanging ved fullført ordre som står i veien. Skru den av, sett statusen manuelt, og fang beløpet i portalen. Sjekk samtidig at reservasjonen ikke allerede har utløpt, for da må kunden betale på nytt.

Refusjon gjort i leverandørens portal vises ikke i WooCommerce

Refusjoner går pålitelig én vei: fra ordresiden i WooCommerce til leverandøren. Refunderer du direkte i portalen, er det ikke sikkert meldingen tilbake oppdaterer ordren. Gjør refusjoner fra WooCommerce når du kan, og sett statusen manuelt til refundert hvis du allerede har gjort det i portalen. Er beløpet bare reservert og ikke trukket, skal reservasjonen kanselleres, ikke refunderes, og det er to forskjellige handlinger.

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

Noen har som regel rørt noe, det var bare ikke et menneske. Fire vanlige forklaringer: en plugin ble oppdatert automatisk, ofte sikkerhetspluginen, og nye regler blokkerer nå meldingen fra leverandøren, se punkt 2. Nøkler ble byttet i portalen uten at WooCommerce ble oppdatert, se punkt 3. Webhotellet endret PHP-versjon eller brannmur. Eller butikken byttet domene, fikk www, eller gikk fra http til https, slik at adressene leverandøren skal svare til ikke stemmer lenger. Sjekk oppdateringsdatoene før du leter videre.

Mange mislykkede betalinger fra kunder du ikke kjenner

Bølger av avviste kort med ukjente navn er sjelden en feil i betalingsløsningen. Som regel tester noen stjålne kortnumre i kassen din. Ikke slett ordrene, og les guiden om card testing.

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

Med betaling er innsatsen høyere enn med de fleste andre feil, fordi det er kundenes penger som står i spill. Her er de fire tegnene på at det haster å få hjelp.

Kunder er belastet uten å få ordre

Er dette skjedd mer enn én gang, fortsetter det å skje til blokkeringen er funnet. Hver time betyr flere kunder som har betalt for noe du ikke vet at du skylder dem, og en avstemming som blir vanskeligere for hver bestilling.

Flere betalingsmåter feiler samtidig

Feiler både kort og Vipps, eller både Klarna og Nexi, på én gang, er det ikke leverandøren. Da er det noe i butikken som stopper alt: cache, en sikkerhetsplugin, en PHP-oppgradering eller et domenebytte. Det er raskere å finne for noen som har sett mønsteret før.

Du har gått gjennom lista uten å finne noe

Har du utelukket alle sju punktene og det fortsatt feiler, ligger årsaken i loggene: avviste kall, feilmeldinger fra leverandørens API, eller en konflikt mot en annen plugin. Da er videre gjetting dyrere enn å få noen til å lese dem ordentlig.

Du vurderer å skru av sikkerhetspluginen for å teste

Det kan være riktig som en kort, kontrollert test, men å la den stå av mens du leter videre er en dårlig idé på en butikk med kundedata. Får du ikke gjort testen trygt, er det bedre å få noen til å finne den ene regelen som blokkerer, enn å ta ned forsvaret.

Slik gjør du feilsøkingen raskere

Betalingsfeil er raskere å løse enn de fleste andre feil, fordi det finnes logger på begge sider. Har du dette klart, går jobben vesentlig fortere, uansett hvem du ber om hjelp.

Finn ett konkret eksempel

Én bestilling der du vet hva som skjedde: tidspunkt, beløp, betalingsmåte, og hva kunden opplevde. Ett eksempel som kan spores gjennom begge systemer er mer verdt enn en generell beskrivelse av at betalingen er ustabil.

Sjekk om betalingen finnes hos leverandøren

Dette avgjør hvilken halvdel av problemet det er. Betaling gjennomført uten ordre peker på meldingen tilbake til butikken. Ingen betaling registrert peker på nøkler, oppsett eller kassen. Å vite hvilken sparer den første timen.

Noter hva som ble endret i det siste

Plugin-oppdateringer, bytte av webhotell, nye sikkerhetsregler, nytt domene, eller nøkler som er byttet. Nesten alle betalingsfeil som oppstår plutselig, har en slik utløser.

Ha tilgangene klare

WordPress-admin, og helst lesetilgang til leverandørens portal. Uten portalen kan vi se hva butikken tror har skjedd, men ikke hva som faktisk skjedde hos leverandøren, og da blir feilsøkingen halvblind.

Si fra om butikken tar imot bestillinger nå

En butikk som fortsetter å ta betalinger med en blokkert melding tilbake, samler opp flere saker hver time. Da prioriterer vi å stoppe blødningen først, og rydde opp i det som allerede har skjedd etterpå.

Kilder

Sist kontrollert 12. november 2026. Dokumentene er leverandørenes egne og på engelsk. Pluginene oppdateres ofte, så sjekk dem hvis det du ser i admin ikke stemmer med denne siden.

WooCommerce: Setting up webhooks (Stripe): webhook-adressen ?wc-api=wc_stripe og webhook-statusen i live- og testfanen.
Kildekoden til Stripe-utvidelsen, versjon 11.2.0: hva utvidelsen svarer og logger når signeringshemmeligheten er feil.
Stripe: Receive Stripe events in your webhook endpoint: omdirigeringer som feilet levering, nye forsøk i opptil tre dager, svarkoder og Resend.
WooCommerce: Cart and Checkout Blocks: blokkassen som standard fra versjon 8.3, betalingsplugins som ikke støtter den, og veien tilbake til klassisk kasse.
WooCommerce: How to configure caching plugins: hvorfor handlekurv, kasse og Min konto ikke skal caches.
WooCommerce: Products Settings: «Hold stock», som kansellerer ubetalte ordrer etter et antall minutter.
Klarna: Troubleshoot guide, Klarna through WooCommerce: permalenker, vilkårsside, eksterne kall, støttet land, BAD_VALUE-feilen og ordrer som blir stående på vent.
Klarna for WooCommerce (WordPress.org): Klarna som betalingsmåte i den vanlige kassen.
Kustom Checkout for WooCommerce (WordPress.org): at Kustom er tidligere Klarna Checkout og ble et eget selskap i 2024.
Kustom Docs: WooCommerce: at Kustom Checkout erstatter kassesiden, og at nøkler og avtale kommer fra Kustom.
Nexi: Checkout for WooCommerce: permalenker, /wc-api/, nøkler uten mellomrom, to desimaler, tomt betalingsvindu og statussiden.
Nexi Checkout (WordPress.org): at Nexi Checkout tidligere het Nets Easy.

Det butikkeiere spør om når betalingen svikter

Kunden sier hen har betalt, men jeg ser ingen ordre. Hva gjør jeg akkurat nå?

Fire steg, i denne rekkefølgen. Bekreft først i leverandørens portal at betalingen faktisk er gjennomført, med beløp og tidspunkt. Ikke refunder, selv om det føles ryddig overfor kunden, fordi det gjør avstemmingen vanskeligere. Opprett så ordren manuelt i WooCommerce med riktige produkter og riktig sum, og merk den som betalt, slik at kunden får bekreftelsen sin og du har et bilag. Finn deretter ut hvorfor meldingen fra leverandøren ikke nådde fram, ellers gjentar det seg. Punkt 2 i sjekklista går gjennom hvor du leter.

Hvorfor står ordren som «venter på betaling» når kunden har betalt?

Fordi bestillingen fullføres på to måter, og den ene er avhengig av at kunden kommer tilbake til butikken. Lukker kunden fanen eller appen etter å ha godkjent betalingen, er butikken helt avhengig av meldingen leverandøren sender direkte til den. Kommer ikke den meldingen fram, står ordren igjen som ubetalt. Det er sjelden leverandøren som er problemet: som regel blokkerer noe i butikken det innkommende kallet, typisk en sikkerhetsplugin, en brannmur hos webhotellet, eller en regel i Cloudflare.

Spiller det noen rolle om det er kort, Vipps, Klarna eller Nexi?

Logikken er den samme for alle: sjekk portalen, sjekk meldingen tilbake, sjekk nøklene, sjekk fanging. Detaljene er forskjellige. Klarna og Nexi krever pene permalenker og at adressene under /wc-api/ er åpne. Stripe bruker adressen ?wc-api=wc_stripe og en egen signeringshemmelighet som må stemme. Klarna krever i tillegg en publisert vilkårsside og et støttet land i kassen. Nexi er streng på desimaler. Vipps har en egen flyt mellom nettleser, app og BankID, og en egen guide på Vipps fungerer ikke.

Jeg har Nets Easy eller Klarna Checkout. Gjelder dette meg?

Ja, men begge har fått nye navn. Nets Easy heter nå Nexi Checkout, også pluginen, så alt om Nexi her gjelder deg. Klarna er to løsninger. Klarna for WooCommerce legger Klarna inn som betalingsmåte i den vanlige kassen, og det er den sjekklista handler om. Klarna Checkout heter nå Kustom Checkout og kommer fra Kustom, et eget selskap siden 2024. Den erstatter hele kassesiden med Kustoms egen kasse, og nøkler og avtale kommer fra Kustom, ikke fra Klarna. Se under WooCommerce, Innstillinger og Betalinger hvilken av dem butikken bruker.

Hvorfor virker betalingen i testmodus, men ikke når butikken er live?

Nesten alltid fordi nøklene som ligger i WooCommerce er testnøklene, eller fordi testmodus fortsatt er skrudd på. Alle leverandørene har to sett nøkler, og de er lette å blande. Sjekk at produksjonsnøklene er hentet fra portalen og limt inn uten mellomrom, og at testmodus er av. For Nexi kan det i tillegg være at kontoen ikke er godkjent for live ennå, eller at valutaen ikke er aktivert på kontoen.

Hva betyr «Amount does not match sum of orderitems»?

At totalsummen WooCommerce sender, ikke stemmer med summen av ordrelinjene, som regel med noen få øre. Det skjer når WooCommerce er satt til null desimaler og mva på hver linje rundes av til hele kroner, mens Nexi regner i øre. Sett antall desimaler til to under WooCommerce, Innstillinger og Generelt, og sjekk avgiftsoppsettet. Klarna gir en beslektet feil, «BAD_VALUE: order_lines[0].total_tax_amount», av samme type årsak.

Kan en sikkerhetsplugin eller Cloudflare virkelig stoppe betalinger?

Ja, og det er en av de vanligste årsakene vi ser. Sikkerhetsplugins og brannmurer er laget for å blokkere automatiske forespørsler utenfra, og meldingen fra leverandøren ser i utgangspunktet ut som nettopp det. Wordfence, brannmurer hos webhotellet, regler i Cloudflare og oppsett i .htaccess kan alle stoppe kallet uten å si fra. Symptomet er alltid det samme: betalingen går gjennom hos leverandøren, men ordren oppdateres aldri i butikken. Løsningen er ikke å skru av sikkerheten, men å tillate nettopp disse kallene.

Hva koster det å få noen til å se på det?

En kassefiks starter 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. Er det ordrer som må avstemmes og rekonstrueres i tillegg, sier vi fra om omfanget før vi går i gang. Se fikse WooCommerce-kasse for hva som inngår. Gjelder det Vipps spesifikt, starter feilretting på 1 990 kr, se Vipps til WooCommerce. Hele oversikten står på prissiden.

Hvordan unngår jeg at dette skjer igjen?

Test en ekte bestilling gjennom hver betalingsmåte etter hver større endring, på mobil, i privat vindu, og lukk fanen med vilje etter godkjenning. Da tester du nettopp den flyten som feiler oftest. Sjekk i tillegg jevnlig om det ligger ordrer som venter på betaling der kunden faktisk har betalt, for det er tidlig varsel om at meldingen tilbake er blokkert igjen. Skru av automatiske oppdateringer av plugins, og test oppdateringer på staging først. Løpende overvåking av dette inngår i WooCommerce-vedlikehold.

Finner du ikke hvor betalingen stopper?

Fortell oss hvilken betalingsmåte det gjelder, hva kundene opplever, og om betalingen finnes i leverandørens portal. Har du sjekket noe av lista allerede, si det, så slipper vi å gjøre det 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