Agentic Payments Explained: How AI Agents Pay and What Fintech Engineers Must Build
EPixelSoft Team
|
30 Sep 2026
|
6 Min Read
Share
Agentic payments are card or bank transactions an AI agent initiates for a user, and they work by answering three questions: who the agent is, what it may spend, and whether a human approved it. Fintech engineering teams implement this with signed HTTP requests for agent identity, scoped tokens such as Stripe's Shared Payment Token, and signed consent records such as Google's AP2 mandates. Visa announced live agent purchases backed by more than 30 European issuers in July 2026.
A customer tells an assistant to reorder running shoes for under 120 dollars. The assistant compares merchants, picks one, and pays. There is no checkout page, no card form, and nobody at the keyboard.
That is an agentic payment, and it has moved out of the demo stage. Visa announced on July 2, 2026 that AI agents were completing live purchases at independent European merchants, backed by more than 30 issuing banks, as reported by The Industry Spread. Mastercard has reported live authenticated agent transactions in Hong Kong and Thailand. McKinsey estimates that agents could orchestrate up to 1 trillion dollars of US retail revenue by 2030, and 3 to 5 trillion dollars globally.
Getting an agent to complete a checkout is the easy part. Payment systems assume a person authorized each transaction, and every control built on that assumption has to be rethought when software does the buying. That includes strong customer authentication and dispute rules.
Why Agentic Payments Break the Assumptions Behind Card Rails
The shortcut most teams try first is giving an agent a stored card number, or letting it drive a browser and fill in forms. Both approaches fail for the same reason. The merchant cannot tell a legitimate agent from a scraper, and the issuer cannot tell whether the cardholder ever agreed to this particular purchase.
Merchants feel this first. Fintech Singapore's coverage of the Visa and Cloudflare announcement describes bot detection systems blocking valid agent activity while merchants lose sight of the consumer behind the agent. Blocking all automation protects the site and kills the sale. Allowing all of it invites fraud.
The EPixelSoft engineering team has spent 12 years building production software for organizations where the stakes are high — FinTech lenders, HealthTech platforms, international NGOs, and funded SaaS startups across the US, UK, Africa, and Asia. With 700+ systems shipped and a proprietary AI platform running in the field, the team writes from direct delivery experience: what breaks in production, what actually works, and what the vendor pitch never tells you.
Platform-owned checkout has had its own trouble. OpenAI launched Instant Checkout in ChatGPT in September 2025. In March 2026, according to Search Engine Land, an OpenAI spokesperson confirmed it was moving to apps, with purchases happening inside connected services. The discovery layer and the payment layer are separating, which makes protocols that work regardless of who owns the chat window more important.
The Three Questions Every Agent Payment Must Answer
Strip away the brand names and each agentic commerce protocol solves the same three problems. The details differ by network, which is why it helps to read them as layers rather than competing products.
Who is the agent? Visa's Trusted Agent Protocol signs each agent request using HTTP Message Signatures (RFC 9421), built on the Web Bot Auth standard. The agent operator registers a public key in a directory, and the merchant verifies each request's signature against it, as described in Visa's developer specification. Cloudflare notes that Mastercard's protocol follows the same registration model.
What may the agent spend? Instead of a card number, the agent receives a scoped token. Stripe's Shared Payment Token, used in the Agentic Commerce Protocol that Stripe built with OpenAI, is bound to a specific merchant and cart total, so the agent can initiate a payment without seeing the buyer's credentials. Mastercard Agent Pay takes a related route by extending its tokenization service, with agentic tokens that tie a buyer's intent to a specific agent and merchant.
Did the human approve it? Google's Agent Payments Protocol (AP2) records consent as three signed mandates, each a W3C Verifiable Credential: an Intent Mandate for what the user asked for, a Cart Mandate for the exact items and price, and a Payment Mandate that ties the payment method to the approved cart. For a task such as buying tickets the moment they go on sale, the user signs the intent up front and the agent generates the cart once the conditions are met, according to Google Cloud's announcement.
The layers are separate on purpose. A registered identity proves the agent exists, not that it may buy. A token limits the damage but leaves no proof of instruction. A mandate proves instruction but does nothing to stop a bad request on the network. Production systems need all three, and today they come from different vendors.
What Agentic Payments Look Like in Production
A working flow has six steps. The user sets a mandate with a spending limit and conditions. The agent requests a scoped token from the payment provider. It signs its request to the merchant with its registered key. The merchant verifies the signature and redeems the token through its payment processor. The issuer returns an authorization. The system then stores one record that ties every artifact together.
The messy part is that there is no single standard. Visa's Intelligent Commerce Connect, launched to give merchants one integration point, supports four agent protocols: Trusted Agent Protocol, Machine Payments Protocol, Agentic Commerce Protocol, and Universal Commerce Protocol. Checkout.com, according to Forkast, is backing ACP, AP2, and Mastercard Agent Pay at the same time. A platform that hard-codes one protocol will likely be reworking that code as the market settles.
The practical answer is an internal abstraction. Define your own canonical agent-payment object, covering agent identity, credential reference, consent artifact, and amount limits, then write thin adapters for each protocol. That keeps the ledger, reconciliation, and risk engine stable while the protocols change underneath. Teams automating the surrounding back-office work can connect this layer to AI workflow automation.
What It Actually Takes: Disputes, Evidence, and Protocol Gaps
Liability is the part nobody has finished. Worldpay notes that no liability shift exists yet, and that Reg E assumes a transaction was either authorized or not, with no framework for an agent that misread an instruction. On September 29, 2026, six banks published principles asking for auditable records of what the consumer instructed and what the agent did next, as reported by TechInformed. Any dispute team will ask for that evidence first.
The protocols themselves are still young. A recent arXiv analysis of the AP2 v0.2.0 reference implementation reported 14 vulnerabilities, including unenforced payee constraints and missing nonce freshness, and traced three of them to gaps in the specification itself. Reference code is a teaching aid. Treat it that way, and add replay protection and payee checks in your own layer.
We have seen the same evidence problem on lending platforms. For a US commercial lending company, we built a system where every automated decision writes an append-only record containing the model version, the inputs, the output, and a timestamp, so a compliance officer can reconstruct it years later. The pattern carries over. Each agent purchase should store the signed mandate, the token ID, the agent's key ID, the merchant, the amount, and the issuer's response in one immutable record. You can see how we approach systems like this in our case studies.
Build the Evidence Trail Before the Volume Arrives
Protocols will keep changing. Visa, Mastercard, Google, and Stripe each ship different pieces, and OpenAI's retreat from in-chat checkout shows that even the interface layer is unsettled. The requirement that stays fixed is evidentiary: for any purchase, you must be able to show who the agent was, what it was allowed to spend, and what the human approved.
Teams that store those three facts as first-class data can swap protocols underneath without losing history. Teams that do not will be reconstructing transactions from application logs when the first disputes arrive, and volume tends to arrive before the dispute rules do.
EPixelSoft is an AI-native software engineering company based in Noida, India. Since 2014, we have shipped 700+ production systems across FinTech, HealthTech, NGO operations, and SaaS.
