Kassenøkler og betjeningsnøkler
Kasse- og kasserernøkler sikrer robust PCI DSS-overholdelse ved trygt å skille betalingsøkter i front-end fra MID-oppgjør i back-end. De benytter asynkron nøkkelgenerering for å beskytte sensitive kortholderdata.
- Kategori
- Utvikler
- Funksjoner
- 6
- Tilgjengelig på
- Alle abonnementer
Cardflo bruker kassenøkler og betjeningsnøkler for å tilby sikre og fleksible integrasjonsalternativer for selgere. Kassenøklene administrerer igangsetting av betalingssesjoner og innsamling av kundedata, mens betjeningsnøklene forenkler server-side transaksjonsbehandling.
Dette skillet sikrer PCI-samsvar og robust sikkerhet for alle betalingsflyter.
Implementering av kasse- og kasserernøkler gir robust tokenisering, som isolerer sensitive betalingsdata fra front-end-interaksjoner. Denne arkitektoniske designen forbedrer PCI DSS-samsvar betydelig og styrker den generelle sikkerheten for betalingsstrømmene dine.
Oversikt over Kassenøkler og betjeningsnøkleroversikt
Skillet mellom legitimasjon i kassenøkler og betjeningsnøkler representerer en grunnleggende sikkerhetsarkitektur i moderne betalingsorkestrering. Kassenøkler er offentlig tilgjengelige identifikatorer som brukes i klient-side-miljøer, for eksempel nettlesere eller mobilapplikasjoner, for å initialisere betalingskomponenter og samle inn sensitive kortholderdata.
Disse nøklene lar en selger gjengi et kassegrensesnitt uten å avsløre sensitive backend-tillatelser. Motsatt er betjeningsnøkler begrensede, server-side legitimasjoner designet for autentisert kommunikasjon mellom en selgerserver og betalingsgatewayen.
Ved å dele disse rollene sikrer systemet at et kompromiss av klient-side-koden ikke gir en angriper muligheten til å utføre administrative handlinger, for eksempel å initiere refusjoner eller fange opp autoriserte betalinger.
Denne arkitektoniske tilnærmingen bidrar til å opprettholde PCI DSS-samsvar ved å minimere omfanget av systemer som samhandler direkte med rå betalingslegitimasjoner, samtidig som den tillater en programmerbar, detaljert kontroll over transaksjonslivssykluser.
Slik fungerer Kassenøkler og betjeningsnøklerfungerer
Klient-side sesjonsinitiering
Integrasjonen begynner med at kassenøkkelen brukes i frontend-applikasjonen for å be om en sikker sesjon. Denne nøkkelen identifiserer selgeridentiteten (MID) og autoriserer gjengivelsen av sikre betalingselementer, noe som sikrer at kundens kortdetaljer tokeniseres før de i det hele tatt når selgerens infrastruktur.
Sikker datatokenisering
Når kunden legger inn betalingsdetaljene sine, tilrettelegger kassenøkkelen for en direkte forbindelse til banken. Sensitive felt som PAN og CVV konverteres til midlertidige tokener. Denne prosessen sikrer at selgerens miljø forblir utenfor det primære omfanget av PCI DSS-kravene.
Server-til-server-autorisasjon
Når et token er generert, bruker selgerens server sin betjeningsnøkkel til å be om en formell autorisasjon fra innløseren. Denne private nøkkelen bekrefter at forespørselen er legitim og lar portalen kartlegge den midlertidige tokenen tilbake til de lagrede betalingsdataene for behandling.
Derfor er Kassenøkler og betjeningsnøkler viktig
Risiko- og ansvarsreduksjon
Å dele legitimasjon reduserer skadeomfanget ved et potensielt sikkerhetsbrudd. Hvis en kassenøkkel blir fanget opp fra en nettsteds kildekode, kan angriperen ikke bruke den til å trekke ut midler eller få tilgang til historiske transaksjonsposter. Betjeningsnøkkelen forblir beskyttet på en sikker backend, noe som sikrer at bare autoriserte servermiljøer kan utføre økonomiske bevegelser, noe som er et kritisk forsvar mot vanlige injeksjonsangrep.
Forenklet PCI DSS-samsvar
Ved å bruke kassenøkler til å håndtere kortholderdata via hostede felt eller komponenter, kvalifiserer selgere vanligvis for en redusert samsvarsbyrde, for eksempel SAQ A eller SAQ A-EP. Betjeningsnøkkelen sikrer at sensitive data håndteres i et tokenisert format på baksiden, noe som eliminerer behovet for at selgeren lagrer, behandler eller overfører rå kredittkortinformasjon på egne servere.
Regelverk for Kassenøkler og betjeningsnøkler
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.
Brukstilfeller for Kassenøkler og betjeningsnøklerbrukstilfeller
Initialisering av betalingsside med én side
En betalingsside med én side må eksponere en offentlig betalingsnøkkel for å initialisere klient-side SDK uten å avsløre den hemmelige kasserernøkkelen som brukes til å opprette eller bekrefte betalingsøkter. Cardflo skiller nettlesersikre legitimasjoner fra serverholdte hemmeligheter og støtter omfangsbegrenset erstatning når en offentlig nøkkel eksponeres.
Innebygd handlekurv, isolering av legitimasjon
En WooCommerce- eller Shopify-integrasjon kan gjengi Cardflo-betalingskomponenter gjennom et tema, en utvidelse eller et butikkfrontskript der autentiseringsnøkler for kassen er synlige for nettleseren. Cardflo tilbyr offentlige nøkler for klientinitialisering, mens hemmelige kasserernøkler forblir i beskyttet serverkonfigurasjon, utenfor maler og versjonskontroll.
Utførelse av kasserernøkkelrotasjon
En produksjonskasserernøkkel kan kreve planlagt rotasjon etter personellendringer, eksponering av depot eller en intern kryptografisk policyfrist, uten å avbryte aktive betalingsøkter. Cardflo støtter kontrollert nøkkelutskifting, slik at ingeniørteam kan distribuere den nye hemmeligheten, validere betalingsopprettelse og trekke tilbake den forrige legitimasjonen etter overgang.
Nøkkelseparasjon for butikkfront med flere merker
En organisasjon som driver flere merkede butikkfronter trenger separate betalingsnøkler slik at en eksponert klientlegitimasjon ikke kan gjenbrukes på tvers av urelaterte domener eller applikasjoner. Cardflo muliggjør distinkt nøkkelallokering og rotasjon per butikkfront, mens finans- og sikkerhetsteam beholder sentral oversikt over hvilke offentlige og kassererlegitimasjoner som forblir aktive.
Kassenøkler og betjeningsnøkler i tall
Bransjestandarder antyder at avlastning av datainnsamling til hostede komponenter via klient-side-nøkler kan redusere antall gjeldende PCI-krav med over 90 prosent.
Standardiserte nøkkelbaserte arkitekturer gjør det vanligvis mulig for utviklere å implementere en grunnleggende sikker kasseflyt innen omtrent to arbeidsdager med utviklingstid.
Profesjonelle betalingsgateway krever at 100 prosent av server-side-forespørslene autentiseres via en privat nøkkel for å sikre integriteten til transaksjonslivssyklusen.
Metodikk: Disse tallene er veiledende intervaller hentet fra publiserte bransjedata og observerte handelsgrupper, ikke garantier. Faktiske resultater avhenger av din risikoprofil, kortmiks, geografi og anskaffelsesoppsett, og bekreftes kun i dine egne priser og godkjenningsvilkår.
Relaterte begreper
Snakk med teamet vårt om en live utrulling på infrastrukturen til våre innløserpartnere.
Hva du får med Kassenøkler og betjeningsnøkler
- Isoler klient-sideaktiviteter fra sensitive administrative backend-funksjoner for forbedret sikkerhet
- Minimer PCI DSS-eksponering ved å sikre at rå kortdata omgår selgerservere
- Autoriser frontend-betalingskomponenter ved hjelp av begrensede, offentlige kassenøkkellegitimasjon
- Utfør sikre server-side innhenting og refusjoner med autentiserte betjeningsnøkkelhenvendelser
- Vedlikehold detaljert tilgangskontroll over spesifikke API-endepunkter og transaksjonsoperasjoner
- Støtt et bredt spekter av frontend-rammeverk uten å risikere eksponering av backend-legitimasjon
A short scoping call, then a written plan for your MIDs.
Spørsmål om Kassenøkler og betjeningsnøkler
Hva er den primære forskjellen mellom en kassenøkkel og en hemmelig API-nøkkel?
En kassenøkkel er designet for bruk i offentlige miljøer der koden er synlig, for eksempel en nettleser. Den har ekstremt begrensede tillatelser, vanligvis bare å kunne opprette et betalingstoken.
En hemmelig API-nøkkel, eller betjeningsnøkkel, brukes til server-side operasjoner og har makt til å flytte penger, utføre refusjoner og få tilgang til sensitive selgerdata.
Å holde disse nøklene adskilt sikrer at selv om en offentlig nøkkel blir kopiert, forblir selgerkontoens kjernefinansielle funksjoner beskyttet bak server-side autentisering.
Kan en kassenøkkel brukes til å utføre en refusjon eller annullere en transaksjon?
Nei, kassenøkler er spesifikt begrenset for å forhindre operasjoner som involverer bevegelse av midler fra selgerkontoen. Refusjoner, annulleringer og innhentinger krever bruk av en betjeningsnøkkel, som må holdes hemmelig og kun brukes i et sikkert servermiljø.
Denne sikkerhetsmekanismen er tilsiktet og forhindrer ondsinnede aktører fra å manipulere klient-sidekoden for å utløse uautoriserte finansielle tilbakeføringer eller dataeksport fra betalingsportalen.
Hvorfor er dette to-nøkkel-systemet nødvendig for PCI DSS-samsvar?
PCI DSS-samsvar handler om hvordan kortholderdata håndteres. Ved å bruke en kassenøkkel for å tilrettelegge for tokenisering av kortdata direkte fra kundens nettleser til betalingsbehandleren, berører selgeren aldri de rå dataene.
Betjeningsnøkkelen lar deretter selgeren jobbe med det tokenet. Dette skillet er det som gjør at en selger kan bruke forenklede samsvarsspørreskjemaer, da systemene deres aldri er i besittelse av sensitiv informasjon som umaskerte PAN-er.
Hvordan skal betjeningsnøkler lagres i en selgers infrastruktur?
Betjeningsnøkler må behandles som svært sensitiv legitimasjon. De skal aldri hardkodes i kildefiler eller lagres i versjonskontrollsystemer som Git.
I stedet bør de administreres ved hjelp av miljøvariabler eller en dedikert tjeneste for hemmelighetsstyring. Tilgang til disse nøklene skal begrenses til de spesifikke serverinstansene som krever dem for å kommunisere med betalingsbehandleren for transaksjonsfullføring og rapportering.
Relaterte funksjoner.
Relatert guider.
Se hvordan Cardflo sammenlignes.
Klar for å forbedre betalingsløsningen din?
Fortell oss om bedriften din. Vi finner de rette innløsningspartnerne og den rette ruten for deg, vanligvis innen en uke.