Payment rail

XRP Ledger

On the XRP Ledger, the Payment’s InvoiceID carries the ATR hash or a hash of it. Source: lcp docs: rails⁠ (opens in a new tab)

Sources (1)

lcp docs: rails⁠ (opens in a new tab)

Where the ATR hash rides

On this rail, the ATR hash rides in the Payment’s InvoiceID.

The standard

Under x402 the InvoiceID is a SHA-256 of the ATR hash’s LCP string; under MPP it is the ATR hash itself. Source: lcp docs: rails⁠ (opens in a new tab)

The Payment’s InvoiceID: SHA-256 of H’s LCP string. The payer signs with a single key: a blob that carries Signers is refused xrpl/multisigned. Source: lcp docs: rails⁠ (opens in a new tab)
x402/exact/xrpl
The Payment’s InvoiceID: H. The payer signs with a single key, as for x402/exact/xrpl. Source: lcp docs: rails⁠ (opens in a new tab)
mpp/charge/xrpl
The PaymentChannelCreate’s one memo: H’s LCP string. The payer signs the opening with a single key. Source: lcp docs: rails⁠ (opens in a new tab)
mpp/session/xrpl

Entry points: @integraledger/lcp/xrpl, @integraledger/lcp/x402-exact-xrpl, @integraledger/lcp/mpp · Install beside the package: ripple-binary-codec

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

the x402 InvoiceID: SHA-256 of H’s LCP string

EDFC016DBC705845777C0A0B18ED760674935F8BDC774DE6161D9016D0BD5672

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 3 pairings, 3 have the buyer’s signature cover the ATR hash, 3 leave a public proof of it, and 2 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

x402/exact/xrplId-ReuseBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: no
Pattern: Id-Reuse (LCP §8.3.5)⁠ (opens in a new tab)
Where the ATR hash rides: The Payment’s InvoiceID: SHA-256 of H’s LCP string. The payer signs with a single key: a blob that carries Signers is refused xrpl/multisigned.
What a payment through it proves: The payer signed, with a single key, an XRPL Payment whose InvoiceID is the SHA-256 of this ATR's hash in LCP string form, and the Payment is in a validated ledger with tesSUCCESS. The hash can be confirmed from the ATR's bytes but not recovered from the ledger alone. This does not show that amount, destination, asset or timing match the ATR's content.
mpp/charge/xrplNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The Payment’s InvoiceID: H. The payer signs with a single key, as for x402/exact/xrpl.
What a payment through it proves: The payer signed, with a single key, an XRPL Payment whose InvoiceID is this ATR's hash, and the Payment is in a validated ledger with tesSUCCESS. This does not show that amount, destination, asset or timing match the ATR's content.
mpp/session/xrplNative FieldBuyer signs H: yesH on chain: yesPublic proof: yesRecoverable from chain: yes
Pattern: Native Field (LCP §8.3.1)⁠ (opens in a new tab)
Where the ATR hash rides: The PaymentChannelCreate’s one memo: H’s LCP string. The payer signs the opening with a single key.
What a payment through it proves: The payer signed, with a single key, an XRPL PaymentChannelCreate whose one LCP memo carries this ATR's hash, and it is in a validated ledger with tesSUCCESS. The memo is in the public transaction. Later requests in this channel were paid under this ATR by vouchers the seller did not meter; each signs the channel id and an amount, not the hash. This does not show that amount, deposit, destination, settle delay or timing match the ATR's content.
LCP profile: mpp/session/hedera-solana-xrpl⁠ (opens in a new tab)

Reading the settlement

The package reads a payment’s settlement through a reader you supply: the endpoint, the credentials, the timeouts and the retries are yours. A reader that fails never makes a payment read as failed. Source: lcp docs: reading settlement⁠ (opens in a new tab)

Sources (1)

lcp docs: reading settlement⁠ (opens in a new tab)

The protocols that pay on it

lcp docs: rails⁠ (opens in a new tab)