Solana Pay standardizes two different layers that are easy to flatten together: a non-interactive transfer-request URL and an interactive transaction-request URL that points wallets at a merchant HTTPS endpoint.
The transfer-request spec is more than a payment deep link. Recipient semantics, token-mint handling, ATA derivation, reference-key indexing, memo placement, and instruction ordering are all made explicit.
The reference parameter is the most reusable mechanism insight. It lets merchants create an order-correlated onchain lookup key before the final transaction signature exists, then find and validate the payment later.
The transaction-request flow is where a second control surface appears. Merchant infrastructure serves GET metadata and POST transaction bodies, which means branding, transaction composition, and some payment logic move off the static URL and into the merchant server.
The wallet-side safety rules matter analytically: interactive request links must resolve to absolute HTTPS URLs, returned transactions are untrusted, signature expectations are strict, and wallets must only sign for the requested account.
The merchant guides make it clear that Solana Pay is also a reconciliation and checkout protocol. The backend is expected to generate references in a trusted environment, store expected amounts, locate the payment by reference, and validate the final transfer before releasing goods or services.
Specific source signals worth retaining
The specification page is the best source for the exact URL grammar, the split between transfer requests and transaction requests, and the wallet validation rules for interactive transactions.
The transfer-request merchant guide is the best source for the operational merchant flow: generate a unique reference, encode the URL, display a QR, find the transaction onchain, and validate the transfer.
The transaction-request merchant guide is the best source for how Solana Pay expands beyond simple payments into arbitrary merchant-vended transactions and merchant-supplied metadata.
The current @solana-commerce/solana-pay README is useful evidence that the standard is still being packaged as a reusable SDK surface with URL encode/parse, QR generation, transfer building, and transaction-request support.
Why this entry belongs in the corpus
It gives the payments cluster a Solana-native request-and-reconciliation baseline beneath richer app-specific commerce flows and beneath newer social-distribution formats like Solana Actions.
It helps separate request encoding, merchant transaction vending, onchain reconciliation, and wallet signing policy instead of collapsing them into one generic payment QR story.
The durable insight is that payment UX power sits not only in the wallet or merchant app, but in the request format, reference-indexing scheme, merchant server behavior, and wallet validation boundaries that tie them together.