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

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/cs/blog/predpisy-pci-pro-vyvojare-aplikaci-kratka-a-bolestiva-verze

Pokud se data o platebních kartách kdykoli dotknou kódu, který jste napsali, přebíráte plnou váhu standardu PCI DSS. Zde je žebříček od SAQ A po SAQ D, proč platby za přítomnosti karty vyžadují certifikovaný hardware a jak aplikaci navrhnout, aby nic z toho nepadlo na vás.

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[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). 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ů[²](https://secureframe.com/blog/pci-saq).

Žá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í[²](https://secureframe.com/blog/pci-saq):

- **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ý.

![Stoh dokumentů o shodě s kreditní kartou nahoře, představující sebehodnotící dotazníky PCI DSS](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

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[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). 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)[²](https://secureframe.com/blog/pci-saq).

## 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](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/) 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)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/) a ten certifikuje poskytovatele řešení, nikoli vaši aplikaci.

![Neoznačený certifikovaný platební terminál na pultu obchodu, hardwarová vrstva vyžadovaná PCI pro platby za přítomnosti karty](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

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?](/blog/build-a-pos-with-lovable-or-replit) a [Vibe coding prodejního místa](/blog/vibe-coding-a-point-of-sale) 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](/blog/claude-opus-5-pos-more-than-code). Shoda s předpisy je také opakovaným důvodem, proč jsou [vibe-kódované platební aplikace odmítány v App Storu](/blog/why-vibe-coded-payment-apps-get-rejected).

## 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.

![Kreditní karta uzavřená ve skleněné vitríně, symbolizující udržení dat o kartách mimo rozsah PCI](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

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](https://finalpos.com/help/where-final-pay-is-available) pokrývá praktickou stránku a [Připojení Tap to Pay k AI POS procesu](/blog/connecting-tap-to-pay-to-an-ai-pos-flow) ukazuje, jak vypadá akceptace karet, když už je bezpečnostní vrstva připravena pod tím.

## FAQ

**Q: Je shoda s PCI právním požadavkem?**
A: Ne. PCI DSS je smluvní závazek vyžadovaný kartovými asociacemi prostřednictvím bank a zpracovatelů plateb. Důsledky jsou obchodního charakteru: pokuty přenesené přes vaši zúčtovací banku, vyšší poplatky za zpracování nebo ztráta možnosti přijímat karty.

**Q: Odstraňuje kompletní outsourcing plateb povinnosti PCI?**
A: Ne. Obchodníci s plně outsourcovanými platbami mohou ověření provést pomocí SAQ A (nejkratšího dotazníku), ale od revize z ledna 2025 musí také potvrdit, že jejich web není náchylný k útokům pomocí skriptů, které by mohly ovlivnit e-commerce systém.

**Q: Jaký je rozdíl mezi SAQ A a SAQ D?**
A: SAQ A se používá v případě, kdy všechna data z karet zpracovává certifikovaná třetí strana, a pokrývá malou část standardu. SAQ D se použije, pokud se data z karet dotknou vašich vlastních systémů, a pokrývá prakticky celý standard s roční atestací.

**Q: Může být aplikace vygenerovaná AI v souladu s PCI?**
A: Kód může sledovat bezpečné vzory, ale shoda s předpisy se váže na firmu a její infrastrukturu: certifikované čtečky karet, smlouvu se zpracovatelem a roční atestaci. Žádný vygenerovaný kód tyto součásti nedodá.

**Q: Jaká verze PCI DSS je aktuální?**
A: PCI DSS 4.0.1, k datu publikace tohoto článku. Její poslední budoucí požadavky se staly povinnými 31. března 2025. Aktuální stav si ověřte na stránkách PCI Security Standards Council.