一、DSP是什么？

DSP，中文名称：“接口服务平台”。主要用于支付结算及账号信息查询使用。本质上是一个支付模块，而非独立的产品。
在日常实际场景下，主要负责对接外部的银行和第三方支付渠道。具体功能主要有支付、收款、签约授权、余额查询、明细流水、对账单、退票、电子回单、电子票据、数字货币等。

1.1 子功能简单介绍

1.1.1 支付

支付，表示由保险公司作为付款人，向收款方进行付款，付款动作由银行或者第三方支付渠道代替，也成委托代付。收款方如果是当前保险公司内部的子公司账户，则该支付行为又称之为“上划下拨”或者叫“内部调拨”；收款方如果是私人的投保人，可称为“对私转账”、“保费理赔”；收款人如果为其他保险公司，可称为“对公转账”；收款人如果为该保险公司内部员工，可称为“薪资代发”、“费用报销”等；
其中，在支付过程中，又由于可逐笔支付和组批支付，因此根据支付行为又可划分为“单笔支付”、“批量代付”；“单笔支付”如果走的是“同行对私”或者 “超级网银”，可实时返回支付状态，又可再细分为“普通支付”和“实时代付”；而“批量代付”由于前端的特殊性，可根据拆分笔数和组批规则，根据表现形式不同，如“一批一笔
”、“一批多笔”在DSP内部有时又可分为“批量转单笔支付”、“普通批量代付”。

1.1.2 收款

收款，表示保险公司作为被动收款人，由付款人主动拨款给保险公司，或者通过银行及第三方支付渠道签约委托代扣协议，委托银行及第三方支付渠道定期自动划走付款人账户的钱来实现收款行为。如果是付款人主动付款给保险公司，称之为“快捷支付”或者叫“普通代扣”，如果是由银行及第三方支付渠道代理收款，可称之为“委托代扣”。
“普通代扣”当中，主要体现为投保人通过扫码、公众号、小程序、APP、H5、快捷短信扣款等支付方式，主动向保险公司收方付款，也称之为“首期扣款”；而“委托代扣”主要表现为在用户第一次向保险公司支付保费时，用户需要先进行签约授权，可体现为用户接收短信，进行回复或者确认，经由投保人授权后，第二次扣款开始，不再由投保人主动向保险公司付款，而是由银行及第三方支付渠道定期自动扣除投保人卡上的钱并划入保险公司收款账户上，该行为也称之为“续期代扣”。
其中，在扣款过程中，又由于可逐笔扣款和组批扣款，因此根据支付行为又可划分为“单笔代扣”、“批量代扣”；“单笔代扣”基本上都是同行代扣，实时扣款的，仅有一部分银行及第三方支持跨行代扣；而“批量代扣”由于前端的特殊性，可根据拆分笔数和组批规则，根据表现形式不同，如“一批一笔
”、“一批多笔”在DSP内部有时又可分为“批量转单笔代扣”、“普通批量代扣”。

1.1.3 签约授权

签约授权，主要发生下第一次扣款也叫“首期代扣”中，可通过批量授权（也叫“存量签约”或者“白名单导入”）或者单笔签约两种方式对用户进行扣款协议签订，如果签约成功，表示用户同意和当前保险公司签订协议，后续保费可由保险公司委托指定银行或者第三方支付渠道委托进行“续期代扣”。
根据签约授权方式不同，可分为批量授权及单笔签约。其中批量授权可分为无感授权和有感授权，无感授权一般也叫“白名单导入”，即保险公司把投保人的开户信息发送给银行，由银行直接导入到银行服务端，后期可直接进行续期代扣；而有感授权一般表现为由保险公司将用户信息，其中关键信息“用户开户预留手机号”发送银行，银行服务端根据预留手机号主动向用户发起授权绑定信息，可由用户直接回复银行短信或者短信确认到银行端，银行端确认完自行更新当前批次授权用户信息为授权成功，后续保险公司可发起授权查询，将授权成功的用户信息查询回保险公司核心系统，并方便后续发起续期代扣。
而单笔签约又可简单分为“短信回复签约”和“短信确认签约”，表现为如果是“短信回复签约”，是由保险公司委托银行及第三方支付渠道主动向用户手机号发送签约绑定信息，由用户回复银行及第三方支付渠道即可，保险公司无需知悉用户是否回复，仅通过签约查询或者等待银行及第三方支付渠道发起签约通知来获取当前用户签约状态；而“短信确认签约”主要表现为由保险公司委托银行及第三方支付渠道主动向用户手机号发送签约绑定信息，用户确认后，需手工在保险公司指定系统中录入验证码，再由保险公司将用户输入的验证码及开户信息发送银行及第三方进行签约，可在签约确认这一步直接获取签约结果，仅有部分情况下，确认异常，可发起签约查询或者等待渠道方发起签约通知，后更新签约状态；
当然，批量授权和单笔签约只是签约授权的表现形式，在渠道方那边，如果当前该保险公司通过批量授权或者单笔签约方式发起的授权动作，会在第二天生成前一天的日终签约结果文件，保险公司可自行通过查询、下载、被动接收通知等方式获取该日终签约结果内容，并支持前端系统主动查询或者由DSP主动推送给前端系统，再由前端系统更新银行最新签约授权用户信息，并便于发起续期代扣。

1.1.4 余额查询

余额查询，顾名思义就是主动向银行或者第三方支付渠道发起余额查询请求，将当前账户的最新实时余额查回。查询的主要目的可用于前一天的日终余额对账，也可用于后续支付金额的判断依据，避免出现余额不足的情况发生。

1.1.5 明细流水

明细流水，在前端系统又分为“历史明细”和“今日流水”。表示保险公司第二天或者月末需要对账时，主动通过任务配置需要查询的账号及日期发送银行及第三方支付渠道查回历史日期或者当天的每一笔交易的明细，交易明细包括支付收款的对方用户卡号、户名、交易时间、交易金额、借贷标志、交易后余额、对账码、交易用途备注等信息，方便前端系统根据这些信息进行逐笔对账，防止收支不平衡。

1.1.6 对账单

对账单，该功能和前端的明细流水功能类似，只是一般情况下银行正常叫历史明细，第三方支付渠道叫对账单，资金内部为了两种都对接，因此也按银行的要求细分为历史明细、今日流水、对账单等功能，对账单获取的明细中也合明细流水一样，会在对账单明细中返回用户卡号、户名、交易日期、交易时间、借贷标志、交易流水号、交易状态等关键信息，并返回给前端系统；

1.1.7 退票

退票，一般发生在支付行为中，并且是在跨行转账过程中，表现为在保险公司发起跨行支付时，渠道方先返回了支付成功，表示央行已将保险公司委托银行在央行的备付金划走指定交易金额，并已发送他行进行处理，但在后续他行交易过程中，发生落地，落地原因可分为当前传入的他行用户开户信息有误，如卡号不存在，卡号错误，卡号格式错误，余额不足，户名错误，证件号错误，开户行行行号、行名、省市区域错误等原因导致退票，保险公司可在交易查询中查回最终交易结果。有的银行处理较快，可在发起支付时就能返回交易成功，大部分都是等待银行的队列处理，需要不断发起交易查询任务查回支付成功状态。
前端收到DSP在支付提交或者支付查询返回的交易成功后，更为已支付未退票，后续在发起退票查询任务自动查回退票信息，并根据退票的流水号去查询交易单支付流水号一样的订单，状态改为已退票，并推送给上一级系统进行后续业务处理。

1.1.8 电子回单

电子回单又叫“电子印章”，最早都是纸质的交易信息，并附有银行的专用章，表示这是一笔银行或者第三方认证的唯一交易凭证。在后续发展中，慢慢出现了电子凭证，并对外开放了对应的接口用于电子凭证获取。一般情况在电子回单格式都是pdf或者html，有的会是img图片，由DSP根据指定账号和日期范围去银行及第三方支付渠道获取，并和交易明细及支付交易进行关联，从而能让前端系统在交易单和明细中查看电子回单。在实际交互过程中，大部分情况下都是由DSP通过接口或者FTP/SFTP服务器获取银行的回单压缩包或者单个的pdf，并识别文件名中的电子回单编号或者业务参考号，将该唯一关联号和文件路径保存到数据库中，而后在明细流水中也将该唯一号返回给前端，后续由前端发起回单查看时，发送指定账号、指定日期、该唯一号给DSP，由DSP从数据库中找到该账号、日期、唯一号匹配唯一的一条回单并通过http get的方式展示在请求的链接上。

二、DSP实现原理

在日常对接过程中，DSP既是服务端也是客户端，DSP的前端主要连接着ATS、S3、630、NET、CXS、JBT等，而后端主要连接着各个银行及第三方支付渠道；
对于前端而言，DSP是一个服务端，按照DSP约定的统一交互报文格式进行交互，DSP在收到前端发来的请求指令后，解析报文头部及体部，并连接后端，连接指定的银行或第三方，发送指定的指令请求。
而后，在后端指令完成后，会发送结果给DSP，DSP收到结果后，按照和前端约定的统一交互报文拼接结果内容并返回给前端；最终由前端获取到数据后进行后续业务处理。
其中，在DSP和后端渠道交互时，先由DSP接收前端请求报文，识别对应的参数，根据线路、指令来区分并发送指定的银行或者第三方支付渠道及对应发送的指令，在实现过程中，DSP内部做了识别参数和按照银行要求拼接报文、加密、签名等操作。如果是DSP直接接入银行前置机软件的一般只做报文拼接，不做加密签名等步骤，由银行前置机软件代替完成这一动作。

三、DSP发展过程

2016年以前，保融科技仅有C#语言编写的NET版本DSP，所有客户均使用NETDSP，到了2016年开始使用JAVA语言编写JAVA版本DSP，16年期间的DSP仅有200~300K源码，并且只有几家大行的直联银行，没有第三方支付渠道的源码。
在2017年开始，陆续补充大量的银行及第三方支付渠道，至今已对接外部的银企直联及第三方支付渠道共300余家。
在17、18年两年期间，公司开始大量推行JAVA版DSP，并配合JAVA版ATS6.0一同上线，从19年开始，只要是新接入的客户，全部使用JAVA版DSP进行渠道对接上线。不过期间由于历史及客户等各种客观原因，现场的NETDSP仍有很大一部分作为主DSP在使用。
目前阶段，现场新接入客户全部都是JAVA版DSP，历史客户有一部分是NETDSP和JAVADSP并用，这一阶段的NETDSP仍无法替换。因此公司的原则是NETDSP仅用作生产运维支持，不再接入新的开发，也不再招C#程序员，主推JAVA版DSP。