How to get a Polygon RPC endpoint for fintech (2026 guide)

TL;DR

When a stablecoin transfer lands on Polygon, your backend has one question to answer: has this payment settled? For years the answer was unreliable — the old checkpoint-based finality meant waiting up to 30 minutes for an Ethereum anchor before a transaction was provably irreversible. The Heimdall v2 upgrade in July 2025 changed that, delivering milestone-based finality in 2–5 seconds. The catch is that the signal only reaches your application if your RPC provider correctly exposes the finalized block tag — and not all of them do. This guide covers how to get a Polygon RPC endpoint for fintech and stablecoin payment workloads: right finality semantics, archive access for compliance audits, and the multi-region topology a production payment product actually requires.

What is a Polygon RPC endpoint

A Polygon RPC endpoint is an HTTPS or WebSocket URL that routes calls to a Bor execution node — the EVM-compatible layer of Polygon’s two-tier architecture. Bor handles block production and transaction execution; it speaks standard Ethereum JSON-RPC, extended with a bor_ namespace that exposes validator and block-proposal methods unique to Polygon. When your payment application calls eth_sendRawTransaction, queries an ERC-20 balance via eth_call, or subscribes to logs over WebSocket, those requests land on a Bor node. Heimdall checkpoints to Ethereum mainnet happen in the background — your application never calls Heimdall directly.

Stablecoin payment applications depend on RPC endpoints for every step of the transaction lifecycle:

• ERC-20 Transfer event detection via eth_getLogs (deposit monitoring)
• Real-time block subscriptions via eth_subscribe → newHeads (confirmation triggers)
• Token balance reads via eth_call → balanceOf (pre-payment checks)
• Transaction broadcasting via eth_sendRawTransaction (outbound payouts)
• Finality confirmation via eth_getBlockByNumber with the finalized tag (settlement confirmation)
• Historical state queries for payment reconciliation and regulatory audits (archive access required)
• Smart contract reads for escrow and payment protocol logic
• Validator and block proposer queries via the bor_ namespace

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

When your RPC provider is slow, throttles unexpectedly, or drops WebSocket connections during a peak settlement window, your application either blocks on a pending confirmation or misses a deposit event entirely — both failures that produce customer support tickets and potential double-charge disputes that are difficult to resolve on-chain.

How Polygon RPC differs from Ethereum RPC

Polygon PoS is EVM-compatible but runs its own two-layer architecture, which creates several meaningful differences at the RPC level that matter specifically for payment and fintech applications.

Feature	Ethereum	Polygon PoS
Block time	~12 seconds	~2 seconds
Throughput	~15–30 TPS	~110 TPS
Gas token	ETH	POL
Consensus	Ethereum PoS validators	Bor + Heimdall (105 validators)
Deterministic finality	~12 minutes (2 epochs)	2–5 seconds (milestone-based, post-Heimdall v2)
L1 checkpointing	Not applicable	Every ~256 Bor blocks (~30 min) to Ethereum mainnet
Proprietary RPC namespace	None	bor_ namespace (validators, proposers, snapshots)
Max reorg depth	Up to ~6 blocks	2 blocks (post-Giugliano hardfork, April 2026)

The finality row is the one that changes everything for fintech. Ethereum’s 12-minute economic finality is acceptable in DeFi where users watch transactions; it is a dealbreaker in payments where “Payment confirmed” must trigger a downstream action within seconds. Polygon’s milestone-based finality makes that confirmation possible — but only if your provider correctly surfaces the finalized block tag, not a stale cache of latest.

Why Polygon became the settlement layer for stablecoins

Polygon’s transition from a DeFi scaling chain to a stablecoin payment rail was completed between 2023 and 2025. The $0.002 average transaction cost and ~110 TPS throughput made it competitive with traditional payment networks on price; Heimdall v2 made it competitive on settlement speed. What followed was a wave of institutional adoption that reshaped the network’s entire traffic profile.

Circle issues native USDC on Polygon. PayPal expanded PYUSD issuance to the network. Stripe processes stablecoin payouts on Polygon. Meta is paying creators in USDC on Polygon via Stripe across Southeast Asia and Latin America. Revolut crossed $1.2B in on-chain transaction volume on Polygon. Cumulative stablecoin transfer volume on the network crossed $2.4 trillion, with payment processor monthly volume growing 409% year-on-year by early 2026.

None of these integrations were possible when finality meant a 30-minute Ethereum checkpoint. The infrastructure that enabled them — and the infrastructure your payment product needs — runs through a Polygon RPC endpoint. That endpoint is where the chain’s payment capability either holds or breaks under load.

Building stablecoin payment products at scale is precisely what Chainstack’s stablecoin infrastructure is purpose-built to support.

Finality guarantees and what they mean for payment UX

Post-Heimdall v2, Polygon has three confirmation states. Every payment application must understand which one to use as a settlement trigger.

Soft confirmation (seconds): A transaction is included in a Bor block. It is probabilistically final but theoretically reversible in a deep reorg. The Giugliano hardfork (April 2026) capped reorg depth at 2 blocks, making this state far safer than it was historically. Accessible via eth_getBlockByNumber("latest").

Milestone finality (2–5 seconds): Heimdall v2 introduces milestone blocks — deterministically finalized checkpoints within the Bor chain itself, without waiting for Ethereum. Once a milestone is reached, the blocks it covers cannot be reversed under any circumstances. This is the threshold at which a payment application should update its “Payment confirmed” state. Accessible via eth_getBlockByNumber("finalized").

Checkpoint finality (~30 minutes): Periodic Merkle root submissions to Ethereum mainnet. Relevant for bridge exits and cross-chain settlement flows but not for pure Polygon-to-Polygon payment paths.

The practical consequence: subscribe to newHeads over WebSocket, and on each new head, call eth_getBlockByNumber("finalized") to determine which block range is now deterministically settled. Transactions in blocks at or below the finalized cursor can trigger downstream settlement actions — releasing goods, crediting accounts, initiating fiat off-ramp flows.

If your provider does not correctly implement the finalized tag — returning stale data or silently defaulting to latest — your application is making settlement decisions on probabilistic confirmations. That is how false “Payment confirmed” signals happen, and how disputes that cannot be traced to a clear on-chain error end up in your support queue.

Compliance requirements for on-chain payment infrastructure

Fintech companies operating on Polygon face regulatory requirements that translate directly into RPC infrastructure decisions.

Archive access is non-negotiable for regulated fintechs. MiCA (EU) and equivalent frameworks require payment service providers to maintain complete transaction history. On-chain records live in archive nodes — only archive nodes can answer eth_getBalance(address, blockNumber) for a block more than 128 blocks in the past. For a compliance audit, this means reconstructing wallet states at any historical point: at the time of a disputed transaction, at a reporting period boundary, or during a regulatory examination. A full node discards this history after approximately 4 minutes of Polygon blocks.

Data isolation for regulated workloads. Shared public RPC endpoints process requests from every application connected to them simultaneously. For a VASP (Virtual Asset Service Provider) subject to AML and KYC obligations, routing production payment traffic through a shared endpoint mixes your transaction queries with those of anonymous applications. A Dedicated Node provides single-tenant isolation: your traffic, your logs, your audit trail — nothing shared.

Real-time monitoring requirements. MiCA’s DORA pillar and similar ICT risk frameworks require ongoing monitoring of third-party technology providers. Your RPC provider is an ICT dependency. You need latency, error rate, and availability metrics that are exportable to your compliance reporting system. Public endpoints provide none of this. A provider with a SOC 2 Type II certification and exportable observability data closes this gap.

KYC and AML integration posture. The RPC layer itself is not a compliance tool, but it sits directly beneath one. Whether you use Chainalysis, TRM Labs, or Elliptic for on-chain screening, those systems consume data that starts with RPC calls. Endpoint reliability and archive depth determine how complete the data your screening layer receives actually is.

MEV protection for high-value transactions. Polygon’s Private Mempool (launched 2025) routes transactions directly to validators, bypassing the public mempool and eliminating front-running and sandwich attack exposure. For a fintech processing high-value stablecoin transfers, this is a one-line integration: swap the standard RPC endpoint for the private mempool endpoint. Managed providers that support Polygon’s Private Mempool routing give you this option without additional infrastructure overhead.

Chainstack’s blockchain infrastructure for fintech is SOC 2 Type II certified and purpose-built for these requirements — Dedicated Nodes, exportable metrics, and compliant data handling across 70+ chains.

Multi-region payment node topology

A payment product serving users across geographies needs RPC infrastructure architected for regional redundancy from day one, not retrofitted after the first outage.

Tier 1 — Primary dedicated node (regional). Deploy a Dedicated Node in the region where your primary payment traffic originates — US East, EU West, or APAC. All production payment calls route here. Traffic is isolated and latency is minimized.

Tier 2 — Regional fallback (same continent, different provider). A second managed endpoint in the same geographic zone on separate infrastructure. Activates when the primary node returns 5xx errors for more than 3 consecutive retries, or when p95 latency exceeds 500ms for 30 seconds. This handles provider-level incidents without cross-continent latency penalties.

Tier 3 — Cross-region tertiary. A managed endpoint in a different continent as a last-resort fallback. Latency will be higher (100–200ms additional round trip depending on geography), but it keeps payment flows alive during regional infrastructure events.

For data residency requirements under GDPR (EU), PDPA (Singapore), or DPDP (India), tier-1 Dedicated Nodes should be placed in the appropriate jurisdiction with contractual data processing agreements. Traffic must not cross regional boundaries except during tier-3 failover, which should be explicitly documented in your ICT risk register.

For WebSocket subscriptions handling Transfer event monitoring, maintain persistent connections to both tier-1 and tier-2 endpoints simultaneously. On reconnect, call eth_getLogs from the last confirmed block to the current head before resuming the subscription to backfill any events missed during the connection gap.

Polygon RPC endpoint options

Public vs private Polygon RPC endpoints

Polygon’s public endpoint is fine for local development and Amoy testnet integrations. At production stablecoin volumes — where a single settlement batch from a payments partner or a wave of end-of-day reconciliation queries can push hundreds of requests per second — shared infrastructure becomes the weakest link in your payment stack.

Official public endpoints:

• Mainnet: https://polygon-rpc.com
• Amoy testnet: https://rpc-amoy.polygon.technology/

⚠️ The public mainnet endpoint throttles at approximately 40 requests per second with no SLA, no WebSocket guarantee, and no access to debug/trace or bor_ namespace methods. A payment application monitoring 500 wallet addresses for incoming USDC deposits — polling each with balanceOf at 2-second block intervals — exhausts 40 req/s before accounting for transaction submission or reconciliation load. The Polygon documentation recommends using professional RPC providers for production deployments.

Feature	Public endpoint	Private managed endpoint
Access	Free and open	Restricted access
Resources	Shared infrastructure	Dedicated resources
Best use case	Development and testing	Production payment workloads
Rate limit	~40 req/s	No aggressive throttling
WebSocket stability	Unreliable, no reconnect guarantee	Stable, authenticated WSS
Archive access	Not available	Available
bor_ namespace	Not guaranteed	Fully supported
Audit trail and metrics	None	Exportable, compliance-ready
SLA	None	99.99% uptime commitment

The 40 req/s ceiling is the number that collapses payment products. Building to the public endpoint in development and then discovering this limit under production load — during a settlement window — is the most common avoidable infrastructure failure on Polygon.

📖 For a side-by-side comparison of managed providers, see the best Polygon RPC providers in 2026 comparison.

Full node vs archive Polygon node

For payment applications, the archive versus full node decision maps directly to the depth of your compliance and reconciliation requirements.

Full node access	Archive node access
Real-time USDC and USDT Transfer event detection	Historical wallet balance at any past block
Current token balances for pre-payment checks	Transaction state at regulatory reporting dates
Transaction broadcasting and mempool submission	Backfill reconciliation for disputed payments
Live smart contract state reads	Complete audit trail export for MiCA compliance
Milestone finality confirmation	Historical gas cost analysis for treasury reporting
Validator and block proposer queries via bor_	Replay of payment contract state at any historical point

Archive calls are billed at 2 RU per request on Chainstack (versus 1 RU for full node calls), which makes cost routing straightforward: budget archive access for compliance and analytics workloads, and route real-time payment flows through a full node endpoint.

Chainstack supports archive nodes for Polygon, giving you queryable history from genesis — essential for any fintech operating under a regulatory framework that demands historical account state reconstruction.

HTTPS vs WebSockets

Payment deposit detection is the canonical WebSocket use case on Polygon. Open a persistent connection, subscribe to logs filtered on your USDC contract address and the ERC-20 Transfer event topic, and receive notifications within seconds of a transfer landing in a finalized block. Polling the same data over HTTPS requires an eth_getLogs call every block — at Polygon’s 2-second block time, that is 1,800 HTTP requests per hour per filter, versus one persistent connection that self-updates.

Feature	HTTPS	WebSocket
Model	Request/response	Persistent connection
Complexity	Simple operationally	Requires reconnect and heartbeat logic
Best for	Balance checks, transaction submission, finality confirmation, archive queries	Real-time deposit detection, new block monitoring, multi-wallet event subscriptions
Latency	Standard round-trip	Lower for frequent updates
Connection overhead	Per request	One-time handshake

For production payment infrastructure, you need both: HTTPS for deterministic queries (balance checks, finality confirmation, archive lookups) and WebSocket for the event stream (Transfer events, new block heads). Chainstack endpoints provide both protocols on the same node.

How to get a private Polygon RPC endpoint with Chainstack

Start by deploying a Polygon RPC node on Chainstack — the process takes under two minutes:

1. Log in to the Chainstack console (or create a free account)
2. Create a new project
3. Select Polygon PoS as your blockchain protocol
4. Choose network: Mainnet or Amoy 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

Here is a connectivity check using ethers.js:

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

// Replace with your Chainstack HTTPS or WSS endpoint
const urlInfo = { url: "YOUR_CHAINSTACK_ENDPOINT" };

// Polygon Mainnet = 137, Amoy testnet = 80002
const provider = new ethers.providers.JsonRpcProvider(urlInfo, 137);

provider.getBlockNumber().then((block) => {
  console.log("Connected to Polygon. Latest block:", block);
});

📖 For the full integration guide including web3.js, Hardhat, and Foundry examples, see the Chainstack Polygon tooling documentation.

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

Using Chainlist

Polygon PoS Mainnet is listed on Chainlist with Chain ID 137. Chainlist is useful for adding the Polygon network to MetaMask or other browser wallets during development. It is not an infrastructure provider — it aggregates available public endpoints from the community with no SLA or rate limit guarantees. Replace any Chainlist-sourced RPC URL with a managed endpoint before shipping to production.

Chainstack pricing for Polygon RPC

Chainstack bills per request unit with no method multipliers: one RU per call for full node requests, two RU per call for archive node requests. There are no hard quota cutoffs — overage continues at the per-plan rate. See the full Chainstack pricing page for plan details and current overage rates.

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

Advanced options:

• Archive Node add-on: billed at 2 RU per request, available on Growth and above — required for compliance and historical reconciliation queries
• Unlimited Node add-on: flat monthly fee, unlimited requests — suitable for high-volume payment processors
• Dedicated Nodes: single-tenant node metered by compute time and storage — the right choice for regulated fintechs that require traffic isolation

How to estimate monthly cost

1. Identify your primary RPC call patterns: deposit detection, balance checks, payout submission, finality confirmation
2. Count calls per pattern per day: monitoring 1,000 wallet addresses at 2-second block resolution generates approximately 43,200 eth_getLogs calls per day
3. Separate full node and archive calls: compliance queries against historical blocks cost 2 RU each — count them separately
4. Add WebSocket subscription overhead: each eth_subscribe and eth_unsubscribe counts as 1 RU
5. For stablecoin payment workloads, settlement activity clusters around fiat off-ramp windows and end-of-business reconciliation batches — model for 2–3x your steady-state baseline during these windows, because throttling during settlement is the worst possible moment to hit a plan limit

Production readiness checklist

• Primary and fallback RPC endpoints configured for both HTTPS and WSS
• Request timeout policy set (recommended: 5s for standard calls, 30s for archive queries)
• Retry logic with exponential backoff implemented
• Credentials stored in environment variables or a secret manager, never hardcoded
• Monitoring for latency, error rate, and throttling in place
• Alerts for sustained error rate above 2% over 5 minutes
• finalized block tag used as the settlement confirmation threshold — never latest
• WebSocket subscription reconnect logic implemented with last-known-block backfill to avoid missed Transfer events
• Archive node access confirmed and tested for compliance queries before go-live
• Multi-region topology documented in your ICT risk register per DORA and MiCA requirements
• Use the Chainstack performance dashboard to benchmark endpoint latency before selecting a provider

Troubleshooting common Polygon RPC issues

Issue	Cause	How to Fix
429 Too Many Requests	Shared endpoint throttle exhausted	Move to a managed endpoint; the 40 req/s public limit is consumed by a single monitoring sweep across dozens of wallets
WebSocket disconnects during settlement window	Connection timeout or provider load spike	Implement reconnect-on-error; on reconnect, call eth_getLogs from the last processed block to current head before resuming subscription
finalized tag returns same value as latest	Provider not correctly implementing Heimdall v2 milestone finality	Switch to a provider with correct finalized support; verify by comparing eth_getBlockByNumber("finalized") versus eth_getBlockByNumber("latest") — they should differ by 1–3 blocks
eth_getLogs returns empty on historical blocks	Full node discards state older than ~128 blocks	Route reconciliation and audit queries to an archive node endpoint
bor_ namespace methods return method not found	Provider does not enable the Bor API namespace	Use a managed provider with full namespace support; bor_getCurrentValidators and related methods are not available on most public endpoints
Deposit events missed after reconnect	Gap in WebSocket coverage during reconnect	Backfill from last confirmed block using eth_getLogs with a block range before resuming the live subscription
Transaction stuck in pending during congestion	Nonce gap or underpriced gas	Use eth_getTransactionCount(address, "pending") to verify nonce state; replace-by-fee with a 10% gas bump to reprice the transaction

Conclusion

The most common payment failure mode on Polygon is not a dropped transaction or a chain outage — it is a stale finality signal delivered without error. An application calls eth_getBlockByNumber("finalized"), receives a block number cached from seconds ago by a provider not correctly tracking Heimdall v2 milestones, and marks a payment settled before the milestone has actually propagated. There is no 5xx, no timeout, no traceable on-chain anomaly — just a wrong answer returned with full confidence. By the time the discrepancy surfaces in reconciliation, the downstream action has already been triggered.

The three infrastructure decisions that separate a production fintech product from a prototype are the same ones most teams get wrong in the same order: choosing a provider that handles finalized correctly, budgeting for archive access before the first compliance audit demands it, and building multi-region redundancy before the first outage forces it. None of these are expensive to get right at launch. All three are expensive to retrofit under pressure.

FAQ

What is the difference between latest, safe, and finalized block tags on Polygon, and which should a payment app use?

latest returns the most recently produced Bor block — probabilistically final but technically reversible (maximum 2-block reorg since the Giugliano hardfork, April 2026). safe returns blocks that Heimdall has internally validated as unlikely to revert. finalized returns blocks covered by a Heimdall v2 milestone — deterministically irreversible, updated every 2–5 seconds. Payment applications should use finalized as the settlement confirmation threshold. Using latest risks triggering settlement actions on blocks that could, in rare cases, be reorganized out.

Is polygon-rpc.com reliable enough for a stablecoin payment product?

No. The public endpoint throttles at approximately 40 requests per second with no SLA. A payment application monitoring even a modest number of wallet addresses for incoming transfers generates far more than 40 req/s during normal operation, before accounting for balance checks, outbound transaction submission, and reconciliation load. The public endpoint is appropriate for local development and Amoy testnet testing. Production payment infrastructure requires a managed endpoint with dedicated capacity and observable performance metrics.

How do I detect incoming USDC deposits on Polygon in real time?

Subscribe to the logs event type over WebSocket with a filter targeting the USDC contract address on Polygon and the ERC-20 Transfer(address,address,uint256) topic hash. Your handler fires within seconds of a transfer landing. Complement this with an HTTPS fallback: on WebSocket reconnect, call eth_getLogs from your last processed block number to the current head before resuming the live subscription to backfill any events missed during the gap.

Does Chainstack support Polygon archive nodes?

Yes. Chainstack supports Polygon archive nodes with queryable history from genesis. Archive calls are billed at 2 RU per request versus 1 RU for full node calls. Archive access is available on Growth plan and above. This is essential for compliance audits, historical payment reconciliation, and any regulatory reporting that requires reconstructing wallet balances at specific past blocks.

What is the bor_ namespace and when does a payment application need it?

The bor_ namespace is a set of Polygon-specific RPC methods not found in standard Ethereum JSON-RPC: bor_getCurrentValidators, bor_getCurrentProposer, bor_getSnapshot, and others. Most payment applications do not need these methods for core flows — they are used for validator monitoring, block attribution, and infrastructure tooling. If you are building compliance tooling that tracks block proposer attribution or validator behavior for regulatory purposes, you will need a managed provider that enables the bor_ namespace, as it is not guaranteed on public endpoints.

How should I route between full node and archive endpoints in production?

Maintain two provider instances in your application — one initialized with a full node endpoint URL for real-time payment operations, one with an archive endpoint URL for historical queries. Route by block parameter: calls that reference latest, safe, or finalized go to the full node; calls that reference a specific block number more than a few hundred blocks in the past go to the archive. This routing pattern keeps archive costs predictable and ensures real-time payment flows are never queued behind a slow historical lookup.

Additional resources

• Chainstack Polygon tooling documentation — ethers.js, web3.js, Hardhat, and Foundry integration examples with Chainstack endpoints
• More Polygon tutorials and articles on the Chainstack Blog
• Best Polygon RPC providers in 2026 — side-by-side comparison of managed providers
• Polygon developer portal — official chain documentation, network parameters, and developer tooling