分享接入支付宝支付时粗心遇到的两个小问题

首先说一下,支付宝支付时容易出现理解偏差的两个字段
分享接入支付宝支付时粗心遇到的两个小问题

一个是timeout_express
另一个是time_expire字段

timeout_express字段可以理解为,用户输入支付密码/或签约支付发起扣费,支付宝开始进行轮询用户可用支付方式的开始(好像支付宝收银台的话,如果用户欠费,会直接给打回来)

说一下,出现问题的两个场景

场景一:
使用的是支付宝收银台支付,送的字段是timeout_express,本以为此字段的意思为,后端产生送支付宝表单后过XXmin后给判定为超时的一个设置,就这样送了,没想到后来,接到客诉,用户支付成功,扣款成功,在咱们系统中却返回了失败。
经过排查可以看到,咱们这边送出的timeout_express字段,设置的是15min,之后,我们的系统设置了15分钟的异步查证,一直显示订单不存在,之后15分钟时,结束异步查证,判定最终结果为失败,但是,支付宝在1h2min的时候通知了系统,用户支付成功,由于订单已经处理为终态了,所以不做修改,造成了这个问题。
咨询小蚂哥才知道,这个timeout_express假设在收银台场景,代表的是用户正确输入密码支付宝受理这笔订单业务开始计时15分钟,在已签约支付宝代扣的业务情况下,则是轮询扣费的轮询定时时间,并不是之前臆想的,后端送的请求时间timestamp+timeout_express是过期时间。
这个用户可能就是停留在支付宝收银台页面1h后发起了支付,等支付宝通知的时候,我们的订单已经终态,不会再受理了。
所以后来建议使用的time_expire,这个参数是绝对超时时间,也就是支付宝在time_exipre时间点后,就不会对订单进行受理处理。所以在使用这两个字段前,注意自己的业务场景,看应该使用什么字段。

场景二:
先说一个支付宝枚举的状态设置

WAIT("WAIT_BUYER_PAY", "交易创建,等待买家付款"), //
CLOSED("TRADE_CLOSED", "未付款交易超时关闭,或支付完成后全额退款"), //
SUCCESS("TRADE_SUCCESS", "交易支付成功"), //
FINISHED("TRADE_FINISHED", "交易结束,不可退款");

支付宝签约代扣,同步请求返回的报文中会有状态码和业务返回码描述
但是,一般情况下,我们选择的都是异步查证,根据查证结果进行最终结果的确定

现在有这么一个场景,用户支付失败,原因为用户余额不足,在同步发起交易的时候,返回的状态码和返回码描述,我们有操作入库,但是订单状态在同步处理之后,定为处理中状态,等待异步查证结果进行订单状态改变。
当返回的tradeStatus字段为WAIT_BUYER_PAY状态时,订单会继续进行补偿查询(在这里提一下场景一中的两个字段,可以选择适当的字段进行表单的递送,亲测在使用timeout_express字段时,可能中间mq的发送等原因,会产生一到几分钟的延迟,测试时设置的15分钟,实际支付宝最终补偿了17分钟--从生成表单开始计算)。
但是建议不要本地设置订单任务,走完定时补偿后,确定订单最后状态,最好是以tradeStatus字段最后返回终态为准(不是WAIT都为终态)
我们遇到的问题就是,在由处理中状态变为终态的时候,把这次查询作为最后一次补偿,同时MQ通知到上游系统,送的状态是没有问题的,但是取不到返回码描述,仔细看蚂蚁提供的文档才知道......查询接口是不提供返回码描述的......
分享接入支付宝支付时粗心遇到的两个小问题

如果需要向上游送错误信息的话,可以在这方面注意一下了,不要直接把查询结果进行返回,最好是依赖状态变更对DB的保存或Redis的保存进行返回.....多测试一下

都是因为开发时粗心出现的两点小问题,分享出来丢丢脸......哈哈哈

上一篇:阿里云IPv6实践,从云服务到云安全


下一篇:支付宝小程序为淘票票贡献近8成流量,反哺阿里商业操作系统进入发力期