【通信行业标准(YD)】 电子商务技术要求 第二部分:支付网关

ICS35.240.60
中华人民共和国通信行业标准
YD/T 1322.2-2004
电子商务技术要求
第二部分：支付网关　
Electronic commerce technical specificationPart two: payment gataway
2004-08-04发布
2005-01-01实施
中华人民共和国信息产业部发布前
规范性引用文件
缩略语
支付API
消息流
认证文档交换（Authentication Documentation Exchange）品牌编辑（BrandCompilation）品牌选择（BrandSelection）
支付成功（SuccessfulPayment)故障处理（FailureProcessing）支付流程
支付询问
1OTP钱包初始化
支付软件管理
6相关性
属性和元件
6.2完成代码
7支付API调用
8函数调用
附录A（规范性附录）
IOTP的SET支持
YD/T 1322.2-2004
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为规范性附录。
本部分由中国通信标准协会提出并归口。本部分起草单位：信息产业部电信研究院本部分主要起草人：何宝宏　田　辉　刘　治　袁　琦标准授搜网bzxZ.net
1范围
电子商务技术要求
第二部分：支付网关　
YD/T 1322.2-2004
本部分规定了因特网开放贸易协议（IOTP）应用内核与支付模块之间的通用接口，目的是保证这些模块之间的互操作性，并规定了在实际实现IOTP应用内核时的一种“即插即用”机制，同时还定义了基于IOTP的支付应用编程接口（API）、消息流程等。本部分适用的接口存在于消费者、商家和支付处理方三者之间，将IOTP应用内核与支付软件组件/策略系统连接起来。
2规范性引用文件
下列文件中的条款通过本部分的引用而成为本部分的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本部分，然而，鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本部分。YD/T 1322.1-2004
RFC1866
RFC2068
RFC2801
RFC2802
RFC2935
Draft-ietf-trade-iotp-v1.0-papi-05Draft-ietf-trade-iotp-v1.0-set-023缩略语
本部分使用以下缩略语：
4 支付 API
电子商务技术要求第一部分：基于扩充标记语言（XML)的企业对消费者（B2C）电子商务总体框架HTML语言
HTTP协议
因特网开放贸易协议（IOTP）
IOTP的数字签名
IOTP的HTTP补充
IOTP的支付API
IOTP的SET补充
Application Programming InterfaceInternet Open Trading ProtocolSecure Electronic Transaction SpecificationSecure Socket Layer
eXtensible Markup Language
Point of Sales
应用编程接口
因特网开放贸易协议
安全电子交易规范
保密套接层
可扩展标记语言
电子收款机
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应用中。
宁提理区
IOTP支付API
现有的支付 API如
SET, Mondex 等
IOTP客户
消费者
IOTP/支付桥
现有支付软件
XML接口：封装
为IOTP消息
图1OTP支付桥
IOTP服务器
IOTP/支付桥
现有支付软件
YD/T 1322.2-2004
IOTP支付API
简单地说，支付API接受来自远端系统的支付协议消息，变换为近端系统支付协议的输人参数，并把近端系统支付协议的消息返回给远端系统。在两者之间交换支付协议消息，直到支付网关的支付API系统用信令通知此次支付结束。图1中的各个组成部分之间的关系可以是任意的。一个IOTP应用内核可能管理多个IOTP桥，而后者可以被多个IOTP应用内核所共享；每个支付桥可能管理多个现有的支付软件模块，而后者可以被多个支付桥所共享；每个现有的支付软件可能管理多个支付方案（例如SET），而后者可以被多个现有的支付软件模块所支持；每种支付方案可能支持多种支付手段（例如ParticularCard）或方法（例如SET上的VISA)，而后两者可以被多个现有的支付软件组件所共享。当处理商家的、配送中心的或客户服务中心的IOTP应用时，用现有的支付系统和IOTP中间件取代原来与支付相关的部分。
4.2要求
任何支付API必须适合多种支付方式，包括软件方式的信用卡（如SET、CyberCoin）以及智能卡方式（像Mondex、GeldKarte）支付，并耳应该能够模拟传统的支付方式，如资金转拨、借记、存款、取款和货币兑换等，最后，支付系统必须是能够实现的。支付API应该同时支持消费者明确确认支付和软件自动确认两种支付方式，当然后者需要得到消费者事先同意。对于支付API可以考虑将以下交易类型作为基本IOTP类型：·基本购物；
·基本退款；
·基本货币兑换；
·基本撤销；
·基本（支付）咨询。
支付API应具有明确自标以及构成IOTP应用视图主要组成部分的能力。一方面，支付API应该是非常强大而灵活的，能够在一般和特殊组件之间建立起充分联系，以使IOTP应用内核真正从中受益；另一方面，支付API不应搭载过多“额外的”现有支付软件不支持的东西。IOTP应用内核只要支持非常基本的查询机制就可以了，复杂的如支付方案指定的查询、失败分析、失败解决等都可以交给包括用户接口标性座网
冰标注行资费票
YD/T1322.2--2004
在内的实际现存支付软件来完成。应把特殊支付方式的询问机制延伸至现有的支付软件中去，也应把完整支付处理中的错误解析延伸至现有的支付软件中去。IOTP应用内核的实现应该是通用的，支付方案作为IOTP交易处理的独立部分，并提供适当的用户接口。单就支付而言，IOTP应用内核应该能够：·管理已注册的IOTP支付桥，为其注册提供一种机制，包括注册过程；·假设所有IOTP支付桥都是被动组件，即严格的等待输人数据，对每个请求产生一个回应；·支持支付请求之前消费者选择支付工具的过程（消费者：选择实际支付手段或方法；商家：提供消费者不同的选择)；
·通过IOTP桥，从所选择和注册的现有支付软件中，引用请求其它特定支付手段来进行支付；·通过IOTP桥，初始化和终止现有支付软件；·从消费者处请求认证数据；
·管理在线交易过程和并加以跟踪；·实现所有支付交易过程的标识符；·为现有支付软件提供通用会话，比如传递输入信息、基本交易咨询、平账咨询、支付品牌选择通知、支付指令插人和支付挂起/取消；·验证（以前）收到的支付收据以及（已结束的）支付交易的状态：·为支付交易保存交易数据和提供询问机制；·为了对特定支付方式做进一步的处理，支持在交互模式下对现有软件模块的使用；·输出回调函数，用在支付桥或现有支付软件的过程指示中，或对数据库进行存取；·输出回调函数，用以产生惟一的交易标识符。这些标识符代表了每个参与方（支付）交易的惟一性；
·通过IOTP支付桥，在基于IOTP的元件和本地元件指示器之间提供一个映射机制。为简单起见，IOTP应用内核和IOTP支付桥独立实现它们各自标识符的产生和维护机制。IOTP支付桥的实现相对简单，比如它可以简单列举属性和元件的输入/出属性（参见后面的API功能的咨询过程状态）。另外，IOTP应用内核还应能够：·咨询将要发生和已经完成的支付交易。·支持解决特定支付工具的问题。·管理交易过程中的IOTP构件以及IOTP交换块，可能会为随后的消息处理（如签名认证）所引用或访问。
·把每种IOTP交易类型与支付交易相关联，把每次支付交易与多个支付参数（如IOTP交易标志、交易协议选项、支付指令、报价响应、IOTP桥和钱包标识符）相关联；当已经成功开始支付交易时，可以把后一种关联简化为消费者支付标识符、IOTP支付桥和钱包标识符。·管理多种标识符，如交易、消息、构件和块标志等。·提供消息缓冲机制。支付网关可以缓冲除询问和ping外的所有输人消息、输出消息及其对应的响应关系。如果请求和相应的响应都已经出现在缓冲中，则可以利用缓冲区的信息作为响应。应该忽略缓冲中仅有请求的情况，因为这说明其处理尚未结束。在消费者系统中，至少应保存最后发送的IOTP请求以及消费者侧的内部支付状态。在检测到远端超时时，消费者的支付系统应该重传已更新的最后一条IOTP状态信息。
·忽略更低层协议的故障。因为它们是由其它协议机制处理的，如用TCP/IP来处理传输错误。·对IOTP应用内核和API层的检测能够同时反映出远端用户和本地外设通信超时的情况，比如智能卡可能出现超时。
·把特殊支付错误的解决延至现有的支付软件。在多数情况下，这些问题是通过对来自IOTP应用内核的支付交换消息的扩展交换来实现的。最关键的故障是突然不可用，或本地或对端支付部件瘫痪。
标准授
YD/T 1322.2-2004
·假定IOTP桥是支付系统的一个被动构件。比如，它等待任何输人数据并且产生个响应；特别是必要时它既不需要识别，也不需要通知超时信息。IOTP支付桥和现有支付软件并不一定依赖IOTP应用内核的能力。比如它们可能会实现一些自已的会话；又如SET钱包可能会拒绝品牌选择时特定支付工具的输出，也可能会运用自已的接口把该选择推迟到检查支付可能性的那一步。
IOTP支付桥并不具有处理自消费者到支付网关的实际支付的能力，但扩展了以下的IOTP能力：·在应用内核和现有支付软件消息格式之间做翻译。如果一个IOTP支付API调用裂变为多个现有支付软件的调用，它必须把它们的输出组装回一个IOTP支付API响应。·消费者支付工具的选择依靠支付品牌、支付协议和支付工具（标志）的不安全输出关联。一般来说，这不仅包括品牌（Mondex，GelAkrte等），也包括所使用支付工具和币种的特定实例（比如哪种特定的Mondex卡以及哪种特定货币可以使用）。但是有些支付方式可能把这些支付工具的选择推迟到实际进行支付的时候，而有些方式甚至缺少对多种支付工具管理的能力，比如智能卡支付方式可能只提供POS(Pointof Sale）一一隐含的意思是支付工具的选择是简单地把智能卡插人对应的读卡机中；或卡支付方式询问已插人的卡，请求检测到的支付工具的做出应答（或选择）。·支付过程检查。检查比如实施购物的资金是否可用。·账务平衡查询。例如在接受支付交易之前，消费者可能会查询支付卡或远端管理账务。·IOTP支付收据检查。更准确地是指检查收据的打包内容。它可能会进一步支持特定支付方式的收据检查。典型情况下是在IOTP支付策略构件，而不是在IOTP支付响应块或智能卡产生的构件之间交换。
罗列XML属性和元件的输人和输出。罗列XML属性和元件包含在顶级XML输人元件中。由顶级和一级XML输出元件按增序命名，通过API函数调用以文本次序罗列。·把包含在品牌、特定IOTP支付收据或特定支付收据的实际支付方式中的数据，解码成能够让用户显示或打印的某种格式。
·取消支付交易，即使是在支付还没有完成的时候也可以取消支付。·挂起或重新开始支付交易。现有支付软件必须处理的一个源故障是网络连接超时。为此，IOTP应用内核可能会设法挂起一个以后可能重新开始的视图。另外一种可能是，IOTP应用内核发出交易取消的信号，但现有软件不能依赖于正确的挂起/取消，比如当它停机时，必须考虑到任何异常，并且解决不一致性。另外一个源故障是资金不足，这时IOTP应用内核发出挂起当前支付交易的信号。消费者可能下载货币，以及可能恢复以前的交易。·支付交易状态查询，以便查询人能够决定恰当的下一步。·询问支付交易，特别是应支持特定支付状态的交易咨询。在启动时IOTP应用内核可能咨询和解析即将进行的交易，比如判断计算机系统是否（因电源故障）岩机。·IOTP支付桥负责详细规定被咨询的交易数据的细节。它可以通过本地数据库、日志文件、智能卡或远端账务管理员做出推断。
·在数据库中存入支付的过程和状态。比如未结束的支付信息，用来在下一个支付协议消息到来时使支付过程继续。
·支付进度指示，用来告知最终用户支付过程的细节。·特定支付方式的认证方式。
现有的支付软件可能并不支持所有上述能力。比如，某些支付协议可能不支持或甚至不允许在支付进程的任意阶段直接取消交易。但无论如何，IOTP支付桥必须实现最低要求，至少能使用出错代码（如下）通知呼叫方存在某些支持方面的缺陷，现有的支付软件存在着非常大的性能变化，比如：·支持实际的在线支付交易。
·解决大部分类型的特定支付故障，5
YD/T 1322.2-2004
·在出现问题时，对外提供失败处理方案提示信息。，能够实现很大范围内的交易数据管理和查询机制，比如从无交易、最后交易、微芯片延时交易、简单交易历史（以及列表查看）的记录查寻，一直到经验丰富的用户提出的非常复杂灵活的查询等。对于支付双方，后一种方式关系到能否容易而有效地排除支付故障。·可以使用IOTP应用内核的通用对话框。当然，某些（商业的）特定规则或支付方面的特殊要求可能需要使用更多的对话框；或使用它们专用外观/结构/内容的对话框来禁止未加密的支付手段；或者可能把口令的输人置于它自己的控制之下。API必须能够同时处理支付成功和支付失败的情形，这是因为：·这关系到支付交易管理员的薪金。·金融机构要求因特网支付系统的可靠性可以与POS相媲美。·同时使用传统的支付方式和基于因特网的支付方式时，对这两种支付方式的接受程度互相具有影响。
·能被广泛接受的支付方式需要能迅速地排除故障。·逆向支付处理可能被限制在当前交易，或可能会锁住以后的支付交易。·不一定因为交易失败而封锁公用的因特网支付终端。·支付双方不希望因为支付者的一小部分系统出错而锁住系统。·发卡者解决故障的方法可能会是缓慢、痛苦、昂贵和对用户不友好的。如果不需要修改智能卡中的内容，可以使用包括邮件/电子邮件、传真或电话等方法来撤销支付。如果消费者能重新连接到支付网关系统，委托支付解决方案并继续进行支付，在多数情况下是可以解决支付问题的。但支付API必须考虑最坏的情况，即重新连接时也失败，那么双方都需要一个可信赖的分析报告，以求了解当前支付交易的状态和可供选择的解决办法。5消息流
支付API调用可划分为一般性咨询调用、与支付交易相关的咨询调用、品牌选择和支付交易相关的调用、客户中心相关支付指令调用以及其它调用。1）与品牌编辑相关的API调用（BrandCompilation Related APICall）确定可接受的支付品牌的数量。出于品牌选择的目的，指定可接受的支付协议和特定打包内容所返回的支付方式。
Get Payment InitializationData：支付处理方为了处理支付而返回的额外支付策略的特定打包内容。InquireAuthenticationChallenge：返回支付协议特定认证盘问值。Authenticate：把处理用的所有与特定支付协议相关的认证信息转发给IOTP支付桥。Check Authentication Response：验证所返回的特定支付协议认证响应值。2）与支付选择相关的API调用（Brand Selection Related API Call）Find Payment Instrument：确定在一次支付中特定支付品牌的可以使用哪种支付工具。FindPaymentProtocol：确定特定支付工具以及所对应的支付品牌能够支持的支付协议。Check Payment Possibility：查验某种支付工具能否完成一次支付。Authenticate：参见与品牌编辑相关的API调用（Brand Compilation Related APICall）。3）与支付交易相关的API调用（PaymentTransaction RelatedAPICall）Start/ResumePaymentConsumer/PaymentHandler：初始化或重新启动一次交易，不同的交易角色（消费者和支付处理方）具有不同的API调用。ContinueProcess：转发支付策略数据给现有的支付软件，传递给对方，以便返回更多的支付策略数据。
Change Process State：终止或挂起当前的支付交易。4）一般性咨询 API 调用（General Inquiry API Call)6
InquirePayment Log：询问不同类型支付的支付标志，可以通过多个参数询问。PaymentInstrument Inquiry：检索支付工具的属性。InquirePendingPayment：报告IOTP桥是否有未决的交易。YD/T 1322.2-2004
5）与支付交易相关的API咨询调用（PaymentTransactionRelatedInquiryAPICall）Check Payment Receipt：检查由“Inquire Process State API”调用返回的IOTP支付收据的有效性。用于查验该支付收据与各自的支付交易是否一致和/或匹配。典型的用法是在消费者的支付交易最终处理过程中，不管怎样，在排除故障时该检查可能对消费者、支付处理方和支付工具消费者服务中心都有好处。
ExpandPaymentReceipt：扩展IOTP支付收据的内容和支付特定支付收据的，成为-个能够显示或打印的形式。
InquireProcessState：对应支付状态和IOTP支付收据构件。支付处理方通常在支付交易的结束时做这样的处理。
Start Payment Inquiry：准备对支付交易状态的远程询问，响应支付处理方可能需要的特定支付策略数据，用于消费者启动询问处理。Inquire Payment Status：支付处理方对消费者启动询问请求的称呼。它提供询问响应块的支付特定内容。
“Continue Process”和“Change Process State”参见与支付交易相关的API调用（Payment TransactionRelated API Call)
6）其它API调用（OtherAPICall）ManagePaymentSoftware：激活紧邻的现有支付软件以后的用户输入，这将受到现有支付软件的控制。
表2给出了哪个API必须“4”，应该“+”或可能“，”由哪种交易角色实现。衰 2 API 功能与交易角色的映射API功能
Find Accepted Payment Brand
Find Accepted Payment ProtocolFind Payment Instrument
Find Payment Protocol
Get Payment Inilialization DataCheck Payment Possibility
Start Payment Consumer
Start Payment Payment HandlerContinue Process.
Inquire Process State
Change Process State
Check Payment Receipt
Inquire:Authentication Challenge消费者
支付处理方
客服中心
YD/T 1322.2-2004
API功能
Authenticate
Check Authentication ResponseResume Payment Consumer
Resume Payment Payment HandlerExpand Payment Receipt
Inquire Payment Log
Payment Instrument Inquiry
Inguire Pending Payment
Start Payment Inquiry
Inquire Payment Status
Manage Payment Software
消费者
表2（续）
支付处理方
客服中心
下节概括了API调用的相互关系和依赖性，它们提供了对可选过程的描述信息，以及描述了通用IOTP应用内核和特定支付模块之间的通信和同步。认证文档交换（AuthenticationDocumentationExchange）5.1
本节将描述如何使用本文档中的函数联合处理认证。被认证方
Authenticate
(Challenge)
Authenticate Response
(Response）
IOTP交易块
认证请求[Auth/TPO]
认证响应[Auth]
认证状态
图2认证文档交换
1）认证方过程（AuthenticatorProcess）认证方
Inquire Authentication ChallengeInquire Authentication Challenge Response(Challenge)
Check Authentication Response(Challenge,Response )
Check Authentication Response ResponseGet Payment Initialization DataGet Payment Initialization Data ResponseIOTP支付桥询问认证盘问值（InquireAuthenticationChallenge），该值被封装在认证请求块中，中
标准授搜网DAT
2）被认证方过程（AuthenticateeProcess）YD/T 1322.2-2004
IOTP应用内核查看IOTP交易类型是否能够实际支持认证过程。如果提供了认证数据构件，那么查看它的认证方式是否是以“Pay”打头。如果是，就把认证方式和盘问值转发给激活的IOTP支付桥（认证Authenticate），认证请求块用没有任何内容的元件来请求被认证方的组织数据。如果失败，可能会重试，或者挂起或取消整个交易。
3）认证方过程（Authenticator Process）IOTP应用内核查看已有的认证响应块。如果产生了一一个认证盘问块，则该块必须包含一个传递给认证响应构件进行验证（Check Authentication Response）的认证响应块。否则，查看被认证方的组织构件。为了继续下面的交易，必须能够通过该验证。任何遭到拒绝的认证都通过错误代码“ElContIllegal”通知被认证方。5.2品牌编辑（Brand Compilation)图3是本标准中的函数如何结合在一起使用的一个例子。该例子可以让商家编辑品牌列表构件，产生支付构件以及根据支付策略特定打包内容调整订购构件。消费者
消费者根据工作和产生品牌选项以及随机产生认证响应来选择
品牌/流通
IOTP交易块
品牌列表【提出】
品牌选择
提议回应
图3品牌编辑消息流
Find Accepted Paynent Brand
Find Accepted Payment Brand Response(Payment Brands)
Find Accepted Payment Protocol.(for each Payment Brand)
Find Accepted Payment Protocol Response(Payment Protocals)
Get Payment Initialization DataGet Payment Initialization Data ResponseGet Payment Initialization DalaGet Payment Initialization Data Respo1）商家的商业服务器用它自的机制控制购物会话，直到消费者查验购物车，显示出打算支付的意图，打算购物包括任何对商家交易角色站点的非IOTP的访问，为的是协商IOTP定单的订购构件的内容。通过激活商家的IOTP件应用，以后的处理转换到基于IOTP的方式。2）IOTP应用内核询问IOTP级的交易参数（消费者的购物标志，支付方向，原货币数，折扣率，商家和配送处理方的网络位置，非支付处理方的组织数据，初始定单信息，…）。3）OTP应用内核向已注册的IOTP桥询问可接受的支付品牌（Find Accepted PaymentBrand）。响应提供品牌列表元件的所有属性值。IOTP应用内核可能有选择地把所返回地支付品牌与商家的偏好进行匹配。
如果IOTP支付桥发信号表示需要特定的错误代码，那么IOTP应用内核必须提供所有的钱包标志。9
标注授授网Aw.bzosc.ccn各光标注行业资料免费下载
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。