I have always used .net as the priority development platform, and of course I used xamarin when making APPs.
The biggest headache is that inPay must be used for recharge or APP functions on iOS. However, inPay cannot be used on Android in China, and only Alipay and WeChat payment can be used.
Finally, I settled on Alipay and inPay for ios. WeChat applied for a merchant account, developer platform, and various certifications. It cost 300 for the merchant account and 300 for the developer certification. I find it very confusing. The content of the same authentication type is the same, but the account number is different. The developer platform cannot use the merchant's login account and needs to use a new one. It’s a clear money trap, and the structure is messy, including the WeChat merchant platform, developer platform, and public account platform. There is no SSO (single sign-on). If I personally think it is a professional point of view, it is really bad, or this way I can charge more money. Then the APPID of the developer platform and the APPID of the official account can easily confuse beginners. The merchant account must be bound to the APPID of the developer platform, and the developer platform APP must be reviewed (7 working days), and then applied for payment and certification. (It also takes 1-2 working days), bind after authentication, and then open the payment permission on the merchant platform, where the APP will be reviewed again (1-3 working days). It's been like this for half a month.
As the saying goes, one flagship product can support the whole family. The ubiquity of WeChat makes it a must-choice for domestic developers. If it were not a must-choice, I would prefer Alipay.
Enough talking nonsense, let’s talk about the pitfalls:
xamarin binds the latest sdk. The DLL has been compiled, and the jar binding library is very simple. You can find it by searching online.
Attached download:https://download.csdn.net/download/Jockey/12411683
APP WeChat payment requires the use of "unified payment ordering". This is easy to understand, that is, regardless of APP, WEB, mini program, or public account, this prepayment order API is used.
C# quotes an official SDK, and then simply changes the APPID, commercial ID, apiKey, and key. Then call the signature method and successfully generate the order data after post application.
The returned data is then used as the following information
public static string SecSign(string prepayid, string noncestr,string timestamp)
{
//二次签名
Dictionary<string, string> parameters1 = new Dictionary<string, string>();
parameters1.Add("appid", AppId);//开发者平台的APPID
parameters1.Add("partnerid", PartnerId);//商户ID
parameters1.Add("prepayid", prepayid);//刚才生成的预付订单的ID
parameters1.Add("noncestr", noncestr);//刚才请求预付订单的随机值(不能新产生的)
parameters1.Add("timestamp", timestamp);//时间截
parameters1.Add("package", "Sign=WXPay");
string content = GetSignContent(parameters1);
//，在stringA最后拼接上key得到stringSignTemp字符串，并对stringSignTemp进行MD5运算，再将得到的字符串所有字符转换为大写，得到sign值signValue。
//stringSignTemp=stringA+"&key=192006250b4c09247ec02edce69f6a2d" //注：key为商户平台设置的密钥key
string signResult =Xamarin.AppFramework.Helpers.CryptHelper.GetMD5(content + "&key=" + outkey).ToUpper();
return signResult;
}Note that the MD5 signature is used here.
then directly
bool torf = wxApi.SendReq(payReq); The call returned here is true
, and then in the callback class
public void OnResp(BaseResp resp)
{
int rel= resp.MyErrCode;//返回-1
}
After checking a lot of information on the Internet,
1. Appid and merchant ID are set incorrectly
2. APIKEY setting error
3. NonceStr must be consistent with when applying for prepayment
4. Wrong package name and signature (can be viewed and modified on the developer platform)
5. After the first signature error in WeChat Pay was cached, the wrong signature was used until the cache was cleared.
I checked and found out that I used the release package when I submitted it to the developer platform for review, so the signature was wrong. I changed it back. Retry.
Still -1. . . . Nima. . .
Is it an old cache problem? Well, back up the chat history first. I went to sleep during the backup and didn't care about processing it tomorrow. .
Deleted WeChat.
After reinstalling WeChat, try again.
Still returns -1
. . . . . . . I repeatedly checked everything for errors and debugged it several times, but no mistakes were made.
well. . . Let’s take a look at the official documentation. From the unified order API to the APP outbound API, we finally saw the problem.
The official was kind enough to use red letters.
I checked and found that my prepaid signature uses sha256 (quoting the official WeChat SDK). Then the payment calling code uses MD5, damn. Vomiting blood.
Because I was too lazy, I found the code on the Internet and modified it before using it. Blame yourself for being careless.
Changed back to using sha256 for signature and successfully called.
Reference for the above code:https://blog.csdn.net/qq_21121397/article/details/89308563
If you did not use MD5 when requesting a prepaid order, be sure to change it back.
If I hadn't asked you to check it all day.
Can’t WeChat’s backend be more user-friendly? Don't just return -1. The lengths of the signatures generated based on sha256 and md5 are different. When returning, you cannot be reminded: Please check whether the prepayment signature and APP payment signature types are consistent. This cost 600 yuan, but I still couldn't get a single humanized reminder.