调用交易服务更新订单价格失败

支付宝上有一种保险叫国民保险和终身养老金。

看它宣传的各种保障和待遇都很好，但人们往往沉浸在表面。你可以看看下图中我用红线圈出的地方：增保额协议、支付授*、保险通知、产品手册、保险条款、平台服务协议。

有多少人认真读过，理解过，理解过？只在表面上参加保险是个忌讳。

参加国民保险终身养老金有15天的犹豫期。在犹豫期间，我们可以全额退保，并按照我们支付的金额退款。犹豫期过后，能退多少钱需要按照相关规定执行。根据保险，是可退保单的现金价值。

保单的现金价值是多少？保单的现金价值与我们的投资理财完全不同。无论是投资理财还是存钱，我们付出的钱的本金都是属于我们的。但是，我们交的保费不是存款和理财。保费由保险公司控制。如果买意外险，在规定期限内不会发生意外，所有保费不退。商业养老分红保险也是如此，只是保费不会完全扣除，而是从保险公司的某些必要费用中扣除，如账户管理费、风险保险费、销售渠道费或代理佣金等。产品介绍里有这样一个演示：

30岁一次性缴纳保费1万元，60岁每年保额1010元。

一次付清保费后，退保金的现金价值，也就是保单，只有8160元。而且所有保单的现金价值都是按照3%左右的保证利率，以每年8160元的速度递增。但是知道还有一定的浮动分红，从0%到3%不等，无法保证，还是很欣慰的。如果回报率只有3%，我们投资理财真的不是很有吸引力。要达到4%~5%的收益率还是很简单的。

如果许多人从这种不确定性出发，他们参与保险的意愿将大大降低。毕竟30岁的我存了一万块钱，60岁以后一年只拿1010块。30年后的购买力如何？人们对此深表怀疑。所以保险的特点是长期稳定，各种利益基本可以在保险合同中约定，未来长期不变，让保险公司通过各种金融手段实现长期目标，稳定挣钱。

与商业养老保险相比，社会养老保险有其自身的特点。社会保险由国家法律强制执行，由国家管理、征收、支付甚至补贴。为了避免养老金流于形式，国家应确保退休人员的待遇符合经济和社会发展。所以很多国家都采用现收现付的养老保险模式，比较大的好处就是可以保证购买力的稳定。然后，国家通过各种手段形成养老保险平准基金的余额，用于调节保险基金的收支波动。2018年，全国基本养老保险基金收入51168亿元，支出44645亿元，养老保险基金累计余额超过5万亿元。可能以前参加保险的老人只交了一点点养老保险，视同缴费期的很多保险费都是国家交的，但是现在每个月的养老金都是三四千元，很划算。不要以为国家出钱就没人出钱。2017年，政*补助基本养老保险基金8004亿元。2019年中央安排养老保险基金补贴5600多亿元，未计入人员和场所支出。因此，中国的养老保险是一项非常亏损的业务，但它也是为了社会的福利。

说商业养老保险不划算吗？其实商业养老保险比较大的特点不是投资，而是稳定。如果我们的收入很不稳定，比如现在可能一年赚几百万，但是以后可能会失业，那就要买商业养老保险了。收入高的时候参加养老保险，是平衡未来收入现金流的一个非常有利的保障。李嘉诚给每一个孙子孙女买了1亿港币的养老分红保险，可以保证这些孩子吃好，每个月至少有几十万港币的分红收入。至于这几十万元几十年的购买力，没必要考虑太多。

综上所述，商业养老保险有其特定的功能。如果把它当成存款或者投资理财，其实是有偏差的理解。好了，回到的话题。就来分享一下支付系统中的一些异常处理方法。

其实这些处理方式并不局限于支付系统，也可以应用到其他系统，可以借鉴应用到自己的系统，提高自己系统的健壮性。

异常是系统运行中不可避免的问题。如果一切正常，我们的系统设计会相当简单。

不幸的是，没有人能做到这一点，所以为了处理异常可能带来的问题，我们不得不增加很多额外的设计来处理这些异常。

可以说，在系统设计中，异常处理需要我们专注于思考，会占用我们大部分的精力。

让我们先来看看支付系统中比较常见的异常：「掉单」

删除文档时出现异常

比较常见的支付平台架构关系如下：

以携程为例，在其上发起订单支付将经过三个系统：

携程创建订单并向第三方支付公司发起支付请求

第三方支付公司创建订单并向工行发起支付请求

工行完成扣款操作，返回第三方支付公司

第三方支付完成订单更新，返回携程

携程更改订单状态

上述过程很简单，如下图所示：

在这个过程中，可能会发生用户的工银卡已经被借记，但携程订单仍未支付的情况。我们通常称这种情况为「掉单」.

上述大多数订单丢失的情况都是由「、」,(我们称之为「外部掉单」.)的信息丢失造成的

还有一种罕见的情况是，从「、」链接返回的信息被接收，但是系统未能更新「、」链接中的订单状态，这导致成功支付信息的丢失。因为这种订单取消是内部问题，我们通常称之为「内部掉单」.

外部掉单

外部取消是因为没有收到对端返回的信息。这种情况很可能是网络问题，或者是对端处理逻辑太慢，导致我们的请求超时，直接断开网络请求。

增加超时时间

对于这种情况，第一个比较简单的解决方案是「适当的增加超时时间」.

但是这里需要注意的是，我们增加网络超时后，可能需要调整整个链路的超时，否则可能会导致整个链路的内部跑腿，导致内部账单丢失。

第二种方法是接收通道异步接收通知信息。

一般来说，我们现在可以向支付渠道接口发送一个异步回调地址，当渠道端处理成功时，会通知回调地址成功的信息。

在这种情况下，我们只需要接收通知信息，进行分析，然后更新内部订单状态。

支付系统异常处理-支付异步通知

在这种情况下，我们需要注意几点：

对于异步请求信息，需要对通知内容进行签名和验证，并检查返回的订单金额是否与商户方的订单金额一致，以防止因数据泄露而导致的“误通知”，造成资金损失。

异步通知会发送很多次，所以异步通知处理需要幂等性。

掉单查询

有些渠道可能不提供异步通知功能，只提供订单查询的接口。在这种情况下，我们只能使用第三种解决方案，即定期下订单进行查询。

我们可以将这种未知超时的订单单独保存到订单投放表中，然后从渠道端定期查询订单的状态。

如果查询成功或失败(例如，订单不存在，等等。)，可以更新订单状态，删除单表记录。

如果查询仍然未知，那么我们需要等待下一次查询的结果。

调用交易服务未能更新订单价格(如何手动检查快递停运区域)" src=" https://p6-tt.byteimg.com/origin/pgc-image/c6ffadf 52e 64497 ba 953 ac 0704677356 . jpg " data-origin=" https://p6-tt . byteimg.com/origin/pgc-image/c6ffadf 52e 64497 ba 953 ac 0704677356 . jpg "

支付系统异常处理-定期查询

我们需要注意这里。在某些情况下，可能不会查询返回订单的状态，因此我们需要设置订单查询的比较大数量，以防止无限查询浪费性能。

对账

比较后，在极少数情况下，订单查询和异步通知都不能获得付款结果，这就剩下比较后一个解决方案，对账。

如果第二天在渠道提供的对账文件中发现此支付结果，我们可以根据此记录更新直接更新我们的内部支付记录。

之前小黑写过一篇和解的文章。有兴趣可以再看看：谈谈对账系统的设计

那么，如果第二天没有这个记录的结果，在这种情况下，我们可以认为这是一个失败。如果用户被扣除，渠道将发起退款，并将支付的金额返还给用户。因此，这种情况可能不需要处理。

内部掉单异常

支付公司内部订单关系

接下来，我们来谈谈内部文档丢弃的例外情况。首先，让我们看看为什么会出现内部文档删除的异常，这实际上与我们的系统架构有关。

如上图所示，第三方支付公司的内部表，支付订单和渠道订单通常是一对n的关系。

支付订单持有外部商户系统的订单编号，代表第三方支付公司的内部订单与外部商户的订单之间的关系。

渠道订单代表第三方支付公司与外部渠道的关系。其实对于外部渠道系统，第三方支付公司是外部商家。

为什么需要设计这种关系？而不是用下面的一对一关系？

如果我们使用上面图1-1所示的订单关系，如果第一次支付失败，外部商户可能会使用相同的订单号再次向第三方支付公司发起支付。

此时，如果第三方支付公司也以相同的内部订单请求外部渠道系统，则有可能是外部渠道系统不支持相同的订单号再次请求。

其实我们也有其他的方法，比如生成一个新的内部订单号，更新原付款单上的内部记录，然后请求外部渠道系统。但是，如果发生这种情况，比较后一次支付失败的记录就会丢失，不利于我们事后做一些统计。

事实上，第三方支付公司可能不支持相同的订单号再次发起请求，但在这种情况下，外部商家需要重新生成一个新的订单号。

在这种情况下，第三方支付公司的系统很简单，所有的复杂性都交给了外部商家。

但是现实中很多外部商家并不是那么容易更换和生成新的订单号的，所以一般第三方支付公司都需要支持同一个外部商家的订单号，如果不成功就需要重复支付。

在这种情况下，我们需要上面1:n的顺序图。

内部掉单异常的原因

当我们收到来自外部渠道系统的成功返回消息时，我们成功地更新了渠道订单的记录。但是，由于渠道订单表和支付订单表可能不是同一个数据库，所以可能不在同一个应用程序中，这可能会导致支付订单表更新失败。

因为支付订单表保存了外部商户订单和内部订单的关系，所以支付订单不成功，外部商户无法查询得到成功的支付结果。

此时渠道订单表已经成功，所以上述外部取消订单的方法不适用于内部取消订单。

内部掉单异常解决办法

「第一种解决办法，分布式事务。」

内部掉单异常，说白了就是因为使用数据库交易无法同时更新支付订单表和渠道订单表成功或者失败。

在这种情况下，我们实际上需要使用分布式事务。

然而，我们没有采用这种分布式事务。第一，我们之前开发的时候市场上还没有开源的成熟的分布式事务框架。第二，自己开发非常困难。

因此，没有使用分布式事务的经验。如果有学生用分布式事务解决这类问题，留言评论。

「第二种解决办法，异步补偿更新。」

如果发生内部单据丢失，即无法更新付款单，可以将此处的付款单保存到内部单据丢失表中。

但是，这里可能有问题，我们不能保证保存到内部下拉列表的步骤会成功。

所以我们还需要定期查询，在渠道订单表中查询一段时间内已成功支付的付款订单记录，然后插入内部降单表中。

在另一个系统应用中，只需要定期扫描内部掉单表，支付订单成功，然后删除内部掉单记录即可。

这里需要注意的是，当支付订单表中的数据量较大时，常规查询可能会比较慢。为了防止主仓库受到影响，这种查询可以在备用仓库中进行。

总结

我们主要介绍支付系统中的掉单例外，这种情况往往会导致用户实际上已经被扣了钱，但是商家订单还在等待支付的情况。

如果这个异常处理不好，会导致用户体验差，可能会收到客户的投诉。

丢单的例外通常可以是外部系统，也可以是内部系统。大部分订单的下降是由外部系统造成的。我们可以增加超时，查询掉的订单，接受异步通知，解决99%的问题。剩下的1%的订单只能通过第二天的对账来弥补。

内部系统导致订单丢失异常是分布式环境下数据一致性的典型问题。对于这类问题，我们不需要追求强一致性，只要保证比较终的一致性即可。我们可以使用分布式事务来解决这样的问题，或者我们可以定期扫描状态不一致的订单，然后批量更新。

比较后，这一次我们只介绍支付系统中的一种异常掉单。在下一篇文章中，我们将介绍支付系统的其他异常情况，敬请期待！