Agentic Payment Providers and Network Tokens Under Visa Rules: 7 PCI DSS Obligations You Cannot Miss

Updated: 9 June 2026

What is an Agentic Payment Provider? An Agentic Payment Provider (APP) is a new category of Visa-regulated service provider, formally defined in the Visa Core Rules and Visa Product and Service Rules effective 18 April 2026. An APP is an entity that acts autonomously on a cardholder’s behalf – searching for and purchasing goods or services using stored payment credentials and cardholder-defined payment instructions, without requiring a real-time cardholder action at the point of each transaction. In practice, this covers AI agents, autonomous payment bots, and any platform that executes purchases on behalf of a user.

Agentic Payment Providers and Network Tokens – in brief:

1. Visa formally created the APP category in its April 2026 rules, alongside a companion category: the Agentic Payment Enabler (APE), which is the platform that contracts with and enables APPs.
2. Every agentic transaction must use a Network Token – not a raw PAN. Tokens must be obtained directly from Visa or from a registered Agentic Payment Enabler.
3. PCI DSS compliance is explicitly required in the Visa Rules for both APEs and, by extension, for APPs handling stored credentials and cardholder data.
4. Before executing any transaction, an APP must obtain express cardholder consent to store payment credentials, must verify cardholder identity per Visa Intelligent Commerce specifications, and must retain consent records for the duration of the agreement.
5. An APP cannot aggregate multiple agentic transactions into a single transaction, cannot operate in a card-present environment, and cannot share tokens with any entity outside the defined chain.
6. Post-transaction, APPs must make order confirmations available to cardholders for at least 120 days from the processing date.
7. Patronusec as an accredited QSA supports fintechs, payment platforms, and AI-driven commerce companies in scoping their PCI DSS certification obligations as Agentic Payment Providers or Enablers – from gap analysis through to Report on Compliance (ROC).

---

---

How Does the Visa Agentic Payment Framework Actually Work?

The April 2026 Visa rules introduced a two-tier architecture for agentic payments, separating responsibilities between two distinct regulated roles.

The Agentic Payment Enabler (APE) is the platform layer. It must enrol in and comply with the Visa Intelligent Commerce programme, register with Visa, contract with each APP it partners with, and – critically – obtain Tokens directly from Visa when using stored credentials. The APE is expressly prohibited from submitting or depositing transactions on behalf of an APP. The Visa Rules state plainly that the APE must “ensure that it complies with the Payment Card Industry Data Security Standard (PCI DSS)”.

The Agentic Payment Provider (APP) is the execution layer – the AI agent or autonomous service acting on cardholder instructions. The APP must be enrolled in or registered with Visa via the APE, must not steer cardholders away from Visa credentials, must offer services uniformly to all cardholders, and must obtain Tokens directly from Visa or through the APE.

These are not interchangeable roles. A single company may be both – but the obligations of each role are tracked separately by Visa, and non-compliance with either can result in disqualification from the Visa programme.

An Agentic Payment Provider is not simply a stored-credential merchant. It is a new regulated entity with autonomous transaction execution authority – and the PCI DSS scope implications are materially different.

What Are Network Tokens in Visa’s Framework and Why Do They Matter for Agentic Payments?

A Network Token – in the Visa context – is a surrogate value issued by the Visa Token Service (VTS) that replaces a primary account number (PAN) in a transaction. The token is bound to a specific domain (device, merchant, channel) and cannot be used outside that domain without Visa’s validation against the EMV Payment Tokenisation Specification.

For agentic payments, tokenisation is not optional. Every agentic transaction using a stored credential must use a Token provisioned through VTS. The APP obtains this token either directly from Visa or from the APE – not from any other intermediary. The Visa Rules explicitly prohibit providing a token to any entity outside the defined chain, including other APPs or APEs.

The Visa Token Service operates under a strict governance model for Issuers. Key requirements for Issuers include:

1. All BINs must be enabled in VTS for card-absent environment transactions (in the Europe Region, this applies at minimum to Active Issuer Participants).
2. A Visa Token Service Active Issuer Participant must maintain a minimum monthly token provisioning approval rate of 90% per BIN.
3. Every token must reflect the most up-to-date underlying account number and expiry date of the underlying payment credential.
4. Where a Visa Token Service Basic Issuer Participant does not manage credential updates, Visa will manage this on their behalf.

For APPs and APEs operating in Europe, this means that the issuer side of the tokenisation chain is already expected to be VTS-enabled – but the responsibility for obtaining and correctly handling that token in the agentic transaction rests entirely with the APP and APE.

Patronusec Insight: In our PCI DSS scoping engagements, the most common misconception we encounter is that tokenisation automatically reduces PCI DSS scope. It does – but only if the token is genuinely out-of-scope for the entity using it. An APP that requests, stores, transmits, or processes tokens is still handling sensitive payment data. The question your QSA will ask is: ‘Does your system see the token, and if so, when?’ The answer determines your CDE boundary. If you are building an agentic platform and have not yet run a PCI DSS gap analysis that explicitly addresses token handling, your scope definition is almost certainly incomplete.

What Are the 7 PCI DSS and Security Obligations for Agentic Payment Providers?

The Visa Rules do not enumerate PCI DSS requirements section by section – they reference PCI DSS as a compliance baseline and layer Visa-specific security controls on top. The obligations map is as follows:

1. PCI DSS compliance (APE and APE)
The Agentic Payment Enabler must comply with PCI DSS. This is a direct, unconditional requirement stated in the Visa Rules. For the APP, PCI DSS applicability follows from the fact that it handles stored credentials and token provisioning – placing it squarely within PCI DSS scope as a service provider.

2. Token-only credential handling
Both APE and APP must use Tokens – not raw PANs – when initiating transactions using stored credentials. The token must be obtained directly from Visa or the APE. Providing a token to any other entity is prohibited.

3. Cardholder identity verification before credential storage
Before storing a payment credential or acting on a cardholder’s payment instructions, the APP must verify cardholder identity per Visa Intelligent Commerce specifications. This has direct implications for authentication controls in PCI DSS Requirement 8 (identity and access management).

4. Express informed consent – documented and retained
The APP must obtain and retain documented consent to store credentials and execute transactions. The consent must specify: the account number (last four digits), how changes will be communicated, how stored credentials will be used, and the expiration of the agreement. Retention requirements align with PCI DSS Requirement 12 (policies, documentation, and evidence management).

5. Transaction-level controls – no aggregation, no card-present, no token sharing
APPs are prohibited from aggregating multiple agentic transactions into one, operating in card-present environments, and sharing tokens beyond the Visa-defined chain. These constraints directly affect how payment data flows are designed – a core PCI DSS scoping and network segmentation concern.

6. Post-transaction order confirmation for 120 days
APPs must retain and make available order confirmations for at least 120 days from the processing date. This intersects with PCI DSS Requirement 10 (log management and retention) and Requirement 12 (data retention policies).

7. Cardholder liability and chargeback implications
A cardholder is responsible for actions taken by an APP as if they initiated the transaction themselves. This allocation of liability does not reduce the APP’s security obligations – it increases them. Any security failure that results in an unauthorised agentic transaction is both a regulatory and a reputational risk for the APP.

Who Needs to Comply and When?

The Agentic Payment Provider and Agentic Payment Enabler categories were effective 18 April 2026 globally (with a slight delay for Chile: 17 June 2026 for certain token-related provisions). If your platform has been operating agentic or autonomous payment functionality before this date, you were operating in a regulatory grey area. After 18 April 2026, there is no grey area.

Entities that should assess their classification immediately include:

• AI-driven travel booking platforms that hold stored Visa credentials and book autonomously
• E-commerce subscription platforms with autonomous replenishment features
• Corporate spend management tools that execute payments based on pre-defined rules
• Any platform operating as an intermediary between a cardholder’s stored Visa credential and a merchant transaction without real-time cardholder initiation

If you are building on top of a Digital Wallet (including a Pass-Through Digital Wallet), note that Visa rules introduced specific requirements for Digital Wallet Operators facilitating agentic transactions, effective 18 April 2026. The Digital Wallet Operator must verify the cardholder via a Visa-approved Consumer Device Cardholder Verification Method (CDCVM) at the point of presenting cardholder-defined payment instructions, transmit all payment data to Visa upon confirmation, and pass the token to the APP or merchant to complete the transaction.

Patronusec Insight: The classification question – ‘Are we an APP or an APE?’ – sounds straightforward until you sit in the room and map the actual transaction flow. In practice, platforms that initially classified themselves as ‘just a wallet’ or ‘just a stored credential merchant’ have found after proper scoping that they meet the definition of an Agentic Payment Provider. The consequence is a materially larger PCI DSS surface – including service provider reporting obligations that do not apply to standard merchants. If your team is working through this classification and needs an external perspective, this is exactly the kind of structured review that a fractional CISO model handles efficiently, without the cost and lead time of a full-time hire.

What Does the Cardholder Consent Model Mean for Your Security Design?

Section 4.1.x is one of the most operationally significant requirements in the Agentic Payment framework, yet it is easy to underestimate. The APP must obtain cardholder consent that is:

• Specific to stored credentials: the cardholder must consent to the APP storing their payment credential as a token for future use.
• Specific to the payment instruction: the cardholder must consent to the APP acting on their defined payment instruction (search and purchase criteria) autonomously.
• Time-bounded: the APP must clearly state the expiration date of the cardholder’s payment instruction.
• Independently retained: the APP must keep consent records for the duration of the agreement and provide them to the cardholder or issuer upon written request.

From a PCI DSS perspective, these requirements affect the design of the cardholder data environment (CDE). If your consent capture mechanism, token request workflow, and stored instruction repository sit within the same system, you are building a single – and large – CDE. If you can architect the system so that token provisioning flows through the APE without the APP ever touching raw card data, your scope may be materially smaller.

The architectural decision is not just a compliance question – it is a business decision with cost implications. The PCI DSS certification cost for a service provider handling stored credentials is meaningfully higher than for a merchant that simply passes tokenised data without storage.

FAQ

---

Your Next Step

The Agentic Payment Provider category is new, and most compliance frameworks have not caught up with its implications. If you are building or operating an autonomous payment platform and have not yet determined your PCI DSS scope as an APP or APE under the April 2026 Visa Rules, the time to act is now – before your next certification cycle.

Patronusec supports payment platforms, fintechs, and AI-commerce companies across Europe with:

• PCI DSS certification and ROC – as an accredited QSA
• PCI DSS gap analysis – scope mapping and pre-audit readiness
• Penetration testing – aligned with PCI DSS Requirement 11
• vCISO on demand – for teams navigating classification and scoping without in-house bandwidth