Receipt JSON / JWT Schema

The Receipt Schema defines the format for proof-of-payment and license validity that a server or facilitator issues after a successful R402 payment flow.

Receipts serve as portable, verifiable licenses, allowing clients to re-access a resource until expiration without re-paying.

🧩 Root Structure

A receipt may be:

A plain JSON object — simple, human-readable proof
A signed JWT — verifiable, compact token for secure revalidation

Both share the same data fields.

📝 Example: JSON Receipt


{
  "profile": "r402/v1",
  "receipt": {
    "resource": "nft:solana:mint:9abc...xyz",
    "tier_id": "7d",
    "paid": {
      "amount": "2.00",
      "currency": "USDC",
      "chain": "solana",
      "tx": "4sJQd2cA...FyW"
    },
    "rights": ["view", "remix"],
    "valid_from": "2025-10-29T00:00:00Z",
    "valid_until": "2025-11-05T00:00:00Z",
    "issued_at": "2025-10-29T00:00:02Z",
    "issuer": "https://facilitator.fx402.xyz",
    "signature": "<optional detached signature>"
  }
}

🪪 Example: JWT Receipt (Compact Form)


eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJyZXNvdXJjZSI6Im5mdDpzb2xhbmE6bWludDo5YWJjLi4ueHl6IiwidGllcl9pZCI6IjdkIiwicGFpZCI6eyJhbW91bnQiOiIyLjAwIiwiY3VycmVuY3kiOiJVU0RDIiwiY2hhaW4iOiJzb2xhbmEifSwidmFsaWRfdW50aWwiOiIyMDI1LTExLTA1VDAwOjAwOjAwWiIsImlzc3VlciI6Imh0dHBzOi8vZmFjaWxpdGF0b3IuZng0MDIueHl6In0.8rHVs...

🧠 Field Definitions

Field	Type	Required	Description
`profile`	string	✅	Always `"r402/v1"`; protocol version identifier.
`resource`	string	✅	Unique identifier for the licensed resource.
`tier_id`	string	✅	Tier that was purchased (`1d`, `7d`, etc).
`paid`	object	✅	Payment information: amount, currency, chain, transaction ID.
`rights`	array	optional	Usage rights granted (e.g., `view`, `remix`).
`valid_from`	string	✅	Start time for the license window (ISO-8601).
`valid_until`	string	✅	Expiration time (ISO-8601).
`issued_at`	string	optional	When the receipt was generated.
`issuer`	string	optional	URL or DID of the signing service (usually the facilitator).
`signature`	string	optional	Detached cryptographic signature if not using JWT.
`jwt`	string	optional	Compact JWT form of the same receipt (when embedded in JSON).

🔏 Signature Rules

JWT receipts use ES256 (Ed25519 or secp256k1) signatures by default.
Facilitators should embed a public key in their metadata for client-side verification.
Detached signatures or JWTs are optional in honor-mode, but recommended for all verified flows.

⚙️ Validation Logic

Clients should:

Verify valid_until is later than the current time.
Ensure the resource matches the requested asset.
Check the signature or jwt, if present.
Cache the receipt until it expires.