Solana Pay Explained: How On-Chain Commerce Works in 2026

Solana Pay is an open protocol for requesting and sending payments on the Solana blockchain. It defines a shared format for a payment request, so that any compatible wallet can read the same instructions and build the same kind of transaction. The protocol is maintained as open source and was introduced by the Solana Foundation, which also publishes reference material for developers.

It helps to be clear about what Solana Pay is not. It is not a wallet, so the customer still needs a Solana wallet that supports the protocol. It is not a bank or money transmitter, and it does not hold merchant funds as a default. Each payment moves directly from the customer's wallet to the merchant's wallet, with no required middle party.

Solana Pay sits between a payment standard and a checkout product. Developers can use the open protocol directly, or they can use a plugin or gateway that wraps it in a familiar store experience. Both approaches rely on the same underlying transaction model, so the decisions you make about amounts, references and confirmations apply in either case.

For a merchant, the main attraction is that the customer pays in a token they already hold, and the merchant receives the funds in its own wallet. For a shopper, the main requirement is a compatible wallet and enough balance to cover the payment and the network fee. Both sides should understand that a blockchain payment is final once it is confirmed, so refunds are handled as separate transfers.

The simplest form of Solana Pay is a transfer request. The merchant's system creates a URI that starts with the solana scheme and includes the recipient address, plus optional fields such as the amount, the token mint for an SPL token, a reference key, a label, a message and a memo. The URI is usually shown as a QR code at a physical point of sale or as a link on a web page.

When the customer scans the code or opens the link in a compatible wallet, the wallet parses these fields and shows the payment details. The customer then approves the transaction. The wallet builds the transfer, the customer signs it with their own key, and the network processes it. The merchant does not receive the customer's private key at any point.

A transfer request is useful when the amount is fixed and the recipient is known in advance. It is simple to generate and simple to understand. The main limitation is that the wallet only knows what the URI says, so the merchant's display and the wallet's display need to match closely.

• Recipient: the merchant wallet address that receives funds.
• Amount: the fixed price, expressed in the token chosen.
• Token: native SOL if no token is specified, or an SPL token identified by its mint.
• Reference: a unique key that links the transaction to one order.
• Label and message: text shown to the customer, which helps them recognise the merchant.

Before approving, a customer should check that the recipient, amount and token shown in the wallet match the checkout page.

A transaction request is a more flexible form. Instead of describing the payment in the URI, it points the wallet to an endpoint controlled by the merchant. The wallet sends a request to that endpoint and receives back a transaction that it can show to the customer. The customer reviews the transaction and signs it, and the wallet then submits it to the network.

This model suits cases where the merchant needs to build the transaction on the server. Examples include carts with several items, discounts applied at the last moment, or payments that must include extra instructions. The server can also check the customer's request before returning a transaction, which gives the merchant more control over the flow.

Transaction requests add moving parts. The endpoint has to be available, respond correctly to the wallet, and return a transaction that is valid at the moment the customer signs. Blockhashes expire, so a stale transaction will fail. Developers should also decide how to handle rejected requests and timeouts in a way that the customer can understand.

For most small merchants, a transfer request with a clear reference is enough. A transaction request is worth the extra work when the payment logic itself needs to change based on the customer or the cart. Whichever format you use, the customer should always see a readable summary before signing.

A reference key is the feature that makes Solana Pay practical for shops. The merchant generates a unique public key for each order and includes it in the payment request. When the transaction is built, the reference is added as an account in the transaction. It is not used to move funds, and it does not need to sign anything. Its only job is to make the transaction discoverable on chain.

The merchant's system then queries the network for transactions that involve that reference. When it finds one that matches the expected amount, recipient and token, it marks the order as paid. Because each reference is generated for one order, the system does not have to guess which payment belongs to which customer.

A few practical points help avoid confusion. Generate a new reference for every order rather than reusing one. Match on more than the reference alone, by checking the recipient, amount and token. Treat a transaction as confirmed only after it reaches the commitment level your business requires, not as soon as it appears.

Keep the logic in your own backend and document it. If a customer pays slightly late, or pays twice, your records should show exactly what happened. Reconciliation is easier when every order has its own reference, a stored status and a timestamp taken from the chain.

A typical Solana Pay checkout follows a short sequence. The customer selects items, the merchant's system creates an order and a reference, and it generates the payment request as a QR code or link. The customer opens a compatible wallet, scans or taps the request, and reviews the details. After approval, the wallet sends the transaction, and the merchant's system watches for the matching reference.

On the merchant side, the setup usually includes a few steps. Choose the wallet that will receive funds and secure its keys carefully. Decide which tokens to accept and test each one with small amounts. Build or install the order logic that creates references, watches for payments and updates order status. Show a clear waiting screen so the customer knows the payment is being detected.

Test the full flow before any real customers use it. Use a test environment or small amounts, and try cases such as an underpayment, an overpayment, a cancelled transaction and a payment made after the order expires. Write down what the customer sees in each case. Clear messages for these edge cases reduce support requests.

Once the flow works, monitor it. Track failed payments, the time from request to confirmation and the number of orders left in a pending state. Those numbers tell you whether the setup is working, and they show problems early.

On Solana, the base network fee for a standard transaction is small, and it is paid in SOL, not in the token the customer sends. This means a customer paying in USDC still needs some SOL in the wallet to cover the fee. Merchants often mention this in their checkout instructions, because a customer with stablecoins but no SOL may be unable to complete a payment.

Fee levels can change, and they can be affected by network conditions and by the priority fees a wallet chooses. Do not publish a fixed fee figure as a permanent fact. Instead, check a current fee source or your wallet's fee display before you set prices or explain costs to customers.

Settlement is fast compared with many card and bank systems, because a transaction is typically final once it is confirmed on chain. That speed comes with a trade-off. A blockchain payment cannot be reversed by the bank or the card network, so refunds are separate transfers that the merchant chooses to make. Write a refund policy that explains how refunds are sent and which token is returned.

Stablecoins are often chosen to reduce price swings between checkout and settlement. Be aware that a stablecoin can still move away from its peg, and that tax treatment of crypto receipts varies by location. Check your local rules on accounting, sales tax and reporting before you rely on any figure in your books.

Solana Pay has been added to several commerce tools, which makes it easier for some merchants to start without building everything themselves. Public announcements have described integration with Shopify as a payment option, and a payment provider has announced Solana Pay support so that its users can pay with crypto at checkout. Gateways also offer ready-made plugins, multi-coin support and non-custodial settlement built on the protocol.

Integrations change often, and each one has its own terms. A platform may support Solana Pay in some regions and not others, may limit the tokens available, or may change its fee structure. Before choosing a provider, read its current documentation and confirm that the features you need are live, not only planned.

When comparing options, look at a short list of practical questions. Does the provider settle directly to your wallet, or does it hold funds for a period? Which tokens and networks does it support? How does it match payments to orders, and what happens when a payment is late or partial? What data does it collect about customers, and how is that data stored?

If you already run a store on a major platform, check whether its crypto payment options include Solana Pay before building a custom integration. If you run a custom site, the open protocol gives you more control, but it also means you own the matching logic and the support burden.

Solana Pay is also being discussed in the context of AI agents and automated payments. A separate open standard called x402 uses the HTTP 402 status code, which has long been reserved for payment required, to let a server ask for a small stablecoin payment before returning a resource. Recent announcements from 2026 describe partnerships and tools that combine Solana payment rails with agent payment flows, including a Solana Foundation and Google Cloud project for on-demand payments for API calls.

The idea behind these projects is that an AI agent could pay for a service automatically, in small amounts, without a human approving each step. Some designs use payment channels, where the agent authorises a spending limit once and then spends against it. The settlement happens later, in a single transaction.

These tools are newer than basic Solana Pay checkout, and their specifications and availability may change quickly. Treat them as separate from the core protocol. If you are evaluating them, read the current documentation, check which networks and assets are supported, and confirm who controls the spending limits and keys.

For most merchants, the practical question is whether agent payments will bring new customers. That depends on your product and on how agent platforms decide which services to use. Keep the core checkout working first, and treat agent payments as an optional channel to test later.

Crypto checkout carries risks that differ from card payments. The most common problems are fake or altered payment requests, customers sending to the wrong address, and phishing pages that imitate a real checkout. Defensive habits reduce these risks on both sides.

For merchants, publish your receiving address through trusted channels, and show the recipient in a way customers can compare with their wallet. Protect the keys to your receiving wallet, use hardware or multisig controls where your volume justifies them, and separate the wallet used for daily operations from the one that holds larger balances. Keep your checkout pages on a domain you control, and avoid asking customers to enter seed phrases or private keys under any circumstances.

For customers, check the recipient, amount and token in the wallet before approving. Be cautious with links and QR codes received by message or email, especially if they ask for urgent action. A payment request should never ask you to share a seed phrase or install unknown software.

Compliance also matters. Requirements for accepting crypto, handling customer data and reporting income vary by country and by product. Check the rules that apply where you operate and where your customers live, and get professional advice before launching at scale.