支付异步回调地址只能设置一个如何解决 及 支付系统应付金额和实付金额不一致验证

支付异步回调地址只能设置一个如何解决

支付异步回调地址只能设置一个。但是在实际开发中，一个公司往往有好几个项目需要微信支付相关的业务，不同的项目有不同的域名解析。
多申请几个微信公众号显然过于浪费，且不利于财务的统一管理。

方法一： 异步回调地址通知到单独的微服务。在微服务中路由转发到不同的项目。 类似：代理模式。
多个项目共用一个回调地址，类似于现在的微服务。支付模块独立出来，其他的项目需要支付的请求这个接口。
这样做，一是业务逻辑变复杂，二是项目耦合性。支付的服务器挂了，所有的项目都不能支付。

方法二： 在接收到异步通知，主动发起查询接口。
主动查询订单。
在异步回调通知支付结果的下面，就有查询订单。主动查询订单的支付状态。这样异步回调就显得多余了。

方法三：在接收到异步通知，根据商户订单号解析或查询出来，该表记录的支付来源和支付环境（测试或生产），
在一个接收点判断需要转发到不同的支付服务中。类似方法一

支付环境如何区分
1.如果商户后台只允许设置一个回调地址，在项目开发测试阶段，配置测试环境的回调地址，是没有问题的。
但是一旦上线后，配置了生产的回调地址上线，这样测试环境如果再次测试支付，则无法收到回调通知。

2.比如微信和支付宝，在支付接口和退款接口都允许上送异步通知地址参数，这样优先以该地址来通知，能区分生产和测试环境。
1、异步通知发送地址错误
2、notify_url参数位置设置错误
3、异步地址设置错误
4、异步地址必须外网可访问
5、异步地址必须能post接收数据
6、接口默认不触发相关的交易状态数据通知

 

3.比如京东mp.store支付，支付可以上送异步通知地址，没有问题。退款方法没有该参数，就会出现一旦上线后，只配置了一个回调地址，则无法在测试环境收到异步通知的问题。
解决方法1：在生产环境的异步通知回调方法中，判断如果是测试的商户订单号，则分流转发到测试环境的回调通知地址。
解决方案2：在退款方法的时候，延时3秒发起主动查询结果，然后构建本地异步通知回调。保持流程的正常运行。

解决方案3：将生产和测试环境的商户号完全分离，这样就可以单独管理配置异步通知了。
或者比如支付宝的先享后付的，可以根据不同的创建的应用来区分。通过绑定的websocket方式来长连接接收消息。也可以分离开来。

 

4.支付异步通知回调参数中缺少金额，时间等，只返回了支付ID和支付状态？
1.为了系统数据的安全性，避免支付金额被篡改的情况下，应付金额和实付金额存在不一致的情况下，需要最终从异步通知中获取到真实的金额，
如果没有通知返回，则需要主动发起查询来获取。
然后在网关中比较 应付金额和实付金额 是否一致，如果不一致，则需要提前返回。认定为支付失败