支付系统方法论

支付

基本概念

三原基

• 交易

• 清分

  • 计算好债务和债券的归属，把账对平，一般由清分中心完成
  • 清分是根据交易的终态结果，对商户、用户、支付通道进行手续计算、账单和到账款项的金额核对
  • 需要根据各方的日切时间将数据汇总，还要进行差账异常数据处理

• 结算

  • 结算是根据清分的数据，进行资金划拨

    • 结算时间

      • 结算日结算
      • 周期结算
      • 实时结算

国家级支付系统

• 大额实时支付系统

  • 无限额
  • 实时清算

• 小额批量支付系统

  • 100万以下

• 网上支付跨行清算系统

  • 5万以下

• 境内外币支付系统

名词解释

• 掉单

  • 因为网络原因，支付服务的结果没能返回给支付发起方

历史

账基支付的发展史

• 银行的业务分为存款、贷款、中间收入。支付就属于中间收入，期初，银行看不上这个收手续费的收入，都是第三方在做
• 后来，第三方手上交易量多了，就开始根据围绕这些信息做数据分析，主要是精准营销
• 再后来，有人开始做自己的账户体系，围绕账户体系做应用服务，比如交水电费
• 再后来，账户做起来了，用户也多了，就开始做更多的应用场景，不再局限于支付。比如做理财、保险等。

资本的策略

• 控制信息流以控制支付流，控制支付流以控制资金流；
• 获得网络接入权胜过资本所有权
• 获得数据接入量胜过资金投入量

国际支付

外卡

• 由国外的发卡组织发的卡是外卡，像VISA、运通、MasterCard等
• 一张实体卡可以同时有内卡卡号和外卡卡号
• 内卡和外卡的关键区分是卡本币是人民币还是外币，此处的卡本币就是结算币种

汇率

• 转换方式

  • 动态汇率转换DCC

跨境支付

• 本质上，就是你的卡本币，和商户的卡本币不同，你们打算用哪个币种结算，无论怎样，都需要汇率转换

• 涉及币种

  • 交易币种

    • 页面计价显示的币种，一般对应商户的结算币种

  • 结算币种

    • 结算给商户资金显示的币种

  • 卡本币

• 核心

  • 查汇方案

    • 不同银行、结算行、不同国家的汇率都不同
    • 银行的买入价和卖出价也不同，银行肯定是要赚点手续费的。（还有一个由外汇管理局发布的中间价）
    • 现汇价、现钞价、中间折算价也不同
    • 是每天一查，还是实时查询
    • 查汇时是否要自己叠加一个上浮比例进行风险控制
    • 实时汇率还分为交易实时汇率，还是结算实时汇率

  • 交易计价

    • DCC，将交易币种动态转换成用户卡本币，

      • 利于展示，且能提前锁汇
      • 一般会有一个汇率上浮
      • 汇率转换在交易发起前

    • EDC，使用当地交易币种

      • 汇率转换在交易发起后，因为先给了商户一笔钱，到扣你款时，发现你的币种和商户的本币不一样，需要转换

  • 汇兑损失

    • 是否涉及延期结汇，是否要买反向远期外汇期货

    • 交易币种结算成哪种结算币种

      • 因为客户只需要知道卡本币和交易币种，它不管你的结算币种，比如港币卡买澳币商品，你用人民币结算，他是感知不到的，但是中间却会有港币换人民币，再换成澳币，出现了两次转换。

分类

支付方式

• 卡基

  • 类型举例

    • 信用卡支付、借记卡支付、网银支付

  • 动作

    • 输入卡号、有效期等

  • 交易类型

    • 消费

      • 商户收用户钱，签约时商户需要提供工商材料，不同品类的手续费不同

    • 鉴权

      • 不涉及金额。比如有的很多网站通过银行卡鉴权来完成用户的实名认证

    • 预授权

      • 就是冻结资金，和消费一样，都是非快捷支付，只是结算时间不同。
      • 注意，这个预授权和代扣的签约是两回事

    • 代扣

      • 由用户授权，商户主动发起的扣款。是快捷支付。
      • 代扣是支付公司的生命线，其他交易类型都只是重在参与。
      • 比如：扣水电费

    • 代付

      • 比如：理财产品分红、发工资

    • 关联交易

      • 类型

        • 冲正

          • 交易在发起端先置为了成功，但是因为掉单，不知道最终在服务端的结果如何。此时由发起方发起冲正操作，服务端收到指令后，如果有该笔订单，则回滚，没有的话，也返回成功

        • 查询

        • 撤销

          • 可以理解为当日的退货，不一定每个通道都提供

        • 退货

          • 区别于冲正，一定是服务端确认支付成功后，才能退货，所以有的服务端要求隔日才能退货，就是用于确认支付成功了。

        • 预授权关联交易

          • 预授权完成、预授权部分完成、预授权撤销等等

        • 解约

      • 就是需要有一个交易的基础上，再发起

• 账基

  • 核心

    • 实名认证

  • 衍生

    • 可以绑定多张卡

  • 类型举例

    • 支付宝、微信

支付品牌

• 各个银行、各个公司等等
• 银行发的银行发可以通过BIN码进行区分，但BIN码归银联和其他外卡的发卡机构管，一般要从银行加银联等多个渠道共同收集，才能保证全

支付产品

• 类型举例

  • 信用卡MOTO、信用卡快捷、信用卡代扣

支付通道

• 类型举例

  • 银行直连（2018年后取消直联，统一接入网联）、银联融合、杉德四方支付等

• 一般可以概括为快捷支付、非快捷支付

  • 快捷类支付

    • 概念解释

      • 需要先签约 再支付
      • 签约完成后，只需要凭借token即可支付

  • 非快捷支付

    • 无需签约，但每次支付都需要提供信息

• 新接通道时要确定的关键问题

  • 签约相关

    • 是否支持重复签约

      • 同一个用户多次绑定同一张卡，会不会冲销掉之前的，返回码是什么样的
      • 不同用户能否绑定同一张卡

    • 签约后若支付信息变化，Token是否还有效

      • 一般卡号变了，Token一定会失效
      • 姓名、证件类型、证件号、手机号变了，一般Token还有效

  • 退款相关

    • 是否支持多次退货、部分退货

    • 退款时是否区分撤销和退货

    • 允许退货的最长时间，退货的到账时间

    • 退款是否要求当日进款大于退款

    • 退款退不退手续费

      • 一般代扣、代付类型退款是不退手续费的，其他会退

    • 对账单中，正负交易是否会全部显示，还是说会对冲掉。

  • 其他

    • 通道是否会给客户发送验证短信，是的话，需要要求要求通道用自己的商户名称显示在短信中
    • 是否有并发量限制
    • 是否有最低交易额限制
    • 日切时间、对账单获取时间分别是多少。使用的时区是哪个
    • 对账单中的结算方式是净额结算还是全额结算
    • 是否有测试环境和测试卡

关系

• 支付方式：支付品牌：支付通道=1:n:n
• 支付产品：支付通道=n:n
• 支付方式、支付品牌、支付产品，这三者本质上都是对支付通道属性的拆解细分后，归纳出的要素
• 支付通道不是最细粒度的划分，但是是最细不可分割粒度

支付系统

路由系统

• 引导路由

  • 负责决定用户看到的，展示给用户哪些支付品牌

  • 只负责到支付方式、支付品牌。不暴露支付通道

  • 可能涉及多个环节，需要与交易路由共同协作，参考交易路由的路由节点

  • 商户可以实现定制

  • 实现方式，需要配置三项内容

    • 品牌列表

      • 通过配置所有的支付方式、支付品牌。作为总的数据库

    • 引导方案

      • 决定如何展示品牌列表，制定很多套展示方式，此处是真正会展示给用户看的。

    • 引导规则

      • 制定规则，决定哪些引导方案展示给哪些商户

• 交易路由

  • 算法

    • 优先级

      • 风险路由>分组路由>短路路由>基础路由

    • 算法分类

      • 基础路由算法

        • 基于手续费最低，满足限额要求，成功率最高

      • 短路路由算法

        • 为了能够手动指定通道

      • 分组路由算法

        • 为了维护通道关系，给部门通道最低限度的分配流量

      • 风险路由算法

        • 风险分级，高风险的交易，要求验证的要素更多，需要选择验证要素更多的通道，或者包赔的通道

  • 路由节点

    • 事前路由

      • 用于给用户展示，让用户选择支付方式和支付品牌

    • 事中路由

      • 同一个支付品牌，可能因为BIN卡，需要重新调整路由，此时可能根据用户的输入，调整需要输入的内容

    • 事后路由

      • 不涉及引导交互，比如通道超限，要由交易路由自身在用户无感的情况下，自动切换路由通道

  • 路由流程

    • 1、上送商户或者用户输入和选择的交易信息
    • 2、匹配所有可用的物理通道，使用了引导规则、引导方案、品牌列表、物理通道信息
    • 3、使用各种算法既逻辑通道，过滤物理通道
    • 4、返回最优的通道及所涉及的信息
    • 5、根据路由节点，决定是否要使用通道进行支付，还是返回给平台要填写的要素信息

  • 实现方式，配置两项内容

    • 物理通道信息

      • 把物理通道的所有属性都配置上，用于匹配用户的支付要求，只包含固定的
      • 主要配置：单个物理通道支持的支付方式、支付品牌、支付产品；通道级别的限额、支持币种等限制信息

    • 逻辑通道，既各种算法的匹配规则

      • 逻辑通道是颗粒度最细的维度，

        • 逻辑功能可能存在于多个物理通道中。比如银联和网联都支持中国工商银行的快捷支付。但它们每一个都要单独配置一个逻辑通道
        • 逻辑通道的本质，就是一个物理通道中，费率和验证条件一样的功能项单独摘出来。
        • 一个物理通道包含多个逻辑通道，比如银联支付，可以付各个银行的

      • 其中有一个属性，是符合条件后，输出的物理通道

      • 不同算法有分类

        • 基础算法规则

          • 主要配置一个物理通道下的多个逻辑通道信息，包含：需要用户填写的要素，费率、维护时间等，目的是能确定用户的输入要求

        • 分组路由规则

          • 只需要配置多个通道的权重或者保量金额，用于计算未完成度，进行均衡分布

        • 短路路由规则

          • 配置行业、商户、支付品牌等所有商户侧的信息，用于过滤

        • 风险路由规则

          • 交易前识别

            • 在基础算法规则中，已经对物理通道进行打分
            • 需要收集用户信息、地理位置、设备信息、交易商户信息等，判别风险，选择通道

          • 交易中处理

            • 更多要素验证
            • 风险转移，路由到包赔通道
            • 人工介入

• 重试服务

  • 超时的处理

    • 前台显示超时

      • 后台一直轮询
      • 后台一直冲正

    • 前台显示失败，建议用户重新支付

      • 后台等第二天对账，根据结果退款或者无需处理

  • 事后路由的重试服务

    • 允许重试的规则

      • 内因

        • 自身设置的重试参数，包括：重试次数、重试参数、参与的商户、交易类型

      • 外因

        • 需要分析允许重试的通道的响应码

    • 重试的对象

      • 一般是银行卡类服务通道，因为只有这种会需要换通道重试，而像账基类的重试时是不需要切换通道的
      • 鉴权失败类、风险类订单、人工置失败的、出款类交易、需要短信验证码的是不能参与重试的

    • 重试的前提条件

      • 需要老通道已经返回了终态结果

清算服务

• 支付核心模块

  • 调用路由系统，然后上报数据给物理通道，完成处理，根据处理结果更新订单状态，并推送至账单模块

• 账单模块

  • 落地交易数据

    • 只要支付状态流转至终态，就将订单推送至账单

  • 拿到订单数据，然后调用计费模块获取手续费，生成对账单，推送给对账差错模块

    • 商户侧的业务订单
    • 支付通道侧的通道流水

• 计费模块

  • 计算手续费、结算方式、结算时间

• 对账差错模块

  • 对账

    • 账账对账

      • 上下游对流水

        • 注意的时间

          • 各方的日切时间
          • 各方的时区
          • 提供对账文件的事件差，比如D+1，T+1
          • 账单推送时间

        • 注意的钱

          • 币种
          • 单位
          • 结算方式是全额结算还是净额结算

      • 一般以通道数据作为基准

      • 考虑交互时间存在时间差，当天没对平的，会滚动到下一个周期进行对账，超过一定时间仍没有对平，则交给人工处理

    • 账证对账

      • 流水对到账凭证

    • 账实对账

      • 流水对实际金额

  • 平账

    • 对不能核对的进行补单或者退款，退款好退；补单根据支付通道，像银行卡支付可能就比较难补，可能需要线下练习用户

• 账户模块

  • 分为余额账户、冻结账户、礼品卡账户等