Regarding the WeChat H5 public account payment we step on (get_brand_wcpay_request: fail ),

Regarding the H5 public account payment we step on (get_brand_wcpay_request: fail ),

Recently, the company has a new demand that students have to ask their parents or friends to pay for their lessons. In this case, I first think of H5 payment (the built-in browser calls the payment module ). The reason why I wanted to pay for it was that the front-end code was very simple ..
However, it is precisely because you have chosen this method that has left yourself in trouble for two consecutive days.
Below is the body and code
First, let's take a look at the H5 Payment document description.

It's easy for new users or children's shoes that have been written to pay for it. The input parameters and descriptions are clear at a glance. But the premise of H5 payment is very important, that is, the user's openid is required. Otherwise, when you call the unified order (where the transaction type: trade_type = JSAPI) they will return the openid parameter you said it is true. Where can we find this parameter?
I directly searched for some materials and posted them to you;
As far as I know, there are two methods:
1. OAuth webpage authorization. You can activate OAuth webpage authorization in the background of the public account. When you perform authorization on the webpage, you will get your openid
2. access the server. Allow access servers for development. After the access server is configured (see the development documentation), all messages sent to the Public Account are forwarded to your server in an xml form.
I am using the first method, which is actually very simple. You can refer to the demoH5demo
See the GetOpenid method in example/WxPay. JsApiPay. php.
In this way, you can obtain the openid and then call the unified order interface. If there are other problems, you can log to see the returned error. Generally, the returned error in this area is obvious and it is easy to find the cause. The most pitfall is the type of future errors.
We can see that after the unified interface is successfully called, these items will be returned.

 

From the results, we can easily see that we have all the parameters in the demo that calls the payment, including the sign signature (this is a pitfall ). In this case, we only need to return these parameters to the client and directly combine the data.
At this point, we return the data to the client. The client combines the data as follows:

After testing, we found that. The returned result is a failed payment signature verification. Generally, get_brand_wcpay_request: fail will be returned for the common error type. At this time, I checked the document again. The timestamp is ten, and the js method is 13-bit accurate to millisecond. So I cut the string and got ten timestamps, at this time, the test is still the same as the error. So I calmed down slowly. Began to query information online. Find the problem? The answer on the internet is generally about the payment authorization directory, which I have already set up. No problem. So I once again picked up his official document and reviewed it again with their demo. In the original document, only the package parameter contains the data returned by the unified order. It is a Chinese culture that is profound and profound, playing a text game.
So I guess the sign returned by the unified interface cannot use the building. The so-called sign is to uniformly generate the result returned by the order with md5 again?
I can only test and verify my conclusion. Not to mention, post code

 

This set of Code is based on the instructions in the document after I return the results from the unified order (case-insensitive), re-generate the sign, and then return the client, including the timestamp. In this case, test again, and it will not report get_brand_wcpay_request: fail. It will report another error to me, prompting me to say that the current page is registered, and the url is popped up (this step, if the shoes are set in the public number. If you have entered the payment-> payment authorization directory), there should be no other problems. Can be ignored.
Basically, H5's built-in browser calls the payment module. The main pitfall lies in signatures. The returned error types are the most common and cannot be quickly located.

Source code free: http://www.jinhusns.com/Products/Download