feat(core)!: speak the spec's PaymentPayload #75

Updated 2026-11-04. Widened from "the two inner field renames" to the whole
PaymentPayload, after diffing our schemas against the spec. The original text
is in the edit history; the two renames are items 1 below.

The Canton scheme spec and core v2 define PaymentPayload at two
levels, and we diverge at both. A conforming client's payload does not parse here,
and ours does not parse there.

The envelope

accepted is the substantive one: the payer echoes back the accepts[] entry it
chose, so the facilitator verifies against what the client actually saw rather
than re-deriving it.

scheme and network are a relocation, not a rename. Their values were
corrected in #83 (exact, and the registered canton:<name> ids) and that work
is done — the fields simply stop being top-level, because accepted already
carries them. Nothing about the ids is outstanding here.

The inner payload

signature is an encoding change, not a rename

The spec: "The payer's ed25519 signature (base64) over preparedTxHash."
Ours is hex. Renaming the field without re-encoding produces a payload that looks
conforming and fails every signature check.

Dropping payer / publicKey moves signature verification to the ledger

This is the item to think hardest about. Today:

// verify/canton-exact.ts
verifySignature(inner.preparedTransactionHash, inner.partySignature, inner.publicKey)

and the payer's ::<fingerprint> suffix is checked against a fingerprint derived
from publicKey. The spec has neither field. Rule 8 derives the payer from
the decoded prepared transaction's sender — our decoder already exposes
DecodedTransfer.sender, so that part is a straight swap — and the facilitator
wraps signature into the ledger's partySignatures for that party.

The consequence: with no publicKey on the wire there is no key to verify
against, so the signature is no longer checkable in /verify. It is validated
by the ledger at execute time instead. /verify keeps every other check (shape,
transfer binding, deadline, preapproval) but stops being able to reject a bad
signature up front. That is what the spec prescribes; it should be a deliberate
decision rather than a side effect of deleting a field.

Removing requirementsHash is safe because of transfer binding

requirementsHash is our mechanism for binding a payload to the requirements it
was signed against. The spec's mechanism is different: accepted carries the
requirements inline, and Rules 4–6 bind the decoded transfer to them — amount,
receiver, instrument. We already implement that (findTransferMismatch), so the
binding survives the removal. It would not if transfer binding were dropped too.

Not in scope

Everything inside accepted is #76 (requirements). This issue carries
accepted as a field; its contents are that issue's problem.

Suggested split

Blocks ChainSafe/canton-x402-facilitator#340. Context: ChainSafe/canton-x402-facilitator#316.

Note: the two renames in item 1 are missing from the conformance analysis in #316 — they were found by diffing our schemas against the spec directly.