Kupac je izabrao proizvod, uneo podatke kartice i kliknuo na dugme za pla\u0107anje. U nekoliko sekundi odlu\u010duje se mnogo vi\u0161e od jedne transakcije: da li \u0107e naplata pro\u0107i, da li \u0107e podaci ostati za\u0161ti\u0107eni i da li \u0107e se kupac vratiti. PCI DSS standard za onlajn prodavnice zato nije administrativna stavka koju treba \u201ezavr\u0161iti\u201d, ve\u0107 osnova poverenja u svaku karti\u010dnu naplatu.<\/p>\n
Za trgovca, rizik nije samo direktan finansijski gubitak u slu\u010daju zloupotrebe. Incident mo\u017ee doneti prekid naplate, tro\u0161kove istrage, zahteve banke, naru\u0161enu reputaciju i pad konverzije ba\u0161 u trenutku kada poslovanje treba da raste. Dobra vest je da se obim obaveza mo\u017ee zna\u010dajno smanjiti pravilnim izborom payment re\u0161enja i na\u010dinom integracije.<\/p>\n
PCI DSS je skup bezbednosnih zahteva koji su razvili najve\u0107i karti\u010dni sistemi radi za\u0161tite podataka o platnim karticama. Njegov cilj je jednostavan: podaci kartice ne smeju biti izlo\u017eeni, neovla\u0161\u0107eno kori\u0161\u0107eni ili nepotrebno zadr\u017eani u sistemima trgovca.<\/p>\n
Standard obuhvata na\u010din na koji se karti\u010dni podaci prenose, obra\u0111uju i \u010duvaju, ali i \u0161ire bezbednosne prakse. To uklju\u010duje kontrolu pristupa, redovno testiranje sistema, pra\u0107enje aktivnosti, upravljanje bezbednosnim propustima i jasne procedure u slu\u010daju incidenta.<\/p>\n
Va\u017ena razlika je izme\u0111u podataka koji se mogu videti na potvrdi o pla\u0107anju i takozvanih osetljivih autentikacionih podataka. Broj kartice, datum isteka i ime vlasnika zahtevaju strogu za\u0161titu. CVV broj se ne sme \u010duvati nakon autorizacije transakcije, bez obzira na to koliko bi trgovcu bilo prakti\u010dno da ga sa\u010duva za narednu kupovinu.<\/p>\n
Aktuelna verzija standarda, PCI DSS v4.0.1, stavlja dodatni fokus na kontinuiranu kontrolu rizika. Drugim re\u010dima, uskla\u0111enost nije dokument koji jednom popunite i odlo\u017eite. Ona zavisi od toga kako su va\u0161i sistemi postavljeni danas, ko im pristupa i \u0161ta se menja u va\u0161oj aplikaciji, infrastrukturi i procesu naplate.<\/p>\n
Odgovornost je podeljena, ali nije potpuno prenosiva. Banka prihvatilac, payment gateway, hosting partner i trgovac imaju razli\u010dite uloge. Payment provajder mo\u017ee preuzeti obradu karti\u010dnih podataka i obezbediti sertifikovanu infrastrukturu, dok trgovac i dalje odgovara za sopstveni sajt, korisni\u010dke naloge, zaposlene, integraciju i procedure.<\/p>\n
Zato PCI DSS Level 1 sertifikat payment gateway provajdera jeste sna\u017ean signal da je kriti\u010dna platna infrastruktura proverena prema najvi\u0161em nivou zahteva. Ipak, on sam po sebi ne zna\u010di da je cela onlajn prodavnica automatski uskla\u0111ena. Ako va\u0161a stranica za pla\u0107anje ima bezbednosni propust, ako neko neovla\u0161\u0107eno menja skripte ili ako zaposleni dele pristupne naloge, rizik ostaje na strani trgovca.<\/p>\n
Oblik potvrde uskla\u0111enosti naj\u010de\u0161\u0107e zavisi od broja transakcija i zahteva banke prihvatioca. Manji trgovci \u010desto popunjavaju odgovaraju\u0107i upitnik za samoprocenu, poznat kao SAQ, dok trgovci sa ve\u0107im obimom ili slo\u017eenijim okru\u017eenjem mogu imati obavezu detaljnije provere. Banka je ta koja odre\u0111uje konkretan proces validacije, rokove i potrebnu dokumentaciju.<\/p>\n
Najva\u017enija odluka nije samo kog provajdera birate, ve\u0107 da li karti\u010dni podaci ikada prolaze kroz va\u0161e sisteme. \u0160to je va\u0161 kontakt sa tim podacima manji, to je manji i PCI DSS obuhvat koji morate da kontroli\u0161ete.<\/p>\n
Kod integracije u kojoj kupac unosi karti\u010dne podatke direktno u platnu formu sertifikovanog provajdera, trgovac ne prima niti skladi\u0161ti kompletne podatke kartice. To u praksi smanjuje tehni\u010dki obim koji treba za\u0161tititi. Pla\u0107anje mo\u017ee ostati na sajtu trgovca, Without Redirection<\/a> na drugi domen, \u0161to je va\u017eno i za ose\u0107aj kontinuiteta kupovine i za manji broj napu\u0161tenih korpi.<\/p>\n Druga opcija je direktno prikupljanje karti\u010dnih podataka na serverima trgovca. Ona mo\u017ee pru\u017eiti ve\u0107u kontrolu nad korisni\u010dkim iskustvom, ali nosi daleko ve\u0107i bezbednosni, operativni i revizorski teret. Za ve\u0107inu trgovaca to nije opravdano ako postoji model integracije koji \u010duva korisni\u010dko iskustvo, a karti\u010dne podatke zadr\u017eava u PCI DSS okru\u017eenju provajdera.<\/p>\n Tokenizacija dodatno smanjuje izlo\u017eenost. Nakon prve uspe\u0161ne naplate, sistem mo\u017ee koristiti token – jedinstvenu zamenu za broj kartice – za naredne transakcije, recurring naplatu ili pla\u0107anje jednim klikom. Token nije isto \u0161to i karti\u010dni broj i nema upotrebnu vrednost van definisanog platnog sistema. Ipak, njime i dalje treba upravljati odgovorno, uz jasno definisane dozvole i kontrole pristupa.<\/p>\n Uskla\u0111enost se \u010desto pogre\u0161no svodi na tehni\u010dku integraciju. Ona po\u010dinje integracijom, ali se odr\u017eava svakog dana. Prodavnica koja koristi bezbedan gateway, a ne a\u017eurira svoj CMS, dodatke i serverski softver, ostavlja otvoren prostor za napad na stranici za pla\u0107anje.<\/p>\n Posebnu pa\u017enju zahtevaju skripte koje se u\u010ditavaju na checkout stranici. Analiti\u010dki alati, alati za chat, pikseli za ogla\u0161avanje i dodaci tre\u0107ih strana mogu biti korisni za marketing i podr\u0161ku, ali svaka nova skripta uvodi i novi rizik. Ako kompromitovana skripta presretne unos karti\u010dkih podataka u pregleda\u010du, posledice mogu biti ozbiljne \u010dak i kada payment gateway bezbedno obra\u0111uje transakciju.<\/p>\n Prakti\u010dno pravilo glasi: na stranici za pla\u0107anje treba da bude samo ono \u0161to je poslovno i tehni\u010dki opravdano. Svaka izmena treba da ima vlasnika, proceduru odobravanja i mogu\u0107nost provere. To nije usporavanje tima, ve\u0107 kontrola kriti\u010dne ta\u010dke prihoda.<\/p>\n Kontrola pristupa je jednako va\u017ena. Administratorski pristup prodavnici, hosting panelu, sistemu za upravljanje kodom i dashboardu za pla\u0107anja ne treba da bude zajedni\u010dki niti trajan za sve \u010dlanove tima. Vi\u0161efaktorska autentikacija, individualni nalozi i redovan pregled ovla\u0161\u0107enja spre\u010davaju da stari, nepotrebni ili kompromitovani pristupi postanu problem.<\/p>\n Za ve\u0107inu onlajn prodavnica, slede\u0107e mere daju najbolji odnos ulo\u017eenog vremena i smanjenja rizika:<\/p>\n Ponekad se bezbednosne kontrole posmatraju kao prepreka brzoj kupovini. Lo\u0161e izvedene kontrole to zaista mogu biti. Previ\u0161e dodatnih koraka, nejasne poruke o gre\u0161ci i preusmeravanja koja kupac nije o\u010dekivao mogu pove\u0107ati napu\u0161tanje korpe.<\/p>\nPCI DSS standard za onlajn prodavnice u svakodnevnom radu<\/h2>\n
Mere koje imaju neposredan efekat<\/h3>\n
\n
Bezbednost i konverzija nisu suprotstavljeni ciljevi<\/h2>\n