preface

Recently, due to business requirements, it is necessary to develop the payment code function. The bottom layer of this interface will aggregate the payment code function of mainstream wallet apps in the market, such as wechat Pay and Alipay Pay.

Ps: There are many nicknames for payment code payment. For example, the payment product of wechat Payment end is payment code payment (the previous document is called payment by swiping card), while the payment product of Alipay end is in-person payment – article payment, and some documents will become qr code payment by scanning.

The definition method of wechat is used in the following paragraphs and is collectively referred to as payment code.

It may sound strange to some students to pay by payment code. In fact, we may use this function every day.

For example, we buy breakfast at the convenience store and use Alipay/wechat to pay when we finally settle the bill. The cashier will ask us to show the Alipay/wechat payment code, then use the scanning gun to get the code, and finally send it to the wechat/Alipay server to complete a deduction.

Taking Alipay as an example, the specific client payment process is as follows:

Payment code payment background call process is as follows:

Payment code Payment details process

Wechat/Alipay payment code payment call process is much the same, the official website is relatively clear, here directly use alipay’s official website process.

As can be seen from the above process, payment code payment can be said to be a synchronous interface, that is, the interface synchronously returns the result of deduction, without obtaining the result through another asynchronous notification.

However, we need to note that due to security risk control and other issues, the user may need to enter the password to confirm the payment during the payment code payment process, and then the payment code interface will return to wait for the user to pay.

Ensure that the returned information is correct. If the following output is displayed, the user is entering a password.

  • Wechat pay: err_code= userventure or err_code=SYSTEMERROR
  • Alipay: Code =10003 or code=20000

Wechat payment code payment in the following cases need to enter the password for second confirmation.

Relevant rules have not been found in the official document of Alipay. After testing, if the payment amount is greater than 2000, the password needs to be entered. If you are familiar with other rules, you can leave a message in the comments section.

Another point to note is that wechat/Alipay other payment interface, after the payment is successful, wechat/Alipay server will send a message to inform the payment result. But the payment code is different, the interface is not notified of the message.

Therefore, if the payment code returns waiting for the user to enter the password, the merchant background service must periodically call the wechat Pay/Alipay query interface to obtain the payment result.

Cancel the payment

If within a period of time, for example, 30 seconds, the payment results of the polling query will be returned waiting for the user to pay, or the payment transaction process will fail or the payment system will time out. In both cases, the official documents suggest to call the undo interface immediately to cancel the transaction.

If the order user fails to pay, the cancel interface will close the order. If the user pays successfully, the cancel interface will refund the order funds to the user.

That is, the cancel payment interface is functionally equivalent to closing an order plus a refund. Although revocation also has the function of refund, there is a big difference between the two:

Restrictions on payment types

Wechat/Alipay cancel payment can only cancel orders of payment code type, while refund can support orders of multiple payment types.

The refund amount

The undo interface can only be a full refund, and the refund interface supports the incoming amount, which can be a full refund or a partial refund.

The time limit

The cancellation interface has a short time limit. For example, wechat Pay can cancel orders within 7 days, while Alipay can only cancel orders on the same day.

However, the refund interface can support the refund of orders over a longer period of time. For example, wechat Pay supports the refund of orders within one year, while Alipay only supports orders within three months.

Based on the above differences, the refund interface should be invoked for other normal payment orders to achieve the same function. The official documents suggest that the refund interface be invoked only in abnormal cases.

In addition, some places this functional interface is called the positive interface, such as the following industrial and commercial TWO-DIMENSIONAL code payment.

In fact, the function provided is similar to wechat/Alipay cancellation, which requires payment companies to provide documents for specific research.

Revocation of payment related issues

Due to the cancellation of payment, it may lead to refund or the order may be closed. Before access, some problems have been unclear, and no information has been found in the official documents, so we have no choice but to test and verify relevant problems.

Due to regulations, payment institutions cannot directly connect to wechat/Alipay, so the following test is based on unionPay wechat/Alipay channel.

Unionpay offers a slightly different interface to direct wechat/Alipay, but the main functions are the same.

Repeat to cancel

The test results show that wechat/Alipay revocation interface is idempotent, and repeated revocation returns consistent results.

However, it is important to note that you need to judge the undo result correctly.

For example, to judge the success of wechat’s revocation interface, we also need to combine recall field, and Alipay also has a similar field.

The order status

Wechat/Alipay order status processing is not consistent, wechat order status is complicated:

That is, once the payment code order is successfully REVOKED, the status will be returned to REVOKED (REVOKED) when the order is queried again.

In addition, wechat has restrictions on payment orders with payment code, so the order cannot be CLOSED by invoking the order closure interface. Therefore, in the scenario of payment code, there is no order status CLOSED — CLOSED.

Next, let’s talk about the status of Alipay. Alipay document does not provide similar order status machine. I summarize the following order status chart according to some official documents and some test results.

Therefore, once the payment code order of Alipay is cancelled successfully, the TRADE_CLOSED will be returned when the original order status is queried again.

Reconciliation file data

After the transaction occurred on that day, we need to take the wechat/Alipay reconciliation files the next day and check the data one by one to prevent the problem of less accounts and more accounts.

The reconciliation design process can refer to the previous article:

Talk about the design of the reconciliation system

The wechat/Alipay reconciliation document will only record orders that have been successfully traded, so the cancellation of unpaid orders will not appear in the reconciliation document. However, if the payment is successful and then cancelled successfully, two records will be generated in the reconciliation file, one positive transaction and one reverse refund record.

It is easy to identify the records of normal transactions and ordinary refunds. Generally, the order number sent by us to wechat Alipay can be used. However, the revocation leads to the refund record, which cannot be identified by only one tracking number. We need to distinguish and judge by combining other fields.

The wechat reconciliation file is REVOKED to generate the refund, and the transaction status is REVOKED, so we can use the merchant order number plus the transaction status to identify whether a record is REVOKED to generate the refund record.

The above unionPay order number can be regarded as the order number generated internally by wechat Alipay

The checking files of Alipay are troublesome, and the refund records generated by the cancellation cannot be distinguished from wechat according to the transaction status. It can be seen from the reconciliation file that the refund generated by Alipay cancellation is the same as the refund record generated by ordinary refund interface.

A careful study of the reconciliation file can find some differences. The refund batch caused by the cancellation record is consistent with the internal order number of alipay that is being transacted. And the normal refund record, the refund batch number is sent by the merchant himself. So we can screen out the refund records generated by the cancellation.

Revocation of failure

In extreme cases, it is possible to create a bizarre situation where undo fails several times. What about that?

In this case, there is no need to consider the direction of automatic system processing, through offline manual intervention processing, after all, this probability is too low. Quote a sentence in the article of Zhihu **@ Tianshun ** :

A lot of times it’s more efficient and less costly to have manual assurance than to have to figure out how the exception in the exception is handled automatically, right

This sentence we carefully product, more product more sense!

Reference

How does asynchronous notification determine which refund transaction corresponds to

Reconciliation and refund

The retry_flag field description of the interface is revoked

The difference between refund interface, close interface and undo interface

One last word (thumbs up)

Payment code payment access is actually relatively simple. The main difficulty is the transformation of the existing system after the introduction of revocation interface. For example, after the revocation of a successful order, should we directly modify the successful state of the original order to the revocation state, or create another revocation record? There is also the reconciliation system when checking, the peer record may be more than the local end, how to check? These questions must be combined with the existing system after access to think about.

Finally, there are some omissions in the article. If you find them, you can point them out in the comments section. Thank you for your support.

If you are also engaged in payment, or docking payment, welcome to add my wechat, discuss problems together, grow together ~

Welcome to pay attention to my public account: procedures to get daily dry goods push. If you are interested in my topics, you can also follow my blog: studyidea.cn