（简单记录，欢迎一起讨论）一般的支付系统由上游端+自己公司系统组成或者上游+自己公司系统+下游商户

上游：指处在整个资金链的开始端，为下游提供不同接口增/减金额（简单理解：银行提供充值、消费、提现等接口，支付宝、微信等第三方支付公司去对接。微信对接银行后，可以自己再开发一套支付系统，为微信用户提供充值、支付、提现等功能）

下游：和上游对接后，会在上游有一个存储金额等信息的账号，此时就可以为自己系统的用户提供充值、消费、提现等服务了。需要说明的是下游也可以自己开发一套接口，为其他公司提供服务，此时下游就变成了上游，这涉及到签约费率（简单理解：用户在微信里面有一个账号有100元，微信在银行的账号里面也有100元。用户在微信账号上的金额操作最后都会体现在银行端）

举个列子：微信a用户和b用户同时从各自账号提现了100元到银行卡，此时微信在收到提现请求后会在自己系统处理一遍，扣除用户微信账号里面的100元，最后微信发转账请求给银行，银行扣除微信在银行端账号里面的200元，分别为a用户和b用户提供的银行卡添加100元

下面我重点说明下之前接触的支付项目。此项目即对接了上游，也为下游提供服务接口

一、涉及的系统罗列

支付项目主要包括消费订单系统、商户管理系统、清结算系统、路由系统、风控系统、账务系统、出款订单系统，另外还有商户服务平台和运营管理平台

消费订单系统：主要处理消费下单请求和转发请求。包括后台逻辑，如：商户权限判断、大额拆单、修改订单状态等

商户管理系统：商户入驻、商户签约等围绕商户的系统

清结算系统：主要是结算系统，对当天交易成功的订单进行结算（商户签约时有标注结算是按D0或者T1等方式结算）

路由系统：主要是指金额操作走那个上游（比如说我们的上游有易宝、惠利宝等，根据逻辑判断会请求到不通的上游）

风控系统：大额交易都有监管，单笔金额、当天累计金额限制

账务系统：管理金额，对商户账号金额增、减操作的最底层系统

出款订单系统：主要处理出款订单请求和转发请求。包括后台逻辑，如：商户权限判断、手续费计算、修改订单状态等

商户服务平台：为商户提供的平台，方便用户查询订单、提现、查看商户id和秘钥等功能

运营管理平台：提供给运营管理的后台，包括商户信息、订单信息等

二、消费订单系统涉及的处理

1.网银支付下单

流程说明

1.在商户网站上银行卡支付

2.向接口系统下单，对商户订单进行验签

3.请求进入消费订单系统，判断产品类型（银行卡、微信、支付宝）、银行名称、银行编码等

4.判断该订单是否存在、判断商户状态、判断商户手续费是否足够（即手续费<订单金额）、修改订单状态

5.请求进入风控系统，判断是否风控拦截

6.请求进入路由系统，请求消费路由选择渠道编号，对应的渠道商户号

7.渠道生成支付报文并往前返回、接口模块返回支付报文，收银台网站跳转到渠道网页

简单理解：收银台选择银行卡支付>请求发送到我们系统>做参数、风控等判断>通过渠道请求到银行，银行返回支付报文>我们系统解析并展示网银支付页面>用户完成网银支付>自动跳转到我们提供给银行的页面（此时上游异步给我们系统回了支付成功的报文）

2.扫码下单

流程说明

1.在商户网站上选择扫码支付

2.向接口系统下单，对商户订单进行验签

3.请求进入消费订单系统，判断产品类型（微信、支付宝）

4.判断该订单是否存在、判断商户状态、判断商户手续费是否足够（即手续费<订单金额）、修改订单状态

5.请求进入风控系统，判断是否风控拦截

6.请求进入路由系统，请求消费路由选择渠道编号，对应的渠道商户号

7.渠道生成支付报文并往前返回。成功，返回二维码url、失败，返回错误信息、超时，返回交易超时

8.收银台显示二维码，用户扫描支付

简单理解：收银台选择扫码支付>请求发送到我们系统>做参数、风控等判断>请求到上游，上游返回支付报文>我们系统解析并把url转换为二维码展示>用户完成扫码支付>自动跳转到我们提供给上游的页面（此时上游异步给我们系统回了支付成功的报文）

3.支付通知

流程说明

1.接口收到第三方支付成功的通知

2.接口透传消费订单系统，找到对应的路由规则找到对应的渠道，渠道解析通知返回支付成功给路由

3.路由返回订单消费支付成功，并且执行路由单日订单消费金额增加流程

4.消费订单系统，将订单由待支付更新为成功

5.判断该笔支付订单商户号+商户订单号在系统中是唯一成功订单

6.异步推送,清结算流水，接口前置通知商户支付成功

7.如果存在多笔订单，并且都支付成功，则其中一笔走退款流程

简单理解：上游给我们系统回支付成功的报文>我们系统解析处理>通知商户或者我们系统的下游订单支付成功

4.重复订单支付成功

流程说明

1.当收到存在两笔商户号+商户订单号成功的通知，进入退款流程

2.异步根据商户号+商户订单号对应的支付订单号发起退货，消费订单系统通过订单中心生成退货支付订单

3.根据原支付订单号，送到路由，通过渠道发起网银退货

4.渠道收到退货成功通知，向路由返回退货成功，路由返回给消费订单系统。其他状态对应修改状态即可，退款不成功则需要走扔处理流程

简单理解：上游返回两笔支付成功的通知>我们系统判断，如果存在相同订单则向上游发起退款>上游处理，返回处理结果*（商户订单过来后，会在我们系统落地，也会有一个匹配的订单号，此订单号才会发往上游）

5.自动查询机制

流程说明

1..轮训任务根据支付订单号、查询延时时间、查询次数安排任务

2.消费订单系统判断需要查询的支付订单

3.通道查询结果，成功则走收到支付成功通知的流程

6.手动查询机制

流程说明

1.交易消费订单系统下单成功后，

2.消费订单状态为待支付，手动在运支撑平台或商户服务后台点击补单后

3.向路由、通道发起订单状态查询

4.查询订单结果为成功，更新订单状态为成功等一系列操作

三、出款订单系统

1.出款下单

流程说明

1.商户通过接口或商户服务后台向出款订单系统下单

2.检查订单是否存在、商户权限、大额拆单判断、

3.出款订单系统送入风控系统模块，获取该订单单笔金额是否被限制

4.出款订单系统送入账务系统，判断账务情况是否正确

5.出款订单系统请求出款路由选择渠道编号，对应的渠道商户号

6.生成出款报文。直接发送至渠道

7.由运营支撑系统发起发送请求，将处理状态由已生成更新为已发送查找对应出款订单路由渠道记录发送至三方服务器，收到对方同步应答

8.将订单的处理状态由1-已生成更新为2-已发送

简单理解：商户通过接口提交出款（提现）>我们系统逻辑处理>发送到渠道

2.出款状态查询

流程说明

1.定时任务发起出款订单系统对上游进行查询订单状态

2.上游返回查询结果，找到对应渠道，订单的路由，传到对应出款订单系统

3.根据订单状态，通知商户