Ett betalningsvalv är ett säkert externt system som lagrar känsliga betalningsuppgifter å ett företags vägnar. Istället för dessa autentiseringsuppgifter får företaget en token: en ersättare som medför mycket mindre risk om den skulle läcka, men som fortfarande gör att företaget kan ta betalt av kunden igen eller försöka en misslyckad betalning igen när det behövs. Användningen av tokens växer snabbt. Under de kommande fem åren beräknas antalet nätverkstokeniserade transaktioner över hela världen få en genomsnittlig årlig tillväxttakt (CAGR) på 18,1 %.
Nedan går vi igenom hur ett valv faktiskt lagrar och skyddar kortuppgifter, vad det innebär för Payment Card Industry Data Security Standard (PCI DSS)-efterlevnad och konvertering, och hur det skiljer sig från den tokenisering som en betalleverantör redan gör på egen hand.
Viktiga lärdomar
Ett betalningsvalv ersätter sparade kortnummer med tokens så att ett intrång i företagets system inte exponerar något som en bedragare skulle kunna använda för att göra en transaktion framgångsrikt.
Ett valv förkortar vanligtvis ett företags PCI DSS-bedömning och stödjer abonnemang med sparade kort, nya betalningsförsök och förmågan att dirigera betalningar över flera personuppgiftsbiträden.
Processorutfärdade tokens är ofta låsta till den leverantören, medan ett dedikerat valv låter ett företag flytta sparade autentiseringsuppgifter vart de än behöver dem.
Vad är ett betalningsvalv?
Ett betalningsvalv är ett säkert externt system som lagrar känsliga betalningsuppgifter, som kortnummer och bankkontouppgifter å ett företags vägnar. Dessa autentiseringsuppgifter berör aldrig företagets egna servrar. När en kund anger sitt kort i kassan registrerar valvet numret, krypterar det och returnerar en token som företaget använder för alla efterföljande transaktioner.
Hur lagrar och skyddar ett betalningsvalv kortinformation?
Ett valvs huvuduppgift är att hålla råa kortnummer separerade från allt annat i ett företags system.
Så här fungerar det:
Kryptering vid registrering: Kortnumret krypteras när det matas in i valvet, innan det skrivs till disken, vilket innebär att det aldrig finns någon version av numret i klartext i företagets miljö.
Tokenisering: Valvet genererar en token – en rad tecken utan någon matematisk koppling till det riktiga kortnumret – och skickar tillbaka denna token till företaget så att det kan användas vid alla framtida referenser till transaktionen.
Tokenmappning: Bara valvet innehåller kartläggningen mellan token och kort. Företagets egen databas, verktyg för kundrelationshantering (CRM) och supportverktyg ser denna token, vilket innebär att ett dataintrång hos dem inte exponerar något som en bedragare skulle kunna använda för att slutföra en transaktion framgångsrikt.
Åtkomstkontroller och loggning: Valvet begränsar och loggar varje begäran om att detokenisera ett kort. Även en anställd med systemåtkomst kan inte dra ett rått nummer utan en specifik, granskad anledning.
Hantering av CVV: Nätverksregler tillåter inte att valv lagrar kortverifieringsvärdet (CVV) efter auktorisering. Det måste samlas in på nytt närhelst en transaktion kräver det.
Nätverkstokenisering: Vissa valv fungerar också med nätverksutfärdade tokens som uppdateras automatiskt när ett kort utfärdas på nytt på grund av förlust eller att kortet löper ut. Detta minskar mängden betalningar som misslyckas på grund av utgången eller ogiltig kortinformation.
Vilka är fördelarna med att använda ett betalningsvalv?
Betalningsvalv innebär minskad efterlevnadsbörda. Om ett företag aldrig lagrar, bearbetar eller överför råa kortuppgifter på sina egna system kvalificerar det sig vanligtvis för ett kortare PCI DSS-frågeformulär (Self-Assessment Questionnaire, SAQ) istället för den fullständiga version som krävs av företag som hanterar kortinnehavarens uppgifter direkt. Det innebär färre säkerhetskontroller att underhålla och mindre tid spenderad på att bevisa efterlevnad varje år.
Dessutom möjliggör ett valv följande metoder:
Abonnemang med sparade kort: Ett företag kan fakturera en kund varje månad utan att be hen ange ett kort igen eftersom en token, inte kortet i sig, används för alla transaktioner efter den första.
Försökslogik för misslyckade betalningar: När en transaktion misslyckas kan företaget försöka igen med samma sparade token, ofta efter att en nätverkstoken redan har uppdaterats bakom kulisserna med ett nytt utgångsdatum eller kortnummer.
Routing för flera leverantörer: Eftersom valvet inte ägs av ett enda personuppgiftsbiträde kan ett företag skicka samma sparade token till olika leverantörer för att jämföra auktoriseringsfrekvenser eller lägga till reservtäckning vid eventuella driftavbrott.
Snabbare kassa för återkommande kunder: När ett kort har sparats i valvet kan en återkommande kund genomföra ett köp utan att skriva något alls, vilket gör det enklare att konvertera i kassan.
Hur skiljer sig ett betalningsvalv från personuppgiftsbiträdets tokenisering?
De tokens som en betalleverantör utfärdar är vanligtvis låsta till leverantörens egna system, vilket innebär att en viss token vanligtvis bara fungerar för framtida transaktioner via samma leverantör. Om kortet dirigeras någon annanstans måste företaget samla in det igen eller be kunden ange det på nytt.
Ett särskilt betalningsvalv eliminerar den begränsningen. Företaget lagrar kortet en gång i en miljö som de själva kontrollerar och skickar sedan vidare den underliggande autentiseringsuppgiften, eller en nätverkstoken som härletts från den, till det personuppgiftsbiträde som passar för en viss transaktion. Kostnad, godkännandefrekvens, geografi och avbrott är alla faktorer i det beslutet, vilket inte är möjligt när en token bara finns inuti ett enda personuppgiftsbiträdes stängda system.
Ett företag som testar två personuppgiftsbiträden sida vid sida utan ett valv behöver två separata uppsättningar sparade kort, i två separata system, som inte känner till varandra. Med ett valv kan en enda sparad autentiseringsuppgift flyttas mellan system utan att fastna i någon leverantörs egna token-format.
Vilka är riskerna och begränsningarna med ett betalningsvalv?
Även om betalningsvalv minskar företagens börda för efterlevnad gäller fortfarande några verkliga begränsningar. Valvet i sig kan bli ett mål. Eftersom varje kunds kortinformation samlas på en plats, kan en framgångsrik attack mot valvet få enorma konsekvenser. Portabilitet är inte heller en självklarhet. Att flytta en sparad autentiseringsuppgift mellan personuppgiftsbiträden kräver att både valvet och det mottagande personuppgiftsbiträdet stödjer ett gemensamt format för överlämningen, vare sig det är en krypterad autentiseringsuppgift, en nätverkstoken eller ett specialbyggt API (Application Programming Interface) som byggts för överföringen.
En integration tar också teknisk tid. Ett företag som börjar använda ett valv måste bygga om sitt betalflöde, sin logik för abonnemangsfakturering och sina avstämningssystem kring tokens i stället för råa kortnummer. Och även om ett valv begränsar omfattningen av PCI DSS behöver företag fortfarande ha policyer som täcker säker överföring vid debitering, de anställdas tillgång till valvets administrativa verktyg samt säljarens egen efterlevnadsstatus.
Hur vet du om ett betalningsvalv är rätt för ditt företag?
Återkommande debiteringar är det tydligaste tecknet på att ett betalningsvalv är rätt för ditt företag. Ett företag som bara gör engångsbetalningar och aldrig behöver ta betalt av en kund igen kanske inte behöver den infrastruktur som ett valv innebär. Abonnemangsföretag, marknadsplatser som gör utbetalningar och företag som försöker göra misslyckade betalningar igen tenderar att få ut mest av ett valv.
Flexibilitet gällande personuppgiftsbiträden är en annan signal. Ett företag som nöjer sig med att köra varje transaktion genom en enda leverantör på obestämd tid behöver ingen portabilitet, men ett företag som vill jämföra auktoriseringsfrekvenser mellan personuppgiftsbiträden, lägga till en reservleverantör eller förhandla om villkor utan att behöva samla in alla kunders kortinformation på nytt skulle dra nytta av det.
Stripes Vault and Forward API bygger på just det här användningsfallet. Det låter ett företag spara betalningsmetoder och sedan använda API:et för att skicka dessa sparade autentiseringsuppgifter till en tredjepartsleverantör eller endpoint av deras eget val.
Så kan Stripe Payments hjälpa till
Stripe Payments erbjuder en enhetlig, global betalningslösning som hjälper alla företag – från växande startupföretag till globala företag – att ta emot betalningar online, fysiskt och runt om i världen.
Det här kan Stripe Payments hjälpa till med:
Optimera din kassa: Skapa en friktionsfri kundupplevelse och spara utvecklartid med färdiga betalningsgränssnitt, tillgång till över 125 betalningsmetoder och Link, en plånbok från Stripe.
Expandera till nya marknader snabbare: Nå kunder över hela världen och minska komplexiteten och kostnaderna för hantering av flera valutor med gränsöverskridande betalningsalternativ, tillgängliga i 195 länder och för över 135 valutor.
Göra betalningar både fysiskt och online till en enhetlig upplevelse: Bygg en enhetlig köpupplevelse i digitala och fysiska kanaler för att personanpassa interaktioner, belöna lojalitet och öka intäkterna.
Förbättrad betalningsprestanda: Öka intäkterna med en rad anpassningsbara, lättkonfigurerade betalningsverktyg, inklusive kodfritt skydd mot bedrägeri och avancerade funktioner som förbättrar auktoriseringstiderna.
Snabbare utveckling med en flexibel och pålitlig plattform för tillväxt: Bygg vidare på en plattform som är utformad för att skala upp med dig, med historisk upptid på 99,999 % och branschledande tillförlitlighet.
Läs mer om hur Stripe Payments kan driva dina online- och fysiska betalningar, eller börja i dag.
Innehållet i den här artikeln är endast avsett för allmän information och utbildningsändamål och ska inte tolkas som juridisk eller skatterelaterad rådgivning. Stripe garanterar inte att informationen i artikeln är korrekt, fullständig, adekvat eller aktuell. Du bör söka råd från en kompetent advokat eller revisor som är licensierad att praktisera i din jurisdiktion för råd om din specifika situation.