Vendor-neutral draft: after x402 settlement, a payment protocol may optionally reference a fiscal artifact by type, version, URI, and hash. Not an official x402 standard. Not submitted.

DRAFT — not submitted — not an x402 standard

This page is a vendor-neutral sketch. It is not an official x402 extension, not a Fiscal402 product claim, and it has not been submitted to the x402 Foundation.

Problem

After an exact transfer settles, downstream fiscal systems need a way to find a fiscal artifact without making any one vendor mandatory. Payment protocols should not embed a tax engine. They may optionally point at evidence.

Proposed optional metadata

After settlement, a payload may include an optional object:

fiscal_artifact.json

{
  "type": "fiscal-artifact",
  "spec": "fiscal402.receipt",
  "version": "1.0.0",
  "uri": "https://api.example.com/v1/receipts/rcpt_…",
  "hash": "sha256:…",
  "issuer": "https://api.example.com/.well-known/jwks.json"
}

Rules that keep this vendor-neutral

type, version, uri, hash, issuer are the only required conceptual fields.
Absence of the object is valid. Fiscalization is optional.
The payment protocol does not verify tax. Verifiers of the fiscal object do.
Any issuer that publishes a receipt spec and JWKS can fill this, not only Fiscal402.

Optional fiscal artifact reference after settlement

Problem

Proposed optional metadata

Rules that keep this vendor-neutral