Testing and go-live preparation
Before going live, run the full flow end to end with a test key: create an order, redirect to the checkout page, complete the payment, receive the webhook, and update your order system.
Test tokens (testnet faucet)
Test-mode payments run on public testnets with platform-issued test stablecoins that have no real value. Claim them from the merchant dashboard: turn on test mode, open Developers, and click the Test tokens button — the dialog claims every token into your own wallet in one flow. Each token mints 1,000 units per address per UTC day (the contract's public drip() function, so you can also call it directly from a block explorer).
| Network | Token | Contract address | Decimals |
|---|---|---|---|
| Arbitrum Sepolia (421614) | USDC | 0xf9Af82ce89B3A8031fc70Ae5999Ba5386c0f6249 | 6 |
| Arbitrum Sepolia (421614) | USDT | 0xd8675B730215142358444f3b496CF590E7E8a5e7 | 6 |
| Arbitrum Sepolia (421614) | EURC | 0x64C9Cc17Ea6e7709F95E5E0B76A1D2D2d71c6c41 | 6 |
| Base Sepolia (84532) | USDC | 0x4e620E21B229fe0319E0E49055b85BcdcDC1Ab3f | 18 |
| Base Sepolia (84532) | USDT | 0xD699ea57770CF7286FbecEccA4c9a7006Efb0bE2 | 18 |
Notes:
- Use these addresses to import the tokens into your wallet so balances are visible.
- Arbitrum Sepolia mirrors mainnet Base/Arbitrum (6 decimals; USDC/EURC pay gasless via EIP-3009). Base Sepolia mirrors mainnet BSC (18 decimals; approve + signature flow).
- Claiming and paying still need a little testnet gas — get Sepolia ETH for each network from any public faucet.
What to verify
You need to confirm that:
- Your server can successfully create a payment intent.
- With Hosted Checkout, the frontend receives the
checkoutUrland redirects. - If you use the Checkout Button, the button fetches the
checkoutUrlfrom your server and opens the hosted checkout. - If you use the Checkout Panel, the frontend receives the
paymentId, and the panel loads and can switch chains and currencies. - After the buyer completes payment, your webhook receives the event.
- Your order system updates idempotently by
paymentIdororderId. - Failed, canceled, expired, and duplicate events do not trigger incorrect fulfillment.
Recommended test sequence
- Create a test API key under Developers in the merchant dashboard.
- Create a webhook endpoint and save the signing secret.
- Create a small test order from your server.
- Redirect the frontend to the Taria Pay checkout page.
- If you use the Checkout Button, confirm the button opens the hosted checkout; if you use the Checkout Panel, confirm the panel can connect a wallet and complete a payment.
- Complete the payment, or simulate the failure path.
- Check the webhook delivery results in Delivery Logs.
- Confirm the order status in your system.
Testing direct transfer payments
On supported networks, the checkout page offers direct transfers (showing an order-specific deposit address and QR code) in addition to wallet payments. We recommend verifying this at least once:
- Create a small test order and open the checkout page.
- Expand the direct transfer section and check the network, currency, amount, and deposit address shown on the page.
- Transfer the displayed amount from any wallet (no connection required).
- Stay on the page and wait for automatic confirmation, or click "I've sent it" to trigger a manual check.
- Confirm your webhook receives the exact same
payment_intent.confirmedevent as a wallet payment, and that your order system records it correctly.
Note: direct transfers are enabled per network — go by what the checkout page actually shows during testing. Never send funds to a deposit address from a past order; unless you enabled a fixed deposit address for that verified customer, every order gets a unique address (and even a fixed address only counts funds sent while an order is open).
Local stack (Taria Pay repo)
Paid intents do not confirm by themselves locally. Run these together:
npm run dev:backend # API :3003
npm run dev:checkout # checkout :3004
./scripts/dev-backfill-loop.sh # required — otherwise status stays processing and no webhook firesOn the merchant app set TARIAPAY_API_BASE=http://127.0.0.1:3003 (origin only).
Local webhooks
If your server is still in local development, Taria Pay needs to be able to reach your webhook endpoint. The common approach is a public tunneling tool that temporarily exposes your local address as an HTTPS URL. Register that URL under Dashboard → Developers → Webhooks and put the signing secret in TARIAPAY_WEBHOOK_SECRET.
Do not fulfill from successUrl as a local shortcut. If you cannot expose a tunnel yet, poll GET /v1/payment-intents/:paymentId on your server.
Before going live, switch the webhook URL to your production domain.
Test checklist
- No API key is exposed in frontend code.
orderIdis stable and unique in your system.- Both
successUrlandcancelUrlopen correctly. - If you use the Checkout Button, the frontend only receives the
checkoutUrland no API key is exposed. - If you use the Checkout Panel, the frontend only holds the
paymentIdand no API key is exposed. - The webhook handler verifies the signature first.
- Webhook processing is idempotent.
- Shipping, access grants, or revenue recording only happen after
confirmed. - Support and operations staff know how to investigate issues using
paymentId,orderId, andtxHash.
Next steps
- Prepare for launch: Go-live checklist
- Payment button or Checkout Panel: Checkout Button and Checkout Panel
- Troubleshooting: Troubleshoot payment issues