微信公众号，中链接到的h5页面需要 用到微信支付。
看到网上别人写的是，在java后端还需要写一个接口，供微信官方回调，以此通知支付结果给后端。不理解为何如此。毕竟在前端已经有 回调函数了。
onBridgeReady(payParam){
// 调起微信收银台，供用户输入支付密码
WeixinJSBridge.invoke('getBrandWCPayRequest',payParam,
function(res) {
if (res.err_msg == "get_brand_wcpay_request:ok") {
// 使用以上方式判断前端返回,微信团队郑重提示：
//res.err_msg将在用户支付成功后返回ok，但并不保证它绝对可靠。
}
});
},
因为前端js执行并不会100%成功，如刚好微信崩了这个单子就没发通知了，还得另外调用微信的接口获取订单状态。
而服务器端通知，如果微信收到商户的应答不符合规范或超时，微信会判定本次通知失败，会重新发送通知，直到成功为止（在通知一直不成功的情况下，微信总共会发起多次通知，通知频率为15s/15s/30s/3m/10m/20m/30m/30m/30m/60m/3h/3h/3h/6h/6h - 总计 24h4m）这里通知发送可能会多台服务器进行发送，且发送时间可能会在几秒内，但微信不保证通知最终一定能成功。
所以就算网络忙，总会有成功的。除非题主的服务器挂了那没得说了。
通过上面就清楚了为什么要服务器通知，前端通知只有一次机会，服务器端就可以有很多次尝试。
有帮助或启发麻烦点个采纳【本回答右上角】，谢谢~~
为了准。A调用微信支付B,假设A调用B成功，但是调用完A的网络断了，没有拿到B的回传信息，这种情况，对A来说，是不知道支付成功的。那么怎么能确定成功了呢？再通过接口拿一次结果。
类似的，B内部其实是一个微服务架构，支付模块只是其中的一个部分，假设为第三个部分网关、支付模块、银行接口，暂时标记为123,1调用2,2调用3都成功了，但是3返回给2的时候，网络断了，这个时候微信内部实时拿到的结果是不准确的，需要再通过接口拿一次。
那么为什么再拿一次就是准的呢？因为前面的微服务架构可能涉及多个模块，尤其还会涉及银行接口，再拿一次，不用走银行接口了也不用再走支付模块了，直接取的是微信持久化的结果，这部分的链条可以缩到很短，甚至只抓通知一节，延迟性大大降低，经过环境更少，准确性大大提高。
前端这次请求是到了微信服务器，微信服务器这次请求返回的信息也只是给到了你的前端，试问，有几个项目把数据库写在前端的。而且如果把数据返回给前端，非常容易被劫持数据。
前端负责的是展示，数据存储和逻辑处理在后端。
微信服务器再通知你的后端，是让你在这个接口中做支付成功的后续处理。而且这次回调给后端的数据会比前一次返回给你前端的多得多。
前端是前端，后端是后端。前端拿到的回调是前端的，后端拿到的是后端的。从应用层面上而言，前端拿到的回调是用户的回调，后端拿到的回调是商户端的回调。如果你商户端不写回调，那么用户支付成功了，你商户如何知道用户成功了呢？ 如果你选择说，前端拿到回调之后再给你，那么是不是代表着前端可以操作你的数据，用虚假数据来骗过后端。