Solana USDC Payments Verified End-to-End

Published: October 18, 2026

The full x402 flow on the Solana rail — 402 challenge, transaction construction, partial signing, fee payer signature, on-chain settlement, and the retry that returns data — is now verified against live mainnet USDC. The interactive API docs have been updated to explain both rails.

What was verified

We ran an end-to-end payment against https://xrplme.online/wc/v1/thailand/bot-solana and confirmed the complete cycle:

POST with no payment → 402 Payment Required with terms
Construct a Solana transaction with 3 instructions: SetComputeUnitLimit, SetComputeUnitPrice, and TransferChecked (USDC)
Partially sign the transaction with the buyer's wallet only
Send the payment payload as X-PAYMENT-SIGNATURE
Facilitator adds its fee payer signature and simulates on-chain
HTTP 200 with data

network   : solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
asset     : EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v   # native USDC
amount    : 1000000                                            # 1.00 USDC
payTo     : 5KMiN7b7qBAqE2o5ucoCJ5xH9vZaFfzvq3dHeiGGvcMw
feePayer  : 32jx1jS6Dkkf7fuGv33h1rVgbAaMHNtnVbGkTWhW8heL
qrData    : solana:5KMiN7b7qBAqE2o5ucoCJ5xH9vZaFfzvq3dHeiGGvcMw?amount=1.00&spl-token=EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

What makes the Solana flow different

On the XRPL, the buyer signs a payment and sends two headers (X-PAYMENT-SIGNATURE + X-INV-ID). On Solana, the transaction must be partially signed by the buyer's wallet, then the facilitator adds a second signature from its fee payer wallet — because the buyer may hold USDC but no SOL for network fees.

Three things that trip up clients

3 instructions minimum. The facilitator's verifier expects at least SetComputeUnitLimit + SetComputeUnitPrice + TransferChecked. A bare transfer with only one instruction is rejected.
partial_sign, not sign. The fee payer (32jx1jS6…) is a separate wallet. The buyer signs only the token transfer; the facilitator signs the fee payer slot during verification.
Message payer must be the fee payer. The Solana Message is constructed with the facilitator's fee payer address as the payer — not the buyer's wallet. Otherwise the fee payer signature doesn't match.

Wallet roles

Role	Holds	Key location
Collector (`payTo`)	All USDC revenue	Not on the server — Phantom address only
Fee payer	SOL for network fees	Server `0600` env file
Payer (buyer)	USDC only	Buyer’s wallet

The revenue wallet never has its key on the server. Separating gas from revenue means the collector address can be a cold wallet.

Pricing

Tier	XRPL (XRP)	Solana (USDC)
Standard	1 XRP	1.00 USDC
AI-enhanced	5 XRP	7.00 USDC

Prices settle nightly from server_solana.py (PRICE_STD / PRICE_AI) and are also returned live in every 402 response. Query xrplme_get_pricing for the current values.

Interactive docs updated

The API docs page now includes a payment rail selector (XRP vs USDC), correct pricing labels for both tiers, and Solana-specific 402 handling — it reads qrData (Solana Pay URI), feePayer, and displays the right retry instructions.