首先=按文档中业务流程和开发步骤接入，按照文档流程排查；如果还有问题，需要按以下环节排查：

#

1、统一下单返回是否正常（后面步骤都用到了这个接口的appid，mchid，prepayid，看参数是否匹配）

#

2、第二次签名过程是否正确（此步骤商户一定要严格按文档的参数列表来做签名，提醒商户用签名工具做校验）

#

2.1、此处涉及一个细节：该接口没有sign_type参数，如果统一下单用的HMAC-SHA256签名，本步骤也必须按HMAC-SHA256；

#

2.2、本次签名的参数列表要跟文档完全匹配：大小写要一致，参数值要与统一下单接口的保持一致，特别注意参数名：partnerid，取值为mchid（开平SDK历史原因，无法改名）

#

2.3、本步骤生成的sign与统一下单的不是同一个，经常有商户直接传同统一下单接口的sign过来

#

3、检查客户端调用sendReq（PayReq）对象赋值的正确性（必要时让商户提供数据），有一种情况是商户会通过异步获取到后台数据，比如data对象是通过异步请求得到的对象：request.appId = data.appid; 实际appid属性值为空，

#

4、 检查配置

#

4.1、 Android要求在开放平台后台配置正确的应用签名和包名，可以引导商户提供配置截图

#

4.2、 IOS则不需要在开平配置，而是要求商户在开发环境红配置正确的URLSchemes为对应APPID

keytool -list -v -keystore my-release-key.keystore

证书指纹:

MD5:  A6:6C:59:13:B4:AF:FF:**************

SHA1: B3:A3:63:4E:DF:AC:**************

SHA256: 0D:41:93:BC:19:C7*******************

签名算法名称: SHA256withRSA

主体公共密钥算法: 2048 位 RSA 密钥

版本: 3