Analysis
Source-backed evidence, implications, and what this development means for autonomous agents and API commerce.
Alt text · M2M Market editorial illustration for Visa–Revolut passkey pilot: a real‑world test of agent authorization on card rails (Sept 7, 2026), showing interconnected AI agents and API services exchanging information.
Open original source ↗What happened (source facts)
Visa and Revolut ran a controlled pilot in France in which Visa’s test agent “My Agent” completed a live merchant checkout using a consumer Revolut card, authenticated with Visa Payment Passkey. Visa described the test as a demonstration of how an AI assistant can finalise a purchase while relying on existing payment protections (tokenisation, issuer controls, fraud monitoring). (visa.fr)
Independent trade coverage and participant statements confirm the merchant used for the exercise was Cleverbridge and that the transaction was executed under Visa’s Agentic Ready programme. Reporting frames the pilot as an experiment to show how existing card infrastructure and strong customer authentication can be applied to agent‑initiated flows. (thepaypers.com)
Moona Intelligence’s evidence review of the exercise notes this was a controlled pilot with customer authority set in advance and that issuer decisioning (Revolut) remained part of the flow rather than being replaced by a new, external authority layer. (moona.ozlunara.com)
Which architectural layer this development addresses
The pilot primarily demonstrates a solution at the authorization and authentication layer of agentic commerce:
- Authentication: Visa Payment Passkey was used to bind a human’s credential to the agent’s delegated authority at enrolment or mandate time, providing a strong cryptographic authentication signal for the transaction. (visa.fr)
- Authorization evidence & issuer control: the experiment preserved issuer decisioning and used the existing card network settlement path, showing how merchant‑facing authorisations and issuer checks can remain the enforcement point for agentic purchases. Moona’s analysis highlights that issuer authorization and retained controls were not displaced by the pilot. (moona.ozlunara.com)
This is not primarily a new payment transport innovation (it reused card rails and existing tokenisation); instead it shows how delegated agent authority can be expressed and cryptographically bound into an otherwise conventional payment flow. (visa.fr)
What this means for API marketplaces (discovery, controlled consumption, settlement)
Source facts above show a pragmatic path where agents can trigger purchases while issuers and card networks retain risk controls. For an API marketplace that mediates agent consumption and settlement, the pilot implies concrete requirements:
- Authorization metadata and receipts — Marketplaces should capture and preserve machine‑readable mandate metadata (who delegated, scope, limits, expiry) and cryptographic evidence (passkey attestations, signed action receipts) so provider services and issuers can verify delegated authority at call time. (The pilot used passkey attestation as the authentication primitive.) (visa.fr)
- Audit trails and dispute artifacts — Because issuer decisioning remains central, marketplaces should log the full authorization chain and produce tamper‑resistant receipts that can be passed to issuers, merchants, or regulators during dispute resolution. (moona.ozlunara.com)
- Integration with issuer/payment controls — Rather than replacing card rails, the practical path shown by the pilot is coexistence: marketplaces should design flows that surface authorization constraints to agents and merchant providers while preserving issuer controls in the settlement path. (thepaypers.com)
- Discovery and policy signals — Marketplaces that publish agent‑payable services should include clear payment acceptance and mandate requirements (what authentication attestation is required, allowed settlement instruments, refund/dispute policies) so agents can decide and prepare the right authorization objects before invoking paid APIs.
Recommended near‑term actions for marketplace operators
- Require and store mandate metadata with cryptographic bindings (e.g., passkey attestation, signed mandate tokens) for any agent‑initiated purchase routed through the marketplace. This preserves the audit evidence that issuers and merchants will need to validate delegated authority. (visa.fr)
- Design provider onboarding checklists that document which authentication/attestation methods a provider supports (passkey, token, x402/MPP headers, card tokenisation) and expose those as machine‑consumable discovery fields so agents can programmatically match capability to requirement. (thepaypers.com)
- Log and retain cryptographic receipts and mandate metadata alongside usage records so settlement and dispute flows can reference a single source of truth for who authorized a purchase and under what constraints. (moona.ozlunara.com)
What this does not show
This experiment is a controlled pilot demonstrating how existing card infrastructure can be adapted to agent‑initiated flows; it is not evidence that a single protocol (e.g., AP2, MPP, x402, MCP) has become dominant or universally adopted. It also does not replace the need for agent‑native payment protocols or on‑chain settlement models where merchants or marketplaces prefer stablecoin or blockchain settlement methods. The pilot illustrates an authorization pattern and a migration path for marketplaces that need to work with today’s payment rails. (visa.fr)
Sources
Primary and corroborating sources include Visa’s France press release describing the pilot, participant statements from Cleverbridge, and independent analysis/validation from trade reporting and intelligence summaries. (visa.fr)