Agentic Payment Provider i Network Tokeny Visa (VTS) – 7 obowiązków PCI DSS, które musisz znać

Zaktualizowano: 11 czerwca 2026

Czym jest Agentic Payment Provider? Agentic Payment Provider (APP) to nowa kategoria dostawcy usług regulowana przez Visa, formalnie zdefiniowana w Visa Core Rules and Visa Product and Service Rules z 18 kwietnia 2026 roku. APP to podmiot działający autonomicznie w imieniu posiadacza karty – przeszukujący oferty i dokonujący zakupów przy użyciu przechowywanych danych płatniczych i instrukcji zdefiniowanych przez użytkownika, bez konieczności każdorazowego potwierdzenia transakcji przez posiadacza karty w czasie rzeczywistym. W praktyce dotyczy to agentów AI, autonomicznych botów zakupowych oraz każdej platformy wykonującej płatności w imieniu użytkownika bez jego aktywnego udziału przy kasie.

Agentic Payment Provider i Network Tokeny Visa – w skrócie:

1. Visa formalnie powołała kategorię APP w regułach z 18 kwietnia 2026 roku. Obok niej wprowadzono kategorię Agentic Payment Enabler (APE) – platformę, która zawiera umowy z APP-ami i rejestruje je w Visa.
2. Każda transakcja agentyczna (Agentic Transaction) z wykorzystaniem przechowywanych danych musi używać Network Tokenu – nie surowego numeru karty (PAN). Token musi być pobrany bezpośrednio od Visa lub od zarejestrowanego APE.
3. Wymóg zgodności z PCI DSS jest wprost zapisany w regułach Visa dla Agentic Payment Enabler . Dla APP wymóg wynika z faktu obsługi przechowywanych danych płatniczych i tokenów.
4. Przed każdą transakcją agentyczną APP musi uzyskać wyraźną świadomą zgodę posiadacza karty na przechowywanie danych i autonomiczne działanie, zweryfikować jego tożsamość zgodnie ze specyfikacją Visa Intelligent Commerce, oraz zachować dokumentację zgody przez cały czas trwania umowy.
5. APP nie może agregować wielu transakcji agentycznych w jedną, nie może działać w środowisku card-present i nie może przekazywać tokenu żadnemu podmiotowi spoza zdefiniowanego łańcucha.
6. Po transakcji APP musi udostępniać posiadaczowi karty potwierdzenie zamówienia przez co najmniej 120 dni od daty przetworzenia.
7. Patronusec jako akredytowany QSA wspiera fintechy, platformy płatnicze i firmy AI commerce w określeniu zakresu certyfikacji PCI DSS jako Agentic Payment Provider lub Enabler – od analizy luk przez testy bezpieczeństwa po Report on Compliance (ROC).

---

---

Czym jest Agentic Payment Enabler i jak różni się od Agentic Payment Provider?

Visa wprowadziła w regułach z 18 kwietnia 2026 dwuwarstwową strukturę dla płatności agentycznych, rozdzielając odpowiedzialność między dwie odrębne role regulowane.

Agentic Payment Enabler (APE) to warstwa infrastrukturalna. Musi on zapisać się do programu Visa Intelligent Commerce i zarejestrować z Visa, zawrzeć umowę z każdym APPem, z którym współpracuje – umowa musi zawierać wymóg zgodności APP z regułami Visa, prawem i przepisami oraz prawo do natychmiastowego rozwiązania umowy z APP – oraz pobierać tokeny bezpośrednio od Visa, gdy korzysta z przechowywanych danych. APE nie może składać ani deponować transakcji w imieniu APP. Co istotne, reguły Visa wprost stanowią, że APE „musi zapewnić zgodność z Payment Card Industry Data Security Standard (PCI DSS)”.

Agentic Payment Provider (APP) to warstwa wykonawcza – agent AI lub autonomiczny serwis działający na podstawie instrukcji posiadacza karty. APP musi być zarejestrowany w Visa bezpośrednio lub przez APE, nie może nakłaniać posiadaczy kart do zmiany metody płatności, musi oferować usługi jednolicie wszystkim posiadaczom kart oraz pobierać tokeny bezpośrednio od Visa lub przez APE.

To nie są role wymienne. Jedna firma może pełnić obie jednocześnie – ale obowiązki każdej roli są śledzone przez Visa oddzielnie, a nieprzestrzeganie którejkolwiek z nich może skutkować dyskwalifikacją z programu Visa.

Pytanie klasyfikacyjne – „Jesteśmy APP, APE, czy obiema rolami?” – nie jest akademickie. Determinuje ono ścieżkę certyfikacji PCI DSS: merchant SAQ dla mniejszego zakresu, lub service provider ROC dla podmiotów obsługujących przechowywane dane płatnicze na większą skalę.

Patronusec Insight: Najczęstsza pułapka, którą widzimy przy scoping PCI DSS dla platform płatności autonomicznych, to błędna klasyfikacja jako „merchant z przechowywanymi danymi” zamiast jako Agentic Payment Provider lub Enabler. Konsekwencja to materialne różnice w wymaganiach certyfikacyjnych – i przeprowadzony audyt pod złą ścieżką, który trzeba powtórzyć. Jeśli Twoja platforma wykonuje transakcje bez aktywnego udziału użytkownika przy każdym zakupie, klasyfikacja powinna być pierwszym krokiem – analiza luk PCI DSS z uwzględnieniem nowych kategorii Visa to najszybszy sposób na defensywne określenie zakresu.

Czym są Network Tokeny Visa i dlaczego są obowiązkowe w transakcjach agentycznych?

Network Token – w rozumieniu Visa – to wartość zastępcza wydana przez Visa Token Service (VTS), która zastępuje podstawowy numer karty (PAN) w transakcji. Token jest powiązany z określoną domeną (urządzenie, merchant, kanał) i nie może być użyty poza tą domeną bez weryfikacji Visa zgodnie z EMV Payment Tokenisation Specification.

Dla płatności agentycznych tokenizacja nie jest opcjonalna. Każda transakcja agentyczna z wykorzystaniem przechowywanych danych musi używać tokenu zaprowizjonowanego przez VTS. APP pobiera token bezpośrednio od Visa lub od APE – nie od żadnego innego pośrednika. Reguły Visa wprost zabraniają przekazywania tokenu jakiemukolwiek innemu podmiotowi spoza zdefiniowanego łańcucha, w tym innym APPom lub APEom.

Visa Token Service działa w oparciu o rygorystyczny model zarządczy dla Issuerów. Kluczowe wymagania dla Issuerów to:

• Wszystkie BINy muszą być włączone w VTS dla transakcji w środowisku card-absent (w regionie Europe dotyczy to co najmniej Active Issuer Participants).
• Visa Token Service Active Issuer Participant musi utrzymywać minimalny miesięczny wskaźnik akceptacji tokenu na poziomie 90% na BIN.
• Każdy token musi odzwierciedlać aktualny numer konta i datę ważności leżących u jego podstaw danych płatniczych.
• Tam gdzie Visa Token Service Basic Issuer Participant nie zarządza aktualizacjami tokenów, Visa robi to w jego imieniu.

Dla APP i APE działających w Europie: strona Issuera łańcucha tokenizacji jest już objęta wymogiem gotowości VTS. Ryzyko operacyjne to nie „Issuer odmawia tokenizacji” – to „miesięczny wskaźnik akceptacji tokenów spada poniżej 90% dla konkretnego BINu i przechowywane dane APP stają się nierozwiązywalne”.

Patronusec Insight: Z naszych projektów PCI DSS wynika, że najczęstszy błąd przy określaniu zakresu CDE dla platform tokenizacyjnych to założenie, że „używamy tokenów, więc jesteśmy poza zakresem”. Tokenizacja redukuje zakres PCI DSS – ale wyłącznie wtedy, gdy token jest faktycznie poza środowiskiem danych posiadacza karty dla danego podmiotu. APP, który żąda, przechowuje, buforuje lub routuje tokeny, obsługuje dane płatnicze – niezależnie od braku surowego PAN. Pytanie, które zada Twój QSA, brzmi: „W którym miejscu Twój system dotyka tokenu i jak długo?” To odpowiedź determinuje granicę CDE. Jeśli budujesz platformę agentyczną i nie przeprowadziłeś jeszcze analizy luk PCI DSS uwzględniającej obsługę tokenów, Twój zakres jest niemal na pewno niekompletny.

Jakie są 7 obowiązków PCI DSS i bezpieczeństwa dla Agentic Payment Provider?

Reguły Visa nie wyliczają wymagań PCI DSS punkt po punkcie – odwołują się do PCI DSS jako bazowego standardu zgodności i nakładają na to specyficzne dla Visa wymagania bezpieczeństwa. Na podstawie sekcji 4.1.xx – obowiązki można zmapować następująco:

1. Zgodność z PCI DSS
Agentic Payment Enabler musi być zgodny z PCI DSS. To bezwarunkowe wymaganie wprost zapisane w regułach Visa. Dla APP wymóg PCI DSS wynika z obsługi przechowywanych danych i tokenów – co umieszcza go w zakresie PCI DSS jako Service Provider.

2. Obsługa danych wyłącznie przez tokeny
Zarówno APE, jak i APP muszą używać tokenów – nie surowych PAN – przy inicjowaniu transakcji z użyciem przechowywanych danych. Token musi być pobrany bezpośrednio od Visa lub APE. Przekazanie tokenu jakiemukolwiek innemu podmiotowi jest zabronione.

3. Weryfikacja tożsamości posiadacza karty przed przechowaniem danych
Zanim APP przechowa dane płatnicze lub zadziała na podstawie instrukcji posiadacza karty, musi zweryfikować jego tożsamość zgodnie ze specyfikacją Visa Intelligent Commerce. Ma to bezpośrednie implikacje dla wymagań PCI DSS wymóg 8 (zarządzanie tożsamością i dostępem).

4. Wyraźna świadoma zgoda – udokumentowana i przechowywana
APP musi uzyskać i przechowywać udokumentowaną zgodę na przechowywanie danych i wykonywanie transakcji. Zgoda musi określać: numer konta (ostatnie 4 cyfry), sposób komunikowania zmian, sposób wykorzystania przechowywanych danych, datę ważności umowy. Wymagania dotyczące przechowywania zgadzają się z PCI DSS wymóg 12 (polityki, dokumentacja, zarządzanie dowodami).

5. Kontrole na poziomie transakcji – brak agregacji, brak card-present, brak udostępniania tokenów
APPom zabrania się agregowania wielu transakcji agentycznych w jedną, działania w środowisku card-present i udostępniania tokenów poza zdefiniowanym łańcuchem Visa. To ograniczenia bezpośrednio wpływające na projektowanie przepływów danych płatniczych – kluczowy aspekt określania zakresu i segmentacji sieci w PCI DSS.

6. Potwierdzenie zamówienia przez 120 dni
APPy muszą zachowywać i udostępniać posiadaczom kart potwierdzenia zamówień przez co najmniej 120 dni od daty przetworzenia. To przecina się z PCI DSS wymóg 10 (zarządzanie logami i retencja) oraz wymóg 12 (polityki retencji danych).

7. Odpowiedzialność posiadacza karty i implikacje dla chargebacków
Posiadacz karty odpowiada za działania APP tak, jakby sam zainicjował transakcję. Ta alokacja odpowiedzialności nie zmniejsza obowiązków bezpieczeństwa APP – zwiększa je. Każde naruszenie bezpieczeństwa skutkujące nieautoryzowaną transakcją agentyczną to jednocześnie ryzyko regulacyjne i reputacyjne dla APP.

W praktyce oznacza to: certyfikacja PCI DSS dla platformy agentycznej to nie formalność. To fundament ochrony przed odpowiedzialnością wobec Visa, Issuera i posiadacza karty.

Kogo dotyczy regulacja i od kiedy?

Kategorie Agentic Payment Provider i Agentic Payment Enabler obowiązują od 18 kwietnia 2026 globalnie (z niewielkim opóźnieniem dla Chile: 17 czerwca 2026 dla niektórych przepisów dotyczących tokenów). Jeśli Twoja platforma realizowała funkcje płatności autonomicznych przed tą datą, działała w regulacyjnej szarej strefie. Po 18 kwietnia 2026 szarej strefy nie ma.

Podmioty, które powinny natychmiast ocenić swoją klasyfikację:

• Platformy rezerwacji podróży oparte na AI, które przechowują dane Visa i dokonują rezerwacji autonomicznie
• Platformy e-commerce subskrypcyjne z funkcją automatycznego uzupełniania zapasów
• Narzędzia do zarządzania wydatkami korporacyjnymi wykonujące płatności na podstawie wstępnie zdefiniowanych reguł
• Każda platforma działająca jako pośrednik między przechowanymi danymi Visa posiadacza karty a transakcją merchantową bez każdorazowej inicjacji przez posiadacza karty w czasie rzeczywistym

Jeśli budujesz rozwiązanie na bazie Digital Wallet (w tym Pass-Through Digital Wallet), sekcja 4.1.xx wprowadza szczegółowe wymagania dla Operatorów Digital Wallet ułatwiających transakcje agentyczne, obowiązujące od 18 kwietnia 2026. Operator Digital Wallet musi weryfikować posiadacza karty za pomocą zatwierdzonej przez Visa metody CDCVM w momencie prezentowania instrukcji płatności, przesyłać wszystkie dane płatnicze do Visa po potwierdzeniu i przekazywać token do APP lub merchantowi w celu sfinalizowania transakcji.

Co oznacza model zgody posiadacza karty dla architektury bezpieczeństwa?

Sekcja 4.1.x to jeden z najbardziej operacyjnie istotnych wymogów w ramach Agentic Payment, a jednocześnie łatwy do niedocenienia. APP musi uzyskać zgodę posiadacza karty spełniającą łącznie następujące warunki:

• Specyficzna dla przechowywanych danych: posiadacz karty musi wyrazić zgodę na przechowywanie przez APP jego danych płatniczych jako tokenu do przyszłego użytku.
• Specyficzna dla instrukcji płatności: posiadacz karty musi wyrazić zgodę na autonomiczne działanie APP na podstawie zdefiniowanych przez niego instrukcji (kryteria wyszukiwania i zakupu).
• Ograniczona czasowo: APP musi jasno podać datę wygaśnięcia instrukcji płatności posiadacza karty.
• Przechowywana niezależnie: APP musi przechowywać dokumentację zgody przez czas trwania umowy i udostępniać ją posiadaczowi karty lub Issuerowi na pisemne żądanie.

Z perspektywy PCI DSS wymagania te wpływają na projekt środowiska danych posiadacza karty (CDE). Jeśli mechanizm zbierania zgody, przepływ żądania tokenu i repozytorium przechowywanych instrukcji znajdą się w tym samym systemie, budujesz jedno – i duże – CDE. Jeśli uda się zaprojektować architekturę tak, by APE realizował provisionowanie tokenów bez bezpośredniego kontaktu APP z surowymi danymi kart, zakres może być materialnie mniejszy.

Ta decyzja architektoniczna to nie tylko kwestia compliance – to decyzja biznesowa z implikacjami kosztowymi. Koszt certyfikacji PCI DSS dla Service Providera obsługującego przechowywane dane jest materialnie wyższy niż dla merchanta, który jedynie przekazuje dane tokenizowane bez ich przechowywania.

Patronusec Insight: Pytanie klasyfikacyjne „Jesteśmy APP czy APE?” brzmi prosto – do momentu, gdy siedzisz przy tablicy i mapujesz rzeczywisty przepływ transakcji. W praktyce platformy, które początkowo klasyfikowały się jako „tylko portfel” lub „merchant z przechowywanymi danymi”, po właściwym scopingu okazywały się Agentic Payment Providerami. Konsekwencja to materialne powiększenie powierzchni PCI DSS – łącznie z obowiązkami raportowania Service Providera, które nie dotyczą standardowych merchantów. Jeśli Twój zespół nie ma wewnętrznych zasobów, by przeprowadzić tę analizę, model vCISO to efektywny sposób na ustrukturyzowaną klasyfikację i scope review bez kosztów i czasu rekrutacji na pełny etat.

FAQ

---

Twój następny krok

Kategoria Agentic Payment Provider jest nowa, a większość programów compliance nie nadążyła jeszcze za jej implikacjami. Jeśli budujesz lub operujesz autonomiczną platformą płatniczą i nie określiłeś jeszcze swojego zakresu PCI DSS jako APP lub APE zgodnie z regułami Visa z 2026 roku, czas na działanie jest teraz – zanim rozpocznie się kolejny cykl certyfikacyjny.

Patronusec wspiera platformy płatnicze, fintechy i firmy z obszaru AI commerce w Europie w zakresie:

• Certyfikacja PCI DSS i ROC – jako akredytowany QSA
• Analiza luk PCI DSS – mapowanie zakresu i gotowość przed audytem
• Testy penetracyjne – zgodne z wymogiem 11 PCI DSS
• vCISO na żądanie – dla zespołów prowadzących klasyfikację i scoping bez wewnętrznych zasobów