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.Verifiable receipts for AP2
Every exercised AP2 mandate AlgoVoi settles produces a deterministic, offline-verifiable, mandate-bound receipt on the shared JCS canonicalisation substrate: a categorical ALLOW / REFER / DENY compliance receipt at admission and a settlement attestation on-chain, bound by theaction_ref primitive.
Anyone can recompute the canonical bytes and verify the signature years later with the open
receipt verifier, with no live call to AlgoVoi and no customer PII.
See Agentic Payment Receipts for how this works across x402, AP2, A2A and
MPP.
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
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.
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-paymentskill (AP2-compatible verification)create-checkoutskill (agent-initiated AP2 mandate exercise)check-statusskill
Canonicalisation conformance
AP2 mandates carry anopen_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:
v0 conformance vectors
We published a 7-vector reference set anchored to AP2’sopen_checkout_mandate.json schema (sha e3d9cafa), structured as pairs so the canonicalisation rules are self-checking:
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.
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
- v0 conformance vectors gist — the 7 paired vectors with their canonical JCS bytes and expected hashes
- AP2 issue #265 — formal proposal to adopt the v0 set as spec-level conformance fixtures
- AP2 Discussion #262 — full validation history, including the rfc8785 + canonicalize cross-impl runs