Updated: 8th April 2026
What are agentic payments? Agentic payments are financial transactions initiated and executed autonomously by AI agents – without any human involvement at the point of authorisation. The agent independently identifies a purchase need, selects a supplier, authenticates cryptographically and finalises the payment, all within a single programmatic flow. Visa defined the infrastructure for this model in March 2026, publishing the card specification for the Machine Payments Protocol (MPP) and a dedicated SDK – transforming agentic payments from a concept into a production payment standard.
Agentic payments and Visa MPP – in brief:
- On 18 March 2026, Visa published the full card specification for MPP (Machine Payments Protocol), developed jointly with Stripe and Tempo
- An AI agent pays without a browser and without a checkout redirect – the payment is part of the same HTTP request as the resource order
- Visa Intelligent Commerce provides agent-specific tokens, passkeys, payment instruction controls and duplicate transaction protection
- Trusted Agent Protocol (TAP) allows merchants to cryptographically verify that a request originates from a Visa-approved agent – not a bot
- Card credential encryption is handled via JWE (RSA-OAEP-256 + AES-256-GCM) – the actual token number is never visible to the agent
- Billing data (name, address, PAR) is transmitted as PII protected solely by TLS – this is one of the key compliance risks (GDPR, PCI DSS)
- Companies accepting payments from AI agents must update their PCI DSS scope, AML policies and transaction authorisation mechanisms
Why Do Agentic Payments Change the Risk Model for Your Business?
Traditional payment systems assumed that a human authorises every transaction – via a click, PIN or biometric. Agentic payments eliminate that control point. The agent receives a general instruction from the user (e.g. “manage my cloud subscription”) and then independently executes dozens or hundreds of micro-transactions: paying for API calls, purchasing compute time, activating B2B services – all without asking the cardholder again.
For CEOs, this means new revenue models and automation of operational costs. For CISOs, it means a new class of risk: transactions initiated by software that does not pass through traditional fraud and compliance control points.
According to estimates by Juniper Research, the autonomous AI agent payments market will exceed USD 50 billion by 2028. Visa’s infrastructure – already available via the Visa Acceptance Platform – means this market is not a future scenario: it has been available in production since Q1 2026.
How Does the Machine Payments Protocol (MPP) and the Visa Card Specification Work?
MPP is an open machine payments standard announced by Stripe and Tempo, extended by Visa to support card payments. The transaction flow works as follows:
- The agent requests a resource – for example, it calls the API of a paid data provider
- The server responds with HTTP 402 (Payment Required) along with challenge parameters: amount, currency, list of accepted card networks, RSA encryption key
- The agent passes the challenge to a Client Enabler – a specialised component (PSP, vault provider) that provisions a network token
- The Client Enabler encrypts the token using JWE with the server’s RSA public key (RSA-OAEP-256 + AES-256-GCM) – the agent never sees the decrypted card material
- The agent repeats the request with an
Authorization: Paymentheader containing the encrypted credential - The server (Server Enabler) decrypts the token using its RSA private key and submits the authorisation to the card network
- The card network (VisaNet) verifies the authorisation and enforces controls previously set via Visa Intelligent Commerce
- The agent receives the resource and payment confirmation – with no user interface and no redirect
In practice, this means: the entire payment cycle – from request to confirmation – takes place within a single programmatic flow, in milliseconds, with no human involvement.
What Are Visa Intelligent Commerce and Trusted Agent Protocol – and Why Do They Matter to CISOs?
Visa has built two layers of security infrastructure specifically for agent payments:
Visa Intelligent Commerce (VIC) is a platform for managing the full lifecycle of agent payments. It offers five integrated services:
- Tokenisation – agent-specific pass-through token; one token per agent, not per card, which minimises the risk of card data exposure
- Authentication – step-up verification of the cardholder during agent onboarding, with a Passkey set for future payment instructions
- Payment instructions – controls whether token requests match the user’s original instruction; VisaNet enforces these controls at the network level
- Signals – a log of every authorisation alongside the original user instruction – the basis for rapid dispute resolution
- Personalisation – optional agent access to the user’s transaction data (with consent) for improved recommendation accuracy
Trusted Agent Protocol (TAP) addresses a problem that is critical for every CISO: how to distinguish a legitimate AI agent from a malicious bot. TAP implements a cryptographic message signature standard (RFC 9421). Every Visa-approved agent attaches a cryptographic signature to every HTTP request. The merchant verifies the signature using the agent’s public key – if verification fails, the request is rejected. Without TAP, a merchant has no technical means of distinguishing an authorised agent from a criminal’s script.
In practice, this means: before implementing support for agent payments, your security team must implement server-side TAP signature verification – otherwise you are opening your API to unauthorised traffic.
What Regulatory and Compliance Risks Do Agentic Payments Create?
This is an area where CEOs and CISOs must work together – because the risks are both strategic and operational.
PCI DSS – scope expansion
Any system accepting card data in agent environments falls within PCI DSS scope. The Visa MPP specification transmits some data (cardholder name, billing address, Payment Account Reference) as plaintext protected solely by TLS. The specification explicitly states that this data constitutes PII and must be handled in accordance with privacy regulations. If your system logs this data – even for debugging purposes – you are in breach of PCI DSS requirements on minimum data storage scope and risk non-compliance with GDPR.
Payment Account Reference (PAR) deserves particular attention: it is a persistent identifier that correlates a cardholder across merchants and channels. The Visa MPP specification mandates that PAR be treated with the same care as billing data and prohibits its use for cross-merchant tracking beyond your own direct business relationship with the customer.
GDPR and data minimisation
An AI agent that continuously collects the user’s transaction data (a built-in feature of VIC personalisation) is a data processor within the meaning of GDPR. Your organisation – if it operates agents or accepts payments from agents – must have documented legal bases for processing, mechanisms for fulfilling data subject rights and appropriate data processing agreements.
AML and transaction authorisation controls
When an agent executes hundreds of micro-payments automatically, traditional AML transaction monitoring mechanisms may fail to detect anomalies – because each individual transaction falls within the limit. Under AMLD V and AMLD VI, your compliance team must update monitoring models to account for the agent transaction profile: high frequency, low amounts, programmatic origin.
Liability for unauthorised transactions
The MPP specification does not explicitly address liability for transactions initiated by an agent that has exceeded the scope of its instruction. This is a legal gap that every organisation must fill contractually – both with agent providers and with its own customers.
| Risk area | Regulation | Required action |
|---|---|---|
| Card data in logs | PCI DSS 4.0 Req. 3 | Log audit, masking of PAR and billing data |
| Agent transaction data | GDPR Art. 6, 28 | Legal basis, DPA with agent provider |
| AML transaction monitoring | AMLD V/VI | Update monitoring models for agent profile |
| Agent verification | TAP / internal policy | Implement TAP or equivalent on the merchant side |
| Liability for misuse | Contract law | Contractual clauses with agent providers |
| Replay protection | MPP specification | Enforce idempotency key (challenge.id) |
What Does the Technical Security of the Visa MPP Card Specification Look Like?
For CISOs, it is important to understand what the specification guarantees technically – and where the limits of that guarantee lie.
What the specification secures:
- The card token is never visible to the agent or the merchant’s server in plaintext – it is encrypted by the Client Enabler using the server’s RSA public key, and decryption is possible only by the Server Enabler holding the private key
- Every transaction uses a one-time cryptogram (dynamicData), eliminating the risk of a replay attack at the token level
- The Challenge ID serves as an idempotency key – the same challenge cannot be used twice to debit funds
- The challenge has a built-in expiry time (expires) and must contain a minimum of 128 bits of entropy
- Transport must use at least TLS 1.2 (TLS 1.3 recommended)
Where the limits of the guarantee lie:
- Security of billing data (address, name, PAR) relies solely on TLS – if TLS is compromised, that data is in plaintext
- The specification does not define how a merchant should manage RSA key rotation – this falls to the Server Enabler
- TAP is an optional extension within MPP – the merchant must decide independently whether to require signatures from agents
- VIC personalisation requires the agent to access the user’s transaction data – each such permission must be explicitly accepted by the cardholder
Cryptographic requirements your infrastructure must meet:
- RSA key: minimum 2,048 bits (2,048 or 4,096 bits recommended)
- Encryption algorithm: RSA-OAEP-256
- Content encryption algorithm: AES-256-GCM
- Not permitted: PKCS#1 v1.5 padding, direct RSA encryption
What Should CEOs and CISOs Do Now – 5 Concrete Steps
Visa’s infrastructure for agent payments is available in production. Companies that do not prepare their processes, compliance frameworks and security architecture will find themselves in a reactive rather than a strategic position.
- Assess whether your organisation is a merchant, PSP or agent provider – each role carries a different scope of technical and regulatory responsibility within the MPP ecosystem
- Conduct a PCI DSS gap analysis against the new transaction model – particularly in the areas of billing data logging and RSA key management
- Implement or require implementation of TAP – without cryptographic verification of agent identity, you risk authorising traffic from unauthorised sources
- Update your GDPR documentation – define the legal basis for processing transaction data generated by agents acting on behalf of your customers
- Review your AML monitoring models – automated agent traffic may bypass alert thresholds configured for human transactions
FAQ
How does an agentic payment differ from a standard e-commerce payment?
In a standard e-commerce payment, a human actively authorises every transaction – clicking a button, entering a 3DS code or confirming via biometric. In an agentic payment, authorisation happens once – during the setup of the payment instruction and the onboarding of the agent. The agent then executes an unlimited number of transactions independently, within defined parameters (merchant, amount, purpose). This represents a fundamental shift in the model of responsibility and risk.
Does Visa MPP require changes to contracts with an acquirer or PSP?
In most cases, yes. The MPP specification defines new roles (Client Enabler, Server Enabler) and new tokenisation flows that may not be covered by existing PSP agreements. CISOs and legal teams should verify whether their processor supports Visa Intelligent Commerce agent-specific tokens and whether the contract addresses liability for agent transactions.
How does Trusted Agent Protocol protect against malicious agents or bots?
TAP requires every Visa-approved agent to cryptographically sign every HTTP request (standard RFC 9421). The merchant verifies the signature using the agent’s public key, retrieved from the Visa registry. An agent without a valid signature or with a signature that does not match the request parameters is rejected. This protects against bots, scrapers and malicious agents that have not gone through the Visa approval process.
What is a Payment Account Reference (PAR) and why is it sensitive?
PAR is a persistent identifier assigned to a physical card that remains constant regardless of tokenisation. It allows a cardholder to be correlated across different merchants and channels – without requiring access to the actual card number. From a GDPR perspective, PAR constitutes data that enables identification of a natural person and must be treated as PII. The Visa MPP specification prohibits the use of PAR for cross-merchant tracking beyond your own direct business relationship with the customer.
Is the Visa agentic payments platform subject to PCI DSS?
Yes. Any system that processes, stores or transmits card data – including network tokens and billing data – falls within PCI DSS scope. Implementing MPP support may expand the Cardholder Data Environment (CDE) to include new components: the Client Enabler, Server Enabler and RSA key management systems. Organisations should conduct a PCI DSS gap analysis before going live, and in the case of Level 1 – update the scope of their ROC.
Can AI agents process payments in currencies other than USD?
Yes. The MPP specification supports the ISO 4217 currency standard (the currency field in the challenge), which means support for USD, EUR, PLN and other currencies. However, the merchant and PSP must hold the appropriate acquirer permissions to accept payments in a given currency – MPP does not alter the currency rules of the card networks.
Agentic payments and AI payment security – free consultation
Patronusec supports financial, fintech and retail organisations in assessing compliance with PCI DSS, GDPR and AML regulations in the context of new payment models – including agent payments. If you are planning to implement MPP support or wish to assess compliance risks before making a strategic decision, book a short, no-obligation call with our team.
