微信公众号/小程序支付

初始化JSAPI请求，通过生成token_id来进行交互验证。

请求：后台请求交互模式返回结果+通知：后台请求交互模式+后台通知交互模式

POSTXML内容体进行请求

数据按XML的格式实时返回

初始化JSAPI请求，通过生成token_id来进行交互验证。如调用时是用的原生态js支付，此接口可以忽略

…后台通过notify_url通知商户，商户做业务处理后，需要以字符串的形式反馈处理结果，内容如下：

采用HTTP标准的POST协议，为了保证接收方接收数据正确,传输数据必须签名。

pay.weixin.jspay100010000100adf880d5c8986bd0deb6423c92c9d9481406046836127.0.0.11XML数据格式采用标准XML协议，所有参数只存在一级节点中，不采用多级节点嵌套。协议级错误返回：

500正确返回数据：

0010业务级错误返回：

01一般有返回有status参数，0表示调用成功；非0表示调用失败。

为了保证数据传输过程中的数据真实性和完整性，我们需要对数据进行数字签名，在接收签名数据之后进行签名校验。数字签名有两个步骤，先按一定规则拼接要签名的原始串，再选择具体的算法和密钥计算出签名结果。一般失败的结果不签名。

无论是请求还是应答，签名原始串按以下方式组装成字符串：1、除sign字段外，所有参数按照字段名的ascii码从小到大排序后使用QueryString的格式（即key1=value1&key2=value2…）拼接而成，空值不传递，不参与签名组串。2、签名原始串中，字段名和字段值都采用原始值，不进行URLEncode。3、…返回的应答或通知消息可能会由于升级增加参数，请验证应答签名时注意允许这种情况。举例：调用某个接口，接口有如下字段：

注意：对后台通知交互模式，如果…收到商户的应答不是“success”或超时，…认为通知失败，…会通过一定的策略（通知频率为15/15/30/180/1800/1800/1800/1800/3600，单位：秒）定期重新发起通知，尽可能提高通知的成功率，但…不保证通知最终能成功。由于存在重新发送后台通知的情况，因此同样的通知可能会多次发送给商户系统。商户系统必须能够正确处理重复的通知。推荐的做法是，当收到通知进行处理时，首先检查对应业务数据的状态，判断该通知是否已经处理过，如果没有处理过再进行处理，如果处理过直接返回“success”。在对业务数据进行状态检查和处理之前，要采用数据锁进行并发控制，以避免函数重入造成的数据混乱。

商户订单支付失败需要生成新单号重新发起支付，要对原订单号调用关单，避免重复支付；系统下单后，用户支付超时，系统退出不再受理，避免用户继续，请调用关单接口。