x402 Integration

This section is advisory and non-prescriptive. The illustrations describe current possibilities and limitations rather than canonical shapes. The x402 Foundation is invited to publish authoritative LCP integration guidance for the protocol.

What it is

An HTTP-402-based payment protocol. Version 2 defines forward-compatible extension points in the PaymentRequired response: per-requirement accepts[].extra and a top-level extensions object. Unknown keys are ignored by conforming clients.

Tier A — Available today

LCP fields ride inside accepts[].extra or top-level extensions:

{
  "x402Version": 2,
  "accepts": [{
    "scheme": "...",
    "network": "...",
    "extra": {
      "atrHash": "0x7f83b165...",
      "legalContextUrl": "https://example.com/.well-known/legal-context.json"
    }
  }],
  "extensions": {
    "legalContext": { "type": "sha256", "value": "0x7f83b165..." }
  }
}

A custom response header (e.g. X-LCP-Hash) is also viable on any HTTP-based rail, including v1 deployments that lack the extensions field.

Tier B — Forward work

The x402 v2 receipt schema (PAYMENT-RESPONSE) does not currently include extension points for receipt-level metadata. A first-class legalContext receipt field requires an upstream specification change.

Limitations

The extra and extensions blocks are HTTP-layer carriers — they do not, by themselves, commit the value to the settlement transaction. On-chain binding depends on the chosen settlement primitive and the binding pattern selected for that primitive. The portability of unknown keys across facilitators rests on convention, not normative specification.

Steward invitation

The x402 Foundation is invited to publish authoritative guidance on placement of atrHash inside extra and extensions, on receipt-level extension points, and on the relationship between HTTP-layer carriers and on-chain binding patterns.