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

#

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

#

四、类似问题

第一次app支付能成功，后面的每次都返回-1错误：遇到这种情况，分析思路：既然第一次能成功，从代码和API调用层面肯定是通的，根据第三节的步骤1，2，3应该都是对的。所以最可能的问题在第4个（实际原因：第一次后台未读取到客户端APP的部分信息，所以验证做了柔性通过验证，后面的严格验证，所以无法正常支付）