作者：陈斌
支付的技术架构是为了保障能够顺利处理支付请求而设计的结构体系。从系统的角度看，它包括了计算机系统的软件、硬件、网络和数据等。从参与的主体角度来看，它涉及交易的付款方、收款方、支付机构、银行、卡组织和金融监管机构等。要想成功地设计和构建支付系统的架构，需要深入地理解支付的业务生态体系，弄清楚并且照顾好支付业务生态体系中各利益相关方的诉求。
本章将讨论支付业务生态体系中利益相关方的作用和特点，分析各利益相关方的核心诉求，总结出为满足利益相关方的需求而提供的各种功能，并且进一步把相关联的功能聚合成子系统。在此基础之上，通过引入参考架构和分层架构设计的方法，讨论支付系统的架构，并描述支付机构的总体技术架构。
5.1 支付业务生态的利益相关方
5.1.1收款人与付款人
（1）收款人
一般来说，在支付过程中，发起支付活动的，首先是收款人（卖方）。卖方为了能卖出自己的产品或者服务，需要展示商品并游說买家付款去购买。而且，当双方的交易意向达成之后，收款人需要提供给付款人发货清单和付款请求。
对收款人而言，核心的利益诉求就是能在合约规定的时间，收到买方支付的约定数额的资金；需要履行的义务是按时、按质、按量发货，并且提供发票和发货信息。
（2）付款人
一般是交易中的买方，付款人（买方）的核心诉求是能够按照合约，在规定的时间收到卖方发出的约定数量和质量的货物，或者接受到约定数量和质量的服务。需要履行的义务是按时、按量完成与货物或服务相对应的资金支付。
对付款人而言，购买商品或者服务是偶尔发生的事情，需要有办法在短期內查询物流和支付情况。对收款人来说，卖东西是他的生意，需要不断地查询是否有新订单？已经收到的订单是否已完成支付？完成支付的订单是否已经发货等情况。
5.1.2银行
除了与交易直接相关的买方或付款人与卖方或收款人之外，银行也是支付活动的积极参与方。因为在通常的情形下，付款方和收款方的资金都存放在银行里。支付将会涉及从买方银行账户把资金转移到卖方银行账户的过程。
银行的核心诉求是能够按照客户的支付指令，按时按量完成资金的转移，从而赚取银行的服务费用。银行要在约定的时间与支付机构进行对账，确保双方所处理的支付请求可以匹配。银行还要帮助支付机构完成结算后的出款活动。图5-1 展示了银行在支付生态体系中的作用。
有些银行对支付的参与度更深，因为他们为了服务好在本银行开户的商户，需要帮助商户完成收单，或者委托第三方支付公司帮忙服务好商户。也就是说，银行可以直接地或者间接地参与支付活动。在某些复杂的情况下，银行还会给买方提供买方信贷，或者为卖方提供应收账款的融资便利，例如应收账款的保理业务。
5.1.3卡组织
如果支付涉及银行卡，那么卡组织将是银行之外的另一个参与者。通常，从卡组织的角度看，付款人就是持卡人，卡组织透过发卡行为持卡人提供底层的基础网络和授权认证服务。收款人也就是商户，有自己签约的收单行，收单行透过卡组织与开户行间接完成支付信息的交换和资金的结算。卡组织的核心诉求是高效且安全地提供银行卡服务，从而赚取银行卡支付处理费。
5.1.4支付机构
支付机构可以在买卖双方之间充当中间人的角色，或者接受卖方的委托，代理收取买方支付的与货物或者服务相对应的资金。支付机构的核心诉求是准确、准时和安全地帮助买卖双方完成交易资金的交割。在交易的过程中，支付机构帮助卖方向买方银行发出支付扣款的指令。支付机构有责任管理好交易过程中存在的信用卡风险。配合金融监管机构调查潜在的洗钱和恐怖融资活动。
5.1.5监管机构
根据支付请求的具体情况，支付交易还有可能涉及政府或者行业监管机构，例如各地的人民银行、国际、国家和地区的反洗钱中心。金融监管机构的核心诉求是确保支付活动符合国家的法律和规范，例如外汇管制法规和信贷管理规范，要求支付机构定期上报所处理的支付请求，以核查可疑的交易。
下表概括总结了支付相关主体的作用和诉求：
作用 | 诉求 | |
付款人 | 付款 | 能按时按质按量付款 |
收款人 | 收款 | 能按时按质按量收款 |
发卡银行 | 为付款人提供银行账户 | 赚取银行服务费用 |
收单银行 | 为收款人提供银行账户 | 赚取银行服务费用 |
卡组织 | 为卡支付提供基础网络和服务 | 收取基础网络和服务费用 |
支付机构 | 为付款人和收款人提供中间服务 | 收取支付处理费用 |
监管机构 | 调查反洗钱和打击恐怖融资活动 | 确保支付活动合规合法 |
表5-1 支付相关主体的作用和诉求 | ||
总之，支付机构不仅需要拥有强大的技术架构和健全的业务管控体系，以保障可以高效、安全和顺畅地处理支付请求，让付款方和收款方满意，而且还需要能考虑和照顾到其他利益相关方的各种需求。全面透彻地理解这些诉求和作用，并且归纳和提炼出相关的功能是成功构建支付的技术架构和业务管控体系的关键。
5.2支付机构的功能
本节将以利益相关方为主轴，从业务功能的角度，对支付机构应该具备的业务功能和相应的技术保障体系进行讨论。一个典型的支付机构要想提供能满足各个利益相关方的核心诉求，就必须要系统地分析并掌握各个利益相关方在支付过程中的功能需求。
5.2.1 为付款人提供的功能
为付款人提供的功能，最基础的是银行提供的借记卡，以及六大卡组织通过银行发行的各种信用卡，在此基础上还包括预付费卡，白条和先买后付（BNPL）卡。不少支付机构还提供积分和商品券（Coupon）等功能。
除了这些支付卡以外，支付机构还研发了各类电子钱包来方便消费者完成支付。
在中国主要包括微信钱包、京东钱包、百度钱包和支付宝钱包，另外还有银联和工行、农行、中行、建行、交行和招行等各种商业银行也在提供各种钱包，甚至还有很多最新式的数字货币钱包。
在日本，主要包括PayPay，LINEPay，DoCoMoPay，AuPAY、QuoPay和RakutenPay等近20多种各式各样的钱包。
在美国主要包括PayPal，Square，Vemo, ApplePay，GooglePay和AmazonPay钱包，以及诸如Wells Fargo，Bank of America, Citibank, JP Morgan Bank等各商业银行的钱包。
这些钱包在形式上大同小异，主要功能基本上都包括：在线支付、扫码支付和余额支付，在中国，现在还有不少的钱包开通了数字货币支付的功能。
5.2.2 为收款人提供的功能
支付机构需要为收款人，即卖方或者商户，提供收单的功能以及收单完成后的资金处理功能。这些功能听起来简单，实际上做起来会有很多挑战。因为它的易用性和安全性会影响到海量消费者，系统的可用性和可扩展性会影响到商户日常营业的开展，具体描述这些必备的功能如下：
（1）收单功能
处于业务前端的支付收单功能。这些功能通常是以诸如POS机、扫码和生物特征识别设备这样的硬件方式出现，也可能是以软件系统集成的方式出现。例如，传统收银综合机和云端POS机等。这些硬件或者软件都是为了帮助商户能顺利达成交易，接收和处理消费者的支付请求。
（2）查询统计
处于业务后端的查询统计功能。这些功能通常是商户常用的查询功能，例如支付请求详细查询、支付请求汇总查询、每日交易对账、周期性的结算、支付数据分析报告等，这些都是商户在经营过程中必不可少的功能。从本质上讲，这些功能属于商户的后台业务运营系统MBOSS（Merchant Backend Operation System）。
（3）接入功能
除了收单和查询功能之外，支付机构也会帮助商户快速接入支付请求处理系统。这部分的接入功能需要易用性好而且安全度高，尽量不要让商户花费太多的时间和精力接入。因为该部分接口是用来接收来自于商户端的支付请求，同时向商户回传支付成功或者失败的状态信息，所以这部分功能做得好坏会直接影响商户对支付机构的信心。
（4）数据分析
根据收单请求，支付机构帮助商户完成各维度的数据分析。例如，支付请求的时间序列分析，即支付请求在每分，每小时，每天，每周，每月，每年等不同颗粒度的数据聚合。这些数据可以帮助商户深入了解自己的业务发展趋势和走向。也可以按照支付资金的来源情况分析用户的支付行为，例如，哪些钱包受消费者欢迎？哪些积分比较受欢迎？这些结论对商户在未来获客引流都有一定的启发。
5.2.3 支付机构的功能
除了要满足支付业务生态体系中利益相关方的诉求之外，支付机构还要拥有一整套用来处理支付请求及其相关业务的系统功能。这部分是支付系统的核心。按照业务发展的顺序描述这些功能如下：
（1）支付前的功能
这部分的功能也被称为KYC（Know Your Customer）。所谓KYC，是指在支付请求发生之前，支付机构了解和掌握商户真实身份的过程。KYC的主要目的是保证业务的合规性，对与支付业务而言就是要保证所提供的支付业务不会被用来洗钱和资助恐怖主义活动等违法的活动。
通常KYC所涉及的真实性检查可以通过线下物理访问商户，或者根据客户提交的申请材料，通过政府权威机构数据库来查询，最终确保商户的真实性与合规性，具体地说，这些功能包括了合约、申请、审核、批准和开通五个部分。
（2）支付中的功能
这部分功能主要发生在商户的支付业务开通之后，商户首先要与支付机构对接系统，以便把支付请求传送给支付请求处理系统进行处理。其次，这些功能还包括了支付机构接收支付请求、解析支付请求、风险管理、形成指令、发送指令、结果通知、分账算费和客户服务等活动。
这些活动是整个支付活动的核心，既包含了商户与支付相互作用的体系，也包含支付机构与银行与其他金融机构相互作用的体系。支付机构的系统把商户的支付请求，转换为银行或者其他金融机构可以理解和操作的支付指令，完成资金的交割工作。
（3）支付后的功能
在支付请求处理完成后，还有后续的环节需要继续完成。支付机构要准确地处理好商户委托收取的交易款项，以便能在规定的时间把累积的资金转移给商户。这部分的功能主要包括账务、账户、对账、结算、出款、统计和报告。支付中所完成的资金交割是在银行或者其他金融机构之间完成的，真正把消费者支付的资金转移给商户是在支付后才完成的。
所以，支付后的活动主要包括检查和确定支付中发生的支付处理活动及其相应的状态，计算出支付机构代收的备付金的数额，然后按照约定的时间和方式把备付金转移给商户。
5.2.4 与银行相关的功能
银行是当前消费者开立账户放置和存储资金的金融机构，银行的账户具有金融属性。支付机构属于非金融机构，并不能直接操作银行或者其他金融机构的账户。为了能有效地处理支付请求，支付机构必须要接入银行、卡组织和其他的金融机构。
这种接入是支付机构主动发起的API对接工作。有些支付机构把这部分功能抽象成可以反复使用的机构接入服务。如果能把机构接入部分做得灵活，不仅可以提高接入的效率，而且还能减少接入占用的资源。
这部分的功能主要包括金融机构支付接口的参数解析和转译等。支付机构与银行之间通常采用专线连接并使用硬件的加密机。除了接入之外，支付机构还会构建与银行的对账子系统，以及为了出款自动化而完成的企业网银对接。
5.2.5 为监管机构提供的功能
支付机构有义务定期或不定期地向监管机构提供支付请求活动的信息，甚至接入监管机构的系统，以完成反洗钱和打击恐怖融资的调查配合工作。这部分的功能主要是反洗钱系统，一般会有专业的反洗钱机构提供，然后集成到支付机构的技术体系中。
中国的支付机构还要依法完成与中国人民银行备付金管理系统相关联的备付金报告和集中功能。除了央行的备付金报备之外，中国的支付机构还面临着来自于公安部门、外汇管理局、人民银行的反洗钱中心、人民银行的支付结算部门，人民银行的在各地的营业管理部。
综上所述，支付机构要能够为在支付生态体系中的各利益相关方提供各种必须的业务功能，这些功能构成了支付的业务体系，进而决定了支付技术体系应该如何搭建。下图汇总展示了支付机构所需要具备的核心功能。
5.3 对支付技术架构的要求
不同于游戏、短信、直播、广告和电商平台。支付业务涉及资金处理，范围广而且功能复杂。支付的技术体系需要满足高可用性、高安全性、高效率和可扩展性四个方面的要求。详细描述这四个方面的要求如下。
5.3.1 高可用性
支付的技术架构必须要能够做到7*24*365不间断地提供服务，核心系统的可用性至少要能达到99.99%，也就是说每年最多只能有52.6分钟的宕机时间, 最好是99.999%。如果技术的体系架构设计得合理，运维得当，优秀的支付技术系统的可用性甚至可以与IBM主机系统相当水平的99.999%媲美，也就是说每年宕机5.26分钟。
这是一项非常具有挑战性的工作，也是非常高的标准。毕竟在资源的冗余度和高可靠性设计方面无法与IBM的主机系统相提并论。高可用性不仅仅是一个技术架构的设计问题，更需要技术管理最佳实践的有力配合。本书将在后续章节专门对此进行分析和讨论。
5.3.2 高安全性
支付涉及的是银行账户或者银行卡相关的信息 （PCI），数据和应用与资金相关，所以其价值极高，对于外界很有吸引力，深受黑客的关注。同时，在支付的过程中，还会涉及商户的法人信息，以及消费者的个人身份识别数据 （PII）。
如果这些数据出现泄漏，同样也会带来很多潜在的问题。所以支付的技术架构必须要处理好信息安全，高安全性是支付业务成败的关键。关于支付卡数据（ PCI）和个人身份识别数据（PII）保护方面的有关内容，本书将会在〈第12章 支付的信息安全〉中进行详细的讨论。
衡量支付系统安全性主要看下面两个方面：
第一，系统是否已经获得必要的安全认证，对支付机构来说，最重要的就是PCI-DSS认证。
第二，系统是否已经取得公安部门的《信息安全等级保护》认证。
第三，系统是否通过定期性的脆弱性安全检查，并且不存在中高等级的安全漏洞。
5.3.3 高效率
支付的收益模式是赚取支付请求处理费用中的一个部分，所以支付的技术系统在处理每笔支付请求的时候。成本要足够低。支付的处理费一般会按照交易金额的某个比例来收取，例如1%，也就是说100元的交易可能最多只能收到1元的支付处理费用。如果不能形成规模，同时以非常高效率的技术手段自动化处理支付，则很难赚到钱。计算单笔交易成本的公式如下：
运维成本：包括IDC或云服务基础设施的成本，以及维护技术平台的人员成本。
支付总笔数：所有在支付系统发生的支付请求的个数，含退款和取消。
一般来说，单笔支付的技术运维成本并没有什么绝对的意义。更多的是支付技术体系内部以时间为轴线的自我对比，目的在于确保支付的技术体系可以不断地得到优化，从而提高效率降低成本。下图展示了某支付机构的单笔交易成本变化情况。
5.3.4 可扩展性
所谓的可扩展性是一个架构术语，是指支付系统的架构在外部支付请求不断增加的情况下，不必修改应用程序，可以通过增加系统的资源来满足外部的请求。
在现实生活当中，支付机构所支持的各种商业活动，经常会有促销、爆款、打折等带来的海量高并发请求。这种海量的高度发会在瞬间对支付系统的计算、网络和存储资源带来巨大的冲击，甚至会因此而瘫痪并导致支付系统的服务中断。
我曾经经历过几次支付系统的严重失败情况。2015年我在中国的某宝支付工作，当时某电商平台联合了一家智能手机制造商进行打折促销活动。活动从上午10点准时在网上开始，刚开始没有几分钟，监控部门（NOC：Network Operations Center）就发现支付系统的响应非常迟缓，而且越来越慢，出现了请求排队和阻塞现象。与此同时，电商平台上骂声此起彼伏，客户服务电话被打爆。
不久，技术运维团队发现有上万笔支付请求在不到10秒钟的短时间内蜂拥而来。因为每笔支付请求都需要应用系统中的数据进行锁表以更新商户的账户，结果造成数据库无法及时响应，直至最后系统完全瘫痪。活动当然也以失败告终了。
由此可见，支付系统的技术架构必须具有良好的水平可扩展性，才能经得起大风大浪的考验。所谓良好的水平可扩展性，指的是当外部的请求增加的时候，可以通过不断增加设备来实现容量的扩展，而且这种扩展不存在任何障碍。那么，如何才能够设计和研发出具有高可用性、高安全性、高效率和可扩展性的支付技术架构呢？
《一本书读懂支付》特别推荐，有关支付的前生后世。
评论区点赞前3获得新书一本。（文章发布后第三天00:00统计）
让你成为首批彻底搞懂支付的人！支付领域标志性著作，支付领军人物在中、美、日等4国30年经验总结，中国银联执行副总裁力荐，360°解读支付。
优惠购书链接（6.5折）点击阅读原文
可以加入技术琐话读者群，请后台回复：读者群
往期推荐：
-
今年这情况，大家多一手准备吧。。。
从管理1800人团队到退隐江湖，聊聊张雪峰
整理：开源LLM，可微调的项目列表
新书上市 | ChatGPT之父Sam Altman强推，国内首部顶级AI学者GPT原理解释之作
别纯技术视角想问题，论ToB的N种“死”法
AI，多赚了1000
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。
