Similar asynchronous processing notification interfaces basically need to do this kind of processing, because asynchronous callback notifications will always not be notified due to network or processing delays. The specific method is to first generate a pending order before calling the asynchronous interface, and then call the Alipay interface for payment. After the payment is completed, under normal circumstances Alipay will actively request your callback interface. If there is no request, your order The status will remain pending. Then do a scheduled task. Every once in a while, query the pending orders and update the corresponding status according to the order status returned by Alipay. It should be noted that the time of order query is controlled. It is not recommended to put all Find the order and update it, and process it according to the amount of data you have. Generally speaking, it is time-consuming to remotely request the Alipay interface for synchronization processing. If there are too many unprocessed orders, it cannot be processed at all. The recommended approach is to directly send the query request. Go to MQ, and then open multiple consumer services based on the amount of data to process query requests. There is also a simple and crude way, which is to directly not process the orders to be processed, but provide the user with a function that allows the user to actively initiate a request. After the user clicks the retry button, he directly calls the Alipay query interface to query the order payment status.
Several statuses of the order: Pending payment, paid to Alipay, Alipay payment completed. The main response is: Payment has been made to Alipay. Some points to consider: real-time, idempotence
Real-time: According to your specific business scenario, single process, multiple threads, and multi-process processing. If there are multiple processes, the data needs to be processed in sections to ensure that the data is not repeated. Idempotent: each order must have a unique identifier. When each link is processed, it is guaranteed that the order has been processed.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Similar asynchronous processing notification interfaces basically need to do this kind of processing, because asynchronous callback notifications will always not be notified due to network or processing delays.
The specific method is to first generate a pending order before calling the asynchronous interface, and then call the Alipay interface for payment. After the payment is completed, under normal circumstances Alipay will actively request your callback interface. If there is no request, your order The status will remain pending.
Then do a scheduled task. Every once in a while, query the pending orders and update the corresponding status according to the order status returned by Alipay. It should be noted that the time of order query is controlled. It is not recommended to put all Find the order and update it, and process it according to the amount of data you have. Generally speaking, it is time-consuming to remotely request the Alipay interface for synchronization processing. If there are too many unprocessed orders, it cannot be processed at all. The recommended approach is to directly send the query request. Go to MQ, and then open multiple consumer services based on the amount of data to process query requests.
There is also a simple and crude way, which is to directly not process the orders to be processed, but provide the user with a function that allows the user to actively initiate a request. After the user clicks the retry button, he directly calls the Alipay query interface to query the order payment status.
Several statuses of the order: Pending payment, paid to Alipay, Alipay payment completed.
The main response is: Payment has been made to Alipay.
Some points to consider: real-time, idempotence
Real-time: According to your specific business scenario, single process, multiple threads, and multi-process processing. If there are multiple processes, the data needs to be processed in sections to ensure that the data is not repeated. Idempotent: each order must have a unique identifier. When each link is processed, it is guaranteed that the order has been processed.