Jeśli budujesz własne narzędzie, które ma styczność z płatnościami, do kogo należy ryzyko związane ze zgodnością?

Ty. Nie sztuczna inteligencja, która wygenerowała kod, nie Twój dostawca hostingu i nie Twój dostawca płatności. W momencie, gdy zbudowane przez Ciebie narzędzie ma styczność z płatnościami, ryzyko związane ze zgodnością spoczywa na Twojej firmie i pozostaje tam bez względu na to, jak wielu zgodnych z przepisami dostawców podłączysz. To, co możesz zmienić, to wielkość tego ryzyka, a różnica między dobrze zaprojektowanym niestandardowym narzędziem a niedbałym jest ogromna.

Dlaczego ryzyko spada na Ciebie, a nie na Twoich dostawców?

Akceptacja kart opiera się na łańcuchu umów. Organizacje płatnicze ustalają zasady, Twój agent rozliczeniowy (bank, który rozlicza dla Ciebie sprzedaż kartową) je egzekwuje, a Twoja umowa akceptanta przenosi je na Ciebie. Zbiorem zasad jest PCI DSS, standard bezpieczeństwa danych branży kart płatniczych, który dotyczy każdej firmy przechowującej, przetwarzającej lub przesyłającej dane posiadaczy kart (numery kart i towarzyszące im szczegóły). Aktualna wersja to 4.0.1. (Numery wersji i szczegóły programu są dokładne na dzień publikacji; traktuj te szczegóły jako migawkę stanu faktycznego).

Twoi dostawcy mają zobowiązania dotyczące własnych systemów, a zgodny z przepisami dostawca płatności drastycznie zmniejsza Twój udział w pracy. Jednak żadne działania dostawcy nie przenoszą odpowiedzialności. Rada ds. Standardów Bezpieczeństwa PCI (PCI Security Standards Council) wyraźnie wskazuje, że o tym, czy musisz potwierdzić zgodność, decydują organizacje płatnicze oraz Twój agent rozliczeniowy, a ich odpowiedź, zapisana w umowie akceptanta, brzmi: tak. Każdego roku ktoś w Twojej firmie podpisuje deklarację (Attestation of Compliance) stwierdzającą, że Twoje środowisko spełnia ten standard. Ten podpis należy do Ciebie, nie do Twojego dostawcy.

Co się zmienia w momencie, gdy Twój własny kod ma styczność z danymi kart?

Zakres. Koszt i wysiłek związany ze zgodnością zależą od zakresu audytu: każdy system, który ma styczność z danymi posiadaczy kart, a także wszystko, co jest z nim połączone, podlega standardowi.

Sprzedawca, którego płatności są w pełni obsługiwane przez zgodnego z przepisami dostawcę i jego certyfikowane urządzenia, potwierdza zgodność za pomocą krótkiego kwestionariusza samooceny (corocznej listy kontrolnej) składającego się z kilkudziesięciu pytań. Sprzedawca, którego własne oprogramowanie obsługuje numery kart, wpada w najgłębszy poziom, który odzwierciedla większość pełnego standardu: grubo ponad dwieście wymogów obejmujących kwartalne skanowanie podatności, testy penetracyjne, kontrolę dostępu, rejestrowanie zdarzeń i formalne polityki bezpieczeństwa¹.

Ten formularz płatności, który AI napisała dla Ciebie w jedno popołudnie? Jeśli akceptuje numery kart, Twój serwer WWW, baza danych, laptop administratora i sklepowe Wi-Fi mogą zostać objęte zakresem audytu. I nie możesz po prostu po cichu złożyć krótkiego kwestionariusza. Wybór poziomu, do którego się nie kwalifikujesz, nie zmniejsza ryzyka – oznacza to, że podpisany przez Ciebie dokument jest niezgodny z prawdą, co zazwyczaj wychodzi na jaw w najgorszym możliwym momencie, tuż po wycieku danych.

Ile naprawdę kosztuje popełnienie błędu?

Egzekwowanie przepisów ma charakter umowny, więc zazwyczaj zobaczysz to na swoim wyciągu z rozliczeń płatności. Wielu operatorów nalicza cykliczną opłatę za brak zgodności co miesiąc, dopóki nie przejdziesz weryfikacji. Po wycieku danych koszty gwałtownie rosną: obowiązkowe dochodzenie śledcze (forensic), za które płacisz, koszty ponownego wydania kart oraz rosnące kary nakładane przez agenta rozliczeniowego, powszechnie szacowane na kwoty od 5 000 do 100 000 USD miesięcznie (na podstawie taryfikatorów kar publikowanych przez asesorów zgodności PCI). W poważnych przypadkach firma może całkowicie stracić możliwość akceptowania kart.

Dla małego sprzedawcy najdotkliwszy koszt jest cichszy niż jakakolwiek kara: prowadzenie prawdziwego programu bezpieczeństwa wymaga czasu, który planowałeś przeznaczyć na prowadzenie biznesu.

Jak budować niestandardowe narzędzia bez wchodzenia w zakres danych kart płatniczych?

Trzymaj swój kod z dala od ścieżki przetwarzania karty. Twoje niestandardowe narzędzie powinno koordynować sprzedaż: tworzyć koszyk, naliczać rabaty, podsumowywać zamówienie i wysyłać kwotę do obciążenia. Sama karta powinna mieć kontakt wyłącznie z certyfikowanym terminalem (sprzętem płatniczym zatwierdzonym do obsługi kart) lub hostowaną stroną płatności Twojego dostawcy – oba te rozwiązania przekazują dane bezpośrednio do procesora płatności (firmy, która transferuje pieniądze). Twoje narzędzie otrzymuje z powrotem wynik (zatwierdzono lub odrzucono) oraz token (numer referencyjny, który jest bezużyteczny dla każdego, kto by go ukradł).

Ten podział to główny argument pragmatyczny za architekturą headless POS: niestandardowe ekrany na górze, certyfikowana infrastruktura płatnicza pod spodem. To także powód, dla którego kasy wygenerowane przez AI świetnie wyglądają na prezentacjach demonstracyjnych, ale utykają na etapie wdrożenia produkcyjnego, oraz dlaczego formularz internetowy jest złą odpowiedzią na płatności debetowe w obecności klienta, takie jak Interac: płatności osobiste, zarówno technicznie, jak i umownie, powinny być realizowane na certyfikowanym sprzęcie.

Final opiera się dokładnie na tej granicy. Tworzone przez Ciebie procesy (flow), niezależnie od tego, czy projektujesz je samodzielnie za pomocą promptów, czy podłączasz własne AI przez MCP, kontrolują ekrany, koszyki i katalogi. Dane kart trafiają z certyfikowanego terminala do procesora płatności za pośrednictwem Final Pay i nigdy nie trafiają do zbudowanego przez Ciebie procesu. Niestandardowe tam, gdzie jest to bezpieczne, ustandaryzowane tam, gdzie leży odpowiedzialność.

Kto więc ponosi ryzyko zgodności?

Ty i zawsze będziesz je ponosić. Prawdziwa decyzja dotyczy tego, jak duży zakres na siebie przyjmiesz, a to jest wybór architektoniczny, a nie kwestia papierkowej roboty. Zanim wdrożysz narzędzie, które ma styczność z płatnościami, zadaj sobie jedno pytanie: czy mój kod może kiedykolwiek zobaczyć numer karty? Jeśli tak, to Ty musisz prowadzić program zgodności. Jeśli nie, zachowujesz elastyczność niestandardowego rozwiązania przy ułamku obciążeń. Jeśli rozważasz obecnie tego typu wdrożenie, zacznij od artykułu o sygnałach, że Twój gotowy POS przestał Ci wystarczać.