AP2 vs. x402: What Each Verifies, and Where Payment Policy Enforcement Fits

TL;DR

• AP2 (opens in a new tab) authorizes a shopping agent to purchase or pay under a mandate. Its verifier evaluates the mandate’s disclosed constraints, including applicable budgets.
• x402 (opens in a new tab) handles payment requests and responses. Its buyer client applies configurable per-payment spend controls.
• AP2 mandate authorization can sit above an x402 payment flow. The protocols address different boundaries and are not substitutes.
• Inherence’s proposed integration adds protected pre-execution release and portable, privacy-preserving evidence of a committed policy calculation for covered payments. It works alongside AP2’s native mandate checks and x402’s buyer controls. A signed AP2 receipt records a verifier’s result, while an x402 settlement response reports a payment outcome. Neither artifact alone proves that separate calculation. The integration is an architecture, not a demonstrated adapter.

What AP2 verifies

AP2 defines how a verifier checks whether a shopping agent’s proposed checkout or payment falls within the authority recorded in its mandates. A Checkout Mandate records authorization for the agent to purchase the specified checkout. A Payment Mandate records authorization to pay for it. Open mandates carry terms and constraints. Closed mandates identify the proposed action for evaluation against those terms. The AP2 specification (opens in a new tab) requires authorization checks to run in deterministic code.

For a presented mandate chain, the verifier checks its cryptographic integrity. It also checks that claims carried forward from an open mandate remain unchanged in the closed mandate. The verifier then evaluates each disclosed constraint against the closed mandate. Under AP2’s authorization rules (opens in a new tab), an unknown constraint fails evaluation rather than being ignored.

AP2’s payment budget sets a cumulative limit. The budget rule (opens in a new tab) permits a requested amount only when that amount plus previously closed payments under the Payment Mandate stays within the maximum. After approval, the verifier must add the amount to the accumulated total. AP2 specifies that tracking obligation but does not prescribe a storage or concurrency mechanism.

A Mandate Receipt is a verifier-signed record of a success or error result that references the received mandate by hash. A reviewer can check the signature and reference. To rerun the evaluation, a reviewer also needs the relevant disclosed terms and the budget state used for the decision. The receipt is a signed attestation of the verifier’s result against a referenced mandate hash, not proof of the internal policy computation.

What x402 verifies

x402 defines an HTTP payment flow in which a seller requests payment and checks the buyer’s payment authorization before serving a resource. The buyer’s client applies its own spend controls. By default, the x402 client (opens in a new tab) pays only with recognized USD-pegged assets and caps each payment at $1. Both defaults can be changed when the client is created. A per-payment cap does not, by itself, track a cumulative budget.

The payment scheme determines what the buyer authorizes. Exact covers a specified payment amount. Under Upto (opens in a new tab), the buyer signs a maximum, and the seller can set a lower charge through a settlement override. Under Batch Settlement (opens in a new tab), the buyer deposits funds and signs a voucher for each request. The seller verifies those vouchers and redeems them later in batches. Batch Settlement also permits a lower per-request charge through a settlement override.

Some controls depend on the scheme and its configuration. In Batch Settlement, a client spend cap can constrain deposit size, while a server’s minimum-deposit requirement is optional to enforce. Batch Settlement and the SVM version of Upto offer self-managed or facilitator-delegated receiver authorization. Those choices do not apply uniformly across x402 payments.

After settlement, the PAYMENT-RESPONSE header reports the result returned to the client. The client can decode it as settle_response. They let the client distinguish a reported successful settlement from a failed one. Those response artifacts do not, on their own, prove that a separate mandate’s budget calculation followed a committed policy.

Where the two protocols draw the line

The AP2 specification (opens in a new tab) separates mandate authorization from payment processing. A verifier checks the presented mandate chain and disclosed constraints, including any applicable cumulative budget, before issuing a signed receipt of its result.

A signed AP2 receipt lets another party verify who attested to a result for the referenced mandate. It does not let that party independently check the verifier’s internal budget calculation. Separate policy-calculation evidence could support a check of how a defined rule applied to committed inputs.

x402 handles payment authorization and settlement within its supported schemes. Its buyer documentation (opens in a new tab) describes client spend controls and a payment response that reports whether settlement succeeded. That response supplies settlement evidence for the x402 payment. It does not establish that a separate AP2 mandate was valid or that an additional policy calculation was performed. A deployment seeking mandate authorization, independently verifiable policy-calculation evidence, and settlement evidence must identify how each is supplied on its covered payment path.

AP2 vs. x402 at a glance

The protocols provide different controls. AP2 (opens in a new tab) defines mandate authorization for agent purchases and payments. x402 (opens in a new tab) defines an HTTP payment flow with buyer spend controls and settlement responses.

How AP2 can authorize an x402 payment

AP2 can authorize a payment that x402 carries out. The AP2 specification (opens in a new tab) does not prescribe a payment rail. AP2 documentation also includes x402 sample flows (opens in a new tab). In one possible combined flow, the agent presents a closed Payment Mandate for verification before the buyer responds to an x402 payment request. The buyer then submits payment authorization through x402 and checks the settlement response (opens in a new tab).

A combined deployment should treat that purchase as one logical payment when it tracks spending across covered payment paths. AP2 requires the verifier to add approved amounts to a cumulative mandate budget, but neither cited protocol defines an atomic reservation shared across x402 and other paths. An implementation seeking a shared budget across covered paths would need an atomic reservation before releasing payment authorization. That reservation must account for competing requests against the same remaining budget.

The evidence from each step answers a different question. A successful AP2 mandate check establishes that the verifier accepted the action under the terms presented to it. An AP2 signed receipt records the verifier’s result, but it does not independently prove that the verifier calculated or committed the shared budget correctly. An x402 settlement response reports the payment outcome. Neither mandate authorization nor a budget reservation, on its own, establishes final settlement.

Where independent policy enforcement fits

AP2’s mandate checks and x402’s client spend controls remain in place when a deployment adds independent policy enforcement. Inherence proposes a protected release point for covered payments. The proposed control would evaluate committed policy before permitting wallet signing, credential release, or payment initiation through that point. This is an integration architecture, not a demonstrated AP2 or x402 adapter.

The proposed architecture would also produce portable, privacy-preserving evidence of the defined policy calculation. Under the proposed design, an independent verifier could check the evidence against the defined public statement and verification key without seeing the protected inputs encoded in the proof. An AP2 Mandate Receipt attests to its verifier’s authorization result. Neither that receipt nor the proposed policy evidence alone establishes settlement. If AP2 authorizes an x402 payment, the proposed integration would use one logical payment and a shared atomic budget reservation across covered paths.

Inherence’s proposed evidence covers only actions routed through the defined enforcement path and evaluated against committed or attested inputs. It does not independently establish the truth of every external input or cover actions executed outside that path. The implementation guide (opens in a new tab) gives engineering detail.

Choosing between AP2, x402, and added enforcement

For an HTTP payment flow that does not require a separate mandate or shared cumulative budget, x402’s buyer controls (opens in a new tab) provide configurable per-payment limits. Its settlement response reports the payment outcome. The client can adjust those limits without adding a mandate protocol.

For payments that require a mandate-based authorization record across payment roles, AP2 (opens in a new tab) provides Checkout and Payment Mandates without prescribing the payment rail. Its current specification does not cover delegation of a mandate from one shopping agent to another.

When a counterparty must verify a policy calculation without seeing protected inputs, Inherence proposes a separate enforcement point and independently verifiable policy evidence for covered actions. It would gate payment authority before execution and produce portable evidence of the committed calculation for covered actions. The evidence depends on committed or attested inputs. It cannot establish the truth of every external input or cover actions outside the defined enforcement path.

FAQ

Can AP2 and x402 be used separately? Yes. AP2 (opens in a new tab) authorizes agent purchases without prescribing a payment rail. x402 (opens in a new tab) can initiate payments without an AP2 mandate. A deployment can also use AP2 to authorize a payment carried through x402.

Does a signed AP2 receipt prove the budget calculation was correct? No. A signed Mandate Receipt records a verifier’s result for a referenced mandate. AP2 requires the verifier to track cumulative spending against a budget, but the receipt does not prove how the verifier calculated or stored that total.

What does x402’s settlement header confirm? The PAYMENT-RESPONSE header reports the payment result returned through the x402 flow. A reported settlement does not establish that an AP2 mandate was valid or that an external policy calculation was correct.

What does an enforced path cover? An enforced path routes a covered action through a policy check before payment signing, credential release, or initiation. Inherence’s proposed integration would produce independently verifiable evidence for actions routed through that path and evaluated against committed or attested inputs. It would not cover actions executed outside the path or independently establish the truth of every external input.

Next steps

Select AP2 when the flow needs mandate authorization, x402 when it needs the supported HTTP payment flow, or both when a mandate authorizes an x402 payment. Separately, determine whether covered actions need a shared budget reservation, pre-execution enforcement, or independently verifiable policy-calculation evidence. The Inherence implementation guide (opens in a new tab) provides engineering detail for a proposed integration, not a demonstrated adapter.