一、专题分享：保险业务中的支付场景及其对支付网关的需求

今天给大家介绍一下接触到的保险公司线上销售过程中的一些支付场景及其对支付网关的需求。 一般来说保险公司都有自己的收银台，对接主流的支付通道或者银行直连。

1.1 支付场景

由于保险产品种类的不同，对应的支付场景不同。下面分别说明：

第一类， 保险公司自营平台（官网，官微或者APP）

在自营平台场景下产品线比较丰富，绝大多数是见费出单的形式（也就是收费后出保单）

  1. 件均较低的短期或极短期保险产品，比如交通意外或者航空延误险等。这类产品支付过程追求的是简洁,快捷一次付清。一般使用微信支付，支付宝支付，储蓄卡或者信用卡快捷支付，扫码支付等
  2. 件均较高的车险、理财产品等。 这类产品一般金额较大，一次性付清。支付方式包括：微信支付，网银，支付宝，储蓄卡，对公汇款，支票进行支付。需要说明的是由于有对公业务，因此需要对公打款和支票支付的方式。 有些特殊情况下，需要支付通道给客户垫资，客户只交净保费，从而实现保险功能拿到全保费，满足监管要求。
  3. 件均较高的多年交寿险产品。这类产品一般金额较大，分为期交，趸交，而期交又分为月交和年交。支付方式分为：代扣，储蓄卡，线下汇款，支票进行支付。 基于节省手续费的考虑，保险公司一般倾向于批量代扣的方式。

第二类，第三方渠道合作

渠道合作根据合作方是否有保险代理资质，分成两种类型：

  1. 有保险代理资质的合作方：合作方直接向客户收款，保费进入到代理公司的账号，然后进行月结或者旬结算给保险公司。使用保险公司提供的保险产品页面直接销售，保费进入到保险公司的账号，这种比较少。
  2. 无保险代理资质的合作方，又分成几种场景：
    • 使用保险公司提供的保险产品页面直接销售，这种比较少。
    • 跟保险公司进行API对接，使用保险公司提供的支付API向客户收款，资金直接进入到保险公司银行实体户或者虚拟户。
    • 要求保险公司跟特定的支付通道合作，合作方使用这个支付通道进行收费。
    • 另外跟特定的商品绑定销售，客户支付一次，而支付通道使用分账的方式：一部分钱到保险公司的账号，另一部分到合作方的账号。

1.2 收银台

针对上述场景，公司启动了收银台项目，项目中对于收银台基本要求如下：

收款方面

  1. 提供支付相关的收银台页面，包括手机H5、公众号、PC网页版等不同的平台。同时提供API，供第三方调用。
  2. 能够根据产品类别、支付金额、手续费、支付通道稳定性等,根据支付路由选择合适的支付方式。
  3. 能够支持主流的支付方式，比如支付宝，微信支付，银联、银企直连等。做好幂等校验，防止重复支付。
  4. 具有良好的设计，能够快速对接新的支付通道。更多是为了支撑合作方指定的支付通道，满足业务的发展。一般是合作方专用，不放在自营平台上使用。
  5. 需要支持实名验证、快捷支付、批量代扣代付。处理期交业务时，需要使用批量代扣，并且要进行校验，防止客户使用其他支付方式进行支付。对于大额支付，由于反洗钱的需要，需要进行身份验证，必要时需要上传身份证正反面及活体检验。
  6. 提供线下汇款支持，用户选择汇款支付方式后，支付页面需要生成支付标示码，标示此次支付所对应的订单；同时可以通过后台汇款管理功能手工补录，并通知订单系统。

退款方面

  1. 系统发起退款后,财务人员可根据后台配置规则（产品类别，金额等），由财务人员批量审批后或者自动审核,进行原路返回退款。
  2. 财务人员批量上传退款清单,系统根据清单列表进行原路返回退款。
  3. 支持财务人员批量提交金额和银行卡号,进行批量代付,及其相应的查询,统计核对。

对帐方面

  1. 支持业务、财务、银行三方对账，对账不平需提供差错表，并提供手工处理功能；
  2. 对账通过后，需对异常状态的订单提供补发通知的功能.
  3. 遇到系统不稳定，不能及时接收支付通道回调，在对账之前需要手工处理的订单，解决办法有两种方式： 1.让合作支付通道方再次发起回调。确认钱已经到了支付通道所在的账号，手工触发回调。风险较大不建议这样做。 2.支持财务人员上传支付通道或者银行的支付流水明细数据,订单系统进行对帐。财务人员一定要及时对账，财务人员一定要及时将虚拟账号中的资金，转移到实体账号。因为发生过未及时转移，支付通道按照签署的协议将超过一定时间的资金返回给客户的问题。

查询及统计

  1. 财务人员可以进行后台订单查询、支付记录查询、对单记录进行查补单。
  2. 支持根据时间,状态,支付方式,支付银行,订单来源渠道进行各个纬度的查询和统计。

支付通道及支付路由管理

  1. 财务人员可以在后台配置支付通道及其对应的参数，并提供支付通道证书或者密码到期提醒功能。即将到期前，通过短信或者微信以及站内信等方式通知相关的人员功能很关键，这样就能提前进行相应处理。
  2. 提供支付智能路由，财务人员可以在后台进行路由规则配置，开发人员可以扩展路由规则；支持将不同的产品绑定不同的支付渠道，并在收银台根据配置动态展现支付渠道。财务人员能够根据支付通道的升级或者系统故障通知，配置相应的智能路由，在特定时间段或者永久将相应支付通道禁用。根据手续费的多少、响应时间、销售产品特点等配置不同的支付通道。

权限及审计功能
1.具有完善的管理后台，方便业务部门进行操作；并对各种后台操作提供日志审计功能
2.后台台账管理需提供完善的权限管理功能。

安全方面

多商户支持
能够以多租户的方式支持多个商户，每个商户可以绑定不同的支付通道，并且制定不同的路由规则等。这个对于支持集团内的多个子公司的业务尤其有帮助。

沙箱服务
对于不提供测试环境的支付通道，应提供模拟服务，便于进行功能和压力测试。

整个需求基本都是从业务角度来提出的，没有涉及到技术选型。上一张整体系统图：
20170703_194437

二、Q&A

Q1: 看到你提到对外合作，对外合作现在80%都不是见费出单，而且都是合作渠道代收 t+1给结算，这部分系统支持对账吗？如何对账?
A1: 这种合作渠道只支持业务明细对账，而不是资金对账。

Q2: 不会存在业务对上了资金对不上的情况吗?
A1: 每日对业务明细，一般旬结算或者月结算，因此总金额能对齐即可。

Q3: 这块很麻烦单子小而多再加上退保之类的，不好对。
A1: 是的，海量小单很麻烦。真有个别的对不上，只能人工消化了。在财务记账做文章。

Q4: 这套收银台系统很完备了，都差不多哈哈，你们收银台对接核心吗？人工消化….很强势。
A1: 不直接对接核心，全部是通过异步回调的方式进行。这样避免跟核心的紧耦合。

Q5: 技术实现上坑一般在异步回调和多商户多机构多维度配置上
A1: 是的。完全是按照保险的场景定制的收银台。

Q6: 你们这块做风控系统了吗
A1: 因为不涉及到贷款和信用类的场景，暂时没有。我们这边只做保险产品本身的风控，没有在支付方面做风控。

Q7: 保险不是收支两条线么？理论上退款应该不允许走收款通路吧，在退款部分看到允许原路退回，有点疑问
A1: 指正的对，是原账号退回。原先是让用户提供卡号等信息，手工通过另外方式退款，用户体验不好，也容易搞错。因此要求尽可能原支付通道原账号退款。

Q8: 上文可能原路退回一般是指第三方支付平台传支付流水号调用退款接口进行退款，也没问题
A1: 在保险公司没有生成保单给客户，这种是可以的。一旦生成，就必须走收支两条线的退费了。

Q9: 但一般这种情况就放在收付系统里做了，收银台原路退款还是指的是未生成保单的情况
A1: 是的。我们是保险收付系统调用收银台进行退款。实现集中的收付款平台。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。