Why architecture matters here

Payment intent architecture matters because it makes the request auditable and verifiable. A structured intent captures amount, merchant, product, and reason in a way a user can review and a system can validate. Free-form "please pay" requests can't be safely automated.

Cost is minimal — the intent is small structured data.

Reliability comes from signing + evidence. Attackers who tamper produce invalid signatures; users who dispute have evidence to reference.

Advertisement

The architecture: every piece explained

Walk the diagram top to bottom.

Agent. Wants to pay for something on the user's behalf.

Structured Intent. Amount, currency, merchant, product/service, reason. Structured JSON per AP2 spec.

User Review. Human sees the intent, approves or rejects. For low-risk small amounts may be pre-authorized.

Evidence. Screenshots, product URL, price references. Attached to intent to justify.

Signed Intent. Once approved, signed by the user (via wallet) and possibly by the agent. Non-repudiation.

Wallet Auth. Wallet verifies signed intent matches agent's scoped token; checks limits.

Fraud Score. Velocity, merchant risk, geo, amount pattern. Score gates or elevates for review.

Execution. Payment rail (card, ACH, crypto) processes.

Receipt + Audit. Immutable trail of intent + approval + execution + result.

Dispute Path. User claims unauthorized. Evidence + signed intent decide.

Agentwants to payStructured Intentamount + merchant + reasonUser Reviewhuman sees + approvesEvidencescreenshots + product refsSigned Intentprovenance + non-repudiationWallet Authscoped token checkFraud Scorevelocity + merchantExecutionpayment railReceipt + Auditimmutable trailDispute Pathconsumer protectionEvery payment starts as a structured intent + explicit approval
AP2 payment intent architecture: agent creates structured intent with evidence → user reviews + approves → signed intent → wallet + fraud → execution → receipt + audit + dispute path.
Advertisement

End-to-end intent flow

Trace an intent. Agent identifies a hotel to book. Creates intent: { amount: 200 EUR, merchant: "Hotel Munich", product: "1 night 2026-08-15", reason: "trip approved by user", evidence: {hotel_url, screenshot} }.

User's phone shows the intent. Reviews: correct dates, correct amount, hotel matches expectation. Approves via biometric.

Wallet signs the intent with user's key. Sends signed intent to fraud detector; low risk. Passes.

Wallet issues a virtual card + charge to Hotel Munich's rail. Card rail succeeds; receipt returned.

Audit log records: intent, signed approval, fraud score, execution, receipt. All time-stamped, cross-referenced.

Two months later, user disputes: "I didn't approve this hotel." Signed intent shows approval was made from user's device with biometric. Dispute closed.

Alternative: agent creates intent for wrong hotel. User reviews, rejects. Intent aborted. No charge.