Skip to main content

​
What is AP2

Agent Payments Protocol (AP2) is Google’s open protocol for AI agents to negotiate, authorise, and settle payments on behalf of humans. Unlike x402’s per-request model, AP2 introduces mandates: signed, scoped authorisations a human gives an agent. For example, “you may spend up to $50 buying flights from these vendors”. AlgoVoi provides the on-chain settlement extension for AP2. When a mandate is exercised, the resulting payment lands on Algorand, VOI, Hedera, Stellar, Base, Solana, or Tempo as USDC.

​
When to use AP2

Bounded autonomy

“Buy any of these 5 SKUs under $20 each, max $100 total this week.”

Cross-vendor mandates

One mandate authorises an agent to pay multiple vendors without re-confirmation.

Audit-grade commerce

Every transaction traces back to a signed human mandate, giving you a strong audit story.

Human-present scenarios

Agent proposes, human approves once, then the agent executes without further approvals.

​
How AP2 differs

x402 / MPPAP2
AuthorisationPer-paymentMandate (multi-payment, scoped)
Counter-party signingJust the payerBoth human and agent
SettlementDirectDirect (with extension)
Best forUnattended API callsAgent-mediated purchases

​
Sample scenarios

AlgoVoi has shipped two reference scenarios upstream into the official AP2 samples repo:

crypto-algo human-present

Algorand USDC settlement of an AP2 mandate, with full agent and ADK code.

crypto-solana human-present

Solana Pay reference-binding settlement of an AP2 mandate.
These PRs are the canonical reference implementations. The code there is exactly what runs against AlgoVoi’s gateway.

​
Architecture

AlgoVoi sits in the verifier role, the same as in x402, but the agent is now spending against a pre-signed mandate rather than per-call human approval.

​
Live demos

A working AP2 over A2A v1.0 REST + MCP demo runs against AlgoVoi’s production gateway. The agent card publishes:
  • verify-payment skill (AP2-compatible verification)
  • create-checkout skill (agent-initiated AP2 mandate exercise)
  • check-status skill

​
Canonicalisation conformance

AP2 mandates carry an open_mandate_hash field that identifies the mandate stably across the agent, the credential provider, and the merchant. The hash needs to be implementation-independent — two parties must derive the same bytes from the same mandate body, or interop breaks silently. AlgoVoi follows this derivation rule: 
open_mandate_hash = SHA-256(JCS_RFC8785(unsigned open-checkout-mandate body))
Lowercase hex output. Hash input is the claims object, not the JWS compact form. This is the load-bearing interop subtlety — JWS re-encoding by intermediaries changes the envelope even when the underlying payload is identical, which would silently break hash matching between implementations that round-trip through different JWS libraries.

​
v0 conformance vectors

We published a 7-vector reference set anchored to AP2’s open_checkout_mandate.json schema (sha e3d9cafa), structured as pairs so the canonicalisation rules are self-checking:
VectorPairRule
baseline-001—reference baseline
object-key-order-002with 001JCS sorts object members → byte-identical to 001
array-order-003with 001arrays are order-significant; do NOT sort → differs from 001
optional-fields-004with 001presence is not absence; not collapsed → differs from 001
currency-minor-unit-005—ISO-4217 integer minor units; no decimal/float
unicode-nfc-006awith 006bRFC 8785 does NO Unicode normalisation
unicode-nfd-006bwith 006aNFC and NFD inputs hash differently
The array-order and Unicode pairs are the ones that catch divergence in practice. An implementer who sorts arrays “to canonicalise” or who NFC-normalises merchant strings before hashing matches the wrong vector immediately, rather than silently producing an incompatible hash.

​
Cross-implementation validation

The v0 conformance vectors are part of the JCS canonicalisation substrate — validated byte-for-byte across five reference implementations authored by four independent teams. 7 vectors × 5 impls = 35 byte-for-byte agreements for this set.
ImplementationAuthorsLanguageResult
rfc8785@0.1.4William Woodruff (Trail of Bits)Python7/7 JCS bytes + 7/7 hashes + 4/4 pair invariants ✓
canonicalize@3.0.0Samuel Erdtman + Anders RundgrenJavaScript7/7 JCS bytes + 7/7 hashes + 4/4 pair invariants ✓
gowebpki/jcs v1.0.1Web PKI WGGo7/7 JCS bytes + 7/7 hashes + 4/4 pair invariants ✓
cyberphone/json-canonicalizationAnders Rundgren (RFC 8785 author)Java7/7 JCS bytes + 7/7 hashes + 4/4 pair invariants ✓
serde_jcs 0.2.0seritalien (Vauban Pay)Rust7/7 JCS bytes + 7/7 hashes + 4/4 pair invariants ✓ (report)
Five implementations, four non-overlapping author sets, four languages — identical canonical bytes and identical hashes for every vector. The Unicode NFC-vs-NFD pair (the canonicalisation edge case where RFC 8785 implementations most often diverge) agrees byte-for-byte across all five, confirming the no-Unicode-normalisation rule is implementation-independent.

​
References

​
See also

  • A2A is the transport AP2 typically rides on
  • x402 is used inside AP2 for per-call settlement
  • The AP2 spec itself