Payment rail

Card networks

On card networks, the agent’s signature or the user’s mandate covers the ATR hash; a plain card checkout carries it in the processor reference. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)

Sources (1)

lcp docs: agentic checkouts⁠ (opens in a new tab)

Where the ATR hash rides

On this rail, the ATR hash rides in the agent’s signature, the mandate, or the processor reference.

The standard

The card authorization itself does not carry the ATR hash. With Visa’s Trusted Agent Protocol and Mastercard’s Verifiable Intent, what the agent or the user signs does; with a plain card checkout, nothing the buyer signs does, and the pairing’s record says so. Source: lcp docs: agentic checkouts⁠ (opens in a new tab) · Source: lcp docs: pairings reference⁠ (opens in a new tab)

An lcp-hash field that the agent lists among the covered components of every agent-payer-auth message signature it sends (RFC 9421). Source: lcp docs: agentic checkouts⁠ (opens in a new tab)
card/visa-tap
The merchant’s checkout_jwt, as its legalContext; a Verifiable Intent mandate signs that JWT’s SHA-256 as checkout_hash. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)
card/mastercard-vi/immediatecard/mastercard-vi/autonomous
A plain card checkout: nothing the buyer signs carries H. The seller shows H and the link before payment and places H’s LCP string in its processor reference. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)
card/seller-reference
The MPP request’s externalId. The buyer’s card signs nothing that carries H. Source: lcp docs: MPP⁠ (opens in a new tab)
mpp/charge/card

Entry points: @integraledger/lcp/card, @integraledger/lcp/mpp

The data

Read from the published packages when the site was built; nothing here is typed by hand.

The ATR hash of the site’s example ATR, as this rail carries it

H’s LCP string, as the seller’s processor reference

lcp:sha256:0x8448dc1b716a5103287cb8f35e36b614ffd91e630ab8b7911833c54748ad5ca6

Computed from the site’s example ATR by this rail’s own helper in the package, when the site was built.

What a payment on this rail proves

Of these 5 pairings, 3 have the buyer’s signature cover the ATR hash, 0 leave a public proof of it, and 0 let anyone read it back from the chain alone. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

The standard

card/visa-tapProtocol ExtensionBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Protocol Extension (LCP §8.3.6)⁠ (opens in a new tab)
Where the ATR hash rides: An lcp-hash field that the agent lists among the covered components of every agent-payer-auth message signature it sends (RFC 9421).
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The buyer's agent sent this ATR's hash in the lcp-hash field and listed that field among the covered components of every TAP agent-payer-auth message signature in the request. The seller checked that listing and did not verify a signature here, which belongs to its TAP recognition step. The card authorization itself does not carry the hash. This does not show that amount, payee or timing match the ATR's content.
LCP profile: card/visa-tap⁠ (opens in a new tab)
card/mastercard-vi/immediateId-ReuseBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: The merchant’s checkout_jwt, as its legalContext; a Verifiable Intent mandate signs that JWT’s SHA-256 as checkout_hash.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The user's Verifiable Intent L2 mandate lists a checkout mandate whose checkout_hash is the SHA-256 of a checkout_jwt carrying this ATR's hash, and the payment mandate's transaction_id, where disclosed, equals it. The seller checked those values and did not verify the user's signature, which Verifiable Intent has the payment network validate before authorization. The card authorization itself does not carry the hash. This does not show that amount, payee or timing match the ATR's content.
LCP profile: card/mastercard-vi⁠ (opens in a new tab)
card/mastercard-vi/autonomousId-ReuseBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: The merchant’s checkout_jwt, as its legalContext; a Verifiable Intent mandate signs that JWT’s SHA-256 as checkout_hash.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The buyer's agent signed a Verifiable Intent L3b checkout mandate whose checkout_hash is the SHA-256 of a checkout_jwt carrying this ATR's hash, with the key the user's L2 mandate delegates to it. The seller verified both ES256 signatures and the sd_hash links, but not the L1 issuer's signature. The user's own signature does not cover the hash, and the seller did not see the L3a payment mandate the network received, whose transaction_id Verifiable Intent requires to equal this checkout_hash. This does not show that amount, payee or timing match the ATR's content.
LCP profile: card/mastercard-vi⁠ (opens in a new tab)
card/seller-referenceHTTP-layer advisoryBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: HTTP-layer advisory (LCP §8.3.7)⁠ (opens in a new tab)
Where the ATR hash rides: A plain card checkout: nothing the buyer signs carries H. The seller shows H and the link before payment and places H’s LCP string in its processor reference.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The ATR was in the seller's storage before payment, and its hash and link were given to the seller to show the buyer and to place in its processor reference. Nothing the buyer signed carries the hash. The seller checked nothing the buyer signed, and settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
mpp/charge/cardOpaque ChallengeBuyer signs H: noH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
Where the ATR hash rides: The MPP request’s externalId. The buyer’s card signs nothing that carries H.
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The ATR was in the seller's storage before payment. The seller's MPP challenge carried this ATR's hash in its id and its opaque reference, bound to the challenge by the seller's own server, and the buyer's credential echoed that challenge. The seller also placed the hash in the method's reference field (externalId for card; the PaymentIntent's metadata for Stripe). Nothing the buyer or its card or Stripe token signed carries the hash, and the seller checked nothing the buyer signed. Settlement is the seller's report. This record does not show that the buyer's approval carried the hash.

Where a sentence names <network> and <transaction>, the pairing’s record fills them in: they name the agreement payment the buyer made first. Source: lcp docs: pairings reference⁠ (opens in a new tab) · Source: lcp docs: the agreement URL⁠ (opens in a new tab)

Reading the settlement

This rail has no public settlement for the package to read.

The protocols that pay on it

lcp docs: agentic checkouts⁠ (opens in a new tab)