在线支付系统是由各功能模块组成，不同的平台因为业务不同，功能设计也会存在差异，但通常都会包括支付核心功能、基础服务功能、运营支撑功能及风险管理功能，以下分别对这些主要模块进行介绍，为读者构建平台支付系统提供参考借鉴。
1、支付核心功能实现
支付系统核心功能的实现主要依赖于完整的接口体系、业务流程和接口管理来实现，详述如下。
1.接口体系
平台支付的核心功能是通过接口体系来完成的，不同的接口支持不同的指令传递。主要接口至少应该包括：与用户资金账户相关的签约、解约接口；与资金支付结算相关的支付（在虚拟账户体系下为入金）、撤销、出金（提现）、退金接口；与账户信息相关的查询、对账接口。因为支付中心介于业务系统和支付渠道之间，所以这些功能的实现是通过上下行接口来实现的。上行接口负责处理与业务系统间的数据交互，对于不同业务场景而言，接口一致；不同支付需求，可通过系统设置及不同接口字段实现。下行接口连接支付中心与合作支付渠道（支付服务提供方），不同渠道提供不同接口接入方式，支付模块整合后按照不同业务场景需求对业务系统提供服务。接口体系如图1所示。
图1 支付中心接口体系
通过以上接口体系，支付中心连接平台业务系统与支付渠道，传递支付相关指令，并实现通知回传、查询等功能。比如商家信息接口处理、接收商家账户信息，含商家结算账户信息绑定以及商家账户状态查询接口。支付接口则通过配置实现不同场景、不同渠道、不同需求的买家支付指令差异化处理，含付款处理接口、付款通知接口、支付状态查询接口。结算接口则针对担保支付场景，支持由买方根据物流情况控制资金结算时间的数据处理逻辑。
2.支付业务流程
除了查询、对账和短信验证功能外，所有支付核心功能的实现都是通过用户、业务子系统、支付中心和支付渠道直接通过各类接口发送指令来实现的，支付中心支持支付业务流程的核心功能包括：参数校验、根据路由规则选择不同支付渠道、调用风控弓|擎进行支付风险评估和处置、调用支付渠道服务、服务结果反馈和订单状态修改。
以业务系统发起的是直接支付业务为例，流程示意图如图2所示。
图2 支付业务流程示意图
（1）支付请求的发起
业务系统根据不同的支付场景发起支付请求，通过调用上行接口将该业务系统的密码因子、买方用户ID、方用户ID、支付金额、分润比例等信息通过上行API上传到支付中心收银台。
支付场景可以分为直接支付、担保支付、充值扣费等。
（2）支付请求的处理
支付中心收银台通过密码因子、签名验证、身份验证等参数校验、账户可用性判断和金额核对等对业务系统发出的支付申请进行处理，推送可用支付方式，支付中心匹配支付渠道。用户确定支付方式和支付渠道，服务申请通过风控系统审查后，支付中心生成支付订单。
①真实性有效性验证
支付中心在处理业务系统的支付请求时需要执行参数校验，避免接口受到攻击。
√验证支付请求中包含的各字段的有效性，比如买方ID，卖方ID，订单金额、返回地址、业务系统密码因子等参数。
√验证买卖双方的账户是否处于可交易的状态。
√验证订单状态是否为未支付订单，以避免重复交易。
②支付风险评估
在向支付渠道分发指令前，支付中心需要调用风控系统的风控引擎对用户的服务请求进行分析判断，并根据系统输出的处置结果指|用户进行下一步操作，处置结果分为：拒绝、通过、增强验证和人工审核四种。风控系统的功能设计和运转流程见后文的风控系统部分。
③支付渠道匹配
根据用户选择的支付方式，支付中心会根据支付中心对接的支付渠道提供的功能、费用情况以及收付款双方的开户情况等因素匹配合适的支付渠道。比如用户选择担保支付，只提供网关直接支付方式的渠道便不会推荐给用户。用户选择余额支付，那只有用户开设了内部账户的银行支付渠道才能完成此服务。
④付款页面推送
在匹配支付渠道后，系统会将第三方支付对接的银行列表或者直联的银行列表推送给用户，用户在付款页面根据自身开户银行进行付款银行选择，选择后直接跳转到该银行的登录入口。此时用户还可以选择使用企业账户或者个人账户进行支付。
（3）支付指令发送
通过风控审核后的支付服务请求会被支付中心生成支付订单，并将支付订单信息通过下行API分发到相关支付渠道，支付渠道通过平台KEY验证对该支付指令的身份和有效性进行验证，验证通过后将该支付指令通过银行网关发送到银行后台处理系统。其中平台的KEY验证又称签名验证，是由支付渠道使用分发给平台的KEY对输入参数拼接成的字符串做MD5Hash或者RSA加密，然后作为一个参数随其他参数一起提交到服务器端，以验证支付接口是否被伪造。
支付指令通过支付系统的定时任务管理、担保支付管理、退款管理等模块实现。定时任务管理是通过设定系统结算指令发送时间，实现用户已支付资金在扣除佣金后定时自动结算给商家，通常支持T+1直接支付方式。担保支付是在用户完成资金支付后不执行T+1自动结算，根据子系统用户确认收货指令或默认收货时间向支付通道发布清分结算指令。退款指令则是在用户资金支付后但资金尚未结算到商家之前，根据商家确认可以退款的信息，调用退款接口完成资金的原路线退回。
（4）支付结果的返回
用户根据支付通道的提示通过插入UKEY或输入动态口令完成实际支付操作，银行将支付结果通过支付渠道回传到支付中心，支付中心记录回传数据后再将支付结果回传到业务系统，业务系统根据回传的支付结果完成订单状态的改变。
由银行提供的支付服务和由第三方支付提供的支付服务在支付结果的返回上有一些差异。使用银行支付渠道时，银行进行不同账户间的支付操作后会直接返回是否支付成功的结果，而第三方支付渠道由于还需要由其自身的支付系统调用银行支付接口，银行返回支付结果后，第三方支付只能通过异步接口将支付结果返回到支付中心。
（5）账户及付款状态查询
为解决付款结果通知时网络通信等问题造成的数据不同步问题，运营人员可以调用付款状态查询接口对订单状态进行查询。
与支付业务流程管理类似，支付系统可以通过调用退款、结算接口，接收业务系统的退款和结算请求，经过处理后完成相关业务的资金处理。
3.接口管理
支付中心对于支付渠道的接口管理有两种方式。一种是按照接口的功能服务来区分，针对每一种功能单独建立子系统，如签约子系统、支付子系统、结算子系统、退款子系统、对账子系统等。每个功能子系统都单独部署，最后由支付中心调用不同容器提供不同功能服务。
无论哪一个支付渠道如果要提供某一个场景的服务都需要调用该功能接口，例如用户签约时，会先调用签约接口，然后分发到不同的支付渠道。另一种是按照对接的不同渠道来拆分，是指每个渠道都单独部署在一个容器中，对支付中心提供大致相同的服务，如中金支付的开户、支付、对账功能，或者华夏银行的开户、支付、对账功能。
按照服务来拆分的一个典型案例是大众点评网在支付建设的第二阶段进行的接口管理模式，主要是考虑有些支付渠道用户使用频率不高，单独部署会造成资源浪费。这种模式虽然解决了不同支付业务不再相互影响的问题，但同一业务内部，不同的渠道之间会互相影响。
随着业务量的增加，这种问题逐渐凸显。例如用户发起的直接支付请求会率先进入支付服务子系统，对不同的支付渠道统一提供分布式的支付API，所有渠道共享同一个服务RPC连接池。这样一旦某一个渠道的支付接口因为故障造成性能恶化，会导致大量占用服务RPC连接，从而其他正常渠道的请求都无法进来，户的支付请求得不到及时有效的响应，复尝试还会引起系统崩溃，会严重影响用户体验。
而且，由于支付中心的渠道网关系统只是在后端生成支付重定向URL与某一个第三方支付渠道进行交互，因此只能通过第三方支付渠道的异步通知或支付中心主动进行支付查询才能得知最终户支付结果。
如果该第三方支付渠道内部发生故障，支付中心的渠道网关系统将完全无法得知该支付链路已损坏，后续分发指令时便会造成支付请求失败的情况，同样伤害用户支付体验。更何况不同的银行和第三方支付在向平台开放接口时有各自不同的接口标准，将不同的支付渠道部署在一个容器中很难满足所有渠道的接入需求。所以目前绝大多数平台在构建自己的支付中心时都会采用按照渠道进行接口管理的模式。在这种模式下，不同的渠道单独部署，某个支付渠道出现问题不会影响其他支付渠道，而且同一个渠道对不同服务的加密、解密方式和报文格式样，可以减少支付中心对于输入输出进行加密、解密及组装和解析报文的开发工作量。不同的支付渠道可以访便选择不同的接入模式，如银行出于安全角度的考虑，通常会要求平台配置单独的前置服务器，银行支付系统对接到该前置机上以减少银行系统的暴露风险。
按照渠道部署可以方便支持支付渠道的这种个性化需求。对于访问量较小的支付渠道单独部署造成的资源浪费问题，可以通过平台的docker的资源调度来解决。
接口管理还需要根据接口管理模式及新增渠道情况进行接口的新增、修改、权限配置等基本操作。
2、基础服务功能
支付系统基础服务功能是对支付核心功能的服务保障。
1.支付渠道管理
对于不同支付渠道的接口、参数、支付服务费用、支付限额等进行管理。
2.用户管理
对于使用支付系统的用户进行管理，包括用户身份识别、用户权限管理、户账户的审核、查询、冻结、解冻、加入黑名单等管理。
用户实名认证信息的查询、维护，包括。用户登入、登出状态的记录，查询和风险管理。
3.账户信息管理
对平台所有使用支付服务的用户资金账户进行管理，包括签约、解约状态查询，银行账户信息及变更记录查询，账户入金、出金、转账记录查询，账户冻结、解冻和加入名单。
4.日终任务管理
该功能主要指基于结算等业务的处理，在每日指定时间点执行结算申请、对账等一系列任务，完成对当日交易的汇总和处理，其功能类似于财务的日结工作。
其中对账功能支持支付中心与各支付渠道以及支付中心与各业务系统的对账。提供双向对账功能，即支付中心可以调用支付渠道的对账数据，反过来支付渠道也可以调用支付中心的对账数据。
5.差错数据处理
差错数据处理是运营支持功能中一项重要的功能。因为支付中心在调用支付渠道支付、支付通知、退款、结算接口返回时，会发生因网络原因或者硬件原因弓|起的通讯异常，导致支付平台与第三方支付渠道的数据不同步，要支付中心定时调用第三仿对账接口，将返回的数据与支付中心的数据进行比对，将差异数据列表展示在支付运营平台上，采取人工干预对数据进行修改。差错对账处理又包括结算失败处理、支付状态不同步数据处理等。结算失败处理是因商家账户信息错误等原因导致结算失败后的处理。支付状态不同步是因网络通信等原因导致支付状态不同步的订单的处理。
3、运营支撑功能
运营支撑功能是支付系统提供给平台运营人员（含支付中心运营人员）进行查询、管理和决策支持的功能。
1.对于业务系统接入支付中心的管理和服务功能
（1）通过开发者服务为业务系统研发人员提供接入指引服务，包括支付功能介绍说明、接入指南、开发DEMO、API接口列表及代码示例等。其中开发DEMO可以模拟子系统调用，用于支付流程演示及内部逻辑测试，供业务系统接入支付中心时进行接口测试。
（2）接入授权：对业务系统接入支付中心的申请进行处理，包括权限配置，密码因子分配及管理子系统调用支付时对应的密码因子。
2.对支付系统运营人员的服务功能
包括支付订单、结算订单、佣金结算等支付相关数据的查询、统计和分析，按不同维度形成统计报表，用于运营分析决策。其中支付订单统计表，可以按时间、支付状态、订单来源等不同维度查询生成。
结算订单统计表可以按时间、结算状态、订单来源等不同维度查询生成。佣金结算统计表可以按时间、结算状态、不同商户等维度进行查询生成。
3.对平台用户的服务支持功能
（1）票证管理：向用户提供支付相关票证，如电子发票、电子回单等。
（2）清算分润：对于有分润需求的商户，提供清分清算、对账处理和计费分润功能。
（3）在线帮助：根据支付服务规则变动随时修改在线支付帮助文件，并发布到前台供用户查看。
4、风险管理模块
风险管理也是支付系统的必备模块，以下从该模块的主要功能、使用场景和业务流程三个方面对该模块进行解析。
1.风险管理模块主要功能
风险管理模块是支付系统的重要组成部分，通过与平台整体安全保障系统的配合来实现平台支付安全双保险。
风险管理系统主要包括风控规则制定和管理、白名单管理、风险事件审核管理以及包括用户管理、权限管理、日志查询、系统配置等基本管理模块。
结合风险管理相关的规则制度，实现风险管理规则确定、风险事件的识别与采集、事件分析、风险处置、数据存储、风险管理优化的流程闭环。通过特定的风险识别规则和模型建设、实时计算及异步数据处理等技术，实现支付风险的事前、事中、事后控制。
日志分析：日志是支付系统统计分析、运维监控的重要依据。公司需要提供基础设施来支持日志的统一收集和分析。
安全机制：安全是支付的生命线，SSL、证书系统、防刷接口等都是支付的必要设施。
2.风险管理模块使用场景
当业务系统开始使用支付中心服务时，如注册、开户、认证、绑定账户、修改密码、支付申请、退款申请、转账结算申请等，支付中心都会调用风险管理系统对用户及服务进行分析处理，并返回四个结果：拦截（拒绝），增强验证，人工核实和通过（放行）。通过（放行）表示服务请求没有问题，可以直接放行。拦截意味着本次服务请求属于高风险业务，所以阻止本次服务请求。增强验证意味着对服务请求存疑，需要用户进一步提交相关信息进行验证后方可转为通过。
比如未经过平台实名认证的企业和个人用户在开设内部账户时，会要求对方先通过平台实名认证，需要提交营业执照、法人身份证等相关信息。人工核实则意味着对服务申请存有疑问，要人工干预处理的情形。
3.风险管理模块业务流程
风险管理处理流程如图3所示。
（1）规则弓|擎
风控规则定义风险类型和范围，规则弓擎基于基础数据库计算风控规则。比如发现服务请求方是白名单库中的用户，则可以直接放行。
如果是黑名单中的用户，则会直接拦截。新用户则看其服务请求是否属于风险事件范围。
图3 风险管理处理流程示意图
（2）风险事件拦截
规则引擎通过计算风控规则，拦截需要进行分析处理的服务请求，并采集输出到分析引擎。
（3）分析弓|擎
分析弓|擎根据风控规则定义的事件判断标准进行分析处理，将分析结果输出到事件处置模块。
（4）风险处置
对于分析弓|擎输送的分析结果进行进一步分析，生成风险处置结果（包括拦截、增强验证、人工核实、通过），将结果反馈到用户及支付运营人员。用户根据系统或者人工反馈的结果进行相关操作，如补充信息资料，输入验证码等。
（5）数据存储及规则优化
系统将本次服务请求的过程数据和结果数据存入相关数据库，风险管理系统通过对存储数据的跟踪分析对黑白名单进行更新，优化风控规则。
（6）其他安全保障
运维监控：支付系统在运行过程中不可避免地会受到各种内部和外部的干扰，如光纤被挖断、黑客攻击、数据库被误删、上线系统中有bug等等，运维人员必须在第一时间内对这些意外事件做出响应，又不能一天24小时盯着。这就需要一个运维监控系统来协助完成。
