Signed, portable evidence for merchant accept/refuse decisions?

[terryncew]

When an agent presents valid buyer authorization but the merchant independently accepts or refuses the requested action, is there a standard way for that merchant decision to become signed, portable evidence rather than remaining local checkout state?

[ECD5A]

There is a signed-response mechanism already. The catch is that it isn't required for every refusal.
In the 2026-08-25 Message Signatures spec, a merchant can sign an HTTP response using RFC 9421. The covered components include @status and, when there is a body, content-digest and content-type. Payment authorization and checkout completion response signatures are recommended, but signatures on 4xx/5xx errors are optional. So a signed refusal is possible; an ordinary error response is not automatically that evidence.
AP2 adds another piece: once negotiated, checkout responses must include ap2.merchant_authorization. That's a detached JWS over the JCS-canonicalized checkout, excluding ap2. It covers the returned checkout state, including status. An earlier signature on ready_for_complete should not be mistaken for a later acceptance or refusal.
For portable evidence, I'd keep the actual response body, signature metadata and a trusted record of the merchant's signing key. I'd also check the request binding: the basic response signature covers status/body, but doesn't require a reference to the particular buyer authorization or request. If that's what your verifier needs to prove, that reference has to be inside what the merchant signs, not just in the local checkout log.
So yes at the signed-response level. I wouldn't read it as a universal standalone accept/refuse receipt, or as proof that payment or fulfillment actually happened. This is from the spec/schema reading; I haven't tested a live merchant flow.

[terryncew]

Yes. That's the binding the verifier needs. A signed response proves the merchant answered something, but without a reference to the specific buyer authorization, it doesn't prove which authorization was accepted or refused. The decision can't travel as evidence. It stays local.

The shape I use: the receiver signs its decision, accept or refuse, over the mandate it evaluated: the authorization, its scope, and the request it answered. A verifier later gets the decision and what it was a decision about, without trusting the merchant's log.

That's the OpenLine receipt: https://github.com/terryncew/openline-wallet

Demonstrated against my own receiver gates. I haven't run it against a live UCP merchant. Open question is where the mandate reference would cleanly fit in the checkout object: alongside ap2.merchant_authorization, or somewhere else.

[ECD5A]

One placement gotcha: if you want merchant_authorization itself to cover the mandate reference, putting that reference inside ap2 won't do it. The whole ap2 object is excluded from the signed checkout payload (canonicalization rule).
For an independently signed decision receipt, I'd lean toward a separate extension rather than overloading ap2. Its verifier would check the receipt's own signature and mandate/request binding. Being placed next to merchant_authorization would not establish that binding by itself. I haven't reviewed OpenLine's implementation, so this is only about the UCP signature coverage.