Playground
在浏览器里走一遍“建单 → 钱包支付 → 确认 → 终局”的真实测试网流程。
下方组件会在浏览器里直接用你粘贴的 sandbox API key 调用 StableOps API(@stableops/api-sdk):
先创建 sandbox 支付单,再使用 @stableops/wallet-sdk 唤起浏览器钱包,
在 Base Sepolia 测试网上发送一笔真实 USDC 转账。
线性走完 4 步即可观察订单从 created 推进到 finalized:
- 创建支付单 — 走
POST /v1/payment-orders,带Idempotency-Key。返回里的payment_instructions是分配给本订单的候选入金地址列表。 - 钱包链上支付 — 前端调用
sendWalletPayment,由钱包发送 ERC-20transfer到订单地址。 - 等待 confirmed — 不再手动推进;轮询订单,等待 scanner + confirmations watcher 自动把订单推进到
confirmed。 - 等待 finalized — 继续轮询,等待达到终局阈值;此时 ledger 与 webhook 才会标记终态。
在组件里粘贴你的 sandbox API key 即可开始 —— key 只保存在你的浏览器。请使用测试网资产,不要在 playground 中发送主网资金。每一步都会把最新订单快照和活动日志展开在下方,方便对照真实请求/响应结构。
- idle1. 创建支付单
- idle2. 用钱包发起链上支付
- idle3. 等待 detected
- idle4. 等待 confirmed
- idle5. 等待 finalized
(empty)
本 playground 直接在浏览器里用你提供的 API Key 调 StableOps API(@stableops/api-sdk);第 2 步调用 @stableops/wallet-sdk 让浏览器钱包发送真实测试网交易;也可以不走钱包,从任意钱包/交易所向显示的地址转账后点击「我已手动转账」。订单进入 detected / confirmed / finalized 依赖 scanner 与 confirmations watcher。在 sandbox(测试网)下,若你的 org 还没有收款地址,会自动为本订单创建一个随机地址。请仅使用 sandbox key —— 切勿在浏览器中粘贴生产 key。
实际生产里发生了什么
第 1 步与真实使用一致:你的服务通过 SDK 或 REST 调用 POST /v1/payment-orders。
第 2 步就是 真链上的入金事件:浏览器钱包把稳定币转到订单地址;scanner 按 (organizationId, environment, chain, address) 分桶拉日志、归一化后落 normalized_events,并把匹配上的订单推进到 detected。
第 3、4 步由 confirmations watcher 周期性比较 head - block_number 与每条链的 CONFIRMED_AFTER / FINALIZED_AFTER 阈值后自动推进,并对同一笔事务的 receipt.blockHash 与初次记录做 reorg 校验。
Playground 现在直接在浏览器里用你提供的 sandbox API key 调 API(@stableops/api-sdk);链上支付、检测、确认和终局都走真实链路。若订单长时间未推进,请确认 API worker、链 scanner、测试网 RPC 与对应 token 合约配置已启动。
接入清单
- 用
Idempotency-Key头去重 — 同一merchant_order_id提交两次永远拿到同一笔订单。 - 本 playground 为演示用途,整段跑在浏览器里且只用 sandbox key。生产环境请把 API key 放在你的后端、切勿在浏览器暴露生产 key;前端只用
@stableops/wallet-sdk发起钱包转账。 - 订阅
payment.detected / payment.confirmed / payment.finalized / payment.revertedwebhook; 每条 delivery 在 worker 端用IN_PROGRESS抢锁,重复投递不会重复触发你的处理逻辑。 - 接收 webhook 时用
@stableops/api-sdk/webhooks验证签名头,避免重放。
继续阅读 快速开始 拿到完整代码示例。