Polygon 支付网关 API 需要 RPC 基础设施提供什么？

Polygon 支付网关 API 实际做什么

Polygon 支付网关 API 并不是一个可以安装的单一产品。它是你的团队构建或集成的后端服务，用于在 Polygon 上接受 POL 和 ERC-20 支付。它监听链上事件，将传入的转账与发票或订单匹配，等待安全的确认深度，然后触发 webhook 或更新内部账本。

RPC 层是大多数团队低估的部分。你的网关需要：

• 扫描新区块，查找发送到你的存款地址的转账
• 读取交易收据以确认成功或失败
• 跟踪确认数并处理链重组
• 估算 gas 并广播退款或归集交易
• 可选地通过 WebSocket 实时订阅日志

如果 RPC 端点停滞、返回过期数据或对区块扫描器进行速率限制，支付就会延迟甚至完全不到账。这就是此查询背后的核心基础设施问题。

决策指南：支付流程选择托管 RPC 还是专用节点？

在选择端点之前，先确定你运行的工作负载类型。

如果你的支付量稳定且可以容忍偶尔重试，像 OnFinality 的 Polygon 端点 这样的托管 RPC API 是合理的起点。如果你运行持续扫描器、需要归档深度或希望隔离容量，专用节点 可以消除邻居干扰效应。

Polygon 主网链设置

配置网关的链客户端或钱包库时使用这些值。

对于测试网开发，Polygon Amoy 使用链 ID 80002，原生货币为 POL，浏览器为 https://amoy.polygonscan.com。在网关中保持主网和测试网配置分离，这样配置错误的环境就不会广播真实支付。

支付确认逻辑如何映射到 RPC 调用

典型的支付流程涉及少量 JSON-RPC 方法。了解哪些方法重要有助于你规划基础设施规模。

1. 检测转账。 轮询 eth_getLogs 查找发送到你的存款地址的 ERC-20 Transfer 事件，或通过 WebSocket 使用 eth_subscribe 订阅。
2. 确认交易。 调用 eth_getTransactionReceipt 检查 status 并读取区块号。
3. 跟踪深度。 将收据区块与 eth_blockNumber 比较，直到达到确认阈值。
4. 处理重组。 如果之前确认的区块不再是规范链，重新检查收据并重新评估支付。
5. 归集或退款。 使用 eth_estimateGas、eth_gasPrice 或 eth_maxPriorityFeePerGas 以及 eth_sendRawTransaction。

以下是使用 JSON-RPC 调用的最小确认检查：

curl -s https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getTransactionReceipt",
    "params": ["0xYOUR_TX_HASH"]
  }'

成功的收据返回 status: "0x1"。回滚的交易返回 status: "0x0"，不应视为支付。

对于持续监控，WebSocket 订阅通常比轮询更高效：

import Web3 from "web3";

const web3 = new Web3("wss://polygon.api.onfinality.io/public/ws");

const subscription = await web3.eth.subscribe("logs", {
  address: "0xYourTokenContract",
  topics: [web3.utils.sha3("Transfer(address,address,uint256)")],
});

subscription.on("data", (log) => {
  // Match log topics against your deposit address index
  console.log("Incoming transfer", log.transactionHash);
});

在设计订阅方案之前，确认你的提供商支持 WebSocket 传输。OnFinality 的 Polygon 端点同时支持 HTTP 和 WebSocket。

支付网关的故障点：故障模式与修复

大多数是应用程序错误，但有两个是基础设施决策：日志查询限制和归档深度。如果你的网关需要核对数月的支付历史，标准全节点可能无法保留你需要的状态。

支付工作负载的提供商评估矩阵

在为支付网关比较 RPC 提供商时，根据实际影响结算的需求进行评分。

如果你希望随着网关扩展，为 Polygon RPC 以及更广泛的支持网络使用单一提供商，请将 OnFinality 放在候选名单首位。将其他提供商与相同的列进行比较，而不是与营销页面比较。

设计故障转移和幂等性

支付系统不能假设单个端点始终保持健康。两种模式可以降低风险：

端点故障转移。 在客户端配置主 RPC URL 和备用 RPC URL。如果主端点超时或反复返回错误，切换并记录事件。有意测试故障转移路径，而不仅仅是在生产事件中。

幂等处理。 为每个链上事件存储唯一键，例如 txHash 加 logIndex。在记入支付之前，检查该键是否已处理。这可以防止重复 webhook 和重组重放。

一个简单的监控探针可以在端点性能下降影响支付之前捕获问题：

#!/bin/bash
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" \
  https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')

if [ "$RESPONSE" != "200" ]; then
  echo "RPC endpoint unhealthy: $RESPONSE"
fi

按计划运行此脚本，并在反复失败时发出警报。结合检查报告的区块号是否在推进。

成本和容量规划

支付网关产生可预测的 RPC 负载：每个区块范围一次日志查询，每笔交易一次收据调用，以及定期的区块号检查。根据支付量估算每日请求数，然后与提供商计划进行比较。

如果你的扫描器每隔几秒轮询一个宽区块范围，请求数会迅速攀升。WebSocket 订阅可以减少轮询开销，但需要处理重连。对于稳定的高交易量，专用节点通常比按请求定价提供更可预测的容量。查看 RPC 定价 以根据预期流量对两种选项进行建模。

关键要点

• Polygon 支付网关 API 依赖可靠的 RPC 进行日志扫描、收据确认、重组处理和交易广播。
• Polygon 主网使用链 ID 137，原生货币为 POL，并支持 HTTP 和 WebSocket 传输。
• 中等交易量选择托管 RPC；持续扫描器、归档需求或隔离容量选择专用节点。
• 从一开始就设计故障转移和幂等性；重复支付和遗漏重组是最常见的生产故障。
• 在承诺使用提供商之前，验证归档深度和日志查询限制。

常见问题

Polygon 支付网关需要特殊 API 吗？ 不需要。它使用标准 JSON-RPC 方法，如 eth_getLogs、eth_getTransactionReceipt 和 eth_sendRawTransaction。网关逻辑建立在这些调用之上。

在 Polygon 上应该等待多少个确认？ 这取决于你的风险承受能力和支付金额。许多团队对低价值支付使用少量区块，对较大支付使用更多区块。检查当前网络行为并进行调整。

我可以使用 WebSocket 进行支付监控吗？ 可以，如果你的提供商支持。OnFinality 的 Polygon 端点支持 WebSocket，这对于实时日志订阅很有用。

如果我的 RPC 提供商在支付过程中宕机怎么办？ 配置了端点故障转移后，你的网关会切换到备用 URL。如果没有配置，确认会暂停，直到端点恢复。幂等处理可防止恢复后重复入账。

支付对账需要归档节点吗？ 如果你需要查询超出标准保留窗口的历史状态或收据，则需要。否则全节点通常足够。

下一步

首先将你的支付量映射到 RPC 模式，然后针对 Polygon 端点 进行测试。如果你的扫描器持续运行或需要归档深度，请评估 专用节点。如需更广泛的比较框架，请参阅 如何选择 RPC 提供商。