What are Agentic Payments? How AI Agents Pay

Your payment infrastructure was built for humans. Humans log in, review a transaction, and approve it. Agentic payments break that assumption entirely.

Agentic payments are machine-initiated transactions where an AI agent executes a payment autonomously, within pre-defined authorization boundaries set by a human or organization, using existing payment rails and wallet infrastructure. The agent doesn't create new money movement mechanisms. It uses the ones you already have, operating 24/7 without waiting for a human to click approve. The architecture question isn't whether to build a new rail. It's whether your authorization layer can handle machine-initiated volume.

As of September 2025, AP2 (Google's agent payment protocol) launched with 60+ partners already treating Mandate-based authorization as the expected model. If a partner's agent sends a Mandate your infrastructure can't validate, the transaction fails before it reaches your signing logic. The architecture question isn't whether this is coming. It's whether you're ready.

What's actually happening when an AI agent pays

The mechanism

An AI agent operating in a payment context doesn't have its own money. It has delegated access to a wallet or payment account, bounded by rules set at authorization time: maximum transaction value, allowed counterparties, expiry windows, and escalation triggers.

When the agent needs to pay for a resource, it calls the payment API, passes the required authorization credentials, and the transaction executes. No human is in the loop for that specific transaction. The human was in the loop when they set the authorization parameters.

This is closer to a standing order or API key with spend limits than it is to anything architecturally novel. What makes it distinctive is the volume and frequency: agents can initiate thousands of micropayments across multiple platforms in the time it takes a human to review one.

Emerging protocols: AP2 and x402

The standard

Two open standards are emerging to give this pattern structure.

Google's AP2 (Agent to Payments Protocol), announced in September 2025, is built on the A2A and MCP protocols. AP2 uses Mandates: cryptographically signed digital contracts that prove a human authorized a payment before any agent executes it. The Mandate travels with the transaction as verifiable proof of intent. AP2 launched with 60+ partners including Coinbase, Mastercard, PayPal, American Express, Revolut, Worldpay, and Adyen. It supports both traditional payment rails and stablecoins and crypto assets.

Within AP2, the x402 extension handles the crypto and stablecoin layer specifically. Coinbase developed x402 as an HTTP 402-based protocol for individual API calls, making it the primitive for machine-to-machine crypto payments. Where AP2 covers the broader agent payment contract framework, x402 handles the per-call payment mechanics. It was co-developed with the Ethereum Foundation and MetaMask.

These protocols matter for platform operators because they're shaping what counterparties will expect from a compliant agentic payment endpoint. If a partner's agent sends an AP2 Mandate, your infrastructure needs to be able to validate and process it.

What your authorization architecture actually needs to handle

The gap

This is where platform operators often find the gap. Most existing payment authorization flows assume:

• A human identity behind each transaction
• Approval happening in real time via UI
• Escalation going to a human inbox

Agentic payment flows invert all three.

The identity is a credentialed agent acting on behalf of a human or organization. Approval happened earlier, encoded in parameters. Escalation needs to happen programmatically, not by emailing someone.

Under a traditional approval flow, an agent queues a $50,000 sweep to an address your allowlist doesn't recognize. There's no programmatic gate: it executes, then someone on your ops team finds it in the morning report.

Under a bounded authorization model, the transaction hits the allowlist check at authorization time, triggers tier-2 reviewer escalation, and never reaches the signing layer until a human confirms the counterparty. The agent's 3am execution window doesn't change that logic.

For an exchange or PSP evaluating readiness, the architecture questions are:

First, the authorization model itself: can you issue API credentials with spend limits, counterparty restrictions, and time-bounded expiry? CoinsDo's [[internal: /en/coinsend]] CoinSend module supports configurable approval expiry controls, with execution approvals carrying expiry times that are visible per dispatch record [source: CoinSend v2.0.25]. That's the kind of bounded delegation agentic flows require.

Second, signature verification: how do you prove the transaction was authorized by the right principal? CoinSign, a feature within CoinSend, uses RSA/HMAC-SHA256 digital signatures across mobile, PC, and browser extension, producing an unforgeable authorization trail [source: CoinSend/CoinSign]. For agentic flows, that trail needs to survive audit without a human being able to reconstruct what happened from memory.

Third, threshold and escalation logic: high-value agent transactions need programmatic escalation, not a human in a Slack channel. CoinSend supports reviewer tiers, thresholds, and escalation logic for high-value transactions [source: CoinSend].

Fourth, execution continuity: agents don't stop at 5pm. CoinSend supports 24/7 automated withdrawal execution [source: CoinSend]. If your platform queues transactions for business hours, your agentic counterparties will route around you.

Fifth, inbound screening: if agents are sending funds to your platform, address-level risk screening becomes critical because there's no human reviewing the counterparty. CoinGet's automatic KYT address risk screening checks sending addresses for risk at deposit time [source: CoinGet v2.0.25].

The key custody question

The stake

One distinction that matters more in agentic contexts than in standard API integrations: who controls the private keys?

An agent with delegated access to a platform that custodies your keys is a much larger attack surface than one with access to a platform where you retain key control. CoinsDo's WaaS infrastructure operates on a non-custodial model: CoinsDo never holds your private keys. For organizations issuing agentic wallet access to third-party agents, this matters structurally.

If you're mapping out how agentic wallet access compares to standard API integration from an infrastructure perspective, this [[internal: /en/blog/agentic-wallet-vs-traditional-crypto-wallet]] breakdown covers the architectural differences directly. For a full picture of what WaaS infrastructure supports in this context, the [[internal: /en/waas]] overview is the right starting point.

FAQ

What are agentic payments?

Agentic payments are transactions initiated by an AI agent acting within pre-authorized boundaries, using existing wallet and payment infrastructure. The human sets the authorization parameters; the agent executes without requiring per-transaction approval.

Do agentic payments require a new payment rail?

No. Agents execute on existing rails, APIs, and wallet infrastructure. The requirement is an authorization architecture that supports machine-initiated transactions: spend limits, signature verification, programmatic escalation, and time-bounded credentials.

What is the AP2 protocol?

AP2 is Google's Agent to Payments Protocol, announced September 2025. It uses cryptographically signed Mandates to prove human intent before agent payment execution, and supports both traditional payments and crypto/stablecoin rails through its x402 extension.

What's the difference between AP2 and x402?

AP2 is the broader protocol framework for agent payment authorization and Mandate verification. x402 is the crypto-specific layer within AP2, handling per-call machine-to-machine payments using an HTTP 402-based mechanism. They work together: AP2 for the contract, x402 for the crypto execution.

How does CoinsDo's platform support agentic payment flows?

CoinsDo's API-first architecture integrates with exchanges, payment apps, and multi-account ecosystems. CoinSend handles authorization controls, signature verification via CoinSign, threshold logic, and 24/7 automated execution. CoinGet handles inbound deposit address generation and address risk screening.

What compliance controls apply to agent-initiated transactions?

The same controls that apply to any API-initiated transaction, plus additional considerations around identity delegation. CoinSend supports tiered approval flows and expiry controls. For onboarding the organizations whose agents will access the platform, CoinFace handles automated KYC including document OCR, liveness detection, facial recognition, blacklist screening, and duplicate detection.