收银台是整个支付系统的交易业务的前置，是离终端用户最近的支付交互入口，这里主要介绍与之对应的支付后端的服务。支付后端的服务主要负责与收银台前端配合，同时与商户服务端进行通知交互和配合，为用户提供支付验证、结果及周边的服务。
支付后端一般提供以下服务。
1、收单服务
通俗地来讲，收单服务就是帮助收银台完成用户支付功能，将用户的钱（资金）结算给商户或第三方支付机构账户。
该服务通常对应的是支付订单收单（下单）API （提供的类型包含移动终端SDK、手机网页及PC接口），首先主要通过此接口传入商户相关订单参数、用户账号信息、商户信息等，通过此服务将完成对支付订单参数和商户授权数据的验证；之后完成设备信息、户信息等风控基础数据的收集和验证；最后，查询支付渠道及 优先级排序并唤起支付页面，用户在支付确认页面选择相应的支付方式并确认结算，这时将产生用户资金的变动，支付后端会接收到交易引擎传过来的支付结果，最后通知商户或收银台为用户展示最终的支付结果。
如图1所示为收单业务流程图。
图1
在收单业务流程中还包含风控信息收集、交易订单提交、订单参数验证、支付渠道获取和路由、支付数据结果拼装、商户系统通知等服务。
在收单服务完成之后，会在订单数据中记录商户提交的订单数据，并生成对应的下单编号与商户编号。
2、订单参数验证
在进件的过程中，商户会提供自己所经营业务的一些数据、安全证书和文件资料，以入驻第三方支付机构或商业银行（以后称上游），上游在审核完这些内容后， 会给商户分配对应的标识、上游数据公钥、加密方式及数据编码格式。
在商户系统提交下单信息时，支付后端会对商户提交的订单参数进行验证，最先验证的是数据编码格式，一般会采用约定的UTF-8编码或GBK编码格式，否则解析出来的订单可能会出现乱码或格式错误，然后对必要的字段进行检查，主要是缺失检查、 顺序检查、特殊字符检查和数据格式检查，如下所述。
（1）缺失检查。指对应的字段是否有按约定的开发者指南文档填充好，比如商户标识、数据签名字段、商户订单号及订单金额等数据信息。例如：商户标识merchant id的字段如果为空、写错或者大小写不规范，支付后端的服务就会判断对应的参数不合法，返回对应的错误信息。
（2）顺序检查。指支付后端的服务会检查商户或收银台传入的参数，是否有按字段的首字母进行升序或降序排列，这种方式一般常见于GET方法的Web支付后端接口或收银台页面，这除了提升了查找性能，还方便了人工查验。例如：订单编号orderjid和商户标识merchant_ id如果按订单字段升序，商户标识字段就会出现在订单编号字段的前面，降序则反之。
（3）特殊字符检查。指在订单数据中不能包含HTTP特殊字段（?、&、=等）、换行符、空格及其他第三方商户系统误加的字符，并且在自定义的附加字段中不能包含上游渠道的保留字段，例如：biz_ content的JSON数据不能包含商户标识merchant id这样的字段，因为这样容易使服务端产生歧义。
（4）数据格式检查。指对订单数据中的数据格式进行检查，例如：金额的数据格式由阿拉伯数字和“.” 字符组成，为冲文或其他字符时不合法，对中文-般采用UrlEncode处理。
在对以上检查类型项都检查完毕之后，后面就要对数据的合法性和风控数据进行检查了，其中主要是对数据签名进行计算和核对 ，确保数据没有被篡改，通常的做法是采用非对称加密算法（RSA算法签名和验签数据）。
数据核验和验签[31的方法有两种：使用RSA还是RSA2验签（SHA256WithRSA算法，支付宝最高安全级别的加密验证方案），这是依据商户自己在进件或请求时使用的密钥格式是RSA还是RSA2来确定的。
支付后端的服务使用商户进件时存放在上游内的密钥数据对（平台的公钥数据和商户的私钥数据）当前订单数据进行签名，这种非对称验证方式只能使用对应格式的商户公钥来验签，否则验签失败。
3、风控信息收集
风控信息收集指支付后端为风控系统收集相关设备、环境、账户及用户行为等类型的基础数据，为后续的安全可信支付打下坚实的基础。风控系统要求采集的数据很全面并且很具体，这样才能判断准确。
风控数据收集从账户登录开始，始终贯穿着整个账号登录、下单、支付流程。
典型的应用场景有账号（账户）登录、验证码验证和填写、忘记密码、修改密码、下单、 支付、返回交易数据并验证及用户通信方式改变（丢手机、解绑手机）等。
收集的数据包含以下几种。
（1）账户数据。一般是第三方支付机构的会员账户数据、银行卡（网银）账户数据及具有-定信用价值的商户会员数据，风控系统可以根据账户相关数据判断是否被禁止交易、当前的信用等级和以往的安全交易状况，来决定是否对该账户做“限止” （停用全部或部分功能及解除风控时间，-般是由于产生了不良用记录或恶意行为）或限定（限制支付方式和支付金额）交易。
（2）设备数据。一般是使用设备的固有信息（MAC地址、设备入网IP地址、设备指纹等）。例如： MAC地址可以被用作风控计算中的访问控制和风险识别点，如果交易出现在非原通用的设备MAC地址，风控系统就可以采用验证码或手机短信下行的方式来辅助验证交易用户的真实性和合法性。
（3）环境数据。这里主要指支付所在的设备和网络环境，例如网络环境（IP地址、常用WiFi热点）和交易时间数据。风控系统在运行过程中会通过查询IP数据库，识别当前交易的IP地址所在的大致地理位置，并依据以往历史交易地理位置做出是否为风险交易的判断，同时验证订单是否来源于高风险地区，然后可以通过下发验证码确认交易者身份是否合法及安全，还可以通过IP地址判断其入网情况，比如国内IP、国际IP、VPN代理的IP地址及 来自高风险地区的IP地址。其他环境数据和用法将在第6章详细讲解。
（4）用户行为数据。用户行为数据包括登录场景、下单场景、交易流水、访问记录、频繁操作次数等，基于这些用户行为数据 ，风控系统可以完善用户画像，例如：一个用户在相对短的一段时间内频繁进行账户的登录和登出，并且超过普通用户的统计基准值，这时风控系统就有理由对此账户登录做出风控规则判定，并在一段时间内停用此账户。
这些数据都会通过风控系统的场景计算模型（包含在线实时风控模型和离线风控两个常用的模型）由风控系统做出决策。例如：支付前的风险识别、支付方式限定、支付限额控制和信用级别降级支付等。
4、交易单提交
在对商户订单进行参数验证和风控系统决策之后，我们需要将订单提交给交易引擎，交易|擎对资金流进行操作，这时的订单有了另一个名称，叫作交易单（或交易订单）。这个提交交易单的业务流程看似简单，但它并不仅仅是一个请求提交和持久化的流程，其难度主要体现在订单防重复方面。
订单防重复的常见场景：网络情况比较差，顾客没有及时支付金额或支付后端的服务未及时返回支付状态，而用户又重新单击了“提交结算”按钮，这时收银台界面会显示“支付进行中，请不要重复提交订单”，这就是订单防重复功能起到的作用。
订单重复在本质上分两种情况：第1种，存在两次支付结算提交；第2种，在支付时中断通信网络，使支付状态通知不到位，造成前置的商户系统仍处于支付状态。针对这两种情况需要采用不同的解决方案。
针对第1种情况，解决方案是对商户的订单编号进行约束，即在对接第三方支付系统时，商户的业务系统在每次调用支付请求时都必须生成不同的商户订单编号，这就要求对“订单支付”按钮上面的订单编号生成做相应的修改和完善，每次单击 “结算”按钮都生成不同的商户订单编号。第三方支付系统对同一个商户订单号会做出异常处理和提示，这种方案在商户开发者指南或服务端接口文档中就要与商户约定致，以确保第三方支付机构后端产生的编号 与商户订单编号对应。
这其中涉及两种订单编号，如下所述。
·商户订单编号：指由商户系统发起并由商户自定义的订单号编号。在通过收银台SDK或调用第三方支付系统接口而发起支付结算请求时需要携带这个参数，商户系统中的编号需要确保在整个系统里面具有唯一性，一笔消费订单对应一个商户订单编号。
·支付订单编号：指在商户系统向第三方支付系统发起支付请求后，支付平台核验订单参数合法后由支付系统自身的后端系统生成的订单系统的唯一标识，用于记录-笔支付订单信息。这时第三支付系统与商户业务系统的订单编号形成一一对应的关系，同时与交易引擎产生的交易编号形成一-对应的关系。
针对第2种情况，支付后端一般采用 异步通知补偿机制来解决此类问题，通过采用定时轮询的方式扫描订单系统中处于支付状态的订单，并主动轮询商户服务端接口，将订单信息和结果推送给商户服务器，一旦收到商户服务器对订单结果的反馈，就将订单支付状态更新为“终态” ，进行关单操作，这样一来就完成了对支付订单状态的补偿。但这种补偿不是一直持续下去的，第三方支付机构的订单系统一般会制定一个由紧到疏的时间片轮询策略，例如：最初10秒、30秒、1分钟、5分钟，....，24小时，..，48小时，并在超过策略规定的时间及轮询次数后将支付订单状态更新为“失效”状态，第三方支付机构的订单状态查询接口可供商户系统自己完成支付订单状态的数据查询，以及自身业务逻辑的更新，例如：订单状态未完成但资金已发生扣款的情况下，在账务核对阶段就需要告知第三方支付系统的核算人员做差异和补偿处理。
5、支付渠道获取与路由
前面讲过，融合收银台-般会为了用户支付的便利性和交易成功率，与多家支付渠道（第三方支付机构、中国银联、商业银行等）签署合作协议，以提高支付的成功率和利润（各家支付渠道的分成比例和手续不一样），从而降低交易失败的风险。
在预下单（签约）过程中，商户应用提交商户订单数据给支付后端，支付后端对商户订单数据进行参数验证、风控，之后再将商户订单数据提交给交易引擎，这个过程就叫作预下单。最后需要经过支付渠道管理模块，给商户应用返回最优、最合适的支付渠道。如果收银台前端采用了融合支付SDK或Web收银台展示方式，则在收银台界面显示推荐和可用的支付渠道。
如果商户系统直接对接支付API的方案，则将推荐和可用的支付渠道数据发给商户应用，由商户系统自行处理支付方式渲染界面和用户交互流程。这时，商户开发者需要遵循相关支付渠道商的渠道商标和名称规范。
在支付渠道路由返回排序的支付方式给自身收银台和商户支付方式选择界面之后，户会选择合适和常用的支付方式确认支付。支付渠道路由指支付系统为用户提供智能的支付方式（交易）路径选择，并引导用户完成资金结算。
支付渠道路由的规则一般受以下因素的影响。
（1）用户自主选择。在设计支付渠道路由时，支付系统会把用户常用的支付方式或历史支付方式放在优先的位置，并且各大型第三方支付机构都会支持用户自定义支付渠道和方式并进行排序，这遵循了客户第一和尊重客户选择的基本准则。
（2）用户体验好。除了让用户自主选择，融合支付厂商和第三方支付机构还会选择用户体验较好的、较流畅的支付渠道作为推荐支付渠道来使用，用户体验好也会体现在支付流程短、操作简单方面，在整个支持方式排序计算中也会占一定的权重。
（3）风控和资金受限。融合支付厂商和第三方支付机构对风控的限定会影响对支付渠道的选择和路由，例如：高风险交易可能会选择屏蔽一些信用类支付方式，或者增加一些辅助验证身份的支付方式，在单笔订单金额较多、用户资金不足且风控允许的情况下，支付系统会推荐-些信用卡或信用支付方式供用户选择。
（4）成本优先。在做支付渠道路由时，把成本和利润放在较重要的位置，是-个商业公司无可厚非的原则，可以按照资金费率成本最低、分成比例最高、最方便市场运营的支付方式来设置路由业务逻辑。
（5）稳定性和成功率。一个支付渠道不能经常存在服务不可用、丢单或掉单等不稳定情况，支付系统也会对其进行分析和监测，所以在支付渠道设计上面一般会选择交易成功率最高的支付渠道来做推荐。
6、通知服务
这里说的通知服务指支付交易结果通知。在支付完成之后，交易引擎会把资金处理的结果给到支付后端，由支付后端将相关支付结果、订单信息和用户信息发送给自己的收银台或商户服务端，商户服务端或应用接收到第三方支付机构的支付系统通知数据之后，需要将其进行字段拆分、验证、加密处理，并给SDK或支付后端API返回对应的回复结果。
商户服务端在收到支付后端的通知并处理后，会反馈给支付后端，如果支付后端收到（未收到）的来自商户服务端的反馈是不成功（数据验证失败、数据不完整）或网络超时，则支付后端认为通知商户失败，后续将通过一定的策略（定期重发机制）重新通知商户服务端，尽可能提高通知的成功率，但支付后端不保证通知最终能成功。
支付后端一般会制定一个由紧到疏的时间片轮询策略，例如：最初10秒、30秒、1分钟、5分钟，...，24小时，....，48小时，并在超过约定的时间（一般约定最长订单时限24小时或48小时）及轮询次数后将支付交易订单更新为“通知失效”状态，同时提供支付订单状态查询API供商户系统完成自身商户订单状态的状态和业务逻辑更新。
这就是定期重发机制。
但是商户服务端会有多种因素导致这种交易结果通知延迟或失败，常见的因素主要有网络不通畅、域名解析失败不可用、商户应用平台系统服务器宕机、商户服务端或支付后端存在Bug、通知服务故障等。
同样的交易结果通知会被尽可能多次发送给商户服务端，在这种情况下就需要商户服务端有正确处理重复的交易订单结果通知的能力。
推荐的做法是（商户服务端）在收到交易结果通知之后，首先验证数据的来源是否可信，验证其是否被篡改（核查提交订单时的附加信息、支付订单金额、JSON数据结构和最长订单时限等），例如：
支付宝平台会提供一个验证公钥，可以使用验证公钥对数据进行验证，并检查业务数据对应的格式和HTTPS状态，然后从业务层面判断此交易结果通知是否被处理。如果没被处理，则再进行处理；如果已处理，则直接返回支付成功的结果。
注意：在对交易结果通知数据进行状态检查和处理时需要严格控制请求并发（例如使用数据锁定），以免业务和数据处理函数重入（重复进入，指有相同的记录或数据）造成数据出错。
7、退款服务
在已支付成功的订单中，用户因商户产品质量不合格或不满足需求等原因需要退货退款（退款发生时，用户在商户平台信用体系中的信用支付额度一般会有一 定程度的下降），在这种情况下，只要用户与商户达成退货退款协议，就需要调用支付系统的退款API进入退款流程。
退款资金一般沿原路退回，例如：收款机构（银行）和付款机构（银行）对调，原订单若采用了工商银行卡进行支付，则会退款到工商银行卡中。
退款在支付系统里面也是有时限的，一 笔成功的订单默认的退款期限是3个月，同时会提供时限（一般为签约）接口进行设置。
退款业务流程如图2所示。
图2
8、查询服务
当有一笔订单结果未通知到商户服务端时，商户服务端可以主动去支付后端进行订单详情查询并进行业务补充，调用的是订单查询接口（也叫作查询接口）。
查询接口通常分为以下两类。
（1）查询支付状态，通过接口查询某笔交易的状态，状态如下：
·交易创建，等待用户付款完成；
·用户未付款，交易超时关闭；
·支付完成后全额退款；
·交易支付成功；
·交易结束，不可退款。
（2）查询退款订单的进度状态，状态如下：
·退款申请中，通常订单还在支付渠道的退款申请和退款审核流程中；
·退款中，提交给支付渠道（银行或其他资金机构处理）；
·退款完成。
