交易附件2：银联互联网安全支付规范修改说明（SAA模式）

机构接入Cupsecure网银模式SAA模式改造说明一、交易处理部分

1、基本信息解释

发卡机构直接验证授权模式 S AA模式

Issuer Secure Authentication and Authorizaiton Mode

在发卡机构直接认证模式中 由持卡人安全认证授权系统以下简称S AA提供界面供持卡人输入身份认证安全信息并完成相应支付交易的安全认证模式。

由发卡机构自行收集用户安全认证信息完成安全认证和授权处理。

持卡人的认证方式和认证要素由发卡银行决定。

持卡人安全认证授权系统

Secure Authentication and Authorizaiton Server SAA

适用于发卡机构直接验证授权模式可以由发卡机构自建或者是委托第三方建设。主要功能为提供和持卡人之间的交互服务、身份验证服务和交易授权服务。

2、交易处理说明--交易种类

 1金融类的交易

余额查询跨行余额查询或某些业务类型的辅助交易

消费、消费撤销、退货

预授权、预授权撤销、预授权完成、预授权完成撤销

账户验证、汇款跨行汇款

代扣保险业务、 电话邮购等

2通知类的交易

交易异常通知为S R发往S AA的消息通知发卡机构S R在对互联网交易进行后续处理时发生异常状况发卡机构需要针对异常的种类对原始交易进行相应的修正

3管理类的交易

交易结果查询为API发往S R的银联卡交易结果查询请求消息用于API未接收到SR响应的ITRes时收单机构主动发起查询请求确定交易结果

卡段下载从API发往SR的消息用于请求以全量/增量方式下载CUPSecure支持的卡段的更新

3、交易处理说明—消息种类

1消息的作用

消息是用来传递详细交易以及交易控制信息的。

2消息的种类

SCReq、 SCRes卡段下载类消息

CEReq、 CERes卡参与查询类消息

ITReq、 ITRes互联网交易类消息

IRReq、 IRRes交易结果查询类消息

ITExc互联网交易异常消息

Error错误消息

4、 SAA安全认证授权方包括的参与对象/组件及其功能

表1 安全认证方参与对象/组件

5、 SAA发卡机构直接验证授权模式交易流程

 1注册系统建立

对于发卡机构直接验证授权模式为确保S AA能够获得支付验证过程中所需要的充足信息发卡机构可以建立注册系统。发卡机构自行定义持卡人注册流程还可以采用柜面注册等方式。本节不对注册系统建立流程进行描述。发卡机构还可以采用柜面注册等方式。对于发卡机构的S AA系统由于其能与持卡人进行完全交互账户的处理由S AA自行完成 。对于认证持卡人时需要输入的信息和账户系统的接口亦不在本规范定义范围之内。2交易处理流程预说明

发卡机构直接验证授权模式也是针对发卡机构而言。5.2中描述了S AA模式下发卡机构支持的交易种类。同SC模式消费、预授权和余额查询交易也需要需要持卡人的实时参与而其他交易则不需要。

同时S AA模式下会有一类特殊的交易需要从S AA直接发起。并且区分通知类和管理类。所以下面会区分这四种情况分别描述交易处理流程。

3消费/预授权/余额查询交易处理流程

下述交易流程适用于消费、预授权和余额查询交易。由于余额查询交易不包含交易金额等信息 因此S AA显示给持卡人的页面不包含交易金额和交易币种信息。

流程说明

发卡机构 SAA

0 API

收单机构支付网关发卡机构直接验证模式交易流程图

上图所示为发卡机构直接验证授权模式交易流程图流程说明如下表发卡机构直接验证授权模式交易流程说明

步骤0

为了减少API访问SR的次数提高系统效率 API应具备从SR下载CUPSecure支持的卡段并存放在cache中的功能。一旦API开启该功能则API可以通过直接查询cache来判断卡片是否在CUPSecure支持的卡段内。 cache中的内容每24小时后将失效且需要重新刷新。因此一旦API首次将卡段装载到cache中其后每隔24小时将定时请求更新cache。

注意为了防止所有AP I同时请求更新卡段 AP I中的更新时间应该可配置。

具体流程如下

1 API生成SCReq消息并发送给SR。

更新方式有两种全量更新和增量更新。

当API需要全量更新时 API生成的SCReq消息中不包含“序列号”域 SR将返回所有参与CUPSecure的卡段。该方式一般用于第一次装载或者是重新装载所有卡段到cache中的情况。

当API需要增量更新时 API从最近收到的SCRes消息中提取出“序列号”域值并包含在SCReq消息中这样SR将只返回自生成前一SCRes消息时间点以来所有变化卡片范围值。

2 SR生成SCRes消息返回给API。

如果在SR收到的SCReq消息中包含“序列号”域则SR只返回自生成前一SCRes消息时间点以来所有变化卡片的范围值。否则 SR将返回所有参与CUPSecure的卡段。

3 API更新cache。

更新cache时必须按照SR返回的卡段列表顺序更新 同时根据“操作标志”域值来进行增加或者删除操作。 同时 AP I必须保存“序列号”域值。

步骤1

1持卡人浏览商户网站购买商品选择使用银联卡进行网上支付

2商户网站提交支付请求到收单机构支付网关 同时将持卡人浏览器页面定向到支付网关支付页面。

步骤2

持卡人在支付网关上输入并提交银联卡号。

步骤3

本步骤在持卡人结账时“确认支付”时触发。支付网关调用API发起交易预授权/消费/余额查询请求流程如下

 1API如果具有下载卡段的功能首先在cache中查找卡号是否包含在参与CUP S ecure的卡段中如果是则API生成CEReq消息否则API发送拒绝通知给收单机构网上支付交易接口并终止本次交易流程。如果API不具有下载卡段的功能则API生成CEReq消息2API提交CEReq消息给S R。

步骤4

SR处理

本步骤在SR从API接收到CEReq消息后立即触发流程如下

 1 SR从CEReq消息中获取持卡人卡号并判断该卡号是否在注册参与CUPSecure的卡BIN范围中如果未包含在卡BIN范围中则SR生成CERes消息将“卡号参与验证标

志”域值设置为“N”并将CERes消息返回给API本次交易流程结束

2若该卡号包含在卡BIN范围之中则SR根据卡号确认卡片参与的安全认证模式如果确认该卡参与发卡机构直接验证授权模式服务则SR生成CERes消息将“卡号参与验证标志”域值设置为“Y” 同时为了防止持卡人在传递交易是篡改信息 SR将交易关键信息签名将签名放置在CERes中具体关键信息的构成参见认证数据域的说明并将CERes消息返回给API

API接收响应

对于API而言本步骤在API提交CEReq消息给S R后立即触发对于SR而言本步骤在SR将CERes消息转发给API后立即触发。处理流程如下

API检查接收到的CERes消息如果“卡号参与验证标志”域值不为“Y”则响应拒绝通知给收单机构支付网关并终止本次交易流程。

步骤5~步骤6

本步骤在API接收到CERes消息后立即触发。处理流程如下

 1API生成ITReq消息预授权/消费/余额查询其中包含从CERes中获得的认证数据信息

2API将ITReq消息压缩表示为B a s e64编码得到ItReq值

3AP I构造如下表格

AP I发往S AA的域

4API通过持卡人浏览器将ITReq消息传递给CERes消息中定义的持卡人交互方URL本模式下该域值即为S AA的URL 同时通过持卡人浏览器将上述表格提交给S AA。这一过程通常由JavaScript组成。

步骤7

本步骤在S AA接收到AP I的包含ITRe q消息的提交后立即触发。处理流程如下

 1 SAA将ItReq域解码解压缩为ITReq消息

2 SAA首先验证认证数据域将其中的交易关键信息和ITReq中信息相比较若一致则继续后续处理若有任何的不一致则拒绝生成拒绝报文

下面以要求持卡人输入用户名、密码和身份证号码等安全信息为例来说明本步的处理流程。 1 S AA收到提交后产生一个含表格的H TML页面给持卡人。下表为该表格内容的一个示例。

持卡人认证页中的显示域示例

数据项 由S AA产生 从ITReq中提

2 SAA提示持卡人输入用户名、密码和身份证号码

3 SAA接收持卡人的输入。

步骤8

处理流程如下

 1 SAA验证持卡人身份

2若持卡人通过身份验证则S AA直接进行交易的处理

3 SAA根据交易结果生成ITRes并且对ITRes签名其中包含交易状态

4 SAA将ITRes发送给SR

步骤9

SR验证ITRes中的签名并且针对ITRes重新采用SR的证书签名后将ITRes发送给APIAPI验证I TRe s中的签名。

验证过程中采用SR证书验证ITRes的数字签名。 ITRes包含采用SR证书的序列号。该验证功能可以集成在API中或者采用一个独立的ITRes签名验证服务器。

注意验证数字签名需遵循现有的数字签名规范并且验证ITRes签名必须验证整个SignedInfo元素的内容包括元素间的空格。

如果采用独立的ITRes签名验证服务器则签名验证过程如下

 1API将ITRes消息发送到ITRes签名验证服务器

2 ITRes签名验证服务器采用根证书验证ITRes签名

3 ITRes签名验证服务器将验证结果发回给API。

步骤10

 1SAA收到SR收到ITRes的确认后对ITRes消息先进行压缩然后进行B ase64编码生成ItRe s值

2 SAA构建如下表格

S C发往API的域

3 SAA通过持卡人浏览器以PO ST方式将上述表格提交给API 以达到将的ITRes消息传递给API URL 即API提交表格中包含的TermUrl值的目的。

4支付网关后续处理流程如下

A调用API接口取得ITRes

B将交易处理结果返回给商户及持卡人。支付网关向持卡人显示交易结果具体显示内容参见附录A。

特别说明

从上述的流程中看到API会从SR收到ITRes同时也会通过持卡人的浏览器收到SAA返回的ITRes。针对两处收到ITRes API以SR发出的ITRes为准。

仅当ITRe q出现语法错误时 S AA会直接返回Error报文。

上述内容皆为正常情况下的处理情况交易异常处理的说明详见《Cupsecure核心功能规范》第一部分交易处理说明。

二、报文接口部分

SAA需要处理的报文包括如下几个接收API发过来的ITReq请求交易处理完毕后反馈API应答报文ITRes

当SAA发现有状态未明的交易时可针对该交易主动向S R发起交易结果查询IRReq请求并能处理SR对该笔查询请求反馈的应答信息IRRes

S AA模式下 S R向交换系统记录日志异常时会向S AA发送I TE x c消息告知S AA该交易出现异常。 S AA应能辨别该报文并进行相应的后续处理。

1、消息域说明

ITReq

可以是由AP I通过持卡人浏览器发往S C/S AA或是AP I直接发往S R或是S AA发往S R以提交互联网交易请求。

消息域说明

ITReq消息域说明