メインコンテンツまでスキップ

Transaction Result Notification

POST 
/:notify_url

Upon the completion of a payment or refund, PayCloud will forward the transaction results and associated user details to the merchant. In such cases, it's imperative for the merchant's backend system to acknowledge this data by sending a response to the gateway payment system.

Note: The current API sends webhooks from PayCloud to the merchant's server. If the notification is successfully received and processed, please return the fixed string: success.

  1. The server URL for receiving notifications from the merchant system is provided to us through the notify_url parameter at the time of placing the order.
  2. If the gateway payment system doesn't receive a confirmation (either a success or a timeout) from the merchant's side, it will interpret this as a missed notification. To ensure the merchant receives these notifications, the system will resend the notice periodically, with a total of 15 attempts over a 12-hour span. However, do note that the system cannot guarantee the delivery of every notification. The reminders will be sent at intervals of: 5s, 10s, 15s, 30s, 60s, 3m, 10m, 15m, three 30m intervals, and three 3h intervals.
  3. Given the system's approach, there's a possibility that the merchant's backend will receive the same payment notification multiple times. As such, merchants need to ensure their systems are equipped to handle such duplicate notices.
  4. The recommended way to manage this is to examine the attached payment information upon receipt of any notification. This is to determine if these details have been processed previously. If the data was already processed, simply return the previously established result. If not, process the new data and then send the response. To ensure data integrity, especially in the face of concurrent transactions, employ a transaction lock before scrutinizing the payment data.
  5. For added security, merchants should also validate the notification's signature. This means checking if the order total mentioned in the notification matches the one recorded in the merchant's own system.
  6. In future iterations, additional parameters may be added to notifications based on evolving business requirements. Hence, it's crucial to ensure your validation system is adaptable. Instead of having a hardcoded list of parameters for verification, your system should be able to dynamically handle parameters as provided in each notification.
  7. Lastly, there might be instances where payment notifications are either not received or where there are signature verification issues. To counteract potential transaction oversights, it's strongly advised to implement a polling mechanism as a safeguard

Request​

Responses​

Response Headers