



Independent Submission                                         C. Hopley
Internet-Draft                                                   AlgoVoi
Intended status: Informational                               30 May 2026
Expires: 1 December 2026


  Categorical Mandate Cancellation Receipt Format for Agentic-Payment
                                 Flows
               draft-hopley-x402-cancellation-receipt-01

Abstract

   This document specifies a categorical mandate cancellation receipt
   format for agentic-payment flows.  The format records that a
   recurring-payment mandate or other standing payer-to-payee
   authorisation has been cancelled, by whom, for what reason, and with
   what effective date.

   The receipt format uses a closed four-element enumeration of
   categorical outcomes (USER_REQUESTED, MERCHANT_REQUESTED,
   COMPLIANCE_TERMINATED, EXPIRED).  The four-state enumeration
   preserves the regulatorily-load-bearing distinction between payer-
   initiated revocation, payee-initiated termination, operator/
   compliance-forced termination, and time-based expiry.  A collapse to
   a three-state or binary representation loses operational distinctions
   that drive PSD2 (Directive 2015/2366) Article 64 refund-window
   obligations, Article 72 contractual-termination record-keeping, and
   POCA/AML evidence-chain linkage on compliance-forced terminations.

   The format records two distinct timestamps -- when the cancellation
   was observed (cancellation_timestamp_ms) and when it takes legal
   effect (effective_from_ms) -- to support PSD2 Article 64(3)(a)
   direct-debit revocation timing, where the effective time is typically
   end-of-business-day prior to the next scheduled execution.

   The format composes with the AlgoVoi-authored compliance receipt
   (draft-hopley-x402-compliance-receipt), settlement attestation
   (draft-hopley-x402-settlement-attestation), and refund receipt
   (draft-hopley-x402-refund-receipt) formats under the same
   canonicalisation discipline (draft-hopley-x402-canonicalisation-jcs).
   A verifier walking the audit chain confirms the full mandate
   lifecycle from admission through recurring execution to cancellation,
   and (where owed) onward to refund of revoked settled debits, under
   one byte-deterministic canonicalisation pin.







Hopley                   Expires 1 December 2026                [Page 1]

Internet-Draft          x402-cancellation-receipt               May 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 1 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Relationship to other Internet-Drafts . . . . . . . . . .   5
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     2.1.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Receipt Format Specification  . . . . . . . . . . . . . . . .   6
     3.1.  cancellation_reason . . . . . . . . . . . . . . . . . . .   6
     3.2.  cancellation_provider_did . . . . . . . . . . . . . . . .   7
     3.3.  cancellation_timestamp_ms . . . . . . . . . . . . . . . .   7
     3.4.  effective_from_ms . . . . . . . . . . . . . . . . . . . .   7
     3.5.  jurisdiction_flags  . . . . . . . . . . . . . . . . . . .   8
     3.6.  mandate_ref . . . . . . . . . . . . . . . . . . . . . . .   8
     3.7.  canon_version . . . . . . . . . . . . . . . . . . . . . .   9



Hopley                   Expires 1 December 2026                [Page 2]

Internet-Draft          x402-cancellation-receipt               May 2026


   4.  Canonicalisation  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Audit Chain Composition . . . . . . . . . . . . . . . . . . .   9
     5.1.  Chain Row Shape . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  Linkage Verification  . . . . . . . . . . . . . . . . . .   9
     5.3.  Composition with Compliance Receipts  . . . . . . . . . .  10
     5.4.  Composition with Settlement Attestations  . . . . . . . .  10
     5.5.  Composition with Refund Receipts  . . . . . . . . . . . .  10
   6.  Year-N Auditability Properties  . . . . . . . . . . . . . . .  11
   7.  Composition with Other x402 Substrate . . . . . . . . . . . .  11
     7.1.  Compliance Receipt Linkage  . . . . . . . . . . . . . . .  11
     7.2.  Settlement Attestation Linkage  . . . . . . . . . . . . .  11
     7.3.  Refund Receipt Linkage  . . . . . . . . . . . . . . . . .  12
     7.4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  URN Namespace Registration  . . . . . . . . . . . . . . .  12
     8.2.  Receipt Format Identifier . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     9.1.  Receipt Tampering . . . . . . . . . . . . . . . . . . . .  12
     9.2.  Backdated Cancellation  . . . . . . . . . . . . . . . . .  13
     9.3.  Reason Spoofing . . . . . . . . . . . . . . . . . . . . .  13
     9.4.  Compliance-Terminated Receipt Disclosure  . . . . . . . .  13
     9.5.  Operator Continuity Loss  . . . . . . . . . . . . . . . .  13
   Appendix A.  References . . . . . . . . . . . . . . . . . . . . .  14
     A.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     A.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Appendix B.  Appendix A.  Examples (Informative)  . . . . . . . .  15
     B.1.  A.1.  USER_REQUESTED revocation under PSD2 Article 64 . .  15
     B.2.  A.2.  MERCHANT_REQUESTED termination under PSD2 Article
           72  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     B.3.  A.3.  COMPLIANCE_TERMINATED under sanctions hit . . . . .  15
     B.4.  A.4.  EXPIRED at agreed mandate end-date  . . . . . . . .  16
   Appendix C.  Appendix B.  Reference Implementations
           (Informative) . . . . . . . . . . . . . . . . . . . . . .  16
   Appendix D.  Known Adopters (Informative) . . . . . . . . . . . .  17
   Appendix E.  Acknowledgments  . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

1.1.  Motivation

   Agentic-payment flows generate categorical receipts across the
   mandate lifecycle.  Where the compliance receipt format (draft-
   hopley-x402-compliance-receipt) admits a mandate and the settlement
   attestation format (draft-hopley-x402-settlement-attestation) records
   recurring executions, mandate termination is the corresponding end-
   state.  Termination is not a degenerate refund; it is its own state
   transition with its own regulatory consequences.



Hopley                   Expires 1 December 2026                [Page 3]

Internet-Draft          x402-cancellation-receipt               May 2026


   The operational and regulatory distinctions are load-bearing across
   four genuinely-different states:

   *  A payer-initiated revocation (PSD2 (Directive 2015/2366) Article
      64, UK Consumer Rights Act 2015 consumer-revocation provisions)
      MAY trigger refund obligations on debits already settled prior to
      the revocation effective date.
   *  A payee-initiated termination (PSD2 Article 72 + contractual
      terms) records the end of a recurring billing arrangement but does
      NOT trigger consumer-revocation refund-window obligations on
      already-settled debits.
   *  A compliance-forced termination (sanctions hit on payer, KYC
      failure, AML alert, court order, regulator directive) triggers
      POCA s.330 and AML 5+6 audit-chain evidence linkage back to the
      originating compliance event.  The recorded receipt is the
      evidentiary anchor.
   *  A time-based expiry (mandate reached its agreed end-date or
      maximum-execution count) records that the mandate's own terms
      terminated it.  No party-initiated regulatory action is required
      beyond standard record-keeping.

   A receipt format that collapses these to a three-state enumeration
   (e.g. PARTY_REQUESTED + AUTO_TERMINATED) loses the payer-vs-payee
   distinction that drives the PSD2 Article 64 refund-window obligation.
   A collapse to two-state (CANCELLED / EXPIRED) loses both that
   distinction and the compliance-forced flag that anchors the AML/POCA
   evidence chain.

   This document specifies a cancellation receipt format that preserves
   the four-state categorical outcome at the canonical-bytes level and
   records the two timestamps (event recording time and legal effective
   time) independently.

1.2.  Scope

   This document specifies:

   *  The canonical JSON shape of the cancellation receipt (Section 3).
   *  The reference to the canonicalisation rule applicable to the
      receipt (Section 4 -- normative reference to draft-hopley-x402-
      canonicalisation-jcs, not redefined inline).
   *  The audit chain composition under which cancellation receipts
      compose with compliance receipts, settlement attestations, and
      refund receipts (Section 5).
   *  The year-N auditability properties the format pins (Section 6).
   *  Composition patterns across the AlgoVoi receipt-format suite
      (Section 7).




Hopley                   Expires 1 December 2026                [Page 4]

Internet-Draft          x402-cancellation-receipt               May 2026


   *  Worked examples covering all four cancellation_reason outcomes
      (Appendix A).

   This document does NOT specify:

   *  The mandate format itself.  The cancellation receipt references
      the mandate via a content-addressed mandate_ref of the form
      sha256:<hex>.  The mandate record MAY be a compliance receipt, an
      Agent Payment Protocol (AP2) mandate object, a Merchant Payment
      Protocol (MPP) subscription record, or any operator-specific
      mandate format.
   *  The refund flow triggered by a USER_REQUESTED cancellation.
      Refund obligations and their categorical receipt format are
      specified in draft-hopley-x402-refund-receipt.  This document
      records only that the cancellation occurred and notes (per
      cancellation_reason) whether a refund obligation may apply.
   *  The compliance event that drives a COMPLIANCE_TERMINATED outcome.
      That event is recorded in a separate compliance receipt (draft-
      hopley-x402-compliance-receipt) and linked via the audit chain.

1.3.  Relationship to other Internet-Drafts

   This document normatively references:

   *  draft-hopley-x402-canonicalisation-jcs -- the JCS canonicalisation
      discipline pinned in Section 4.

   This document is complementary to:

   *  draft-hopley-x402-compliance-receipt -- admission-time compliance
      screening receipts.  A cancellation receipt's mandate_ref MAY
      equal the content_hash of the compliance receipt that admitted the
      mandate.
   *  draft-hopley-x402-settlement-attestation -- per-execution
      settlement attestations during the mandate's life.
   *  draft-hopley-x402-refund-receipt -- post-cancellation refund
      receipts.  A refund receipt's original_payment_ref MAY reference a
      settlement attestation that became refundable as a result of a
      USER_REQUESTED cancellation recorded under this document.

2.  Conventions and Definitions










Hopley                   Expires 1 December 2026                [Page 5]

Internet-Draft          x402-cancellation-receipt               May 2026


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

   *cancellation receipt*: a JSON object of the shape specified in
   Section 3, canonicalised under the discipline of draft-hopley-x402-
   canonicalisation-jcs.

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

   *mandate_ref*: a string of the form sha256:<lowercase-hex-64>
   identifying the mandate record being cancelled by content hash.  The
   mandate record itself is out of scope of this document.

   *cancellation_reason*: a string-valued field carrying one of four
   closed enumeration values.  See Section 3.1.

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

3.  Receipt Format Specification

   A cancellation receipt is a JSON object with the following seven
   fields.  All fields are REQUIRED.  The receipt is canonicalised under
   draft-hopley-x402-canonicalisation-jcs per Section 4.  Field names
   are sorted lexicographically by JCS during canonicalisation; the
   object itself uses arbitrary authoring order.

3.1.  cancellation_reason

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

   *  USER_REQUESTED -- the payer revoked the mandate.  PSD2 Article 64
      applies.  UK Consumer Rights Act 2015 consumer-revocation
      provisions apply.  Triggers payer-side refund-window calculations
      for direct debits already settled prior to the effective date.
   *  MERCHANT_REQUESTED -- the payee terminated the recurring billing
      arrangement.  PSD2 Article 72 and contractual terms apply.  Does
      NOT trigger consumer-revocation refund-window obligations on
      already-settled debits.




Hopley                   Expires 1 December 2026                [Page 6]

Internet-Draft          x402-cancellation-receipt               May 2026


   *  COMPLIANCE_TERMINATED -- the operator (gateway, facilitator, bank,
      regulator) forced termination from a post-mandate compliance
      trigger: sanctions hit on payer, KYC failure, AML alert, court
      order, regulator directive.  Triggers POCA s.330 and AML 5+6
      audit-chain linkage back to the originating compliance event.
   *  EXPIRED -- the mandate reached its agreed end-date or maximum-
      execution count.  No party-initiated decision; the mandate's own
      terms terminated it.  Standard record-keeping only.

   The four-element enumeration is closed.  Implementations MUST reject
   any other value at validation time before canonicalisation.  Free-
   form "reason" strings, dispute codes, or operator-internal
   classification labels are not acceptable substitutes for the
   categorical outcome.

   The regulatory distinction is load-bearing.  The four-value
   enumeration is one wider than the three-value enums in sibling
   formats because the regulatorily-load-bearing distinctions in mandate
   termination are genuinely four-state: payer vs payee vs operator vs
   time.

3.2.  cancellation_provider_did

   A string-valued DID URI identifying the entity issuing the
   cancellation receipt (gateway, facilitator, payer-bank, operator).

3.3.  cancellation_timestamp_ms

   An integer-valued field carrying the epoch-millisecond timestamp at
   which the cancellation event was observed and recorded by the issuing
   provider, in UTC.

   This field MUST be an integer.  RFC 3339 string forms (e.g.
   "2026-05-30T12:00:00Z") MUST be rejected at the validation layer
   before canonicalisation.  This is Substrate Rule 2, normatively
   specified in draft-hopley-x402-canonicalisation-jcs Section 4.1.

3.4.  effective_from_ms

   An integer-valued field carrying the epoch-millisecond timestamp at
   which the cancellation takes legal effect, in UTC.

   effective_from_ms MUST be greater than or equal to
   cancellation_timestamp_ms.  Implementations MUST reject receipts
   where the effective time precedes the recording time, both at
   validation time and at verification time.





Hopley                   Expires 1 December 2026                [Page 7]

Internet-Draft          x402-cancellation-receipt               May 2026


   For most cancellations the two timestamps are equal.  The independent
   encoding supports PSD2 Article 64(3)(a) direct-debit revocation
   timing, where the agreed effective time is typically the end of the
   working day before the next scheduled execution -- distinct from the
   moment the revocation was recorded.

   For COMPLIANCE_TERMINATED outcomes the effective time MAY be
   immediate (equal to the recording time) or scheduled (regulator-
   directed future effective date).

   Substrate Rule 2 applies: integer-only, RFC 3339 string forms
   rejected.

3.5.  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 cancellation 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 per draft-hopley-
   x402-canonicalisation-jcs Section 4.3.

3.6.  mandate_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 mandate record
   being cancelled.

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

   When the original mandate record is an operator-specific format (AP2
   mandate object, MPP subscription record, custom recurring
   authorisation), the mandate_ref is the SHA-256 of that record's JCS-
   canonical bytes.

   Implementations MUST NOT strip the sha256: prefix during
   canonicalisation or verification.






Hopley                   Expires 1 December 2026                [Page 8]

Internet-Draft          x402-cancellation-receipt               May 2026


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.

4.  Canonicalisation

   The cancellation receipt MUST be canonicalised under the discipline
   pinned by draft-hopley-x402-canonicalisation-jcs and identified by
   the URN:

   urn:x402:canonicalisation:jcs-rfc8785-v1

   The full normative specification of the discipline (JCS RFC 8785 plus
   the schema-normalisation requirements including Substrate Rule 2) is
   in that document.  This document does not redefine the discipline
   inline.

5.  Audit Chain Composition

   A cancellation receipt MAY participate in an audit chain alongside
   compliance receipts, settlement attestations, refund receipts, and
   other receipt classes that pin the same canonicalisation discipline.

5.1.  Chain Row Shape

   The audit chain row shape used by this document is identical to that
   specified in draft-hopley-x402-compliance-receipt Section 5.1 and
   reused by the settlement attestation (draft-hopley-x402-settlement-
   attestation) and refund receipt (draft-hopley-x402-refund-receipt)
   formats.  The row shape is:

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

   Row 1's prev_hash MUST be 64 zero hex characters.  Row N's prev_hash
   MUST equal row N-1's row_content_hash.

5.2.  Linkage Verification

   Per draft-hopley-x402-compliance-receipt Section 5.2: a verifier
   reading a chain segment recomputes each row's row_content_hash from
   its first three fields and confirms forward linkage via prev_hash.
   Any mismatch indicates tampering or chain integrity loss.



Hopley                   Expires 1 December 2026                [Page 9]

Internet-Draft          x402-cancellation-receipt               May 2026


5.3.  Composition with Compliance Receipts

   When a cancellation receipt references a compliance receipt via
   mandate_ref, the audit-chain composition is:

   chain row N      chain row N+1
   +------------+   +---------------+
   | compliance |-->| cancellation  |
   | receipt    |   | receipt       |
   | (ALLOW)    |   | (USER_REQ)    |
   +------------+   +---------------+

   Row N anchors the compliance receipt admitting the mandate.  Row N+1
   anchors the cancellation receipt.  The cancellation receipt's
   mandate_ref equals row N's content_hash.  Chain linkage via prev_hash
   confirms ordering.

5.4.  Composition with Settlement Attestations

   For mandates with intervening recurring executions, settlement
   attestations occupy rows between the compliance receipt and the
   cancellation receipt:

   chain row N      chain row N+1     chain row N+2    chain row N+3
   +------------+   +-------------+   +-------------+  +---------------+
   | compliance |-->| settlement  |-->| settlement  |->| cancellation  |
   | receipt    |   | attestation |   | attestation |  | receipt       |
   | (ALLOW)    |   | (SETTLED)   |   | (SETTLED)   |  | (USER_REQ)    |
   +------------+   +-------------+   +-------------+  +---------------+
          row N           row N+1           row N+2          row N+3

   A verifier walking the chain confirms the full mandate lifecycle
   under one canonicalisation pin.

5.5.  Composition with Refund Receipts

   When a USER_REQUESTED cancellation triggers a refund obligation under
   PSD2 Article 64 (refund of a recently-settled debit that predated the
   cancellation but post-dated the effective revocation window), a
   refund receipt MAY follow:

   chain row N+3        chain row N+4
   +---------------+    +------------+
   | cancellation  |--->| refund     |
   | receipt       |    | receipt    |
   | (USER_REQ)    |    | (FULL)     |
   +---------------+    +------------+




Hopley                   Expires 1 December 2026               [Page 10]

Internet-Draft          x402-cancellation-receipt               May 2026


   The refund receipt's original_payment_ref references the settlement
   attestation being refunded (not the cancellation receipt).  The
   cancellation receipt is the chain-evidence anchor that establishes
   why the refund is owed.

6.  Year-N Auditability Properties

   The same six properties pinned by draft-hopley-x402-canonicalisation-
   jcs Section 5 apply to the cancellation receipt:

   1.  Self-describing canonicalisation pin via canon_version.
   2.  No external rule registry required.
   3.  Cross-implementation verifiability (8-implementation matrix per
       the discipline I-D).
   4.  Tamper detection via per-row content_hash and chain prev_hash
       linkage.
   5.  Regulatory distinction preserved via closed enumeration.

   Plus one cancellation-specific property:

   6.  *Mandate-cancellation evidence chain.* A verifier reading a
       retained cancellation receipt years after emission can determine
       (a) which mandate was cancelled (via mandate_ref), (b) who
       cancelled it (via the combination of cancellation_reason and
       cancellation_provider_did), (c) when the cancellation was
       recorded (cancellation_timestamp_ms), and (d) when it became
       effective (effective_from_ms), without dependence on the issuing
       operator's continued operation.

7.  Composition with Other x402 Substrate

7.1.  Compliance Receipt Linkage

   See Section 5.3.  The conventional mandate_ref target for a mandate
   admitted under a compliance receipt is the content_hash of that
   compliance receipt.

7.2.  Settlement Attestation Linkage

   See Section 5.4.  Settlement attestations recording recurring
   executions occupy chain rows between the admission and the
   cancellation.  The cancellation receipt does not reference individual
   settlement attestations directly; chain linkage via prev_hash
   establishes ordering.







Hopley                   Expires 1 December 2026               [Page 11]

Internet-Draft          x402-cancellation-receipt               May 2026


7.3.  Refund Receipt Linkage

   See Section 5.5.  A USER_REQUESTED cancellation MAY be followed in
   the chain by a refund receipt if PSD2 Article 64 refund obligations
   attach to a recently-settled debit.

7.4.  Non-Goals

   This document does not encode:

   *  The mandate's terms (frequency, cap, expiry condition).  Those
      belong in the mandate record itself.
   *  The refund obligation determination.  PSD2 Article 64 refund-
      window applicability is verifier-side judgement against retained
      settlement attestations.
   *  The compliance event driving a COMPLIANCE_TERMINATED outcome.
      That belongs in a separate compliance receipt linked via the audit
      chain.

8.  IANA Considerations

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:cancellation-receipt-v1

   This identifier MAY be used by composite-trust-query implementations
   to refer to cancellation receipts as a class.  Registration with IANA
   is requested under the x402 URN namespace.

9.  Security Considerations

9.1.  Receipt Tampering

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





Hopley                   Expires 1 December 2026               [Page 12]

Internet-Draft          x402-cancellation-receipt               May 2026


9.2.  Backdated Cancellation

   The two-timestamp design (cancellation_timestamp_ms recording event
   time, effective_from_ms recording legal effective time) admits a
   class of attack where a malicious operator emits a receipt at time T
   with effective_from_ms set to a past timestamp T' < T, to
   retroactively void a debit that has already settled.

   Mitigation is verifier-side: a verifier MUST cross-check the
   cancellation_timestamp_ms against operator-emission-time evidence
   (TLS log, audit-chain prev_hash of the row recording this receipt,
   external timestamping service) before accepting a claimed effective
   time in the past.

   The effective_from_ms >= cancellation_timestamp_ms invariant required
   by Section 3.4 prevents the simpler attack of stamping the recording
   time in the past, but does not by itself prevent all backdating
   attacks.

9.3.  Reason Spoofing

   A malicious operator could emit a MERCHANT_REQUESTED receipt for what
   was actually a USER_REQUESTED cancellation, to avoid the PSD2 Article
   64 refund-window obligation.  Detection requires out-of-band evidence
   (payer complaint, payer-side log, regulator inspection).  The
   cancellation_provider_did identifies the attesting party, supporting
   accountability.

9.4.  Compliance-Terminated Receipt Disclosure

   A COMPLIANCE_TERMINATED receipt records that a compliance trigger
   fired against the payer.  Such a receipt MAY contain indirectly-
   disclosing information: the existence of the cancellation under that
   reason, combined with public sanctions listing dates, MAY reveal that
   the payer was placed on a sanctions list.

   Implementations SHOULD restrict access to COMPLIANCE_TERMINATED
   receipts to parties with a legitimate audit interest (regulator,
   auditor, court order).  Public disclosure of such receipts is NOT in
   scope of this document.

9.5.  Operator Continuity Loss

   If the original attesting operator becomes unavailable, the audit
   chain and its cancellation receipts MUST remain independently
   verifiable from retained bytes plus the reference implementations
   cited in draft-hopley-x402-canonicalisation-jcs Section 7.




Hopley                   Expires 1 December 2026               [Page 13]

Internet-Draft          x402-cancellation-receipt               May 2026


Appendix A.  References

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.
   *  draft-hopley-x402-canonicalisation-jcs Hopley, C., "JCS
      Canonicalisation Discipline for Agentic-Payment Receipts", draft-
      hopley-x402-canonicalisation-jcs-v1, May 2026.

A.2.  Informative References

   *  draft-hopley-x402-compliance-receipt Hopley, C., "Categorical
      Compliance Screening Receipt Format for Agentic-Payment Flows",
      draft-hopley-x402-compliance-receipt-00, 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-refund-receipt Hopley, C., "Categorical Refund
      Receipt Format for Agentic-Payment Flows", draft-hopley-x402-
      refund-receipt-00, May 2026.
   *  [AlgoVoi-Substrate-Authorship] AlgoVoi, "Substrate Authorship and
      Provenance", target="https://docs.algovoi.co.uk/substrate-
      authorship-provenance" (https://docs.algovoi.co.uk/substrate-
      authorship-provenance)
   *  EU Payment Services Directive 2 (PSD2, Directive 2015/2366),
      Articles 64, 72, 89.
   *  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.
   *  EU Anti-Money Laundering Directive 5 (Directive (EU) 2018/843).
   *  EU Anti-Money Laundering Directive 6 (Directive (EU) 2018/1673).
   *  UK Proceeds of Crime Act 2002, section 330.
   *  UK Consumer Rights Act 2015.







Hopley                   Expires 1 December 2026               [Page 14]

Internet-Draft          x402-cancellation-receipt               May 2026


Appendix B.  Appendix A.  Examples (Informative)

B.1.  A.1.  USER_REQUESTED revocation under PSD2 Article 64

   {
     "canon_version": "jcs-rfc8785-v1",
     "cancellation_provider_did": "did:web:api.algovoi.co.uk",
     "cancellation_reason": "USER_REQUESTED",
     "cancellation_timestamp_ms": 1716494400000,
     "effective_from_ms": 1716537600000,
     "jurisdiction_flags": ["UK", "EU"],
     "mandate_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f"
   }

   Records a payer-initiated revocation under PSD2 Article 64 with
   effective time set to end-of-business-day prior to the next scheduled
   execution per Article 64(3)(a).  If a debit already settled within
   the recoverable window prior to the effective date, a refund receipt
   MAY follow.

B.2.  A.2.  MERCHANT_REQUESTED termination under PSD2 Article 72

   {
     "canon_version": "jcs-rfc8785-v1",
     "cancellation_provider_did": "did:web:api.algovoi.co.uk",
     "cancellation_reason": "MERCHANT_REQUESTED",
     "cancellation_timestamp_ms": 1716494400000,
     "effective_from_ms": 1716537600000,
     "jurisdiction_flags": ["UK", "EU"],
     "mandate_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f"
   }

   Records payee-initiated termination of the recurring billing
   arrangement.  Does not trigger the Article 64 refund-window
   obligation on already-settled debits.

B.3.  A.3.  COMPLIANCE_TERMINATED under sanctions hit

   {
     "canon_version": "jcs-rfc8785-v1",
     "cancellation_provider_did": "did:web:api.algovoi.co.uk",
     "cancellation_reason": "COMPLIANCE_TERMINATED",
     "cancellation_timestamp_ms": 1716494400000,
     "effective_from_ms": 1716494400000,
     "jurisdiction_flags": ["UK", "EU"],
     "mandate_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f"
   }




Hopley                   Expires 1 December 2026               [Page 15]

Internet-Draft          x402-cancellation-receipt               May 2026


   Records immediate operator-forced termination.  Effective time equals
   recording time.  Anchors POCA s.330 and AML 5+6 audit-chain linkage
   back to the originating compliance receipt (a separate record).

B.4.  A.4.  EXPIRED at agreed mandate end-date

   {
     "canon_version": "jcs-rfc8785-v1",
     "cancellation_provider_did": "did:web:api.algovoi.co.uk",
     "cancellation_reason": "EXPIRED",
     "cancellation_timestamp_ms": 1716494400000,
     "effective_from_ms": 1716494400000,
     "jurisdiction_flags": ["UK", "EU"],
     "mandate_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f"
   }

   Records time-based expiry of the mandate.  Standard record-keeping
   only; no further regulatory action attaches.

Appendix C.  Appendix B.  Reference Implementations (Informative)

   The following open-source implementations conform to this format:

   *  algovoi-cancellation-receipt (Python) on PyPI:
      target="https://pypi.org/project/algovoi-cancellation-receipt/"
      (https://pypi.org/project/algovoi-cancellation-receipt/) Provides
      build_cancellation_receipt().  Depends on algovoi-substrate for
      the JCS canonicalisation primitive.  Apache 2.0 licensed.

   *  @algovoi/cancellation-receipt (TypeScript) on npm:
      target="https://www.npmjs.com/package/@algovoi/cancellation-
      receipt" (https://www.npmjs.com/package/@algovoi/cancellation-
      receipt) Byte-for-byte parity with the Python sibling.  Depends on
      @algovoi/substrate for the JCS canonicalisation primitive.  Apache
      2.0 licensed.

   Conformance vectors:

https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/vectors/cancellation_receipt_v1

   8 byte-level reference vectors + 7 pair invariants + 3 chain
   invariants pinning the closed four-element enumeration, jurisdiction-
   array-order, canon_version pin, effective-time-greater-equal-
   recording-time invariant, and audit-chain linkage properties.







Hopley                   Expires 1 December 2026               [Page 16]

Internet-Draft          x402-cancellation-receipt               May 2026


Appendix D.  Known Adopters (Informative)

   The following downstream parties have published artefacts that anchor
   to the cancellation receipt format specified by this document, or to
   the canonicalisation discipline shared with this format.  Inclusion
   in this list is informational and reflects public adoption only; it
   does not imply endorsement or normative authority from the listed
   party.

    +=====================+===================+=======================+
    | Adopter             | Surface           | Anchor                |
    +=====================+===================+=======================+
    | AlgoVoi             | Production        | All AlgoVoi-emitted   |
    | (api.algovoi.co.uk) | mandate-lifecycle | cancellation receipts |
    |                     | issuer            | under canon_version:  |
    |                     |                   | jcs-rfc8785-v1        |
    +---------------------+-------------------+-----------------------+

                                  Table 1

   Adopters publishing vector sets or receipt-format extensions that
   anchor to this format are encouraged to publish them in adopter-
   controlled repositories with canon_version recorded in-band, so each
   adopter's authorship is unambiguous and their artefact is
   independently citable.

   This appendix is maintained as a record of observed adoption at the
   time of revision; absence from this list is not normative.

Appendix E.  Acknowledgments

   This document, the receipt format it specifies, and the conformance
   vectors derived from it are AlgoVoi work under AlgoVoi authorship.
   Substrate authorship history is catalogued at
   target="https://docs.algovoi.co.uk/substrate-authorship-provenance"
   (https://docs.algovoi.co.uk/substrate-authorship-provenance).

   The canonicalisation discipline pinned by Section 4 is normatively
   specified in draft-hopley-x402-canonicalisation-jcs under the same
   authorship.











Hopley                   Expires 1 December 2026               [Page 17]

Internet-Draft          x402-cancellation-receipt               May 2026


   This document closes the lifecycle gap between the admission-time
   compliance receipt (draft-hopley-x402-compliance-receipt), per-
   execution settlement attestation (draft-hopley-x402-settlement-
   attestation), and post-cancellation refund receipt (draft-hopley-
   x402-refund-receipt) formats.  The four formats share the same
   canonicalisation pin, audit-chain row shape, and integer-millisecond
   timestamp encoding, so that a verifier walking the full mandate
   lifecycle requires only one implementation of the canonicalisation
   discipline.

   The author acknowledges Anders Rundgren as the editor of RFC 8785,
   the JSON Canonicalization Scheme on which the discipline builds.

Author's Address

   Christopher Hopley
   AlgoVoi
   Email: chopmob@gmail.com

































Hopley                   Expires 1 December 2026               [Page 18]
