Playground

The widget below calls the StableOps API directly from your browser with the sandbox API key you paste, via @stableops/api-sdk. It creates a sandbox payment order, then uses @stableops/wallet-sdk to open the browser wallet and send a real Base Sepolia USDC transfer. Run the four steps in order to watch one order move from created to finalized:

1. Create payment order — POST /v1/payment-orders with an Idempotency-Key. The returned payment_instructions list contains the candidate deposit addresses allocated to this order.
2. Pay on-chain with wallet — the frontend calls sendWalletPayment, and the wallet sends an ERC-20 transfer to the order address.
3. Wait for confirmed — no manual state push; the UI polls until scanner + confirmations watcher move the order to confirmed.
4. Wait for finalized — polling continues until the finality threshold is reached; only then do ledger entries and outgoing webhooks become terminal.

Paste your sandbox API key into the widget to begin — it stays in your browser. Use testnet assets only; do not send mainnet funds in the playground. Each step shows the latest order snapshot and activity log so you can compare it with real request/response shapes.

(empty)

What happens in production

Step 1 is identical to real usage — your service calls POST /v1/payment-orders via SDK or REST. Step 2 is a real on-chain deposit: the browser wallet transfers stablecoins to the order address; the scanner pulls logs bucketed by (organizationId, environment, chain, address), normalizes them into normalized_events, and advances any matching order to detected. Steps 3 and 4 are driven by the confirmations watcher, which periodically compares head - block_number against each chain's CONFIRMED_AFTER / FINALIZED_AFTER thresholds and also verifies receipt.blockHash against the originally recorded block to detect reorgs.

The playground calls the StableOps API directly from your browser using the sandbox API key you provide (@stableops/api-sdk); payment, detection, confirmation, and finality all use the real chain path. If an order does not advance, check that the API worker, scanner, testnet RPC, and token contract configuration are running.

Integration checklist

• Use the Idempotency-Key header — submitting the same merchant_order_id twice always returns the same order.
• This playground runs entirely client-side with a sandbox key for demonstration. In production, keep your API key on your backend and never expose a live key in the browser; the frontend should only use @stableops/wallet-sdk for the wallet transfer.
• Subscribe to payment.detected / payment.confirmed / payment.finalized / payment.reverted webhooks; every delivery is single-flight via an IN_PROGRESS claim, so duplicates won't double-fire your handler.
• Verify webhook signatures with @stableops/api-sdk/webhooks to defeat replay.

Continue with the Quickstart for runnable code samples.