Skip to content

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).

NetworkTokenContract addressDecimals
Arbitrum Sepolia (421614)USDC0xf9Af82ce89B3A8031fc70Ae5999Ba5386c0f62496
Arbitrum Sepolia (421614)USDT0xd8675B730215142358444f3b496CF590E7E8a5e76
Arbitrum Sepolia (421614)EURC0x64C9Cc17Ea6e7709F95E5E0B76A1D2D2d71c6c416
Base Sepolia (84532)USDC0x4e620E21B229fe0319E0E49055b85BcdcDC1Ab3f18
Base Sepolia (84532)USDT0xD699ea57770CF7286FbecEccA4c9a7006Efb0bE218

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 checkoutUrl and redirects.
  • If you use the Checkout Button, the button fetches the checkoutUrl from 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 paymentId or orderId.
  • Failed, canceled, expired, and duplicate events do not trigger incorrect fulfillment.
  1. Create a test API key under Developers in the merchant dashboard.
  2. Create a webhook endpoint and save the signing secret.
  3. Create a small test order from your server.
  4. Redirect the frontend to the Taria Pay checkout page.
  5. 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.
  6. Complete the payment, or simulate the failure path.
  7. Check the webhook delivery results in Delivery Logs.
  8. 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:

  1. Create a small test order and open the checkout page.
  2. Expand the direct transfer section and check the network, currency, amount, and deposit address shown on the page.
  3. Transfer the displayed amount from any wallet (no connection required).
  4. Stay on the page and wait for automatic confirmation, or click "I've sent it" to trigger a manual check.
  5. Confirm your webhook receives the exact same payment_intent.confirmed event 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:

bash
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 fires

On 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.
  • orderId is stable and unique in your system.
  • Both successUrl and cancelUrl open correctly.
  • If you use the Checkout Button, the frontend only receives the checkoutUrl and no API key is exposed.
  • If you use the Checkout Panel, the frontend only holds the paymentId and 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, and txHash.

Next steps