background

Generally, companies have relevant requirements for accessing Alipay and wechat Payment. Here are some points encountered in the access process

Wechat Pay access

The development document of wechat Pay is at this address, which mainly includes payment code payment, JSAPI payment, Native payment, APP payment, H5 payment, mini program payment, facial payment and so on. So far, I have come into contact with four kinds of payment, including JSAPI payment, Native payment, APP payment and H5 payment. Therefore, I will mainly talk about the differences between these four kinds of payment and the other kinds are basically similar.

Before access, you can first apply for relevant account parameters, generally a merchant number corresponding to different applications and related keys. For specific application procedures, you can refer to the payment account section in the document, taking small programs as an example

General content

For the above payment scenarios, basically wechat’s payment process API is similar, so we will start from general.

You can view it by watching the API list of the corresponding payment type, and you can take the seat with the corresponding number. There are many contents involved, such as placing a unified order, querying an order, closing an order, applying for refund, querying a refund, and notification of payment results.

Applet payment except the difference in the figure below, the rest can be understood as JSAPI payment, related address

Unified order

For details, please refer to relevant documents according to the service type for access ([wechat Pay – Development document][wechat])

1. API differences between orders

In addition to the payment code and brush face payment (not in the scope of this article, after talked about do not contain), the rest of the payment request API is https://api.mch.weixin.qq.com/pay/unifiedorder

The main difference lies in the transaction type [trade_type] of one of the pass parameter fields, whose corresponding relationship is as follows: JSAPI–JSAPI payment (or small program payment), NATIVE– NATIVE payment, APP– APP payment, and MWEB–H5 payment

In the middle, H5 pay is no spare domain name of the API documentation, and the other three (JSAPI, NATIVE, APP) standby domain name https://api2.mch.weixin.qq.com/pay/unifiedorder (secondary domain name)

2. Differences in recharge parameters

The H5 payment parameters differ from the rest in the required scene information field in the document parameters

According to my understanding, the unified order of payment can be understood as the following three types:

  1. JSAPI, APP, NATIVE Payment – basically the same except for different transaction types
  2. H5 payment – Similar to the first one, note that the scenario information parameter is mandatory
  3. Others – Payment code payment, face payment

Query order

Query the contents of the order, different payment types are the same. The application scenarios are as follows:

  • When the merchant background, network and server are abnormal, the merchant system does not receive the payment notice
  • After invoking the payment interface, return system error or unknown transaction status
  • Call the paycode payment API to return the state of USERPAYING
  • Confirm the payment status before calling the closing order or revoking the API

Close the order

The closed orders of different payment types are basically the same, and the application scenarios are as follows:

  1. If a merchant fails to pay an order, it is necessary to generate a new order number to initiate payment again, and call the closing order against the original order number to avoid repeated payment
  2. After the system places an order, the user pays time out, and the system no longer accepts the exit, avoiding the user to continue

It should be noted that there is no alternate domain name for the mini program payment, and there are alternate domain names for the rest

Interface links: https://api.mch.weixin.qq.com/pay/closeorder URL: https://api2.mch.weixin.qq.com/pay/closeorder (see redundant across the city disaster backup domain name)Copy the code

To apply for a refund

A two-way certificate is required to apply for a refund

The interface address does not have an alternate domain name

Matters needing attention:

  1. Orders that have been traded for more than a year cannot be submitted for a refund
  2. Wechat Pay refund supports multiple refunds for a single transaction. For multiple refunds, the merchant order number of the original payment order should be submitted and different refund tracking number should be set. The total amount of refund cannot exceed the order amount. If a refund fails to be submitted again, please do not change the refund receipt number, please use the original merchant refund receipt number
  3. Request frequency limit: 150 QPS, that is, the number of normal refund requests shall not exceed 150 per second (error or invalid request frequency limit: 6 QPS, that is, the number of abnormal or incorrect refund requests shall not exceed 6 per second)
  4. The number of partial refunds for each paid order cannot exceed 50
  5. If the same user has multiple refunds, you are advised to refund the user in different batches to avoid refund failure caused by concurrent refunds
  6. The return of the refund application interface only represents the processing status of the service. You need to obtain the result of the refund query interface to check whether the refund is successful.

Notice of payment result

Payment callback is a key step to judge whether an order is completed or not. Completion does not mean receiving money for wechat, but notifying relevant business systems of subsequent operations after receiving the payment.

The notification link of payment results needs to be provided by the merchant. There is a notify_URL in the unified order interface, which corresponds to the address of wechat notification. Note that the callback address cannot carry parameters

The callback parameters of different payment methods, similar to unified order, can be distinguished according to trade_type **. If the order is confirmed, the return value specified by wechat should be returned

Note:

1. The same notification may be sent to the merchant system multiple times. The merchant system must be able to handle duplicate notifications correctly.

2. During the background notification interaction, if wechat receives the merchant’s response that does not meet the specifications or times out, wechat will judge that the notification has failed and resend the notification until it succeeds (In the case that the notification has not been successful, wechat will initiate multiple notifications altogether. Inform frequency for 15 s/s / 30/10 m/s / 3 m 20 30 30 m/m/m/m / 60 m / 3 h / 3 h / 3 h / 6 h/h – a total of 24 h4m), but not guarantee WeChat notification will succeed eventually.

3. In the case that the order status is unknown or the result of wechat Pay has not been notified, merchants are advised to call wechat Pay [Order Query API] to confirm the order status.

Special reminder:

1. The merchant system must conduct signature verification for the content of the notification of payment results, and verify whether the returned order amount is consistent with the order amount on the merchant side, so as to prevent “false notification” caused by data leakage and capital loss.

2. When receiving a notification, check the status of the corresponding service data to determine whether the notification has been processed. If the notification has not been processed, the result is successfully returned. Prior to state checking and processing of business data, use data locks for concurrency control to avoid data clutter caused by function reentry.

3. Technical personnel can log into wechat merchant background to scan and join the interface alarm group to obtain interface alarm information (there is a ruthless alarm robot to send relevant information).

Pay attention to callback notification

The JSAPI pay

According to the brief prompt information on the picture, we can know that the access mode is realized by calling the built-in method in wechat browser.

Single parameter:

​ trade_type – JSAPI

Native to pay

It can be simply understood as two-dimensional code payment. After placing an order successfully, you can obtain a link to the wechat protocol, such as: weixin://wxpay/ bizpayURL? Sr =123456, and then generate a TWO-DIMENSIONAL code for users to identify by scanning the code through wechat.

Two-dimensional code background knowledge introduction:

www.thonky.com/qr-code-tut…

Coolshell. Cn/articles / 10…

Single parameter:

​ trade_type – NATIVE

APP to pay

Single parameter:

​ trade_type – APP

H5 pay

Request payment for the wechat Pay scene in a mobile browser other than the wechat browser. Once the order has been placed, wechat will return a link through

Single parameter:

​ trade_type – JSAPI

Scene_info – required

The problem

1. The format of merchant parameters is incorrect

There are two possibilities for this:

  1. The merchant does not set the authorized domain name of H5
  2. The refer for H5 payment is empty, which can be skipped through a transfer page. If it is in the APP, it can be set manually in the WebView

2. To be added