Rails

Most pairings need nothing from you beyond the seller's document and your signer. Where a build needs a value only the buyer can supply (a recent blockhash, an account sequence, a deposit), you pass it in inputs. This page lists, rail by rail, the account form each pairing accepts, the kind of request your signer receives, and every input the build reads.

A missing or malformed input declines with no-payable-option and a detail ending in /input-missing, before any fetch of the ATR. Input values are JSON: a decimal is a string of digits ("1000000"), an integer is a JSON number, hex is 0x followed by hex digits.

The pairings reference gives each pairing's binding export, its Python constant, and what its payment proves. The signers guide gives the answer each request kind takes.

AccountsCopy Anchor Link

The signer's account is CAIP-10. Its namespace selects the pairings it can pay:

EVMCopy Anchor Link

TempoCopy Anchor Link

SolanaCopy Anchor Link

StellarCopy Anchor Link

The gate passes your account's address to the build as the payer. Before anything reaches your signer, the build compares the transfer your simulated transaction carries with what the seller asked for, and declines offer-unreadable when they differ:

XRP LedgerCopy Anchor Link

An mpp/session/xrpl challenge's amount is the first claim's cumulative total in drops, which the claim signs as a 64-bit unsigned integer. A challenge whose amount is anything but such a number written as a decimal string, with no sign, point or leading zero, does not offer the pairing (mpp/request-malformed): the gate declines no-payable-option, and nothing is signed.

HederaCopy Anchor Link

Other chainsCopy Anchor Link

LightningCopy Anchor Link

Your node moves the payment when it pays the invoice. A decline after that carries moved.

On x402/exact/lnbtc/invoice-named the ATR itself names the invoice. The gate pays only when the ATR's bytes are one JSON object whose first members are atrVersion, id and x402, in that order, with no member name repeated, and whose x402 slot holds the option's invoice; otherwise it declines offer-unreadable with ln/invoice-not-named before your node is asked to pay. Every JSON reader then finds the same x402 slot, since RFC 8259 leaves a repeated name to each reader.

CloudflareCopy Anchor Link

Cards and StripeCopy Anchor Link

Mandates and checkoutsCopy Anchor Link

Where the request is "none", confirm returns request: null. For x402/batch-settlement/cloudflare, whose build is itself the payment, finish with a null signature completes it, and transact returns it as signed. For every other such pairing, transact returns signed: null once the comparison and, where the pairing needs one, the agreement payment are done, and the protocol's own flow completes the payment.

Pairings that pay an agreement firstCopy Anchor Link

With transact, every pairing whose payment is not itself a public proof of H pays the seller's agreement URL first, once the buyer's agent has approved that payment. confirm and finish neither pay nor check the agreement; only transact and agree do (see driving the steps yourself). The pairings reference marks these pairings, and the agreement payments guide describes the exchange. The agreement payment's build reads the same inputs as the payment's own: a Solana agreement option reads the Solana inputs above. Pass agreementSigner to transact when a different wallet pays the agreement, for example an EVM wallet beside a card.