写在前面

今天我想分享更多关于我的支付经历。记得在进入互联网金融之前，我在一家传统银行做某银行的境外卡业务，涉及到场外支付交易：收款、转账、支付；我也亲身经历过一次重大的财务损失事故，深深地让我对支付交易产生了敬畏之心。从那时起，我认为任何涉及金钱的工作都必须严谨，认真，多次检查和测试。

加入美丽后，我又开始玩“支付”了。美利金融成立之初刚刚成立。一切从0开始，团队和体系开始搭建。然而业务发展的速度对支付系统提出了非常迫切的要求，从支付场景、交易量、渠道稳定性、信息安全等方面都需要快速建立和支撑。施工时间很短。此外，我们的研发对于支付来说是“新的”。看似很快就搞定了，但上线后却频频出现问题和故障。 ，并发生多起资金损失事件。

支付平台经过2年多的建设，我们迭代了三大系统架构，也经历了很多生产中的坑。但值得宣传的是，我们为每一个陷阱和事故都写了一份 RCA 报告。通过不断的审核，到目前为止，美利支付取得了非常好的成绩：系统微服务架构布局已落地、生产运营系统稳定、支付工作流程规范、数据信息安全等。截至发稿，我们完成了“401”天零资金损失。

什么是RCA？

上面提到了RCA，这是一种值得提倡的工作态度。 RCA的英文：Root 中文意思是：根本原因分析。

RCA 是一种结构化的问题解决方法，可逐步识别并解决问题的根本原因，而不是仅仅关注其症状。根本原因分析是一个系统的问题解决过程，包括识别和分析问题的原因、寻找问题的解决方案以及制定预防措施。在组织管理领域，根本原因分析可以帮助利益相关者发现组织问题的症结并找到根本解决方案。

对于付款过程中出现的任何生产问题，我们必须写一份RCA报告并将其放在wiki上。只有不断认清根源，输出预防措施，我们犯过的错误才不会再次重演，才能形成经验。而这些RCA的文章，也非常方便其他开发同学阅读和分享，从而传递经验。

如何理解资本损失？

资本损失：资本损失。我们老板将“资本损失”定义为正资本损失和负资本损失：

正资本损失：

一般来说，公司多付了货款。从公司角度来看，造成了直接的资金损失。损失追偿计划可能会在不通知客户的情况下主动扣留相应金额。但有些情况下，用户转账速度很快，需要后续帮助。收藏。

影响：占用公司客服及收款资源；可能存在无法恢复的情况。

负资本损失：

最典型的问题就是客户重复扣款。从公司的角度来看，公司的资金似乎并没有流失。损失由客户承担。我们可以主动退货给客户，但这往往是最致命的。顾客是每次付款的人。自然人有不同的脾气和性格。如果遇到顽固的客户，不愿意原谅，就会威胁、咒骂，甚至发布到网络或自媒体上，从而损害公司的声誉。

影响：客服资源被占用，客户需要安抚，客户要忍受不好的言语和态度；事故被发布到网络上，给公司造成危机，公关资源被占用等。

另外，资金损失事件往往可能涉及大量交易和巨额资金（主要取决于平台交易量）。一旦发生，就是P0级事故。这里我们还要考虑我们的支付监控能力以及及时故障报警的能力。

我们遇到的坑

以下是几个典型的真实资本损失案例并简要回顾：

业务订单重复下达，导致重复扣款

问题：系统新上线下单，同一客户下单两次。交易流程有不同的预扣服务，导致多个客户发送重复的预扣。

总结：商户端和支付端都存在问题。远程通信导致一些异常情况的处理不正确。还有就是人员短缺，基本上没有做过多少测试。其实我对付费还是缺乏尊重。现在回想起来，我真的不应该这样做。还是很难过。对客户和公司都产生了很大的影响，敲响了警钟。

系统异常，重复批量扣款

问题：由于系统线程池异常，导致订单状态更新异常，手动重复扣款；查询历史数据导致批次重复扣缴。

总结：没做，系统异常就急着扣钱，状态也不清楚。特别是，支付生产不得允许开发者操纵在线数据。过度自信会造成无尽的伤害。

新上线通道交易状态异常，导致重复扣款

问题：由于渠道关闭，紧急开发新渠道，基础功能测试上线后出现问题。

摘要：新通道紧急开发并测试3天，启动开发自测。这是一个惨痛的教训，也导致了一个又一个的问题。我们连夜加班改数据，苦不堪言。总之，没有支付功能就不能测试或直接上线支付。

支付宝交易记录不存在，居然成功

问题：由于用户主动还款，但前端查询速度快，支付宝还没有完成订单数据的创建，所以返回的结果是交易订单不存在。实际结果是支付成功。

总结：之前操作支付宝、微信支付的回调结果必须以回调结果为准。对于短期查询，时间间隔不能太短，比如1-2秒。

测试阶段和开发阶段通道特殊错误码通讯不一致导致处理状态问题和单边账（生产中4个通道有类似问题）

问题：某日建行代扣代缴业务量大时容易出现卡单情况。有些渠道在文档中直接返回了失败，但是没有说明这个错误码不能设置为失败。我们在开发和测试的时候并没有遇到，导致订单失败。副账户问题依然存在。

总结：通道后面连接着很多通道。由于数量问题，一些状态处理问题会导致账户单一。前期测试并不容易。在开发过程中，要求所有未知的错误和状态码不应该被设置为最终状态。我们将其归类为“状态未知”；

手动修改数据，导致复发

问题：周末线上出现问题，数据临时修改且SQL不严谨，导致更新数据为正常数据。

总结：这是一个人为操作的问题。人们在匆忙的时候更容易犯错误。越是紧急，越是严格。在执行SQL等手动操作时，需要规范执行流程，以避免出现此类低级问题。以上只是部分案例。市场上大家踩过的陷阱基本都是相似的。这些都是我们一次又一次支付的昂贵的学费。它们是来之不易的、遇到的、解决的。更重要的是，我们可以防范未来，防患于未然。

采取行动

在金融支付行业，资金底线至关重要。确保资金不丢失是任何金融支付行业的首要任务。这也是最困难的任务之一；让我们行动起来，让每一次旅行都是一次陷阱，一次一次都是痛苦的。好在兄弟俩的士气并没有减退，抗压能力比较强，责任心也很强。也对支付团队的兄弟们的辛勤付出和奉献表示感谢。

我们从行为约束、流程规范、高效运维、系统优化、业务监控等方面全面发力，汲取经验，下定决心，用行动守住资金损失的防线。

启动千日零资金损失项目

当年年初，支付宝针对频发的支付事故，推出了千日零资金损失项目。现在我们也效仿，为自己设立了“千日零资金损失项目”。一旦发生资金损失事件，计数器将被清零，流程将重新开始。本计划从“4.19”开始（2017年4月19日发生重大支付事故，我们将这一天定义为“梅里安全生产日”）。评审一直持续到凌晨3点。我们很着急，等不及了。系统优化后才进行操作。早期监控简单粗暴，多发帖。在没有业务监控“扁鹊”系统之前，值班人员甚至用肉眼观看日志滚动。

开展资金安全、资金零损失专项整治

对过去支付系统各个环节出现的问题进行全面梳理，从全局、全局、全环节分步梳理我们需要做的事情，并有计划、有节奏地落实；我们知道，这是一个大而持久的工程，我们可以用它来做，所以我们把这次行动定义为：“资金安全、资金零损失专项整治行动”，见下图：

行为约束

专用帖子和隔离：不要让开发人员直接接触生产。功能上线后，应交给专门的支付运营商。过去我们曾发生过多起开发者利用生产账号修改商户和路由参数，导致生产事故的事件。 ;因为开发不一定了解真实线上商户运营的路由策略和要求；我们对开发、运营、产品进行了严格的职责分工。开发线上账号的权限全部转移，“懂开发的千万别碰在线，要懂得在线开发”。

不要急于发展，不要急于上线：互联网的快速迭代，对于金融领域来说，应该更多体现在快速发展，而不是上线。我们需要有足够的时间进行测试，以确保财务数据准确、金融系统稳定，所以在我们公司有一句座右铭：急于开发，不急于推出。

标准化流程

我们更多地讨论了研发旅程的费用。之前，我们使用了简单的 三步流程：开发 --> 测试 --> 上线。通过不断的经验总结，我们现在研发有六个步骤：开发-->测试-->产品。受理-->审核上线-->真钱测试；阶段：代码开发并自测成功后，提交QA测试前，研发发起代码评审。参与人员包括项目、开发、测试等，需要运行的代码覆盖率、单元测试状况以及代码的现场讲解。我们的要求是必须存在包括代码可读性、复用性、依赖关系、缺失场景等问题；上线审核：上线前的准备工作，将检查项目清单一一核对，确保上线时没有遗漏；真钱测试：这是非常关键的一步。我们申请了专项测试资金，以真实交易对线上新支付通道和路由策略进行在线验证，确保线上新功能稳定运行；

高效运营

前面提到，专职岗位和权限隔离要求我们开发相应的高效操作系统、工具和标准化操作流程；系统方面：我们开发了商户操作系统、支付统计报表系统等，涉及支付查询、路由等日常操作。配置、交易处理、商户管理、通知管理等；流程：建立有针对性的交流群包括内部扣费群、支付群、外部第三方渠道群，避免信息轰炸（之前群很小，特别不利于信息聚焦，如果可以的话，建议使用钉钉通讯）。出现问题的第一沟通方是支付运营人员。建立工单机制。如需开发介入，由二次开发值班人员负责快速处理；此外，“客户”必须牢记“第一”的价值，我们向运营和开发人员支付费用，确保他们的手机24/7可用，下班后必须随身携带一台可以工作的电脑以及节假日（很多学生下班后不带手机回家，导致问题无法及时解决），保证能够快速解决问题；

系统优化

我们对系统上的微服务器架构进行了两次主要迭代。我们基于第三方支付架构思想建立服务，保证系统的高可用性和业务的快速迭代。我们梳理了资产流失点并做了专项优化，包括： 反犯罪策略：普遍困扰。拦截是避免资金损失的一个非常重要的计划。在支付过程中，通过支付的特征来识别资金是否发生底线风险。如果被发现，可以及时拦截，避免事情进一步恶化。它分为：

扣款防范：订单号防范以及根据公司支付业务特点进行防范；

代支付防诈骗：根据公司支付交易特点，如合同借贷业务等，防范诈骗。其业务特点是只会向一个合约借钱一次，因此我们在借贷交易时会重点关注交易要素：合约号、金额、卡号、身份证号、交易类型进行唯一的交易验证；

对账机制：支付、渠道、商户、账户四方验证，确保支付四方最终结果一致。经过这样一轮闭环验证，就可以避免资金损失；

对未知交易的保守处理：不要过度相信第三方渠道的错误码。根据经验，整理出确定的成功代码和失败代码。对于可疑的代码值和网络超时，我们将其定义为“不明交易”，切不可发起仓促重置。对于测试，系统需要自动通知操作人员进行人工和第三方验证；例如，历史上我们曾遇到过“我认为支付失败并发起新的支付”之间的通道问题。最终收到大量客户投诉，出现重复扣款的情况；还有很多，我就不一一列举了。

业务监控

我们自主研发了“扁鹊”监控平台。我们希望这个系统能够“看病、治病、健康检查”。对于核心交易，按照报警日志格式输出，然后监控平台提取相应的日志文件信息并设置相应的报警策略，一旦发现异常，可以通过短信、钉钉、邮件等方式发送通知。有了这个平台，我们结束了人工监控的历史，方便我们快速发现问题。 （扁鹊监控更详细的设计方案请等待后续安排来写分享）

思考总结

虽然支付经历了很多陷阱，但每一次错误都是一笔宝贵的“财富”。正是我们实践经验的积累，让美丽成为了一批支付领域的专家。业绩可能只取决于结果，但成长必须取决于过程。只有勇于正视自己的错误，遇到错误，解决它，不断检讨，才能真正理解“成长”。

文章中有些问题看似很简单，我们为什么要做出来，比如手动配置问题、随机上线和代码修改等；如果我们从一开始就严格制定相关规则，也许能够避免或减少很多问题。出现问题。生活中没有如果。我们分享我们的错误并发起零资本损失行动，希望能够帮助和我们经历同样事情的开发团队。也许没有先进的技术升级，所有的陷阱都是那么真实。这可能看起来很简单。但这并不容易做到；借用支付小哥最后分享时的一句话：好好学习，天天向上。能做到的人确实不多。不管多么小，只有经历过之后，你才知道，你会一直保持良好的付款态度。敬畏。

***

作者简介

阿兵（郭斌）拥有10年金融领域研发经验。现任美丽金融研发（后端）总监，负责融资平台技术团队。主要业务方向为融资、支付结算、财务会计。公司成立时，美丽就加入了我。作为公司早期的程序员，我见证了美丽从0到1的系统建设以及业务的快速发展。我有幸参与了中后台战略核心系统的建设，以及信贷业务架构和微服务架构领域的建设。积累了丰富的实践经验。