Background · the standards behind the demos

x402 & AP2, explained

The Igentix demos are built on two emerging open standards for the agent economy — AI agents that discover, buy, and pay for services on their own. x402 covers how an agent's payment executes and settles over the web. AP2 covers the identity, policy, and cryptographic authorization an agent needs to spend a user's money safely. This page explains both, how they fit together, and exactly which parts each demo exercises.

What is x402?

x402 is an open, HTTP-native payment protocol. It revives the HTTP status code 402 Payment Required — reserved in the web's standards since the 1990s but never activated — and turns it into a working payment handshake. It was initiated by Coinbase in 2025 and is now developed openly (x402 Foundation) with a growing multi-chain ecosystem; the demos use its Radix scheme.

The idea: any web resource — an API call, a data feed, an article, a service — can price itself, and any client (human or machine) can pay for it in the same request/response flow it already uses. No account signup, no API keys, no subscription, no card form.

1 · RequestThe client requests a paid resource over plain HTTP.

2 · QuoteThe server answers 402 with machine-readable terms: price, currency (a stablecoin such as USDC), the receiving account, the network.

3 · PayThe client authorizes an exact-amount payment; a facilitator verifies it and settles it on-ledger — and can sponsor the network fee, so the payer needs no gas token.

4 · DeliverThe client presents proof of payment (the X-PAYMENT header) and the server returns the resource.

x402 defines three roles: the client (the paying agent), the resource server (the paid service), and the facilitator (which verifies payloads, settles payments, and optionally sponsors fees). It is deliberately minimal: one call, one exact price, instant settlement. That minimalism is what makes it machine-friendly — an AI agent can complete the whole loop autonomously in seconds.

What x402 does not cover: whether the agent was allowed to make that payment in the first place. That's AP2's job.

What is AP2?

AP2 (Agent Payments Protocol) is an open protocol announced by Google in 2025 with a broad coalition of payments and technology partners. It answers the question every merchant, bank, and user has about agentic commerce: how do you prove a human actually authorized what an AI agent just bought?

AP2's core building block is the mandate — a tamper-evident, cryptographically signed digital credential (technically a verifiable credential in SD-JWT form) that captures what the user authorized, in terms a machine can verify and an auditor can hold up later:

What may be bought — the checkout side: acceptable items, allowed merchants.
How much — a cap per payment and a total budget.
How often — one-off, or a recurrence (e.g. daily, with a maximum number of occurrences).
To whom — an explicit list of allowed payees.
Until when — a validity window outside which the mandate is dead.

Because the mandate is signed with a key bound to the user, it can't be forged or quietly edited; because it travels with the transaction, every party in the chain can verify the same authorization before acting on it. AP2 distinguishes human-present flows (the user confirms a specific cart in the moment) from human-not-present flows (the user delegates in advance — "renew this daily for a month, within these limits" — and the agent acts alone). The second is the hard case, and it is the one the mandate machinery is really for: it gives the ecosystem an accountability chain — non-repudiable evidence of who authorized what — when no human is watching.

AP2 is payment-method agnostic: the same mandates work over card networks, bank transfers, or stablecoin rails. Its published extensions include one that pairs it with x402 for crypto settlement — the exact combination these demos explore.

How they complement each other

x402 moves the money. AP2 proves the human said yes.

They operate on different layers of the same purchase and neither replaces the other. x402 alone settles a payment but says nothing about whether the agent was entitled to make it; AP2 alone authorizes a purchase but doesn't move a cent. Together they form a complete story: the user signs a mandate (AP2) → the agent finds the service and receives priced terms (x402) → the terms are checked against the mandate before paying (AP2) → the payment settles instantly in stablecoin (x402) → the credential and the settlement record form the audit trail (both).

The demos add a third layer the standards leave open: enforcement. An AP2 mandate is authenticated policy — but whoever executes the payment must still choose to honor it. By anchoring the mandate's limits (and a fingerprint of the signed credential itself) into a smart-contract component on the Radix ledger, the limits stop being a promise and become physics: a payment that exceeds them doesn't get flagged, it fails to commit — even if the operator's own servers were compromised. Authorization (AP2) + settlement (x402) + ledger enforcement (Radix) is the thesis the whole demo series builds toward.

Why these demos exist

The demos are a learning and experimentation environment, not a product. Everything runs on Radix's public testnet (Stokenet) — the tokens have no real value, so you can let a real AI agent (your own Claude or ChatGPT, connected over MCP) discover services, negotiate terms, and spend, and watch every step land on a public ledger you can independently inspect.

Learn the protocols by running them — each demo isolates one capability of the x402/AP2 stack and shows it end to end, with the on-chain proof one click away.
Test the guarantees adversarially — several demos include a "try to cheat" step: the agent (or a deliberately misbehaving server) attempts to exceed what was authorized, and you watch the ledger refuse it. A guarantee you can't break is worth more than one you're asked to trust.
Experiment safely — spending is bounded by capped vaults, budgets, and approval thresholds throughout, so an experiment can never run away from you.

How the demos map to the standards

Each demo exercises specific parts of x402 and/or AP2 — and each adds something on top of the standards (marked beyond) that the standards deliberately leave to implementations: receipts, atomic composition, and ledger-level enforcement.

Demo	What it shows	From the standards	Beyond the standards
1 · Buy a single on-chain service	An agent discovers a priced service and pays for it autonomously — holding no gas token of its own.	x402 The exact-amount payment pattern with a fee-sponsoring facilitator: the agent authorizes the spend, the facilitator settles it and pays the network fee.	beyond The agent spends from a capped, revocable on-chain vault — a custody floor the standards don't define: a leaked agent key can never exceed the vault's limits.
2 · Two services, one atomic transaction	Two paid services settle in a single all-or-nothing transaction — both succeed or neither happens.	x402 Two exact payments, same rail as Demo 1.	beyond Atomic multi-service composition. x402 is strictly one-call-one-payment; composing several into one indivisible settlement is a native capability of the underlying ledger, not part of the protocol.
3 · Off-chain service, receipted on-chain	An ordinary internet service (not on any blockchain) is bought and paid in USDC; the ledger keeps the proof.	x402 The complete protocol loop over HTTP: `402` quote with machine-readable terms → stablecoin settlement → proof-of-payment → delivery.	beyond A buyer-countersigned settlement receipt committed on-chain, binding the parties, the agreed terms, the payment, and a fingerprint of what was delivered. x402 explicitly leaves receipts out of scope — yet they're what makes off-chain work non-repudiable.
4 · Ledger-enforced human approval	Routine spending stays autonomous; high-value spending physically cannot move without a human co-signature.	AP2 The "human-present" escalation AP2 assumes for sensitive actions — realized as a hard gate rather than a UI prompt.	beyond The human's authority lives in the account's on-chain access rule, not in application code. The adversarial step: a compromised server submits the agent-only-signed transaction directly — and the ledger rejects it. The same transaction commits once the human co-signs.
5 · Metered micropayments	Many sub-cent, per-request payments that are actually economically viable.	x402 Per-request payment obligations at machine frequency, interoperable with the broader x402 web (e.g. pay-per-request / pay-per-crawl gateways).	beyond An aggregation layer: unit-level obligations accrue off-chain and batch-settle on-chain in one transaction — clearing the fee floor that makes per-call on-chain settlement of sub-cent payments uneconomical.
6 · Recurring subscription under a spend mandate	The delegated, human-not-present agent: the user authorizes once, the agent renews a daily subscription on its own — and can never exceed what was signed.	AP2 The mandate machinery in full: a checkout mandate (what may be bought) and a payment mandate (recurrence, per-payment cap, total budget, allowed payee, validity window) signed as verifiable credentials, and re-verified before every occurrence. x402 Each day's renewal settles through the standard quote → pay → deliver loop, receipted as in Demo 3.	beyond The mandate's limits are mirrored into an on-chain spend-mandate component, with the signed credential's cryptographic fingerprint pinned on-ledger — binding credential and enforcer together. The adversarial step: attempt an extra day, a higher amount, a different payee, or an out-of-window payment, and the ledger rejects it outright.

Honest scope — what the demos do and don't cover

x402 coverage

The demos exercise the protocol's substance — the data model and the settlement mechanics — in a single-operator environment.

Used: the 402 handshake with machine-readable payment terms; the exact-amount scheme; stablecoin (USDC) settlement; fee-sponsored payments (the paying agent holds no gas token); payment-proof delivery; replay protection; a canonical hash of the agreed terms.
Hardened further than the reference: payments are cryptographically verified and simulated against strict spending bounds before settlement — nothing is submitted that would fail or overdraw.
Not covered: the facilitator as a separate public service with its own API (here the roles run under one roof); non-sponsored payments; the multi-chain discovery layer.

AP2 coverage

The demos implement the credential layer faithfully, for the profile that matters most to autonomous agents.

Used: checkout + payment mandates as genuine SD-JWT verifiable credentials (real signatures, selective disclosure, holder key-binding — not mock data); the human-not-present recurring-purchase profile; full verification and constraint-checking before every payment.
Adapted: the user's signing key is a delegated demo key bound to their real wallet account at setup, standing in for a production wallet passkey.
Not covered: AP2's full multi-party ecosystem (separate shopping agents, merchant endpoints, and credential providers exchanging messages agent-to-agent), and card-network settlement — settlement here is on Radix.

Both standards are young and evolving; the demos track them as they advance. Where a demo goes beyond the published specs, this page and the demo descriptions say so explicitly — the extensions (receipts, atomic composition, ledger-enforced mandates and approvals) are the point of the exercise, not accidental drift.