When the wind blows, the clouds are flying, and an de Meng Shi walks everywhere. BUG, you have to change it at any time. If you don't change it, you can't. think about it. When you're alone, you can't use it when you eat hot pot and sing songs after work!
This paper sorts out the wechat applet Wx The requestpayment reported an error or did not respond. Error reporting information and answers are mostly sorted out in [wechat development community]. This article is only for sorting. ( https://developers.weixin.qq.com/community/develop/mixflow)
1, Error reporting
Question 1:

requestPayment:fail no permission

terms of settlement:
1. Restart the project and try again.
2. check appID，If consistent, try copying and pasting again

Question 2:

requestPayment:fail jsapi has no permission
// Both development and experience versions can be paid, but not the official version

terms of settlement:
ios The payment is restricted by the platform and the appeal is completed

Question 3:

requestPayment:fail Payment verification signature failed

terms of settlement:
1. When signing, you need to contact appId(I Capitalize)Sign together because you're calling requestPayment Interface does not need to be passed in appId
2. The signature problem is generally that your signature parameters do not meet the document specifications, case. Escape, sort. And so on must fully comply with the specifications. Confirm that the parameters are correct and can be replaced KEY. There is also parameter coding, which may cause garbled code. Pay attention to coding UTF8

Question 4:

After the video Number jumps into the applet, when placing an order in the applet, call wx.requestPayment()When paying, the payment fails all the time

terms of settlement:
If you enter the applet to place an order through the video number, you need to first push the commodity for approval and call wx.requestOrderPayment()Make payment.
If the search enters the applet, it can be called normally wx.requestPayment()

Question 5

requestPayment:fail parameter error: parameter.noner.paySign should be String instead of Undefined

Needless to say, it takes a total of paySign,timeStamp,nonceStr,package,signType Five parameters. Each parameter must be a string, not a string null and undefined. If you report this error, you will console Check the parameters.

Question 6

APP Transfer up payment return:-1

Solution (official response):
1,[Using the signature check tool](https://pay.weixin.qq.com/wiki/doc/api/micropay.php?chapter=20_1) Check whether the signature algorithm is wrong

2,Confirm whether the secret key is correct (the service provider mode uses the secret key of the service provider's account number, which is configured on the merchant platform. If the same merchant number calls other interfaces successfully, it can be ruled out that it is the secret key problem)

3,Confirm that the actual request parameters of the interface are consistent with the parameters of the original signature string, and the parameters cannot be added or missing (you can check by printing the original signature string)

4,Confirm the case of the parameter, and the parameter name is consistent with the interface document

5,The parameter value of the original signature string uses the original value, which is not required encode

6,The interface needs to be used UTF-8 code

7,IOS If Android is normal or abnormal, please check the package name and package signature

8,unregistered APPID

9,Project settings APPID incorrect

10,Registered APPID Does not match the setting

11,Under the mode of service provider, the in the unified order sub_appid Whether there is incoming

12,"Whether the signature type in "unified payment interface" is consistent with that in "unified order interface"

Well, this is a common error reporting problem sorted out temporarily. Let's talk about the fairy problem I encountered.

2, No response

Let's talk about how unresponsive

Model: iPhone 8, 12, 13
System: Unlimited
Scenario: users click on payment, call pre payment, and get wx.. Requestpayment, no response
Look at the code

...
let data = res.data.data;
try {
  console.log(data); // normal print
  wx.requestPayment({
    timeStamp: data.timeStamp,
    nonceStr: data.nonceStr,
    package: data.package,
    signType: 'MD5',
    paySign: data.paySign,
    success (res) { 
    	// No response
    },
    fail (res) {
		// No response
    },
    complete(res) {
    	// No response
    }
  })
} catch (err) {
  // No error reporting
  console.log(err)
} finally {
  console.log('Yes'); // Normal execution
}

This payment code has been running stably for three years and has never had any problems, so it was not considered in the code at the beginning. It was suspected that other departments had changed the configuration items. After checking, it was no problem. It was also suspected that it was the problem of v2 and v3 versions. I urgently wrote the demo of v3 and found that it could not be called.

Therefore, it is suspected that it is not a configuration item or background code problem. Start checking the front-end code. Delete the code one method by one to see which method will affect the payment. Finally,

onUnload: function () {
  for (let timer = 0; timer < 1000; timer++) {
    clearInterval(timer)
  }
},

Because there are a lot of timers in the order list, I wrote this code 3 years ago to clear the timer 1000 times when the page is unloaded.

After deleting this code, the applet can pay normally, so it feels like some methods at the bottom of the wechat applet are blocked when clearing the timer.

Now the new wording has been changed:

let setIntervals = {}; 
setIntervals[`${id}`] = setInterval(() => {
...
...
onUnload: function () {
   for(var each in setTimeOuts){
     clearInterval(setTimeOuts[each]);
   }
},

In this way, the timer can be deleted correctly, and wechat payment is not abnormal.

Now I finally paid the price for my youth.
End, sprinkle flowers!