WHEN AI GETS A WALLET: INSIDE GOOGLE’S AP2, COINBASE’S x402 AND THE NEW TRUST LAYER FOR AGENTIC COMMERCE
Updated: 11 hours ago
Artificial intelligence has spent the past several years learning how to answer questions, write software, analyze documents and navigate the internet.
The next transition is considerably more consequential.
AI is learning how to spend money.
That seemingly small change transforms an AI agent from an information system into something closer to an economic actor: software capable of discovering a product, negotiating with another system, selecting a supplier, obtaining payment credentials, authorizing a transaction and potentially completing the purchase without its human operator being present.
That future creates a problem that has little to do with whether an AI model is intelligent enough to shop.
The problem is proving that it was actually allowed to.
Google’s Agent Payments Protocol, or AP2, is an attempt to build that missing trust layer.
First announced by Google on September 16, 2025, AP2 was developed with participation from more than 60 payments and technology organizations, including Coinbase, Mastercard, American Express, Adyen, PayPal, Worldpay, Revolut, Intuit, Salesforce, ServiceNow, Ant International and others.
Google positioned it as an open framework through which AI agents, merchants and payment providers could establish who authorized a transaction, exactly what was authorized and what evidence should exist if something later goes wrong.
The Coinbase relationship is particularly important, but it is more specific than describing AP2 simply as a Google–Coinbase project.
Coinbase provides one of the most consequential pieces of the emerging infrastructure: x402, an internet-native payment protocol designed to allow software and AI agents to pay for digital resources directly over HTTP, including through stablecoins.
Together, AP2 and x402 point toward an internet in which software does not merely exchange information.
It can exchange value.
And that distinction could eventually change how online commerce works.
THE PAYMENT PROBLEM AI CREATES
Most modern payment systems were designed around a simple assumption:
Somewhere in the transaction, a human is pressing the button.
A customer visits Amazon, enters a card, confirms a purchase and clicks “Place Order.”
A business employee approves an invoice.
A traveler selects a hotel and presses “Book.”
Even when much of the underlying processing is automated, the payment industry generally has a recognizable point at which a person indicates consent.
Agentic commerce weakens that assumption.
Imagine telling an AI assistant:
“Buy two tickets for the Knicks game next month. Lower bowl only. Spend no more than $500 total. Buy them whenever you find the best price.”
The user may close the application immediately afterward.
Three days later the agent finds qualifying tickets.
Who proves the user actually issued those instructions?
How does the ticket seller know the agent did not misunderstand them?
How does the card issuer determine whether the resulting charge was authorized?
What happens if the agent purchases tickets for the wrong date?
What happens if malicious instructions injected into a website cause the agent to buy something else?
And if the transaction is disputed, what evidence can the merchant, bank, user and agent provider inspect?
Google describes the fundamental problems as authorization, authenticity and accountability.
AP2 attempts to turn those abstract questions into machine-verifiable evidence.
That is the significance of the protocol.
AP2 IS NOT A NEW PAYMENT NETWORK
It is important to understand what AP2 is not.
Google is not attempting to replace Visa, Mastercard, bank transfers or blockchains with a proprietary Google payment network.
AP2 is designed to be payment-method agnostic.
A transaction could ultimately travel across a traditional credit-card network, a real-time banking system, a digital wallet or a stablecoin network.
What AP2 tries to standardize is the layer above the settlement rail: the evidence showing what an agent was authorized to do.
This distinction is critical.
Think of the payment itself as moving money from A to B.
AP2 attempts to answer a different question:
Why was the software entitled to move that money in the first place?
The current AP2 v0.2 specification defines several participants in that process, including a Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor and Trusted Surface.
The Shopping Agent performs the purchasing task.
The Credential Provider controls access to the user's payment credentials.
The Merchant supplies the goods or services.
The Merchant Payment Processor executes or facilitates the payment.
And the Trusted Surface is the environment in which the human grants authenticated consent.
A single company could perform several of these roles, but AP2 deliberately describes them separately because the protocol must work when different companies control each piece.
That is what interoperability actually means here.
Google does not need to control the merchant.
The merchant does not need to control the AI model.
The AI developer does not need to become a bank.
And the payment processor does not need to trust the language model's word that “the customer told me to do this.”
Each participant instead receives cryptographically verifiable evidence appropriate to its role.
THE MOST IMPORTANT IDEA IN AP2: MANDATES
The central concept in AP2 is something Google calls a Mandate.
A Mandate is effectively a cryptographically verifiable record describing what authority a user has given an agent.
Instead of trusting the AI's interpretation of a conversation, downstream systems can inspect signed evidence of the user's authorization.
Google's original AP2 announcement described this through Intent Mandates and Cart Mandates.
An Intent Mandate can represent broader instructions such as:
“Buy a green version of this jacket if it becomes available for less than $250 before Friday.”
A Cart Mandate can represent approval of the actual transaction:
“Purchase this specific jacket, from this merchant, at this price.”
The protocol has continued evolving. AP2 v0.2's formal specification focuses on linked Checkout Mandates and Payment Mandates, while the SDK and supporting material continue to expose concepts including Intent, Cart and Payment Mandates.
The essential architecture remains the same: authorization is converted from natural-language intent into signed, machine-verifiable objects that can be inspected by other participants in the transaction.
This solves one of the most dangerous problems in agentic commerce.
An AI model can misunderstand language.
Cryptographic verification does not.
The AP2 specification explicitly states that validation and processing required of participating roles must occur in deterministic code, whether or not the broader system is agentic.
That requirement is easy to overlook, but extraordinarily important.
It means an issuer should not be asking another generative AI model whether a purchase “seems consistent” with the customer's wishes.
The rules controlling authorization must ultimately resolve to deterministic verification.
The model can reason.
The security layer must prove.
FROM “BUY THIS” TO A CRYPTOGRAPHIC AUDIT TRAIL
Consider a conventional agent-assisted purchase.
A user asks an agent to find a laptop.
The agent searches merchants, compares products and builds a checkout.
The merchant cryptographically signs information describing the checkout.
The user authorizes the purchase through a trusted interface.
That authorization becomes linked to the exact transaction the merchant presented.
A Payment Mandate can then provide the credential provider, payment network and merchant processor with evidence that the agent has authority to use the selected payment method for that checkout.
The current AP2 specification binds payment authorization to a particular checkout using cryptographic hashes and signed transaction objects. It also calls for signed receipts to be returned after mandates are accepted or rejected.
The result is something ordinary conversational AI does not provide:
a chain of evidence.
User instruction.
Agent action.
Merchant offer.
Purchase authorization.
Payment authorization.
Receipt.
If something goes wrong, those records can potentially be examined during a dispute.
This is why AP2 may matter more as an accountability protocol than as a payment protocol.
HUMAN PRESENT VERSUS HUMAN NOT PRESENT
The more difficult use case is not an AI helping someone check out.
It is an AI checking out when nobody is there.
Google calls this a Human Not Present transaction.
Imagine telling an agent:
“Buy a PlayStation the next time the price falls below $400.”
Or:
“Book a nonstop flight to Miami if you find one leaving Friday after 5 p.m. and returning Sunday for less than $450.”
Or:
“Renew this cloud-computing capacity automatically as long as our monthly infrastructure bill remains below $20,000.”
These instructions can exist hours, days or weeks before the actual transaction.
AP2 therefore needs a durable representation of delegated authority.
The important shift is from approving a transaction to approving constraints.
Maximum price.
Eligible merchants.
Product parameters.
Expiration dates.
Refund requirements.
Timing conditions.
Other boundaries can potentially be encoded as well.
The agent can then search within those boundaries without repeatedly returning to the user for permission.
In April 2026, Google released AP2 v0.2 with additional support for Human Not Present transactions, explicitly describing scenarios in which an agent can execute a transaction from previously authorized instructions while the user is absent.
That is the point at which an AI agent becomes substantially more economically powerful.
It can wait.
It can monitor.
It can negotiate.
And, within predefined limits, it can act.
COINBASE'S ROLE: x402
This is where Coinbase enters the picture.
AP2 establishes authorization and trust.
x402 provides a mechanism through which machines can actually pay.
Coinbase introduced x402 in May 2025 as an open payment protocol built around one of the internet's long-unused HTTP status codes: 402 Payment Required.
The HTTP specification has carried the 402 code for decades, but the web never developed a universally adopted payment system around it.
Coinbase is attempting to change that.
In an x402 transaction, software requests a digital resource from a server.
The resource might be an API response, dataset, AI inference request, computational job or another digital service.
Instead of requiring an account, subscription or conventional checkout flow, the server can respond that payment is required and specify payment instructions.
The client signs a payment authorization.
The request is submitted again with the payment data.
A facilitator can verify and settle the transaction.
Once payment succeeds, the resource is delivered.
That architecture is unusually well suited to software.
An agent does not want to open a browser, type a card number, receive an SMS code and click through four checkout pages every time it needs $0.03 worth of data.
It needs a machine-readable price.
A machine-readable payment request.
A cryptographic signing process.
And a machine-readable receipt.
x402 is designed around that idea.
WHY STABLECOINS FIT THE MACHINE ECONOMY
Stablecoins become especially interesting in this environment because they behave more like programmable internet assets than conventional consumer payment instruments.
They can move around the clock.
Wallets can interact with them programmatically.
Transactions can be initiated without displaying conventional card credentials to every merchant.
And very small transactions can become economically practical.
Coinbase argues that this makes x402 appropriate for applications such as API access, data retrieval, AI inference, automated services and micropayments.
Imagine an AI research agent working on an investment report.
It discovers a specialized database containing a dataset it needs.
Access costs $0.07.
Instead of creating an account, subscribing to a $49 monthly plan and entering billing information, the agent receives a 402 payment request.
It determines that the data falls within the user's authorized research budget.
It signs a payment.
Seven cents of stablecoin moves.
The API responds.
The agent continues its research.
That is a fundamentally different commercial architecture.
And it becomes even more interesting when the buyer and seller are both software agents.
One AI agent could purchase an inference from another.
A logistics agent could purchase routing information.
A trading system could purchase a specialized dataset.
A software-development agent could pay another service to run a security audit.
A compute agent could purchase additional processing capacity.
Commerce becomes composable.
Software begins buying services from software.
HOW x402 ACTUALLY SETTLES THE PAYMENT
Coinbase's x402 infrastructure adds another important component: the facilitator.
Instead of requiring every merchant or API developer to operate blockchain infrastructure themselves, a facilitator can verify and settle transactions.
Coinbase's current Developer Platform exposes separate x402 verification and settlement endpoints.
Verification checks whether the proposed payment satisfies the requirements.
Settlement completes the transfer.
Coinbase's x402 infrastructure has expanded beyond the original implementation and currently describes support across networks including Base, Polygon, Arbitrum, World and Solana, with mechanisms supporting USDC, EURC and a broader set of ERC-20 assets depending on the payment scheme.
This distinction between AP2 and x402 is essential.
AP2 answers:
“Was this agent authorized to make this purchase?”
x402 answers:
“How can software pay another piece of software over the internet?”
Those are complementary problems.
THE STACK: MCP, A2A, UCP, AP2 AND x402
The rapidly emerging agent economy is beginning to resemble a protocol stack.
At the bottom are the systems that move data and money.
Above them are increasingly specialized protocols governing how agents interact.
Model Context Protocol, or MCP, primarily addresses how AI systems connect to tools, applications and data sources.
Agent2Agent, or A2A, addresses communication and coordination between agents.
Universal Commerce Protocol, or UCP, standardizes commerce interactions such as capabilities, checkout and orders between platforms and businesses.
AP2 supplies authorization, delegation and payment evidence.
x402 can provide internet-native settlement for digital or onchain transactions.
The boundaries are not perfectly rigid, and these technologies are still evolving, but the architecture is beginning to look something like this:
An agent discovers a service.
A2A or another communication layer allows agents to interact.
UCP or merchant infrastructure describes the commerce process.
AP2 proves the user's authority and establishes transaction evidence.
x402 or another payment rail moves the money.
That modularity is important.
The future of agentic commerce is unlikely to be one company owning everything.
It is more likely to resemble the internet itself: different systems agreeing on enough common protocols to communicate.
THE LOWE'S EXAMPLE
Coinbase and Google demonstrated the concept through a prototype created for Lowe's Innovation Lab.
In the example, an AI agent can interpret a customer's home-improvement request, identify products, retrieve localized inventory and pricing, assemble a cart and complete payment.
The transaction can use x402 and stablecoins for settlement rather than asking the customer to manually enter card information during checkout.
Coinbase describes the process as moving from consultation, to recommendation, to confirmation, payment and fulfillment. Some portions of the demonstration were simulated, an important qualification when evaluating how close the technology is to mass-market deployment.
The significance is not Lowe's specifically.
It is the collapsing of what are currently separate software processes.
Search.
Product recommendation.
Inventory.
Checkout.
Payment.
Shipping.
Today those functions are normally stitched together through webpages and human interaction.
Agentic commerce tries to connect them through software.
THE ECONOMIC CONSEQUENCE: THE CHECKOUT PAGE MAY BECOME AN API
For roughly three decades, internet commerce has been optimized around websites designed for human eyes.
Search results.
Product pages.
Shopping carts.
Checkout pages.
Payment forms.
The agentic model changes the interface.
A machine does not care whether the checkout button is blue.
It cares whether inventory, price, merchant terms, authorization requirements and fulfillment options can be represented in structured data.
That could gradually shift competitive advantage away from visual interfaces and toward machine-readable infrastructure.
Merchants may eventually optimize not only for Google Search or human customers, but for purchasing agents.
Product catalogs may need to be agent-readable.
Promotions may become machine-negotiable.
Inventory may need standardized discovery interfaces.
Payment terms may be expressed as structured credentials.
Receipts may become cryptographically verifiable objects.
This is one reason AP2 should not be viewed simply as a payments experiment.
It sits inside a much larger attempt to redesign commerce for software intermediaries.
FROM CUSTOMER TO POLICY MAKER
There is also a deeper behavioral change.
When humans shop directly, they make individual transaction decisions.
When agents shop for humans, users increasingly define policies.
“Never spend more than $100 without asking me.”
“Only buy refundable hotels.”
“Prefer American Airlines unless another nonstop flight is at least $150 cheaper.”
“Reorder this product when fewer than two remain.”
“Keep monthly software spending below $3,000.”
“Never purchase from merchants outside the United States.”
Instead of deciding every transaction, the user defines a rule set.
The agent operates inside it.
In that world, the quality of the delegation system becomes as important as the intelligence of the model.
The best AI agent is not merely the one that identifies the optimal purchase.
It is the one that can prove it stayed inside its authority.
THE SECURITY PROBLEM DOES NOT DISAPPEAR
AP2 does not make autonomous payments risk-free.
It changes the security architecture.
If anything, agents create new attack surfaces.
A malicious website may attempt prompt injection.
A compromised agent could manipulate purchase instructions.
A fraudulent merchant could attempt to misrepresent transaction data.
An attacker might attempt to replay an old payment authorization.
Wallet credentials could be targeted.
Delegated purchasing policies could be excessively broad.
An agent might satisfy the literal requirements of a mandate while violating what the user subjectively intended.
The x402 A2A specification acknowledges several of these risks directly. Among other requirements, it states that private keys should remain with trusted components rather than being exposed directly to the language model, that payment signatures must be cryptographically verified and that implementations need replay protection and secure transport.
That architecture reflects one of the most important principles for financial AI:
The language model should not be the security boundary.
An AI model can decide that a payment should occur.
A deterministic security system should decide whether it is permitted to occur.
COMPLIANCE STILL EXISTS
Stablecoins do not eliminate financial regulation either.
Machine payments remain subject to compliance obligations.
Coinbase, for example, describes Know Your Transaction screening in its hosted x402 facilitator and has implemented controls intended to prevent payments involving sanctioned or other high-risk addresses.
That highlights an important reality about the supposedly autonomous machine economy.
The future may be highly automated.
It will not necessarily be permissionless.
Banks, wallet providers, stablecoin issuers, payment processors, identity providers and regulators are likely to remain involved.
What changes is the interface between them.
Instead of humans manually navigating those institutions, software may increasingly interact with them programmatically.
THE DISPUTE QUESTION MAY BE THE MOST IMPORTANT ONE
Consider a customer who receives a $1,200 charge generated by an AI agent and claims:
“I never authorized this.”
Today's payment industry has established procedures for fraud claims and chargebacks.
Agentic commerce introduces another evidentiary layer.
What exactly did the user tell the agent?
Was the instruction altered?
What limits existed?
Which merchant offer did the agent accept?
Was the amount within the permitted range?
Did the user approve a specific cart?
Which credential authorized payment?
Was a human present?
Which agent initiated the transaction?
Was the authorization expired?
AP2's mandate architecture attempts to create cryptographic evidence around these questions.
This may ultimately be one of its greatest contributions.
Autonomous payments cannot scale merely because agents are technically capable of spending money.
They scale only when banks, merchants, consumers and regulators have a credible answer for what happens when something goes wrong.
FROM GOOGLE PROTOCOL TO INDUSTRY STANDARD
Another major development occurred on April 28, 2026.
Google donated AP2 to the FIDO Alliance, the industry organization best known for its work on authentication technologies such as passkeys.
At the same time, Google released AP2 v0.2.
The move is significant because it attempts to move AP2 away from being perceived as a Google-controlled payment framework and toward a broader standards process.
FIDO has since organized work around agentic authentication and payments.
Its Agentic Authentication Technical Working Group is examining how users can securely delegate authority to AI agents without simply giving those agents unrestricted access to human credentials.
Its Payments Technical Working Group is developing specifications for agent-initiated commerce using contributions including Google's AP2 and Mastercard's Verifiable Intent framework.
That also means AP2 should not be described as a finished universal standard.
As of 2026, the standardization process is still developing.
That distinction matters.
AP2 has code, documentation, SDKs, sample flows and a public specification.
But widespread adoption across merchants, banks, networks, wallets and AI platforms is a much larger task.
Protocols become powerful only when enough counterparties agree to speak them.
WHY COINBASE MATTERS
Coinbase's involvement represents more than simply adding cryptocurrency support.
It provides a glimpse of what payments designed specifically for machines could look like.
Traditional payment systems grew around people, bank accounts, plastic cards and merchant terminals.
x402 begins from a different assumption:
The buyer may be software.
The seller may be software.
The product may be an API response.
The transaction may cost fractions of a dollar.
The interaction may last milliseconds.
Nobody may ever see a checkout screen.
Stablecoins fit naturally into that environment because they are digital bearer-like assets running on programmable networks.
This does not guarantee that stablecoins will dominate agentic commerce.
AP2 is intentionally designed to accommodate cards, bank transfers and other payment methods.
But machine-to-machine commerce exposes several weaknesses of traditional payment architecture, particularly for tiny, global, programmatic transactions.
That creates an opening for stablecoins that is considerably broader than crypto trading.
The largest stablecoin use case of the future may not involve humans sending dollars to one another.
It may involve software paying software.
THE QUOTE THAT NEEDS CORRECT ATTRIBUTION
One widely circulated quotation associated with the AP2 announcement reads:
“Our goal is to unlock instantaneous, global commerce, giving agent builders the greatest flexibility.”
That statement was not from Coinbase.
It came from Alfonso Gomez, co-founder of Crossmint, another AP2 participant.
Coinbase's Erik Reppel offered a different assessment, arguing that the integration of x402 into AP2 indicates that agent-to-agent payments are moving beyond experimentation and toward infrastructure developers can actually build around.
The distinction is small but worth preserving.
AP2 represents a broad industry coalition.
Coinbase is one particularly important participant because x402 supplies a crypto-native settlement layer.
THE BIGGER PICTURE
For decades, software has been able to communicate instantly across the internet while moving money remained comparatively cumbersome.
An application could transmit a billion bytes across the world in seconds but might still need a credit-card form, billing account, invoice or banking relationship to transfer one dollar.
AI agents make that mismatch harder to ignore.
Software capable of independently researching, negotiating and acting eventually requires financial infrastructure capable of operating at similar speed.
AP2 is an attempt to establish the trust model.
x402 is an attempt to establish a machine-native payment mechanism.
Stablecoins offer one potential settlement asset.
A2A allows agents to communicate.
MCP connects models to tools.
UCP increasingly describes the underlying commerce objects and processes.
Together, these systems are beginning to resemble the early pieces of an economic operating system designed not only for humans using computers, but for computers acting for humans.
The important question, therefore, is not whether ChatGPT, Gemini or another assistant will eventually be able to buy something.
That is almost certainly the easy part.
The much harder problem is building the infrastructure that allows millions of autonomous software systems to exchange money without destroying the trust assumptions that modern commerce depends on.
Who authorized the transaction?
What exactly did they authorize?
How much authority did they delegate?
Which agent acted?
Which merchant responded?
Which payment credential was used?
Can every participant verify the evidence?
And when something goes wrong, who is responsible?
AP2 is Google's—and increasingly the wider payments industry's—attempt to answer those questions before autonomous agents begin answering them for us.
That may be the real significance of the protocol.
AI is not simply acquiring better tools.
It is acquiring economic agency.
And once software can independently discover, negotiate, authorize and settle transactions, the architecture of the internet begins to change with it.
Comments