Předpisy PCI pro vývojáře aplikací: Krátká a bolestivá verze

Shoda s požadavky PCI (bezpečnostní pravidla kartového průmyslu pro kohokoli, kdo manipuluje s daty o kartách) je cenou za slova "přijímáme platební karty". Krátká verze: pokud se data z karet kdykoli dotknou kódu, který jste napsali, nebo serverů, které provozujete, zdědíte bezpečnostní standard s stovkami kontrol, roční atestaci (formální podepsané prohlášení, že splňujete standard) a následky řešené přes vašeho zpracovatele plateb. Bolestivá verze compliance s PCI pro vývojáře aplikací: většina z nich to zjistí až v momentě, kdy je pokladní proces již hotový.

Jedna poznámka před podrobnostmi. Čísla verzí, data a pravidla pro dotazníky uvedená níže jsou přesná k datu publikace; standard se vyvíjí, takže tyto detaily berte jako snímek k danému okamžiku.

Co je to vlastně shoda s PCI?

PCI DSS (Payment Card Industry Data Security Standard) je smluvní závazek, nikoli zákon. Kartové asociace jej vyžadují po bankách a zpracovatelích plateb a ti jej vyžadují po obchodnících a softwaru, který ti obchodníci používají. Současná verze je 4.0.1 a poslední vlna jejích nových požadavků se stala povinnou 31. března 2025¹. Standard pokrývá 12 skupin požadavků, od bezpečnosti sítě a šifrování až po řízení přístupu a protokolování, které se dále rozšiřují do stovek jednotlivých kontrolních bodů².

Žádný úřad vám zaklepat na dveře nepřijde. Následky přicházejí obchodní cestou: pokuty přenesené přes vaši zúčtovací banku (banku, která pro obchodníka zúčtovává platby kartou), vyšší poplatky za zpracování a v nejhorším případě ztráta možnosti přijímat karty vůbec. Po úniku dat následují stejnou cestu náklady na forenzní vyšetřování a opětovné vydání karet.

Proč věta „prostě přidejme platby“ dostane do rozsahu celou vaši aplikaci?

Rozsah (scope) je klíčem k celému problému. PCI DSS se vztahuje na každý systém, který ukládá, zpracovává nebo přenáší údaje o držiteli karty, a navíc na vše, co je k těmto systémům připojeno. Ověřování funguje jako žebříček a každý stupeň je výrazně náročnější než ten předchozí²:

• SAQ A (sebehodnotící dotazník A): platby jsou zcela outsourcovány certifikovanému poskytovateli a data z karet se nikdy nedotknou vašich systémů. Nejratší dotazník.

• SAQ A-EP: váš web se dat z karet nikdy nedotkne, ale řídí, jak se zákazníci dostanou k platebnímu formuláři. Na vaše webové servery se nyní vztahuje velká část plného standardu.

• SAQ D: data z karet procházejí čímkoli, co jste vytvořili, i když jen krátce a bez ukládání. Fakticky celý standard, každoročně dokládaný a atestovaný.

Ani nejnižší stupeň neznamená „nic“. V lednu 2025 PCI Security Standards Council odstranil požadavky na skripty na platební stránce z SAQ A, ale přidal podmínku způsobilosti: musíte potvrdit, že váš web není náchylný k útokům pomocí skriptů, které by mohly ovlivnit váš e-commerce systém¹. I u plně outsourcované varianty se od vás očekává, že budete bránit stránku, na které je hostován platební formulář někoho jiného.

Při překročení šesti milionů kartových transakcí ročně sebehodnocení zcela končí a začíná audit na místě prováděný kvalifikovaným hodnotitelem QSA (certifikovaným externím auditorem)².

Můžete se z plateb za přítomnosti karty vyprogramovat?

Ne. Osobní platby jsou místem, kde se žebříček mění ve zeď. Transakce za přítomnosti karty vyžadují certifikovaný hardware: fyzické čtečky, které prošly laboratorním programem PTS organizace PCI Council, provozující schválený firmware a zprovozněné prostřednictvím zpracovatele plateb. Proměna telefonu ve čtečku pouze pomocí softwaru podléhá samostatnému standardu Mobile Payments on COTS (MPoC) a ten certifikuje poskytovatele řešení, nikoli vaši aplikaci.

Toto je hranice, kterou generování kódu pomocí AI nemůže překročit. Model dokáže za odpoledne vytvořit přesvědčivou obrazovku pokladny; články Můžete vytvořit POS pomocí Lovable nebo Replitu? a Vibe coding prodejního místa popisují, kde se tyto výtvory zaseknou. Žádný vygenerovaný kód neposkytne certifikovanou čtečku, smlouvu o akceptaci karet ani potvrzení o shodě (attestation of compliance), bez ohledu na to, jak dlouho model kóduje bez dohledu. Shoda s předpisy je také opakovaným důvodem, proč jsou vibe-kódované platební aplikace odmítány v App Storu.

Jak vývojáři skutečně zmenšují rozsah PCI?

Nenutíte se k přísnějšímu dodržování; navrhnete architekturu tak, aby bylo méně věcí k plnění:

• Nikdy nedovolte, aby se PAN (hlavní číslo účtu, tedy samotné číslo karty) dotkl vašeho kódu. Používejte hostovaná platební pole od vašeho zpracovatele, aby data z karty putovala z prohlížeče zákazníka přímo ke zpracovateli.

• Ukládejte tokeny, ne karty. Tokenizace (výměna čísla karty za referenční řetězec, který je v případě krádeže nepoužitelný) zabrání tomu, aby uložené karty a refundace vtáhly vaši databázi do rozsahu PCI.

• Při osobním prodeji používejte certifikované čtečky od vašeho zpracovatele, aby data z karty proudila ze čtečky ke zpracovateli, aniž by procházela vaší aplikací.

• Udělejte platební stránku co nejjednodušší. Každý skript třetí strany na ní se stává nečím, co musíte vykazovat.

Pokud to uděláte správně, vaše aplikace diriguje prodej, aniž by kdy držela data z karet, a dotazník zůstane krátký. Pokud to uděláte špatně, jediná funkce pro usnadnění („prostě ukládejme celé tělo požadavku do logu“) vás nenápadně převede do kategorie SAQ D.

Jak bolestivá tedy je shoda s PCI pro vývojáře aplikací?

Bolestivá úměrně tomu, kolika dat z karet se váš kód dotýká – proto je nejlepším krokem nedotýkat se žádných. Standardu je jedno, zda vaši aplikaci napsal vývojářský tým nebo ji za odpoledne vygenerovala AI; rozsah je rozsah. Než vydáte cokoli, co přijímá karty, položte si jednu otázku: může číslo karty kdykoli projít kódem, který jsem napsal? Pokud ano, počítejte s rozpočtem na audit. Pokud ne, udržte to tak.

Tuto architekturu využívá i Final. Pokladní proces postavený na systému Final, ať už zadávaný v prostředí Build nebo vytvořený vaší vlastní AI přes MCP, zpracovává platby přes Final Pay: zpracovatel plateb a certifikovaný terminálový hardware se postarají o data karet, takže samotný proces číslo karty nikdy nevlastní. Článek Kde je k dispozici služba Final Pay pokrývá praktickou stránku a Připojení Tap to Pay k AI POS procesu ukazuje, jak vypadá akceptace karet, když už je bezpečnostní vrstva připravena pod tím.