Deposit callback
<p><strong>Brief description</strong></p>
<ul>
<li>Callback notice for coin deposit</li>
</ul>
<p><strong>Attention:</strong></p>
<ul>
<li>
<p>The same notification may be sent to the merchant system multiple times. The merchant system must be able to handle duplicate notifications correctly. The recommended practice is that when the merchant system receives a notification for processing, it first checks the status of the corresponding business data and determines whether the notification has been processed. If it has not been processed, it will be processed again; if it has been processed, the result will be returned directly as successful. Before checking and processing the status of business data, data locking should be used for concurrency control to avoid data confusion caused by function re-entry.</p>
</li>
<li>
<p>If no KlicklPay callback is received, the merchant should call the order inquiry interface to confirm the order status</p>
</li>
<li>
<p>The merchant system must do signature verification for the content of the opening result notification, and verify whether the notified information is consistent with the information on the merchant side to prevent data leakage leading to "fake notification" and resulting in capital loss.</p>
</li>
<li>In case of fixed address mode, it may happen that the user places one order in the merchant system but initiates two top-ups, if the order placed by the user is not found in the KlicklPay platform, the order will be automatically created for the user in the KlicklPay platform and then called back, merchants need to pay attention to this scenario when docking callbacks.</li>
</ul>
<p><strong>Notification rules:</strong></p>
<ul>
<li>
<p>After the user has made the payment, KlicklPay sends the relevant payment result to the merchant, who needs to receive and process the message and return an answer.</p>
</li>
<li>When interacting with backend notifications, if KlicklPay receives a response from a merchant that does not meet the specification or timeout, KlicklPay considers the notification to have failed and KlicklPay will periodically re-initiate the notification through certain policies</li>
</ul>
<p><strong>Request method:</strong></p>
<ul>
<li><code>POST</code>
Parameter content in the form of application/x-www-form-urlencoded</li>
</ul>
<p><strong>Callback notification example</strong>
<img src="https://www.showdoc.com.cn/server/api/attachment/visitFile?sign=f0450d71c481b518de6064eb14e7f245&file=file.png" alt="" /></p>
<p><strong>Example of signature</strong>
（Sort the parameters in ascending order by name, then add the key for MD5 to get the mac value）
Example of signature when the productName and exData are not passed to the deposit request:</p>
<pre><code>mac=MD5(actualPaymentAmount=100&address=TAeMbWoQXFHsghaciHU5R49XBJVHSisY1Y&amount=100&coin=TRC20_USDT&creationTime=1644862950186&orderNo=O202202151493410356700860411&outOrderNo=20220215032229628495&paymentUserId=34419&receivedTime=1644863516194&status=4&timeStamp=1644863528178&txId=e5d6286de4a42b8551c6e37b784093bfd7258eb90bc5e998995546fd88e1410f&secretKey=b33d9fa8-ba71-474e-96bc-4217e4b989d6)</code></pre>
<p>Example of a signature when a productName and exData are passed to the deposit request:</p>
<pre><code>mac=MD5(actualPaymentAmount=100&address=TAtfv8ZKMiN1DTsW1xJWqmWTW6NoEs7dRT&amount=100&coin=TRC20_USDT&creationTime=1644670622682&exData=vip&orderNo=O202202121492603676660511680&outOrderNo=202202111557011080217980&paymentUserId=21939&productName=buyvip&receivedTime=1644671213544&status=4&timeStamp=1644671225425&txId=1f6db25c2b7f8188ba6c60bc86a8d0daf326c2ef54e3fc3ae71cfe875b3734a6&secretKey=b33d9fa8-ba71-474e-96bc-4217e4b989d6)</code></pre>
<p><strong>Description of notification parameters</strong></p>
<table>
<thead>
<tr>
<th style="text-align: left;">Parameter name</th>
<th style="text-align: left;">Type</th>
<th>Maximum length</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">orderNo</td>
<td style="text-align: left;">string</td>
<td>64</td>
<td>Platform order number</td>
</tr>
<tr>
<td style="text-align: left;">outOrderNo</td>
<td style="text-align: left;">string</td>
<td>64</td>
<td>Merchant order number</td>
</tr>
<tr>
<td style="text-align: left;">paymentUserId</td>
<td style="text-align: left;">string</td>
<td>64</td>
<td>Unique identification for merchant platform users</td>
</tr>
<tr>
<td style="text-align: left;">amount</td>
<td style="text-align: left;">decimal</td>
<td>decimal(65,30)</td>
<td>Order amount</td>
</tr>
<tr>
<td style="text-align: left;">actualPaymentAmount</td>
<td style="text-align: left;">decimal</td>
<td>decimal(65,30)</td>
<td>The actual amount paid by the user, the merchant shall give the user the credit according to the actual amount paid</td>
</tr>
<tr>
<td style="text-align: left;">status</td>
<td style="text-align: left;">int</td>
<td></td>
<td>Status (0: not filled; 4: completed; 5: manually completed; 6 : closed/revoked) Callback will be made only when the status is 4/5/6</td>
</tr>
<tr>
<td style="text-align: left;">productName</td>
<td style="text-align: left;">string</td>
<td></td>
<td>Product name, if the productName field is not passed in the coin application, no signature will be added.</td>
</tr>
<tr>
<td style="text-align: left;">address</td>
<td style="text-align: left;">string</td>
<td>256</td>
<td>Deposit address</td>
</tr>
<tr>
<td style="text-align: left;">coin</td>
<td style="text-align: left;">string</td>
<td>32</td>
<td>Coin</td>
</tr>
<tr>
<td style="text-align: left;">txId</td>
<td style="text-align: left;">string</td>
<td>text</td>
<td>Txid,Multiple TxId's may appear. If the order is closed and the txId is empty, no signature or callback will be added. See comments for example</td>
</tr>
<tr>
<td style="text-align: left;">exData</td>
<td style="text-align: left;">string</td>
<td>500</td>
<td>Merchant extended data, if the coin application is not passed into the exData field, then no signature will be added.</td>
</tr>
<tr>
<td style="text-align: left;">creationTime</td>
<td style="text-align: left;">long</td>
<td></td>
<td>creationTime</td>
</tr>
<tr>
<td style="text-align: left;">receivedTime</td>
<td style="text-align: left;">long</td>
<td></td>
<td>Payment arrival time</td>
</tr>
<tr>
<td style="text-align: left;">mac</td>
<td style="text-align: left;">string</td>
<td>string</td>
<td>Signature</td>
</tr>
<tr>
<td style="text-align: left;">timeStamp</td>
<td style="text-align: left;">long</td>
<td></td>
<td>Current UTC time stamp</td>
</tr>
</tbody>
</table>
<p><strong>Notification of response</strong></p>
<ul>
<li> The payment notification http answer code is 200 or 204 before it will be accepted as normal, and the merchant should return the standard json answer format after successful callback processing, see example for format. When the callback processing exception, the HTTP status code of the answer should be 500, or 4xx , isSuccess = false , message fill in the reason for the exception.
<pre><code>{
"isSuccess": "true",
"message": "success"
}</code></pre></li>
</ul>
<p><strong>Notification response parameter description</strong></p>
<table>
<thead>
<tr>
<th style="text-align: left;">Parameter name</th>
<th style="text-align: left;">Type</th>
<th>Maximum length</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align: left;">message</td>
<td style="text-align: left;">string</td>
<td>64</td>
<td>Returns a message, if not null, as the cause of the error.</td>
</tr>
<tr>
<td style="text-align: left;">isSuccess</td>
<td style="text-align: left;">bool</td>
<td></td>
<td>Status: true success, false failure</td>
</tr>
</tbody>
</table>
<p><strong>Notes</strong></p>
<ul>
<li> For more return error codes, please refer to the error code description on the homepage.</li>
</ul>