Checkout-nøgler og kassenøgler
Checkout keys og kasse-nøgler giver robust PCI DSS-overholdelse ved sikkert at adskille front-end betalingssessioner fra back-end MID-afregning. De bruger asynkron nøglegenerering til at beskytte følsomme kortindehaverdata.
- Kategori
- Udvikler
- Funktioner
- 6
- Tilgængelig på
- Alle abonnementer
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.
Implementering af checkout- og kasserernøgler giver robust tokenisering og isolerer følsomme betalingsdata fra frontend-interaktioner. Dette arkitektoniske design forbedrer PCI DSS-compliance betydeligt og styrker den overordnede sikkerhed for dine betalingsstrømme.
Oversigt over Checkout-nøgler og kassenøgleroversigt
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 Checkout-nøgler og kassenøglervirker
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.
Hvorfor Checkout-nøgler og kassenøgler er vigtigt
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.
Regulativer for Checkout-nøgler og kassenøglermyndighedskrav
PCI DSS compliance and credential scope
The Payment Card Industry Data Security Standard mandates strict logical separation between public-facing data collection systems and internal financial processing infrastructure.
Utilising heavily restricted checkout authentication keys significantly limits the scope of client-side vulnerabilities, as this public string only permits the initial generation of encrypted tokens.
By processing actual financial captures through securely stored backend strings, engineering teams prevent their merchant servers from ever touching raw Primary Account Numbers.
The tokenised payload travels safely through the orchestration layer directly to acquirer partners, reducing the overall merchant compliance burden to a simplified self-assessment questionnaire.
Cryptographic standardisation and secure storage
Financial scheme rules explicitly require that any credential capable of authorising live money movement must be protected by robust cryptographic algorithms and rotated following strict enterprise security protocols.
Merchant systems must transmit these cashier identifiers over verified transport layer security connections to prevent man-in-the-middle interception during processing.
Enforcing regular credential rotation schedules directly reflects recognised information-security practice for access control and secret management. Maintaining distinct architectural environments for testing and production ensures that live cashier credentials remain totally isolated, mitigating the risk of accidental exposure during complex software deployment or debugging exercises.
Anvendelsestilfælde for Checkout-nøgler og kassenøgleruse cases
Initialisering af checkout på én side
En betalingsside på én side skal eksponere en offentlig betalingsnøgle for at initialisere klient-side SDK'en uden at afsløre den hemmelige kassenøgle, der bruges til at oprette eller bekræfte betalingssessioner. Cardflo adskiller browsersikre legitimationsoplysninger fra server-holdte hemmeligheder og understøtter afgrænset udskiftning, når en offentlig nøgle eksponeres.
Isolering af legitimationsoplysninger i indlejret indkøbskurv
En WooCommerce- eller Shopify-integration kan gengive Cardflo-betalingskomponenter via et tema, en udvidelse eller et butiksfacade-script, hvor checkout-autentificeringsnøgler er synlige for browseren. Cardflo leverer offentlige nøgler til klientinitialisering, mens hemmelige kasserernøgler forbliver i beskyttet serverkonfiguration, uden for skabeloner og kildekontrol.
Udrulning af rotation af kasserernøgle
En produktionskasserernøgle kan kræve planlagt rotation efter personaleændringer, eksponering af repository eller en intern kryptografisk politikfrist, uden at afbryde aktive checkout-sessioner. Cardflo understøtter kontrolleret nøgleudskiftning, hvilket giver ingeniørteams mulighed for at implementere den nye hemmelighed, validere betalingsoprettelse og trække den tidligere legitimationsoplysning tilbage efter overgangen.
Nøgleadskillelse for butiksfacader med flere brands
En organisation, der driver flere brandede butiksfacader, har brug for separate checkout-nøgler, så en eksponeret klientlegitimationsoplysning ikke kan genbruges på tværs af uafhængige domæner eller applikationer. Cardflo muliggør særskilt nøgleallokering og rotation pr. butiksfacade, mens finans- og sikkerhedsteams bevarer centralt overblik over, hvilke offentlige og kassererlegitimationsoplysninger der forbliver aktive.
Fakta og tal:Checkout-nøgler og kassenøgler 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.
Metode: disse tal er illustrative spænd baseret på offentliggjorte branchedata og observerede forhandlerkohorter, ikke garantier. Faktiske resultater afhænger af din risikoprofil, kortmix, geografi og indløsningsopsætning, og bekræftes kun i dine egne pris- og godkendelsesvilkår.
Relateredetermer
Tal med vores team om en live-udrulning på vores indløsningspartneres infrastruktur.
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
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.
Relaterede funktioner.
Relaterede vejledninger.
Se hvordan Cardflo sammenligner sig.
Klar til at forbedre din betalingsopsætning?
Fortæl os om din virksomhed. Vi matcher dig med de rigtige indløsningspartnere og den rigtige rute, typisk inden for en uge.