Penetrationtest

Betaling i webshoppen: hvad er jeres ansvar, og hvad er betalingsudbyderens?

Betaling i webshoppen: hvad er jeres ansvar, og hvad er betalingsudbyderens?

Når en kunde betaler i webshoppen, er der næsten altid to virksomheder involveret: webshoppen og betalingsudbyderen. En penetrationstest kan kun undersøge den del, webshoppen selv råder over. Hvor grænsen går, afhænger af, hvordan betalingen er koblet på webshoppen, og det skal være afklaret, før testen bestilles.

Det korte svar er, at webshoppen har ansvar for alt det, der sker, før og efter kunden møder betalingsudbyderen: kurven, prisen, ordren, kundens konto og den måde, betalingen er indbygget på. Udbyderen har ansvar for sin egen platform. Testen bør dække webshoppens del grundigt og respektere grænsen til udbyderen.

Betalingen går gennem to virksomheder

For kunden er betalingen ét skridt i købet. For virksomheden er det et samarbejde med en udbyder, som har sine egne systemer, sine egne vilkår og sit eget ansvar. Udbyderens platform er ikke webshoppens at teste, og en test af den kræver udbyderens udtrykkelige tilladelse.

Det betyder ikke, at betalingen falder uden for testen. Mange af de spørgsmål, der har størst betydning for webshoppen, ligger på webshoppens side af grænsen. Det gælder for eksempel, om en ordre kan registreres som betalt, uden at betalingen er gennemført, eller om prisen kan ændres undervejs. → Er en penetrationstest lovlig?

Hvordan er betalingen koblet på?

Den første opgave er at finde ud af, hvordan betalingen er bygget ind. Spørg webbureauet eller den, der har udviklet webshoppen, og læs betalingsudbyderens beskrivelse af løsningen. Overordnet er der tre situationer.

  • Kunden sendes videre · betalingen sker på udbyderens egen side, og kunden sendes tilbage bagefter.
  • Udbyderens felter i webshoppen · betalingsfelterne vises i webshoppen, men leveres af udbyderen.
  • Webshoppen modtager selv kortoplysninger · oplysningerne passerer webshoppens egne systemer.

Jo flere kortoplysninger der passerer webshoppens egne systemer, jo større er webshoppens ansvar, og jo mere omfattende bliver kravene fra kortbranchen. Valget af løsning er ikke et emne for penetrationstesten, men det er en forudsætning for at afgrænse den.

Webshoppen kan også bruge flere betalingsformer på samme tid: kort, mobilbetaling, faktura eller afbetaling gennem en anden udbyder. Hver betalingsform kan være koblet på forskelligt og have sin egen udbyder med egne vilkår. Lav derfor en oversigt over betalingsformerne, og angiv for hver, hvem udbyderen er, hvordan den er koblet på, og om den skal med i testen. En betalingsform, der sjældent bruges, er ikke nødvendigvis mindre vigtig, hvis den kan føre til en ordre, der bliver sendt uden betaling.

Det, webshoppen selv har ansvar for

Uanset hvordan betalingen er koblet på, er der en række funktioner, som webshoppen selv driver. De kan alle være relevante at nævne i bestillingen.

  • Kurv og pris · om prisen, rabatter og fragt beregnes og fastholdes korrekt.
  • Ordrens status · om en ordre kun registreres som betalt, når udbyderen har bekræftet det.
  • Beskeder fra udbyderen · om webshoppen kun accepterer bekræftelser, der faktisk kommer fra udbyderen.
  • Kundens konto · gemte adresser, tidligere ordrer og eventuelle gemte betalingsoplysninger.
  • Administration · hvem der kan ændre priser, refundere eller se ordrer.

Spørgsmålene handler om forretningslogik, ikke kun om teknik. En ordre, der kan registreres som betalt uden betaling, er et tab for webshoppen, selv om ingen kortoplysninger er i fare. Hvis webshoppen bruger plugins eller moduler til betalingen, hører de til webshoppens del. → Plugins og tredjepartskode

Det, udbyderen har ansvar for

Betalingsudbyderen har ansvar for sin platform, sin egen side og de felter, den leverer. Webshoppen kan ikke lade testeren undersøge udbyderens servere, og den kan ikke bestille en test af udbyderens sikkerhed gennem sin egen opgave.

Webshoppen kan derimod spørge udbyderen, hvilken dokumentation der findes for udbyderens egen sikkerhed. Det er en leverandørkontrol og ikke en penetrationstest. Det samme gælder hostingfirmaet: at hostingfirmaet har sine egne kontroller, betyder ikke, at webshoppens funktioner er undersøgt. → Hostingfirmaet tester for os

Webshoppen kan også bede udbyderen om at bekræfte, hvilke dele af løsningen udbyderen står for, og hvilke webshoppen selv skal sørge for. En sådan bekræftelse gør afgrænsningen af testen lettere. Skriv grænsen ind i opgaven. Testeren skal vide, hvor webshoppens del slutter, og rapporten bør bruge samme grænse, så ingen tror, at udbyderens platform er vurderet.

PCI DSS og testen

PCI DSS er kortbranchens sikkerhedskrav. Krav 11.4 nævner penetrationstest direkte. Hvilke krav der gælder for den enkelte webshop, afhænger af, hvordan betalingen er koblet på, og af aftalen med betalingsudbyderen eller indløseren. Den vurdering bør laves af den, der er ansvarlig for kortbetalinger i virksomheden, sammen med udbyderen.

En penetrationstest kan indgå som dokumentation, når kravet gælder, men den skal passe til det miljø, kravet omfatter. Det er ikke nok, at tilbuddet nævner PCI DSS. Teksten her er ikke en vurdering af, hvilke krav der gælder for jer. Standarderne og deres forhold til testen er beskrevet i → Penetrationstest og standarder.

Testbetalinger og miljø

For at undersøge betalingsflowet skal testeren kunne gennemføre køb. Det kræver en plan. Betalingsudbydere kan tilbyde et testmiljø eller testtilstand, hvor betalinger kan gennemføres uden rigtige penge. Spørg udbyderen, hvad der findes, og om webshoppen kan kobles til det under testen.

Hvis testen sker i produktion, skal virksomheden aftale, hvordan testordrer markeres, annulleres og holdes ude af regnskab og lager. Ordrer, der sendes til lageret, kan ende med at blive pakket og sendt. Valget mellem produktion og testmiljø har betydning for, hvad resultatet kan sige. → Penetrationstest i produktion eller testmiljø

Det skal I lade være med

  • At bestille test af udbyderens platform. Den kræver udbyderens tilladelse og hører ikke til jeres opgave.
  • At holde betalingen helt ude af testen. Ordrestatus, pris og bekræftelser er webshoppens ansvar.
  • At lade PCI DSS-navnet erstatte afgrænsningen. Kravet skal kobles til det konkrete miljø.
  • At glemme lager og regnskab. Testordrer i produktion skal kunne genkendes og annulleres.
  • At gå ud fra, at hostingfirmaet har testet webshoppen. Deres kontroller dækker deres egen del.

Hvad kan og ikke kan konkluderes

En test kan vise, om webshoppens egen del af købet opførte sig som forventet i de situationer, der blev undersøgt. Den kan ikke sige noget om betalingsudbyderens platform eller om udbyderens håndtering af kortoplysninger.

Den kan heller ikke alene fastslå, at webshoppen opfylder PCI DSS. Det kræver en bredere vurdering. Et resultat uden fund i betalingsflowet gælder de funktioner og den kobling til udbyderen, der var med på testtidspunktet.

Tjekliste til betalingen i bestillingen

  • ☐ Er det afklaret, hvordan betalingen er koblet på webshoppen?
  • ☐ Er grænsen til betalingsudbyderen skrevet ind i opgaven?
  • ☐ Er kurv, ordrestatus, bekræftelser og administration nævnt?
  • ☐ Er plugins og moduler til betalingen med?
  • ☐ Har den PCI DSS-ansvarlige vurderet, hvilke krav der gælder?
  • ☐ Er testmiljø eller testtilstand hos udbyderen undersøgt?
  • ☐ Er håndtering af testordrer i lager og regnskab aftalt?

Kilder

  • PCI DSS krav 11: Microsofts sammenfatning af krav 11, hvor penetrationstest er beskrevet i 11.4.

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Artikler om penetrationstest

Læs også: Penetrationstest af webapplikationer · Integrationer mellem systemer

→ Kontakt · Tlf. 70 13 63 23 · Penetrationstest hos Nielco IT

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal I have testet noget?

Fortæl kort, hvad I vil have testet, og hvornår I skal bruge resultatet. Så vender jeg tilbage.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.