Seller integration

This guide describes how an operator of an x402 selling endpoint attaches its attestation once admitted. The integration is additive: it extends responses the endpoint already sends, and buyers that ignore the extension keep working unchanged.

Prerequisites

• An admitted operator. Admission runs off the transaction path, once: an

authorised issuer reviews the legal entity and the operator deposits the financial guarantee bond.

• The signed credential issued on admission, binding the operator and bond

to the endpoint identifiers.

Attaching the attestation

The seller's middleware attaches the attestation to the HTTP 402 response as an additive identityPolicy extension. A response without the extension remains a valid x402 response; a response with it gives the buyer the option to verify before paying.

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "accepts": [ ... ],
  "identityPolicy": {
    "attestation": "<compact signed payload>",
    "verdictHint": "<optional inline verdict>"
  }
}

The companion request header X-PAYMENT-IDENTITY lets either side carry proof in both directions when a transport does not surface response extensions.

What the middleware guarantees

• Additive only. No existing field changes meaning; buyers unaware of

the extension are unaffected.

• No round-trips added. The attestation rides on responses the endpoint

already sends; attaching it adds no network calls to the payment flow.

• Stateless. The credential is signed material; the middleware holds no

session and calls no external service to attach it.

Renewal

Attestation freshness is bounded by a renewal cadence promised in the credential itself. The middleware refreshes the signed material on that cadence; a buyer checks freshness against the same promise, so an endpoint that stops renewing degrades to unknown on the buyer side — it does not break.

Next: buyer verification describes what the other side of the transaction sees.