PCI DSS scope: kako smanjiti količinu kartičnih podataka koje sistem dodiruje

Najefikasniji način da web shop smanji PCI DSS scope jeste da kartični broj nikada ne prođe kroz njegov server, bazu, logove ili sopstveni checkout kod. Umesto toga, podaci kartice treba da se unesu na stranici koju hostuje PCI DSS validirani payment service provider, kroz kontrolisani iframe ili kroz drugi model u kome payment provider direktno prihvata kartične podatke.

To, međutim, ne znači da je web shop automatski „van PCI DSS-a“. PCI Security Standards Council obuhvata i sisteme koji mogu da utiču na bezbednost cardholder data environment-a, a kod pojedinih e-commerce modela merchant i dalje mora da zaštiti svoju stranicu, redirekciju, skripte, server i proces upravljanja dobavljačima. PCI SSC opis PCI DSS standarda zato treba posmatrati kao polaznu tačku za arhitektonsku odluku, a ne samo kao dokument koji se čita pred proveru usklađenosti.

U nastavku je praktičan okvir za odluku: koji payment flow smanjuje izloženost, gde tokenizacija zaista pomaže, zašto iframe nije isto što i ubacivanje kartičnog formulara u stranicu i koje kontrole ostaju obavezne čak i kada kartične podatke obrađuje eksterni provajder.

Šta zapravo znači smanjiti PCI DSS scope

PCI DSS scope je granica sistema, komponenti, procesa i ljudi koji moraju da budu obuhvaćeni procenom bezbednosti kartičnih podataka. U toj granici nisu samo aplikacije koje čuvaju puni PAN, odnosno broj kartice. U obzir mogu da uđu i sistemi koji kartične podatke procesiraju ili prenose, kao i komponente koje mogu da utiču na bezbednost okruženja u kome se ti podaci obrađuju.

Zato je korisno razlikovati tri cilja:

• eliminisati nepotrebno dodirivanje kartičnih podataka – na primer, da web shop nikada ne prima puni broj kartice;
• smanjiti broj sistema u scope-u – da CMS, CRM, analitika, log server i korisnička podrška ne dobijaju PAN;
• smanjiti posledice kompromitacije – da ukradeni podaci iz jedne aplikacije ne omogućavaju pristup cardholder data environment-u.

Ovo je razlika između „koristimo poznatog payment providera“ i dobro postavljene integracije. Provider može da obrađuje kartične podatke, ali konfiguracija web shopa i dalje određuje da li kartični formular potiče iz providerovog okruženja, da li vaš JavaScript može da ga menja, gde odlaze podaci iz browsera i koji sistemi imaju pristup tokenima.

Prvi izbor: gde se kartični podaci unose

Arhitektura payment flow-a najviše utiče na količinu podataka koju vaš sistem dodiruje. U praksi se najčešće biraju tri modela.

1. Redirekcija na hosted payment page

Kupac sa checkouta prelazi na payment stranicu koju hostuje payment provider. Kartični broj, datum isteka i sigurnosni kod unose se na toj stranici, a vaš sistem dobija rezultat transakcije kroz povratnu adresu i webhook.

Ovo je obično najjednostavniji model za smanjenje direktnog kontakta sa kartičnim podacima. Njegov trade-off je korisničko iskustvo: kupac napušta domen web shopa, a izgled i ponašanje payment stranice delimično zavise od provajdera. Ako je brend važniji od potpune kontrole checkouta, može biti prihvatljivo da se providerova stranica vizuelno prilagodi koliko platforma dozvoljava.

Važna granica je server koji generiše redirekciju. Ako merchantova stranica može da bude izmenjena tako da kupca pošalje na lažnu payment adresu, redirekcioni mehanizam i server koji ga kontroliše ostaju bezbednosno relevantni. PCI SSC navodi da merchant web server može ostati u scope-u i kada ispunjava kriterijume za SAQ A, jer assessor mora da proveri njegovu konfiguraciju i mehanizam redirekcije. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/faqs/is-a-merchant-website-still-in-scope-for-pci-dss-if-it-meets-all-the-criteria-for-saq-a/?utm_source=openai))

2. Hosted payment page kroz iframe

Iframe omogućava da payment providerov element bude prikazan unutar checkouta web shopa, dok se kartični podaci šalju direktno provideru. Za kupca iskustvo može izgledati kao deo vašeg sajta, ali je važno razumeti šta iframe jeste, a šta nije.

Iframe ne znači da je ceo checkout automatski izvan scope-a. Merchantova stranica i dalje učitava payment komponentu, a njene skripte, HTTP zaglavlja, third-party tagovi i administracija mogu da utiču na bezbednost payment procesa. PCI SSC pravi razliku između iframe-a u kome payment provider generiše element koji prihvata kartične podatke i modela u kome merchantov HTML ili JavaScript generiše formular, a podatke naknadno šalje provajderu. To nisu iste arhitekture ni isti rizici. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/faqs/1292/?utm_source=openai))

Providerova dokumentacija može dodatno precizirati model. Na primer, Adyen za Drop-in i Components opisuje iframe elemente kao komponente u kojima se podaci kartice obrađuju u izolovanom elementu, dok merchant nema ključeve za dešifrovanje kartičnih podataka. To može smanjiti scope, ali konačna procena zavisi od konkretne implementacije, konfiguracije i zahteva acquirera ili payment brenda. ([docs.adyen.com](https://docs.adyen.com/development-resources/pci-dss-compliance-guide?utm_source=openai))

3. Merchant-hosted ili direktni API formular

U ovom modelu web shop sam prikazuje card fields ili koristi JavaScript formu, a zatim podatke šalje payment gateway-u. To može dati najveću kontrolu nad dizajnom checkouta, validacijom i korisničkim tokom, ali povećava broj komponenti koje mogu da utiču na bezbednost kartičnih podataka.

Poseban rizik predstavlja e-skimming: napadač ne mora da menja server koji obrađuje transakciju ako može da ubaci skriptu u browser i kopira podatke u trenutku unosa. Zbog toga PCI DSS v4.x uvodi kontrole za skripte na payment stranicama i detekciju neovlašćenih promena payment page sadržaja i HTTP zaglavlja. PCI SSC smernice iz 2025. posebno naglašavaju autorizaciju skripti, proveru njihovog integriteta, inventar sa poslovnim opravdanjem i detekciju neovlašćenih izmena. ([blog.pcisecuritystandards.org](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming?utm_source=openai))

Ovaj pristup nije uvek pogrešan, ali zahteva zreliju bezbednosnu i operativnu disciplinu. Ako je cilj smanjenje scope-a, nije dovoljno samo prebaciti POST zahtev sa web shopa na gateway. Potrebno je proveriti ko generiše payment page, koje skripte se izvršavaju, da li se kartični podaci pojavljuju u browser logovima ili monitoring alatima i da li postoji način da kompromitovani CMS promeni payment flow.

Tokenizacija: šta rešava, a šta ne rešava

Tokenizacija zamenjuje PAN vrednošću koja predstavlja payment method ili sačuvanu karticu u sistemu payment providera. Web shop tada može da čuva token za buduće naplate, refundacije ili recurring payments, bez čuvanja punog broja kartice u sopstvenoj bazi.

To je korisno, ali token nije čarobna oznaka koja automatski izbacuje svaki sistem iz PCI DSS scope-a. Prvo pitanje je da li se token može iskoristiti za povratak do PAN-a. PCI SSC navodi da sistemi koji rade tokenizaciju, detokenizaciju, upravljanje ključevima ili imaju pristup takvom procesu ostaju u scope-u. Sistemi koji obrađuju samo tokene mogu biti van scope-a samo ako su adekvatno izolovani i token nema vrednost napadaču za dolazak do PAN-a ili uticaj na bezbednost CDE-a. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf?utm_source=openai))

Za web shop to praktično znači:

• u bazi čuvati providerov customer ID, payment method ID ili drugi dokumentovani token, a ne PAN;
• ne slati token u URL, e-mail, javni log ili frontend ako nije neophodno;
• ograničiti koji backend servisi mogu da pokrenu naplatu tokenom;
• odvojiti tokene za produkciju i test okruženje;
• proveriti šta se dešava pri refundaciji, storno transakciji i neuspešnoj automatskoj naplati;
• dokumentovati da li token može da se detokenizuje i ko kontroliše taj proces.

Kada web shop uvodi pretplate, tokenizacija je obično deo šire arhitekture. Nije dovoljno samo sačuvati payment method: potrebno je definisati status pretplate, webhook događaje, retry logiku, dozvole za naplatu i postupanje kada kartica istekne ili banka odbije transakciju. Za taj deo može pomoći vodič Recurring payments: arhitektura pretplata i automatske naplate, dok se sam PCI DSS scope mora proceniti na nivou svih uključenih sistema.

Kako izgleda data flow sa manjim scope-om

Jedan razuman model za standardni web shop može izgledati ovako:

1. Kupac u web shopu formira korpu. Vaš server dobija proizvode, cenu, adresu isporuke i podatke za porudžbinu, ali ne i PAN.
2. Backend kreira payment session kod provajdera koristeći server-side credentials.
3. Checkout koristi hosted payment page ili providerovu komponentu za unos kartice.
4. Payment provider obrađuje kartične podatke i vraća status transakcije.
5. Vaš sistem potvrđuje porudžbinu na osnovu verifikovanog webhook događaja, a ne samo na osnovu podatka koji je browser poslao na success URL.
6. U bazi se čuvaju status, transaction ID i eventualni token koji je potreban za dozvoljene buduće radnje.

Ovakav tok smanjuje broj sistema koji dodiruju PAN, ali ne uklanja potrebu za kontrolom pristupa, zaštitom servera, bezbednim deploymentom i proverom third-party integracija. Detaljan pregled same transakcije, od checkouta do potvrde, nalazi se u članku Kako teče online kartična transakcija: od checkouta do potvrde plaćanja.

Šta ostaje u scope-u i kada provider obrađuje kartice

Checkout stranica i njene skripte

Ako payment stranica pripada vašem domenu ili na njoj učitavate third-party skripte, morate znati šta se izvršava u browseru. Marketing tagovi, chat widgeti, A/B testiranje, session replay alati i custom analytics mogu da promene ponašanje checkout stranice ili da prikupljaju više podataka nego što je planirano.

Praktična kontrola je inventar skripti: naziv, izvor, svrha, vlasnik, trenutak učitavanja i način provere integriteta. Skripta koja nije potrebna na payment stranici ne treba da bude tamo samo zato što se nalazi na svim ostalim stranicama sajta.

ASV skeniranje i SAQ A

SAQ A nije isto što i „nemamo nikakvu PCI DSS odgovornost“. PCI SSC je u junu 2026. potvrdio da SAQ A za PCI DSS v4.x uključuje zahtev za spoljnim skeniranjem ranjivosti e-commerce web stranica od strane Approved Scanning Vendor-a, čak i kada su payment processing i unos kartice potpuno outsourcovani. To obuhvata i stranice koje redirektuju kupca na third-party payment page ili prikazuju providerov iframe. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/faqs/1604/?utm_source=openai))

Tačan SAQ zavisi od kriterijuma konkretnog modela. Ako svaki element payment stranice potiče direktno od PCI DSS validiranog service provider-a, to može voditi ka SAQ A kriterijumima. Ako merchantova stranica generiše deo payment stranice ili payment formulara, arhitektura može preći u drugačiji profil, kao što je SAQ A-EP. To ne treba zaključivati samo na osnovu toga što se koristi određeni SDK ili naziv proizvoda. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/faqs/if-a-merchant-s-e-commerce-implementation-meets-the-criteria-that-all-elements-of-payment-pages-originate-from-a-pci-dss-compliant-service-provider-is-the-merchant-eligible-to-complete-saq-a-or-saq-a-ep/?utm_source=openai))

Webhook, admin i korisnička podrška

Webhook endpoint ne prima PAN, ali može da menja status porudžbine i pokrene refundaciju ili isporuku. Zato mora da proverava autentičnost događaja, spreči ponovnu obradu istog događaja i ograniči dozvole. Admin panel koji omogućava refundaciju ili ponovno slanje payment zahteva takođe treba da ima jaku autentikaciju, audit trail i najmanje privilegije.

Korisnička podrška ne treba da traži da kupac pošalje broj kartice e-mailom ili kroz chat. Dovoljni su identifikator porudžbine, transaction ID, poslednje četiri cifre ako ih provider bezbedno prikazuje i status payment pokušaja. Maskirani podaci nisu isto što i puni PAN, ali i dalje treba proveriti gde se prikazuju, ko im pristupa i koliko dugo se čuvaju.

Trade-offi: manje podataka naspram više kontrole

Najbolja odluka nije nužno model sa najmanje klikova ili najviše kontrole. Bolji kriterijum je odnos između potrebnog korisničkog iskustva, broja komponenti u payment flow-u, sposobnosti tima da održava bezbednost i obaveza koje prihvata merchant.

Kontrolna lista pre puštanja web shopa

• Da li puni PAN može da se pojavi u server logu, application exception-u, analitici ili CRM-u?
• Da li kartični formular generiše provider ili vaš frontend?
• Da li se payment podaci šalju direktno provideru ili prvo prolaze kroz vaš server?
• Koje skripte se izvršavaju na checkout stranici i zašto su sve potrebne?
• Da li su success URL i webhook odvojeni izvori istine za status transakcije?
• Da li je dokumentovano koji servisi čuvaju tokene i šta tačno mogu da urade sa njima?
• Da li su produkcioni i test ključevi, webhook endpointi i baze razdvojeni?
• Da li je provereno koji SAQ, ASV skenovi i dodatne obaveze važe za konkretan model?
• Da li ugovor sa payment providerom i njegova potvrda o usklađenosti pokrivaju uslugu koju zaista koristite?
• Da li se promena payment providera, checkout skripti ili data flow-a tretira kao značajna promena koja zahteva novu procenu scope-a?

PCI SSC značajnom promenom smatra, između ostalog, promene u toku ili skladištenju account podataka, granicama CDE-a i third-party servisima koji podržavaju CDE. Zato procena scope-a nije jednokratni dokument: redizajn checkouta, novi analytics alat, migracija platforme ili uvođenje pretplata mogu promeniti rezultat. ([pcisecuritystandards.org](https://www.pcisecuritystandards.org/faqs/1317/?utm_source=openai))

Kako ovu odluku povezati sa integracijom platnih kartica

PCI DSS scope treba definisati pre nego što se izabere način integracije, a ne tek nakon što je checkout već napravljen. U tehničkom briefu treba jasno navesti: ko hostuje payment page, da li se koristi redirect ili iframe, koji podaci napuštaju browser, šta se čuva u bazi, kako se potvrđuje webhook i koje stranice ulaze u ASV skeniranje.

Ako vam je potreban širi pregled izbora payment flow-a, API-ja, webhooka, tokenizacije i ponašanja transakcije, sledeći korak je stranica integracija platnih kartica. Ako checkout zavisi od nove arhitekture web shopa, CMS-a ili custom modula, relevantna je i izrada sajta — ne kao odvojena prodajna tema, već zato što se scope često određuje upravo načinom na koji su sajt, checkout i payment provider povezani.

Za većinu web shopova najbezbedniji početni princip je jednostavan: kartični podaci treba da se unesu kod payment providera, a vaš sistem treba da dobije samo ono što mu je potrebno da potvrdi porudžbinu, izvrši dozvoljenu naplatu i vodi korisnički proces. Nakon toga treba proveriti preostale komponente, jer smanjen scope nije isto što i odsustvo odgovornosti.