Betaling og abonnement i produktet

Et SaaS-produkt kan tage betaling for sig selv: kunden vælger et abonnement, indtaster kortoplysninger eller får en faktura og kan skifte plan undervejs. Det meste af selve betalingen sker hos en betalingsudbyder, og det er derfor ikke oplagt, hvad jeres egen pentest skal dække. Svaret hviler på, hvor kortoplysningerne bevæger sig hen. Det, der sker hos udbyderen, er udbyderens ansvar. Alt det, jeres produkt gør før og efter betalingen, er jeres.

Abonnementsdelen er ikke nødvendigvis det, kunderne spørger mest til. Men den indeholder kundernes fakturaer, betalingsoplysninger og den logik, der bestemmer, hvem der har adgang til hvad, og den bør ikke falde ud af omfanget.

Hvor kortoplysningerne bevæger sig hen

Der er grundlæggende tre måder at koble betalingen på, og de flytter grænsen for jeres ansvar:

Kunden sendes til udbyderens side · kortoplysningerne indtastes hos udbyderen, og jeres produkt ser dem aldrig.
Udbyderens felter vises i produktet · kunden indtaster oplysningerne i felter på jeres side, men felterne leveres og styres af udbyderen.
Produktet modtager selv kortoplysninger · oplysningerne passerer jeres egne systemer, og I står med et langt større ansvar.

En SaaS-leverandør kan vælge en af de to første. Hvis jeres produkt hører til den tredje gruppe, eller hvis I håndterer betaling på vegne af jeres kunder, hører spørgsmålet hjemme i en anden sammenhæng. → PCI DSS og testkravet

Det, der altid er jeres

Uanset hvordan betalingen er koblet på, er der en del af abonnementet, som ligger i jeres produkt:

Planer og rettigheder · at en kunde kun får de funktioner og den mængde, abonnementet giver adgang til.
Skift af plan · at kun de rigtige roller hos kunden kan ændre abonnementet eller opsige det.
Fakturaer og kvitteringer · at en kunde kun kan se sine egne, og at de ikke kan hentes af andre.
Gemte betalingsoplysninger · hvad produktet viser af et gemt kort, og hvem der kan erstatte det.
Beskeder fra udbyderen · at produktet kun ændrer et abonnement på grundlag af bekræftelser, der virkelig stammer fra betalingsudbyderen. → Webhooks og udgående integrationer
Jeres egen administration · hvem hos jer der kan give rabat, forlænge en prøveperiode eller ændre en kundes plan.

Fejl i den logik kan betyde, at en kunde får funktioner uden at betale, men også at en kunde kan se en anden kundes fakturaer. Det sidste er et spørgsmål om adskillelse, og det er det, kunderne vil spørge til. → Multi-tenant: test af adskillelsen

Det, der er udbyderens

Betalingsudbyderens egen platform er ikke jeres at teste. Den kræver udbyderens tilladelse, og det er sjældent relevant for jeres kunder, at jeres tester har kigget på den. Udbyderens sikkerhed dokumenteres af udbyderen selv, og I kan henvise til den, når en kunde spørger.

I sikkerhedsspørgeskemaer optræder betalingsudbyderen som en underleverandør. Skriv, hvem udbyderen er, hvordan betalingen er koblet på, og at kortoplysningerne ikke lagres hos jer, hvis det er tilfældet. → Underleverandører i skemaet

PCI DSS, når kunderne spørger

Nogle kunder spørger, om produktet overholder PCI DSS, fordi det modtager betaling. Spørgsmålet giver kun mening, når man ved, hvordan betalingen er koblet på. PCI DSS krav 11 beskriver bl.a. ekstern og intern penetrationstest mindst hver 12. måned og efter væsentlige ændringer af infrastruktur eller applikation. Kravene gælder det miljø, hvor kortdata behandles, og hvor stor en del af jeres produkt der hører til det miljø, afhænger af valget mellem de tre måder ovenfor.

Krav 11.6.1 handler desuden om at opdage uautoriserede ændringer af betalingssider, som de modtages i kundens browser. Hvis udbyderens betalingsfelter vises på jeres side, kan det have betydning for jer, også selv om kortoplysningerne aldrig når jeres servere. Lad en kvalificeret rådgiver vurdere, hvad standarden betyder for netop jeres opsætning; teksten her er ikke en vurdering af overholdelse.

Et tænkt eksempel

Et softwarehus sælger et bookingsystem til klinikker på månedsabonnement. Kortbetalingen sker i felter, som betalingsudbyderen leverer, og produktet gemmer kun en henvisning til kortet hos udbyderen. En kunde spørger i sit spørgeskema, om produktet overholder PCI DSS, og om betalingen er med i pentesten.

Et præcist svar har tre dele. Kortoplysningerne behandles af udbyderen, som dokumenterer sin egen del. Produktets abonnement, fakturaer og administration var med i den seneste pentest, afprøvet med to testkunder og udbyderens testtilstand. Spørgsmålet om, hvilke krav i standarden der gælder for den side, felterne vises på, er vurderet særskilt. Kunden får dermed et svar, der skelner mellem det, testen viste, og det, andre dokumenter skal vise.

Hvad I giver testeren

Abonnementsdelen kræver forberedelse, fordi testeren skal kunne gennemføre køb, skift og opsigelser uden at flytte rigtige penge:

Udbyderens testtilstand · betalingsudbydere kan have et testmiljø, hvor betalinger kan gennemføres uden rigtige kort.
Konti med forskellige roller · både en kundeadministrator, der må ændre abonnementet, og en bruger, der ikke må. → Roller og rettigheder i produktet
Flere testkunder · så adgangen til fakturaer kan afprøves på tværs.
En liste over planer · hvad hver plan giver adgang til, så testeren kan se, om grænserne holder.

Fortæl også testeren, hvilke handlinger der sker automatisk, når en betaling mislykkes, fx at adgangen begrænses efter en periode. Den slags regler er en del af produktets logik og kan have betydning for kunderne, hvis de ikke virker som tilsigtet.

Testes der i produktionen, skal I aftale, hvordan testkøb bliver genkendt og annulleret, så de ikke ender i bogholderiet som rigtige indtægter.

Det skal I lade være med

At holde abonnementet ude af testen, fordi betalingen ligger hos udbyderen · planer, fakturaer og rettigheder er jeres.
At teste udbyderens platform uden tilladelse · det er ikke jeres miljø.
At svare ja til PCI DSS uden at kende grænsen · svaret afhænger af, hvordan betalingen er koblet på.
At give testeren én konto med alle rettigheder · så kan grænsen mellem roller ikke afprøves.
At lade testkøb i produktionen stå uden markering · de forvirrer både regnskab og support.

Hvad kan og ikke kan konkluderes

En test af abonnementsdelen kan vise, om jeres produkt holder styr på planer, fakturaer og rettigheder med de roller og kunder, der var med. Den siger intet om betalingsudbyderens platform, og den er ikke i sig selv en vurdering af overholdelse af PCI DSS. Rapporten bør sige, hvordan betalingen er koblet på, så kunderne kan se, hvor grænsen gik.

Tjekliste til betaling og abonnement i testen

☐ Er det beskrevet, hvordan betalingen er koblet på produktet?
☐ Står planer, fakturaer og administration af abonnementer i omfanget?
☐ Har testeren adgang til udbyderens testtilstand?
☐ Er der konti med forskellige roller hos flere testkunder?
☐ Er det aftalt, hvordan testkøb genkendes og annulleres?
☐ Er betalingsudbyderen beskrevet som underleverandør i jeres svar til kunderne?

Kilder

PCI DSS krav 11, gengivet af Microsoft Learn: krav 11.4.2 og 11.4.3 om penetrationstest mindst hver 12. måned og efter væsentlige ændringer, og krav 11.6.1 om ændringer af betalingssider.

Senest gennemgået: oktober 2026.