Zgodność z PCI dla twórców aplikacji: Krótka i bolesna wersja

Zgodność z PCI (zasady bezpieczeństwa branży kart płatniczych dla każdego, kto przetwarza dane kart) to cena za możliwość używania sformułowania „akceptujemy karty kredytowe”. W skrócie: jeśli dane kart kiedykolwiek dotkną napisanego przez Ciebie kodu lub prowadzonych przez Ciebie serwerów, przejmujesz standard bezpieczeństwa zawierający setki wymogów kontrolnych, coroczną atestację (formalną, podpisaną deklarację spełniania standardu) oraz konsekwencje przekazywane przez operatora płatności. Bolesna wersja zgodności z PCI dla twórców aplikacji wygląda tak: większość dowiaduje się o tym dopiero po zbudowaniu modułu kasy.

Jedna uwaga przed przejściem do szczegółów. Numery wersji, daty i zasady dotyczące kwestionariuszy podane poniżej są dokładne w momencie publikacji; standard się zmienia, więc traktuj te dane jako opis stanu na dany moment.

Czym właściwie jest zgodność z PCI?

PCI DSS (Payment Card Industry Data Security Standard) to zobowiązanie umowne, a nie prawo stanowe czy państwowe. Organizacje kartowe nakładają je na banki i operatorów płatności, a ci z kolei na sprzedawców oraz oprogramowanie, z którego korzystają. Aktualna wersja to 4.0.1, a ostatnia fala jej nowych wymogów stała się obowiązkowa 31 marca 2025 r.¹. Standard obejmuje 12 grup wymagań — od bezpieczeństwa sieci i szyfrowania po kontrolę dostępu i logowanie — które dzielą się na setki szczegółowych zasad².

Żaden urzędnik nie zapuka do Twoich drzwi. Konsekwencje mają charakter handlowy: kary finansowe przekazywane przez Twój bank agenta rozliczeniowego (bank rozliczający płatności kartą dla sprzedawcy), wyższe prowizje od transakcji, a w najgorszym przypadku utrata możliwości akceptowania kart. W przypadku wycieku danych koszty analizy śledczej i ponownego wydania kart podążają tą samą drogą.

Dlaczego sformułowanie „po prostu dodajmy płatności” włącza całą aplikację do zakresu PCI?

Zakres (scope) to kluczowa sprawa. Standard PCI DSS dotyczy każdego systemu, który przechowuje, przetwarza lub przesyła dane posiadaczy kart, a także wszystkiego, co jest z tymi systemami połączone. Walidacja przypomina drabinę, gdzie każdy kolejny szczebel jest znacznie trudniejszy od poprzedniego²:

• SAQ A (Kwestionariusz samooceny A): płatności są w pełni przekazane do zewnętrznego, zgodnego dostawcy, a dane kart nigdy nie trafiają do Twoich systemów. Najkrótsza wersja kwestionariusza.

• SAQ A-EP: Twoja strona nie ma kontaktu z danymi kart, ale kontroluje sposób przekierowania klienta do formularza płatności. Znaczna część pełnego standardu dotyczy teraz Twoich serwerów WWW.

• SAQ D: dane kart przechodzą przez cokolwiek, co zbudowałeś — choćby przez chwilę i bez zapisywania. W praktyce oznacza to konieczność spełnienia pełnego standardu, dokumentowanego i audytowanego co rok.

Najniższy szczebel również nie oznacza „braku jakichkolwiek wymagań”. W styczniu 2025 r. PCI Security Standards Council usunęła z SAQ A wymogi dotyczące skryptów na stronie płatności, ale dodała warunek kwalifikowalności: musisz potwierdzić, że Twoja strona nie jest podatna na ataki skryptowe, które mogłyby wpłynąć na system e-commerce¹. Nawet przy pełnym outsourcingu wymaga się od Ciebie ochrony strony, na której znajduje się formularz płatności dostawcy.

Po przekroczeniu sześciu milionów transakcji kartowych rocznie samoocena całkowicie się kończy i rozpoczyna się audyt na miejscu przeprowadzany przez QSA (certyfikowanego audytora zewnętrznego)².

Czy można ominąć wymogi płatności kartą w punkcie sprzedaży samym kodem?

Nie. Płatności osobiste to moment, w którym drabina staje się ścianą. Transakcje z fizycznym użyciem karty (card-present) wymagają certyfikowanego sprzętu: fizycznych czytników, które przeszły program laboratoryjny Council PTS lab program, działają na zatwierdzonym oprogramowaniu układowym (firmware) i są dostarczane przez operatora płatności. Zmiana telefonu w czytnik za pomocą samego oprogramowania podlega osobnemu standardowi, Mobile Payments on COTS (MPoC), który certyfikuje dostawcę rozwiązania, a nie Twój własny kod.

To bariera, której generowanie kodu przez AI nie przekroczy. Model może stworzyć przekonujący ekran kasy w jedno popołudnie; artykuły Czy można zbudować POS za pomocą narzędzi Lovable lub Replit? oraz Vibe coding systemu POS pokazują, gdzie takie projekty utykają. Żaden wygenerowany kod nie stworzy certyfikowanego czytnika, umowy z agentem rozliczeniowym ani poświadczenia zgodności, bez względu na to, jak długo model koduje bez nadzoru. Zgodność z przepisami to także częsty powód, dla którego tworzone metodą vibe codingu aplikacje płatnicze są odrzucane z App Store.

Jak deweloperzy mogą realnie zmniejszyć zakres PCI?

Nie chodzi o to, by jeszcze usilniej wdrażać zasady — należy zaprojektować architekturę tak, aby jak najmniej elementów podlegało kontroli:

• Nigdy nie pozwalaj, aby numer PAN (numer karty płatniczej) dotknął Twojego kodu. Używaj pól płatności hostowanych przez operatora, aby dane karty trafiały z przeglądarki klienta bezpośrednio do operatora.

• Przechowuj tokeny, a nie karty. Tokenizacja (zamiana numeru karty na ciąg znaków referencyjnych, bezużyteczny w przypadku kradzieży) sprawia, że zapisane karty i zwroty nie włączają Twojej bazy danych do zakresu PCI.

• W przypadku sprzedaży stacjonarnej używaj certyfikowanych czytników od operatora płatności, aby dane z karty przepływały z czytnika bezpośrednio do operatora z pominięciem Twojej aplikacji.

• Zachowaj prostotę strony płatności. Każdy skrypt zewnętrzny umieszczony na tej stronie staje się elementem rozliczanym w audycie.

Jeśli zrobisz to dobrze, Twoja aplikacja zarządza sprzedażą, ani przez chwilę nie posiadając danych karty, a kwestionariusz pozostaje krótki. Jeśli zrobisz to źle, jedna funkcja wprowadzona dla wygody („po prostu zapisujmy całą treść zapytania w logach”) po cichu zakwalifikuje Cię do SAQ D.

Jak bolesna jest więc zgodność z PCI dla twórców aplikacji?

Jest tak bolesna, jak bolesny jest kontakt Twojego kodu z danymi kart — dlatego najlepszym posunięciem jest całkowite uniknięcie tego kontaktu. Standardu nie obchodzi, czy aplikację napisał zespół programistów, czy wygenerowała ją sztuczna inteligencja w jedno popołudnie; zakres to zakres. Zanim wypuścisz cokolwiek, co akceptuje karty, zadaj sobie jedno pytanie: czy numer karty może kiedykolwiek przejść przez napisany przeze mnie kod? Jeśli tak, zaplanuj budżet na audyt. Jeśli nie, zadbaj o to, aby tak pozostało.

Właśnie taką architekturę stosuje również Final. Moduł kasy zbudowany na platformie Final — niezależnie od tego, czy został wygenerowany w narzędziu Build, czy stworzony przez Twoją własną sztuczną inteligencję przez MCP — realizuje płatności za pośrednictwem Final Pay: dostawca płatności oraz certyfikowany terminal obsługują dane karty, dzięki czemu sam proces sprzedażowy nigdy nie posiada numeru karty. Artykuł Gdzie usługa Final Pay jest dostępna opisuje kwestie praktyczne, a tekst Łączenie usługi Tap to Pay z procesem sprzedażowym AI POS pokazuje, jak wygląda akceptacja kart, gdy warstwa zgodności z przepisami znajduje się pod spodem.