3.支付平台架构：业务、规划、设计与实现 --- 支付后端技术实战

第3章 支付后端技术实战
	支付后端也叫支付云端，指的是部署在私有云或公有云主机上的支付后端服务应用和数据存储单元，是支付前端的有力支撑，为支付收银台，客户端，SDK和前端系统提供业务服务，
数据存储管理，数据验证，安全传输，账户管理和安全验证，资金和渠道管理，消息推送和分发，支付业务流程，风控等相关服务。

3.1 业务架构
	3.1.1 产品层
		产品层主要面向线上和线下用户，其中的用户包含C端用户，商户，金融机构等。

	3.1.2 核心业务层
		核心业务层无疑是整个支付平台架构最有核心价值的一部分，主要关注支付规则的制定，支付业务流程的实现及支付业务需求有关的产品设计，为产品层提供支付业务支撑。核心
	业务体系按业务范围来划分，可以分为用户账户体系，支付核心体系，安全风控体系，渠道管理体系及运营管理体系。

	3.1.3 数据支撑层
		1.数据资产
		2.实时，离线计算平台
		3.机器学习和人工智能
		4.数据库

	3.1.4 技术支撑层
		1.大数据技术
		2.安全技术
		3.移动终端技术
		4.微服务技术
		5.监控服务技术
		6.中间件技术
		7.数据挖掘技术
		8.消息通信技术

3.2 支付系统技术栈探秘
	技术栈是为了实现某个业务系统而采用的一系列子系统，技术框架，组件，方法，工具及配置的集合，其中的各个部分并不是孤立的，而是互相关联和有机整合的。

	3.2.1 操作系统层
	3.2.2 虚拟层
	3.2.3 Web服务层
	3.2.4 数据存储层
	3.2.5 服务端技术
	3.2.6 终端层

3.3 支付后端业务介绍
	1.用户在商户app中选择商品，并单击购物车界面的"去支付"(结算)按钮，这时会触发这个流程
	2.商户app首先会按照自己的订单规则创建一笔订单，然后将订单，商户的相关信息传递给第三方支付机构或融合支付厂商的收银台和支付后端进行预下单请求。
	3.支付后端在收到这个预下单请求后，对商户资格进行核验(授权验证的过程)，并将商户信息和账户信息发送到风控系统进行验证(发起风控挑战)
	4.在风控挑战通过后，在支付后端产生了一笔订单信息，此时预下单过程已经完毕，返回给收银台支付方式和可用渠道，展示支付界面(例如支付宝，微信支付等)
	5.用户在收银台提供的订单信息(包含支付方式)界面选择对应的支付方式，这时后端系统受到了来自收银台或商户app的请求
	6.商户系统将支付数据传递给第三方支付机构的交易引擎(此过程叫收单，交易引擎对订单中的应收和应付事宜进行处理，然后对中国网联发起付(收)款指令)。
	7.中国网联通过指令对付款行账户发起付款流程，收款行同时收到相关款项，在操作成功后，交易引擎产生相关单据信息。
	8.交易引擎在操作完成之后将结果返回给支付后端，支付后端将数据推送到收银台界面作为支付结果进行展示，同时异步通知商户服务器修改订单状态。
	9.这时用户就可以看到收银台界面的支付结果信息了。

3.4 支付后端的服务类型
	3.4.1 收单服务
		通俗来说，收单服务就是帮助收银台完成用户支付功能，将用户的钱(资金)结算给商户或第三方支付机构账户。

		该服务通常对应的是支付订单收单(下单)API(提供的类型包含移动端sdk,手机网页及PC接口)，首先主要是通过此接口传入商户相关订单参数，用户账户信息，
	商户信息等，通过此服务将完成对支付订单参数和商户授权数据的验证；之后完成设备信息，用户信息等风控基础数据的收集和验证；最后，查询支付渠道及优先级
	排序并唤起支付页面，用户在支付确认页面选择相应的支付方式并确认结算，这时将产生用户资金的变动，支付后端会接收到交易引擎传过来的支付结果，最后通知
	商户或收银台为用户展示最终的支付结果。

		在收单业务流程中还包含风控信息的收集，交易订单提交，订单参数验证，支付渠道获取和路由，支付数据结果拼装，商户系统通知等服务。

		在收单完成之后，会在订单数据中记录商户提交的订单数据，并生成对应的下单编号和商户编号。

	3.4.2 订单参数验证
		在进件的过程中，商户会提供自己所经营业务的一些数据，安全证书和文件资料，以入驻第三方支付机构或商业银行(以后称上游)，上游在审核完这些内容后，
	会给商户分配对应的标识，上游数据公钥，加密方式及数据编码格式。

		在商户系统提交下单信息时，支付后端会对商户提交的订单参数进行验证，最先验证的是数据编码格式，一般会采用约定的utf-8编码或gbk编码格式，否则
	解析出来的订单可能会出现乱码或者格式错误，然后对必要的字段进行检查，主要缺失检查，顺序检查，特殊字段检查和数据格式检查。

	3.4.3 风控信息收集
		风控信息收集指支付后端为风控系统收集相关设备，环境，账户及用户行为等类型的基础数据，为后续的安全可信支付打下坚实的基础。

		风控数据收集从 账户登录开始，始终贯穿整个账户登录，下单，支付流程。

		典型的应用场景有 账户登录，验证码验证和填写，忘记密码，修改密码，下单，支付，返回交易数据并验证及用户通信方式改变(丢手机，解绑手机)等。

		收集的数据包含以下几种：
			1.账户数据
			2.设备数据
			3.环境数据
			4.用户行为数据

		这些数据都会通过风控系统的场景计算模型(包含在线实时风控模型和离线风控两个常用模型)由风控系统做出决策。例如：支付前的风险识别，支付方式限定，
	支付限额控制和信用级别降级支付等。

	3.4.4 交易单提交
		在对商户订单进行参数校验和风控系统决策后，我们需要将订单提交给交易引擎，由交易引擎对资金流进行操作，这时订单有了另外一个名称，叫做交易单(或交易订单)。
	这个提交的交易单的业务流程看似简单，但它不仅仅是一个请求的提交和持久化的流程，其难度主要体现在订单防重复方面。

		订单防重复的常见场景：网络情况比较差，顾客没有及时支付金额或支付后端的服务未及时返回支付状态，而用户又重新单击了"提交结算"按钮，这时收银台界面会显示
	"支付进行中，请不要重复提交订单"，这就是订单防重复起到的作用。

		订单防重复在本质上分两种情况：第一种，存在两次支付结算提交；第二种，在支付时中断通信网络，使支付状态通知不到位，造成前置的商户系统仍处于支付状态。

		针对第一种情况，解决方案是对商户的订单编码进行约束，即在对接第三方支付系统时，商户的业务系统在每次调用支付请求时都必须生成不同的商户订单编号，这就要求
	对"订单支付"按钮上面的订单编码生成做相应的修改和完善，每次单击"结算"按钮都生成不同的商户订单编号。第三方支付系统对同一个商户订单编号会做出异常处理和提示，这种
	方案在商户开发指南或服务端接口文档中就要与商户约定一致，以确保第三方支付机构后端产生的编码与商户订单编码一一对应。
		这其中涉及两种订单编号：
			1.商户订单编号
				指由商户系统发起并由商户自定义的订单编号。在通过收银台sdk或调用第三方支付系统接口而发起支付结算请求时需要携带这个参数，商户系统中的编号需要在
			整个系统里面具有唯一性，一笔消费订单对应一个商户订单编号。
			2.支付订单编号
				指在商户系统向第三方支付系统发起支付请求后，支付平台审核订单参数合法后由支付系统自身的后端系统生成的订单系统的唯一标识，用于记录一笔支付订单
			信息。这时第三方支付系统与商户业务系统的订单编号形成一一对应，同时交易引擎的交易编号形成一一对应的关系。

		针对第二种情况，支付后端一般采用异步通知补偿机制来解决此类问题，通过采用定时轮询的方式扫描订单系统中处于支付状态的订单，并主动轮询商户服务端接口，将
	订单信息和结果推送给商户服务器，一旦收到商户服务器对订单结果的反馈，就将订单支付状态更新为"终态"，进行关单操作，这样一来就完成了对订单支付状态的补偿。但这种
	补偿机制不是一直会持续下去的，第三方支付机构的订单系统一般会定制一个由紧到疏的时间片轮询策略，例如：最初10s,30s，1分钟，5分钟，24小时，...，48小时，并在
	超过策略固定的时间及轮询次数后将订单支付状态更新为"失效"状态，第三方支付机构的订单查询接口可供商户系统自己完整支付订单状态的数据查询，以及自身业务逻辑的更新，
	例如：订单状态未完成但资金已发生扣款的情况下，在账务核对阶段就需要告知第三方支付系统的核算人员做差异和补偿处理。

	3.4.5 支付渠道获取与路由
		融合收银台一般会为了用户支付的便利性和交易成功率，与多家支付渠道(第三方支付机构，中国银联，商业银行等)签署合作协议，以提高支付的成功率和利润(各家支付
	渠道的分成比例和手续不一样)，从而降低交易失败的风险。

		在预下单(签约)过程中，商户应用提交商户订单参数数据给支付后端，支付后端对商户订单数据进行参数验证，风控，之后再将商户订单数据提交给交易引擎，这个过程就
	叫预下单。最后需要经过支付渠道管理模块，给商户应用返回最优，最合适的支付渠道。如果收银台前端采用了融合支付sdk或者web收银台展示方式，则在收银台界面显示推荐
	和可用的支付渠道。

		如果商