首页  >  文章  >  后端开发  >  支付宝接口回调处理问题?

支付宝接口回调处理问题?

WBOY
WBOY原创
2016-12-01 00:56:461632浏览

网站集成支付宝接口进行订单支付和会员余额充值,订单支付因为提前生成有订单没什么疑问,但我做余额充值的时候,提交请求到支付宝的这个时候,要不要把生成的订单请求数据先存入数据库,然后在支付宝的回调return和notify中进行订单处理,改变会员余额,但这样的话如果会员提交充值,没有完成支付的话,会产生很多无用的单。

如果是会员提交请求的时候,不存订单信息,直接在回调同步异步函数中判断支付成功,存充值记录和改会员余额,这样有没有安全隐患,我看了支付宝的接口文档,“商户需要验证该通知数据中的out_trade_no是否为商户系统中创建的订单号,并判断total_fee是否确实为该订单的实际金额(即商户订单创建时的金额)”这样的话我就做不了这样的操作,

请做过的大神给个意见,非常感谢!!!

回复内容:

网站集成支付宝接口进行订单支付和会员余额充值,订单支付因为提前生成有订单没什么疑问,但我做余额充值的时候,提交请求到支付宝的这个时候,要不要把生成的订单请求数据先存入数据库,然后在支付宝的回调return和notify中进行订单处理,改变会员余额,但这样的话如果会员提交充值,没有完成支付的话,会产生很多无用的单。

如果是会员提交请求的时候,不存订单信息,直接在回调同步异步函数中判断支付成功,存充值记录和改会员余额,这样有没有安全隐患,我看了支付宝的接口文档,“商户需要验证该通知数据中的out_trade_no是否为商户系统中创建的订单号,并判断total_fee是否确实为该订单的实际金额(即商户订单创建时的金额)”这样的话我就做不了这样的操作,

请做过的大神给个意见,非常感谢!!!

当然要提交时就保存订单, 那几笔"无用"的单难道比可靠性更重要么

额外举一个好处, 你们还可以根据你认为的"无用"的单和实际支付的单的比例来看这个支付的流失率, 为支付流程优化做准备和参考数据

你开始的方案是正确的

声明:
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn