recently, I have been experiencing a very depressing thing. After the system developed by myself is put online, there will always be a problem that one or two payments have not changed the status of the order. And the order with the problem is that several orders are repeatedly generated in the same second and finally the money is not changed to the order status.
122017092918226
9012
submit the order and save it to the system, and then find out the details of the order display. The confirmation button is shown below, and the page to be paid after confirmation is displayed
. This prevents duplicate submission directly from the design point of view. Even if the step of submitting the order is repeated, the confirmed order definitely exists
PS: does not recommend changing the button disable state directly, because sometimes it can be clicked for no reason.
it is best to directly display a layer to prevent event bubbling, and the layer covers the entire page. It is safer to use it with disabled status
I don't see the complete functions of front-end payOrder and payMoney, and I don't know if there's a problem.
looking at the description of the landlord, I didn't find anything wrong with the front end.
add:
the problem of repeatedly placing an order can be controlled by the back end before the front-end problem is found. If the item number and quantity contained in each order are the same, and within a short period of time, such as 2 minutes, it can be judged to be a repeat order.
my current platform also has this kind of problem. It is usually repeated when the user clicks, an instant thing, which is difficult to identify. What I use now is the most simple and rude. As soon as it is submitted, the button will be grayed out or redirected without waiting for the server to give feedback. I hope you can share it when you have a good plan.
one button is enough
<button class="payf" type="button" onclick="payOrder()" disabled="false">
</button> add a disabled attribute to the button, and then set a flag bit.
when sending a request, set disabled to true, to disable click payment until the asynchronous result comes back.
there is also a situation where when the asynchronous result returns that the order number already exists, you can jump to a new page and tell the user not to submit any more and where to view the submitted order.
1. The front end forbids repeated clicks. 2. The backend processes the business and finds duplicate orders, which are prohibited from entering the table
this problem should not be solved through a pure front-end approach. Look at the records in the database are basically submitted at the same time, the subject also said that more than N people in the company failed to reproduce a test.
solution: make the request "idempotent". to put it simply, getting a token, that places an order in advance on the payment page can only submit an order once per token, and creating an order with the same token will not succeed .
payment operations should not only be checked at the front end, but also need to be intercepted at the backend
for testing compatibility. If there is a problem with the
callback, find out which sql statements were executed for that order, where the code execution suddenly broke, and Wechat initiated a total of several callbacks for you. For example, turn on
to enable the debug mode of tp. Or mysql writes slow logs, and you can write a method to save the content to be debugged in a file or database, such as the beginning of the callback, save the execution time of the xml, callback, and write these down for troubleshooting!
the final solution is
2. Backend limit
whether there is a difference of 15 seconds between the previous query, if repeated submission of orders is prohibited within 15 seconds. Effectively prevent multiple orders from being submitted in a short period of time.
frontend: status settings to prevent repeated clicks on
backend: redis setnx