交易超时查询机制最佳实践
一、概述
1.1 背景
目前接入网易支付代扣接口的商户增多，且代扣渠道普遍不太稳定，尤其在并发量大时，超时情况急剧增多。商户普遍反馈实时代扣订单交易超时后，无法获取除支付成功订单外该笔交易订单的最终状态及失败原因，导致商户端相关业务不易开展。
1.2 目标
通过介绍网易支付的实践，分析通过实践的数据，明确订单状态的占比及时间段内占比，得出商户可通过查询交易订单接口来同步订单最终状态的最佳实践，最大化避免或解决因交易超时而无法获取交易最终状态和原因的问题。
二、网易支付实践
2.1 订单状态查询机制
为了与银行同步订单的最终状态（成功或明确失败）。尤其是支付成功订单，减少用户等待时间，最大化增强用户（商户）的支付体验；明确失败订单状态同步，反馈订单最终交易失败的结果。单笔订单状态查询机制主要流程，如图2.1所示。
图2.1 订单状态同步流程图
主要点说明：
1、支付订单从下单开始时，会根据对应订单的属性分配相应的查询策略，然后计算该笔订单首次查询的时间。
2、达到指定查询时间的订单会触发与银行订单状态同步。
3、根据银行同步回来的状态，如果订单为明确状态（失败或成功），则更新订单为明确成功或明确失败，反之则根据对应查询策略获取下次查询的时间点。
2.2 数据统计
网易支付统计8月1日至8月13日的数据，按照漏单（实时交易超时，订单查询银行状态最终为成功）查询回来的时间段统计结果如表2-1所示。
表2-1 漏单查询成功各个时间段占比
日期 | 5分钟内占比 | 15分钟内占比 | 25分钟内占比 | 30分钟内占比 |
8月1日 | 38.16% | 42.03% | 98.55% | 99.03% |
8月2日 | 35.51% | 41.30% | 100.00% | 100.00% |
8月3日 | 35.41% | 44.59% | 96.39% | 99.34% |
8月4日 | 27.56% | 36.22% | 100.00% | 100.00% |
8月5日 | 32.08% | 38.68% | 99.06% | 99.06% |
8月6日 | 22.97% | 27.03% | 100.00% | 100.00% |
8月7日 | 31.21% | 37.58% | 93.62% | 100.00% |
8月8日 | 57.40% | 75.15% | 100.00% | 100.00% |
8月9日 | 57.05% | 61.54% | 98.08% | 98.72% |
8月10日 | 62.50% | 67.37% | 99.15% | 100.00% |
8月11日 | 65.78% | 67.56% | 100.00% | 100.00% |
8月12日 | 89.19% | 91.74% | 99.58% | 99.58% |
8月13日 | 54.63% | 55.56% | 99.07% | 100.00% |
漏单查询成功各个时间段内百分比的占比趋势如图2.2所示。
图2.2 漏单查询成功各个时间段占比趋势图
明确失败订单各个时间段内占比如表2-2所示。
表2-2 明确失败订单各个时间段占比
日期 | 1分钟内占比 | 5分钟内占比 | 30分钟内占比 |
8月1日 | 97.57% | 99.21% | 99.23% |
8月2日 | 98.64% | 99.35% | 99.55% |
8月3日 | 98.28% | 99.43% | 99.56% |
8月4日 | 96.69% | 97.79% | 99.84% |
8月5日 | 98.59% | 99.58% | 99.60% |
8月6日 | 98.93% | 99.72% | 99.77% |
8月7日 | 98.42% | 99.56% | 99.66% |
8月8日 | 98.67% | 99.76% | 99.86% |
8月9日 | 96.19% | 97.01% | 99.74% |
8月10日 | 98.39% | 99.14% | 99.27% |
8月11日 | 98.73% | 99.62% | 99.79% |
8月12日 | 98.24% | 99.83% | 99.93% |
8月13日 | 98.98% | 99.87% | 99.88% |
明确失败订单各个时间段占比时间趋势如图2.3所示。
图2.3 明确失败订单各个时间段占比趋势图
通过上述分析可知，代扣漏单同步回成功状态在5分钟内占46.88%，30分钟内占99.67%；失败订单同步回明确失败状态1分钟内占98.18%，5分钟内同步回明确失败状态占比99.22%。
2.3 总结
目前网易支付可获取99%以上交易订单的最终状态，但是无法同步给商户，需商户通过接入网易支付的交易订单查询接口，来获取交易订单状态及支付结果。
三、商户接入最佳实践
3.1 概述
通过上节介绍网易支付的最佳实践，来协助商户采用类似模式，并给出建议查询策略来最大化解决交易超时而无法获取最终订单状态及原因的问题。交易状态同步的整体流程如图3.1所示。
图3.1 交易订单状态同步流程
3.2 实时代扣支付
实时代扣支付的接口，API详见【银行卡支付API】。
3.2.1 超时时间
实时代扣网易支付与银行间通信的超时时间为20秒，建议商户端设置超时时间为23秒。
3.2.2 实时返回状态及处理
实时代扣会返回支付状态字段，该字段有三种值：SUCCESS(代表成功)，FAILED(代表失败)，PROCESSING(代表处理中)。
SUCCESS(代表成功)：实时代扣支付成功，商户可走成功支付后续流程。
FAILED(代表失败)：实时代扣支付明确失败，商户可走失败后续流程。
PROCESSING(代表处理中)：实时代扣支付处理中，需商户调用查询接口获取支付的最终状态。返回处理中状态时，不建议针对此订单重新发起支付。
3.3 异步订单查询
3.3.1 查询接口
交易订单查询接口，API详见【单笔订单查询API】。
3.3.2 返回状态及处理
查询交易订单状态接口中，目前会返回交易订单状态和快捷支付失败信息（如果支付失败）。商户可根据交易订单状态和快捷支付失败信息来判断该次支付请求的最终状态。
同时网易支付为解决商户无法获取支付最终结果，特增加了快速关单的交易订单模式，商户可根据自身订单机制来决定是否要采用此交易模式。
采用快速关单模式（推荐）
快速关单交易订单模式：
1、前提：商户发送交易请求时，确保交易流程每次唯一。
2、当交易订单发起支付后，如果此次支付是明确失败的，则触发交易订单关单，不允许此订单号再次发起支付请求。交易流程如图3.2所示。
图3.2 快速关单交易订单模式
通过流程图可知，快速关单在支付中，增加当订单明确失败时，将交易订单关闭。若商户希望配置此模式，可联系技术支持进行配置。
查询接口返回结果：
如果实时支付明确失败，则交易订单状态为关单状态，后续查询时，返回的交易订单状态均为6（交易关闭）同时返回失败信息。
如果实时支付明确成功，则交易订单状态为已付款状态，后续查询时，返回的交易订单状态也均为支付成功的状态（可能为1,2,3,4,5）。
如果实时支付处理中，则交易订单状态为未付款，后续查询时，将根据网易支付查询银行的结果进行变更为关单或已支付，同时返回该此支付请求的失败信息。
注：关单后，该笔交易订单不允许再次发起支付请求
不采用快速关单模式
商户不能保证每次交易请求流水唯一，可采用此模式，但是在前一次支付请求状态处理中时，不建议再次发起支付请求。
查询接口返回结果：
如果实时支付明确失败，则交易订单状态停留在未付款状态，后续查询时，返回交易订单状态为未付款，且返回最后一次支付请求的失败信息（同一笔交易订单支付多次，则为最后一次） 如果实时支付明确成功，则交易订单状态为已付款状态，后续查询时，返回的交易订单状态也均为支付成功的状态（可能为1,2,3,4,5）。
如果实时支付处理中，则交易订单状态为未付款，后续查询时，将根据网易支付查询银行的结果进行变更为未付款或已支付，同时返回该此支付请求的失败信息，在交易订单状态为未付款或已关单且报错快捷支付错误信息，则可根据快捷错误码来判断是否明确失败，其中交易处理中的错误码为016005,016009,016015，其余为明确失败。
注：实时下单会要求传关单时间，超时将直接关单，关单后也可查询到该笔交易订单支付失败信息
3.3.3 查询策略
商户可按照网易支付订单状态查询机制来进行交易订单状态查询。参照2.2的数据统计，总结出商户端最佳的查询策略。
故查询接口商户端的最佳查询策略如表3-1所示。
表3-1 查询接口查询策略
查询次数 | 时间间隔（秒） | 备注 |
1 | 120 | 下单后2分钟 |
2 | 240 | 上次查询后4分钟 |
3 | 600 | 上次查询后10分钟 |
4 | 900 | 上次查询后15分钟 |
5 | 3600 | 上次查询后1小时 |
6 | ... | ... |
按此策略进行查询，可覆盖漏单类型订单99.67%以上，明确失败订单99.67%以上。