Receive and debug callbacks

Step-by-step guide

Follow these steps in your own dashboard. Select an image to enlarge it.

1. 1

   Open Receive Callbacks in the developer center and enter your merchant UID and API Key. Copy the displayed debug notifyUrl into the orders whose callbacks you want to inspect, or select Use debug URL in the order tool.

   

2. 2

   Start receiving to refresh every four seconds and show up to the latest 20 records sent to that debug address. Refresh now queries immediately. Stop receiving only stops the page's polling; it neither cancels orders nor disables the server endpoint. Orders using another notifyUrl will not appear here.

3. 3

   Pay-ins send completed callbacks after successful processing. Payouts send final callbacks at confirmed or failed. A newly created, unpaid or confirming order does not yet have a success callback. Compare order numbers, asset, amount, hash, signature verification and delivery status. Successful verification by the debug receiver does not prove your own business system processed the payment.

4. 4

   For your own service, use the complete Node.js or PHP receiver example below the tool. Deploy it to a publicly reachable HTTPS URL and preserve rawBody. With the API Key used for the original order, verify HMAC-SHA256(timestamp + "." + nonce + "." + rawBody) against x-callback-signature. Do not reformat parsed JSON for verification or substitute the request header x-signature.

5. 5

   After signature verification, check the merchant, order relationship, network, asset, amount and final business status. Use database transactions and unique constraints to make updates idempotent. Return HTTP 2xx only after successful handling or reliable persistence to a processing queue. Reject invalid signatures and do not report success when your service fails.

6. 6

   First test locally with a fictional key: valid notifications pass; modified bodies fail; duplicate delivery updates only once; interrupted processing can recover. Then set new orders' notifyUrl to your own service and inspect logs, responses and business orders. Non-2xx responses or timeouts trigger up to three attempts: a retry one minute after the first failure, then a third attempt five minutes after the next failure. Do not assume unlimited retries.