Payment rail

Card networks

On card networks, a Verifiable Intent mandate signs the hash of a checkout that carries the ATR hash, and an agent’s Trusted Agent Protocol signature covers it when the agent adds it; a plain card checkout carries it in the seller’s processor reference. Source: lcp docs: agentic checkouts⁠ (opens in a new tab) The Agentic Transaction Record (ATR) is one record of exactly what was agreed, for one transaction. Its ATR hash, the ATR’s fingerprint, is the proof bound to the transaction: change one byte of the ATR and it no longer matches. Source: lcp docs: the ATR⁠ (opens in a new tab) · Source: lcp docs: the ATR hash⁠ (opens in a new tab)

lcp docs: agentic checkouts⁠ (opens in a new tab) · lcp docs: the ATR⁠ (opens in a new tab) · lcp docs: the ATR hash⁠ (opens in a new tab)

Card networks

Example

Field: the agent’s signature, the mandate, or the processor reference

lcp:sha256:0x8448dc1b716a5103287cb8f35e36b614ffd91e630ab8b7911833c54748ad5ca6

The ATR hash, written out as text.

This example’s ATR hash, as it rides

Where the ATR hash rides

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

Exhibit Each field, and the pairings that use it

The package

The card authorization itself does not carry the ATR hash. A Mastercard Verifiable Intent mandate signs a checkout that carries it; with a plain card checkout, nothing the buyer signs carries it. Source: lcp docs: agentic checkouts⁠ (opens in a new tab) · Source: lcp docs: pairings reference⁠ (opens in a new tab)

A Visa Trusted Agent Protocol signature covers the ATR hash only where the agent lists the lcp-hash field among the components it signs. TAP signs the request’s authority and path, and covering another field is an arrangement between the agent and the seller, which TAP does not define. Source: LCP §C.6⁠ (opens in a new tab) · Source: lcp docs: agentic checkouts⁠ (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.

lcp docs: pairings reference⁠ (opens in a new tab)

Exhibit Each pairing’s record

The package

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)
Pattern: id-reuse, the package’s name for it
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)
Pattern: id-reuse, the package’s name for it
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)
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>. This ATR's hash and link are for the seller to show the buyer and to put in its processor reference. Nothing the buyer signed carries the hash, nothing the buyer signed was checked, and settlement is the seller's report. This record does not show that the buyer's approval carried the hash.
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 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 nothing the buyer signed was checked. 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)

Ready to see your own agreements proved?

Tell us what you sell, buy or carry, and we will show you where the agreement rides in it.

Integra Binder, hosted by Integra, does the seller’s side of each agreement and is free on test networks, with test-network USDC.

Talk to us