AFFIXIO
AP2 verification
AP2 Agent Payments Protocol verification
The AP2 Agent Payments Protocol defines how agents express payment intent. Merchants and orchestrators still need a verifier-checkable gate that confirms policy before funds move. AffixIO sits beside AP2 as a signed allow or deny layer, bound to agent identity, amount scope, and expiry, with zero PII at the verifier by default.
Definition
AP2 verification is a signed cryptographic outcome that an agent was permitted to initiate a payment under stated policy at the AP2 boundary, without copying payer credentials into every merchant system.
Field note. AP2 checkout without upstream verify produces agent chargebacks your team cannot defend with protocol logs alone.
Where AffixIO sits beside AP2
Keep AP2 for agent payment messaging and discovery. Add AffixIO verify immediately before authorisation: issue a short-lived permission proof when consent is granted, verify at checkout, gate on signed allow or deny. Payment rails stay unchanged. AffixIO answers whether this agent may attempt this spend under policy right now.
The flow follows Issue, Bind, Present, Verify. Noir circuits can encode predicates such as amount caps and merchant category without exporting raw attributes to the verifier. ML-DSA-65 signs the outcome. Merkle audit refs travel with the transaction record.
Operational wiring for agentic commerce
Orchestrators that already route AP2 traffic add a verify call at the payment edge. On deny, the checkout stops before the PSP sees an authorisation request. On allow, store the Merkle reference with the order for chargeback and AML review.
Test the full path in the sandbox with payment-policy circuits before production. Map the same verify endpoint to treasury transfers if agents initiate outbound payments, not only card checkout.
Integration notes for AP2 payment verification
Wire AffixIO verify immediately before the boundary where AP2 payment verification applies: checkout authorisation, MCP tool invocation, age gate, or offline scan. Issue proofs when policy is satisfied. Present at the edge. Gate on signed allow or deny.
Train support on deny retrieval: Merkle ref lookup should not require engineering access. Document which circuit version was active when the proof was issued.
Circuit complexity
Protocol messages are not payment permission
AP2 carries intent and metadata. It does not replace a defensible authorisation record that auditors and issuers can re-check when a charge is disputed.
Intent without policy binding
An agent can emit a valid AP2 message that exceeds the user consent scope or merchant class you approved.
Replay across sessions
Without spent-proof or nonce binding, the same payment intent artefact can be presented twice at different checkouts.
Weak dispute evidence
Logs of protocol traffic do not prove a policy engine returned allow at authorisation time.
Identity sprawl at merchants
Copying payer records into every AP2 participant multiplies PII risk without improving the gate signal.
Proof flow
Wire AffixIO verify before AP2 authorisation
AP2 agent payment flows need verify one hop before authorisation so deny stops capture before side effects. Issue proofs when user policy passes and present at the AP2 checkout boundary.
Map AP2 payment edges
List where agents present payment intent: checkout, wallet top-up, subscription renewal.
Define permission policy
Encode limits, consent scope, agent binding, and expiry in the circuit you issue against.
Verify before authorisation
Gate on signed allow or deny at the AP2 boundary before the PSP authorises.
Attach Merkle audit refs
Store proof metadata with the payment record for later dispute defence.
Ops sign-off
Readiness checks for AP2 payment verification
- Confirm AP2 message paths that reach live authorisation.
- Replace shared agent secrets with scoped permission proofs.
- Enable spent-proof where replay must be blocked.
- Confirm zero PII retention at verifier endpoints.
- Run deny paths in sandbox before go-live.
Integration FAQ
Questions on AP2 payment verification
Does AffixIO replace AP2?
No. AffixIO verifies permission outcomes beside AP2 messaging. Protocol traffic and verification gates serve different jobs.
What proof does the merchant receive?
Signed allow or deny plus Merkle audit metadata, not a copy of payer identity documents.
Can this work with existing PSPs?
Yes. AffixIO sits at the permission boundary. PSPs still process payments.
How do we test AP2 verification paths?
Route sample AP2 payment intents through sandbox verify before your PSP stub. Confirm deny stops authorisation and allow stores Merkle metadata on the order.
Cross-links
Pages that support AP2 payment verification
Agentic payments
More agentic payments briefs
Test AP2 payment verification
Run issue and verify on AP2 hooks in sandbox, then map the same gate to production authorisation.