Agentic payments compliance guidelines – 8 Visa and Mastercard rules for processing cards with an AI agent and their PCI DSS scope impact

Updated: 16 August 2026

How do you process cards in agentic payments in line with Visa and Mastercard rules? An AI agent must never operate on the raw card number (PAN). Both card schemes permit only transactions performed by a registered agent using a network token bound to that agent’s identity – after the cardholder’s identity has been verified and on the basis of documented consent. Visa codified these obligations in the Visa Core Rules and Visa Product and Service Rules effective 18 Apr 2026; Mastercard did so through its Agent Pay programme and the Agent Pay Acceptance Framework published in Oct 2025. For any organisation building a payment agent, these rules translate into concrete architectural decisions and directly shape the scope of PCI DSS certification.

Card processing in agentic payments replaces the PAN with a network token bound to a registered AI agent, issued after cardholder identity verification and on the basis of documented consent, as required by Visa and Mastercard rules.

Agentic payments compliance guidelines – key takeaways:

1. Visa rules effective 18 Apr 2026 require every agentic transaction using stored credentials to run on a network token obtained directly from Visa or a registered Agentic Payment Enabler – submitting a raw PAN breaches scheme rules.
2. Mastercard admits only agents verified through its Know Your Agent (KYA) process; payments run on Agentic Tokens – dynamic tokens carrying agent identity, consent and spend limits, validated network-side at authorisation.
3. The PCI SSC Tokenization Guidelines (Aug 2011) state that a token capable of initiating a transaction may remain in PCI DSS scope – classification rests with the acquirer and the scheme, so the defensible assumption is to treat the token as a payment instrument.
4. The tokenisation system, and every component with access to tokenisation or de-tokenisation processes, is always in PCI DSS scope – “we use tokens” never automatically means “we are out of scope”.
5. Merchants accepting agents verify their authenticity through Web Bot Auth signatures (Mastercard) or the Trusted Agent Protocol built on RFC 9421 (Visa) – without rebuilding their existing acceptance integration.
6. Patronusec, an accredited QSA, guides agentic platforms through scheme role classification, gap analysis and PCI DSS certification – from scope assessment to the Report on Compliance (ROC).

How do Visa and Mastercard agentic payment programmes differ – Intelligent Commerce vs Agent Pay?

Visa governs agentic payments through the Agentic Payment Provider and Agentic Payment Enabler roles written into the Visa Rules from 18 Apr 2026, with tokens issued by the Visa Token Service. Mastercard builds Agent Pay on agent registration through Know Your Agent and on Agentic Tokens – MDES tokens extended with agent, consent and limit data.

The foundation of both programmes is identical: only a registered agent presenting a network token may initiate an agentic transaction – never a raw card number. The differences begin in the regulatory and technical layers.

Visa Intelligent Commerce operates through formal entity categories written into the public scheme rules. The Agentic Payment Provider (APP) executes transactions on the cardholder’s behalf, while the Agentic Payment Enabler (APE) registers APPs and intermediates token provisioning. We unpack these roles and the seven obligations attached to them in a dedicated asset on Agentic Payment Providers and Visa network tokens.

Mastercard Agent Pay puts the weight on verifying the agent itself. According to Mastercard, access to tokens requires the agent to pass Know Your Agent (KYA) – a KYC-style vetting process for software – and every Agentic Token carries metadata about the agent, the merchant scope and the permitted transaction envelope. Mastercard has stated that all US Mastercard cardholders were enabled for Agent Pay by mid-Nov 2025, with other markets following, and in Jun 2026 the programme was extended to machine-to-machine payments (Agent Pay for Machines).

Area	Visa Intelligent Commerce	Mastercard Agent Pay
Basis	Visa Core Rules and Visa Product and Service Rules, from 18 Apr 2026	Agent Pay programme + Agent Pay Acceptance Framework, Oct 2025
Agent registration	APP registered with Visa directly or via an APE	Know Your Agent (KYA) vetting before token access
Token	Visa Token Service network token bound to the agent; passing it outside the defined chain is prohibited	MDES-based Agentic Token with agent, consent and limit fields, validated at authorisation
Identity and consent	Cardholder verification per the Visa Intelligent Commerce specification, documented consent, order confirmations retained for at least 120 days	Explicit consumer consent and programmable spend limits embedded in the token
Merchant layer	Trusted Agent Protocol (RFC 9421, developed with Cloudflare)	Web Bot Auth at the CDN layer + Dynamic Token Verification Code in standard card fields

If the distinction between a network token and an agentic token is not yet second nature, start with our guide to the four token types and the differences that decide PCI DSS scope – this article assumes that groundwork.

Can an AI agent process the raw card number (PAN)?

No. Visa rules effective 18 Apr 2026 require an agentic transaction using stored credentials to run on a network token obtained directly from Visa or a registered Agentic Payment Enabler, and Mastercard admits only Agentic Tokens issued to registered agents. A raw PAN anywhere in the agent’s flow breaches the rules of both schemes.

The prohibition has two practical consequences that are easy to miss at design time.

First, the token distribution chain is closed. Visa rules expressly prohibit passing the token to any entity outside the defined chain – including other APPs or APEs. Mastercard’s merchant documentation stresses that agents never handle raw credentials, and that using ordinary stored credentials instead of an Agentic Token prevents the issuer from recognising the transaction as agentic and applying the appropriate risk controls.

Second, the PAN can enter your system through the side door – a failure mode specific to LLM-based agents. A user can paste a full card number straight into the chat window even though the payment flow never asks for it. From that moment the PAN lands in prompts, inference logs, conversation memory and telemetry – components nobody designed as part of a cardholder data environment.

In the agentic model, the card number should never surface in the conversational layer at all – its only legitimate home is the token provisioning process on the scheme, wallet provider or enabler side. The agent’s architecture must enforce this technically: input filtering, masking across all logging, and periodic scanning of log repositories for PAN patterns.

Is a payment token in scope for PCI DSS?

PCI DSS does not settle this unambiguously. The PCI SSC Tokenization Guidelines state that a token capable of initiating a transaction may remain in PCI DSS scope, with final classification resting with the acquirer and the card scheme. The tokenisation system and any component with access to de-tokenisation are always in scope.

This single question routinely decides the size and cost of certification, so it is worth splitting into three layers consistent with the PCI SSC position in the Information Supplement: PCI DSS Tokenization Guidelines (Aug 2011):

1. The token as data. The guidelines state that tokens which can be used to initiate a transaction might be in scope for PCI DSS even where they cannot be used to retrieve the PAN – and that merchants should confirm classification with their acquirer or the payment brands directly. The standard does not say “always in scope”, but it clearly says “do not assume out of scope”.
2. The high-value token. The same guidelines warn that tokens serving as payment instruments (so-called high-value tokens) could be monetised or used to generate fraudulent transactions, and may therefore hold the same value to an attacker as the PAN itself. An agentic token meets that definition head-on: initiating transactions is its only function.
3. The tokenisation system. Regardless of how the token itself is classified, every component with access to the tokenisation system or the tokenisation/de-tokenisation process is in PCI DSS scope – the PCI SSC position allows no exceptions here.

The practical conclusion for agentic platforms: since the standard offers no unambiguous “out of scope” and an agentic token is by definition a payment instrument, the only defensible design assumption is to treat the token as in-scope payment data – with the access control, encryption, logging and segmentation a CDE demands. If your acquirer or the scheme later confirms a narrower classification, scope can be reduced; the reverse order ends with re-architecting the platform under audit pressure. UK and EU organisations should additionally track how scheme-level identity verification interacts with PSD2 strong customer authentication as supervisory positions on agent-initiated payments mature.

Patronusec Insight: Across our PCI DSS engagements, teams building payment agents most often fall into inverted logic: they assume “token = out of scope” first and only trace where the token actually flows when the audit approaches. Meanwhile conversation memory, API response caches and prompt logs are exactly where tokens – and sometimes raw PANs pasted by users – settle for weeks. A PCI DSS gap analysis run at the flow-design stage costs a fraction of re-architecting the platform after the first scoping session with a QSA.

Building an agentic platform and unsure whether the Visa rules of 18 Apr 2026 make you an Agentic Payment Provider, an Enabler or a PCI DSS service provider?

In a free 30-minute scope assessment we will walk through your token flows and identify which validation path (SAQ or ROC) applies to your role – together with a list of the systems that will fall into scope.

Book a scope assessment with an accredited QSA

What must a company building a payment agent watch out for? 8 compliance rules

A company building a payment agent must classify its role towards the schemes, register the agent, eliminate raw PAN from every flow, provision tokens only through the authorised chain, treat tokens as payment data, verify cardholder identity and consent, retain purchase-intent data, and separate the agent runtime from the tokenisation system.

Taking each rule in turn:

1. Classify your role before you design the architecture. With Visa the question is APP, APE or both; with Mastercard it is whether you are the agent subject to KYA registration or a platform relying on a registered agent. The classification determines your PCI DSS validation path and your scheme obligations – get it wrong and every downstream design decision inherits the error.

2. Register the agent with the scheme programme. Visa requires APP registration directly or via an APE; Mastercard conditions access to Agentic Tokens on passing Know Your Agent. An unregistered agent has no lawful route to a token.

3. Eliminate raw PAN from every agent touchpoint. That covers not just the payment flow but prompts, conversation memory, inference logs, telemetry and debug dumps. Design input filtering and output masking, and scan log repositories periodically for card number patterns.

4. Provision tokens only through the authorised chain. For Visa that means provisioning directly from the Visa Token Service or via a registered APE; for Mastercard, through MDES within Agent Pay. Every intermediary outside the chain is both a scheme violation and an expansion of your audit surface.

5. Treat the token as a payment instrument in PCI DSS scope. Following the previous section’s conclusion: access control, encryption at rest and in transit, event logging and retention limits apply to tokens exactly as they do to cardholder data.

6. Verify identity and document consent. Visa requires cardholder verification per the Visa Intelligent Commerce specification (including step-up and passkey mechanisms) and retention of documented consent; Mastercard is developing a Verifiable Credential standard with the FIDO Alliance confirming amount, merchant and product details. Design the consent repository for evidentiary use from day one – it will be the first artefact examined in any dispute.

7. Retain intent data and order confirmations. Visa rules require order confirmations to remain available to the cardholder for at least 120 days from processing. Intent data (commerce signals) doubles as chargeback evidence – treat its retention and integrity as a requirement, not an option.

8. Separate the agent runtime from the tokenisation system. The language model, tool orchestrator and conversational layer should never hold direct access to the token vault. A dedicated payment service with a narrow API keeps the CDE at a predictable minimum – we cover the technique in our guide to PCI DSS scope, the CDE and segmentation.

The fix: the compliance boundary is drawn not by the agent technology itself, but by the discipline with which you control every point where a token is requested, cached or passed on.

How do agentic payments affect the scope of PCI DSS certification?

An agentic platform handling tokens on cardholders’ behalf will typically fall into PCI DSS scope as a service provider – with scope confirmation every 6 months and usually a full ROC rather than an SAQ. The CDE boundary is drawn by the systems that request, store and pass tokens, plus every connected component.

Three consequences deserve particular attention when planning certification.

The service provider path, not the merchant path. An entity executing transactions on cardholders’ behalf, or intermediating token provisioning, delivers a service that affects the security of other entities’ payment data – the defining trait of a service provider. Requirement 12.5.2.1 of PCI DSS v4.0.1 obliges service providers to confirm and document their scope at least every 6 months and after every significant change – for a fast-iterating AI platform this cadence belongs in the release process, not the audit calendar.

Security testing matched to a new attack surface. Requirement 11.4 of PCI DSS v4.0.1 covers application-layer and network-layer penetration testing, and requirement 11.4.6 obliges service providers to validate segmentation effectiveness at least every 6 months. For an agentic platform, test scope must extend to the token provisioning APIs, the consent mechanisms and the conversational layer’s resistance to token exfiltration through prompt manipulation. Patronusec delivers penetration tests combining the classic requirement 11 scope with AI integration assessment – reports prepared by an OSCP- and CREST-certified team that knows what an assessor will accept, because we act as the QSA on other engagements.

Architecture as a cost lever. The largest certification cost gap we have seen between comparable agentic platforms in our project work came not from business scale but from a single decision: whether the agent runtime held direct token access. Isolating vault interaction into a narrow, segmented service can shrink the CDE from “the entire platform” to a handful of components.

What the QSA will check – an assessor’s checklist for an agentic platform:

• Is the scheme role documented (APP/APE with Visa, KYA registration status with Mastercard) and consistent with the actual transaction flow?
• Does the data-flow diagram cover prompts, conversation memory, inference logs and telemetry – not just the payment flow?
• Is there a technical block on raw PAN entering the conversational layer, with evidence it has been tested?
• Are tokens covered by access control, encryption and logging as cardholder data would be?
• Does the consent repository meet the schemes’ evidentiary requirements (consent elements, instruction expiry date, availability on request)?
• Are order confirmations and intent data retained for at least 120 days (Visa) with integrity assured?
• Has segmentation between the agent runtime and the tokenisation system been tested within the last 6 months?
• Has PCI DSS scope been confirmed within the last 6 months (service provider) and after the most recent significant architectural change?

Patronusec Insight: The costliest scenario we observe with agentic platforms is certification bolted on after the product is built: the engineering team iterates weekly while the PCI DSS scope was signed off once, six months earlier. Every new agent tool call, new LLM vendor or new hosting region can move the CDE boundary. For teams without an internal owner of this problem, the vCISO model provides structural scope oversight – architecture change reviews for compliance impact wired into the release cycle, without the cost of a full-time hire.

What do Visa and Mastercard rules mean for merchants accepting AI agents?

Merchants do not need to rebuild their checkout. Mastercard enables agent verification through Web Bot Auth signatures at the CDN layer and acceptance of Agentic Tokens in standard card fields, while Visa provides the Trusted Agent Protocol built on RFC 9421. Merchant obligations centre on recognising registered agents and preserving evidence for disputes.

Merchant compliance guidelines for agentic payments reduce to three questions: do I recognise a registered agent, do I accept a token rather than a PAN, and can I prove purchase intent in a dispute?

Recognising the agent. Under the Agent Pay Acceptance Framework, a merchant can verify agent authenticity by implementing the emerging Web Bot Auth standard at the CDN layer – without deploying new code – after which the verified agent submits a Dynamic Token Verification Code, an agentic token formatted for standard card payment fields. On the Visa side, the Trusted Agent Protocol, built on the HTTP Message Signatures standard (RFC 9421) and developed with Cloudflare with input from Adyen, Checkout.com and Worldpay among others, lets the merchant validate the agent’s signature before serving any payment-required step.

Evidence in disputes. Agentic transactions carry additional contextual data – the user’s instruction, basket contents, limits and the consent validity window. Visa has also announced Intelligent Commerce Connect, a platform the scheme says will handle payment initiation, tokenisation, spend controls and PCI compliance through a single integration via the Visa Acceptance Platform (currently piloting, with broader rollout planned for later in 2026). A merchant that retains commerce signals and verifies agents enters disputes with a complete evidence pack – compliance translating directly into the bottom line.

Fraud rules. Agent purchasing patterns differ from human ones (timing, cadence, repeatability), so existing fraud detection rules need recalibration – otherwise the platform starts declining a legitimate and growing sales channel.

FAQ

What to read next – reading path

1. Agentic payments and Visa security – how Intelligent Commerce works – the foundations of the Visa programme mechanics.
2. Network tokens vs agentic tokens – four token types and the differences that decide PCI DSS scope – the conceptual layer of tokenisation.
3. Agentic Payment Providers and Visa network tokens – 7 PCI DSS obligations – the APP and APE roles in Visa rules in detail.
4. Verifiable intent in agentic payments – proving purchase intent in disputes.
5. PCI DSS scope, the CDE and segmentation – the scope-reduction techniques you apply when architecting an agent.

Agentic payments and PCI DSS certification – free consultation

Patronusec, an accredited QSA, works with fintechs, payment platforms and e-commerce organisations implementing agentic payments – combining the assessor’s perspective with an in-house penetration testing team.

In a free 30-minute consultation we will help you:

• classify your platform’s role under Visa and Mastercard rules (APP, APE, service provider, merchant),
• map your token flows and identify the systems that will fall into PCI DSS scope,
• choose the validation path (SAQ or ROC) and a realistic certification timeline,
• plan security testing covering the token APIs and the agent’s conversational layer.

Book a free consultation | PCI DSS certification | PCI gap analysis | Penetration tests | vCISO