How to get a Solana RPC endpoint for payment processors (2026 tutorial)

TL;DR

Subscribe to account updates on a Solana RPC endpoint during any network traffic spike, and the WebSocket connection drops without notification — your payment detection queue freezes while USDC transfers continue settling on-chain. With Visa running institutional stablecoin settlement on Solana and Western Union connecting its 360,000-location USDPT network to the chain, getting RPC infrastructure wrong is no longer just a developer problem: it is a compliance and reconciliation incident waiting to happen. This guide covers the commitment level mechanics that determine real payment finality, the archive access that audit teams will eventually require, and the multi-region node topology that payment-grade infrastructure actually looks like in 2026.

What is a Solana RPC endpoint

A Solana RPC endpoint is a network gateway that exposes Solana’s native JSON-RPC API, which shares no method names, data types, or encoding conventions with Ethereum’s JSON-RPC standard. Requests travel over HTTP for discrete operations (sendTransaction, getBalance, getAccountInfo, getTransaction) or over persistent WebSocket connections for real-time event subscriptions (accountSubscribe, logsSubscribe, slotSubscribe). A third transport layer, gRPC via the Yellowstone Geyser plugin, provides typed, structured streaming at sub-50ms latency and is the standard choice for production payment monitoring pipelines.

For payment infrastructure, a Solana RPC endpoint handles:

• Reading USDC and USDT token account balances and mint states
• Broadcasting signed transactions with configurable commitment levels and preflight simulation
• Subscribing to specific token account changes to detect incoming payments in real time
• Querying transaction status and confirmation level for settlement verification
• Simulating transactions before broadcast to catch insufficient-balance failures before funds move
• Fetching recent blockhashes required to construct valid transactions
• Querying historical SPL token transfer records for reconciliation and compliance audits

You can review the full list of supported JSON-RPC methods in the Solana developer documentation.

A degraded or overloaded endpoint does not just slow your application down. On Solana, a stale blockhash returned by an overloaded shared node produces a transaction that validators reject without returning any error code, leaving your payment system with a silent gap in its settlement records.

How Solana RPC differs from EVM chains

Solana’s RPC layer is architecturally incompatible with every EVM-based chain. There is no compatibility shim, no method alias layer, and no way to reuse ethers.js, viem, or web3.py tooling. Solana operates on public keys in Base58 encoding (not 0x-prefixed hex addresses), lamports as the base denomination (not wei), versioned binary transaction structures (not RLP-encoded hex blobs), and an account-based state model where programs are stateless and all data lives in separately addressed data accounts.

Four structural differences matter most for payment developers:

No event logs: Solana has no concept of EVM-style event emission. SPL token transfers are embedded in transaction instruction data, not in named logs. Detecting an incoming USDC payment requires either parsing the full instruction set of a transaction or subscribing to a filtered Yellowstone gRPC stream; there is no eth_getLogs equivalent.

Commitment levels are mandatory, not optional: Every Solana RPC read or write accepts a commitment parameter (processed, confirmed, or finalized). The default varies by provider. For payment operations, omitting this parameter and trusting the provider default is the single most common source of production reconciliation failures.

Transaction expiry via blockhash: Solana transactions are only valid for approximately 150 blocks (~60 seconds) from the recent blockhash embedded at construction time. An RPC node running even slightly behind the network tip returns a stale blockhash, producing a transaction that validators silently discard without returning an error.

Account model, not contract model: USDC on Solana lives in SPL token accounts associated with each wallet, not in a shared contract balance mapping. Monitoring a payment means watching the specific token account for the USDC mint, not the wallet address itself — a subtle distinction that breaks naive EVM-to-Solana migrations.

Solana RPC endpoint options

Public vs private Solana RPC endpoints

Solana’s public endpoints enforce hard limits of 100 requests per 10 seconds per IP and 40 requests per 10 seconds per individual RPC method — with no SLA, no WebSocket reliability guarantees, and shared compute that degrades under peak network load. For a payment processor monitoring multiple concurrent transaction flows, that ceiling disappears the moment two customers check out simultaneously.

Official public endpoints:

• Mainnet: https://api.mainnet-beta.solana.com
• Testnet: https://api.testnet.solana.com
• Devnet: https://api.devnet.solana.com

⚠️ Public endpoints enforce 100 req/10s per IP with no SLA, no WebSocket reliability guarantees, and no Yellowstone gRPC access. The Solana clusters documentation itself recommends deploying dedicated or private RPC servers for any production workload, explicitly excluding live applications and high-traffic services.

Feature	Public endpoint	Private/managed endpoint
Access	Free and open	Requires account
Resources	Shared infrastructure	Dedicated resources
Best use case	Local development and testing	Production payment flows
Rate limit	100 req/10s per IP, 40 per method	No aggressive throttling
WebSocket reliability	Drops under load, no reconnect SLA	Stable persistent connections
Yellowstone gRPC	Not available	Available (Chainstack from Growth plan)

For a detailed comparison of major providers, see Best Solana RPC providers for fast and reliable production in 2026.

Any endpoint producing stale blockhashes, the most common failure mode on overloaded shared infrastructure, degrades from a performance problem into a payment reliability problem that cannot be fixed at the application layer.

Full node vs archive Solana node

On Solana, payment reconciliation, audit compliance, and dispute resolution all require access to transaction history that full nodes progressively purge. Full nodes typically retain only recent weeks of history; Solana’s ledger grows at approximately 1–2 TB per year, making archive storage an explicit infrastructure decision rather than a free default.

Full node access	Archive node access
Current USDC/USDT token account balances	Full SPL token transfer history from genesis
Recent transaction status and confirmation level	Historical account state at any specific slot
Live accountSubscribe WebSocket streams	Backfilling missed payment events after an outage
Transaction simulation and preflight checks	Reconstructing settlement records for compliance audits
Active blockhash for new transaction construction	Querying account balance at an exact past slot for dispute resolution

Chainstack supports Solana archive nodes, providing access to the complete Solana ledger history for historical queries and state verification. Archive queries consume 2 RU per call instead of 1 RU for full-node requests.

Payment processors that deprioritize archive provisioning typically encounter this requirement at the worst possible moment: during a regulatory inquiry or a dispute where the relevant transaction is already beyond the full node’s retention window.

HTTPS vs WebSockets

For payment monitoring, polling via HTTPS is the wrong architecture. At Solana’s 400ms average block time, detecting an incoming USDC transfer through HTTP getSignatureStatuses polling at 1-second intervals introduces a 600ms-to-1s detection lag per payment under ideal conditions; a missed event during any polling gap is lost entirely. Ten concurrent pending payments would require ten parallel polling loops, each burning rate limit budget.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Balance reads, transaction simulation, one-time queries, blockhash fetching	Real-time payment detection, account change monitoring, slot tracking
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

For high-volume payment flows, Yellowstone gRPC outperforms WebSocket in both latency (sub-50ms versus 200–400ms) and reliability. gRPC delivers typed, filtered events — including token transfer notifications for specific mint accounts — with far more stable reconnect behavior under network stress.

WebSocket support on Chainstack Solana endpoints is available across all plan tiers. Yellowstone gRPC streaming is available from the Growth plan with 1-stream, 5-stream, and 25-stream tiers.

Why Solana became the settlement layer for stablecoins

Solana now handles roughly 35% of all on-chain stablecoin transfers globally by transaction count, ahead of every individual Ethereum L2, driven by sub-cent transaction fees, 400ms average block times, and a theoretical throughput ceiling above 50,000 transactions per second. For payment processors, the economics are straightforward: a USDC transfer that costs $2–15 on Ethereum mainnet and takes 12 seconds for confirmation costs under $0.001 on Solana and settles in under a second.

The institutional validation is no longer speculative. Visa launched USDC settlement on Solana for US banks through Cross River Bank and Lead Bank, reaching a $3.5 billion annualized settlement run rate as of late 2025. Western Union launched USDPT — its US Dollar Payment Token, backed one-to-one — on Solana in May 2026, connecting it to a global agent network spanning more than 360,000 locations. Monthly USDC transfer volume on Solana reached $880 billion in February 2026, ahead of Ethereum’s roughly $551 billion for the same period.

For teams building on Chainstack’s stablecoin infrastructure or integrating Solana into existing fintech payment platforms, this institutional adoption also means regulatory scrutiny is arriving. The infrastructure that underpins a Visa-connected payment rail is held to a different standard than a developer prototype — and that standard starts with the reliability of the RPC layer. A missed accountSubscribe event during high network traffic translates to an undetected incoming payment, a manual reconciliation task, and a potential SLA breach.

Finality guarantees and what they mean for payment UX

Solana’s three commitment levels are not interchangeable — they represent materially different degrees of settlement certainty, and choosing the wrong one for a payment flow either creates false positives (accepting payment before it is safe to do so) or unnecessary friction (making users wait for finality they do not need).

Processed (~400ms): The transaction was included in a block that has propagated to the network. This block can still be rolled back before it accumulates validator votes. Using processed as a payment confirmation signal means accepting a non-zero rollback probability. This is appropriate for read operations and internal monitoring, never for confirming that value has been received.

Confirmed (~600ms): A supermajority of the network’s stake — 66% or more of active validators — has voted on this block. Rollback probability at this stage is extremely low under normal network conditions. For consumer-facing USDC payments below a materiality threshold (point-of-sale transactions, small remittances), confirmed delivers the sub-second experience that makes Solana payment UX competitive with card networks, while providing sufficient security for everyday transaction sizes.

Finalized (~13 seconds): The block has achieved maximum lockout. No validator can produce a competing block at this height. For high-value settlement: large stablecoin transfers, exchange deposit crediting, B2B payment rails. Finalized is the required confirmation target at this tier. Any system that credits a large transfer at confirmed and later discovers a network-level rollback faces a compliance incident.

The correct payment architecture is a two-tier confirmation model: deliver the user-facing success signal at confirmed to maintain sub-second UX, then fire the internal settlement event only after finalized confirmation for high-value orders. For a detailed breakdown of which commitment level maps to which transaction type, see Solana transaction commitment levels on the Chainstack Blog.

Compliance requirements for on-chain payment infrastructure

GENIUS Act frameworks in the US and MiCA’s Transfer of Funds Regulation in the EU are transitioning from technical guidance to active enforcement requirements, and on-chain payment processors are directly in scope. The infrastructure implications are concrete.

Audit trail completeness: MiCA requires stablecoin payment processors to maintain originator and beneficiary information correlated against on-chain records for every regulated transfer. Satisfying a 90-day regulatory lookback means querying historical transaction data at arbitrary slot heights, which requires archive access. A full node that has pruned transactions older than two weeks cannot respond to this inquiry. The cost of retrofitting archive access after the first compliance audit is significantly higher than provisioning it from day one.

Real-time sanctions screening: Effective OFAC and sanctions screening for USDC and USDT flows requires detecting incoming transactions before or within seconds of confirmation — not minutes after a polling sweep. Yellowstone gRPC subscriptions at sub-50ms latency make this feasible. HTTP polling on a shared endpoint with throttled responses does not.

Infrastructure certification: SOC 2 Type II certification from your RPC provider is an increasingly standard due-diligence requirement for institutional payment counterparties, banking partners, and regulated payment service providers operating under MiCA. Chainstack holds SOC 2 Type II certification, which matters when a correspondent bank or acquiring partner asks for documentation of your infrastructure’s security controls.

Data sovereignty: For EU-regulated payment processors, where data is processed and stored is a regulatory question, not just a performance preference. Multi-region node deployments with documented data residency are becoming part of standard infrastructure due-diligence packages.

Multi-region payment node topology

A single RPC provider endpoint — even with a 99.99% uptime SLA — provides roughly 52 minutes of potential downtime per year. For a payment settlement layer processing continuous USDC flows, that is not an acceptable single point of failure.

Production payment topology for Solana follows a three-tier structure:

Tier 1 — Primary endpoint: A Dedicated Node deployed in the region closest to your primary transaction volume. Dedicated Nodes provide isolated compute, no noisy-neighbor interference, and predictable latency. For payment systems where a 100ms increase in RPC response time can push a confirmed detection beyond the payment timeout window, shared infrastructure is not viable at the primary position.

Tier 2 — Regional fallback: A Global Node from a second provider in an adjacent geographic region. Global Nodes handle the case where your primary endpoint is temporarily degraded without requiring a full failover event. Automatic routing should trigger when sustained error rates exceed 1% or when latency exceeds 500ms.

Tier 3 — Provider-level tertiary: A managed endpoint from a separate RPC provider — Helius, Triton One, or similar — to handle provider-level outages where your primary vendor’s infrastructure is the failure point. This tier exists specifically for the scenarios that affect an entire provider rather than a single endpoint.

For Yellowstone gRPC streams used in payment monitoring, run two concurrent subscriptions from different endpoints and deduplicate events at the application layer. A stream that drops and reconnects has a replay gap during which transactions may have settled; backfill that gap using getSignaturesForAddress before resuming stream-only monitoring.

How to get a private Solana RPC endpoint with Chainstack

To deploy a private Solana RPC node on Chainstack:

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select Solana as your blockchain protocol
4. Choose network: Mainnet or Testnet
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

import { address, createSolanaRpc } from "@solana/kit";

// Install: npm install @solana/kit
const rpc = createSolanaRpc("YOUR_CHAINSTACK_ENDPOINT");

// Always specify commitment for payment operations — omitting it trusts provider defaults
const balance = await rpc
  .getBalance(address("YOUR_WALLET_ADDRESS"), { commitment: "confirmed" })
  .send();

console.log(balance.value); // lamports as bigint (1 SOL = 1,000,000,000 lamports)

📖 For the full integration guide, see the Chainstack Solana tooling documentation.

You can also access Chainstack Solana RPC directly from Claude, Cursor, Codex, Gemini, or Windsurf using Chainstack MCP. Learn more about Chainstack MCP.

Chainlist is EVM-only and does not apply to Solana — no Solana networks appear in its registry.

Chainstack pricing for Solana RPC

Chainstack bills on a flat Request Unit model, which makes costs predictable across variable payment traffic — a meaningful advantage when Visa-scale settlement events can spike your request volume by an order of magnitude in minutes. See the full Chainstack pricing page for plan details, overage rates, and add-on options.

Plan	Cost	Requests/Month	RPS	Overage (per 1M extra)
Developer	Free	3M	25	$20
Growth	$49/month	20M	250	$15
Pro	$199/month	80M	400	$12.50
Business	$499/month	200M	600	$10
Enterprise	From $990/month	400M+	Unlimited	$5

Solana-specific add-ons:

• Archive Node: Archive requests consume 2 RU per call. Available from the Growth plan.
• Unlimited Node add-on: Flat-rate RPS tiers from $149/month (25 RPS) to $3,199/month (500 RPS) — no per-request billing, predictable cost at high payment volume.
• Dedicated Nodes: From $0.50/hour compute + $0.01 per 20 GB/hour storage. Required for isolated resources on production payment rails.
• Yellowstone gRPC streaming (Solana-specific): 1 stream at $49/month, 5 streams at $149/month, 25 streams at $449/month.
• Warp Transactions: $0.15 per transaction for MEV-optimized routing — relevant for time-sensitive payment submissions during network congestion.

How to estimate monthly cost

1. Baseline transaction volume: average daily transactions multiplied by 30 days.
2. Add account balance reads: one getTokenAccountBalance per payment session per active user.
3. Add WebSocket event counts: each accountSubscribe notification counts toward your RU budget.
4. Factor in archive queries: historical lookups for reconciliation and compliance consume 2 RU each.
5. Solana stablecoin payment traffic spikes hard during market events and end-of-month settlement runs — model for 3–5x your baseline RU estimate, not 2x. Multiple token accounts monitored simultaneously multiply this further.

Production readiness checklist

Core items:

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in environment/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation

Solana payment-specific items:

• Commitment level explicitly set on every payment read and write — confirmed for user-facing signals, finalized for settlement records; never rely on provider defaults for payment flows
• Transaction expiry handling implemented: if a transaction has not confirmed within 45 seconds, re-fetch a fresh blockhash and resubmit rather than treating it as definitively failed
• Yellowstone gRPC reconnect logic with getSignaturesForAddress backfill covering any disconnection window
• Archive access provisioned and confirmed before launch — not retrofitted after the first compliance request
• Use the Chainstack performance dashboard to benchmark endpoint latency before choosing a provider

Troubleshooting common Solana RPC issues

Issue	Likely Cause	How to Fix
429 Too Many Requests	Shared endpoint rate limit (100 req/10s per IP) exceeded	Move to a managed endpoint; implement a client-side request queue to stay under the limit during migration
WebSocket drops silently	Public endpoint instability or connection timeout under load	Add 30-second heartbeat pings; reconnect with exponential backoff; backfill missed events via getSignaturesForAddress for the disconnection window
Transaction confirmed, then disappears from ledger	Payment monitored at processed commitment level — block rolled back before supermajority vote	Switch all payment-critical status polling to confirmed; never use processed for payment confirmation logic
BlockhashNotFound on transaction submit	Stale blockhash from an RPC node lagging behind the network tip	Re-fetch getLatestBlockhash immediately before submitting; verify your RPC is within 2–3 slots of tip under load
getTransaction returns null for a known transaction	Transaction outside full node’s retention window	Switch to an archive endpoint; Chainstack archive data covers the full Solana ledger history
Incoming USDC payment not detected	Monitoring the wallet address instead of the token account	Subscribe to the SPL token account address for the USDC mint, not the wallet; use Yellowstone gRPC with token transfer filters for reliable event delivery
Intermittent reconciliation discrepancies	Inconsistent commitment levels across read operations in the same session	Standardize on confirmed for all user-facing reads and finalized for settlement records; document and enforce this at the application layer

Conclusion

The payment failure that is hardest to diagnose on Solana is not a crash with a clear error code — it is the USDC transfer that your WebSocket stream never detected because the subscription dropped silently during a traffic spike, and the accountSubscribe reconnect happened after the relevant event window closed. By the time the reconciliation discrepancy surfaces in your ledger, the transaction is beyond your full node’s retention window, your archive access was never provisioned, and there is no clean audit trail to share with a regulatory counterparty.

The pattern that closes these gaps is deliberate: use confirmed for user-facing payment signals, finalized for settlement records, Yellowstone gRPC with reconnect and backfill logic for account monitoring, archive nodes from day one, and a three-tier endpoint topology with a Dedicated Node at the primary position. This is not over-engineering for edge cases: it is what Visa-connected and MiCA-compliant Solana infrastructure looks like in 2026.

FAQ

What commitment level should a payment processor use on Solana? Use confirmed for the success signal shown to users — it arrives in roughly 600 milliseconds and has an extremely low rollback probability under normal network conditions. For settlement records, high-value USDC transfers, exchange deposit crediting, or any transaction where a reversal would constitute a compliance incident, wait for finalized (~13 seconds). Never use processed for payment confirmation — a processed block has not yet been voted on by a supermajority of validators and can be rolled back.

Can I use Solana’s public RPC endpoint for payment processing? Not in production. The public endpoint enforces 100 requests per 10 seconds per IP — a ceiling that evaporates under real payment load — with no WebSocket reliability guarantees and no SLA. More critically, public endpoints frequently return stale blockhashes under congestion, causing submitted transactions to expire silently without any error code propagating back to your payment system. The Solana Foundation explicitly states that public endpoints are not intended for production applications.

Do I need an archive node for payment infrastructure? Not on day one, but plan for it from the start. Full nodes prune transaction history aggressively — your reconciliation team will hit a data gap the first time they need a 90-day transaction history for a compliance audit, dispute resolution, or regulatory inquiry. Provisioning archive access retroactively means either a gap in your records or expensive reconstruction from third-party indexers. It is far cheaper to include archive from the initial infrastructure design.

How does Solana’s transaction expiry affect payment flows? Every Solana transaction is constructed with a recent blockhash and is only valid for approximately 150 blocks — roughly 60 seconds. If your RPC node returns a stale blockhash because it is lagging behind the network tip, the transaction will be silently discarded by validators with no error returned to your application. Implement expiry detection: if a transaction has not reached confirmed status within 45 seconds, re-fetch a fresh blockhash and resubmit. Do not treat an expired transaction as definitively failed without verifying it never landed.

Is Solana’s JSON-RPC API compatible with Ethereum tooling? No. Solana’s API is structurally incompatible with Ethereum’s JSON-RPC standard. There is no eth_getBalance, no eth_getLogs, no ABI encoding, and no compatibility shim. SPL token transfers are embedded in transaction instruction data and require dedicated parsing — there is no event log equivalent. Teams migrating from EVM chains need a full SDK rewrite using @solana/kit (the current standard) or @solana/web3.js for JavaScript, or the native Rust SDK for on-chain programs.

What is Yellowstone gRPC and why does it matter for payment processors? Yellowstone gRPC is Solana’s native high-performance streaming interface, delivering account updates, transaction notifications, and slot events at sub-50ms latency with typed, structured payloads and filtering support. For a payment processor monitoring incoming USDC transfers, this is materially better than WebSocket subscriptions, which run at 200–400ms latency and drop silently under load; HTTP polling cannot match real-time confirmation speeds at scale. Chainstack provides hosted Yellowstone gRPC from the Growth plan, including token-account-level filters that let you subscribe to specific mint activity without processing every network event.

Additional resources

• Solana: Transferring SPL tokens in TypeScript — end-to-end SPL token transfer walkthrough directly applicable to USDC and USDT payment implementations
• Chainstack Solana tooling documentation — SDK setup, WebSocket configuration, gRPC integration, and endpoint connection guides
• Real-time Solana data: WSS vs Yellowstone gRPC Geyser — Chainstack comparison guide for choosing between WebSocket and gRPC for payment event monitoring
• Solana RPC methods reference — official documentation for all supported JSON-RPC methods and parameters
• More Solana tutorials and articles on the Chainstack Blog