The successful payment trap
A common agent-commerce failure mode is treating a successful payment as a successful job. That feels natural because many web products are access-based: pay the fee, unlock the resource, transaction complete. Agent work is different. The buyer often wants an outcome, not merely access.
If an agent pays for a code audit, the payment event says the seller was paid or authorized. It does not say the audit covered the requested repository, found the relevant risks, followed the requested format or met the agreed deadline.
Payment proof is usually local to the rail
A payment proof is shaped by its rail. In x402 it may involve HTTP payment requirements, a payment payload, facilitator verification and settlement. On a chain-based rail it may involve a transaction, note, box, contract call or token movement. In a mock rail it may be deterministic local state for a demo.
Those proofs are important, but they usually answer rail questions: was the payload valid, was the amount sufficient, was the transaction accepted, did the facilitator settle, did the note redeem. They do not carry the full semantics of the work.
Work verification is scoped to an agreement
Work verification needs a different anchor: the Agreement Object. The agreement names the buyer and seller, defines the task, sets the price and deadline, identifies the verifier and explains the acceptance policy. A Verification Receipt can then bind a verdict to that canonical agreement.
That receipt can say accepted, rejected or partially accepted. Each result matters. Rejections are not failures of the protocol; they are useful evidence that the verifier evaluated the work and found it did not meet the terms.
The accounting trail needs both
A system that keeps only payment proof cannot explain why the payment was justified. A system that keeps only verifier output cannot explain whether the economic side settled. Production-grade agent workflows need both records and the relationship between them.
Accord separates Agreement Object, Verification Receipt and Settlement Receipt for exactly this reason. The task, verdict and closeout are different facts and should be inspected independently.
How to design for disputes
Disputes become easier when each artifact is scoped. If the buyer claims the work was wrong, inspect the agreement and verification receipt. If the seller claims payment failed, inspect the rail evidence and settlement receipt. If the agent exceeded authority, inspect buyer policy and payment mandate references.
This is the difference between logs and protocol records. Logs are useful for operators. Protocol records are useful for independent systems trying to reason about what happened.
FAQ
Can a payment protocol include work metadata?
It can include descriptions or references, but payment validation and work acceptance are still different claims with different trust assumptions.
Why not put everything in one receipt?
One combined receipt makes the lifecycle harder to inspect. Separate records let payment, verification and settlement fail or succeed independently.
Is a Verification Receipt objective proof of quality?
No. It records a verifier's verdict under the agreement's rules. The verifier's trust model must still be documented.
Sources and references
Coinbase x402 documentation
Describes x402 as an HTTP payment protocol for programmatic payments and paid API/content access.
Accord Verification Receipt schema
Canonical public schema for Accord v0 verification receipt shape.
Accord Settlement Receipt schema
Canonical public schema for Accord v0 settlement receipt shape.
Inspect the receipt schemas
Separate payment proof, verification verdict and settlement evidence in your implementation.