The cover is for my dog brother
Hello, everyone, I’m the little black man downstairs ~
In today’s article, we continue the topic of last time, continue to talk about the payment system exception solution.
In the previous article “Abnormal solution for payment of order drop”, we mainly mentioned the scenario of order drop in the process of payment. The user clearly made the payment and the bank card has been deducted, but the order is still displayed to be paid.
In today’s post, we’ll talk about the exception of double payment, where the user is charged two sums for the same order.
We will also mention another exception, where the user successfully charges, but the order fails to be paid.
For the users who have been charged for the above two kinds of exceptions, the use experience is very poor. They have paid more money, but the order is not successful. So if you don’t deal with these two types of exceptions in a timely manner, you can expect complaints.
Welcome to pay attention to my public number: procedure, get daily dry goods push. If you are interested in my topics, you can also follow my blog: studyidea.cn
Double payment exception
Abnormal scenario
The exception of double payment is usually found in the payment scenarios such as e-banking payment, wechat payment, Alipay, etc., which need to jump to a payment gateway page (e-banking payment), or jump to the wallet APP(Alipay, wechat), so as to complete the asynchronous deduction.
In this type of payment scenario, the only way to know the result of the payment is to accept the asynchronous notification, which is commonly referred to as the asynchronous payment.
PS: With asynchronous payment, what is synchronous payment?
In fact, synchronous payment means that the payment result can be returned immediately after the payment interface is called. For example, bank card fast/withholding payment is synchronous payment.
Of course, there are also some strange bank card payment channels, synchronous payment results for the acceptance of success, can only accept asynchronous notification or query back payment results.
Since bank card payment needs to return a clear payment result, this type of channel can only be internally designed to change from asynchronous to synchronous. You can see the previous historical article for interest:
Architecture design | how synchronous processing asynchronous requests?
The background payment process is as follows:
The picture is from the previous article: How Card Payment works
Why does double payment occur?
The main reason is the same as the previous internal slip exception, which is related to the business table design.
As we mentioned last time, the main table structure of the payment system is as follows:
Under this table structure, as long as the payment order is unsuccessful, the merchant can repeatedly invoke the payment interface using its internal same order number.
Suppose such a scenario, the user chooses China Merchants Bank for online banking payment when he pays at the cashier, and when he clicks to pay, the merchant system will call the online banking interface of the payment company.
At this time, a payment order and the associated channel order will be created inside the payment system, and the interface of the mobile bank system will be called.
Then the user’s browser page will open a new page, and then jump to the China Merchants website.
If the user clicks pay again at the checkout counter, the payment system interface will be called again. At this time, because the payment order already exists, only another channel order record will be created and the CMB system interface will be called. At this time the user’s browser will open a mobile website again.
If the user completes the payment on both China Merchants Bank online banking pages, then double payment occurs.
This scenario may seem silly, but real user action can actually happen. In addition to this, the friends on the blog garden also mentioned the following situation:
The solution
There are two main solutions to the double payment exception, which are pre-payment and post-payment.
The main goal in advance is to prevent users from making repeated payments as far as possible. The main solution is to optimize the payment page and do prompt as far as possible.
In the first optimization method, the payment page directly jumps to the online banking page of the third party/bank. Do not open a new page to jump.
This method can prevent users from opening two online banking payment pages by mistake, which can lead to double payment.
However, there will be a problem here. After the payment on the bank’s online banking page is successful, how can the user know that the order status on the merchant side is also successful?
In fact, very simple, now online banking payment interface, generally will have a parameter return_URL: synchronous jump address.
As long as the address is passed in the interface, when the payment is successful, the page will eventually jump to the incoming address, and the merchant side can display whether the order has been paid successfully at the address.
As mentioned above, it is possible for users to use the browser rollback feature and jump to the payment page, leading to repeated payments.
In this case, we can first query the payment result of this order to the background when it returns the payment page. If the payment has been successful, the success page will be directly displayed.
The second optimization, for this re-opening a page to jump to the bank website, we can add a pop-up prompt in the page, asking the user whether the payment has been completed.
For example, when the user clicks the confirmation to complete the recharge, he can immediately query the order status to the background.
Let’s talk about the solution after the fact, in fact, the solution is very simple, initiate internal refund, will pay a reverse refund back.
There can be a scheduled task in the payment system, which can scan the records of multiple successful channel orders under the payment order at a scheduled time, and then select to issue a refund to the repeated payment channel orders.
This method is an internal operation of the payment company system and does not require instructions from the merchant side.
Order failure exception
Abnormal scenario
This scenario is commonly seen in e-commerce shopping, seckill and other shopping scenes. Once the user has placed the order, the page will start to count down and the user needs to pay successfully within the validity period.
Suppose the user clicks to jump to Alipay, but instead of paying immediately, he stays for a long time and completes the payment within the last second of the order, but at this time, the order has already expired and is automatically cancelled.
This occurs in a scenario where the user has successfully charged, but the order has failed or closed.
In another case, the payment is successful within the validity period, but the asynchronous notification of the payment result is received after a long time due to network and internal application problems. At this time, the early internal order is cancelled due to the expiration of time.
The solution
The first solution is to send the expiry date to the payment channel.
Generally, the payment interface will have a payment validity period field, indicating the latest time when the payment can be paid. If the payment is not made over time, the payment will be closed.
Of course, under normal circumstances, if not sent, this field will generally have a default validity period, such as 3 days, this time is relatively long.
So when the payment interface is invoked, the remaining validity period of the order can be passed into the payment interface. If the user does not complete the payment within the timeout period, the payment will fail.
The second solution is to initiate a refund internally.
This solution is still a post-payment solution. In case the payment order has been closed, but the payment is successful, an internal refund is initiated and the money is refunded to the user.
There could be an internal scheduled task that would periodically scan if the payment order was closed but the payment was successful, and then issue a refund order.
The last
Finally, I will use mind mapping to summarize the exceptions that the payment system may encounter.
Historical payment system related articles
- Money collection artifact! The principle of interpretation of polymerization of yards behind the original |
- How does it work when you can still pay when your phone has no Internet? | original
- Don’t you want to know the principle behind the payment code? | original
- Evolution of payment channel routing system
- Design a reconciliation system from scratch