Checkout-nøgler og kassenøgler
Cardflo anvender Checkout-nøgler og Kassenøgler for at tilbyde sikre og fleksible integrationsmuligheder for forhandlere. Checkout-nøgler administrerer igangsættelse af betalingssessioner og indsamling af kundedata, mens Kassenøgler faciliterer server-side transaktionsbehandling.
Denne adskillelse sikrer PCI-overholdelse og robust sikkerhed for alle betalingsflows.
- Kategori
- Udvikler
- Funktioner
- 10
- Tilgængelig på
- Alle abonnementer
Overblikket
Adskillelsen af legitimationsoplysninger i checkout-nøgler og kassenøgler repræsenterer en grundlæggende sikkerhedsarkitektur i moderne betalingsorkestrering. Checkout-nøgler er offentligt tilgængelige identifikatorer, der bruges i klient-side miljøer, såsom webbrowsere eller mobile applikationer, til at initialisere betalingskomponenter og indsamle følsomme kortholderdata.
Disse nøgler giver en forhandler mulighed for at gengive en checkout-grænseflade uden at eksponere følsomme backend-tilladelser. Omvendt er kassenøgler begrænsede, server-side legitimationsoplysninger designet til godkendt kommunikation mellem en forhandlerserver og betalingsgatewayen.
Ved at opdele disse roller sikrer systemet, at et kompromis med klient-side koden ikke giver en angriber mulighed for at udføre administrative handlinger, såsom at igangsætte refusioner eller indfange godkendte betalinger.
Denne arkitektoniske tilgang hjælper med at opretholde PCI DSS-overholdelse ved at minimere omfanget af systemer, der interagerer direkte med rå betalingslegitimationsoplysninger, samtidig med at det giver mulighed for en programmerbar, granulær kontrol over transaktionslivscyklusser.
Sådan fungerer det
Klient-side sessionsinitiering
Integrationen begynder med, at checkout-nøglen bruges i frontend-applikationen til at anmode om en sikker session. Denne nøgle identificerer forhandleridentiteten (MID) og autoriserer gengivelsen af sikre betalingselementer, hvilket sikrer, at kundens kortoplysninger tokeniseres, før de nogensinde når forhandlerens infrastruktur.
Sikker datatokenisering
Når kunden indtaster sine betalingsoplysninger, faciliterer checkout-nøglen en direkte forbindelse til vaulten. Følsomme felter som PAN og CVV konverteres til midlertidige tokens.
Denne proces sikrer, at forhandlermiljøet forbliver uden for det primære omfang af PCI DSS-krav.
Server-til-server godkendelse
Når et token er genereret, bruger forhandlerserveren sin kassenøgle til at anmode om en formel godkendelse fra indløseren. Denne private nøgle bekræfter, at anmodningen er legitim og giver gatewayen mulighed for at kortlægge det midlertidige token tilbage til de lagrede betalingsdata til behandling.
Transaktionslivscyklusstyring
Handlinger efter godkendelse, herunder indfangning, afregning og refusioner, håndteres udelukkende via kassenøglen. Da disse handlinger involverer flytning af midler, kræver de det højere niveau af godkendelse og begrænset adgang, som den server-side kassenøgle giver forhandleradministratoren.
Hvorfor det betyder noget
Risiko- og ansvarsbegrænsning
Opdeling af legitimationsoplysninger reducerer skadesomfanget af et potentielt sikkerhedsbrud. Hvis en checkout-nøgle opsnappes fra en hjemmesides kildekode, kan angriberen ikke bruge den til at hæve penge eller få adgang til historiske transaktionsposter.
Kassenøglen forbliver beskyttet på en sikker backend, hvilket sikrer, at kun autoriserede servermiljøer kan udføre finansielle bevægelser, hvilket er et kritisk forsvar mod almindelige injektionsangreb.
Forenklet PCI DSS-overholdelse
Ved at bruge checkout-nøgler til at håndtere kortholderdata via hostede felter eller komponenter kvalificerer forhandlere sig typisk til en reduceret overholdelsesbyrde, såsom SAQ A eller SAQ A-EP.
Kassenøglen sikrer, at følsomme data håndteres i et tokeniseret format på backend, hvilket fjerner behovet for, at forhandleren gemmer, behandler eller transmitterer rå kreditkortoplysninger på deres egne servere.
Anvendelser
E-handelswebapplikationer
Forhandlere bruger checkout-nøgler til at indlejre sikre betalingsformularer direkte på deres websteder, mens kassenøglen gemmes i deres backend-miljø for at afslutte indfangningen af midler, når ordren er bekræftet.
Native mobilapps
Mobiludviklere bruger checkout-nøgler i iOS- eller Android-apps til sikkert at indsamle betalingssignaturer, idet de stoler på server-side kassenøgler til at styre den komplekse logik for afregning i flere valutaer og tilbagevendende fakturering.
Abonnement og tilbagevendende fakturering
Efter at den oprindelige checkout-nøgle har indsamlet kortoplysningerne, bruges kassenøglen til at etablere et forhandler-initieret transaktions (MIT) framework, hvilket muliggør automatiske fornyelser uden yderligere kundeintervention.
I tal
Industristandarder antyder, at aflastning af dataindsamling til hostede komponenter via klient-side nøgler kan reducere antallet af gældende PCI-krav med over 90 procent.
Standardiserede nøglebaserede arkitekturer giver typisk udviklere mulighed for at implementere et grundlæggende sikkert checkout-flow inden for cirka to arbejdsdage med udviklingstid.
Professionelle betalingsgateways kræver, at 100 procent af server-side anmodninger godkendes via en privat nøgle for at sikre integriteten af transaktionslivscyklussen.
Relaterede termer
Talk to our team about a live rollout on your acquiring stack.
Hvad du får med Checkout-nøgler og kassenøgler
- Isoler klient-side aktiviteter fra følsomme administrative backend-funktioner for forbedret sikkerhed
- Minimer PCI DSS-eksponering ved at sikre, at rå kortdata omgår forhandlerens servere
- Autoriser frontend-betalingskomponenter ved hjælp af begrænsede, offentligt tilgængelige checkout-nøgleoplysninger
- Udfør sikre server-side indfangninger og refusioner med godkendte kassenøgleanmodninger
- Oprethold granulær adgangskontrol over specifikke API-slutpunkter og transaktionsoperationer
- Understøt en bred vifte af frontend-frameworks uden at risikere eksponering af backend-legitimationsoplysninger
- Reducer sandsynligheden for svigagtige pengeoverførsler via kompromitteret klient-side kode
- Faciliter sikker tokenisering af kortholderoplysninger ved det første indtastningspunkt
- Aktiver forhandler-initierede transaktioner for abonnementsmodeller ved hjælp af sikker backend-godkendelse
- Giv klare revisionsspor for både klient-side sessioner og server-side administrationshandlinger
A short scoping call, then a written plan for your MIDs.
Spørgsmål om Checkout-nøgler og kassenøgler
Hvad er den primære forskel mellem en checkout-nøgle og en API-hemmelig nøgle?
En checkout-nøgle er designet til brug i offentlige miljøer, hvor koden er synlig, f. eks.
en browser. Den har ekstremt begrænsede tilladelser, typisk kun at kunne oprette et betalingstoken.
En API-hemmelig nøgle, eller kassenøgle, bruges til server-side operationer og har magten til at flytte penge, udføre refusioner og få adgang til følsomme forhandlerdata. At holde disse nøgler adskilt sikrer, at selvom en offentlig nøgle kopieres, forbliver forhandlerkontoens kernefinansielle funktioner beskyttet bag server-side godkendelse.
Kan en checkout-nøgle bruges til at udføre en refusion eller annullere en transaktion?
Nej, checkout-nøgler er specifikt begrænset for at forhindre operationer, der involverer flytning af midler fra forhandlerkontoen. Refusioner, annulleringer og indfangninger kræver brug af en kassenøgle, som skal holdes hemmelig og kun bruges i et sikkert servermiljø.
Denne sikkerhedsforanstaltning er tilsigtet og forhindrer ondsindede aktører i at manipulere klient-side koden for at udløse uautoriserede finansielle tilbageførsler eller dataeksport fra betalingsgatewayen.
Hvorfor er dette to-nøglesystem nødvendigt for PCI DSS-overholdelse?
PCI DSS-overholdelse fokuserer på, hvordan kortholderdata håndteres. Ved at bruge en checkout-nøgle til at facilitere tokenisering af kortdata direkte fra kundens browser til betalingsbehandleren, rører forhandleren aldrig de rå data.
Kassenøglen giver derefter forhandleren mulighed for at arbejde med det token. Denne adskillelse er det, der gør det muligt for en forhandler at bruge forenklede overholdelsesspørgeskemaer, da deres systemer aldrig er i besiddelse af følsomme oplysninger som klartekst-PAN'er.
Hvordan skal kassenøgler opbevares inden for en forhandlers infrastruktur?
Kassenøgler skal behandles som yderst følsomme legitimationsoplysninger. De bør aldrig hardkodes i kildefiler eller gemmes i versionskontrolsystemer som Git.
I stedet bør de administreres ved hjælp af miljøvariabler eller en dedikeret hemmelig administrationstjeneste. Adgang til disse nøgler bør begrænses til de specifikke serverinstanser, der kræver dem for at kommunikere med betalingsbehandleren for transaktionsafslutning og rapportering.
Hvad sker der, hvis en checkout-nøgle lækkes eller kompromitteres?
Hvis en checkout-nøgle kompromitteres, er virkningen generelt lav sammenlignet med en lækage af en hemmelig nøgle. En angriber kunne potentielt bruge nøglen til at indsende junkdata eller forsøge at oprette tokens via forhandlerens MID, men de kan ikke få adgang til eksisterende kundedata eller midler.
Det er dog stadig standardpraksis at rotere den lækkede checkout-nøgle for at forhindre uautoriseret brug af forhandlerens frontend-aktiver og for at opretholde rene transaktionslogfiler.
Understøtter kassenøgler forskellige niveauer af tilladelse baseret på brugeren?
Mens kassenøglen i sig selv repræsenterer en serverlegitimationsoplysning på højt niveau, tillader industristandardgateways ofte oprettelse af flere nøgler med forskellige omfang. For eksempel kan en kassenøgle være begrænset til skrivebeskyttet adgang til rapportering, mens en anden kan have autoritet til at behandle indfangninger og refusioner.
Dette følger princippet om mindste privilegium, hvilket sikrer, at hver del af en forhandlers backend-system kun har de tilladelser, den har brug for for at fungere.
Relaterede funktioner.
Klar til fart?
Fortæl os om din virksomhed. Vi matcher dig med de rigtige ’acquiring’-partnere og den rigtige rute, typisk inden for en uge.