Categorical Refund Receipt Format for Agentic-Payment Flows

1.1. Motivation

Agentic-payment flows generate two classes of receipt over the lifecycle of a transaction: admission-time receipts (compliance screening, payment authorisation, mandate verification) and post-settlement receipts (settlement confirmation, refund, dispute resolution).¶

A refund is a state transition that creates a new record on the post-settlement chain: funds previously transferred to a payee are returned in full, in part, or the return request is denied. The operational and regulatory significance of this state transition is load-bearing:¶

• Under UK Consumer Rights Act 2015 and EU Consumer Rights Directive 2011/83/EU Article 9, a FULL refund within the statutory window closes the consumer's right to further remedy.¶
• Under PSD2 (Directive 2015/2366) Article 89, an unauthorised payment must be refunded immediately or rejected with documented reasons. A REJECTED outcome creates dispute-evidence obligations distinct from a FULL or PARTIAL outcome.¶
• Under UK POCA 2002 and EU AML Directives 5/6, a refund triggered by post-settlement sanctions screening or fraud detection requires audit-chain linkage to the original compliance receipt for retention-period audit by competent authorities.¶

A receipt format that collapses these distinctions to a continuous amount-only representation loses the load-bearing operational distinction.¶

This document specifies a refund receipt format that preserves the categorical outcome at the canonical-bytes level. The same canonicalisation discipline and audit-chain semantics as draft-hopley-x402-compliance-receipt apply, so a verifier can use one implementation to walk the entire payment lifecycle.¶

1.2. Scope

This document specifies:¶

• The canonical JSON shape of the refund receipt (Section 3)¶
• The canonicalisation rule applicable to the receipt (Section 4)¶
• The audit chain composition under which refund receipts compose with compliance receipts and settlement records (Section 5)¶
• The year-N auditability properties the format pins (Section 6)¶
• Worked examples covering FULL, PARTIAL, and REJECTED outcomes (Appendix A)¶
• Reference implementations and conformance vectors (Appendix B)¶

The document does NOT specify:¶

• The refund orchestration protocol (operator-layer concern; out of scope)¶
• Dispute-resolution state machines (a refund receipt records one state transition; multi-party dispute orchestration is a separate problem class)¶
• Cross-chain settlement mechanisms (an asset substitution between original payment and refund is permitted in the receipt format but the bridge mechanism is out of scope)¶
• Card-network chargeback or interchange formats (ISO 8583 / ISO 20022 message families serve that purpose)¶

1.3. Relationship to other Internet-Drafts

This document is one of a coordinated suite of five AlgoVoi-authored receipt and response format Internet-Drafts, all anchoring to the canonicalisation discipline specified in draft-hopley-x402-canonicalisation-jcs:¶

• draft-hopley-x402-canonicalisation-jcs -- the JCS canonicalisation discipline pinned by Section 4 of this document.¶
• draft-hopley-x402-compliance-receipt -- admission-time compliance screening receipt. A refund receipt's original_payment_ref MAY equal the content_hash of the compliance receipt that admitted the original payment.¶
• draft-hopley-x402-settlement-attestation -- per-settlement categorical attestation. A refund receipt's original_payment_ref MAY equal the content_hash of a settlement attestation when the refund reverses a previously-SETTLED payment.¶
• draft-hopley-x402-cancellation-receipt -- the mandate cancellation receipt format. A USER_REQUESTED cancellation under PSD2 Article 64 MAY chain forward to a refund receipt on the audit chain when Article 64 refund obligations attach to a recently-settled debit.¶
• draft-hopley-x402-composite-trust-query -- verifier-side composite-trust-query response format. A verifier walking an audit chain containing a refund receipt emits a single composite-trust response over the chain.¶

The five formats share the same canonicalisation pin, audit chain row shape, integer-millisecond timestamp encoding (Substrate Rule 2), jurisdiction_flags ordering convention, and closed-enumeration discipline. A verifier walking the full payment lifecycle requires only one implementation of the canonicalisation discipline.¶

1.4. Relationship to draft-vauban-x402-stark-receipts

draft-vauban-x402-stark-receipts covers cryptographic settlement-time payment-condition proofs (STARK receipts). The refund receipt specified in this document MAY reference a STARK receipt as its original_payment_ref value: when a payment that was settled with a STARK proof is subsequently refunded, the refund receipt links back to the STARK-receipt content_hash and the verifier walks the chain across both formats under one canonicalisation pin.¶

2.1. Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Definitions

refund receipt: a JSON object of the shape specified in Section 3, canonicalised under the discipline specified in Section 4.¶

content_hash: SHA-256, lowercase hex, of the JCS-canonical bytes of the receipt object.¶

original_payment_ref: a string of the form sha256:<lowercase-hex-64> identifying the original payment record by content hash. The original record MAY be a compliance receipt, a settlement attestation, or an operator-specific payment record.¶

refund_amount: a two-field object {amount_minor, asset_id} representing the refunded value. amount_minor is a decimal-digit string in the asset's minor unit; asset_id identifies the asset and its decimal precision.¶

canon_version: an in-band string identifying the canonicalisation discipline. Fixed value jcs-rfc8785-v1 for this version.¶

audit chain row: a four-field object linking receipts via SHA-256 hash chain, shape specified in Section 5.1.¶

3.1. refund_result

A string-valued field. The value MUST be one of:¶

• FULL -- the entire original payment amount has been returned to the payer.¶
• PARTIAL -- less than the original payment amount has been returned. The refund_amount field carries the actual refunded value; the verifier compares against the original via original_payment_ref linkage.¶
• REJECTED -- a refund request was processed and denied. No funds moved. The receipt records the denial event so downstream dispute / chargeback chains can reference it.¶

The three-element enumeration is closed. Implementations MUST reject any other value at validation time before canonicalisation. Score, percentage, or amount-only projections are not acceptable substitutes for the categorical outcome.¶

The regulatory distinction is load-bearing. Under PSD2 (Directive 2015/2366) Article 89, a payer denied a refund (REJECTED) must receive a documented denial; this is operationally distinct from a PARTIAL refund where some-but-not-all of the original amount has been returned. 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. A percentage or amount-only representation cannot preserve these distinctions.¶

3.2. jurisdiction_flags

An ordered array of string-valued ISO-3166-1 alpha-2 country codes or alpha-3 region codes identifying the applicable regulatory frameworks for the refund event.¶

Authoring convention: primary jurisdiction first (where the operating entity is licensed), secondary jurisdictions in order of regulatory precedence.¶

Array element ORDER is SIGNIFICANT and load-bearing. RFC 8785 does not normalise array order during canonicalisation. The array ["UK", "EU"] and the array ["EU", "UK"] produce byte-distinct canonical representations and distinct content_hash values.¶

3.3. original_payment_ref

A string-valued field of the form sha256:<lowercase-hex-64>. The hex digest is SHA-256 of the JCS-canonical bytes of the original payment record being refunded.¶

When refunding a payment that was admitted under a compliance receipt (per draft-hopley-x402-compliance-receipt), the original_payment_ref MAY equal the content_hash of the compliance receipt itself. This is the conventional choice and enables the audit-chain composition described in Section 5.¶

When refunding a payment that was settled with a STARK proof (per draft-vauban-x402-stark-receipts), the original_payment_ref MAY equal the content_hash of the STARK receipt.¶

Implementations MUST NOT strip the sha256: prefix during canonicalisation or verification. The prefix is part of the canonical bytes.¶

3.4. refund_amount

A sub-object with exactly two fields:¶

• amount_minor -- a string of decimal digits representing the refunded value in the asset's minor unit. String typing avoids float-precision loss and JavaScript-integer-overflow concerns for large values, and is representable losslessly under JCS.¶
• asset_id -- a string identifying the asset and its decimal precision. Convention: <symbol>.<decimals> for chain-native assets (e.g. USDC.6, ALGO.6, ETH.18); <chain>:<asset_id>.<decimals> for ASA-style assets (e.g. algo:31566704.6).¶

The sub-object's keys are sorted lexicographically by RFC 8785 during canonicalisation: amount_minor then asset_id. Verifiers MUST treat {"amount_minor":"100000","asset_id":"USDC.6"} as equivalent to the same content produced by an authoring layer that emitted fields in asset_id-first order; JCS canonicalisation removes the distinction.¶

For a PARTIAL refund, refund_amount carries the actual refunded value. For a FULL refund, refund_amount carries the entire original payment amount. For a REJECTED refund, refund_amount carries the amount that WOULD have been refunded had the request been accepted (the requested-but-denied amount), enabling the denial-evidence chain to capture the operational claim.¶

Cross-asset refunds (where the refund asset differs from the original payment asset, e.g. paid in USDC on Base, refunded in USDC on Solana) are permitted: refund_amount.asset_id MAY differ from the asset of the original payment. The cross-chain mechanism by which the substitution is achieved is out of scope of this document.¶

3.5. refund_provider_did

A string-valued DID URI identifying the entity issuing the refund. For Verifiable-Credentials-class identities this is the issuer DID; for centralised gateway-class identities this is did:web:<host>.¶

3.6. refund_timestamp_ms

An integer-valued field carrying the epoch-millisecond timestamp of the refund event in UTC.¶

This field MUST be an integer in the canonical receipt. RFC 3339 string forms (e.g. "2026-05-28T12:00:00Z") MUST be rejected at the validation layer before canonicalisation; silent type-coercion breaks year-N auditability and cross-implementation byte-determinism.¶

The integer-only restriction is required because RFC 8785 canonicalises the integer 1716494400000 and the string "1716494400000" to distinct canonical-bytes representations. A receipt format that accepted both forms could produce two byte-distinct receipts for the same logical refund event, breaking the dedup and audit-chain linkage properties.¶

This rule is formalised in x402-foundation/x402 pull request #2436 (canonicalisation discipline), normatively specified in draft-hopley-x402-canonicalisation-jcs Section 4.1, and is referred to in the AlgoVoi substrate as Substrate Rule 2.¶

3.7. canon_version

A string-valued in-band canonicalisation rule pin. For this version of the receipt format the value MUST be jcs-rfc8785-v1.¶

The pin enables year-N re-verification from retained bytes alone. A future revision of the canonicalisation discipline MAY introduce a successor pin (e.g. jcs-rfc8785-v2); a verifier reading a receipt with the successor pin applies the corresponding rule. The pin is itself canonicalised and signed-over so it cannot be silently re-narrated post-emission.¶

5.1. Chain Row Shape

An audit chain row is a JSON object with four fields:¶

{
  "row_number": 1,
  "content_hash": "<hex64>",
  "prev_hash": "<hex64>",
  "row_content_hash": "<hex64>"
}

• row_number: integer, 1-indexed.¶
• content_hash: SHA-256, lowercase hex, of the JCS-canonical bytes of the receipt object anchored by this row.¶
• prev_hash: SHA-256, lowercase hex, of the previous row's row_content_hash. For row 1, prev_hash MUST be 64 zero hex characters (0000...0000).¶
• row_content_hash: SHA-256, lowercase hex, of the JCS-canonical bytes of this row object (with row_content_hash itself excluded from the JCS computation; the row's first three fields {row_number, content_hash, prev_hash} are canonicalised and hashed to produce row_content_hash).¶

This row shape is identical to the audit-chain row shape specified in draft-hopley-x402-compliance-receipt Section 5.1. The two documents pin the same chain composition so receipts of either class can be linked into one verifiable chain.¶

5.2. Linkage Verification

A verifier reading a chain segment performs these checks:¶

• For each row, recompute the row's row_content_hash from its first three fields under JCS and compare against the stored value. Mismatch indicates row tampering.¶
• For each row N > 1, check that row N's prev_hash equals row N-1's row_content_hash. Mismatch indicates chain truncation, reordering, or row deletion.¶
• For row 1, check that prev_hash is 64 zero hex characters (the chain genesis anchor).¶
• For each row, optionally fetch the receipt body whose content_hash is referenced and verify the body re-canonicalises to the same hash. This step is required for receipt-level audit but optional for row-level chain integrity.¶

A chain that passes all of the above is byte-deterministically verifiable from retained bytes alone, with no dependence on the originating gateway's continued operation.¶

5.3. Composition with Compliance Receipts

When a refund receipt references a compliance receipt via original_payment_ref, the audit-chain composition is:¶

chain row N      chain row N+1
+------------+   +------------+
| compliance |-->| refund     |
| receipt    |   | receipt    |
| (content_  |   | (content_  |
|  hash)     |   |  hash)     |
+------------+   +------------+

Row N anchors the compliance receipt (admission decision). Row N+1 anchors the refund receipt; the refund receipt's original_payment_ref equals the content_hash of the compliance receipt anchored by row N. The chain row N+1's prev_hash equals row N's row_content_hash. A verifier walking this segment confirms:¶

1. The compliance receipt admitted the original payment.¶
2. The refund receipt links to that admission via original_payment_ref.¶
3. The chain rows preserve hash-linkage with no truncation or reordering.¶

The same composition extends to longer chains: multi-leg PARTIAL refunds, refund reversals (refund-of-refund), and disputed REJECTED refunds with subsequent re-evaluation each contribute one or more rows to the chain.¶

5.4. Retention Storage

Retention storage of refund receipts and their audit chains is out of scope of this document. Operators MUST retain receipts for the period required by applicable regulatory frameworks (UK Consumer Rights Act 2015 disclosure period; PSD2 Article 89 dispute window; MiCA Article 80 records retention; AMLR Article 56 records retention).¶

Object Lock COMPLIANCE-mode retention on object stores supporting WORM retention (Amazon S3, Backblaze B2, Cloudflare R2) is a practical implementation; refund receipts and their audit-chain rows MUST NOT be modifiable during the retention period.¶

7.1. Compliance Receipt Linkage

The conventional original_payment_ref target for an admission-then-refund flow is the content_hash of the compliance receipt that admitted the original payment under draft-hopley-x402-compliance-receipt. The two receipts compose into one audit-chain segment that records the full admission-through- refund lifecycle. See Section 5.3.¶

7.2. STARK Receipt Linkage

When a payment was settled with a STARK proof per draft-vauban-x402-stark-receipts, the refund receipt's original_payment_ref MAY equal the content_hash of the STARK receipt. The verifier confirms the STARK-proven settlement and the subsequent refund event under one canonicalisation pin.¶

7.3. Composite Trust-Query

Multiple emitters' attestations may participate in a composite trust-query per x402-foundation/x402 pull request #2440. A refund provider's attestation row in a composite-trust-query MAY reference a refund receipt's content_hash as the underlying evidence.¶

8.1. URN Namespace Registration

This document references the URN urn:x402:canonicalisation:jcs-rfc8785-v1 registered by draft-hopley-x402-canonicalisation-jcs Section 10.1. No additional URN namespace registration is required by this document.¶

8.2. Receipt Format Identifier

This document defines the receipt format identifier:¶

urn:x402:receipt:refund-v1

This identifier MAY be used by composite-trust-query implementations (per x402-foundation/x402 PR #2440) to refer to refund receipts as a class. Registration with IANA is requested under the x402-foundation/x402 receipt-format identifier namespace.¶

9.1. Receipt Tampering

A refund receipt's content_hash is the SHA-256 of its JCS-canonical bytes. Tampering with any field of the receipt produces a different content_hash; the tampered receipt fails verification against any audit-chain row that references the original content_hash.¶

9.2. Chain Truncation and Reordering

The audit chain prev_hash linkage (Section 5.2) detects truncation, reordering, or row deletion. A verifier walking the chain confirms that every row's prev_hash equals the previous row's row_content_hash; any deviation indicates chain integrity loss.¶

9.3. Double-Refund Attacks

A malicious operator might attempt to issue two refund receipts for the same original payment, each linking to the same original_payment_ref. Detection requires the verifier to walk the chain forward from the compliance receipt and observe both refund rows; the chain itself does not prevent the double-issuance but makes it byte-detectable.¶

Operators SHOULD enforce single-refund-per-payment at the operator-layer orchestration before emitting receipts. For PARTIAL refunds that genuinely require multiple legs (e.g. a customer returning two items from a single order), each leg's refund receipt MUST link to the original payment ref AND to the prior refund row to make the leg-sequence verifiable; the chain order encodes the cumulative refunded amount.¶

9.4. Cross-Asset Refund Substitution

A refund receipt MAY refund in a different asset than the original payment. A verifier cannot determine equivalence-of-value between the original asset and the refund asset from the receipt alone; asset-substitution claims of equivalence require additional external evidence (price oracle attestations, settlement proofs) and are out of scope of this document.¶

Operators substituting assets MUST disclose the substitution clearly to the payer at the time of the refund and MUST retain evidence of the equivalence claim under the same retention period as the receipt itself.¶

9.5. Operator Continuity Loss

If the original refund-issuing operator becomes unavailable, the audit chain and its receipts MUST remain independently verifiable from retained bytes plus the eight reference implementations cited in Section 6. This document specifies year-N auditability properties so that operator continuity loss does not break verifiability.¶

9.6. DID Resolution Compromise

refund_provider_did is a DID URI. If the DID resolution infrastructure is compromised at verification time, the verifier MAY be unable to resolve the DID to an authoritative key. The receipt format MAY be combined with offline DID document snapshots (captured at the time of receipt emission and retained alongside the receipt) to make verification independent of live DID resolution.¶

9.7. Privacy

The original_payment_ref field is content-addressed, not cleartext. A receipt does not leak payer identity, payee identity, or original payment amount on its face. The refund_amount field carries the refunded value but the original payment amount is not in the receipt; cross-receipt linkage (via original_payment_ref to a compliance receipt) is required to recover the original amount, and the linkage is itself content-addressed.¶

A.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.¶
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.¶
• [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.¶
• [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020.¶
• [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017.¶

A.2. Informative References

• draft-hopley-x402-canonicalisation-jcs Hopley, C., "JCS Canonicalisation Discipline for Agentic-Payment Receipts", draft-hopley-x402-canonicalisation-jcs-v1, May 2026.¶
• draft-hopley-x402-compliance-receipt Hopley, C., "Categorical Compliance Screening Receipt Format for Agentic-Payment Flows", draft-hopley-x402-compliance-receipt-01, May 2026.¶
• draft-hopley-x402-settlement-attestation Hopley, C., "Categorical Settlement Attestation Format for Agentic-Payment Flows", draft-hopley-x402-settlement-attestation-00, May 2026.¶
• draft-hopley-x402-cancellation-receipt Hopley, C., "Categorical Mandate Cancellation Receipt Format for Agentic-Payment Flows", draft-hopley-x402-cancellation-receipt-00, May 2026.¶
• draft-hopley-x402-composite-trust-query Hopley, C., "Composite Trust Query Response Format for Agentic-Payment Audit Chains", draft-hopley-x402-composite-trust-query-00, May 2026.¶
• draft-vauban-x402-stark-receipts (companion document on STARK receipt format).¶
• AlgoVoi, "Substrate Adopters Registry", target="https://docs.algovoi.co.uk/adopters"¶
• x402-foundation/x402 pull request #2436 -- canonicalisation discipline (AlgoVoi-authored normative section with subsequent review co-signatures from Vauban Pay and Arian Gogani).¶
• x402-foundation/x402 pull request #2440 -- composite trust-query algorithm.¶
• [AlgoVoi-JCS-8-impl] AlgoVoi, "Eight-implementation cross-validation attestation for JCS RFC 8785", 2026-05-24, target="https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/blob/main/_attestations/2026-05-24-8-impl-cross-validation.md"¶
• [AlgoVoi-Substrate-Authorship] AlgoVoi, "Substrate Authorship and Provenance", target="https://docs.algovoi.co.uk/substrate-authorship-provenance"¶
• UK Consumer Rights Act 2015.¶
• EU Consumer Rights Directive 2011/83/EU, Article 9.¶
• EU Payment Services Directive 2 (PSD2, Directive 2015/2366), Article 89 (unauthorised payment refunds).¶
• UK Money Laundering Regulations 2017.¶
• UK Proceeds of Crime Act 2002, Section 330.¶
• EU Anti-Money Laundering Directive 5 (Directive (EU) 2018/843).¶
• EU Anti-Money Laundering Directive 6 (Directive (EU) 2018/1673).¶
• EU Markets in Crypto-Assets Regulation (MiCA, Regulation (EU) 2023/1114), Article 80.¶
• EU Anti-Money Laundering Regulation (AMLR, Regulation (EU) 2024/1624), Article 56.¶

B.1. A.1. FULL refund under UK + EU joint jurisdiction

{
  "canon_version": "jcs-rfc8785-v1",
  "jurisdiction_flags": ["UK", "EU"],
  "original_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "refund_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
  "refund_provider_did": "did:example:refund-provider-1",
  "refund_result": "FULL",
  "refund_timestamp_ms": 1716494400000
}

Refunds 0.1 USDC (100000 minor units, 6 decimals) under joint UK + EU jurisdiction. The original_payment_ref references a payment record whose content_hash is the listed value (e.g. a compliance receipt from draft-hopley-x402-compliance-receipt). FULL closes the consumer's right to further remedy under UK Consumer Rights Act 2015 and EU Consumer Rights Directive 2011/83/EU Article 9.¶

B.2. A.2. PARTIAL refund

{
  "canon_version": "jcs-rfc8785-v1",
  "jurisdiction_flags": ["UK", "EU"],
  "original_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "refund_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
  "refund_provider_did": "did:example:refund-provider-1",
  "refund_result": "PARTIAL",
  "refund_timestamp_ms": 1716494400000
}

refund_amount carries the actual refunded value; the verifier compares against the original via original_payment_ref to confirm the refund is strictly less than the original. PARTIAL does not close the consumer's right under consumer-rights statutes; further remedy may remain.¶

B.3. A.3. REJECTED refund (PSD2 Article 89 dispute evidence)

{
  "canon_version": "jcs-rfc8785-v1",
  "jurisdiction_flags": ["UK", "EU"],
  "original_payment_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "refund_amount": {"amount_minor": "100000", "asset_id": "USDC.6"},
  "refund_provider_did": "did:example:refund-provider-1",
  "refund_result": "REJECTED",
  "refund_timestamp_ms": 1716494400000
}

A refund request was processed and denied. refund_amount carries the requested-but-denied amount so the denial-evidence chain can record the operational claim. Under PSD2 Article 89, a payer denied a refund must receive a documented denial; this receipt fulfils that documentation obligation.¶