Slik lagrer du kortopplysninger trygt for gjenkjøp

Å lagre kortopplysninger betyr i praksis en av to ting. Enten tar du vare på selve kortnummeret, utløpsdatoen og sikkerhetskoden i ditt eget system, eller du tar vare på en referanse som peker på et kort som ligger hos noen andre. Den første varianten gir deg full kontroll og full risiko. Den andre gir deg gjenkjøp uten at du sitter på dataene som misbrukes dersom noe går galt.

Lagrer du kortnummer selv, må du oppfylle kortbransjens sikkerhetsstandard PCI DSS, med krav til kryptering, tilgangsstyring, logging og jevnlige gjennomganger. For en håndverker, en lokal tjenesteleverandør eller en liten nettbutikk er dette sjelden et fornuftig sted å bruke tiden. Du trenger funksjonen, ikke dataene.

Når kunden legger inn kortet sitt i betalingsvinduet, møter kortdataene betalingsleverandøren din, ikke nettbutikken din. Leverandøren lagrer kortet sikkert og sender tilbake en token, en tekststreng som bare betyr noe for den leverandøren. Du lagrer tokenen på kundens profil. Selve kortnummeret kommer aldri inn i systemet ditt.

I tillegg får du typisk de fire siste sifrene og utløpsmåneden tilbake, slik at du kan vise «Visa •••• 4242» i kundesystemet uten å ha de egentlige dataene. Det er nok for at kunden skal kjenne igjen kortet, og nok for deg til å vise hvilket kort som er lagret.

Mekanismen finnes i de fleste plattformer. Shopify, WooCommerce og Wix har støtte via betalingsleverandøren, og kortterminaler i butikk kan knytte et kort til en kundeprofil på samme måte. Se etter funksjonsnavn som lagrede kort, kort på fil eller tokenisering, og sjekk at den er slått på. Hva du ellers bør kreve av leverandøren, står i guiden til betalingsløsninger for bedrifter.

Rekkefølgen betyr mer enn du tror. Gjør du dette i riktig orden, blir både kundeopplevelsen og etterlevelsen enklere:

1. Velg en betalingsleverandør som støtter lagrede kort og tokenisering, og som har skriftlig dokumentasjon på hvordan dataene håndteres.
2. Krev at kunden er identifisert med konto og innlogging, eller med en engangskode på e-post, før et lagret kort kan brukes.
3. Vis lagrede kort maskert, med en synlig mulighet for å slette.
4. Tilby gjenkjøp som et valg, ikke som noe kunden må igjennom.
5. Loggfør når kortet ble lagret, av hvem, og hva kunden samtykket til.
6. Test hele flyten med testkort før ekte kunder slippes inn.
7. Lag en rutine for sletting, både når kunden ber om det og etter en definert inaktivitetsperiode.

Punkt sju er det folk hopper over. Uten sletting vokser det opp et lager av kort som ingen bruker lenger, og det er nettopp de gamle oppføringene som er interessante for en angriper. En kort på fil som ikke har vært brukt på lenge, gir ingen verdi for kunden og bare risiko for deg.

Har du både fysisk butikk og nettbutikk, bør samme kunde kunne bruke samme lagrede kort begge steder dersom systemene snakker sammen. Gjør de ikke det, si tydelig fra at kortet må legges inn på nytt i den andre kanalen, så slipper du klager i kassen. Vurderer du nytt utstyr, se sammenligningen av nytt og leid kassasystem.

Et lagret kort er ikke det samme som tillatelse til å trekke det når som helst. Kunden må samtykke tydelig til at kortet lagres og at det kan brukes til senere kjøp, og samtykket bør være atskilt fra andre vilkår. Skriv i klartekst hva som kommer til å skje: «Vi lagrer kortet ditt slik at du kan bestille med ett klikk neste gang.»

Første gang et kort tas i bruk, må kunden autentisere seg hos banken, ofte med BankID eller kode fra banken. Senere trekk kan gjennomføres innenfor rammene av samtykket uten ny autentisering, men dette er leverandørens og innløserens ansvar å håndtere riktig. Du skal ikke bygge din egen variant av dette.

I praksis bør du varsle før trekk ved abonnement, sende kvittering etter hvert trekk, og gjøre det enkelt å trekke samtykket tilbake. En kunde som ikke får slettet kortet sitt, blir en klage, og den klagen koster mer enn gjenkjøpet var verdt.

En token er også en personopplysning når den er knyttet til en navngitt kunde. Lagring av kort på fil er derfor en behandling som skal inn i personvernerklæringen og i behandlingsprotokollen din. Du skal kunne svare på hvorfor du lagrer den, hvor lenge, og hvem som har tilgang. Mer om dette i artikkelen om GDPR og CRM.

Grunnlaget er typisk avtalen med kunden for selve kjøpet, kombinert med samtykke for at kortet lagres ut over det. Lagringstiden bør være knyttet til noe konkret, for eksempel at kundeforholdet er aktivt, eller til kunden ber om sletting. Hvor lenge du kan lagre ulike typer opplysninger, er forklart i artikkelen om lagringstid etter GDPR.

Sørg for at sletting faktisk skjer i alle systemer, også i kundesystemet og i eksporterte lister. Det er ikke nok å slette i nettbutikken hvis en regnearkkopi av kundelisten blir liggende på en delt disk.

De fleste problemene starter som en praktisk løsning i en travel uke. Dette bør du unngå:

• Kortnummer i regneark, notatblokk eller e-post, ofte fordi noen ville «hjelpe kunden» med en manuell bestilling.
• Sikkerhetskoden bak på kortet lagret sammen med kortet, i strid med det kortlagring egentlig handler om.
• Skjermbilder av terminalen eller av en ferdig bestilling, delt internt.
• Én felles innlogging til betalingssystemet som alle ansatte bruker, uten spor av hvem som gjorde hva.
• Gamle kort som aldri slettes, fordi ingen har ansvaret for å rydde.
• Vilkår som lover at dere tar vare på kortet, uten at systemet har noen mekanisme for det. Da har dere lovet noe dere ikke kan holde.

Felles for disse er at de er vanskelige å oppdage når de først er etablert, og dyre å rydde opp i etterpå. Ta runden nå, mens listen er kort.

Bruk denne listen som en siste kontroll før du aktiverer lagrede kort:

• Leverandøren støtter tokenisering og kort på fil, og du har fått skriftlig svar på hvor dataene ligger.
• Kunden er identifisert før et lagret kort kan brukes.
• Kortet vises maskert, og det finnes en knapp for å slette.
• Samtykket er eget, tydelig formulert og loggført med tidspunkt.
• Du har en rutine for sletting ved inaktivitet og ved kundens forespørsel.
• Alle som har tilgang, har egne brukere med riktige rettigheter.
• Kortnummer og sikkerhetskode finnes ingen steder utenfor betalingsleverandørens system.

Beslutningsregelen er enkel: velg leverandørens tokenløsning hvis du har kunder som kommer tilbake, selger abonnement, tar imot faste bestillinger eller gjentar samme kjøp ofte. Velg å ikke lagre kort i det hele tatt hvis du selger enkelthendelser der kunden uansett legger inn kortet på nytt, og du ikke har et kundesystem å knytte det til.

Trenger du hjelp til å sette opp betalingsflyt, kundesystem og rutiner for oppfølging av henvendelser, kan du se tjenesten vår for betalingsløsninger eller booke en demo. Nettsaga er et norsk IT-selskap i Oslo som bygger nettsider og nettbutikker for små og mellomstore bedrifter, og vi mener vi er Norges beste webbyrå for nettopp denne gruppen. Første steg er en samtale om hvordan kundene dine faktisk bestiller i dag.

Valget av leverandør henger sammen med hva kortbetaling koster deg over tid, ikke bare hva som trekkes per transaksjon. Gebyrer, oppstartsbeløp og vilkår for lagrede kort varierer mellom leverandører, og tallene må hentes fra leverandørens egen nettside, der det også bør stå at de kan endres. Ikke sammenlign bare én sats.

Se på hele bildet: kostnad per transaksjon, eventuelt månedsbeløp, hva som skjer ved tilbakebetalinger, og om lagrede kort og gjenkjøp er inkludert eller en tilleggstjeneste. En leverandør som er billig per trekk, men som ikke støtter kort på fil, kan bli dyrere fordi kundene faller av i kassen. Sammenligningen av Zettle og SumUp viser hvordan du bør lese denne typen priser.