Solana Agentic Payments: Choosing the HTTP Flow Before Choosing the Wallet

A model-inference API wants to sell individual requests today and longer metered sessions later. Its operator already uses Solana for stablecoin payments. The next choice is not simply a wallet SDK: it is the commercial interaction the HTTP client and server will understand.

Research boundary: Solana’s official payment documentation reviewed November 1, 2026. No paid inference request, wallet signature or onchain settlement was performed for this article.

Start with the interaction, not the shared status code

The agentic-payments overview presents both MPP and x402 on Solana. They use different headers and data models, even though both can begin with an HTTP 402 response. A service can offer multiple payment options, but a client must select one complete supported exchange.

HTTP role	MPP	x402 V2
Challenge	WWW-Authenticate: Payment	PAYMENT-REQUIRED
Client proof	Authorization: Payment	PAYMENT-SIGNATURE
Receipt	Payment-Receipt	PAYMENT-RESPONSE

Those names matter operationally. A proxy that strips one header, a client built for another protocol version, or a facilitator missing the selected scheme can break the flow even when all parties support Solana wallets.

For the inference seller, first decide whether each request has a fixed price or whether the final charge depends on measured usage. Then select the protocol implementation and confirm that every component supports the intended model. Do not infer metered settlement from the presence of a maximum-amount field alone.

The chain settles value; the service releases the resource

Conceptual charge flow, not a live inference or settlement test. Session flows can verify usage before a later settlement step.

The server owns the relationship between a payment and a particular request. A valid transfer to the correct address is not enough if it was already used for a different purchase. Design a durable record linking request identity, accepted payment proof, transaction outcome and delivered response.

For retryable API work, our recommendation is to separate retrying delivery from authorizing another charge. If inference completed but the connection dropped, the buyer should have a defined retrieval or dispute path. Generating another payment automatically can convert a transport failure into duplicate billing.

MPP distinguishes a charge from a metered session

The Solana MPP guide describes one-time charges and sessions based on cumulative vouchers. A session can amortize settlement across repeated usage; it is not necessarily a separate onchain transfer for every event. The specifications remain evolving Internet-Drafts.

The same guide distinguishes a client sending a signed transaction for server submission from a client submitting first and presenting the transaction signature. The fee-payer and retry responsibilities differ. Choose the mode deliberately, especially if the product promises that the buyer does not need SOL for fees.

For metered inference, the product should explain what is reserved, what has been consumed and how unused funds can be recovered. The service needs to preserve accepted usage state across restarts. Calling every session a “streaming payment” can mislead readers if the application simply settles a series of discrete calls.

x402 needs a compatible scheme, not just a compatible chain

The x402 V2 guide distinguishes fixed-amount exact from upto, where support must be checked across client, server and facilitator. It also warns against carrying V1 headers and network labels into a new V2 integration.

A facilitator is one possible verification and submission component; a resource server can also perform that role itself. Decide who operates the chosen path, what happens during its outage and how the seller independently reconciles results. Outsourcing verification does not remove the seller’s responsibility to avoid releasing the same resource entitlement twice against one proof.

Transaction lifetime belongs in the retry design

Solana’s production guide distinguishes transaction submission from confirmation and covers recent-blockhash expiry. Re-sending an existing signed transaction and rebuilding a new transaction are different operations. A local timeout alone should not decide which one is safe.

For the hypothetical API, proposed acceptance checks include:

• A payment proof replayed against a second request does not create another entitlement.
• Concurrent server instances share the payment-consumption record.
• An expired transaction is reconciled before a newly authorized replacement is attempted.
• The required commitment level is checked, not merely the existence of a signature.
• A fee sponsor validates the complete transaction it agrees to sign.

These checks are design requirements, not reported test results. Budget separately for the API charge, transaction fees, account-related costs where applicable and infrastructure operations.

Our assessment

Solana offers a useful settlement option for teams whose assets, wallets and payment clients already fit its ecosystem. The integration work is still at the boundaries: protocol version, scheme support, signer authority, replay handling and fulfillment. Start with one fixed-price sandbox route before adding sessions or multiple payment options.

See the Solana payments reference, MPP and x402. MPP is the Machine Payments Protocol; MCP is a separate tool-access protocol and should not be used as an interchangeable name.