导读
近来经历了一件事，就是小码农所在的公司由于被某大厂竞购以后要进行融合了，其他方面的融合就没必要说了，明天俺们只是聊一下支付系统融合的事情。首先从好多互联网公司的发展经验来看，随着多条业务线的发展，最终都是会催生出建设统一支付系统的强烈需求。
这是为何呢？由于支付系统太重要了，它拥有公司所有的现金流水，是进行业务清算、财务核算、上市审计以及后续各种财务信息管理的关键系统之一。一家公司被竞购后新老总们最关心的事也莫过分财务数据的确切性了，之前小码农从事支付系统的研制工作加入的都是早已比较成熟的团队，去建设的支付系统也都是为了帮助所在公司来实现上述的目标和战略，而所采用的策略也都是在强悍的下层的支持下进行业务线统一支付入口的归集。
只不过这一次作者所加入的是一家互联网创业公司，而在支付系统的建设上，也属于比较混乱和中级的阶段，因而在被竞购后属于是在另外一个强悍下层的支持下而被统一的一方而已。其实从客观的角度看，这也是一件十分合理的事情，由于一个大的集团公司无论是从成本还是统一管理的角度看都是没有必要重复建设多套支付系统的，而对一家被竞购的公司而言，其支付系统肯定也是首先须要被融合的关键系统之一。
作者对此持开放和豁达的心态，虽然这个过程对个人会有一些影响。只是由于在此之前经历了好多的艰辛，认为有好多事情还是值得总结一下，因而才想着写一篇文章来追忆下这个过程。而总结的目的，也只是希望还能对未来会经历这样一个过程的公司，有一点参考价值，由于虽然是被融合，假如做的比较好的话也会让融合的过程会愈加容易一些，起码能够得到一些口碑，否则就很容易遭人骂了，而从技术本身看也会是一种失败。
被忽略的团队
关于支付团队是否是被忽略的团队的问题，可能因公司而异（或则其实因不同公司处于关键岗位的技术是否具备这样的经验和远见而异），可能有一些互联网创业公司在发展早期并不是很Care这件事微信订货系统，由于初期的业务也确实没有这么复杂，在业务代码中接个微信、支付宝能有多难，两三个人都嫌多还想造成哪些样的注重？
的确，作者最开始加入这家互联网创业公司时，真的就只是在业务代码中对接了一个支付宝、微信，看上去似乎真的是没有这么复杂，在人员方面也就是两个没有太多支付经验的研制而已，连即将的支付订单流电表都没有，还基本上是与业务订单耦合在一起的那个。
但是，其实这一切似乎也并没有影响公司业务的蓬勃发展，在线收款业务量也是下降迅速，每晚好几个亿的进帐。只是这个时侯，会时常出现好多掉单而已，总之用户投诉了，写条SQL改下订单状态，要么退货，要么用SQL进行下业务处理。
其实，看上去一切并没有这么复杂，只是前面又降低了几个新的支付渠道，而支付宝、微信这些由于开了新的入口（如和微信小程序合作，支付宝第三方合作之类）又申请了下新的微信、支付宝商户号。
从截至到以上阶段的场景上剖析，到目前为止都只是在双向的进行收款操作。而此后的事情可能就有点戏曲性了，由于忽然某三天，发生了挤兑的事，系统的退货恳求迅速降低，其实，此时大部份的退货恳求还都只是走原路进行全额退票的操作，还没有部份退货等一些复杂的业务退货情况，而此时的退货掉单则有点扯了，由于这造成了大量用户早已退货，而业务系统逻辑并没有更新状态的情况，此时此刻也就为后续财务数据的混乱埋下了相应地伏笔（之前的支付掉单处理得不及时，也是在埋伏笔）。
虽然更为糟糕的是，由于有些用户太过分忠诚，支付的订单时间过长，早已超出了第三方渠道容许进行原路退货返回的年限，而此时由于未能通过系统手动进行原路退票，最终没有办法客服小妹妹只能人工搜集顾客上报的资料（如支付宝帐号），之后通过Excel由哪两位悲催的开发去通过手工的形式整理后通过单独申请的支付宝代付帐号进行转帐退货操作，虽然这些方法也没有哪些太大问题，只是比较原始而已。的确是这样，但是不幸的是，只是这些人工操作时常都会失败，须要重新发起和进行系统订单状态的更新（假如真的把钱给他人转成功了，得用SQL把状态给改了啊），而这个过程由于人工诱因，致使了一些状态未更新的情况，以及汇款重复的小失误，而这也为后续财务数据的混乱埋下了另外一笔伏笔。
见到这儿，其实不少朋友就会惊讶，这卧槽为何不设计相应的机制来解决呢？所以，这个时侯开始有人谈起了支付系统构建的问题。而此时作者刚好加入这家公司，所以心想也算一个机会，于是也提出的自己的构建方案。细节不提了，只说一个基本的支付系统应当是哪些样，如右图所示：
于是作者激情满满的找到了领导，提出了自己的看法。但是，令人没想到的是，还有个项目由于也涉及到一些支付功能的构建，所以须要找人相关人员沟通下，好吧，此时才晓得原先支付系统早已在秘密地被重塑了，只是正常开发和维护支付系统的人竟然不晓得这件事。也罢，而让人更意想不到的事，这是竟然还不算完，由于还有另外一个团队，属于另外一个VP领导下的团队也在进行支付系统的构建，只是正常的支付团队以及秘密构建的项目都还彼此不晓得而已。
说到这儿，仔细想想，作者也是很惊讶，不过好歹由于作者提出的这个看法并鼓起勇气和大鳄沟通，终于让你们彼此晓得了这件事，也算是一个良好的进步和开端。而与此同时，还有另外一个团队在开发所谓的财务系统（实际上就是作者图中所规划的帐目系统，其实前者由于种种胡扯的因素，在做了两月以后做黄了，以至于到目前为止依然缺位这一块，而竞购方希望融合方法则正是所有的业务线接入她们统一收银台的同时，还须要接入其帐目系统，这样资金流、业务流就完成单向闭环了，这样业财核实、收入估算就可以通过集团统一而完备的系统进行集中处理了）。
于是乎，似乎此时此刻，这件事应当是奔向好的方向发展了，支付系统应当是在比较充足的资源配置的情况下，而且经过合理的设计后开始有计划有步骤地构建了。但是，不幸的事，此时此刻又出现了新的搅局者，新来了一位貌似很有经验的产品总监，提出要建设一套很牛逼的统一交易系统，而支付系统其实只是其中底层的一个小部份而已。
这么如此，最终经过N轮的推诿、沟通以及团队利益的苦恼厮杀，最后就由某甲团队开始进行支付系统的构建了，与此同时作者呢由于刚来，所以就做起了你们都认为很不起眼的对帐工作了。但是，后续支付系统的构建，并没有完成彻底的重新打造，整个系统的订单模型并没有进行脱胎换骨的整修和升级，对于历史数据的处理，也是避重就轻，只是简单的在新的支付系统的代码层面进行了适配，并采用了无敌的词尾策略，这么至今还是词尾（客观地究其缘由，由于那种团队实际参与构建的也只有2～3人，在经验和资源缺少的情况下，也很难将这件事做的相对全面而完整）。
以上种种也就为支付系统的先天残缺，资金数据的混乱以及后续为了适配各类新业务而疲于奔命，因而造成更多的不确定埋下了深深的伏笔。而这其中，又经历了不同主管的更换，但其实没有一个是专业的，于是缔造了现现在的种种顽疾。
通过上述的曲折历程的回顾，这可能并不像是一个技术问题，而更多的像是由于创业公司的技术管理混乱而造成一种扭曲的现象。其实换一个CTO就不一定会是这些状态，所以这些情况是否属于共性问题，也就须要你们自己按照自身公司的实际情况进行判别了。只是在这儿作者将其扼要的怪罪为对支付团队统一建设的一种忽略吧。
有问题的组织
关于这个问题，不同的公司的情况可能是不一样的，正如前面所说，初期在业务代码中对接个支付宝、微信的插口其实并不是太复杂的事，而且须要说明的是假如考虑到未来业务的扩充所造成的复杂性，而且在早已开始构建支付系统的情况下，则是一定要做到“麻雀虽小，脏腑俱全”，之所以如此说，缘由在于支付系统是一种对数据一致性要求十分高，而且又很难单纯的从某一个小的方面保证数据一致性的系统，它须要一个完整的体系来保证。
而前面提及的复杂性，就有好多种情况了，比如假如涉及系统退货，退票本身都会存在众多的复杂性，如全额原路退货、部分原路退货、在线汇款退货、线下汇款退货等，但是不同的支付渠道所能支持的程度还有差别。
另外，假如涉及多渠道、同一渠道不同的商户主体，以及工行卡支付／非交行卡支付，海外支付多发的等情况，则带来的复杂性也会相应地降低。由于此时支付系统除了须要满足参数配置化、渠道路由化等要求，支付方法、交易方法所形成的数据订单也须要具备完整的储存逻辑。
其实，上述逻辑复杂度的降低也不是一开始就是这样的，而是随着业务发展逐渐递增的。所以对于支付团队的配置，也没有必要一开始就配置一个大的团队，并且作为团队的技术，一定要清楚在哪些阶段须要哪些样的人员配备，但是明晰的指定一名具有一定专业度的支付团队技术来带头进行有组织、有计划地构建工作，而不是在这个问题上含混不清，由于根据个人的经验，在这个事情上的瞎竞争似乎是没有哪些用处的，最终可能会带来混乱。
支付订单模型
在具体讨论怎样对支付订单模型进行设计讨论之前，和你们一起回顾了一些团队发展和建设的问题，由于起码在作者目前看来，最本质的问题并不是出在技术本身上，而是由于团队技术管理混乱，带来了一系列的弊端。
但好多时侯，其实以上种种并不是我们作为普通技术人员本身就能干预得了的，由于这常常牵涉好多技术以外的诱因。这么假如假定你承当了这一角色，或则作为一名具体的工程师，在你具体构建或设计支付系统时，怎样尽可能地想得长远一些呢？这儿有作者依据自身经验设计的一套逻辑模型，供你参考。
上图是一张精简的关于支付系统订单模型设计的图，在模型中我们将订单分为交易&支付两个层面，之所以要如此界定，是在于我们进行支付系统开发时好多时侯是须要满足一部份业务逻辑的，而设置交易订单的目的则是为了屏蔽这些业务不确定性而带给支付订单本身的复杂性。
在这个模型中，交易订单作为与业务交易映射的一张记录表，比如业务A通过支付系统发起了一笔冲值交易（如10块钱），这么都会在交易订单中插入一条10块钱的冲值交易流水，而这笔冲值流水正常情况下可以通过相应地支付渠道进行支付，可以一次性支付10块钱（插入一条对应的支付订单流水），也可以支付两次5块钱，但是还可以分别使用不同的支付渠道（分别插入两笔对应的5块钱的支付订单流水），所以交易订单与支付订单的关系为1:N。
之所以容许这样的情况发生，是由于在实践中，由于渠道限额，业务容许重复发起支付等诱因，所以必须容许进行拆单支付的情况发生。而倘若在这些情况下又须要容许交易进行退票的话，为了精简数据储存，对于交易订单可以通过状态机进行处理（如设置交易退货状态），而对于支付来说，退票本身也是支付流水，所以不应当直接在支付订单流水上进行状态修改，而是应当单独设计独立的退货流电表，只是须要在退票流电表中设置原始支付的订单信息，以及退货的具体形式即可。
而支付退货本身又可以分为原路退货/非原路退货，而这两种退货形式又分别可以分为全额退票和部份退货两种情况，所以支付流水与退票流水之间又存在1:N的关系。还是举里面那种事例，假如用户冲值交易所支付的10块钱，是一次性通过微信支付的，这么退票时假如时全额原路退票，则只须要插入一条与支付流水对应的10块钱的退货流水，并更新交易订单状态为“已退货”即可。
假如是由于该用户的冲值部份，使用了5块，剩下的5块钱可以退货，这么此时发起的就是原路部份退货，在退货流电表中插入一条与支付流水相关的5块钱的退货流水即可，而且此时须要将对应的交易订单状态更新为”部分退货“的状态。
据悉，以上情况倘若因为支付订单时间太久，原支付渠道已难以再进行原路退货，此时只能通过线上或线下汇款形式／代付形式进行退票的话，则为了建立模型，我们也须要在退票流电表中记录一条与原支付订单关联的退货流水，只是退票形式须要记录非原路退货的情况，但是在发起汇款或代付退货后，须要在退货流水中关联对应的汇款或代付流水号微信订货系统，然后按照实际退货的情况更新对应的交易订单状态为“已退货/部份退货”。
而汇款或代付本身由于又是一种单独的支付形式，所以此时我们须要在支付流电表中单独记录汇款订单或代付订单，但由于此时与交易订单本身无直接关联，所以不须要形成新的交易流水。
对于海外支付渠道由于形成了的情况，我们须要将其视为与汇款类似的非原路退货方法，因而进行退票流水的记录，以及订单本身的记录，这一点对于海外支付渠道的支付逻辑建立以及本身的溯源会比较重要。
根据这些模型进行支付订单结构的设计，并在一开始就撸清楚这种支付场景的对应的数据储存逻辑，会对未来系统的分拆扩充大有益处，由于起码数据逻辑是十分清晰的了。只是为了确保这套数据逻辑的一致性，我们还须要强化对帐系统关于内部订单对帐的逻辑，确保不出现异常和不一致的数据问题。
以上就是本次作者关于支付部份想写的全部内容了，希望还能对一些正在经历支付系统建立的同学们无论优劣有一点参考借鉴的意义。
谈一下家国情结
在这儿里面干货部份的内容就说完了，接出来的内容纯属抒发下心情，希望指正！近来由于华为风波，作者也看了好多报导和相关的剖析文章，总结一点就是华为的5G太强悍，打动了以英国为主导的西方利益，由于一旦5G网路建设的主导权被中国公司把握，这么未来世界的网路格局就要发生翻天覆地的变化了，所以日本开始搞一些下三滥的绑票手段了。
在这儿作者作为一名中国人，对此表示强烈的悲痛，同时也认识到这个世界还是一个弱肉强食的世界，之前好多人都说日本这儿好，那里好的，其实我也承认日本的确在好多方面还领先中国，并且正所谓“金窝银窝不如自己的狗窝”，还是希望你们多多爱自己的祖国，不要经常的随波逐流喷我们国家这不好，那不好的了。做好自己的本质工作，不求为国做多大贡献，只求不给国家唱反调就行！
最后，以本文的封面抒发下对华为这家伟大企业的支持！感谢你们！
—————END—————
免责声明：部分文章信息来源于网络以及网友投稿，本站只负责对文章进行整理、排版、编辑，出于传递更多信息之目的，并不意味着赞同其观点或证实其内容的真实性，如本站文章和转稿涉及版权等问题，请作者在及时联系本站，我们会尽快为您处理。
