Article directory
foreword
Recently, I feel that I should summarize some of the more interesting core processes I encountered in my work so as to improve my ability to summarize projects. Due to limited ability, I hope that all netizens who have problems in this article can contribute, thank you.
background
This is an NFT e-commerce business. The requirement is to do a snap-up function. It is required that a user can only snap up one NFT. The number of NFTs is limited and the number is unique. The number sold cannot be repeated. The total quantity cannot be sold more than the number. Sell, each user account can not buy more. Here we only talk about the payment process first, because this part involves more third-party interactions, which is difficult to control.
General order payment process
Attention to details in the order payment process
Prevent duplicate order creation
Why do duplicate orders appear?
Because the client and server do not perform idempotent operations.
Treatment measures
The client needs to make a judgment to prevent repeated form submissions and the server to prevent repeated creation of orders.
Here, combined with business requirements, a unique order number can be generated based on product information and activity strategies to guarantee idempotence on the server side.
Duplicate payment due to lost order
Why does this happen
-
External order drop: The payment status of the third-party payment is not synchronized or not synchronized to the mall in time, which is called an external order drop.
-
Internal order drop: The status of the payment service is not synchronized with the order, or the client does not obtain the order status in time, which is called internal order drop.
Treatment measures
It is processed by a combination of active query and passive waiting.
Actively wait for the payment service to call back the successful payment information of the order service. However, due to possible network problems, the callback information cannot be received for a long time, so it is best to add an active query method. But we can’t take the initiative to query immediately, too frequent and easy to cause the third-party payment platform to limit our flow, we generally set the callback before receiving the payment information after the normal callback time of the third-party service.
Here we use delayed tasks for active queries. Because this solution is more real-time than scheduled tasks and delayed queues, the frequency of querying the database is lower. For active query and passive reception, when updating the order and payment status, it is necessary to judge whether the update is successful. Success means that the thread has updated the data. The update record is 0, which means concurrency. Update status. If updated, it will return update success information. If it fails, update failure prompt will be displayed. At the same time, this part needs to classify failure scenarios, which ones need to be alerted and which ones do not.
Refunds paid
Why does this happen
If there is a payment in progress when the payment is initiated, if the third-party payment platform does not support cancellation of payment, or the user's new payment is through a different channel, we hope to increase the user's payment success rate as much as possible, what should we do?
Treatment measures
We can allow the user to initiate multiple payments when the order is still being paid when the payment is initiated. When the payment is called back, we can check whether the user has a successful transaction and refund the subsequent transaction.
Of course, refunding is a very dangerous operation. After all, the money is refunded, but it is difficult to get it back. We can use the review method to let the operating personnel review the refund. Because there are not many orders in itself.