x402 Agent Payments: The AEP2 Authorize-First Protocol

TL;DR

• AEP2 (Agent Embedded Payment Protocol) is FluxA's protocol for embedding signed payment mandates directly into x402, MCP, and A2A calls.
• The core model is Authorize First, Settle Later: the payee verifies a signed mandate instantly; on-chain settlement happens in a batched window afterward.
• A payment mandate is a one-time signed authorization — not a payment itself. Verification is instant. Settlement is deferred.
• AEP2 supports two transaction modes: Intent Mode (payer-initiated, one round trip) and Order Mode (payee-initiated, two round trips).
• AEP2 does not replace x402. It solves three things x402 was never designed to handle: pay-before-service trust friction, per-call on-chain latency, and compliance.

Why x402 Alone Isn't Enough

x402 solves payment discovery. AEP2 solves payment latency and trust.

The x402 protocol embeds stablecoin payments into HTTP using the 402 status code — a clean solution for one-off API calls. But according to the AEP2 official documentation, three structural limitations appear as soon as workloads scale:

Limitation 1: Pay First, Service Later

x402 requires funds to transfer on-chain before the payee fulfills the request. For high-value or complex tasks, both sides carry trust risk — the payer commits funds before knowing the output quality, and the payee can't proceed until confirmation lands.

Limitation 2: Per-Call On-Chain Confirmation

Every x402 transaction waits for blockchain confirmation. At even modest frequencies — 20 API calls per agent workflow — that latency compounds into seconds of dead time. For LLM inference APIs or streaming data feeds, per-call on-chain settlement is not a tradeoff. It's a hard blocker.

Limitation 3: No Compliance Layer

x402 has no built-in KYC, KYB, KYA, or AML modules. That's fine for permissionless developer tools. It's a dealbreaker for enterprise deployments, financial services APIs, or any use case where knowing your agent's identity matters.

These aren't edge cases. They are the three reasons x402 doesn't scale past simple, infrequent API calls without additional infrastructure. The compliance gap is also why governance cannot be an afterthought — if you're deploying agents that transact autonomously, defining spending controls before they hit production is the prerequisite to any compliance layer being effective.

What Is a Payment Mandate?

A payment mandate is a signed, one-time authorization — the equivalent of a dated purchase order that a payee can submit for settlement within a defined window.

Per the AEP2 Payment Mandate documentation, the mandate is a cryptographically signed object containing six fields:

{
  "mandate_id":    "<unique identifier>",
  "from_wallet":   "<payer on-chain address>",
  "to_wallet":     "<payee on-chain address>",
  "amount":        "<USDC amount>",
  "nonce":         "<replay-attack prevention>",
  "signature":     "<payer cryptographic signature>"
}

Once signed, the mandate is Base64-encoded and embedded directly into the protocol request header — whether that's an x402 call, an MCP tool invocation, or an A2A message.

The Five-Step Flow

• Sign — Payer agent requests a mandate from its Debit Wallet; wallet signs with a cryptographic key
• Embed — Signed mandate is Base64-encoded and placed in the request header
• Verify — Payee extracts and verifies the mandate's signature and amount before delivering service
• Enqueue — Payee delivers service, then queues the verified mandate to the Settlement Processor
• Settle — Settlement Processor batches and executes on-chain debits within the settlement window

The Critical Distinction

A mandate is not a payment. It is proof that a payment will happen. Verification is instant. Settlement is deferred. This separation is what makes high-frequency agent workloads economically viable — the payee gets cryptographic certainty of payment without waiting for a block confirmation on every call.

How AEP2 Composes With x402, MCP, and A2A

AEP2 does not replace x402, MCP, or A2A. It adds a payment layer to each of them.

x402 handles HTTP-level payment negotiation. MCP exposes AI tool interfaces. A2A enables agent-to-agent communication. None handle payment authorization, compliance, or deferred settlement. AEP2 fills that gap by embedding a signed payment mandate into the protocol's designated payment field — a request header for x402, a payload field for MCP and A2A — per the AEP2 embedded payment documentation.

AEP2 on x402

AEP2 layers authorize-first semantics on top of x402. Instead of waiting for settlement confirmation before the server responds, the agent embeds a signed mandate using the X-Payment-Mandate header. The payee verifies the mandate and delivers the service immediately. Settlement happens later in a batched transaction.

FluxA is listed on the official x402 ecosystem page as providing "permissionless deferred payment rails for x402" — this is the architecture that pattern represents.

AEP2 on MCP

MCP has no native payment mechanism. When an agent calls a paid MCP tool, there is no standard way to authorize and settle payment inside the tool call itself. AEP2 solves this with Intent Mode: the agent embeds a payment mandate in the MCP tool invocation header. The tool server verifies the mandate before executing — no separate payment step, no API key required.

AEP2 on A2A

In agent-to-agent workflows, one agent delegates a subtask to another. A2A has no built-in payment handling. AEP2 embeds the mandate in the A2A message payload — the receiving agent verifies payment authorization before accepting the task, and settlement runs asynchronously after execution.

Intent Mode vs Order Mode

AEP2 supports two transaction modes. The difference is who initiates payment and how many round trips it takes.

Per the AEP2 transaction modes documentation:

Intent Mode

Payer-initiated. The agent knows the price upfront, signs a mandate, embeds it in the request, and sends everything in one round trip. Best for fixed-price API calls in the $0.001–$0.1 range and high-frequency automated interactions.

Order Mode

Payee-initiated. The payee responds to an initial request with a payment order containing amount and terms; the payer signs a mandate and resubmits. Best for dynamic pricing, subscriptions, and high-value tasks requiring explicit user confirmation before funds are authorized.

Intent Mode mirrors the standard HTTP request-response model and is x402-compatible by design. Order Mode is the pattern that makes agent subscriptions viable without a third-party billing layer.

The Settlement Layer

Settlement in AEP2 is deferred, batched, and optionally ZK-verified.

Deferred Settlement

The payee collects signed mandates and submits them to a Settlement Processor within a defined settlement window. The payer's Debit Wallet holds funds under smart contract custody; the Settlement Processor debits the correct amounts when processing the batch.

Batched Settlement

Multiple mandates are aggregated into a single settlement transaction. Batching is what makes $0.001 micropayments economically viable — without it, transaction fees alone can exceed the payment amount.

ZK-Verified Settlement

For very high-frequency workloads, the ZK-Verified Settlement Processor batch-verifies many signed mandates using a single Groth16/BN254 proof. One proof covers an entire batch — no per-mandate confirmation, no per-transaction fee overhead.

Conclusion

AEP2 is the authorization and compliance layer that x402 was never designed to be. x402 handles payment discovery and HTTP-level negotiation. AEP2 handles what comes next: instant mandate verification, deferred batch settlement, and the identity controls that enterprise deployments require. Used together, they cover the full payment stack for agent commerce.

Try a live mandate flow in the AEP2 Playground.

Frequently Asked Questions

What is AEP2?

AEP2 is FluxA's protocol for embedding signed payment mandates into x402, MCP and A2A calls. It separates authorization from settlement, allowing instant service delivery without waiting for on-chain confirmation.

How is AEP2 different from x402?

x402 requires settlement before service delivery. AEP2 reverses the sequence: the agent submits a signed mandate, the payee verifies instantly and serves, and settlement is deferred to a batch window. The two protocols compose, not compete.

What is a payment mandate?

A payment mandate is a one-time signed authorization embedded in an agent request. It carries payer address, payee address, amount, nonce, and a cryptographic signature — verifiable proof of payment without an on-chain transfer.

Does AEP2 work with MCP servers?

Yes. Mandates are embedded directly in MCP tool invocation headers. The tool server verifies the mandate before executing — no separate payment step or API key required.

Which mode should I use: Intent or Order?

Use Intent Mode for fixed-price, high-frequency API calls where the agent knows the price upfront. Use Order Mode when pricing is dynamic or the transaction requires explicit user confirmation before funds are authorized.

Is AEP2 open source?

Yes. The AEP2 MVP implementation is publicly available on GitHub under the FluxA-Agent-Payment organization, including reference implementations for the mandate flow, Settlement Processor, and Debit Wallet.

Can AEP2 mandates work alongside AP2 authorization?

Yes. AEP2 mandates can leverage AP2 for user authorization — only mandates that receive AP2 user consent are treated as valid, adding an auditable authorization layer on top of AEP2's payment flow.