Is this a real payment?
No. Test mode only. The page accepts generic Stripe test numbers and never contacts a payment network. The real artefact is the AffixIO proof.
Live tool · test mode
An AI buying agent asks to charge a Stripe test card. AffixIO authorises the agent (Know Your Agent), checks the card, then stamps a signed proof: simple_yesno plus audit_proof, ML-DSA-65, for every intent. No real charge, ever.
Checking live licence…
The 3D tunnel behind this panel reacts to every payment: idle drift, payment surge, green approval pulse or red decline flash. Drag to orbit, scroll to zoom.
Three.js · drag to orbit · scroll to zoom
Agentic payment flows can sound like a headline from the future, but the shape of one is quite ordinary once you break it down. An AI agent works on your behalf. It reads a request, compares options, and builds a cart. The agent still needs permission to spend, and that is where Know Your Agent enters the picture. Every tool call is checked against an explicit capability, and the result is not a vibe check. It is a decision that can be proven after the fact.
This page turns that idea into something you can click. The buying agent agent://agentic-pay/checkout arrives with a narrow mandate. It may call pay.charge against the stripe://test/* resource group, and nothing else. When you press Pay and Prove, the server verifies that authority, screens the card against Stripe’s generic test numbers, and closes the loop with a signed receipt. Because the whole path is inspectable, you never have to take the agent’s word for anything.
That is the point of a working demo rather than a diagram. Agentic commerce is moving from assisted discovery, through human in the loop checkout, toward autonomous purchasing. Industry estimates already put agent influenced commerce in the trillions of dollars in global volume by the end of the decade. The systems that carry that growth will be judged on trust, and trust in this world is a property you verify, not a promise you extend.
Pick a Stripe test card, set an amount, and let the agent run: KYA authorisation → card checks → signed proof → receipt. Full PANs never leave your browser log redaction. Only the last 4 reach the server.
Know Your Agent checks pay.charge on stripe://test/*.
Waiting…
Luhn, brand, expiry, CVC + Stripe test scenario.
Waiting…
simple_yesno settlement proof + audit_proof, ML-DSA-65.
Waiting…
Licence heartbeat + ledger append (last4 only).
Waiting…
AffixIO proof · live
Four hops, every one inspectable in the receipt above.
The checkout agent presents agent://agentic-pay/checkout with capability pay.charge on stripe://test/*. The server proves allow against simple_yesno. A denial still yields a signed no receipt.
Generic Stripe test numbers only (4242 4242 4242 4242, 4000 0025 0000 3155, 4000 0000 0000 0002…). Luhn, brand, expiry and CVC run first; scenario numbers map to declines. No network charge is ever attempted.
The intent (pi_… + amount + currency + card fingerprint) is proven on simple_yesno via Noir + Barretenberg, attested ML-DSA-65, Merkle-anchored. A second audit_proof binds the decision for reconciliation.
GET /v1/auth/check on api.affix-io.com confirms the agentic-pay key is live. Only intent id, amount, brand and last4 are stored, never the full PAN.
Once an agent can pay without a human at the keyboard, the questions change. It is no longer about whether a model wrote good checkout code. It is about whether the agent had the right to spend, whether it overspent, and whether any party in the loop can dispute the record afterwards. Those questions are answered with verifiable, auditable mandates. A mandate records what the agent is authorised to do, and agent identity separates a trusted agent from an impersonator.
This is where the proof envelope meets the money. Every intent binds a unique intent identifier, the amount, the currency and a fingerprint of the card into a single statement. That statement is proven on the simple_yesno circuit with Noir and Barretenberg, the zero knowledge stack, and signed with ML-DSA-65, the post quantum lattice signature from FIPS 204. The same envelope is Merkle anchored and written to an append only ledger, which makes it tamper evident and replay safe. Reusing a proof on a different amount fails, because the envelope no longer matches the new context.
That combination solves real engineering problems. Idempotency keeps a retried client request from charging a customer twice. Spending caps and budgets bound an agent’s blast radius, so an out of control loop only costs a fixed amount, not everything. Replay protection stops a captured intent from being replayed onto another merchant. And because the verifier only ever sees signed, zero PII verdicts and a licence heartbeat, the privacy story stays intact. The host that owns the decision proves it locally, and nothing personal crosses the wire.
None of this is hypothetical. This page runs the whole flow against a live key on api.affix-io.com, and you can watch each stage complete or fail honestly. That is the difference between an agent that could pay and an agent whose payment can be audited.
Agentic payments and AI payments are not quite the same thing, although people reach for the words interchangeably. Agentic payments describe the event: an AI agent initiating a checkout, a subscription top up, or a scheduled transfer on your behalf. AI payments describe the wider system underneath: the payment rails, the identity layer, and the fraud controls that make a machine initiated payment safe to settle. This page sits at the junction of the two, so the distinction is worth keeping in mind as you explore.
The payment rails in this demo are deliberately boring, and that is by design. Stripe provides generic test card numbers that a developer can rely on without ever touching real money, and AffixIO supplies the proof layer on top. No real network charge is attempted. What you are watching is the shape of the flow, not the plumbing behind a card network or an open banking call. That is enough to learn the pattern and hard enough to respect the problem.
The hard part of AI payments is not moving the money. That part is solved. The hard part is answering four questions on every single transaction: who is the agent, what is it allowed to do, how much may it spend, and can the record be checked later. AffixIO answers those questions with capability gates and signed proofs, which means an AI payment can carry the same audit weight as a payment a human clicked. Machine initiated payments only mature when they stop being an exception and start behaving like every other line on the ledger.
The AI agent economy will reward builders who treat payments as a verifiable claim rather than a black box. When an invoice, a refund, or a recurring charge is produced by software, somebody still has to reconcile it at the end of the month. A proof envelope that binds the intent, survives an audit, and proves exactly what an agent was allowed to do is the practical bridge between autonomous AI and the accountants who close the books.
Straight answers before you wire this into your agent.
No. Test mode only. The page accepts generic Stripe test numbers and never contacts a payment network. The real artefact is the AffixIO proof.
Server-side. The browser calls same-origin /agentic-pay/proxy.php, which forwards to a Node service holding the agentic-pay key from api.affix-io.com. View-source reveals nothing.
The affixio SDK in /var/www/vhosts/SDK (prove-kit over /v1/circuits/…/prove), plus Know Your Agent authorisation for the buying agent. The receipt shows proof id, digest, Merkle root and ML-DSA-65 attestation.
No. Only the last 4 digits, brand, amount and proof id reach the ledger. Full PANs stay in your browser and are never logged.
Yes. The agent still receives a signed no decision, so your reconciliation trail stays complete. The verdict card turns red and the digest still verifies.
Not quite. Agentic payments are the transaction an agent starts. AI payments are the whole system around it: the rails, identity, limits and controls that keep machine initiated money movement safe. This demo uses one handily to explain the other.
Yes. Swap the mock credit card check for your payment processor and keep the proof path. Attach the proof envelope as the idempotency key or metadata on the charge, then verify on the recipient side. Nothing in the flow depends on the demo rails.
KYA turns capability into an auditable mandate. Instead of trusting an agent not to exceed its role, the server proves exactly which action and resource the agent is allowed to use. The authorisation itself becomes a signed decision in the trail.
Point the same proof path at your own rails. Issue a key from the AffixIO hub, attach the proof envelope as the idempotency key or metadata on your payment, then verify on the recipient side. The flow here is a faithful reference for that wiring.