[Spec] Concurrent checkout updates can cause silent data loss - need ETag/If-Match support

[alidogankaya]

The Problem

I noticed there's no mechanism to handle concurrent updates to checkout sessions. This can cause silent data loss:

Example scenario:

• User opens checkout in Tab 1, starts editing address
• Same user (or an AI agent) opens checkout in Tab 2, changes quantity
• Tab 1 saves → success
• Tab 2 saves → success, but it just overwrote Tab 1's address change

No error, no warning. The address change is just gone.

This happens because Update Checkout does a "full replacement" (as spec says), but there's no way to detect if someone else modified the resource in between.

When does this actually happen?

• Two browser tabs open (pretty common)
• Phone + laptop at the same time
• AI agent making changes while user is also editing
• Network hiccup causes a retry

Suggestion

Standard HTTP already solves this with ETag/If-Match headers (RFC 7232). Something like:

Response includes a revision:

{
  "id": "chk_123",
  "revision": "r_a8f2e1",
  ...
}

Update request includes If-Match:

PUT /checkout-sessions/chk_123
If-Match: "r_a8f2e1"

If revision changed, return 412:

{
  "status": "requires_escalation",
  "messages": [{
    "type": "error",
    "code": "revision_mismatch", 
    "message": "Checkout was modified by another request.",
    "severity": "recoverable"
  }]
}

This is what Google Cloud APIs do, Stripe does something similar with versioning, etc.

Happy to help

If this makes sense, I can put together a PR with the spec changes. Just wanted to check if this is something you'd consider adding first.