Agentic Payments: AP2, x402, Authorization, and Settlement

Agentic payments are transactions in which an AI Agent participates in product discovery, checkout, authorization, payment execution, or post-purchase handling. The hard problem is not teaching a model to call a payment API. It is preserving verifiable intent and bounded authority across systems that can disagree, time out, retry, settle, fulfill, refund, or enter dispute.

Two emerging protocols illustrate different layers. AP2 v0.2 defines authorization evidence for Agent-performed checkout and payment. x402 v2 defines a payment-required exchange plus verification and settlement. A production commerce system still owns identity, catalog and checkout truth, fraud controls, accounting, fulfillment, refunds, privacy, and applicable law.

Key Takeaways

• Separate shopping intent, checkout state, payment authorization, settlement, fulfillment, and reconciliation.
• Treat the Agent and every LLM-assisted role as a potential attacker; verify critical transitions in deterministic code.
• AP2 Mandates bind authorization evidence to checkout and payment state.
• x402 carries payment requirements and payment authorization; it does not provide client budget policy or complete commerce semantics.
• Human-not-present payment needs a prior, narrow, expiring mandate bound to the Agent key and enforced by every verifier.
• Money amounts use integer minor or atomic units with an explicit currency or asset identity.
• Timeouts create unknown outcomes. Reconcile before retrying.

The Transaction Has Several Truths

A single paid=true field cannot represent an Agent purchase. At least five truths exist:

Dispute and accounting systems need links among all five. A payment can settle after a checkout expires. A checkout can be accepted while settlement remains pending. A paid API request can fail before returning the resource. Model text is not the system of record for any of these states.

AP2 v0.2: Authorization Evidence

AP2 v0.2 describes five roles: Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, and Trusted Surface. One organization can play multiple roles, but it inherits each role's verification duties.

The protocol defines two primary Mandate types:

• Checkout Mandate: proves that the Shopping Agent is authorized to accept a particular checkout.
• Payment Mandate: proves authorization to pay for that checkout.

The Merchant signs the checkout state. The Payment Mandate is linked to it through a checkout hash, and receipts link back to the accepted or rejected Mandates. Verifiers must process these objects in deterministic code even when an Agent participates in the role.

AP2 distinguishes:

• Human present: the user reviews and signs the closed checkout and payment.
• Human not present: the user first signs open constraints; the Agent key can later sign a closed transaction that satisfies them.

For autonomous mode, the authorization must include the Agent public key confirmation and should use the shortest practical expiry. A verifier evaluates the closed transaction against the disclosed constraints. Agent-to-Agent delegation is conceptually possible but explicitly outside the current AP2 v0.2 specification, so do not claim interoperable sub-delegation from AP2 alone.

AP2 is a security feature inside a Commerce Protocol. Catalog search, checkout updates, inventory, tax, order APIs, fulfillment, and refunds are outside its core scope. UCP documents one way to integrate checkout state with AP2 Mandates.

x402 v2: Payment Requirements and Settlement

x402 v2 defines transport-independent types and logic for paid resources. A common HTTP flow is:

1. a client requests a resource;
2. the server returns a payment-required response and accepted payment requirements;
3. the client signs or obtains a payment authorization;
4. the server or facilitator verifies it;
5. settlement occurs;
6. the server returns the resource and settlement response.

The core roles are Client, Resource Server, and optional Facilitator. Version 2 separates:

• Types: payment requirements, payload, verification, and settlement response.
• Logic: scheme- and network-specific formation, verification, and settlement.
• Representation: transport binding for HTTP, MCP, A2A, or another protocol.

x402 explicitly leaves client-side budget management and session handling outside the core specification. It also does not prove that a resource is useful, correctly priced, legal, or fulfilled. The Agent application needs an independent purchase policy.

How AP2 and x402 Can Compose

AP2 and x402 are complementary only when each layer keeps its own meaning:

One valid architecture uses AP2 Mandates to prove what purchase was authorized, while x402 transports and settles a supported payment method. That composition is not automatic. Pin exact protocol versions, define a mapping, and test every failure state. When OAuth participates in the surrounding identity flow, keep its delegated authorization separate from the payment authorization itself.

Design the Authorization Envelope

An autonomous purchase policy should be narrower than "Agent may spend $500":

• principal and organization;
• Agent definition and public key;
• merchant or allowed merchant category;
• product, quantity, substitution, and delivery constraints;
• exact currency or asset and maximum amount;
• tax, fee, and exchange-rate treatment;
• start, expiry, recurrence, and maximum uses;
• geographic, legal, and data-processing restrictions;
• whether a human must approve the final checkout;
• revocation and exception behavior.

The final verifier must compare the canonical checkout, not a model summary. A change in payee, amount, item, quantity, destination, currency, mandate version, or material terms requires a new decision.

The Agent identity and delegation guide explains how principal and actor identities should survive the call chain. The Approval Gate entry covers action-bound decisions and replay protection.

Validate Amounts and Bind the Checkout

Never use floating-point values for money. Preserve the exact integer amount in minor or atomic units, plus currency or asset identity. Verify signatures with the protocol's supported libraries before applying application policy.

The following Go example checks a simplified mandate after cryptographic verification. It binds the Agent, payee, amount, currency, checkout hash, operation, and expiry.

package main

import (
	"errors"
	"fmt"
	"math/big"
	"time"
)

type Mandate struct {
	AgentID      string
	Payee        string
	Amount       string
	Currency     string
	CheckoutHash string
	OperationID  string
	ExpiresAt    time.Time
}

type Charge struct {
	AgentID      string
	Payee        string
	Amount       string
	Currency     string
	CheckoutHash string
	OperationID  string
}

func validate(m Mandate, c Charge, now time.Time) error {
	if !now.Before(m.ExpiresAt) {
		return errors.New("mandate expired")
	}
	if m.AgentID != c.AgentID || m.Payee != c.Payee ||
		m.Currency != c.Currency || m.CheckoutHash != c.CheckoutHash ||
		m.OperationID != c.OperationID {
		return errors.New("mandate binding mismatch")
	}
	authorized, ok := new(big.Int).SetString(m.Amount, 10)
	if !ok || authorized.Sign() < 0 {
		return errors.New("invalid mandate amount")
	}
	requested, ok := new(big.Int).SetString(c.Amount, 10)
	if !ok || requested.Sign() < 0 || requested.Cmp(authorized) > 0 {
		return errors.New("amount exceeds mandate")
	}
	return nil
}

func main() {
	now := time.Unix(1_800_000_000, 0)
	mandate := Mandate{
		AgentID: "shopping-agent-7", Payee: "merchant-42",
		Amount: "2500", Currency: "USD-cent",
		CheckoutHash: "sha256:abc", OperationID: "purchase-123",
		ExpiresAt: now.Add(time.Minute),
	}
	charge := Charge{
		AgentID: "shopping-agent-7", Payee: "merchant-42",
		Amount: "2499", Currency: "USD-cent",
		CheckoutHash: "sha256:abc", OperationID: "purchase-123",
	}
	fmt.Println(validate(mandate, charge, now))
}

Expected output:

<nil>

Production checks also include issuer, signature algorithm, key status, mandate type and version, nonce, selective-disclosure proof, Agent key binding, merchant checkout signature, tax and fee rules, fraud decisions, use count, and atomic consumption.

Idempotency and Unknown Outcomes

Payment systems fail between steps. A timeout after dispatch does not mean the charge failed. Use a stable operation identity across retries:

created -> authorized -> submitted -> settled
        -> rejected
        -> outcome_unknown -> reconciled_settled
                           -> reconciled_not_settled
        -> fulfilled -> refunded

Before retrying:

1. query the merchant order by operation ID;
2. query the processor or facilitator by payment identity;
3. query the payment network if appropriate;
4. compare amounts, payee, checkout hash, and status;
5. continue fulfillment, refund, or retry only from authoritative evidence.

An Agent must not decide that "no response" means "try again with a new nonce." Keep settlement and fulfillment idempotent where their underlying systems support it, and surface unresolved outcomes to operations.

Threat Model and Privacy

AP2's security considerations explicitly treat LLMs and Agents as potential attackers. Important attacks include manipulated checkout, manipulated payment, credential theft, malicious discovery, and multiple overlapping uses of an open Mandate.

Controls include:

• bind payment authorization to the exact signed checkout;
• bind autonomous Mandates to the Agent key;
• verify all constraints in deterministic code;
• prevent overlapping use or enforce one-time consumption;
• release payment credentials only after final verification;
• use salted selective disclosure for constraints;
• share only fields needed by each role;
• keep prompts, recommendations, and Agent reasoning out of the payment truth.

Also test currency confusion, Unicode merchant names, decimal conversion, stale exchange rates, redirect substitution, replay after timeout, partial settlement, duplicate fulfillment, refund races, and compromised discovery data.

Evaluate the Complete Purchase

Track more than payment success:

• authorized checkout acceptance rate;
• unauthorized or over-budget attempt rate;
• mandate verification and false-rejection failures;
• duplicate charge and duplicate fulfillment count;
• outcome_unknown rate and reconciliation time;
• settlement-to-fulfillment mismatch;
• refund completion and dispute evidence retrieval;
• user confirmation rate and consent abandonment;
• total cost per correctly fulfilled purchase.

A model that finds a cheaper item but violates quantity, delivery, privacy, or merchant constraints has failed. A payment protocol cannot replace task evaluation.

Frequently Asked Questions

Is HTTP 402 itself a payment protocol?

No. It is an HTTP status code. x402 defines message types, payment schemes, verification, settlement, and transport representations around a payment-required exchange. Other 402-based systems may use different headers, payloads, networks, and trust models.

Does AP2 require blockchain payments?

No. AP2 is payment-method agnostic and focuses on authorization evidence. x402 v2 currently documents specific schemes and networks, but that does not limit AP2 to those methods.

Can a model create or verify a Payment Mandate?

It may help assemble candidate data, but signature verification, constraint evaluation, amount comparison, key binding, and state transitions must run in deterministic code outside the LLM.

Who is responsible when an Agent purchase is wrong?

Protocol receipts can improve evidence, but legal and contractual responsibility depends on the parties, jurisdiction, payment method, service terms, and facts. Do not encode a universal liability conclusion into application logic.

What must be tested before autonomous payments?

Test changed checkout data, expired or revoked mandates, wrong Agent key, wrong payee or currency, over-budget amounts, replay, concurrent use, timeout after settlement, duplicate fulfillment, refunds, disputes, malicious discovery, and unavailable human escalation.

Sources

• AP2 v0.2 Specification
• AP2 Security and Privacy Considerations
• UCP and AP2 Integration
• x402 Protocol Specification v2
• A2A Protocol Guide
• AI Agent Tool Security