---
key: integrateSeller
path: /integrate-seller
section: integrate
priority: 0.9
title: Seller integration
description: How an x402 selling endpoint attaches its ZadQ attestation to HTTP 402 responses, with graceful degradation for every buyer.
---

# 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
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](/verify) describes what the other side of the
transaction sees.
