How to get a BNB Smart Chain RPC endpoint for payment processors (2026 guide)

TL;DR

A shopper pays a merchant in USDT, the transaction finalizes on BNB Smart Chain in barely over a second, and your payment processor still shows “pending” three minutes later — because the one efficient way to watch thousands of merchant deposit addresses at once, eth_getLogs, is disabled on every public BNB mainnet endpoint, and per-address polling across sub-half-second blocks burns through the shared rate limit before you finish a single sweep. For a payment processor, that gap is not a latency annoyance; it is a checkout that times out and a merchant who churns. This guide shows how BNB Smart Chain RPC behaves under payment-acceptance load and how to provision a private endpoint that keeps deposit detection and payouts in lockstep with the chain.

What is a BNB Smart Chain RPC endpoint?

A BNB Smart Chain RPC endpoint is the JSON-RPC interface your payment backend uses to read state from and broadcast transactions to the network. BNB Smart Chain is an EVM-compatible Layer 1 secured by Proof of Staked Authority, so the method surface is the standard eth_* set — eth_call, eth_getBalance, eth_getLogs, eth_sendRawTransaction, eth_getTransactionReceipt. For a payment processor, the endpoint is the exact point where an inbound stablecoin transfer becomes a “paid” webhook, where a sweep moves merchant funds into a settlement wallet, and where a payout to a merchant’s bank-linked address is acknowledged. Every checkout, every settlement, every refund is a sequence of RPC calls — and the endpoint either keeps pace with the chain or your payment status falls behind reality.

In a payment-acceptance context, the endpoint is what powers:

• Detecting inbound BEP-20 stablecoin payments (USDT, USDC) by watching Transfer events across many merchant deposit addresses
• Confirming a payment reached finality via eth_getTransactionReceipt and block confirmations
• Sweeping collected funds from deposit addresses into a hot or cold settlement wallet through eth_sendRawTransaction
• Broadcasting merchant payouts and refunds, with eth_estimateGas and nonce management to keep them flowing
• Reading eth_getBalance and BNB gas balances to know when deposit addresses need top-ups before a sweep can run
• Generating per-checkout deposit addresses and tracking their state without a self-hosted indexer

You can review the full list of supported JSON-RPC methods in the BNB Chain developer documentation. For a payment processor the decisive detail is concentrated in event access: the instant you need to detect payments across more than a handful of addresses, eth_getLogs with a topic filter is the only call that scales — and it is precisely the call public BNB endpoints refuse to serve. When that door is closed, your detection layer falls back to polling every address one at a time, and on a chain producing blocks faster than almost any other EVM network, that fallback does not scale to a real merchant base.

How BNB Smart Chain RPC differs from Ethereum RPC

BNB Smart Chain speaks the same JSON-RPC dialect as Ethereum, but the operating characteristics that decide a payment processor’s architecture are different enough to change how you provision infrastructure.

Property	Ethereum	BNB Smart Chain
Block time	~12 seconds	~0.45 seconds (post-Fermi, Jan 2026)
Fast finality	~12–15 min	~1.1 seconds
Consensus	Proof of Stake	Proof of Staked Authority
Gas token	ETH	BNB
eth_getLogs on public endpoints	Generally available (rate-limited)	Disabled on public mainnet
Public endpoint rate limit	Varies	10K requests / 5 min, shared

The block cadence is the part that reshapes a payment stack. BNB Smart Chain has compressed its block time from 1.5 seconds to 0.75 seconds (Maxwell, mid-2025) to roughly 0.45 seconds (Fermi, January 2026), with irreversible finality near 1.1 seconds. That is excellent for checkout UX — a customer’s payment is settled almost instantly — but it means any per-block or per-address poller fires far more often than the equivalent code on Ethereum. Combine that with eth_getLogs being disabled on the public mainnet nodes, and the two differences compound for a processor: the chain confirms payments faster than anywhere you operate, while the cheapest way to detect those payments at scale is the one method you cannot call. Provider selection for BNB payment processing is therefore decided by event-log access and sustained request headroom, not by headline latency.

BNB Smart Chain RPC endpoint options

Public vs private BNB Smart Chain RPC endpoints

For a payment processor, the public-versus-private decision on BNB Smart Chain is not about uptime percentages — it is about whether your deposit-detection layer can see payments arrive at all. A public node is fine for a wallet that needs to switch networks; it is structurally unable to back a system that monitors thousands of merchant addresses in real time.

Official public endpoints:

• Mainnet: https://bsc-dataseed.bnbchain.org
• Testnet: https://bsc-testnet-dataseed.bnbchain.org

⚠️ eth_getLogs is disabled on the public BNB Smart Chain mainnet data-seed endpoints, the shared rate limit is 10K requests per 5 minutes, and there is no public WebSocket. The BNB Chain docs themselves direct developers to third-party endpoints for log retrieval. A payment processor that detects deposits by polling each address individually will exhaust that 10K/5min budget within seconds at any real merchant count.

Public endpoint	Private endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development & testing	Production workloads
eth_getLogs access	Disabled on mainnet	Full support
Rate limit	10K / 5 min, shared	No aggressive throttling
WebSocket support	Not available	Available

📖 For a detailed comparison of BNB Smart Chain RPC providers, see Best BNB Smart Chain RPC providers for production use in 2026.

The math is the whole argument. Watching N merchant addresses by polling each one per block, at roughly 0.45-second blocks, generates thousands of requests per minute before you have onboarded a hundred merchants — and the method that would let you replace all of it with a single filtered query is the one the public tier disables. “Start on the free endpoint and upgrade later” is not a migration path for a payment processor; it is building a checkout that goes blind the moment it has customers.

Full node vs archive BNB Smart Chain node

For a payment processor, the line between a full node and an archive node is the line between “is this payment confirmed right now” and “reconstruct every payment this merchant received last quarter.” Live acceptance runs on a full node; merchant reporting, chargeback investigation, and settlement reconciliation reach into historical state.

Full node access	Archive node access
Detecting and confirming live inbound payments	Rebuilding a merchant’s full payment history for monthly statements
Current deposit-address and gas balances before a sweep	Point-in-time balance proofs for settlement and dispute resolution
Real-time payout and refund broadcasting	Backfilling Transfer event history beyond the recent-block window
Live “paid / not paid” status for checkout	Investigating a contested or duplicated payment after the fact

Chainstack supports archive nodes for BNB Smart Chain, so historical payment reconstruction does not require running your own indexer. This matters most when a processor has to answer a question about the past: producing a merchant’s statement, proving what a balance was at the moment a settlement ran, or backfilling event history after onboarding a merchant whose payments predate your monitoring. All of that reads state a full node has pruned, so it requires reliable archive node access. Archive calls bill at 2 request units each versus 1 for full-node calls, so size for it deliberately rather than discovering the cost during a month-end reporting run.

HTTPS vs WebSockets

A payment processor on a sub-half-second chain pays a steep tax for the wrong transport. Polling eth_getBlockByNumber or sweeping balances over HTTPS across every deposit address, every block, is a flood of redundant round-trips that scales linearly with both your merchant count and the block rate. A WebSocket subscription inverts the model: the node pushes each new block or matching Transfer event to you once, the moment it lands.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect/heartbeat logic
Best for	Payout broadcasting, gas top-ups, balance reads, reporting batch jobs	Live deposit detection, payment confirmation streams, instant checkout updates
Latency	Standard	Lower for frequent updates
Connection overhead	Per request	One-time handshake

WebSocket is not available on the public BNB Smart Chain data-seed endpoints — it is a managed-provider feature. Any real-time deposit-detection design therefore assumes a private endpoint from the outset; there is no public wss:// fallback to lean on while you wait for instant payment confirmation.

How to get a private BNB Smart Chain RPC endpoint with Chainstack

You can deploy a private BNB Smart Chain RPC node on Chainstack in a few minutes:

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

Once you have the endpoint, connecting with ethers.js follows the standard BNB Smart Chain pattern:

const { ethers } = require("ethers");

var urlInfo = {
    url: 'YOUR_CHAINSTACK_ENDPOINT'
};
// Network ID 56 = BNB Smart Chain mainnet; 97 = testnet
var provider = new ethers.providers.JsonRpcProvider(urlInfo, 56);

provider.getBlockNumber().then(console.log);

📖 For the full integration guide, see the Chainstack BNB Smart Chain tooling documentation.

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

Using Chainlist

BNB Smart Chain is listed on Chainlist under chain ID 56, which makes adding the network to MetaMask and other wallets a one-click action. Chainlist is a network registry, not an infrastructure provider — the RPC URLs it surfaces are the same throttled public data-seed endpoints, with eth_getLogs disabled and no WebSocket. Use Chainlist to register the network in a wallet for testing, then replace any public URL it hands you with a managed endpoint before a single live payment routes through it.

Chainstack pricing for BNB Smart Chain RPC

Chainstack charges on request units rather than opaque compute-unit multipliers, which lets a payments team forecast cost straight from expected checkout and settlement volume instead of reverse-engineering per-method weights. See the full Chainstack pricing page for current plan details and overage rates.

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

For a processor scaling its merchant base, the relevant options sit above the shared plans. Dedicated Nodes start at $0.50/hour plus storage and give you isolated infrastructure with no resource contention when a flash sale spikes checkout volume. Global Nodes provide geo-balanced endpoints across APAC, EU, and US so payment traffic is served from the region nearest each merchant. For teams that need flat-fee throughput with no per-request billing on a high-frequency detection workload, the Unlimited Node add-on removes the request-volume variable entirely.

How to estimate monthly cost

1. Count your steady-state requests per second across deposit detection, gas top-ups, sweeps, and payout broadcasting
2. Multiply by the seconds in a month to get your baseline monthly request volume
3. Add your eth_getLogs detection and reporting volume — heavier per call, and bursty around settlement runs
4. Map the total against the plan tiers and confirm your peak RPS fits the plan’s ceiling
5. On BNB Smart Chain, deposit detection cost scales with merchant count multiplied by the ~0.45-second block rate — every new merchant address you poll per block adds measurable RPS, so a topic-filtered eth_getLogs or WebSocket subscription is not just cleaner, it is the difference between a Growth plan and a Business plan

Production readiness checklist

• Primary + fallback RPC provider configured
• Request timeout policy set
• Retry logic with exponential backoff implemented
• Credentials stored in env/secret manager (never hardcoded)
• Monitoring for latency, error rate, and throttling
• Alerts for sustained degradation
• eth_getLogs access confirmed on your provider before launch — deposit detection at scale depends on it
• Deposit detection built on a topic-filtered log subscription or WebSocket stream, not per-address per-block polling
• Nonce management and gas (BNB) balance monitoring in place so sweeps and payouts never stall mid-batch
• Archive endpoint provisioned if merchant statements or dispute investigations reach beyond the recent-block window

Benchmark candidate endpoints with the Chainstack performance dashboard before committing latency-sensitive checkout confirmation to a provider.

Troubleshooting common BNB Smart Chain RPC issues

Symptom	Cause	How to fix
Deposit detection misses or delays payments	eth_getLogs disabled on public node; per-address polling can’t keep up	Move to a managed endpoint and detect via a topic-filtered Transfer log subscription
eth_getLogs returns -32005 limit exceeded	Block range too wide for the provider’s window	Cap each query to ~5,000 blocks or fewer and paginate the backfill
429 Too Many Requests	Exceeded the 10K/5min shared public limit	Move to a managed endpoint and add a client-side rate limiter sized to the plan RPS
Confirmation lags the chain by minutes	Sub-half-second blocks outrun a slow or shared endpoint	Stream blocks and matching events over WebSocket instead of HTTPS polling
Sweeps or payouts stall mid-batch	Nonce gaps or deposit address out of BNB gas	Add nonce tracking and a gas top-up step before broadcasting each sweep
Merchant statement query returns empty for old payments	Querying pruned history against a full (non-archive) node	Route historical and reporting queries to an archive endpoint

Conclusion

The failure mode that catches payment processors on BNB Smart Chain is not a crash — it is a confirmation that never arrives in time. The chain finalizes a customer’s stablecoin payment in about a second, but your detection layer, polling each merchant address against a public endpoint, is rate-limited into falling minutes behind. The checkout page spins, the customer abandons or pays twice, and the merchant blames your processor for a problem that lives entirely in the RPC layer. There is no error in the logs to point to, because the payment did succeed on-chain — your infrastructure just never saw it fast enough. That is the specific, revenue-leaking thing this chain does to teams that treat the public endpoint as a starting point.

The pattern that works is to build detection around event subscriptions, not address polling, before you onboard a single merchant. Put a managed endpoint with full eth_getLogs support behind your detection layer, stream new payments over WebSocket so confirmation tracks the chain’s ~1.1-second finality, and add an archive endpoint the moment your reporting reaches past recent blocks. As your merchant count grows, move payment-critical traffic onto dedicated or flat-fee infrastructure so a flash sale never throttles checkout. Do not poll per address per block and hope the rate limit holds — it will not.

Start free, then move detection and settlement traffic onto dedicated or flat-fee infrastructure as your merchant base scales.

FAQ

Why does my BNB Smart Chain payment processor miss or delay deposits on the public endpoint? Because eth_getLogs is disabled on the public mainnet data-seed endpoints, so you cannot detect payments across many addresses with a single filtered query. The fallback — polling each merchant deposit address individually every block — hits the shared 10K/5min rate limit almost immediately at any real merchant count, and detection falls behind the chain. A managed endpoint that serves log queries lets you replace thousands of polls with one topic-filtered subscription.

How do I detect inbound stablecoin payments across thousands of merchant addresses? Subscribe to the BEP-20 Transfer event over a WebSocket endpoint, filtered by the token contract and the indexed to topic, rather than polling each address. One subscription covers your whole address set and pushes each payment the moment it lands. WebSocket is provider-only on BNB Smart Chain, so this requires a managed endpoint, and you should pair it with reconnect and missed-block backfill logic so a dropped connection never loses a deposit.

How does BNB Smart Chain’s block time affect my RPC request volume? Block time has dropped from 1.5s to ~0.45s after the Maxwell and Fermi upgrades, with finality near 1.1 seconds. Any per-block or per-address poller therefore fires far more often than the same code on Ethereum, so detection cost scales with merchant count times the block rate and can self-throttle even on a paid plan. Use a topic-filtered log subscription or WebSocket stream instead of per-address polling to decouple detection cost from the block cadence.

Can I use the public BNB Smart Chain endpoint for production payment processing? No. The public endpoint disables eth_getLogs, offers no WebSocket, caps you at a shared 10K/5min rate limit, and carries no uptime guarantee — each of those is disqualifying for live payment acceptance. It is appropriate for wallet network registration and early development, not for detecting or settling real payments.

Do I need an archive node to run a BNB Smart Chain payment processor? Not for live acceptance — detection, sweeps, and payouts all run on a full node. You need archive access once your obligations reach past recent blocks: producing merchant statements, proving a point-in-time balance during a dispute, or backfilling payment history for a newly onboarded merchant. Archive calls cost 2 request units each versus 1 for full-node calls, so budget for the heavier reads.

How do I keep sweeps and payouts from stalling on BNB Smart Chain? Track the nonce per signing address and make sure each deposit address holds enough BNB for gas before you broadcast a sweep, since a deposit wallet funded only in stablecoin cannot pay its own gas. Use eth_estimateGas ahead of broadcasting, and batch with monotonic nonces so one stuck transaction does not block the queue behind it.

Additional resources

• BNB Smart Chain: BEP-1155 contract with Truffle and OpenZeppelin — Chainstack tutorial
• Chainstack BNB Smart Chain tooling documentation
• BNB Smart Chain JSON-RPC methods supported by Chainstack
• BNB Chain developer documentation
• More BNB Chain tutorials and articles on the Chainstack Blog
• Chainstack blockchain infrastructure for fintech and payments