Płatności agentowe Visa i Mastercard – 8 zasad przetwarzania kart przez agenta AI i ich wpływ na zakres PCI DSS

Aktualizacja: 16 sierpnia 2026

Jak przetwarzać karty w płatnościach agentowych zgodnie z regułami Visa i Mastercard? Agent AI nie może operować surowym numerem karty (PAN). Obie sieci dopuszczają wyłącznie transakcje realizowane przez zarejestrowanego agenta przy użyciu tokenu sieciowego powiązanego z jego tożsamością – po weryfikacji posiadacza karty i na podstawie udokumentowanej zgody. Visa zapisała te obowiązki w Visa Core Rules and Visa Product and Service Rules z 18 kwi 2026, Mastercard – w programie Agent Pay i opublikowanym w paź 2025 Agent Pay Acceptance Framework. Dla firmy budującej agenta płatniczego przekłada się to na konkretne decyzje architektoniczne i bezpośrednio kształtuje zakres certyfikacji PCI DSS.

Przetwarzanie kart w płatnościach agentowych polega na zastąpieniu numeru PAN tokenem sieciowym powiązanym z zarejestrowanym agentem AI, wydawanym po weryfikacji tożsamości posiadacza karty i na podstawie udokumentowanej zgody, zgodnie z regułami Visa i Mastercard.

Płatności agentowe Visa i Mastercard – w skrócie:

1. Reguły Visa obowiązujące od 18 kwi 2026 wymagają, aby każda transakcja agentowa z użyciem przechowywanych danych korzystała z network tokenu pobranego bezpośrednio od Visa lub zarejestrowanego Agentic Payment Enablera – użycie surowego PAN narusza reguły sieci.
2. Mastercard dopuszcza do transakcji wyłącznie agentów zweryfikowanych w procesie Know Your Agent (KYA); płatność realizuje Agentic Token – dynamiczny token z danymi agenta, zgody i limitów, walidowany po stronie sieci przy autoryzacji.
3. PCI SSC w Tokenization Guidelines (sie 2011) wskazuje, że token zdolny do zainicjowania transakcji może pozostawać w zakresie PCI DSS – o klasyfikacji rozstrzyga acquirer i sieć płatnicza, dlatego bezpiecznym założeniem jest traktowanie tokenu jak instrumentu płatniczego.
4. System tokenizacji oraz każdy komponent z dostępem do procesu tokenizacji lub detokenizacji zawsze pozostaje w zakresie PCI DSS – „używamy tokenów” nie oznacza automatycznie „jesteśmy poza zakresem”.
5. Merchant akceptujący agentów weryfikuje ich autentyczność sygnaturami Web Bot Auth (Mastercard) lub przez Trusted Agent Protocol oparty na RFC 9421 (Visa) – bez przebudowy istniejącej integracji płatniczej.
6. Patronusec jako akredytowany QSA prowadzi platformy agentowe przez klasyfikację roli wobec sieci, analizę luk i certyfikację PCI DSS – od scope assessment po Report on Compliance (ROC).

Czym różnią się płatności agentowe Visa i Mastercard – Intelligent Commerce vs Agent Pay?

Visa reguluje płatności agentowe przez role Agentic Payment Provider i Agentic Payment Enabler zapisane w Visa Rules od 18 kwi 2026 oraz tokeny wydawane przez Visa Token Service. Mastercard opiera program Agent Pay na rejestracji agenta w procesie Know Your Agent i na Agentic Tokens – tokenach MDES rozszerzonych o dane agenta, zgody i limitów.

Fundament obu programów jest identyczny: transakcję agentową może zainicjować wyłącznie zarejestrowany agent posługujący się tokenem sieciowym, nigdy surowym numerem karty. Różnice zaczynają się w warstwie regulacyjnej i technicznej.

Visa Intelligent Commerce działa w oparciu o formalne kategorie podmiotów wpisane do publicznych reguł sieci. Agentic Payment Provider (APP) wykonuje transakcje w imieniu posiadacza karty, a Agentic Payment Enabler (APE) rejestruje APP-y i pośredniczy w provisioningu tokenów. Szczegółowo rozłożyliśmy te role i 7 obowiązków z nimi związanych w osobnym aktywie o Agentic Payment Providerach i network tokenach Visa.

Mastercard Agent Pay kładzie nacisk na weryfikację samego agenta. Według Mastercard dostęp do tokenów wymaga rejestracji agenta w procesie Know Your Agent (KYA) – odpowiedniku KYC dla oprogramowania – a każdy Agentic Token przenosi metadane o agencie, zakresie merchanta i dozwolonej kopercie transakcji. Mastercard podał, że od połowy lis 2025 obsługą Agent Pay objęci są wszyscy posiadacze kart Mastercard w USA, a kolejne rynki dołączają sukcesywnie; w cze 2026 program rozszerzono o płatności machine-to-machine (Agent Pay for Machines).

Obszar	Visa Intelligent Commerce	Mastercard Agent Pay
Podstawa	Visa Core Rules and Visa Product and Service Rules, od 18 kwi 2026	Program Agent Pay + Agent Pay Acceptance Framework, paź 2025
Rejestracja agenta	APP rejestrowany w Visa bezpośrednio lub przez APE	Proces Know Your Agent (KYA) przed dostępem do tokenów
Token	Network token z Visa Token Service, powiązany z agentem, zakaz przekazywania poza zdefiniowany łańcuch	Agentic Token na bazie MDES z polami agenta, zgody i limitów, walidowany przy autoryzacji
Tożsamość i zgoda	Weryfikacja posiadacza karty wg specyfikacji Visa Intelligent Commerce, udokumentowana zgoda, potwierdzenia zamówień min. 120 dni	Wyraźna zgoda konsumenta i programowalne limity wydatków zapisane w tokenie
Warstwa merchanta	Trusted Agent Protocol (RFC 9421, opracowany z Cloudflare)	Web Bot Auth na poziomie CDN + Dynamic Token Verification Code w standardowych polach karty

Jeśli różnica między network tokenem a tokenem agentowym nie jest dla Ciebie oczywista, zacznij od naszego przewodnika po 4 rodzajach tokenów i różnicach decydujących o zakresie PCI DSS – ten artykuł zakłada, że rozróżnienie jest już znane.

Czy agent AI może przetwarzać surowy numer karty (PAN)?

Nie. Reguły Visa od 18 kwi 2026 wymagają, aby transakcja agentowa z użyciem przechowywanych danych korzystała z network tokenu pobranego bezpośrednio od Visa lub zarejestrowanego Agentic Payment Enablera. Mastercard dopuszcza wyłącznie Agentic Tokens wydawane zarejestrowanym agentom. Surowy PAN w przepływie agenta narusza reguły obu sieci.

Zakaz ma dwie praktyczne konsekwencje, które łatwo przeoczyć na etapie projektowania.

Po pierwsze, łańcuch dystrybucji tokenu jest zamknięty. Reguły Visa wprost zabraniają przekazania tokenu jakiemukolwiek podmiotowi spoza zdefiniowanego łańcucha – w tym innym APP-om lub APE-om. Dokumentacja Mastercard dla merchantów podkreśla z kolei, że agenci nigdy nie dotykają surowych danych uwierzytelniających, a użycie zwykłych stored credentials zamiast Agentic Tokenu uniemożliwia issuerowi rozpoznanie transakcji jako agentowej i zastosowanie właściwych kontroli ryzyka.

Po drugie, PAN może wejść do systemu bocznymi drzwiami – i to jest problem specyficzny dla agentów opartych na LLM. Użytkownik potrafi wkleić pełny numer karty wprost do okna czatu, mimo że przepływ płatności tego nie przewiduje. Od tego momentu PAN trafia do promptów, logów inferencji, pamięci konwersacji i telemetrii – czyli do komponentów, których nikt nie projektował jako części środowiska danych posiadacza karty.

W modelu agentowym numer karty w ogóle nie powinien pojawiać się w warstwie konwersacyjnej – jego jedynym miejscem jest proces provisioningu tokenu po stronie sieci, wallet providera lub enablera. Architektura agenta musi to wymuszać technicznie: filtrowaniem wejścia, maskowaniem danych w logach i regularnym skanowaniem repozytoriów logów pod kątem wzorców PAN.

Czy token płatniczy jest w zakresie PCI DSS?

PCI DSS nie rozstrzyga tego jednoznacznie. PCI SSC w Tokenization Guidelines wskazuje, że token zdolny do zainicjowania transakcji może pozostawać w zakresie PCI DSS, a ostateczną klasyfikację należy ustalić z acquirerem i siecią płatniczą. System tokenizacji i komponenty z dostępem do detokenizacji pozostają w zakresie zawsze.

To pytanie, które regularnie decyduje o wielkości i koszcie certyfikacji – warto więc rozłożyć je na trzy warstwy zgodne ze stanowiskiem PCI SSC wyrażonym w dokumencie Information Supplement: PCI DSS Tokenization Guidelines (sie 2011):

1. Token jako dana. Wytyczne stwierdzają, że tokeny, których można użyć do zainicjowania transakcji, mogą być w zakresie PCI DSS nawet wtedy, gdy nie da się z nich odzyskać numeru PAN – a merchant powinien potwierdzić klasyfikację u swojego acquirera lub bezpośrednio w sieci płatniczej. Standard nie mówi więc „tak, zawsze”, ale mówi wyraźnie „nie zakładaj, że nie”.
2. Token wysokiej wartości. Te same wytyczne ostrzegają, że tokeny pełniące rolę instrumentów płatniczych (tzw. high-value tokens) można spieniężyć lub wykorzystać do wygenerowania oszukańczych transakcji, przez co dla napastnika mogą mieć wartość porównywalną z samym numerem karty. Token agentowy spełnia tę definicję wprost: jego jedyną funkcją jest inicjowanie transakcji.
3. System tokenizacji. Niezależnie od klasyfikacji samego tokenu, każdy komponent z dostępem do systemu tokenizacji lub procesu tokenizacji/detokenizacji jest w zakresie PCI DSS – to stanowisko PCI SSC bez wyjątków.

Wniosek praktyczny dla platform agentowych: skoro standard nie daje jednoznacznego „poza zakresem”, a token agentowy jest z definicji instrumentem płatniczym, jedynym defensywnym założeniem projektowym jest traktowanie tokenu jak danych płatniczych w zakresie PCI DSS – z kontrolą dostępu, szyfrowaniem, logowaniem i segmentacją, jakich wymaga środowisko CDE. Jeśli acquirer lub sieć potwierdzi później węższą klasyfikację, zakres można zredukować; odwrotna kolejność kończy się przebudową architektury pod audyt.

Patronusec Insight: Z naszych projektów PCI DSS wynika, że zespoły budujące agentów płatniczych najczęściej wpadają w pułapkę odwróconej logiki: najpierw zakładają „token = poza zakresem”, a dopiero przed audytem sprawdzają, którędy token faktycznie przepływa. Tymczasem pamięć konwersacji, cache odpowiedzi API i logi promptów to miejsca, w których tokeny – a czasem surowe PAN-y wklejone przez użytkownika – osiadają na tygodnie. Analiza luk PCI DSS przeprowadzona na etapie projektowania przepływów kosztuje ułamek tego, co przeprojektowanie platformy po pierwszym scopingu z QSA.

Budujesz platformę agentową i nie wiesz, czy reguły Visa z 18 kwi 2026 czynią z Ciebie Agentic Payment Providera, Enablera czy service providera PCI DSS?

W ramach bezpłatnej 30-minutowej rozmowy scope assessment przejdziemy przez Twój przepływ tokenów i wskażemy, która ścieżka certyfikacji (SAQ czy ROC) dotyczy Twojej roli – wraz z listą systemów, które wejdą do zakresu.

Umów scope assessment z akredytowanym QSA

Na co musi uważać firma budująca agenta płatniczego? 8 zasad zgodności

Firma budująca agenta płatniczego musi zaklasyfikować swoją rolę wobec sieci, zarejestrować agenta, wyeliminować surowy PAN z całego przepływu, pobierać tokeny z autoryzowanego łańcucha, traktować je jak dane płatnicze, weryfikować tożsamość i zgodę posiadacza karty, przechowywać dane intencji zakupowej oraz odseparować runtime agenta od systemu tokenizacji.

Rozwińmy każdą z zasad:

1. Zaklasyfikuj rolę, zanim zaprojektujesz architekturę. U Visa pytanie brzmi: APP, APE czy obie role; u Mastercard: agent podlegający rejestracji KYA czy platforma korzystająca z zarejestrowanego agenta. Klasyfikacja determinuje ścieżkę certyfikacji PCI DSS i zestaw obowiązków wobec sieci – błędna klasyfikacja unieważnia dalsze decyzje projektowe.

2. Zarejestruj agenta w programie sieci. Visa wymaga rejestracji APP bezpośrednio lub przez APE; Mastercard warunkuje dostęp do Agentic Tokens przejściem procesu Know Your Agent. Niezarejestrowany agent nie ma legalnej drogi do tokenu.

3. Wyeliminuj surowy PAN z każdego punktu styku agenta. Dotyczy to nie tylko przepływu płatności, ale też promptów, pamięci konwersacji, logów inferencji, telemetrii i zrzutów debugowych. Zaprojektuj filtrowanie wejścia i maskowanie wyjścia, a repozytoria logów obejmij regularnym skanowaniem pod kątem wzorców numerów kart.

4. Pobieraj tokeny wyłącznie z autoryzowanego łańcucha. Dla Visa oznacza to provisioning bezpośrednio z Visa Token Service lub przez zarejestrowanego APE; dla Mastercard – przez MDES w ramach Agent Pay. Każdy pośrednik spoza łańcucha to naruszenie reguł sieci i rozszerzenie zakresu audytu.

5. Traktuj token jak instrument płatniczy w zakresie PCI DSS. Zgodnie z wnioskami z poprzedniej sekcji: kontrola dostępu, szyfrowanie w spoczynku i tranzycie, logowanie zdarzeń i ograniczenie retencji obejmują tokeny tak samo jak dane posiadacza karty.

6. Weryfikuj tożsamość i dokumentuj zgodę. Visa wymaga weryfikacji posiadacza karty zgodnie ze specyfikacją Visa Intelligent Commerce (w tym mechanizmów step-up i passkey) oraz przechowywania udokumentowanej zgody; Mastercard rozwija z FIDO Alliance standard Verifiable Credential potwierdzający kwotę, merchanta i szczegóły produktu. Repozytorium zgód projektuj od razu pod wymogi dowodowe – to ono będzie pierwszym artefaktem w sporze.

7. Utrzymuj dane intencji i potwierdzenia zamówień. Reguły Visa nakazują udostępniać posiadaczowi karty potwierdzenie zamówienia przez co najmniej 120 dni od przetworzenia transakcji. Dane intencji (commerce signals) to jednocześnie materiał dowodowy w chargebackach – ich retencję i integralność potraktuj jak wymóg, nie opcję.

8. Odseparuj runtime agenta od systemu tokenizacji. Model językowy, orkiestrator narzędzi i warstwa konwersacyjna nie powinny mieć bezpośredniego dostępu do vaulta tokenów. Wydzielony serwis płatności z wąskim API ogranicza CDE do przewidywalnego minimum – szczegóły tej techniki opisaliśmy w przewodniku po zakresie PCI DSS, CDE i segmentacji.

W praktyce oznacza to: granicę zgodności wyznacza nie sama technologia agenta, lecz dyscyplina, z jaką kontrolujesz każde miejsce żądania, buforowania i przekazywania tokenu.

Jak płatności agentowe Visa i Mastercard wpływają na zakres certyfikacji PCI DSS?

Platforma agentowa obsługująca tokeny w imieniu posiadaczy kart z reguły wchodzi w zakres PCI DSS jako service provider – z potwierdzaniem zakresu co 6 miesięcy i zwykle pełnym ROC zamiast SAQ. Granice CDE wyznaczają systemy żądające, przechowujące i przekazujące tokeny oraz komponenty z nimi połączone.

Trzy konsekwencje zasługują na szczególną uwagę przy planowaniu certyfikacji.

Ścieżka service providera zamiast merchanta. Podmiot wykonujący transakcje w imieniu posiadaczy kart lub pośredniczący w provisioningu tokenów świadczy usługę wpływającą na bezpieczeństwo danych płatniczych innych podmiotów – a to definicyjna cecha service providera. Wymóg 12.5.2.1 PCI DSS v4.0.1 nakłada na service providerów obowiązek potwierdzania i dokumentowania zakresu co najmniej raz na 6 miesięcy oraz po każdej istotnej zmianie – dla szybko iterującej platformy AI to rytm, który trzeba wpisać w proces wydawniczy, nie w kalendarz audytu.

Testy bezpieczeństwa dopasowane do nowej powierzchni ataku. Wymóg 11.4 PCI DSS v4.0.1 obejmuje testy penetracyjne warstwy aplikacyjnej i sieciowej, a wymóg 11.4.6 nakazuje service providerom weryfikować skuteczność segmentacji co najmniej co 6 miesięcy. Dla platformy agentowej zakres testów musi objąć także API provisioningu tokenów, mechanizmy zgody oraz odporność warstwy konwersacyjnej na wyprowadzenie tokenu przez manipulację promptem. Patronusec realizuje testy penetracyjne łączące klasyczny zakres wymogu 11 z oceną integracji AI – raporty przygotowuje zespół z certyfikatami OSCP i CREST, z wiedzą o tym, co zaakceptuje audytor, bo sami pełnimy rolę QSA w innych projektach.

Architektura jako dźwignia kosztowa. Największa różnica w koszcie certyfikacji między porównywalnymi platformami agentowymi, jakie widzieliśmy w praktyce projektowej, wynikała nie ze skali biznesu, lecz z decyzji, czy runtime agenta ma bezpośredni dostęp do tokenów. Wydzielenie interakcji z vaultem do wąskiego, odseparowanego serwisu potrafi zredukować CDE z „całej platformy” do kilku komponentów.

Co sprawdzi QSA – checklista audytora dla platformy agentowej:

• Czy udokumentowano rolę wobec sieci (APP/APE u Visa, status rejestracji KYA u Mastercard) i czy jest spójna z rzeczywistym przepływem transakcji?
• Czy diagram przepływu danych obejmuje prompty, pamięć konwersacji, logi inferencji i telemetrię – a nie wyłącznie przepływ płatności?
• Czy istnieje techniczna blokada przyjęcia surowego PAN w warstwie konwersacyjnej i dowód jej testowania?
• Czy tokeny są objęte kontrolą dostępu, szyfrowaniem i logowaniem jak dane posiadacza karty?
• Czy repozytorium zgód spełnia wymogi dowodowe sieci (elementy zgody, data ważności instrukcji, dostępność na żądanie)?
• Czy potwierdzenia zamówień i dane intencji są przechowywane co najmniej 120 dni (Visa) z zapewnioną integralnością?
• Czy segmentacja między runtime agenta a systemem tokenizacji została przetestowana w ciągu ostatnich 6 miesięcy?
• Czy zakres PCI DSS potwierdzono w ciągu ostatnich 6 miesięcy (service provider) i po ostatniej istotnej zmianie architektury?

Patronusec Insight: Najdroższy scenariusz, jaki obserwujemy u platform agentowych, to certyfikacja „doklejona” po zbudowaniu produktu: zespół inżynierski iteruje tygodniowo, a zakres PCI DSS zatwierdzono raz, pół roku wcześniej. Każdy nowy tool call agenta, nowy dostawca LLM czy nowy region hostingu potencjalnie zmienia granice CDE. Dla zespołów bez wewnętrznego właściciela tematu model vCISO daje strukturalny nadzór nad zakresem – przegląd zmian architektury pod kątem zgodności wpisany w cykl wydawniczy, bez kosztu etatu.

Co reguły Visa i Mastercard oznaczają dla merchantów akceptujących agentów AI?

Merchant nie musi przebudowywać kasy. Mastercard umożliwia weryfikację agentów sygnaturami Web Bot Auth na poziomie CDN i akceptację Agentic Tokens w standardowych polach karty, a Visa udostępnia Trusted Agent Protocol oparty na RFC 9421. Obowiązki merchanta koncentrują się na rozpoznawaniu zarejestrowanych agentów i zabezpieczaniu dowodów na wypadek sporu.

Wytyczne zgodności dla merchantów (merchant compliance guidelines) w agentic commerce sprowadzają się do trzech pytań: czy rozpoznaję zarejestrowanego agenta, czy akceptuję token zamiast PAN i czy potrafię udowodnić intencję zakupową w sporze.

Rozpoznawanie agenta. Według Agent Pay Acceptance Framework merchant może zweryfikować autentyczność agenta implementacją standardu Web Bot Auth w warstwie CDN – bez wdrażania nowego kodu – a zweryfikowany agent przekazuje Dynamic Token Verification Code, czyli token agentowy sformatowany pod standardowe pola płatności kartą. Po stronie Visa protokół Trusted Agent Protocol, zbudowany na standardzie HTTP Message Signatures (RFC 9421) i opracowany z Cloudflare przy udziale m.in. Adyen, Checkout.com i Worldpay, pozwala merchantowi zweryfikować podpis agenta, zanim udostępni jakikolwiek krok wymagający płatności.

Dowody w sporach. Transakcje agentowe niosą dodatkowe dane kontekstowe – instrukcję użytkownika, zawartość koszyka, limity i okres ważności zgody. Visa zapowiedziała ponadto platformę Intelligent Commerce Connect, która według deklaracji sieci ma obsługiwać inicjowanie płatności, tokenizację, kontrole wydatków i zgodność z PCI w ramach jednej integracji przez Visa Acceptance Platform (pilotaż, szersze wdrożenie planowane na dalszą część 2026 r.). Merchant, który przechowuje sygnały transakcyjne i weryfikuje agentów, wchodzi w spory z kompletem dowodów – to bezpośrednie przełożenie zgodności na wynik finansowy.

Reguły antyfraudowe. Wzorce zakupowe agentów różnią się od ludzkich (pora, tempo, powtarzalność), więc dotychczasowe reguły fraud detection wymagają rekalibracji – inaczej platforma zacznie odrzucać legalny, rosnący kanał sprzedaży.

FAQ

---

Jeśli chcesz wiedzieć więcej

1. Płatności agentowe Visa – jak działa Intelligent Commerce i co oznacza dla bezpieczeństwa – fundament tematu od strony mechaniki programu Visa.
2. Network token a token agentowy – 4 rodzaje tokenów i różnice decydujące o zakresie PCI DSS – warstwa pojęciowa tokenizacji.
3. Agentic Payment Provider i Network Tokeny Visa – 7 obowiązków PCI DSS – szczegóły ról APP i APE w regułach Visa.
4. Verifiable intent w płatnościach agentowych – jak dowodzić intencji zakupowej w sporach.
5. Zakres PCI DSS, CDE i segmentacja – jak redukować koszty certyfikacji – techniki ograniczania zakresu, które stosujesz przy architekturze agenta.

Płatności agentowe a certyfikacja PCI DSS – bezpłatna konsultacja

Patronusec jako akredytowany QSA pracuje z fintechami, platformami płatniczymi i firmami e-commerce wdrażającymi płatności agentowe – łącząc perspektywę audytora z kompetencjami zespołu pentesterów.

W bezpłatnej 30-minutowej konsultacji pomożemy Ci:

• zaklasyfikować rolę Twojej platformy wobec reguł Visa i Mastercard (APP, APE, service provider, merchant),
• zmapować przepływy tokenów i wskazać systemy, które wejdą do zakresu PCI DSS,
• wybrać ścieżkę walidacji (SAQ czy ROC) i realistyczny harmonogram certyfikacji,
• zaplanować testy bezpieczeństwa obejmujące API tokenów i warstwę konwersacyjną agenta.

Umów bezpłatną konsultację | Certyfikacja PCI DSS | Analiza luk PCI | Testy penetracyjne | vCISO