How to prevent repeated payment of orders?

Hello everyone , I'm the third , You must be familiar with online payment , Today, I want to talk with you about how to prevent repeated payment of orders .

Official account 「 Three evils 」, reply 「666」, Get an exclusive and original interview manual with more than 700 pages ！

Look at the order payment process

Let's see , Brief process of e-commerce order payment ：

Order from / The calculation begins ：

1. Place an order / Settlement ： Although this step is not the direct starting point of payment , But the payment related amount and other information come from settlement , At this time, the status of the order is unpaid

2. Application for payment ： The user chooses to apply for payment , The client invokes the payment service , At this time, a payment flow is generated in the system , The status of this flow is unpaid

3. Initiate payment ： Payment service calls three-party payment , Usually this kind of wallet payment , In the step of initiating payment , Will respond to some payment links , The client will process the link accordingly .

4. Pay with your wallet ： Users pay , Usually through the corresponding wallet , You can recall your shopping , Payment process , Different ends , The processing of wallet payment is different ：

   • PC End ：PC End , Usually open the cashier , Show a QR code , Pay by scanning your wallet , Below is jd.com's wechat payment scanning page

   

   • WAP End ： Mobile website ,WAP The end of the payment is usually directly pull up the corresponding wallet , If you fail to pull up your wallet , Jump to the interface

     

     • APP End : At home , Shopping is mostly in APP End , Product managers will try to bring users to APP, Why do my example pictures use JD , Don't use Taobao ？ Because I take UC Open Taobao , Will jump directly APP.

       APP End wallet payment , We should all be very familiar with , It's usually pulling up your wallet , payment .

       

5. Payment callback ： After the user completes the payment , Tripartite payment platform , Will call back merchants , Notification of payment results .

6. Synchronize order status ： Payment service after confirming the completion of payment , The payment results will be synchronized to the order service , Order service changes the status of the order , By unpaid -》 To be delivered , The client polls 、 A long connection , Or the way that the server actively pushes , Change the order status on the interface .

Let's look at the change of payment status from the perspective of payment flow ：

• Never paid , To the final state with payment results , There is another intermediate state in the middle In the payment
• Users open their wallets –》 Complete payment –》 Payment callback , The payment flow during this period is In the payment

Why spend so much time on the business process of payment 、 Interaction process ？ Because I think , Prevent double payment of orders , It's not just a technical problem , It is also a business and product problem .

Why are orders paid repeatedly

Repeated payment caused by failure to prevent weight

We can see PC End payment , It's scanning QR code , These QR codes , It corresponds to the corresponding payment flow , If the user clicks repeatedly to pay , If you don't do anti weight , Two payment flows will be generated , That is, two different QR codes , If the user scans two different payment codes , So there's no doubt about it , There will be repeated payments .

Repeated payment caused by missing orders

“ I paid clearly , Why hasn't my order been paid yet ？”

That's what's called “ Drop the list ”：

• External drop order ： The payment status of the three-party payment is not synchronized or is not synchronized to the mall in time , This is called external order dropping
• Internal drop order ： The status of the payment service is not synchronized to the order , Or the client does not get the order status in time , This is called internal order dropping .

The user has a look , I paid for it myself , As a result, the order in the mall has not been paid , But I especially want , Maybe another order will be placed , In this way, the payment is repeated .

Repeated payment caused by multiple channels

Our domestic payment experience is very fast , You may not feel , If you know about overseas payment, you may know , Many payment channels , It takes a long time .

For example, user Paul chose a payment method Boleto, As a result, the payment outlet is too far away from Paul's village , Paul chose again Paypal payment , When Paul went to the market , Go to the outlet again Boleto This payment of , As a result, the payment was repeated .

You may seldom encounter this kind of situation , We can use Meituan Next order , First open wechat payment , Don't pay , Then return to meituan , Open Alipay , After paying with Alipay , Pay with wechat , Let's guess , Can both payments succeed ？ The answer is yes .

How to prevent repeated payment of orders

Lock

Whether it's 3. Application for payment 、 still 5. Payment callback , Should be locked with the order dimension , Prevent repeated operations under concurrency .

Lock , without doubt , It is also a distributed lock , Usually we choose Redis Distributed lock .

Cache results

Successfully applied for payment , Payment callback succeeded , Should cache the results .

Apply for payment again , When a successful callback is received , You should check the payment status first .

Cancellation during payment

If say , The user paid repeatedly , When applying for payment again , If you have successfully applied for payment , Then this payment must be rejected .

however , If the existing water still exists In the payment Well ？—— We are not sure whether it will succeed or fail , It must be impossible to refuse to pay , Because maybe the user failed to pay , But the status is not synchronized , That's not gonna work .

therefore , We can cancel the current payment , Pay again .

A running refund has been paid

Now there are new problems , If the payment is initiated , There is running water being paid , If the third-party payment platform does not support cancellation of payment , Or users' new payment is through different channels , We hope to improve the payment success rate of users as much as possible , What shall I do? ？

We can initiate payment , When the order is still being paid , Allow users to initiate multiple payments , At the time of payment callback , Check whether the user has a successful flow , Refund the subsequent flow .

Of course , Refund is a very dangerous operation , After all, the money is refunded , But it's hard to catch up , We must do a good job in risk control .

Active polling & Try again to prevent dropping orders

Active polling prevents external order dropping

If the callback is not received because of the fault , Or the callback is not received in time , The so-called external off order may occur .

The key to prevent external order dropping , It's about , You can't just wait for the callback notification of the three parties , Instead, take the initiative to inquire , User initiated payment 3s after , You can start polling , Until we get the final status of the payment flow , Active polling , Generally, this can be achieved ：

• Scheduled task polling

  Using scheduled tasks , Scan the flow of payment in the table , Actively query the status of payment , There are many ways to implement scheduled tasks , Thread pool 、 Scheduling framework 、 Distributed scheduling framework and so on .

  Timed task polling has two disadvantages ：

  1. There is some pressure on the database , Watch and monitor , You will find that when the scheduled task scans the table , Sometimes it will cause some problems in the database “ Peak thorn ”
  2. It is inconvenient to adjust the frequency , actually , After the user initiates a payment , Usually in 10s-1min Complete the payment , The later , User completes payment , So polling gradient , It would be more reasonable , The polling interval can be set like this ：3s,10s,30s,3min……

• Delay message polling

  Another way is to use delayed messages , After the user initiates the payment , Send a delay message , Consume until after the delay message , Query the daily payment status , Didn't get the final status , Just send another delay message . The advantage of delayed messages is that there is less pressure on the database , The gradient of polling can also be controlled , The disadvantage is that the implementation is more complicated , And maintain the message queue .

Sync + Asynchronous to prevent internal order dropping

The payment service calls back after receiving the asynchronous notification 、 Or after actively polling the final state of the flow , Notice the change of order service payment flow , The order service synchronously updates the status of the order , This process should be as successful as possible , Synchronization can be used + Asynchronous way .

• A synchronous invocation ： The payment service calls the notification interface of the order service , It may fail due to network and other reasons , You can also try again , But based on experience , If there are some fluctuations in the network , Retry is likely to fail .
• Asynchronous notification ： The payment service should also send a successful payment message , The order service can utilize the retry mechanism of message queue , To ensure the synchronization of payment status as much as possible .

There's another problem here , How does the client synchronize this state ？ Because the server may have updated the order status , But the client interface is still unpaid , Users have to take the initiative to refresh , To get the latest status , This is obviously inappropriate .

Server side 、 State synchronization of the client , Nothing but PULL and PUSH :

• PULL ： It's simple , When the client jumps back to the order status page , Poll for a while , If the user completes the payment , Usually, the change of state can be obtained in a short time , Of course, this method will have some impact on the performance of the client , And state synchronization often occurs “ a fish escaped through the seine ” The situation of .
• PUSH ： The implementation of push is a little troublesome ,Web Usually with Websocket, Yes APP End push , Generally, third-party push platforms are used .

The client payment should not jump out as much as possible

No matter from the perspective of products , Or from the perspective of Technology , The client initiates payment , In fact, you should try not to jump out as much as possible ,PC The client uses the payment code generated by the payment service , Instead of jumping ; Mobile web page 、APP Display the payment page in the app , Of course, this is decided by the third-party payment platform .

I wonder if you have noticed , Now Alipay , You have done it without pulling up your wallet , Payment can be completed within the application , This is of great significance to businesses , For the user experience 、 Payment success rate , Have a positive effect , I believe that with the degree of domestic involution , Other payment suppliers , Definitely, I will “ To follow up ” Of .

---

Okay , About how to prevent double payment , That's all . For payment , The third is just a novice , I hope you guys will give me some advice .

---

Reference resources ：

[1]. How does the server prevent duplicate payment

---

Face slag counter attack series ：

• Face slag counter attack ：Java Basic fifty-three questions
• Face slag counter attack ：Java Set up a series of thirty questions
• Face slag counter attack ：JVM Classic fifty questions , Now the interview is stable ！
• Face slag counter attack ：Java Ask
• Face slag counter attack ：Spring Thirty five questions , 40000 words + Fifty pictures in detail ！
• Face slag counter attack ： Figure 22 、 Eight thousand words 、 Twenty ask , Get it all done MyBatis！
• Face slag counter attack ： Computer network 62 ask , 30000 word graphic explanation ！ Collect quickly ！
• Interview byte , Hung up by the operating system
• Face slag counter attack ：RocketMQ Twenty three questions
• Face slag counter attack ：Redis Serial 52 asks ！ Thirty thousand words + Detailed explanation of 80 pictures ！