No.
The signature at V2 interface is MD5 or HMAC-SHA256, and the signature at V3 interface is asymmetric key SHA256-RSA.
The WeChat Pay callback contains the following four HTTP headers in the HTTP header:
1、Wechatpay-Timestamp
2、Wechatpay-Nonce
3、Wechatpay-Singature
4、Wechatpay-Serial Some proxy servers or CDN service providers will "filter" the HTTP headers of WeChat Pay extensions when forwarding, causing the application layer of signature verification to fail to obtain the signature information of WeChat Pay.
In that case, merchants should adjust the proxy server configuration or accept WeChat Pay callbacks through direct connection.
The error is caused by the wrongly set basic rules.
Both Accept and User-Agent need to be set.
1. Please refer to the following to set up Accept setting:
Content-Type: application/json Accept: The application/ json
2. Refer to the following tips for the setting of User-Agent:
HTTP agreement requires the requesting client to use User-Agent in the HTTP header to identify itself in each request. WeChat Pay recommends that the caller choose one of the following two methods:
A. Use the default User-Agent of the HTTP client.
B. Follow the HTTP agreement, and use the name and version of the system and application to form the unique User-Agent.
Note:
1. The error only exists in the V3 interface.
2. WeChat Pay API V3 is likely to refuse to process requests without User-Agent.
We recommend using the SDK provided by WeChat Pay. You can also view the sample codes in the following programming languages.
/**
* 获取私钥。
*
* @param filename 私钥文件路径 (required)
* @return 私钥对象
*/
public static PrivateKey getPrivateKey(String filename) throws IOException {
String content = new String(Files.readAllBytes(Paths.get(filename)), "utf-8");
try {
String privateKey = content.replace("-----BEGIN PRIVATE KEY-----", "")
.replace("-----END PRIVATE KEY-----", "")
.replaceAll("\\s+", "");
KeyFactory kf = KeyFactory.getInstance("RSA");
return kf.generatePrivate(
new PKCS8EncodedKeySpec(Base64.getDecoder().decode(privateKey)));
} catch (NoSuchAlgorithmException e) {
throw new RuntimeException("当前Java环境不支持RSA", e);
} catch (InvalidKeySpecException e) {
throw new RuntimeException("无效的密钥格式");
}
}
Please find the cause of the error and the corresponding solution in the table below according to the message.
Error description | Cause | Solution |
---|---|---|
The merchant has not set an APIv3 key. | The merchant has not set an APIv3 key | Please log in to the merchant platform to set an APIv3 key |
The merchant has not applied for a certificate. | The merchant has not applied for an API certificate | Please refer to Private key and certificate |
The merchant certificate serial number is incorrect. | A wrong merchant certificate was used, or a merchant certificate that has expired was used, or the serial number of the obtained merchant certificate is incorrect. | Please check the merchant certificate. You can log in to the merchant platform to view the correct certificate serial number. |
The merchant certificate has expired. | Expired merchant certificate and private key were used. | Please log in to the merchant platform to renew the certificate for use. |
The merchant certificate has been invalidated. | The merchant certificate and private key invalidated by the merchant owner are used. | Please log in to the merchant platform to apply for the certificate again, and use the new certificate. |
Verification failed due to wrong signature. | A wrong merchant private key was used, or the signature string was incorrectly constructed. | See the next question. |
Http header Authorization value format error | The Authorization header is missing, or its format is incorrect. | Please check the Authorization sent. |
Http header Authorization authentication type is incorrect. | The signature algorithm declared in Authorization is not supported. | Please check the Authorization sent. Currently, it only supports WECHATPAY2-SHA256-RSA2048. |
The timestamp in the Http header Authorization and the time for initiating the request must not exceed 5 minutes | The time indicated by the timestamp in the Authorization header is more than 5 minutes away from the current time. | Please check whether the system time is accurate, or whether the logic for obtaining the time is correct. |
The certificate has been replaced. Please use the new certificate. | The merchant reapplied for a merchant API certificate. | Please use the new merchant API certificate. |
In order to help developers locate the error, we will add the verification information to the error detail detail of the response when there is a verification failure. The verification information is a variety of information we request Constructing a signature stringbased on the merchant's HTTP.
1. Method
, HTTP request method
2. Url
, requested URL
3. Truncated_sign_message
, the signature string used during WeChat Pay verification (the line break is displayed as \n). For easy viewing, we truncated the body of the final request message.
4. sign_message_length
, byte length of the signature string used in WeChat Pay verification
{
"code": "SIGN_ERROR",
"message": "Verification failed due to wrong signature",
"detail": {
"field": "signature",
"issue": "sign not match",
"location": "authorization",
"sign_information": {
"method": "GET",
"url": "/payscore/user-service-state?service_id=500001&appid=wxeaf7bf1de621b0c2&openid=oWm9Z5JQwgV7BKAQUeKsUMVSjTpQ",
"truncated_sign_message": "GET\n/payscore/user-service-state?service_id=500001&appid=wxeaf7bf1de621b0c2&openid=oWm9Z5JQwgV7BKAQUeKsUMVSjTpQ\n1559194069\n18a427e78d2344e1a71156a2690cc4d6\n\n",
"sign_message_length": 157
}
}
}
We recommend that developers export the signature string they have assembled and the byte length of the signature string in the debugging information in the program, and carefully compare the verification information returned by WeChat Pay to check for the following common errors:
No line break character added to the last line of the signature string
If the body of the request message is empty (such as a GET request), the last line should be a line break character.
The parameters in the signature string are inconsistent with the actual requested parameters.
The manually spliced URL is inconsistent with the actual request sent. We recommend using the HTTP library to construct the request object or URL object, then use the corresponding method to obtain the URL.
Two timestamps generated at different time were used when you sign and set the Authorization header.
Two different random strings generated at different time were used when you sign and set the Authorization header.
The JSON strings serialized at different time were used as the request subject during signing and request.
Inconsistent text encoding
The generated signature string uses non-UTF-8 encoding or no specific encoding is set.
Wrong signature string construction sequence
The signature string was not constructed in the order required by the document.
Wrong merchant private key
Developers can use the following openssl command to check whether the private key and the modulus (the product of the two large prime numbers p and q) in the merchant certificate are consistent. If yes, the private key and certificate are paired.
$ openssl x509 -noout -modulus -in 1900009191_20180326_cert.pem
Modulus=C6D43C87B991...
$ openssl rsa -noout -modulus -in 1900009191_20180326_key.pem
Modulus=C6D43C87B991...
The callback of WeChat Pay contains the following four HTTP headers in the HTTP header:
1. Wechatpay-Timestamp
2. Wechatpay-Nonce
3. Wechatpay-Signature
4. Wechatpay-Serial
Some proxy servers or CDN service providers will "filter" the HTTP headers of WeChat Pay extensions when forwarding, causing the application layer of signature verification to fail to obtain the signature information of WeChat Pay. In that case, merchants should adjust the proxy server configuration or accept WeChat Pay callbacks through direct connection.
Customer Service Tel
Business Development
9:00-18:00
Monday-Friday GMT+8
Technical Support
WeChat Pay Global
ICP证