Problem
When an AI agent makes a purchase that doesn't match user intent, no existing chargeback reason code covers it. The payment was authenticated, authorized, and completed — no fraud occurred. But the agent acted outside the scope the user granted.
Traditional chargeback codes (Visa 13.x, Mastercard 48xx) assume a human authorized a transaction. Agent commerce introduces a new failure mode: the agent was legitimately authorized to transact, but the specific purchase fell outside the authorized scope.
Opportunity
The v2 grant model (#179) creates the opening to close this gap. A grant carries the authorization scope (aud, scope, constraints, exp), and the receipt's ack binding ties each payment back to the grant that authorized it. Both legs of the evidence — what was authorized and what happened — are now signed artifacts with a cryptographic binding between them.
What's missing is a machine-readable format for the mismatch between them, and a verification path a third party can walk without callbacks to either side.
Sketch
A dispute+jwt artifact (registered in core's Section 9 table) signed by the disputant (the grant issuer). It embeds the grant and receipt in full, and carries a structured delta — which grant constraint was violated, the authorized value, and the actual value. A resolver verifies mechanically: extract the named field from each embedded artifact and confirm the values don't match.
Four reason codes, all mechanically verifiable from the embedded artifacts:
scope-exceeded — amount, recipient, or constraint violationgrant-expired — grant's exp preceded the receipt's iataudience-mismatch — payment to a counterparty not in the grant's audunauthorized-agent — receipt names a different agent than the grant authorized
Codes intentionally excluded (can't be mechanically verified from the artifacts alone): category mismatch, revoked grants, no-grant scenarios.
Full proposal
A complete working draft with spec, diagrams, claim tables, verification checklist, security considerations, and a running jose example:
agent-payments-research/dispute-resolution
This proposal is part of a cross-protocol effort — the same evidence architecture has been adapted for MPP and x402.
Dependencies
This depends on the v2 grant model and receipt ack binding from #179. The spec is written against v2's artifact shapes — it can't land before core does. Happy to restate once the claim shapes settle.
Relationship to open decision #2
The pay core RFC's open decision #2 asks whether buyers should retain offers. This extension strengthens the case for retention: without the embedded payment request, a resolver can't verify amount-based deltas.
This issue was prepared with AI assistance (Claude Code).
Problem
When an AI agent makes a purchase that doesn't match user intent, no existing chargeback reason code covers it. The payment was authenticated, authorized, and completed — no fraud occurred. But the agent acted outside the scope the user granted.
Traditional chargeback codes (Visa 13.x, Mastercard 48xx) assume a human authorized a transaction. Agent commerce introduces a new failure mode: the agent was legitimately authorized to transact, but the specific purchase fell outside the authorized scope.
Opportunity
The v2 grant model (#179) creates the opening to close this gap. A grant carries the authorization scope (
aud,scope,constraints,exp), and the receipt'sackbinding ties each payment back to the grant that authorized it. Both legs of the evidence — what was authorized and what happened — are now signed artifacts with a cryptographic binding between them.What's missing is a machine-readable format for the mismatch between them, and a verification path a third party can walk without callbacks to either side.
Sketch
A
dispute+jwtartifact (registered in core's Section 9 table) signed by the disputant (the grant issuer). It embeds the grant and receipt in full, and carries a structured delta — which grant constraint was violated, the authorized value, and the actual value. A resolver verifies mechanically: extract the named field from each embedded artifact and confirm the values don't match.Four reason codes, all mechanically verifiable from the embedded artifacts:
scope-exceeded— amount, recipient, or constraint violationgrant-expired— grant'sexppreceded the receipt'siataudience-mismatch— payment to a counterparty not in the grant'saudunauthorized-agent— receipt names a different agent than the grant authorizedCodes intentionally excluded (can't be mechanically verified from the artifacts alone): category mismatch, revoked grants, no-grant scenarios.
Full proposal
A complete working draft with spec, diagrams, claim tables, verification checklist, security considerations, and a running
joseexample:agent-payments-research/dispute-resolution
This proposal is part of a cross-protocol effort — the same evidence architecture has been adapted for MPP and x402.
Dependencies
This depends on the v2 grant model and receipt
ackbinding from #179. The spec is written against v2's artifact shapes — it can't land before core does. Happy to restate once the claim shapes settle.Relationship to open decision #2
The pay core RFC's open decision #2 asks whether buyers should retain offers. This extension strengthens the case for retention: without the embedded payment request, a resolver can't verify amount-based deltas.
This issue was prepared with AI assistance (Claude Code).