银企直联系统接口的设计与实现_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
银企直联系统接口的设计与实现
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
你可能喜欢点击阅读原文
快捷支付详解
4月25日 发布，来源：
快捷支付指用户在电商网站上执行支付时，不需要输入卡信息，仅根据短信或者其他的验证方式确认身份后，就可以执行扣款的支付方式。 这是目前电商网站采用的主要支付方式。
快捷支付分为首次支付和非首次支付，他们的流程是不一样的，区别就在于首次支付的时候，用户需要绑卡。而非首次支付则是直接使用已经绑定的卡来执行扣款，仅需做身份验证就行。注意，这里介绍的是电商网站为业务提供的快捷支付接口，而不是银行或者其他渠道提供给电商的快捷支付接口。
一、支付场景
快捷支付第一步是要求用户做绑卡操作。绑卡是将用户的银行卡信息提供给电商，以后电商就用这个信息去银行完成支付。绑卡实际上是一个授权，让用户允许商家自动从他的账户上扣除资金。所以绑卡也叫签约，用户和银行，商家的三方签订的支付合约。
但我们知道，绑卡对用户和商户来说都存在巨大风险。如果说用户绑卡是图省事，那商户为什么要做这个事？快捷支付在支付场景上的优势在如下几个方面：
1. 提升支付成功率
网银支付需要用户去银行开通网银，而对快捷支付来说，这并不是必须的。 这样使得可以使用快捷支付的用户群体得到扩展。 使用网银支付成功率在20%左右，银联直联成功率一般在50%左右，银行卡直联可以提升到70%左右。这是相当可观的数据。所以，当你看到绑卡送洗衣粉之类做法时，不需要担心商家会不会赔本。
2. 提升支付安全性
网银是需要用户自己来保证支付环境的安全。在支付宝推出快捷支付和卡通支付之前，网银还是主要的支付方式，这导致各种的木马，钓鱼病毒肆虐，目标之一就为窃取用户的银行卡信息。银行发放U盘U盾，各种的证书，都是为了保证网银支付的安全，这也带来了各种支付的不便。 哪天忘了带了，就无法完成支付。而快捷支付是由商家来保证支付信息的安全，可靠性得到保障。当然，至于商家如何保证这些信息安全，还有待商榷。总的来说，这也比个人自己抵御黑客黑产要靠谱多了。
3. 提升用户体验
想想网银支付的流程，用户在跳转到银行页面后，还得插入U盾，各种的核对。产品经理应该知道，每增加一个操作，都会带来一定的掉单率。 而快捷支付仅需在第一步完成绑卡后，以后的扣款，最多一个短信就搞定了，败家更方便。 在快捷支付中，绑卡和支付都不需要和渠道打交道，都是通过服务器来中转。而且在绑卡成功后，操作都在服务器上进行。这使得这种支付方式可以跨平台使用。手机，PC都可以。甚至在其他终端完成绑卡后，可以在电视，嵌入式设备上做支付。
4. 获取可靠支付数据
快捷支付还有一个很好的副作用， 那就是得到真实用户信息，特别是身份证信息、银行卡号、手机号、验证方式、真实姓名等。再结合用户的订单信息，大家就可以知道为什么淘宝、京东等这些电商网站现在的商品推荐会这么精准了。
二、绑卡流程
怎么绑卡？我们知道对接银行有两种途径，直接对接银行接口和通过银联来间接对接。这两种情况下绑卡处理也不同。 直观的，电商网站会在用户后台提供一个绑卡的入口，让用户直接绑卡。以支付宝绑卡流程为例，我们可以体验下:
这里有如下要点：
只能绑自己的卡，这主要从安全角度考虑。作为自己的卡，指银行卡在银行预留的姓名和身份证与网站预留的一致。
需要用户在银行侧预留的手机号进行短信验证。但不是所有银行都需要。这个时候，为了统一处理，可以考虑自己发验证短信。
对这个入口不要指望太多，更多的用户是在支付中绑卡。也就是提交订单后，发现没有银行卡了，就开始绑卡。 和纯绑卡流程不同的是，最后一步，绑卡成功后，一般都同时完成支付。有些渠道会提供绑卡并支付的接口，减少交互次数。
为了保证卡的安全，绑卡有这些前置需求:
用户必须已经绑定了手机号。该手机号用于修改支付密码。
用户需设置了支付密码。支付密码不同于登录密码。
针对用户不同状态，绑卡流程上有区别。当然，绑卡是安全操作，要求用户必须登录到系统中。为了避免和服务器端的交互被劫持，所有操作必须在安全协议中进行，即使用https。
1. 输入卡号
用户输入卡号，系统对卡号执行初步验证。 验证的依据是卡bin和LUHN算法。参见。
当然，还有些系统会提供扫卡识码的功能，比如微信支付。 扫码识别的准确率可以达到99%，有些卡的卡号颜色和背景色一致的，就会识别出错。 如果用户没细看，进入下一步，就会报告错误了，这种错误还比较难发现。自动识别卡号，还需要考虑在识别错误时如何圆过去的问题。
2. 获取卡信息
首次绑卡需要提供卡信息。借记卡需要卡号，用户真实姓名和身份证，这个所有银行都一样。(有不一样的，留言告知，谢谢)
信用卡就复杂点。大部分信用卡还需提供CV码和有效期。但是如果和银行关系好，拿到合适的接口，把这两个因素都免了，也是有可能的。
3. 要素验证
首先在服务器端做验证。主要是验证卡是否已经被绑过。 如果一个用户有多个账户，系统还需要考虑是否支持这些账户都绑到一个卡上。
接着调用银行绑卡验证接口进行绑卡。这里有一个四要素验证的概念。由于国内要求实名制，所有银行卡都是实名办理的，所以银行可以验证姓名，身份证号，银行卡号和手机号是不是一致的。如果没问题，则会发短信到手机上。
这里还有几个注意点:
1.关于手机号。大家都知道，银行预留的手机号一般都是办卡的时候留的，过了几年，换手机了，很多人就忘了同步到银行。所以很多银行就不验证手机号。
2.关于验证短信，手机号都不是必须的，那短信就可能都不发了。这在流程设计时需要统一处理。银行不发短信就的自己发。
3.重复绑卡问题。如果系统支持多账户，那不可避免的出现一个人绑卡到多个账号上。渠道侧绑卡，有接口支持重复绑卡，有些是不支持的。所以如果需要重复绑卡，还得在服务器端处理。
4. 执行绑卡
用户输入短信验证码并确认绑卡，服务器端将用户实名信息以及短信验证码组合形成报文，发送给银行，执行签约操作。银行侧签约成功后，返回签约号给商户。
这一个处理逻辑放在支付渠道侧介绍。银行会返回如下结果：
签约成功：这意味着可以建立签约关系。而签约关系在支付系统中则通过虚拟账户来表示。 具体的账户设计参见。
重复签约： 按照业务考虑是否支持重复签约。 一般针对一个银行卡仅保留一个签约关系，建立一个虚拟账户。
签约失败： 需要提示具体失败原因。
三、扣款流程
在完成签约后，支付处理就相对简单不少。扣款流程如下：
流程要点：
订单系统生成订单后，请求支付系统执行支付；
支付服务器生成支付记录，请求渠道执行支付。如果该渠道需要短信支持，请求渠道发送短信。
服务器端在生成支付记录后，请求渠道执行支付。对于需要短信验证或者其他身份验证方式的支付行为，还需要首先请求渠道发送短信，之后让用户输入短信验证码。之后将订单、短信验证码、支付金额送到渠道侧，执行支付。
这里需要关注如下问题：
1. 订单有效期
用户必须在订单有效期内完成支付。支付时，必须为每个订单设置有效期。这个有效期不能太长，一般不会超过一天。有效期可以从下单开始算，避免使用相对日期。 在执行支付时，需要验证下订单是否还在有效期内。
2. 同步和异步处理
银联提供的商户侧开通快捷支付接口，不同步返回最终扣款结果，而是通过异步通知的方式来返回。 异步通知会多次调用回调接口， 直到调用成功。 所以，一个订单支付成功的通知，有可能会收到多次回调。
四、解约流程
解约流程一般是由用户自己发起。当然，存储在本地的签约信息只是被设置为无效，而不是实际删除。 解约时，还需要注意相关的订单是否都已经完成。
五、退款流程
没有平白无故的退款。支付都是由交易调起的，那退款就都对应的由退货发起的。 针对已经扣款成功的交易执行退款。如果交易还在进行中，比如渠道侧还没有返回结果，则执行退款会导致状态不可预知。
注意，退款的钱并不一定立即到账。不同银行、不同渠道到账时间不一样。
六、接口概述
一般来说，快捷支付需要提供如下接口：
签约， 也叫“绑卡签约”、“开通交易”等，指用户在商户网站上开通快捷支付的功能，他需要将银行卡相关信息提供给电商。
解约， 也叫“解绑卡”， 指用户取消在该网站上的快捷支付功能。一般也会删除该用户在该网站上的相关的银行卡信息。
扣款， 也叫“支付”， 指用户使用签约的卡来执行一笔扣款。
退款， 针对已经扣款成功的交易执行退款操作，一般同时也会把用户权益或者对应的订单撤销。并不是所有订单都可以执行退款。
查单, 查询某次交易的处理状态。
签约查询， 即检查某个用户是否已经开通了签约功能。
七、备份通道
由于快捷支付是常用的一个通道，其带来的问题是，如果这个通道出问题了，应该怎么办？回顾之前的文章，我们提到过，银行卡快捷支付不仅仅只有发卡行的通道，银联、第三方支付也都可以提供银行卡快捷支付接口。就发卡行来说，也不仅仅总行通道，很多发卡行的各省分行，由于历史因素，手头也有通道资源。 这也为我们实现通道切换提供了可能。
切换支付通道最大的问题是如何解决签约。 比如用户原来使用工行快捷支付接口来完成工行借记卡支付。某一天，工行通知接口要维护，不可用了，这就需要提前把工行接口切到其他备用通道，比如银联接口。 当然，直接切换是不行的，和银联还没签约呢。 那如何处理备用通道？ 关于备用通道的签约时间。可以在用户签约到主通道时，同时签约到备用通道，这种情况要求备用通道必须是无短信验证的，否则一次签约发两条短信，用户必须会怀疑的。还可以在第一次支付的时候签约，这时候将签约支付短信一并发出，避免影响用户体验。
关于通道选择，参考一文。
八、接口实现
一般来说，快捷支付接口可以通过封装如下通道接口来实现：
当然，首先是银行自己提供的快捷支付接口；
银行的代扣接口；
银联的客户侧开通Token接口。
第三方支付的代扣接口。
九、安全与合规
和银行卡对接，特别是快捷支付接口，有三个重要的合规文档，必须通读。
《非银行支付机构网络支付业务管理办法》(中国人民银行公告〔2015〕第43号公布）
中国人民银行关于进一步加强银行卡风险管理的通知, 银发〔号
严禁留存非本机构的支付敏感信息（包括银行卡磁道或芯片信息、卡片验证码、卡片有效期、银行卡密码、网络支付交易密码等），确有必要留存的应取得客户本人及账户管理机构的授权。
各商业银行、支付机构应在客户端软件与服务器、服务器与服务器之间进行通道加密和双向认证，对重要信息关键字段进行散列或加密存储，保障信息传输、存储、使用安全。
自日起，各商业银行、支付机构应使用支付标记化技术( Tokenization)，对银行卡卡号、卡片验证码、支付机构支付账户等信息进行脱敏处理，并通过设置支付标记的交易次数、交易金额、有效期、支付渠道等域控属性，从源头控制信息泄露和欺诈交易风险。
严格限制使用初始交易密码并提示客户及时修改，建立交易密码复杂度系统校验机制，避免交易密码过于简单（如“111111”、“123456”等）或与客户个人信息（如出生日期、证件号码、手机号码等）相似度过高。
网络支付报文结构及要素技术规范(V1.0版), 银办发[号
感谢您对本文的关注，如需要及时收到凤凰牌老熊的最新作品，或者有相关问题探讨，请扫码关注“凤凰牌老熊”的微信公众号，在公众号里留言或者回复，可以尽快处理，谢谢。
本文欢迎转载，转载时请注明本文来自 微信公众号“凤凰牌老熊”。
我要该，理由是：
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）查看: 12308|回复: 12
请问，银企直联和企业网银的区别是什么啊？
论坛徽章:0
请问，银企直联和企业网银的区别是什么啊？
望知道的留下答案，大家一起讨论下。
论坛徽章:0
企业网银是交互式操作，大部分工作需要人来操作；银企直连是银行和企业的系统直接对接，批量处理，交互式处理少
论坛徽章:1
最明显，企业网银客户有很多，而银企直连的客户是固定的单一的客户。
论坛徽章:0
区别就在于企业网银是一个是模板式的、面向一般企业客户的，而银企直联则是个性定制的，满足集团大客户需求的。不同的地方还有收费，银企直联很贵的哦。。。
论坛徽章:0
问问题，找答案-问题库信息网，您身边的百科全书匿名回答：8人气：8提问时间： 22：05
论坛徽章:1
上面说的都对，补充一点。企业网银无法针对集团进行资金管理，银企则可以，即现金管理系统，有资金池的概念。
认证徽章论坛徽章:92
一个是通用平台，一个是个性化贴身大客户服务
论坛徽章:0
原帖由 yandong2007 于
10:15 发表
请问，银企直联和企业网银的区别是什么啊？
望知道的留下答案，大家一起讨论下。
银企直联主要是实现银行的网上银行系统跟企业的业务系统或者会计系统的直接对接，也可以看成是一个接口。
企业网银是银行提供给企业客户的一个可以通过互联网操作公司账户的平台。
论坛徽章:0
企业网银是网银的企业版，还是一个单一网银客户；银企直联是对企业特别是集团企业定制的银行客户端，主要管理资金、调度资金。
论坛徽章:0
企业网银其实就是网上银行，只是针对的客户群不一样，提供的功能不一样，比如企业网银至少的有代发工资的功能。
银企直连，我认为对于银行来说就是实现了一个第三方中间业务接口，只不过这回不是跟水 电 连，是跟一个大集团连接而已。当然具体交易肯定不一样。对于开发人员来说只不过数据域里的数值不同而已。
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：10　广播电视节目制作经营许可证：编号（京）字第1149号您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
银行普通支付快捷支付银企直连对接操作手册.docx 6页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
下载提示
1.本站不保证该用户上传的文档完整性，不预览、不比对内容而直接下载产生的反悔问题本站不予受理。
2.该文档所得收入(下载+内容+预览三)归上传者、原创者。
3.登录后可充值，立即自动返金币，充值渠道很便利
需要金币：350 &&
银行普通支付快捷支付银企直连对接操作手册
你可能关注的文档：
··········
··········
银行普通支付、快捷支付、B2B、银企直连对接操作手册普通支付普通网银支付整体流程时序图图1-1 网银支付整体流程时序图（可另存下来或放大看）代码结构图图1-2 普通支付代码结构图对接银行开发步骤首先应该有框架代码，IPaymentService、PaymentServiceImpl、IBankPaymentService、AbstractBankPaymentServiceImpl；新建maven项目，命名为ccb，建立package
com.rrtx.payment.ccb.service及com.rrtx.payment.ccb.service.impl；在com.rrtx.payment.ccb.service下编写ICcbPaymentService接口，扩展自IBankPaymentService接口；在package com.rrtx.payment.ccb.service.impl下创建CcbPaymentServiceImpl，继承AbstractBankPaymentServiceImpl并实现刚定义的ICcbPaymentService接口，按提示添加须实现的方法，添加完后如下图：在CcbPaymentServiceImpl中添加com.eclipse-javadoc:%E2%98%82=payment/src%5C/main%5C/java%3Ccom.rrtxrrtx.eclipse-javadoc:%E2%98%82=payment/src%5C/main%5C/java%3Ccom.rrtx.paymentpayment.eclipse-javadoc:%E2%98%82=payment/src%5C/main%5C/java%3Ccom.rrtx.payment.serviceservice.eclipse-javadoc:%E2%98%82=payment/src%5C/main%5C/java%3Ccom.rrtx.payment.service%7BIPaymentService.java%E2%98%83IPaymentServiceIPaymentService.Bank的对象属性bank，并复写父类的init方法，在init方法中对bank对象的相关属性初始化，此属性主要封装了本银行服务的相关信息，比如显示的图标、银行编号、在平台的代码、简称等，该部分可能需要读取配置文件perties，该文件约定放在src/main/resources/目录下，文件里一般还包含了提交的银行接口地址、在银行开立的商户号、证书、密钥、返回通知本系统的url等信息：在prePayment方法里写逻辑，将我们平台的PaymentInput转换成建设银行对应的报文格式，部分字段可能需要根据PaymentInput中的字段去数据库查询；在afterPayment方法中，根据建行的接口文档将银行返回的Map解析出我们平台的数据PaymentOutput对象返回；如果要使用模拟银行，我们一般在shopDemo中的simBank目录下放置模拟银行的应答jsp，里面模拟银行返回信息，然后将上面提到的提交银行接口的url改成该jsp的请求url。至此银行普通支付的对接工作基本完成。快捷支付代码结构图图2-1 快捷支付代码结构图交互流程描述客户操作流程：选择支付方式“快捷支付”，从支持快捷支付的银行列表中选择银行；输入银行卡、银行预留手机号等等信息，阅读并勾选签约协议，提交信息；提示支付成功；系统前后端交互流程：用户在支付方式页面选择快捷支付选项卡后，页面向后台请求系统支持的快捷支付的银行列表并展示银行快捷支付图标；用户选择银行后点击下一步，进入快捷支付页面，该页面首先发起请求判断当前用户是否已签约该银行的快捷支付；如果没有则显示签约录入表单，用户输入签约所需的所有信息，并点击发送手机短信验证码，用户收到短信验证码后输入并一起提交表单，后台将该用户提交的信息发送至银行的鉴权接口，鉴权返回成功后系统验证用户提交的短信验证码和支付密码等信息；验证通过后系统调用银行的签约接口签约，完成后前端转入步骤4）；如果已签约则提示输入手机号等关键支付信息，提交到后台，后台发送短信验证码后，前端弹出验证码输入框，再次提交到后台验证，后台验证正确后发送银行快捷支付接口，成功后返回到前端，提示支付结果；对接快捷支付开发步骤开发步骤和普通网银支付基本一样，但是我们有几项约定：快捷银行的项目和银行的简称我们都以quick结尾，比如中信银行快捷支付项目名叫citicquick；因为不同银行的快捷支付接口功能统一性不高，因此相对网银支付我们加了一层适配器来屏蔽接口方法，银行服务中只需实现我们本银行有的接口。因为对快捷支付来说，我们平台输出的数据与网银支
正在加载中，请稍后...