支付宝网银业务管理及管理知识规范.docx
《支付宝网银业务管理及管理知识规范.docx》由会员分享，可在线阅读，更多相关《支付宝网银业务管理及管理知识规范.docx（41页珍藏版）》请在冰点文库上搜索。
支付宝网银业务管理及管理知识规范
支付宝网银接入业务规范
副标题：
网银接入规范
版本0.3
修订历史
版本号
作者
内容提要
核准人
发布日期
1.0.1
葛乔
初稿
2010-2-26
1.0.2
王增贤
初稿
2010-2-28
1.0.3
葛乔
增加明细查询业务
完善余额查询条件
完善结算规范
2010-3-9
1文档概述
本文档主要描述支付宝与银行之间的网银接入业务规范业务内容、交互模式，安全配置等内容。
1.1目标读者
1.2
本文的主要目标读者是支付宝网银接入业务银行方的业务规划人员，其中的部分内容也可供银行的经管与技术人员参考。
1.3版本规范
1.4
支付宝网银接入业务规范的版本规范是：
<主版号>.<次版本号>.<修订号>。
本文介绍支付宝网银接入业务规范的1.0.3版。
2交互模式
3
支付宝网银接入业务规范交互模式，根据不同业务需求包括：
同步交互模式，异步交互模式，文件上传模式三种交互模式。
3.1同步交互模式
3.2
同步交互模式，也叫请求-应答模式。
在请求-应答模式下，一方作为服务提供者，另一方作为服务使用者。
由服务使用者主动向服务提供者发起请求并等待应答，服务提供者接受请求，完成处理，并向服务使用者应答处理结果，服务使用者收到处理结果之后进行后续处理。
请求-应答模式适用于服务使用者需要根据服务提供者的服务应答才能进行正确的后续处理的场景，比如，在交易查询业务中，支付宝作为服务使用者，银行作为服务提供者，支付宝需要知道银行的交易处理结果之后才能继续交易流程。
3.3异步交互模式
3.4
异步交互模式，一方作为服务提供者，另一方作为服务使用者。
由服务使用者主动向服务提供者发起请求，服务提供者接受请求，完成处理（图：
服务请求）。
返回应答结果时，之前的服务提供者角色变为服务使用者，把处理的结果作为服务请求主动向之前的服务使用者发起请求，而之前的服务使用者角色变为服务提供者，提供接收应答结果的服务（图：
服务应答）。
异步模式适用于服务提供者处理完服务请求后，需要主动通知服务使用者处理结果的场景。
比如，在网银支付业务中，支付宝作为服务使用者，银行作为服务提供者，支付宝请求数据会跳转到银行网银页面，用户在网银页面支付成功后，银行需要把处理结果主动通知给支付宝，支付宝作为接收结果的服务方再做后续处理。
图：
服务请求
图：
服务应答
3.5文件上传模式
3.6
在文件上传模式中，一方作为文件提供者，另一方作为文件使用者。
文件提供者首先生成文件，然后将文件上传给文件提供者。
在文件上传完成之后，文件提供者通知文件使用者，通知信息中包含文件的上传位置与其它信息。
文件使用者接到通知之后，根据文件内容进行后续的业务处理。
文件上传模式的特点是文件使用者拥有文件服务系统。
由于网银接入规范中，文件服务系统是由支付宝统一提供的，因此，文件上传模式适用于由银行向支付宝发起的对帐业务处理请求，如清算对账等。
4网银业务
5
支付宝网银接入规范网银业务支持业务包括：
支付业务，交易查询，余额查询，内部户明细查询，退货业务和清算业务；以上各业务都为7*24小时运行，节假日同样处理。
下面对每个业务进行详细描述。
5.1支付业务
5.2
支付业务主要实现互联网交易中的买家，通过银行网银方式来给支付宝帐户充值或进行交易支付的业务。
5.2.1业务功能
5.2.2
互联网用户可以通过支付业务，把用户在银行卡中的资金用于在支付宝网站上的交易支付和帐户充值等业务。
从而完成用户在互联网上的购物行为。
5.2.3业务规则
5.2.4
a）支付业务从支付宝发起
b）
c）支付宝清算流水号必须支付宝系统唯一
d）
e）支付业务金额不能超过银行网银产品限额
f）
g）银行对同一清算流水号的重复支付请求，只做一次处理
h）
i）银行对超过网银用户限额的支付业务请求，不能做成功处理
j）
5.2.5处理流程
5.2.6
支付业务流程：
a）用户在支付宝收银台选择充值银行
b）
c）支付宝按支付要素构造报文提交银行接口
d）
e）支付宝引导用户到选择的银行网银进行充值操作
f）
g）用户根据银行网银的要求进行操作（如：
输入卡号、密码进行校验；插入U盾等）
h）
i）银行根据规则对用户操作进行验证，并根据支付返回要素向支付宝返回
j）
i.验证成功：
ii.
1.银行实时接口通知支付宝该笔交易成功
2.
3.银行将该笔用户充值资金进行记录，日终汇总一笔转账给支付宝在银行开设的账户或内部户
4.
5.银行引导用户跳转到支付宝成功页面
6.
iii.验证失败：
iv.
1.该笔充值操作结束，银行告知用户失败原因
2.
5.2.7交互模式
5.2.8
在支付业务中，银行与支付宝通过异步交互模式进行交互。
在支付流程第2步和第3步中，支付宝构造请求要素并且主动向银行网银交易请求。
在支付流程第6步和第7步中，银行网银处理结束应答结果时主动向支付宝发起请求。
5.2.9业务要素
5.2.10
“支付业务”请求要素：
要素名称
英文缩写
要素要求
金额
Amount
● 必须要素，单位是分。
币种
Currency
● 非必须要素，如果没有该要素，则默认为人民币。
卡类型
cardtype
● 必须要素，银行按支付宝发送的借、贷、其他标示控制用户所支付能支持的卡类型
清算流水号
SerialNumber
● 必须要素，由支付宝生成，银行进行保存，其长度至少大于20位字符，支持数字和字符。
● 该字段在银行系统的唯一性，当天不重复
● 在银行系统不可重复的范围内，如果有重复的流水号提交到银行，一定不能允许其支付。
● 这里的流水号唯一性指的是相同商户标号下的流水号唯一性。
清算日期
SettleTime
● 非必须要素，格式为：
yyyyMMddHHmmss。
● 该要素用来进行流水号重复性控制，以及钓鱼的防范，比如：
银行系统时间在SettleTime-30分钟~SettleTime+30分钟以内有效，超过该范围的订单不能进行支付。
● 该要素可用来做资金对账用。
商户编号
MerchantNumber
● 必须要素，银行端用来定位密钥以及清算流水号。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
支付结果回执地址
ReturnUrl
● 银行可以通过服务器通知，或者页面跳转来通知。
支付宝建议使用通知服务器来通知，增加可靠性。
“支付业务”应答要素：
要素名称
英文缩写
要素要求
金额
Amount
● 必须要素，单位是分。
币种
Currency
● 非必须要素，如果没有该要素，则默认为人民币。
卡类型
cardtype
● 必须要素，银行按支付宝发送的借、贷、其他标示控制用户所支付能支持的卡类型
清算流水号
SerialNumber
● 必须要素，由支付宝生成，银行进行保存，其长度至少大于20位字符，支持数字和字符。
● 该字段在银行系统的唯一性，当天不重复
● 在银行系统不可重复的范围内，如果有重复的流水号提交到银行，一定不能允许其支付。
● 这里的流水号唯一性指的是相同商户标号下的流水号唯一性。
清算日期
SettleTime
● 非必须要素，格式为：
yyyyMMddHHmmss。
● 该要素用来进行流水号重复性控制，以及钓鱼的防范，比如：
银行系统时间在SettleTime-30分钟~SettleTime+30分钟以内有效，超过该范围的订单不能进行支付。
● 该要素可用来做资金对账用。
清算状态
SettleStatus
● 该要素必须有明确的结果返回。
商户编号
MerchantNumber
● 必须要素，银行端用来定位密钥以及清算流水号。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
支付结果回执地址
ReturnUrl
● 银行可以通过服务器通知，或者页面跳转来通知。
支付宝建议使用通知服务器来通知，增加可靠性。
5.3交易查询
5.4
交易查询业务是支付宝系统向银行系统查询某笔交易在银行系统中处理最终结果的业务。
目的是确认某笔交易的最终处理状态。
5.4.1业务功能
5.4.2
对于支付宝发送银行的支付、退货请求，因网络、系统等原因造成掉单的交易，为了提升用户使用体验，减少用户对资金的担忧与咨询，需在最短的时间内进行恢复。
此时支付宝需要向银行查询原请求在银行端的状态或结果，银行需将最终结果返回给支付宝。
5.4.3业务规则
5.4.4
a）交易查询业务仅支持单查询
b）
c）查询交易结果为银行最终处理结果
d）
5.4.5处理流程
5.4.6
交易查询流程：
a）支付宝按交易查询要素构造查询报文向银行发起查询请求
b）
c）银行系统接收查询请求，解读报文内容
d）
e）银行系统查询系统内对应交易号状态，并且构造结果应答报文返回
f）
g）支付宝系统接收银行查询结果应答报文
h）
i）支付宝系统处理查询应答结果
j）
5.4.7交互模式
5.4.8
在交易查询业务中，银行与支付宝通过同步交互模式进行交互。
在交易查询流程第1步、第2步、第3步和第4步交互中，支付宝构造请求要素并且主动向银行系统发起查询请求，银行系统接收报文，处理查询请求后，构造结果报文并返回支付宝系统。
5.4.9业务要素
5.4.10
“交易查询”请求要素：
要素名称
英文缩写
要素要求
清算流水号
SerialNumber
● 必须要素，同支付时的流水号要求
清算日期
TransDate
● 必须要素，格式为：
yyyyMMdd
● 银行要用该要素来进行流水号重复性控制，即银行要查询TransDate那天的流水号。
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
类型
Type
● 支付
● 退货
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
“交易查询”应答要素：
要素名称
英文缩写
要素要求
清算流水号
SerialNumber
● 必须要素，同支付时的流水号要求
清算金额
RealAmount
● 必须要素，银行实际清算成功金额，在接口文档中要详细说明该要素单位，是元还是分，还是千分位格式。
清算日期
SettleDate
● 必须要素，格式为：
yyyyMMdd
● 银行清算日期。
做充退时用来定位其实际日期。
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
清算状态
SettleStatus
● 必须要素，完整的状态必须包括成功，失败，处理中，查无记录。
● 若银行系统与其核心系统之间状态无法确定，有两种选择1、可以告知清算状态为处理中，2、告诉失败，银行自行冲正这笔交易，要确保该交易不会再变成成功。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
5.5明细查询（共用卡通提现的明细查询接口）
5.6
明细查询主要指，支付宝为向银行发起的查询银行内部户账务变化明细的业务。
目的是获了支付宝在银行内部户的账务明细。
5.6.1业务功能
5.6.2
因支付宝不在异地城商行开户，未能登录城商行网银，故需查询内部户账务明细用于对账。
查询回的明细要记录与更新。
5.6.3业务规则
5.6.4
a）明细查询业务需支持按时间段查询（如：
2010-3-1~2010-3-3）
b）
c）明细查询结果中的帐户明细为该时间段支付宝内部户的交易明细
d）
5.6.5处理流程
5.6.6
明细查询流程：
a）支付宝系统按明细查询要素构造明细查询报文向银行发起查询请求
b）
c）银行系统接收请求报文，校验数据是否有效
d）
e）银行系统查询支付宝在银行内部户该时间段账务明细，并构造结果报文返回
f）
g）支付宝系统接收银行明细查询结果应答报文
h）
i）支付宝系统记录银行内部户该时间段明细
j）
5.6.7交互模式
5.6.8
在明细查询业务中，银行与支付宝通过同步交互模式进行交互。
在交易查询流程第1步、第2步、第3步和第4步交互中，支付宝构造请求要素并且主动向银行系统发起查询请求，银行系统接收报文，处理查询请求后，构造结果报文并返回支付宝系统。
5.6.9业务要素
5.6.10
“明细查询”请求要素：
要素名称
英文缩写
要素要求
开始日期
StartDate
● 必须要素，用来确定查询的开始日期
结束日期
EndDate
● 必须要素，用来确定查询的结束日期
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
“明细查询”应答要素：
明细数据要素：
要素名称
英文缩写
要素要求
交易日
TransDate
● 必须要素，账户明细变化时的日期
金额
RealAmount
● 必须要素，银行实际清算成功金额，在接口文档中要详细说明该要素单位，是元还是分，还是千分位格式。
借贷
DebitCredit
● 必须要素，按借、贷进行区分显示
余额
Balance
● 必须要素，用来返回账户明细发生变化后的余额
摘要
Memo
● 必须要素，对该笔款项的注释，比如：
往来款、清算款、B2C充值、B2C退货、卡通充值、卡通提现、卡通退货
商户编号
MerchantNumber
●∙∙必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
●∙∙必须要素，必须使用非对称加密算法生成
5.7余额查询（共用卡通的余额查询接口）
5.8
余额查询业务是支付宝为向银行发起的查询银行内部户头寸的业务。
目的是获了支付宝在银行内部户的余额。
5.8.1业务功能
5.8.2
因支付宝不在异地城商行开户，只能开设内部户，需实时查询内部户余额，此余额是随业务增长而变化的。
同时因结算需要，还需查询每日支付宝内部户余额，此余额是日切后支付宝内部户余额，该余额日切后不可变化。
查询回的最新余额要分别记录与更新。
5.8.3业务规则
5.8.4
e）余额查询业务仅支持单查询
f）
g）余额查询结果中的帐户余额为支付宝可用余额
h）
5.8.5处理流程
5.8.6
余额查询流程：
k）支付宝系统按余额查询要素构造余额查询报文向银行发起查询请求
l）
m）银行系统接收请求报文，校验数据是否有效
n）
o）银行系统查询支付宝在银行内部户余额，并构造结果报文返回
p）
q）支付宝系统接收银行余额查询结果应答报文
r）
s）支付宝系统更新余额
t）
5.8.7交互模式
5.8.8
在余额查询业务中，银行与支付宝通过同步交互模式进行交互。
在交易查询流程第1步、第2步、第3步和第4步交互中，支付宝构造请求要素并且主动向银行系统发起查询请求，银行系统接收报文，处理查询请求后，构造结果报文并返回支付宝系统。
5.8.9业务要素
5.8.10
“余额查询”请求要素：
要素名称
英文缩写
要素要求
日期
Date
● 必须要素，用来定位查询日期
类型
Type
● 必须要素，N表示当前余额，该余额是变化的；H表示该日最终余额，该余额是不可变化的
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
“余额查询”应答要素：
要素名称
英文缩写
要素要求
日期
Date
● 必须要素，用来返回查询日期
账户余额
Balance
● 必须要素，用来返回余额
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
5.9退货业务
5.10
退货业务是支付宝发起的把已经支付成功并且结算成功的交易，按原路退回到用户银行卡的业务。
目的是把用户支付业务的现金退回到用户的银行卡中。
5.10.1业务功能
5.10.2
对于客户的充值金额，为防止套现或借用支付宝渠道转帐，支付宝控制客户不能转入其它银行。
为满足客户充值金额返回原充值银行卡的需求，开发充值退回功能，即退货业务。
5.10.3业务规则
5.10.4
a）退货业务从支付宝发起。
b）
c）单笔退货业务必须有对应的支付宝支付业务交易
d）
e）单笔退货的金额不能超过对应的支付交易的金额，但可以少于支付时的金额
f）
g）可支持多次退款，但退款总金额应少于支付时该笔交易的金额
h）
i）单笔退货的资金只能原路划回支付业务使用的银行卡账户中
j）
k）客户单笔退回时收到的资金只能从支付宝公司事先约定的清算账户中划拨
l）
m）同一退回订单号的单笔退货交易银行必须保证只能执行一次
n）
o）在未获取到银行对该笔冲退有明确结果前，不得再发起对该笔交易的第2笔冲退操作
p）
a）如果由于支付宝系统原因再次发起冲退，银行应明确做失败处理
b）
q）银行与支付宝需要保存单笔退回相关报文的日志，作为解决资金清算不一致的凭据
r）
s）支持1年内的交易退货请求
t）
5.10.5处理流程
5.10.6
退货业务流程：
第一阶段：
客户申请阶段
a）客户对充值金额申请普通提现。
b）
c）提现失败，错误提示页面出现充值退回页面链接入口。
d）
e）支付宝系统对退回交易的合法性进行验证。
验证内容包括：
f）
⏹客户的银行退货服务状态是否为激活
⏹
⏹单笔退回的交易是使用网银充值的
⏹
如果上述验证中有一项不符合，则支付宝系统拒绝该笔网银单笔退回请求。
g）支付宝系统临时冻结客户支付宝账户内与单笔退回金额等量的资金，并登记退货申请。
h）
i）支付宝向客户显示网银充值退回申请已经被接受，等待支付宝处理。
j）
第二阶段：
批量处理阶段
k）支付宝对退货交易金额进行解冻扣款
l）
m）支付宝将退货交易单笔指令，构造退货报文并发送请求
n）
o）银行处理完成后进行实时返回
p）
a）如为失败需返回具体的失败原因
b）
q）支付宝根据返回进行后续逻辑处理
r）
5.10.7交互模式
5.10.8
在退货业务中，银行与支付宝通过同步交互模式进行交互。
在交易查询流程第8步、第9步、第11步和第12步交互中，支付宝构造请求报文并主动向银行系统发起退货请求，银行系统接收退货报文，处理退货结束后，构造结果报文并返回支付宝系统。
5.10.9业务要素
5.10.10
“退货业务”请求要素：
退货报文是支付宝向银行发起的通知退货指令请求。
要素名称
英文缩写
要素要求
退货流水号
SerialNumber
● 必须要素，同支付时的流水号要求
清算日期
TransDate
● 必须要素，格式为：
yyyyMMdd
手续费
Charge
● 非必须要素
交易金额
Amount
● 必须要素，单位是分。
币种
Currency
● 非必须要素，如果没有该要素，则默认为人民币。
原交易流水号
OriginalSerialNumber
● 必须要素，对应原支付流水号
原交易日期
OriginalTransDate
● 必须要素，对应原支付日期,格式为：
yyyyMMdd
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
● 必须要素，必须使用非对称加密算法生成
● 待签名要素必须覆盖所有接口中需要传递的要素
● 若查询时采用的双向加密认证的通信通道则可以不使用数字签名
“退货业务”应答要素：
要素名称
英文缩写
要素要求
退货流水号
SerialNumber
● 必须要素，同支付时的流水号要求
清算日期
TransDate
● 必须要素，格式为：
yyyyMMdd
手续费
Charge
● 非必须要素
交易金额
Amount
● 必须要素，单位是分。
币种
Currency
● 非必须要素，如果没有该要素，则默认为人民币。
原交易流水号
OriginalSerialNumber
● 必须要素，对应原支付流水号
原交易日期
OriginalTransDate
● 必须要素，对应原支付日期,格式为：
yyyyMMdd
处理状态
Status
● 必须要素，Y成功，N失败
失败原因
Reason
● 非必须要素，如果处理状态为失败，则描述失败原因
商户编号
MerchantNumber
● 必须要素，用来定位密钥，以及流水范围，查询出来的结果一定要是在这个商户编号下面发生的。
数字签名
Signature
● 必须要素，
升级会员 