Repository navigation
Replies: 1 comment
|
Answering from the merchant/resource-server side of the wire, since that is the implementation I can speak to directly. Our gate never sees an "order" at all, and I think that is informative for question 3. The check we run is exactly two things: verify the PaymentMandate's ed25519 signature over the canonical mandate JSON, then verify the referenced tx_id settled on-chain (correct receiver, amount, asset). Once both pass, the gate grants access. There is no order object, no fulfillment state, nothing downstream in scope of that check at all. So in this implementation a Payment Receipt (or in our case, a verified PaymentMandate) is strictly evidence of payment. It cannot be evidence of purchase completion, because the component issuing it has no visibility into whether an order was ever created. That is not a gap we could close by adding fields to the mandate either; the merchant's order commit happens in a system the payment gate does not talk to. One sharpening point from being on a settlement rail without an authorize/capture split: once the on-chain tx confirms, there is no window to roll the payment back if the order fails afterward. So the failure case in your post (payment settles, inventory race kills the order) is not just under-specified by AP2, it is structurally outside what a payment layer can prevent on any rail where settlement is final. The recovery has to be a refund flow at the orchestrator/merchant layer, and the Payment Receipt that already issued was correct when it issued; it just answered a narrower question than "did the user get their order." That pushes me toward your option 3: a documented sentence that a Payment Receipt is evidence of payment, not of purchase completion, would be a useful, citable boundary, and it matches what a production payment-side implementation can actually attest to today. |
Uh oh!
There was an error while loading. Please reload this page.
The spec defines Checkout Receipts and Payment Receipts and their distribution ("Upon completion, a Checkout Receipt is returned to the Shopping Agent, and the Payment Receipt is returned to the Shopping Agent, Credential Provider and, if applicable, the Network"), but I couldn't find language about the relationship between a payment receipt and the merchant's order state. Related threads I checked: #277 asks about execution-time revalidation before the action; this question is about what happens after, when the layers disagree. (Adjacent: #258 / #302 on task-level state.)
Concrete failure case: payment authorization and capture succeed; the merchant's order commit then fails (say, an inventory race — the last unit sold concurrently). The payment receipt is valid; the order does not exist; a refund flow starts asynchronously and takes days.
Three questions:
Does AP2 define any artifact or status representing the composed outcome (payment succeeded + order failed), or are Checkout and Payment Receipts intentionally independent attestations of their own layers?
If composition is the orchestrator's responsibility by design, is there guidance — normative or informative — on what a "purchase completed" claim should minimally require? The failure mode I want to avoid: an orchestrator treats a valid Payment Receipt as task success and reports "purchased" for an order that will never ship, while every protocol artifact remains valid.
Narrower version of the same: is a Payment Receipt intended to be interpretable by downstream consumers as evidence of purchase completion, or strictly as evidence of payment? If the latter, would a sentence to that effect in the receipt documentation be in scope? It would give implementers a citable boundary.
Motivation: I'm mapping which completion guarantees an orchestration layer must build above AP2 versus what it can already rely on. The dispute/accountability sections handle after-the-fact evidence well; my question is about the moment of reporting success to the user. Either "intentionally out of scope" or "here's the intended artifact" is a useful answer.
All reactions