Testing your integration

Two admin panel tools for verifying your integration: Transaction History and Test webhooks.

Beyond sending real (or testnet) payments, the merchant admin panel gives you two tools to verify an integration without writing extra code:

• Transaction History — inspect real invoices, deposits, and withdrawals and their full status history, optionally driven by a sandbox payment simulator.
• Test webhooks — send a synthetic, signed webhook to your endpoint on demand, independent of any real object.

---

Transaction History

Go to Accounts → History. The table lists invoices, deposits, withdrawals, conversions, and transfers for the selected account. You can filter by type and status, or search by ID, order ID, or transaction hash.

Click a row to open the detail drawer. Its Status history section shows every status transition with a timestamp and source (API, Admin, Payment page, or System) — the quickest way to confirm your object moved through the statuses you expect.

For invoices in the sandbox environment, the drawer also offers Simulate payment (admin-only). It advances the invoice through the real settlement pipeline and fires real invoice.statusChanged webhooks, without requiring a testnet transfer.

See Sandbox environment for the testnet-based flow, and the status pages for what each status means: invoice statuses, deposit statuses, withdrawal statuses.

---

Testing a plugin or integration without sending crypto

CMS plugins (WooCommerce, WHMCS) and integrations like Zapier create a real Cryptonly invoice for each order, tagged with an orderId you can recognize (for example WC-123 for WooCommerce, WHMCS-45 for WHMCS, or whatever orderId your Zap sends).

To confirm the whole round trip — plugin creates invoice, customer pays, your store/CRM gets notified — without moving testnet funds:

1. Place a test order through the plugin or integration as usual, so it creates a Cryptonly invoice.
2. In the admin panel, go to Accounts → History and search for that order's orderId to find the matching invoice.
3. Open the invoice and click Simulate payment.
4. Cryptonly settles the invoice for real and sends the resulting invoice.statusChanged webhook exactly as it would for a genuine payment — to the invoice's webhookUrl (how WooCommerce and WHMCS receive it) and to any tenant-level webhook subscription (how Zapier's triggers receive it).
5. Confirm the plugin or integration reacted as expected (order marked paid, Zap fired, and so on).

This only works while the invoice is still simulatable (typically created, before a real payment settles it) and requires an admin account in the sandbox.

---

Test webhooks

Go to Settings → Integration → Test webhooks (admin-only). Pick a kind — Invoice, Deposit, or Withdrawal — which sends invoice.statusChanged, deposit.statusChanged, or withdrawal.statusChanged respectively, then choose a status, enter your webhook URL and an orderId, and send.

The payload is synthetic (sample amounts, random IDs), but it is signed with your real webhook signing key, so this is a valid way to test signature verification and handler logic in isolation. It does not create or update any invoice, deposit, or withdrawal.

See Webhooks for signature verification, payload structure, and the full list of test webhook kinds.

---

Which one to use

Goal	Use
Verify a real object moves through the expected statuses	Transaction History (with the payment simulator in sandbox)
Verify your endpoint is reachable, signature verification works, and your handler behaves correctly	Test webhooks