Kassenøkler og betjeningsnøkler
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.
- Kategori
- Utvikler
- Funksjoner
- 10
- Tilgjengelig på
- Alle abonnementer
Oversikten
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 det
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.
Transaksjonslivssyklusstyring
Handlinger etter autorisasjon, inkludert innhenting, oppgjør og refusjoner, håndteres eksklusivt via betjeningsnøkkelen. Fordi disse handlingene involverer bevegelse av midler, krever de det høyere nivået av autentisering og begrenset tilgang som den server-side betjeningsnøkkelen gir selgeradministratoren.
Hvorfor det er 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.
Bruksområder
E-handel nettapplikasjoner
Selgere bruker kassenøkler til å bygge inn sikre betalingsskjemaer direkte på nettstedene sine, mens betjeningsnøkkelen lagres i backend-miljøet for å fullføre innhenting av midler når bestillingen er bekreftet.
Native mobilapper
Mobilutviklere bruker kassenøkler i iOS- eller Android-apper for å sikkert samle inn betalingssignaturer, og er avhengige av server-side betjeningsnøkler for å administrere den komplekse logikken for multi-valuta oppgjør og gjentakende fakturering.
Abonnement og gjentakende fakturering
Etter at den første kassenøkkelen samler inn kortdetaljene, brukes betjeningsnøkkelen til å etablere et MIT-rammeverk (Merchant-Initiated Transaction), noe som muliggjør automatisk fornyelse uten ytterligere kundeinngrep.
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.
Relaterte begreper
Talk to our team about a live rollout on your acquiring stack.
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
- Reduser sannsynligheten for svindelaktige pengeoverføringer via kompromittert klient-sidekode
- Tilrettelegg for sikker tokenisering av kortholderdetaljer ved første inntasting
- Aktiver selgerinitierte transaksjoner for abonnementsmodeller ved hjelp av sikker backend-autentisering
- Gi klare revisjonsspor for både klient-side-sesjoner og server-side administrasjonshandlinger
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.
Hva skjer hvis en kassenøkkel lekker eller kompromitteres?
Hvis en kassenøkkel blir kompromittert, er konsekvensene generelt lave sammenlignet med en lekkasje av en hemmelig nøkkel.
En angriper kunne potensielt bruke nøkkelen til å sende inn søppeldokumenter eller forsøke å opprette tokener gjennom selgerens MID, men de kan ikke få tilgang til eksisterende kundedata eller midler.
Imidlertid er det fortsatt standard praksis å rotere den lekkede kassenøkkelen for å forhindre uautorisert bruk av selgerens frontend-ressurser og for å opprettholde rene transaksjonslogger.
Støtter betjeningsnøkler forskjellige nivåer av tillatelse basert på brukeren?
Mens betjeningsnøkkelen i seg selv representerer en serverlegitimasjon på høyt nivå, tillater industri-standard betalingsgateway ofte opprettelse av flere nøkler med forskjellige omfang.
For eksempel kan en betjeningsnøkkel være begrenset til skrivebeskyttet tilgang for rapportering, mens en annen kan ha autoritet til å behandle innhentinger og refusjoner.
Dette følger prinsippet om minst privilegium, og sikrer at hver del av en selgers backend-system bare har de tillatelsene den trenger for å fungere.
Relaterte funksjoner.
Klar for fart?
Fortell oss om bedriften din. Vi finner de rette innløsningspartnerne og den rette ruten for deg, vanligvis innen en uke.