Solana Pay

• Name: Solana Pay
• URL: https://docs.solanapay.com/spec
• Category: payment-request URL standard / wallet-to-merchant transaction-vending protocol / QR and deep-link payment middleware
• Tags: solana-ecosystem
• Summary: Solana Pay is best kept as a payment-request and transaction-vending standard, not a full payments stack. The important split is simple: one mode encodes a transfer request directly in a solana: URL, while the other turns the URL into a pointer to a merchant HTTPS endpoint that can vend a transaction. That makes Solana Pay a useful mechanism note because it keeps request encoding, reconciliation, and wallet trust policy legible instead of flattening everything into Solana checkout.
• What it does:
  • Defines solana: transfer-request URLs for direct SOL or SPL-token payments
  • Defines interactive transaction-request flows where the wallet fetches metadata and a serialized transaction from a merchant HTTPS endpoint
  • Standardizes optional fields such as amount, spl-token, reference, label, message, and memo
  • Uses reference public keys as reconciliation markers so merchants can locate and verify payments onchain
  • Requires wallets to treat merchant-vended transactions as untrusted and validate the signature structure before signing
• Key claims:
  • The transfer-request versus transaction-request split is the whole reason to keep this note: it cleanly separates static payment encoding from remote transaction construction
  • The reference field matters because it gives merchants a durable reconciliation hook before the final transaction signature exists
  • The spec is explicit about wallet safety boundaries, which makes Solana Pay more analytically useful than a generic QR-payment note
  • This is a solid lower-layer Solana commerce primitive, but it is still a mechanism note, not a broad merchant-control-plane anchor
• Whitepaper: No standalone Solana Pay whitepaper surfaced in this pass. The strongest primary materials were the official specification, the merchant integration guides, and the current Solana Commerce SDK surfaces collected in ../../whitepapers/solana-pay-primary-sources-2026-05-13.md.
• Sources:
  • https://docs.solanapay.com/spec
  • https://docs.solanapay.com/core/transfer-request/overview
  • https://docs.solanapay.com/core/transfer-request/merchant-integration
  • https://docs.solanapay.com/core/transaction-request/merchant-integration
  • https://github.com/solana-foundation/commerce-kit
  • https://raw.githubusercontent.com/solana-foundation/commerce-kit/main/packages/solana-pay/README.md
  • https://raw.githubusercontent.com/solana-foundation/commerce-kit/main/packages/solana-pay/package.json

Internal linkages

• Best comparison points: solana-actions, walletconnect-pay, and x402.

Control surface

• The real leverage is offchain: the merchant endpoint decides metadata, vended transaction contents, and how much extra logic gets smuggled into the flow.

• So Solana Pay stands or falls on wallet-side validation, allow or deny policy, reference-handling discipline, and how much trust the wallet extends to remote transaction-vending infrastructure.

• Keep it as payment-request middleware, not a merchant-control-plane anchor.

• Last reviewed: 2026-06-17 UTC