draft-hopley-x402-refund-receipt (POSTED on IETF datatracker; revision -01 POSTED 2026-05-25), and published as a standalone reference implementation:
- Python:
algovoi-refund-receipt(live, v0.1.0)
algovoi-substrate / @algovoi/substrate for the JCS canonicalisation primitive. Apache 2.0.
Why this format
Refund events are state transitions that carry distinct regulatory significance from the original payment. A refund receipt format that collapses the outcome to a continuous percentage-of-original representation loses the load-bearing operational distinction:- Under UK Consumer Rights Act 2015 and EU Consumer Rights Directive 2011/83/EU Article 9, only a FULL refund within the statutory window closes the consumer’s right to further remedy.
- Under PSD2 (Directive 2015/2366) Article 89, a payer denied a refund must receive a documented denial — operationally distinct from a PARTIAL refund where some-but-not-all of the original amount has been returned.
- Under UK POCA 2002 and EU AML Directives 5/6, a refund triggered by post-settlement sanctions or fraud detection requires audit-chain linkage back to the original compliance receipt for retention-period audit by competent authorities.
Receipt shape
A refund receipt is a seven-field JSON object canonicalised under RFC 8785 (JCS). Field names are sorted lexicographically by JCS during canonicalisation.The closed enumeration: refund_result
Each value produces a byte-distinct
content_hash from the other two. Implementations MUST reject any other value at validation time before canonicalisation.
Composition with compliance receipts
A refund receipt’soriginal_payment_ref MAY reference the content_hash of a compliance receipt. The two receipts compose into one audit-chain segment recording the full admission-through-refund lifecycle:
original_payment_ref; (c) the chain rows preserve hash-linkage with no truncation or reordering.
Conformance vectors
Eight byte-level reference vectors + five pair invariants + three chain invariants are published atalgovoi-jcs-conformance-vectors/vectors/refund_receipt_v1/.
The canonicalisation layer underneath the refund receipt is the same JCS RFC 8785 layer covered by the 8-implementation cross-validation attestation dated 2026-05-24. The refund receipt’s content_hash reproduces byte-identical under any of the eight implementations (Python, TypeScript, Go, Rust, Java, PHP, .NET, Ruby).
Quick start
Python
TypeScript
What this is NOT
- Not a dispute resolution protocol. Disputes are multi-party state machines. The refund receipt records one state transition; orchestration is operator-layer.
- Not a cross-network settlement attestation. A refund receipt MAY refund in a different asset than the original payment (e.g. paid USDC on Base, refunded USDC on Solana), but the cross-chain mechanism is out of scope of this format.
- Not a chargeback / interchange format. ISO 8583 and ISO 20022 message families cover card-network chargeback. This format applies to agentic-payment receipts.
- Not the only refund format. Operators MAY emit richer receipts with additional internal fields. This format specifies the minimum byte-load-bearing surface required for cross-implementation verifiability.
Companion IETF Internet-Draft
draft-hopley-x402-refund-receipt (Independent Submission, Informational) is the canonical specification. AlgoVoi-authored, sole authorship. The draft pins urn:x402:canonicalisation:jcs-rfc8785-v1 and specifies the seven-field receipt format, audit-chain composition, and year-N auditability properties.
See also
- Canonicalisation substrate — the JCS RFC 8785 + Substrate Rule 2 discipline
- Conformance vectors — the full vector corpus
- Audit verifier — selective-disclosure audit-chain verifier
- Substrate authorship and provenance — citable record of AlgoVoi-authored substrate artefacts