What Are Agentic Payments?

Software is learning to spend money. AI agents are discovering products, negotiating prices, and completing purchases without a human ever clicking the "buy" button. This is the world of agentic payments.

Coinbase founder Brian Armstrong recently said that “Very soon there are going to be more AI agents than humans making transactions”. But our current payments infrastructure was built for humans. Agents need their own protocols.

Agentic payments are well on their way to changing the way enterprises are run. Initially a hobbyist endeavor best understood through individuals installing the open-source OpenClaw onto virtual servers or dedicated Macbook Minis, agents are now being run autonomously and customized via enterprise setups through Claude Code, Cursor, and OpenAI’s Agents SDK. Enterprises can use these technologies to make and receive payments for data they supply or request, and developers can equip coding agents with the ability to pay for premium services. In the future, agents could play a role in an operational capacity: organizing and executing payroll or making supplier decisions and making payments.

In this blog, we will break down how agentic payments work, what makes them different from traditional online payments, and the various protocols enabling agentic payments.

How Do Agentic Payments Work?

Agentic payments are financial transactions initiated, authorized, and completed by AI agents on behalf of users or other agents, without human intervention at the point of transaction. Instead of a person creating an account and entering card details, the agent pays as part of the request itself.

Today, when an AI agent needs to pay for something, it inherits the same onboarding flow a human would go through. Someone has to create an account with the provider, navigate a pricing page, choose between subscription tiers, enter payment details, and set up billing. Each step requires human intervention, and agents often struggle to complete these steps. 

Agentic payment protocols like x402 and MPP collapse this into something closer to how the web itself works. While there are a variety of protocols and some do different things, a standard example of an agentic payment protocol would be something like the following: the agent sends a request, gets a “Payment Required” response, and pays with stablecoins—no account creation, no KYC gate, no prepaid credits, no API key to manage. The service gets paid per-use at the moment of access, and the agent moves on. The practical difference is that payment stops being a setup problem that a human has to solve in advance and becomes part of the request itself.

Right now, agentic payment protocols are mainly being used to enable agents to pay for API usage on a meter-like basis. This is exciting on its own. But in the future, it’s possible we might see more ambitious use cases: a user could give an agent a shopping list and the agent could find the best options and order them autonomously. Or an agent could see travel plans in its user’s calendar and automatically take the initiative to book flights. 

In order to demonstrate the power of its agentic payments protocol (MPP), Stripe enabled agentic payments for a New York City sandwich shop, with users able to ask their agents to get them a sandwich; from here, the agent handled the rest. Very cool.

Agentic Payment Protocols

A few different protocols to enable agentic payments have sprung up. Each takes its own approach: some use stablecoin settlement, while others are geared to more traditional payment rails. These protocols are not necessarily in competition with each other; some of them cover different elements of the payment stack. While some are useful for verification, others are optimized for settlement, for example.

Let’s take a look.

x402

x402 is an open payment protocol developed by Coinbase that enables automated stablecoin payments directly over HTTP, reviving the HTTP 302 “Payment Required” status code for programmatic use.

The flow is straightforward: a client (human or AI agent) requests a resource; the server responds with 402 Payment Required and payment details; the client sends a stablecoin payment; and access is granted. No accounts, no subscriptions, no API keys. Payments settle in stablecoins.

It is best suited for API-layer payments, particularly pay-per-call infrastructure; for example, when an agent needs to pay $0.002 to run a search query, wants to access a premium data source, or needs to access any premium API. You can find a list of protocols that leverage x402 for agentic payments here and a list of those contributing to x402 here.

Machine Payments Protocol (MPP)

Co-created by Stripe and Tempo (the company’s payments-focused blockchain) and Paradigm, MPP is an open specification proposed to the IETF that embeds payments directly into HTTP requests (the 402 Payment Required request, the same as the x402 protocol). 

Any client (agent, app, or human) can pay for any service as part of the same request that calls it. The protocol is payment method-neutral: stablecoins, cards, and bank transfers in any currency can be taken through blockchains (all blockchains are technically compatible; Tempo is integrated natively), Stripe rails, or card. 

It’s composable by design, so things like disputes or identity can be layered over time without reworking the base flow. For agentic use cases, the practical upside is straightforward: an agent that needs to pay for a service doesn't have to break out of its workflow to do it. 

One feature that makes MPP stand out is batching: transactions are compiled into batches and can be checked out together in a single transaction.

AP2

Google’s AP2 is a payment-agnostic open protocol developed with more than 60 organizations, including Adyen, American Express, Coinbase, Mastercard, Paypal, and Shopify. It simply extends Google’s Agent2Agent (A2A) protocol and Anthropic’s Model Context Protocol (MCP).

AP2 is payment-method agnostic, supporting credit cards, debit cards, stablecoins, and real-time bank transfers. Its role is to provide a trust and verification layer, so that the authorization and authenticity of a payment can be confirmed, along with accountability. It operates through verifiable digital credentials (VDCs): tamper-evident, cryptographically signed digital objects that serve as the building blocks of a transaction. They are the data payloads that agents create and exchange. Once a transaction has been verified, AP2 can then be paired with protocols like x402 for onchain settlement.

ACP (Agentic Commerce Protocol)

ACP is an open-source spec developed by Stripe and OpenAI that enables programmatic commerce flows between buyers, AI agents, and businesses.

ACP works with existing payment methods. It introduces SPTs (Shared Payment Tokens), which allow AI agents to initiate payments using a buyer’s saved payment method. Each token is scoped to a specific seller, bounded by time and amount.

Visa TAP (Trusted Agent Protocol)

Visa introduced its Trusted Agent Protocol with partners including Microsoft, Shopify, Stripe, and Cloudflare. It helps merchants distinguish between malicious bots and legitimate AI agents by enabling agents to signal intent, identify the consumer behind them, and deliver payment credentials securely.

When an AI agent initiates a transaction, it presents a signed attestation that identifies the human consumer behind it and signals the nature of the request. Merchants receive structured credentials verified through Visa's trust framework, confirming that the agent is acting on behalf of a real, identified individual with valid payment credentials. This attestation travels alongside the standard card payment flow.

Why Blockchains Are a Natural Fit for Agentic Payments

Several emerging protocols accommodate traditional payment rails for agentic commerce, and that's a reasonable approach for certain use cases. But when you examine what agents actually need from a payment system, blockchains have structural advantages that traditional rails can't match.

The most fundamental issue is identity. Agents cannot open bank accounts, sign legal documents, or pass KYC checks—the entire traditional banking system is predicated on a human or registered legal entity on the other end of a transaction. But agents can hold cryptographic keys and control onchain wallets. A wallet doesn't care whether its owner is a person or a piece of software. It just needs a valid signature. With onchain wallets, you can architect the permissions from the ground up: fund a wallet with only what the agent is allowed to spend, use smart contract allowances to cap amounts or restrict recipients, or use session keys that expire after a set time or number of transactions.

Settlement speed and finality are also decisive advantages. A card payment might feel instant to a buyer, but it is not. Behind the scenes, card transactions go through authorization, clearing, and settlement; a multi-step process that typically takes 1-2 business days to reach final settlement. Blockchains collapse this entirely: on networks like Base or Solana, transactions reach finality in seconds.

Programmability is another decisive advantage. Smart contracts allow payment logic to be encoded directly into the transaction itself: spend limits, conditional releases, multi-party splits, time-bound authorizations. This is exactly what agentic workflows demand, where a transaction might depend on the completion of a prior task, the output of a model, or a price threshold being met. A developer might need to split an automated payment once premium data has been delivered, for example, triggering multiple transactions from multiple agents; this could also be voided if the data is not received in a specific time window. Each agent can also be issued with a spending limit, acting as a safety mechanism in case the agent misunderstands a request or is issued a malicious request.

On traditional rails, this kind of conditional logic requires stitching together multiple third-party integrations, each with its own API and failure modes. Onchain, logic and money live in the same environment. And every transaction is recorded on an immutable ledger; for enterprises deploying agents with spending authority, this provides a complete audit trail by default, without additional logging infrastructure or reconciliation systems.

The Transparency Problem

But while blockchains are specifically suitable for agentic payments, if they’re to serve as the backend for the agentic economy, there’s one key issue that needs to be addressed.

Every transaction on a public blockchain is visible to everyone. Balances, transfer amounts, and transaction histories are all readable by any observer. In the context of agentic payments, this creates serious problems. 

Consider an agent executing a B2B procurement workflow. On a transparent blockchain, competitors could monitor the agent's transaction patterns to reverse-engineer pricing strategies, supplier relationships, and purchasing volumes. An agent managing payroll would expose every employee's salary to anyone who looked. Even taking a step back, it’s unlikely that users and enterprises would voluntarily reveal every single API call, transaction, and account balance to the public; once agents take up more of this flow, the same principle applies.

While a range of solutions to this issue are currently in production or development for onchain privacy in general, agentic payments need a specific set of features. 

Privacy solutions for agentic payments must be fast and work at the speed of the native blockchain the agent is transacting on; those that introduce latency undermine the micropayment feature that makes some agentic payment protocols so advantageous.

Furthermore, users need to be able to see the payments their agents have been making. If transactions are encrypted and only the agent has knowledge of what has been paid for, this creates trust issues with the agent’s user. So different actors in an agentic payment flow need different visibility, and a workable privacy model needs to define these access rules clearly.

• The end user (the user deploying an agent) should always be able to see the full history of what their agent has paid for, and how much. This is a basic requirement of trust.
• Merchants and counterparties need confirmation that a specific payment was made and its amount, but have no legitimate reason to see a user’s broader transaction history or what else the agent has been doing.
• Compliance, auditors, and regulators are another access tier. Enterprises deploying agents in regulated industries need to be able to produce transaction records on demand, but this access should be scoped, auditable, and not equivalent to public visibility. A regulator should be able to see what they need; a competitor should not.
• The agent itself has a particular position. In autonomous multi-agent workflows, an agent may need to prove to a downstream counterparty that it has already made a specific payment, without revealing other details of its transaction history.

With its low-latency and flexible architecture, Inco provides a solution to these issues. Agents can transact at the speed of the blockchain they’re paying on, and transactions can be decrypted by permissioned third parties. 

Inco Agentic Payments Demos

Let’s take a look at a proof-of-concept demonstration using Inco Lightning to shield transactions for the x402 and MPP protocols. These demos are simple: they demonstrate an request to the x402 and MPP protocols on the Base Sepolia testnet, with Inco Lightning protecting the payment details. You can see the slight difference between the two protocols: MPP can be used to make multiple requests, with the agent settling at the end, whereas x402 pays per request and settles on a per-request basis

You can try them on Base Sepolia. Check it out here:

x402 demo

MPP demo

Agentic payments are still in a nascent phase of development. Numerous key issues, particularly security, need to be addressed. However, the foundational components—fast, secure blockchains, a flexible and composable privacy solution, and numerous native protocols—are in place. It’s exciting to imagine what agents will be able to do in the near future.