AEP2 Whitepaper

Abstract

In this paper, we introduce the Agent Embedded Payment Protocol (AEP2) — a new payment primitive purpose-built for the agentic economy. AEP2 redefines payment not as a separate financial step, but as an embedded capability within agent communication itself. When an agent sends a request, it can carry a payment mandate directly within the same message — authorizing the debit amount, terms, limits, and conditions for future settlement. The service executes instantly upon authorization, while actual fund transfers occur asynchronously in batched settlement cycles.

This architectural shift embedding payment into interaction, which enables real-time, low-latency transactions with the same finality and audibility as on-chain systems.

We also introduce a stablecoin-based AEP2 implement, which combines cryptographic payment mandates, smart wallets, paymaster-based gas-free, and programmable settlement processors to deliver near-centralized speed with decentralized security and compliance guarantees.

1. Introduction

Autonomous agents are beginning to participate directly in economic activity — purchasing compute and resource, consuming APIs, invoking AI agents and MCPs, and coordinating with other agents. These transactions often occur at millisecond to second intervals, and require seamless, low-latency exchange of value between machine participants.

However, today’s payment infrastructure was designed for human interaction, not autonomous execution. Whether through fiat gateways or stablecoin transfers, each payment is an external, blocking operation that requires a wallet, signature, and on-chain confirmation before the service can proceed. In agent workflows, this creates three major bottlenecks:

• Latency: each payment confirmation introduces seconds of delay, unacceptable for real-time agent calls.
• Interaction overhead: payment and service execution are decoupled, forcing the agent to manage two distinct protocols.
• Scalability limits: the per-transaction cost model makes high-frequency micropayments economically infeasible.

To support continuous and automated commerce between agents, we propose the Agent Embedded Payment Protocol (AEP2) — a model that integrates payment directly into the communication fabric, rather than treating it as a separate transactional layer.

In AEP2, every agent request can carry a cryptographically signed payment mandate that specifies the amount, asset, and settlement conditions. The receiving service verifies this mandate and executes immediately upon authorization, while the actual fund transfer is deferred and batch-settled asynchronously.

2. Embedded Payment

This section presents the core workflow of AEP2’s embedded payment mechanism, which enables agents to authorize and attach payments directly within their communication protocols.

We describe how the payer agent generates and embeds a payment mandate, how the payee verifies it, and how settlement is completed asynchronously through mandate submission.

2.1. Payment Mandate Generation. The payer agent initiates a payment by invoking its AEP2-compatible wallet through standard tools or SDK interfaces. The wallet constructs and signs a payment mandate, serves as a cryptographically verifiable authorization that grants the payee permission to withdraw funds later under defined conditions.

2.2. Payment Mandate Encoding. Once the payment mandate is structured in JSON format, it is Base64-encoded to make it suitable for transmission within network messages. This encoding step transforms the mandate into a compact, transport-friendly string that can be embedded directly into communication payloads, while preserving its data integrity and cryptographic authenticity.

2.3. Payment Mandate Embedding. After encoding, the payment mandate is embedded directly into the outbound agent request, allowing payment authorization to travel together with the service message. In AEP2, this embedding can be applied across standard agent-to-agent protocols such as HTTP, x402, MCP, or other A2A frameworks, using either headers or structured payload fields. By combining communication and payment into a single atomic message, agents can exchange value as seamlessly as they exchange data. For example, an HTTP message may include a header such as X-Agent-Payment-Mandate: U29ycnlBYm91dE1h...bmRhdGVz

2.4 Payment Verification and Execution. When the payee agent receives a request containing an embedded payment mandate, it extracts and verifies the mandate using the signer’s public key and predefined schema. Once validation succeeds, the payee immediately executes the requested service, confident that payment is authorized and guaranteed for later settlement.

2.5. Deferred Settlement. After the service is executed, the validated payment mandate is forwarded to a Settlement Processor, which manages the clearing and settlement process asynchronously. The processor aggregates multiple mandates, verifies their validity and sequence, and executes settlement tasks within a configurable time window. This deferred mechanism decouples service delivery from fund transfer, allowing real-time interaction at the protocol level while maintaining reliable and traceable financial settlement across participants.

3. Payment Mandate

This section details the Payment Mandate, the foundational primitive that enables embedded payments within the AEP2 framework. It introduces the protocol design, data structure, and execution model of the mandate, and includes a stablecoin-based example to illustrate how authorization and settlement interact in practice.

3.1. Overview

The Payment Mandate in AEP2 can be viewed as a contract between the Wallet and the Settlement Processor (SP), established and enforced through the underlying Payment Layer.

It defines the conditions under which the SP is authorized to debit funds from the wallet owner’s account — but only when holding a valid mandate that has been cryptographically signed by the wallet.

In essence, a payment mandate functions like a digital check: a signed authorization that grants the payee the right to claim a specific amount under predefined terms from the payment layer.

Within this structure, three entities collaborate to complete an embedded payment:

• AEP2 Wallet — represents the payer’s controlled account, responsible for generating and cryptographically signing payment mandates that specify the authorized payment terms.
• Settlement Processor (SP) — acts as the trusted executor, maintaining a queue of valid mandates and performing fund deductions according to the mandate contract.
• Payment Layer — serves as the financial substrate that maintains account and executes the actual debit operation once a valid mandate is verified. It can be implemented through traditional payment networks (such as PayPal or card-based systems) or smart contract–based stablecoin payment, depending on the deployment environment and settlement requirements.

3.2 Mandate schema

Each payment mandate is composed of four fundamental fields:

• **schema:**Defines the structure and rules of the mandate (e.g., scheme type, signing format, expiration logic).
• payload: Contains transaction details such as payer, payee, amount, and settlement conditions.
• signature: The cryptographic signature generated by the wallet to ensure authenticity and non-repudiation.
• signer: Identifies the wallet or entity that created and signed the mandate.

The payment mandate structure is extensible. Different schemes within AEP2 can define additional fields in the payload to support various use cases. Each mandate’s signature always covers both the schema and the payload, ensuring that all business logic is bound to the original authorization.

3.3 Stablecoin-Based Example

In a stablecoin-based implementation, a payment mandate represents a smart contract debit authorization signed by the user’s wallet private key. The payee, upon receiving this mandate, can submit it to the designated smart contract or settlement processor, which verifies the signature and authorization terms. Once validated, the corresponding amount of stablecoins is transferred from the payer’s wallet balance to the payee’s account, completing the settlement.

4. Implement: FluxA AgentSpend

FluxA AgentSpend is a stablecoin-based implementation of the Agent Embedded Payment Protocol (AEP2). It is designed to enable authorize-first, settle-later payments across autonomous agents and AI-driven applications, combining programmable payment authorization, deferred settlement, and compliance support into a unified framework.

In essence, AgentSpend brings the concept of embedded payment into real-world execution — allowing AI agents to embed cryptographic payment mandates directly within their service requests while achieving efficient, trust-minimized settlement on stablecoin infrastructure.

Its architecture consists of five core components that work together to enable authorize-first, settle-later transactions across chains and agents.

4.1 Authorize first, settle later

At the core of FluxA AgentSpend lies its defining payment flow — authorize first, settle later

This design separates the payment process into two distinct yet connected phases, allowing agents to complete transactions instantly while deferring on-chain settlement for efficiency and scalability.

Phase 1: Authorization (Instant)

• The payer signs a cryptographic payment mandate, defining payment terms and limits.
• The payee verifies the signature and submits the validated mandate to the Settlement Processor, which maintains the payer’s settlement queue.
• Once verified, the service is delivered immediately — no on-chain transaction occurs at this stage.
• The authorization serves as a trustless commitment to settle later.

Phase 2: Settlement (Deferred)

• The processor aggregates multiple mandates from various transactions and builds batch settlements.
• These batches are then executed on-chain periodically, distributing gas costs across hundreds of transactions.
• Settlement finality is achieved asynchronously without affecting real-time transaction flow.

4.2 Debit wallet

The Agent Debit Wallet is an account abstraction–based smart contract that manages user funds and authorizations for agent payments.

It serves as the programmable settlement protocol where stablecoin balances are held, payment mandates are signed and verified, and authorized Settlement Processors are permitted to debit funds according to predefined rules.

This wallet enforces withdrawal delay periods to ensure settlement safety and prevent front-running or unverified fund movement. By combining programmable fund control with verifiable mandate execution, it acts as the trust anchor between agents and the settlement layer.

Operationally, the Agent Debit Wallet introduces several key mechanisms:

1. Pre-funded balance – users deposit stablecoins before any payment authorization, ensuring immediate liquidity for settlement.
2. Deferred withdrawal – all withdrawals trigger a configurable delay window (e.g., 24 hours) during which pending mandates can still be processed or contested.
3. Authorized SP access – only Settlement Processors explicitly whitelisted by the payer can execute debit operations.
4. Mandate queue – maintains an ordered ledger of outstanding or partially settled mandates for transparent reconciliation.
5. Auto-extension logic – each time a new mandate is issued, the withdrawal delay window extends automatically, preventing premature withdrawals while settlements remain in flight.

4.3 Settlement Processor

The Settlement Processor serves as the dedicated coordinator responsible for verifying mandates submitted by payees and performing the corresponding fund settlements.

Every wallet designates one and only one Settlement Processor, which acts as the exclusive controller of its settlement queue. This processor aggregates all payment mandates issued by the wallet owner, validates their authenticity, and sequentially executes or batch-executes settlements on-chain—much like a rollup sequencer that orders transactions deterministically.

For a payment to be considered complete, the payee must forward the received, wallet-owner-signed mandate to the Settlement Processor. Only after the processor confirms that the mandate has been accepted into the settlement queue is the payment formally recognized as confirmed.

This ensures that every transaction is verifiable, ordered, and auditable before funds are released.

Key functions of the Settlement Processor include:

1. Exclusive wallet binding – each wallet is linked to a single Settlement Processor that manages its settlement logic and queue integrity.
2. Mandate admission – receives mandates from payees, validates their signatures and balance availability, and enqueues them for settlement.
3. Sequential clearing – processes mandates strictly in issuance order, ensuring fairness and avoiding race conditions.
4. Batch settlement execution – merges multiple pending mandates into optimized batch transactions to reduce gas and latency.
5. Unified confirmation logic – defines the moment of “payment confirmation” as the point when a mandate is accepted into the queue, not when funds are transferred.

4.4 KYA Provider

The KYA Provider is designed to ensure that agent transactions are anchored to verified real-world identities.

Its primary purpose is to enable payments between agents to occur under transparent, compliant, and trust-assured conditions. By linking each agent to a verifiable identity, the KYA Provider allows both payer and payee to configure payment preferences—for example, accepting only verified counterparties or enforcing compliance-based transaction modes.

When a transaction is initiated under KYA-enabled mode, both sides undergo identity verification, confirming the authenticity of the participating agents. This process satisfies regulatory requirements such as KYC (Know Your Customer), KYB (Know Your Business), and AML (Anti-Money Laundering), while maintaining compatibility with decentralized infrastructure.

The KYA Provider offers the following capabilities:

1. Agent verification and registration – verifies the authenticity of each agent’s identity, ensuring that all participants in a transaction are backed by a verifiable real-world entity or operator.
2. Compliance attestation – issues KYC/KYB/KYA certificates and embeds compliance attestations directly within payment mandates, allowing every transaction to be transparently validated against regulatory and anti–money laundering requirements.

4.5 Dispute Processor

The Dispute Processor (DP) is an optional protocol module designed to ensure fairness and transparency in settlement.

When a payer raises a dispute, the DP evaluates the associated evidence — such as signed receipts, service logs, or transaction metadata — and determines whether the funds should be released, withheld, or refunded.

Its role is to provide accountability and trust assurance without compromising the efficiency of automated settlement. Implementation of a Dispute Processor is not mandatory; rather, it depends on the specific design of each Settlement Processor (SP). SPs that choose to support dispute resolution must integrate a compatible DP implementation and define their own dispute-handling policies, including payee obligations and timing rules. For example:

• Disputes unresolved within a defined window may delay withdrawals or trigger automatic refunds to the payer.
• Payees are required to interface with the DP protocol to receive dispute events, respond automatically, and manage case status.

4.6. Transaction Modes

FluxA AgentSpend supports two distinct payment initiation patterns under the AEP2 framework, enabling flexibility for both real-time micropayments and complex, order-based workflows.

4.6. Intent Mode

In Intent Mode, the payment flow is initiated entirely by the payer agent.

The agent proactively embeds a pre-signed payment mandate within its outbound request, authorizing the corresponding payment in advance. This creates a single-round transaction pattern — the service request and the payment authorization travel together as one atomic

message.

Payer: "Call analyze_data(data) with $0.01 mandate"
       → [Request + Embedded Mandate]
Payee: Verify mandate → Execute service → Return result
       → Total time: <100ms

This mode is optimized for deterministic, low-latency interactions where the cost is fixed and known beforehand. Once the payee receives the request, it simply verifies the mandate signature and proceeds to execute the task immediately without waiting for any external confirmation. The transaction is finalized asynchronously later, during the settlement cycle managed by the Settlement Processor.

By eliminating negotiation and confirmation overhead, Intent Mode achieves near-real-time responsiveness, typically within tens of milliseconds, making it ideal for high-frequency micropayments, pay-per-call APIs, streaming compute, or autonomous agent coordination.

4.6.2. Order Mode

In Order Mode, the payment process is initiated by the payee rather than the payer.

This mode introduces a two-round interaction where the payee first issues a quote or order describing the expected cost, terms, or metering rules of a service. The payer agent then reviews the quote, constructs a corresponding payment mandate, and sends it back to authorize execution.

Round 1:
Payer: "Request service X"
Payee: "Service X costs $5.00" → [Returns Order]

Round 2:
Payer: "Approved" → [Submits Mandate]
Payee: Verify mandate → Execute service → Return result

This approach suits dynamic or usage-based pricing models, where the final cost cannot be known until the service context is established — for example, after a model inference cost estimate, a compute-time projection, or an on-demand data retrieval request. By separating the quotation and authorization stages, Order Mode preserves flexibility without sacrificing automation.

Once the payer submits the signed mandate, the payee validates it against the specified quote, executes the requested task, and later submits the mandate for deferred settlement. The result is a fully automated yet policy-compliant payment flow that still allows pricing negotiation, risk control, or human-in-the-loop approval when required.

Typical scenarios include subscription renewals, task completion billing, custom agent services, and metered API consumption.

5. Co-work with Existing Protocols

The Agent Embedded Payment Protocol (AEP2) is designed to integrate seamlessly with the existing agent and AI communication ecosystem. Rather than replacing current standards, it extends their capability by embedding programmable payment authorization directly into their message structures.

This section outlines how AEP2 interacts with four key protocols that form the foundation of agentic communication and authorization.

5.1. x402: Extending Embedded Payment over HTTP

x402 defines an embedded payment protocol built on top of HTTP, enabling payments to be attached to service calls.

AEP2 extends this design by allowing Payment Mandates to be embedded directly into the x402 payment schema.

Through this integration, developers can enhance x402 with support for deferred settlement, programmable mandates, and compliance-aware identity checks — enabling not only one-time transfers but stateful, verifiable payment authorization within the same familiar transport layer.

5.2. AP2: Authorization Foundation

AP2 focuses on user and agent authorization — defining how an agent gains consent to act or spend on behalf of a user. AEP2 can leverage the authorization primitives defined by AP2 to handle the signing and verification of payment mandates.

This creates a unified trust model where AP2 manages identity and permissioning, while AEP2 manages the execution and settlement of financial actions, forming a complete authorize–execute–settle lifecycle.

5.3. MCP: Embedded Payments in Tool Invocation

MCP (Model Context Protocol) defines the communication standard for agents invoking external tools and services. By embedding AEP2 payment mandates into MCP requests, every tool invocation can carry a verifiable payment authorization.

This enables agents to pay for API usage, compute time, or data access automatically, removing the need for manual billing or pre-deposited credits.

As a result, MCP-enabled tools can participate directly in agentic economies with minimal integration overhead.

5.4. A2A: Payments between Autonomous Agents

A2A (Agent-to-Agent Communication Protocol) defines how autonomous agents interact and exchange data with each other. AEP2 can be embedded into A2A message formats, allowing agents to attach payment mandates to their inter-agent calls.

This enables native value exchange within multi-agent workflows — where computation, data, or service coordination can be compensated in real time.

Through AEP2, A2A interactions evolve from simple task coordination into economic coordination, bridging communication and commerce in one unified protocol layer.

6. Extensibility

The modular design of the Agent Embedded Payment Protocol (AEP2) allows developers and service providers to extend its components to meet diverse business and regulatory requirements.

Each core module — including the settlement mechanism, wallet, and identity layer — can be customized or replaced without breaking protocol compatibility.

This flexibility makes AEP2 suitable for both open agent economies and enterprise-grade payment environments.

6.1 Settlement Mechanism Extensions

The settlement mechanism in AEP2 defines how and when authorized payments are executed.

Beyond the default debit settlement, AEP2 supports multiple extensible modes that adapt to different business logic and risk models:

• Debit Settlement (Default) – Funds are debited directly from the payer’s wallet and transferred to the payee after the settlement processor finalizes the transaction.
• Credit Settlement – The payee extends temporary credit to the payer, with settlement triggered once a predefined credit threshold is reached. This mode enables usage-based billing or free-trial models.
• Result-Based Settlement – Settlement occurs only after successful service delivery or confirmation from the payer. This provides built-in buyer protection and supports escrow-like workflows.

6.2 Wallet Extensions

AEP2 wallets can evolve beyond simple balance management into programmable financial instruments.

Different wallet types can support richer transaction logic and interoperability with external systems:

• Basic Debit Wallet – Manages pre-funded balances with fixed withdrawal delays and standard authorization.
• Credit Wallet – Allows limited negative balances, integrates with credit scoring systems, and supports interest calculation for deferred settlements.
• Voucher Wallet – Enables marketing incentives, loyalty programs, or multi-token reward systems using vouchers or coupons issued as programmable assets.

6.3 Identity Provider Extensions

The identity layer in AEP2 enables flexible compliance and trust configurations, adapting to varying regulatory or market requirements:

• Anonymous Mode – Facilitates pseudonymous transactions between agents without identity verification, offering low friction but limited trust guarantees.
• Verified Mode – Integrates KYC/KYB/KYA verification and compliance checks, ensuring regulatory alignment and enhancing transaction credibility for enterprise or institutional contexts.

7. Conclusion

The Agent Embedded Payment Protocol (AEP2) represents a new architectural paradigm for payment infrastructure in the era of autonomous agents.

By embedding payment authorization directly into agent communication — and decoupling authorization from settlement — AEP2 delivers the speed, scalability, and programmability required for real-time agent commerce, while preserving the trust and verifiability of decentralized systems.

Its modular design enables innovation across wallets, settlement mechanisms, and identity frameworks, forming a flexible and extensible foundation for AI-native economies.

AEP2 not only enhances existing communication protocols such as x402, AP2, MCP, and A2A, but also transforms payments from a separate financial process into a native part of agent behavior.

As AI agents evolve into autonomous economic participants, AEP2 provides the essential payment rails to support high-frequency, low-latency, and compliant micropayments at scale — enabling new forms of collaboration, coordination, and value exchange across the intelligent economy.

References

• Agent Embedded Payment Protocol Documentation: https://docs.fluxa.ai
• x402 Protocol Specification: https://github.com/httpx402
• Account Abstraction (ERC-4337): https://eips.ethereum.org/EIPS/eip-4337
• Model Context Protocol: https://modelcontextprotocol.io