Docs

Testing end-to-end

How to use the built-in /test-payment page to exercise the full invoice + webhook lifecycle without writing any code.

The dashboard ships with an end-to-end test harness at /test-payment. It is a plain form that calls the same invoice-create API your backend will call, then hands you a scannable QR so any wallet on any network can pay the invoice.

What it does#

  1. Calls POST /api/invoices with your form inputs.
  2. Redirects to the invoice detail page with:
    • A QR code encoding the payment URI (BIP-21 for BTC, EIP-681 for ETH + tokens, a bare address for TRX tokens — see Payment URIs).
    • A countdown until TTL expiry.
    • A live status section that polls the invoice until it reaches a terminal state.

Why use it#

  • Confirm your webhook endpoint works without writing API-client code first.
  • Reproduce a merchant's bug on a clean invoice.
  • Exercise every terminal state (confirmed, expired, underpaid, overpaid) by sending minimal real amounts that differ from the invoice's crypto_amount.
  1. Expose your webhook endpoint via a tunnel.
  2. Create a dedicated test merchant in the dashboard with the tunnel URL as its webhook.
  3. Use /test-payment to create small-amount invoices. The platform only supports mainnet — use minimal real amounts while you're verifying the flow.
  4. Watch the Webhook events tab on the merchant detail page — every delivery attempt is logged with the HTTP response code your server returned.
  5. Use the Retry button on any failed event to re-trigger delivery without creating a new invoice.

What it does not do#

  • /test-payment does not simulate buyer behaviour. You still need to send a real on-chain transaction on the chosen network to move the invoice to pending → confirming → confirmed.
  • It does not bypass signature verification on your side — your webhook handler must still HMAC-check the delivery.
  • There is no testnet mode. Every invoice is a real mainnet invoice using a real deposit address.