# PCI-efterlevnad Att diskutera Payment Card Industry:s (PCI) krav kan ofta börja med att ta en kopp kaffe. Om du någonsin deltagit i dessa samtal är resultaten ofta subjektiva, vilket leder till en allmän önskan att minska omfattningen av en miljö så mycket som möjligt. Med den lösning som Zoom och PCI Pal har implementerat blir kaffe valfritt. I detta inlägg kommer vi att utforska implementeringen, dess fördelar och hur din organisation kanske kan minska omfattningen för era affärsprocesser. ### Bakgrund om PCI PCI Security Standards Council har fastställt en uppsättning riktlinjer som reglerar hanteringen av kreditkortsinformation inom olika miljöer. Det finns riktlinjer [publicerade](https://www.pcisecuritystandards.org/standards/) av rådet som definierar kraven för en handlare (företaget som tar emot betalningar). Huvudfokus för standarderna är att skydda kortinnehavarens data (CHD) när den delas över flera system. Handlaren kommer att använda olika leverantörer och lösningsleverantörer för att hantera försäljningen. Alla dessa komponenter leder till en stödjande intyg om efterlevnad (AOC). AOC gör det möjligt för handlaren att använda olika leverantörers intyg för att bilda sin egen AOC. Beroende på lösningsdesign och transaktionsvolym kan det krävas ett ganska stort arbete för att åtgärda och upprätthålla en kortinnehavarmiljö (CHE).
Combining Vendor AOC's to support a Customer AOC and a PCI Compliant Design

Kombinera leverantörers AOC för att stödja en kunds AOC och en PCI-kompatibel design

När vi diskuterar implementeringen och hur den kan gynna en organisation är det viktigt att vara medveten om den övergripande flödet av kortinnehavarens data. Om kortinnehavarens data är närvarande kan efterlevnadsrevisioner krävas. Med den Zoom-lösning som lyfts fram nedan har en handlare möjlighet att minimera denna miljö och dess associerade kostnader. Vi kommer att titta på hur Zoom och PCI Pal samarbetar bakom kulisserna för att möjliggöra att kunder uppnår PCI-efterlevnad i Zoom Contact Center. ### Översikt av lösningen Lösningen utnyttjar [Zoom App Marketplace](https://marketplace.zoom.us/apps/MxNTkUxtQYSja9I-2YbMwQ?optimizely_user_id=efe7866fa2ae9ac46f7e6b8bb8e98da9) och [Zoom Partner Solutions](https://partner.zoom.us/solutions/pcipal/?optimizely_user_id=efe7866fa2ae9ac46f7e6b8bb8e98da9) för att möjliggöra PCI-kompatibla samtal inom en miljö. Det finns många olika sätt att närma sig efterlevnad, och med lösningen som beskrivs nedan finns möjligheter att minimera omfattningen av en miljö. För syftet med denna sektion kommer vi att fokusera på två primära enheter: agenten och konsumenten. Agenten är en individ som använder Zoom Contact Center och som kommer att ta emot ärenden via en röst-, video- eller meddelandekanal och som måste ta emot betalningar från konsumenten på ett säkert sätt. Konsumenten är den som initierar ärendet och som är betalkorthavaren. Även om textbaserade betalningskanaler är tillgängliga kommer vi i exemplet att fokusera på ärenden över röstkanalen. När konsumenten ringer in till Zoom Contact Center styrs denne genom menyerna och interaktionerna baserat på den administrativa ködesignen innan hen dirigeras till den utsedda agenten. När ärendet har startat finns två segment av medieflöde som tillåter agenten och konsumenten att kommunicera med varandra via en röstkanal: (1) media skickas från konsumenten till PSTN- och ZCC-infrastrukturen, och (2) media skickas mellan ZCC-infrastrukturen och agentens klient. Detta är också ett exempel på ett traditionellt samtal in i Zoom Contact Center.
Initial Phone Call setup

Initiering av telefonsamtal

När det ursprungliga samtalet är etablerat kan agenten kommunicera med konsumenten tills betalning ska inhämtas. Vid den tidpunkten startar agenten, inom PCI Pal Zoom-appen, (3) en session för att börja insamlingen av betalningen. Med en kombination av Zooms och PCI Pals API:er används SIP för att orkestrera ytterligare samtalsben mellan PSTN-leverantören, PCI Pal och Zoom. Dessa samtalsben möjliggör medieförhandling på ett sätt som befriar Zoom och agenten från att bearbeta, överföra och lagra kortinnehavardata. Det ursprungliga samtalsbenet (4) förblir anslutet mellan PSTN-leverantören och Zoom. Ett ytterligare samtalsben (5) etableras från Zoom till PCI Pal. När samtalsbenen (4) och (5) är framgångsrikt anslutna förhandlas media (6) direkt mellan PSTN-leverantören och PCI Pal. Medan media finns inom PCI Pal tas kortinnehavardata bort. PCI Pal skickar signaleringen med en associerad medieström tillbaka till Zoom (7). När den tas emot återansluter Zoom flödet till agenten (8). Detta medieflöde från PSTN till PCI Pal (6) innehåller kortinnehavardata och filtreras när det går in i PCI Pal-miljön. Mediat skickas tillbaka till Zoom (7) och i slutändan till agenten (8). Denna medieväg är endast aktiv under betalningsprocessens längd, vilket vanligtvis bara tar några minuter. Agenten har möjlighet att upprätthålla kommunikationen med konsumenten under denna tid. Eftersom media har fått kortinnehavardata borttaget innan det når Zoom kan tjänster som inspelning bibehållas under hela upplevelsen utan att öka efterlevnadsomfånget.
Payment in Process

Betalning under bearbetning

Efter att betalningen är slutförd tas de extra anslutningarna automatiskt bort och media återställs till den ursprungliga uppsättningen: från PSTN till Zoom (1) och från Zoom till den ursprungliga agenten (2). En agent kan etablera ytterligare betalningsflöden vid behov.
Original Flow is re-established

Ursprungligt flöde återställs

### Sammanfattning av lösningen En av de saker som kanske inte är omedelbart uppenbara är tillgängligheten av Zoom Contact Center-tjänster för samtalet. Att kortinnehavardata tas bort innan mediat når Zoom gör att interaktionen kan dra nytta av Zoom Contact Centers funktioner, från inspelning, transkriptioner och sentimentanalys till kvalitetsstyrning för övervakningsfunktioner. Den ovan beskrivna arkitekturen är unik för Zoom Contact Center och har flera designfördelar. Andra designer kräver att varje samtal som kan behöva betalningsinformation måste ansluta till betalningsprocessorn (t.ex. signalering). Med designen som ansluter till Zoom som den centrala dirigeringsmotorn kommer endast de samtal som behöver ansluta till en betalningsprocessor att etablera för de integrerade systemen och endast under den tid som behövs. Detta möjliggör flexibilitet i samtalsflöden så att de fungerar normalt om inte en betalning krävs, samt smidigare drift om en betalning oväntat behöver tas. Många andra flöden är ihållande anslutna genom den säkra betalningslösningen. Förutom latensöverväganden är den andra tillagda fördelen med den efterfrågebaserade lösningen relaterad till felområden. [Även om dessa system har mycket tillgängliga uppetider](https://uptime.zoom.us/?optimizely_user_id=efe7866fa2ae9ac46f7e6b8bb8e98da9), system som är kopplade i serie har sammanslagna SLA:er. Med lösningen implementerad i Zoom Contact Center har de olika systemen möjlighet att fortfarande koppla konsumenten till agenten om en integration skulle få problem. Slutligen tillåter Zooms plattformsbaserade designer att dessa integrationer kan utnyttjas för användare som inte är Zoom Contact Center-användare. Zoom Phone har liknande kapabiliteter som kan användas om användaren inte är kopplad till en Zoom Contact Center-kö. Utöver de unika fördelarna kan integrationen med PCI Pal och en granskning av agentens arbetsflöden möjliggöra för din organisation att begränsa sitt PCI-omfång. ### Avslutningsvis Att balansera efterlevnads- och tekniska behov för att implementera ett kontaktcenter som stödjer betalningar kräver korrekt navigering. Med Zoom Contact Centers integration med PCI Pal finns ytterligare flexibilitet för att hjälpa till att minska komplexiteten kring efterlevnad. Vi kommer att publicera fler artiklar som fokuserar på hur integrationen konfigureras ur administratörens perspektiv.