After the front desk receives the payment successfully, it will jump to the successful page by itself, and turn on the countdown jump. Normally, this jump is hard-coded, but when there are some special needs, this jump is dynamic
2. Process:
On success page ->
Obtain the payment order number through the three-party interface ->
Take the number and go to the background to ask what order is this ->
Get the corresponding information, splicing the corresponding dynamic jump road strength
3. Analysis:
Advantages: strong adaptability, can return different orders according to the interface, realize different jumps
shortcoming:
1. Asynchronous payment may notify the background that the background is not timely, the background order status has not been modified, or the order status has not been modified due to a bug in the background code logic. Careful consideration should be given to this situation.
(I need to consider whether the order status is modified here? Personally, I don’t think it is necessary to consider whether the background order status is modified, so this shortcoming should not exist. Recently, it also depends on the business needs. For example, the asynchronous is unsuccessful, and you jump dynamically. When the page needs to generate some data asynchronously, it must wait for the asynchronous success)
2. Sometimes when the three-party payment interface returns, without the order code, you cannot go to the background to query the corresponding order