Callback Integration Preparation Instructions
Technical specifications for merchants to handle WaaS callback requests
1. WaaS Callback Processing Flow
// Request sent by WaaS to merchant’s callback URL
POST /your-callback-endpoint HTTP/1.1
Host: your-merchant-domain.com
Content-Type: application/x-www-form-urlencoded
X-API-KEY: merchant_api_key_12345
ew0KICAib3JkZXJJZCI6ICIxMjM0NTY3ODk…
2. Key Points for Merchant Handling Callbacks
- Obtain key provided by WaaS from HTTP header
X-API-KEY
- Verify whether key is valid and within validity period
- Return
401 Unauthorized
if validation fails
Note: This API Key is different from the key used by merchants to call WaaS APIs
- Must use
HttpServletRequest
raw input stream for reading - Base64 decode to obtain encrypted byte data
- RSA decrypt using merchant public key
Common error: Misusing request.getParameter(“data”)
will return null
The WaaS system sends event notifications to the callback URL configured by the merchant. Merchants need to correctly handle these callback requests. The encryption/decryption process is the same as when merchants call WaaS APIs, the main difference is in the way callback data is read.
3. Callback Idempotency Handling
Callback Type | Idempotency Key Composition | Explanation |
---|---|---|
Deposit Callback | (txid, chain, symbol, toAddress) combined hash | Resolves wrapped contract duplicate deposit issues |
Withdrawal Callback | txid | Globally unique transaction ID controlled by WaaS |
Other Callbacks | (type, trackingId, callBackId…) | All callback types must implement idempotency |
WaaS Tip: Do not use requestUUID that changes each time as idempotency key
- Store unique identifiers of processed callback events
- Return success status directly for duplicate callbacks (without repeating business processing)
- WaaS will retry callback only when callback processing fails (only when errCode=0 is considered successful by WaaS)