The Agent Payment Stack: AP2 vs x402 vs UCP vs Circle vs Catena

Reviewed 17 August 2026 · 17 minute read

AP2, x402, UCP, Circle Agent Stack, Catena and Concordium are not interchangeable agent-payment products. AP2 secures agent-performed checkout and payment authorization. x402 makes payment an HTTP-native exchange. UCP defines commerce capabilities such as checkout and order state. Circle supplies wallets and USDC transaction infrastructure. Catena combines financial accounts, rails and policy controls. Concordium contributes verifiable agent identity and on-chain registry infrastructure.

An enterprise payment architecture may use several of them. The selection question is not "Which protocol wins?" It is "Which layer owns intent, business authority, checkout, credentials, settlement, reconciliation and evidence?"

Agent payment protocols compared by layer

Swipe horizontally to inspect the full diagram.

This is a scope comparison, not a claim that one product implements every feature in its column at production maturity.

AP2 secures authorization inside a commerce flow

AP2 v0.2 defines Checkout and Payment Mandates plus corresponding receipts. The specification requires role-specific validation to occur in deterministic code. A closed Checkout Mandate binds to a merchant-signed checkout, and a Payment Mandate binds payment authority to that checkout. The AP2 specification is explicit that AP2 acts as a security feature within a commerce protocol and is designed to work with UCP.

AP2 is the better fit when the transaction is an agent-performed checkout and the participants can implement the defined roles and verification responsibilities. It is more than a transport envelope. It directly addresses authorization and dispute evidence.

An enterprise still needs to map its internal approval chain, supplier status, budget, segregation of duties and credential release into that flow. AP2 does not become the company's procurement system or policy source.

x402 makes payment a web request

x402 v2 uses HTTP 402 Payment Required to return payment requirements, a PAYMENT-SIGNATURE request header for the signed payment payload and a PAYMENT-RESPONSE header for settlement information. The protocol is useful when an agent needs to pay for an API or digital resource without creating a conventional account and checkout session. Coinbase's x402 v2 migration guide documents the current headers and package split.

x402 is the better fit for stateless pay-per-request access and on-chain settlement. Its extension system includes payment identifiers and offer receipts, but an enterprise must still decide whether the buyer agent was allowed to purchase the resource, which cost center owns it and whether repeated paid calls share a budget.

A wallet signature shows that a key authorized a payment payload. It does not by itself show that the key holder had enterprise purchasing authority.

UCP owns commerce state around payment

UCP defines capabilities and version negotiation for interactions between a platform and a business. Its current standard capabilities include cart, checkout, identity linking and order. Checkout can remain user-finalized unless an AP2 Mandates extension is supported. UCP's Checkout specification separates checkout lifecycle from payment handlers, while the Order specification models current order state, fulfillment events and adjustments such as refunds.

UCP is the better fit when the architecture needs a common commerce language across merchant systems and agent surfaces. It gives the transaction a lifecycle beyond payment. It is not a bank, wallet or universal enterprise authorization system.

Circle and Catena provide financial capabilities

Circle Agent Stack gives agents wallets, token operations and x402 access, with USDC as a central settlement asset. Current documentation describes wallet and transaction tooling, multi-chain operations and spending controls. Circle Agent Stack documentation is relevant when the application needs programmable on-chain value and Circle infrastructure.

Catena positions itself as a banking and governance platform for agents. Its product materials describe agent identities, deterministic financial policies, approvals, audit trails, accounts and payments through cards, ACH, wires and stablecoins. Catena's current product page makes it the more vertically integrated choice for organizations that want agent financial operations and governance together.

Catena overlaps Intelliger most directly in financial policy and audit. Catena is the better fit when the customer wants financial accounts, treasury and payment rails in the same product. Intelliger is the better fit when the same portable authority and evidence model must govern payments and other consequential actions across existing providers. That distinction must be validated in a real design-partner workflow, not asserted from websites alone.

Concordium adds a public identity and accountability layer

Concordium's Agent Registry gives an agent an on-chain identity anchor and an Agent Card whose integrity is protected by an on-chain hash. The registry can link an agent to a verified human owner through Concordium's identity layer. Concordium's Agent Registry technical reference describes the contracts and records.

Concordium is complementary when a merchant or counterparty needs a portable owner or registry signal. The enterprise still decides what that identity may purchase under its own policy, and the payment provider still establishes settlement.

Where the payment providers sit

Enterprise agent market positioning

Product-scope analysis, not market share, quality or maturity

Text summary of highlighted companies

Company or protocol	Primary scope represented on the map
Intelliger	Transaction-specific authority, deterministic enforcement, reconciliation and portable evidence.
Concordium	Verified ownership, agent registry and identity-linked transaction infrastructure.
Catena	Agent financial policy, approvals, accounts, payment execution and audit.
Circle Agent Stack	Programmable wallets, USDC settlement and x402 support.
Google AP2	Typed checkout and payment mandates, role validation and receipts.
UCP	Commerce discovery, checkout, payment-handler and order-lifecycle protocol.

The plot should not be read as a maturity ranking. AP2 and UCP are protocols. Circle and Catena are commercial platforms. Concordium is a blockchain and identity ecosystem. Intelliger and OATI remain developer preview. Procurement comparisons must account for those different product forms.

Compose the stack around one canonical transaction

Consider an enterprise agent buying a EUR 40 market-data report through an x402 endpoint:

1. Agent identifies the report and receives an HTTP 402 challenge.
2. Enterprise control maps the endpoint to data.purchase and supplier:data-provider-9.
3. A mandate permits up to EUR 50 for purpose=market-research and one use.
4. Current policy checks supplier status, budget and data-use classification.
5. A short-lived wallet capability signs the x402 payment payload.
6. The facilitator verifies and settles the payment.
7. The service returns the report and a stable service reference.
8. Reconciliation confirms settlement and successful delivery separately.
9. A receipt binds mandate, request, decision, payment reference and observed outcome.

The transaction envelope might contain:

{
  "transaction_id": "txn:data:2026-08-17:4012",
  "agent_id": "agent:research:4",
  "action": "data.purchase",
  "resource": "report:provider-9:energy-q3",
  "counterparty": "supplier:data-provider-9",
  "purpose": "market-research",
  "amount": { "currency": "EUR", "minor": "4000" },
  "payment_protocol": "x402-v2",
  "authority_ref": "mandate:research:118",
  "request_digest": "sha256:...",
  "idempotency_key": "research:report:energy-q3:v1"
}

This internal profile is illustrative. It does not replace an AP2, UCP or x402 schema. It connects business authority to whichever payment and commerce messages the provider requires.

Separate accepted, settled and delivered

Payment systems create intermediate states. A network may accept a submission before it reaches final settlement. A paid endpoint may settle successfully but fail to deliver the resource. A checkout may complete while fulfillment remains open.

Track payment and delivery as separate state dimensions:

payment:  proposed -> authorized -> submitted -> accepted | unknown
          accepted | unknown -> settled | failed
          settled -> reversed | disputed

delivery: pending -> delivered | delivery_failed

Not every rail uses these names. Normalize provider states without erasing them, and do not let payment settlement imply delivery. Store the raw status and the mapping version. Never retry an unknown payment as if it were a confirmed failure. Reconcile by the provider's stable reference or idempotency key first.

Test the stack before moving real value

Run the suite against testnet or sandbox money. Record provider calls, wallet signatures, policy decisions, state transitions and receipt findings. A green model demonstration does not test duplicate execution or ambiguous settlement.

Where Intelliger adds value

Intelliger does not need to issue a wallet, become a merchant of record or replace licensed payment providers. Its value is the provider-neutral transaction chain:

• consume identity from an IdP or registry;
• express bounded authority across payment and non-payment actions;
• prevent delegated agents from expanding parent limits;
• bind approval and policy to the exact request;
• release credentials after deterministic authorization;
• reconcile the provider's ambiguous and terminal states;
• issue portable evidence with explicit assurance limits.

That is most useful when one workflow crosses procurement, API access, payment and post-payment operations or when one participant must enforce safely before counterparties adopt the same trust framework.

Questions about the agent payment stack

Is AP2 an alternative to x402?

They solve different parts of the problem. AP2 defines mandate-based authorization and accountability for agent payments. x402 defines an HTTP payment challenge and settlement flow. A system can use AP2-style authority controls around an x402 payment if the binding and state transitions are explicit.

Does UCP process payments?

UCP coordinates commerce capabilities such as checkout and orders and can reference payment handlers. It is not itself a universal payment rail. The merchant, payment provider and selected handler still determine how funds move, settle, reverse and generate provider evidence.

How do Circle and Catena differ in this comparison?

Circle exposes stablecoin, wallet and payment infrastructure that can support agent workflows. Catena presents an agent-commerce payment and compliance proposition. Buyers should compare exact custody, licensing, settlement, geography and production-availability claims directly with each provider because those details can change.

Does Intelliger hold or move customer funds?

No. The current OATI developer preview does not operate a payment rail, wallet or licensed money-movement service. Its relevant role is provider-neutral transaction authority, deterministic control, replay handling, reconciliation structure and bounded evidence around whichever regulated provider executes the payment.

Current Intelliger and OATI boundary

OATI's developer preview implements Passport and Mandate objects, transaction signing, deterministic evaluation, non-amplifying delegation, replay controls and Receipt schemas across TypeScript, Python and Go conformance cases. The sandbox includes paid-API and commerce development flows.

Intelliger does not currently operate a licensed payment rail, wallet, commercial reconciliation service or production agent-spend product. The complete policy compiler, durable evidence and dispute workflows, independent review and two-enterprise production acceptance remain open. Agent Spend Control and the broader commerce platform are target commercial profiles over the same control foundation.

The focused Catena versus Circle Agent Stack evaluation compares the two finance products. The canonical agentic payments guide explains why a model must not make the authorization decision. The AP2 mandate analysis goes deeper into the AP2 boundary, and exactly-once payment handling covers retries and reconciliation.

Expert review required before publication: payment, compliance and protocol reviewers should confirm product status, rail terminology, regulatory boundaries and all failure-state mappings.

To evaluate one provider-neutral payment transaction, open the OATI developer documentation and run the paid-API sandbox with a bounded mandate.