Art 777: PSP Dispute Reason Crosswalk

A buyer says “I never authorized this charge,” and each PSP’s paperwork names that condition differently.

Each PSP’s values are reproduced verbatim from that PSP’s own published tables: PayPal’s dispute_reason enum (schema v1.12, including the British UNAUTHORISED), Stripe’s reason, Adyen’s Visa scheme reason codes, Square’s DisputeReason. The crosswalk never renames or normalizes anyone’s vocabulary; it maps between them.

Every mapping cell cites the snapshot clause that justifies it: id, verbatim quote, URL.

Four primary-text snapshots (PayPal S1–S9, Stripe S1–S6, Adyen A1–A6, Square Q1–Q5) are the authority here. Quotes are verbatim and short. Where a snapshot itself states an absence (Stripe’s Visa table mapping Unrecognized to None; Square publishing no network mapping), that stated absence is cited, not guessed around.

Give it one PSP’s reason; get the equivalents at the other three, each graded exact, partial or none.

Why partial for Stripe: Stripe’s own Visa row makes “Fraudulent” broader than a buyer-unauthorized claim (it spans card-present, card-absent and monitoring-program fraud). The grade is that cell’s own clauses speaking, not a judgment call, and the output carries the per-PSP match, the concept label, and every cited clause with its quote.

crosswalk_psp_dispute_reasons {psp: "paypal", reason: "UNAUTHORISED"}

A reason no other PSP’s snapshot supports crosses to none, with the absence stated, not papered over.

The proptest floor (P5) asserts this on singletons: the one designed partial exception (Adyen’s singleton reaching Stripe’s aggregate S5 category) is cited-partial, never silent, never upgraded to exact. Fixture singleton_paypal_crosses_to_none pins the PayPal case end to end.

A Visa 13.1 or Mastercard 4855 code also enters the crosswalk wherever a snapshot publishes the mapping.

Network-code lookups use only the tables the snapshots actually reproduce (Stripe’s Visa and Mastercard category tables; Adyen’s Visa scheme codes). An unknown network or a code no table carries is refused by name: REFUSED_UNKNOWN_NETWORK, REFUSED_UNKNOWN_NETWORK_CODE.

Bad input gets a named refusal in refusal_reason and domain_errors, never a stack trace.

Seven refusal vectors are pinned in the fixtures: unknown PSP (the categorical check fires first: an empty object is REFUSED_UNKNOWN_PSP, a recorded nuance), the PayPal American-vs-British spelling distinction, unknown reason, both-or-neither input shape, unknown network and unknown network code.

crosswalk_psp_dispute_reasons {network_code: {network: "visa", code: "13.1"}}

One input surface, one output contract, one kernel digest, and the whole thing runs offline.

Kernel: chaingraph/kernels/art-777-psp-dispute-reason-crosswalk.kernel.mjs: pure data tables plus lookup, no hashing inside the kernel, no iteration bound from inputs. Identity: sha256:8932a23abee00ab938d8cbc12ccc3cc44bd59addb232c25e4097e343e4383037 (SPEC §17.1 compute_images). Prove: deferred (a new gpu:false node excluded from §18 proving until the next batch). Fixtures: 14 vectors with pinned golden hashes; the manifest’s example_execution_hash (2e76d901…) equals the golden vector’s pinned hash. Clause authority: research/clause-snapshots/{paypal,stripe,adyen,square}-disputes-2026-10/SNAPSHOT.md.

input  : {psp: paypal|stripe|adyen|square, reason: <that PSP's exact enum value>}
        | {network_code: {network: visa|mastercard, code: <published code>}}
output : {concept, concept_label, match, per_psp_match,
          crosswalk: {<psp>: {value, match, basis, evidence_categories, clauses[]}},
          network_codes, network_codes_note, cited_clauses[], domain_errors[], refusal_reason}
refuse : REFUSED_UNKNOWN_PSP | REFUSED_UNKNOWN_REASON | REFUSED_INPUT_SHAPE
        | REFUSED_UNKNOWN_NETWORK | REFUSED_UNKNOWN_NETWORK_CODE