To test crypto payments with CryptoLike, use its test environment: a separate cabinet and API that run on test networks, where coins have no value. Ask CryptoLike support for access and the test API URL, create a ck_test_ key there, point your code or plugin at that URL, and pay test payments through every status before switching to a live key.
There is no test mode inside production. The production API runs on the main networks and refuses test keys outright, so a forgotten test setting fails loudly instead of quietly taking fake payments. What a testnet is in general, and why its coins are worthless, is in the glossary.
How test and production differ
CryptoLike runs each environment on one kind of network only: production on the main networks, the test environment on test networks. The environment, not the key, decides which network a payment uses.
| Aspect | Production | Test environment |
|---|---|---|
| Networks | Main networks, real funds | Test networks, coins without value |
ck_live_ key |
Works | Works, moves test coins only |
ck_test_ key |
Not issued; every request refused with 401 auth.test_key |
Works |
| API URL | The default in the SDKs and plugins | Given by CryptoLike support |
| Cabinet | Your production account | A separate account in the test cabinet |
| Payment page, statuses, webhooks | As documented | The same; confirmations follow the same rules |
| Explorer links next to a transaction | Open the transfer | Open a main-network explorer, which shows "not found" for a test transfer |
Keys do not cross environments: a key from one gets 401 auth.invalid_key in the other, whatever its prefix.
1. Get access to the test environment
Write to CryptoLike support and ask for the test environment. You get access to its cabinet and the test API URL. Test coins have no value and cannot be moved to a main network.
Plan your test payments on Ethereum and TRON assets: ETH, TRX and the USDT and USDC tokens. Their test networks are public, so a wallet switched to the test network can pay, and confirmations arrive on their own. Bitcoin and Litecoin in the test environment do not run on a public test network, and an ordinary wallet cannot pay them. Statuses, webhooks and the payment page work the same for every asset, so the scenarios below cover your integration either way.
Test addresses for Bitcoin and Litecoin start with a different prefix than mainnet ones; on Ethereum and TRON a test address looks exactly like a mainnet address. Tell the environments apart by the cabinet and the API URL, never by the address.
2. Create a test API key
In the test cabinet, open Developers → API keys → Create key and set Mode to Test. The form explains: "This environment runs on test networks: test and live keys alike move test coins only." The first key there defaults to test mode and is named "First test key".
Give the key the same permissions your production integration will have, for example create_invoice and read, and store the secret on your server only; it is shown once. The production cabinet has the Test option greyed out, and the API answers an attempt to create one with 400 validation_error on the mode field.
3. Point your integration at the test API URL
Every CryptoLike client reads the API address from one setting, so switching environments means changing a URL and a key, not code.
| Client | Where the URL goes |
|---|---|
| TypeScript SDK | baseUrl option |
| Python SDK | base_url option |
| Go SDK | Options.BaseURL |
| PHP SDK | 'base_url' option |
| Any SDK, or curl | CRYPTOLIKE_API_URL environment variable |
| WooCommerce, OpenCart, PrestaShop, Magento | Test mode on, API URL field |
Without an explicit URL the SDKs use https://api.cryptolike.net, the production API. With a ck_test_ key that means 401 auth.test_key on the first request, which is the reminder to set the URL. The SDK reference lists the other variables; request signing is in API authentication.
In a shop plugin, switch on Test mode and paste the test API URL. The plugin checks the key prefix against the mode ("Test mode needs a ck_test_ key; live mode needs a live key."), shows a Test mode badge in its settings and tells shoppers "Test mode: testnet coins, no real funds." next to the payment method. Setup per CMS is on the WooCommerce page and the other integration pages.
4. Check your webhook endpoint with a test event
Register your endpoint in the test cabinet under Developers → Webhooks and press "Send test event". CryptoLike queues a ping event, signed and retried like any other; the response your server gave appears in the delivery journal.
Your endpoint must answer with a 2xx status within 10 seconds. A failed delivery is retried after 1 minute, 5 minutes, 15 minutes, 1 hour, 6 hours and 24 hours. Verify the X-Signature header before trusting the body, and reject a timestamp more than 5 minutes away from your clock in either direction; the webhook verification guide has the code in four languages.
5. Pay test payments through every status
A happy-path payment proves little. Create one payment per scenario in an Ethereum or TRON asset, pay it from a wallet switched to that network's test network, and check that your system does the right thing for each status and webhook.
| Scenario | How to cause it | What to check |
|---|---|---|
| Paid in full | Send the exact amount | invoice.pending, then invoice.paid; the order is fulfilled once, on paid |
| Underpaid, then topped up | Send less, then the rest to the same address | invoice.underpaid, the remaining amount, then paid |
| Expired | Create a payment with a short time to pay and do not pay | invoice.expired; the order is released |
| Cancelled | Cancel a payment while it is new |
The order is closed on your side |
| Overpaid | Send more than due | Status paid with overpaid_amount above zero |
| Late payment | Pay a payment that has already expired | late_payment: true and invoice.late_payment; the status does not change |
| Retried request | Repeat POST /v1/invoices with the same Idempotency-Key and body |
The same payment comes back, no duplicate |
The shortest time to pay is 60 seconds through the API, which makes the expiry case quick. The payment page names the network as production does ("Ethereum", "TRON") and does not say "test", so do not send test links to real customers. Its transaction links, like the cabinet's, open main-network explorers: a test transfer shows "not found" there even when the payment is paid. Trust the status in the cabinet and your webhooks, or look the txid up in an explorer of the test network. What each status means for the money is in underpaid, overpaid and late payments.
6. Switch to live
Going live repeats the setup in production with live values; your code stays the same.
- In the production cabinet, create a
ck_live_key with the same permissions. - Remove the test URL: unset
CRYPTOLIKE_API_URLor the SDK option, or switch off Test mode in the plugin and restore the default API URL. - Register the webhook endpoint in the production cabinet; its signing secret is new, so update it on your server.
- Create one small real payment and watch it reach
paid.
The launch checklist for online stores covers the shop side: statuses, stock and refunds.
Errors and fixes
Nearly every test-environment error comes from mixing the two environments. The error code tells you which half is wrong.
| HTTP · code or message | What happened | What to do |
|---|---|---|
401 auth.test_key |
A ck_test_ key reached the production API |
Set the test API URL, or use a live key in production. |
400 validation_error, field mode |
A test key was requested in production | Create it in the test cabinet. |
401 auth.invalid_key |
The key belongs to the other environment | Use the key issued where the URL points. |
| "Test mode needs a ck_test_ key; live mode needs a live key." | Plugin mode and key prefix differ | Match the key to the Test mode switch. |
"The API URL must start with https://." |
Plugin API URL without https:// |
Paste the full test API URL. |
| 409 on "Send test event" | The endpoint is disabled | Enable it, then send the event again. |
| Webhooks rejected by your server | Clock drift over 5 minutes, or the wrong secret | Sync the server clock; use the test endpoint's secret. |
FAQ
Does CryptoLike have a sandbox?
Yes, as a separate test environment rather than a switch inside production. It has its own cabinet and API URL and runs on test networks, so payments, confirmations and webhooks behave as in production without real money. CryptoLike support gives access. Payments there are made in Ethereum and TRON assets, whose test networks are public.
Can I use a ck_test_ key against the production API?
No. Production runs on the main networks and refuses test keys on every request, reads included, with 401 auth.test_key and a link to the documentation. A test key works only in the test environment, together with its API URL.
Where do I get test coins?
From the public faucets of the test networks, or from CryptoLike support together with access to the test environment, for the Ethereum and TRON assets you test with. Test coins have no value and exist only on test networks, so they cannot be sold or moved to a main network.
Are confirmations faster on test networks?
The rules are the same in both environments: a payment waits in pending until it reaches the confirmation threshold of its asset, and only then counts. The threshold is a setting of each environment, so the number in the test environment can differ from production; the payment page shows it as Confirming n/N. How long it takes depends on how often the test network produces blocks.
Can I test payment links without code?
Yes. Create a payment in the test cabinet and open its link, exactly as in the guide to crypto payment links. No API key is needed for that.