ICS 35.240.60 YD L 67 中华人民共和国通信行业标准 YD/T 1322.2-2004 电子商务技术要求 第二部分：支付网关 Electronic commerce technical specification Part two: payment gataway 2004-08-04发布 2005-01-01实施 中华人民共和国信息产业部•发布 YD/T 1322.2-2004 目 录 前 言 1 范围 规范性引用文件 3 缩略语 4 支付API 消息流 5.1 认证文档交换（AuthenticationDocumentation Exchange） 5.2 品牌编辑（BrandCompilation) 5.3 品牌选择（BrandSelection） 5.4 支付成功(Successful Payment) 5.5 故障处理（Failure Processing） 18 5.6 支付流程 26 5.7 支付询问 28 5.8 IOTP钱包初始化 28 5.9 支付软件管理 29 6相关性 29 6.1 属性和元件 34 6.2完成代码 38 7支付API调用 38 函数调用 62 附录A（规范性附录） IOTP的SET支持 YD/T 1322.2-2004 前言 本部分为电子商务系列标准之。本系列标准的结构及名称如下： 1.YD/T1322.1-2004《电子商务技术要求第一部分：基于扩充标记语言（XML）的企业对消费者 （B2C）电子商务总体框架》； 2.YD/T1322.2-2004《电子商务技术要求第二部分：支付网关》； 3.YD/T1322.3-2004《电子商务技术要求第三部分：证书及认证系统》； 4.YD/T1322.4-2004《电子商务技术要求 第四部分：票据的表示层句法》。 本部分的附录A为规范性附录。 本部分由中国通信标准协会提出并归口。 本部分起草单位：信息产业部电信研究院 本部分主要起草人：何宝宏田辉刘治袁琦 YD/T 1322.2-2004 电子商务技术要求 第二部分：支付网关 1 范围 本部分规定了因特网开放贸易协议（IOTP）应用内核与支付模块之间的通用接口，目的是保证这些 模块之间的互操作性，并规定了在实际实现IOTP应用内核时的一种“即插即用”机制，同时还定义了基 于IOTP的支付应用编程接口（API）、消息流程等。 本部分适用的接口存在于消费者、商家和支付处理方三者之间，将IOTP应用内核与支付软件组件/ 策略系统连接起来。 2规范性引用文件 下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的 修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究 是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。 YD/T 1322.1-2004 电子商务技术要求第一部分：基于扩充标记语言（XML） 的企业对消费者（B2C）电子商务总体框架 RFC1866 HTML语言 RFC2068 HTTP协议 RFC2801 因特网开放贸易协议（IOTP） RFC2802 IOTP的数字签名 RFC2935 IOTP的HTTP补充 Draft-ietf-trade-iotp-v1.0-papi-05 IOTP的支付API Draft-ietf-trade-iotp-v1.0-set-02 IOTP的SET补充 3缩略语 本部分使用以下缩略语： API Application Programming Interface 应用编程接口 IOTP Intermet Open Trading Protocol 因特网开放贸易协议 SET Secure Electronic Transaction Specification 安全电子交易规范 SSL Secure Socket Layer 保密套接层 XML eXtensible Markup Language 可扩展标记语言 POS Point of Sales 电子收款机 4支付API IOTP将单纯的支付协议，比如SET（安全电子交易协议），基于SSL（保密套接层）的卡支付方式、 类似CyberCash的电子现金以及小额支付等扩充为交易协议，使之能够处理购物单、支付收据以及配送响 应，它并不取代任何一种支付方式，相反，它提供了一个对这些特殊支付协议的封装方法，只需做少量 改动，IOTP应用依然可以使用现有的支付软件。IOTP应用内核建立了IOTP交易平台、IOTP交易数据管 理系统以及用户接口，而把实际的支付处理交给现有的支付软件。 1 YD/T 1322.2-2004 4.1典型支付交易的逻辑步骤 表1概括了典型支付交易的4个逻辑步骤，其中省略了支付交易之前的购物合同、支付方式、购物 金额和配送规则。 表1典型支付交易的4个逻辑步骤 支付状态 角色 行为举例 支付处理方 产生身份请求、偿付能力请求以及一些随机数 相互认证与初始化 消费者 响应这些请求以及产生自己的随机数 支付处理方 产生授权请求（为消费者） 消费者 同意支付（通过预留消费者的电子货币） 授权 接受或拒绝此同意（消费者的授权响应），产生授权请 支付处理方 求（为发卡行或获取者）并处理其响应 产生获取请求（为发卡行或接收行） 获取 消费者 被收取费用 支付处理方 接受或拒绝该电子货币，结束此次支付交易 拒绝时（在线或离线）：产生逆转数据 逆转 消费者 接收退款 可是有些支付方案： ·将交易过程限制为单向认证； ·实行离线授权，不通过任何发卡行或接收行， ·在“获取”处理中使用“批”模式； ·根本不对授权和获取加以区分； ·缺少一种有效的带内机制用于逆转或实现有限的变化。 该模型不仅适用于典型的POS支付，还可以扩展到退款、存款、撤销、电子支票、直接借记和资金 转拨。 般支付API支持各种支付方式以及未来的支付方式，消费者使用IOTP钱包时不必关心所采取 的具体支付方式，这对消费者接受IOTP钱包十分重要，对支付网关同样重要，因为如果支付网关可 以同时为多种不同的支付方式提供服务，那么就能够把支付网关原来所连接的支付系统的接口标准 化。 在支付交易中，支付API为所涉及的当事人提供个交换支付协议消息的标准方法，但这需要实现 IOTP支付桥。另外，经过良好定义的支付API能够使支付软件开发人员将自已设计的构件插入到其他开 发人员的通用IOTP应用中。 2 YD/T 1322.2-2004 4.1典型支付交易的逻辑步骤 表1概括了典型支付交易的4个逻辑步骤，其中省略了支付交易之前的购物合同、支付方式、购物 金额和配送规则。 表1典型支付交易的4个逻辑步骤 支付状态 角色 行为举例 支付处理方 产生身份请求、偿付能力请求以及一些随机数 相互认证与初始化 消费者 响应这些请求以及产生自己的随机数 支付处理方 产生授权请求（为消费者） 消费者 同意支付（通过预留消费者的电子货币） 授权 接受或拒绝此同意（消费者的授权响应），产生授权请 支付处理方 求（为发卡行或获取者）并处理其响应 产生获取请求（为发卡行或接收行） 获取 消费者 被收取费用 支付处理方 接受或拒绝该电子货币，结束此次支付交易 拒绝时（在线或离线）：产生逆转数据 逆转 消费者 接收退款 可是有些支付方案： ·将交易过程限制为单向认证； ·实行离线授权，不通过任何发卡行或接收行， ·在“获取”处理中使用“批”模式； ·根本不对授权和获取加以区分； ·缺少一种有效的带内机制用于逆转或实现有限的变化。 该模型不仅适用于典型的POS支付，还可以扩展到退款、存款、撤销、电子支票、直接借记和资金 转拨。 般支付API支持各种支付方式以及未来的支付方式，消费者使用IOTP钱包时不必关心所采取 的具体支付方式，这对消费者接受IOTP钱包十分重要，对支付网关同样重要，因为如果支付网关可 以同时为多种不同的支付方式提供服务，那么就能够把支付网关原来所连接的支付系统的接口标准 化。 在支付交易中，支付API为所涉及的当事人提供个交换支付协议消息的标准方法，但这需要实现 IOTP支付桥。另外，经过良好定义的支付API能够使支付软件开发人员将自已设计的构件插入到其他开 发人员的通用IOTP应用中。 2 YD/T 1322.2-2004 4.1典型支付交易的逻辑步骤 表1概括了典型支付交易的4个逻辑步骤，其中省略了支付交易之前的购物合同、支付方式、购物 金额和配送规则。 表1典型支付交易的4个逻辑步骤 支付状态 角色 行为举例 支付处理方 产生身份请求、偿付能力请求以及一些随机数 相互认证与初始化 消费者 响应这些请求以及产生自己的随机数 支付处理方 产生授权请求（为消费者） 消费者 同意支付（通过预留消费者的电子货币） 授权 接受或拒绝此同意（消费者的授权响应），产生授权请 支付处理方 求（为发卡行或获取者）并处理其响应 产生获取请求（为发卡行或接收行） 获取 消费者 被收取费用 支付处理方 接受或拒绝该电子货币，结束此次支付交易 拒绝时（在线或离线）：产生逆转数据 逆转 消费者 接收退款 可是有些支付方案： ·将交易过程限制为单向认证； ·实行离线授权，不通过任何发卡行或接收行， ·在“获取”处理中使用“批”模式； ·根本不对授权和获取加以区分； ·缺少一种有效的带内机制用于逆转或实现有限的变化。 该模型不仅适用于典型的POS支付，还可以扩展到退款、存款、撤销、电子支票、直接借记和资金 转拨。 般支付API支持各种支付方式以及未来的支付方式，消费者使用IOTP钱包时不必关心所