Formularz jest na Twojej stronie. Dane karty – nie.

Klient wpisuje numer karty na stronie sklepu. Pola mają krój pisma tego sklepu, jego kolory i zaokrąglenia. A właściciel sklepu nie jest w stanie odczytać ani jednej cyfry – choć to jego strona i jego kod.

Brzmi jak sztuczka, i trochę nią jest. Dzięki niej mała firma może przyjmować karty bez budowania zabezpieczeń na poziomie banku. Żeby ją docenić, trzeba poznać cztery litery, przed którymi ucieka cała branża: PCI DSS.

Sztuczkę da się zobaczyć samemu. Wejdź do sklepu, w którym formularz karty jest osadzony bezpośrednio na stronie, np. przez Stripe. Kliknij pole numeru karty prawym przyciskiem i wybierz „Zbadaj”. Zamiast zwykłego <input> w kodzie sklepu znajdziesz <iframe>, czyli okno na inną stronę, z innej domeny.

To pole tylko wygląda jak część sklepu. Tak naprawdę jest cudze.

Czym jest PCI DSS

PCI DSS to globalny standard bezpieczeństwa dla każdego, kto przechowuje, przetwarza lub przesyła dane kart płatniczych. Rozwija go PCI Security Standards Council, organizacja założona przez największe marki kartowe. Standard nie jest ustawą, ale sklep trafia pod niego przez umowę z operatorem płatności.

Kluczowe jest tu słowo „przesyła”. Jeśli numer karty choćby przeleci przez Twój serwer, w drodze do bramki płatniczej, wchodzisz w świat wymagań, których mała firma zwykle nie chce brać na siebie. Stripe pisze o ponad 300 kontrolach bezpieczeństwa, a do tego specjalistyczne oprogramowanie, sprzęt i zewnętrznych audytorów.

Stąd najlepsza rada w całej branży jest przewrotna: najprościej spełnić PCI DSS, nigdy nie widząc danych karty. Czego nie dotykasz, tego nie musisz tak drogo chronić.

Skalę obowiązków wyznacza między innymi ankieta samooceny, czyli SAQ (Self-Assessment Questionnaire). Najkrótsza jest SAQ A, przeznaczona dla sprzedawców, którzy całą obsługę danych karty oddają certyfikowanemu dostawcy. Właśnie o nią toczy się gra.

Jak działa ta sztuczka

Cała magia stoi na starej regule przeglądarek, czyli same-origin policy. Dokumenty z różnych źródeł mają do siebie tylko bardzo ograniczony dostęp. Pilnuje tego przeglądarka, a nie uczciwość programisty.

Możesz to sprawdzić jedną linijką w konsoli strony z formularzem dostawcy:

1document.querySelector('iframe').contentDocument // null
Kopiuj

Wynik null oznacza, że Twój kod nie dostaje dokumentu ramki. Dla Twojej strony środek pola jest czarną skrzynką, mimo że leży na samym środku koszyka.

Sama płatność przebiega tak:

1. Strona ładuje skrypt dostawcy, a ten wstawia ramkę z polami karty. Kolory i fonty przekazujesz jej w konfiguracji, stąd wrażenie, że to Twój formularz.
2. Klient wpisuje numer w ramce, więc dane trafiają do dokumentu dostawcy, a nie sklepu.
3. Po kliknięciu „Zapłać” Twoja strona wysyła do ramki krótki komunikat przez postMessage, jedyny oficjalny kanał między takimi dokumentami.
4. Ramka przekazuje numer dostawcy szyfrowanym połączeniem i otrzymuje token.
5. Twój serwer używa tokenu i swojego klucza tajnego, żeby sfinalizować płatność.

Token to identyfikator, a nie zaszyfrowana karta, więc nie da się z niego odzyskać numeru po stronie sklepu. Do zamówienia możesz zapisać to, co odsyła dostawca, np. typ karty, cztery ostatnie cyfry i datę ważności. To wystarczy, żeby pokazać klientowi „Visa •••• 4242”.

W goodads mówimy, że dobre systemy dobrze ze sobą rozmawiają. Tutaj najważniejsze w tej rozmowie jest to, czego Twoja strona nigdy nie usłyszy.

Gdzie kończy się magia

Iframe chroni dane przed odczytaniem, ale nie chroni klienta przed podmianą formularza. Złośliwy skrypt na Twojej stronie nie zajrzy do ramki, ale może ją przykryć fałszywym polem albo zastąpić własnym. Klient nie zobaczy różnicy.

Ataki na skrypty płatności to nie teoria. Latem 2018 r. napastnik dodał 22 linijki JavaScriptu do strony British Airways, a dane płatnicze zaczęły trafiać na podstawioną domenę. Brytyjski regulator uznał, że w całym ataku napastnik mógł uzyskać dostęp m.in. do nazwisk, adresów, numerów kart i kodów CVV 244 tys. klientów. Kara wyniosła 20 mln funtów.

Dlatego PCI SSC zmieniła zasady. Od 1 kwietnia 2025 r. sprzedawca korzystający z SAQ A musi potwierdzić, że jego strona nie jest podatna na ataki skryptami. Dla stron z osadzonym formularzem FAQ 1588 daje dwie drogi:

• własna ochrona, np. techniki z wymagań 6.4.3 (kontrola skryptów na stronie) i 11.6.1 (wykrywanie zmian),
• potwierdzenie od dostawcy zgodnego z PCI DSS, że jego rozwiązanie wdrożone według instrukcji chroni przed takimi atakami.

Przy czystym przekierowaniu do bramki to kryterium nie obowiązuje. Nie znaczy to jednak, że strona sklepu wypada z gry, o czym niżej.

Cztery sposoby przyjęcia płatności

Im dalej numer karty od Twojego kodu, tym mniej obowiązków. Wybór to zwykle kompromis między wygodą w koszyku a zakresem PCI DSS.

Uwaga na słowa: „płatność na stronie sklepu” nie zawsze oznacza iframe. Polskie bramki oferują integracje bez przekierowania, np. Secure Form w PayU czy formularz kartowy on-site w Tpay. Przed wdrożeniem zapytaj dostawcę, jaki SAQ obejmuje konkretną integrację, i poproś o odpowiedź na piśmie.

W Polsce dochodzi do tego jeszcze BLIK. Klient podaje jednorazowy kod i potwierdza płatność w aplikacji banku, więc w tej metodzie numer karty w ogóle się nie pojawia. W pierwszej połowie 2026 r. w sklepach internetowych płacono BLIK-iem około 767 mln razy. Karty wciąż warto mieć, ale dla wielu sklepów nie będą jedyną ani główną metodą.

Co zostaje po Twojej stronie

„Nie dotykam danych” nie znaczy „PCI mnie nie dotyczy”. Stripe nazywa to wprost wspólną odpowiedzialnością: dostawca odpowiada za swoją część, a sprzedawca co roku potwierdza swoją. Przed startem sprzedaży sprawdź te punkty:

• Ustal SAQ z operatorem. O właściwej ankiecie ostatecznie decyduje agent rozliczeniowy lub organizacja kartowa, a nie blog ani wykonawca strony.
• Zdobądź potwierdzenie od dostawcy. Sama informacja „jesteśmy zgodni z PCI” nie wystarczy. Potrzebujesz potwierdzenia, że rozwiązanie chroni przed atakami skryptami.
• Trzymaj się instrukcji wdrożenia. Potwierdzenie dostawcy zwykle obowiązuje tylko przy integracji zgodnej z jego dokumentacją.
• Zrób przegląd skryptów na stronie płatności. Menedżer tagów, czat, piksele reklamowe i mapy cieplne to cudzy kod na Twojej stronie. Zostaw tam tylko to, co niezbędne, i ogranicz resztę przez Content Security Policy.
• Sprawdź skany ASV. FAQ 1604 z czerwca 2026 r. potwierdza, że skany zatwierdzonego dostawcy w SAQ A dotyczą też stron z przekierowaniem i z iframe.
• Nie ufaj przeglądarce w sprawie zapłaty. Status zamówienia zmieniaj na podstawie powiadomienia od dostawcy i weryfikuj jego podpis.
• Nie zbieraj numerów kart bokiem. Numer karty w polu „uwagi do zamówienia”, w mailu czy w logach błędów niweczy całą konstrukcję.

Punkt o skryptach szczególnie dotyczy sklepów prowadzących reklamy. Tag dodany „tylko na chwilę” może trafić akurat na stronę płatności. Mierzenie konwersji da się zwykle ustawić na stronie podziękowania, bez wpuszczania dodatkowego kodu do kroku płatności.

Magia, która ma instrukcję obsługi

Formularz na stronie, do którego właściciel strony nie ma dostępu, to piękny kawałek inżynierii. Przeglądarka pilnuje granicy, dostawca bierze na siebie najtrudniejszą część, a Ty zachowujesz wygląd sklepu.

Ta granica działa jednak tylko wtedy, gdy ktoś jej pilnuje po Twojej stronie. Jeśli planujesz sklep albo chcesz sprawdzić obecny, zobacz, jak budujemy sklepy internetowe lub napisz do nas. Podpowiemy, która integracja płatności pasuje do Twojej sprzedaży.

Artykuł ma charakter informacyjny i nie zastępuje oceny zgodności. O wymaganiach dla Twojej firmy decydują operator płatności i organizacje kartowe.

Źródła

Stan na 2 listopada 2026 r.

• PCI SSC: FAQ wyjaśnia kryterium SAQ A dla e-commerce
• PCI SSC: FAQ 1604 o skanach ASV
• Stripe: Integration security guide
• MDN: Same-origin policy
• MDN: HTMLIFrameElement.contentDocument
• ICO: kara dla British Airways (komunikat)
• Wikipedia: British Airways data breach
• Davis Wright Tremaine: obowiązki sprzedawców po FAQ 1588
• PayU: przegląd integracji i tokenizacja kart
• Tpay: metody integracji
• XYZ.pl: wyniki BLIK-a w I półroczu 2026 r.