Network Working Group Y. Kawatsura
Request for Comments: 3538 Hitachi
Category: Informational June 2003
Network Working Group Y. Kawatsura
Request for Comments: 3538 Hitachi
Category: Informational June 2003
Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)
1.0版互联网开放交易协议（IOTP）的安全电子交易（SET）补充
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes detailed Input/Output parameters for the Internet Open Trading Protocol (IOTP) Payment Application Programming Interface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP.
本文档描述了互联网开放交易协议（IOTP）支付应用程序编程接口（API）的详细输入/输出参数。它还描述了支付桥中使用SET（SET安全电子交易）作为IOTP版本1.0中的支付协议的程序。
Table of Contents
目录
1. Introduction....................................................3
1.1 Objectives of this Document.................................3
1.2 Scope of this specification.................................3
1.2.1 The version of IOTP specification.....................3
1.2.2 The version of SET specification......................4
1.2.3 The version of IOTP Architecture document.............4
1.3 Audience....................................................4
1.4 Notation....................................................4
1.5 Terminology.................................................4
2. Requirements & Development Policy...............................4
3. Business Models.................................................5
3.1 Entity models between SET and IOTP..........................5
3.2 Role of Participants........................................5
3.3 Scope of Transaction Types..................................6
3.4 Types of transaction not in scope...........................6
4. Architecture of SET/IOTP........................................7
5. Trading Types of SET/IOTP.......................................7
5.1 Baseline Purchase...........................................7
5.2 Cash Advances...............................................8
5.3 Status Inquiry .............................................8
1. Introduction....................................................3
1.1 Objectives of this Document.................................3
1.2 Scope of this specification.................................3
1.2.1 The version of IOTP specification.....................3
1.2.2 The version of SET specification......................4
1.2.3 The version of IOTP Architecture document.............4
1.3 Audience....................................................4
1.4 Notation....................................................4
1.5 Terminology.................................................4
2. Requirements & Development Policy...............................4
3. Business Models.................................................5
3.1 Entity models between SET and IOTP..........................5
3.2 Role of Participants........................................5
3.3 Scope of Transaction Types..................................6
3.4 Types of transaction not in scope...........................6
4. Architecture of SET/IOTP........................................7
5. Trading Types of SET/IOTP.......................................7
5.1 Baseline Purchase...........................................7
5.2 Cash Advances...............................................8
5.3 Status Inquiry .............................................8
6. General Flow of SET/IOTP........................................8
6.1 Baseline Purchase...........................................9
6.1.1 Brand Independent Baseline Purchase...................9
6.1.2 Brand Dependent Baseline Purchase....................13
6.2 Cash Advances..............................................14
6.3 Status Inquiry.............................................15
7. IOTP Payment APIs..............................................16
7.1 Brand Compilation Related API Calls........................16
7.1.1 Find Accepted Payment Brand..........................16
7.1.2 Find Accepted Payment Protocol.......................17
7.1.3 Get Payment Initialization Data......................18
7.1.4 Inquire Authentication Challenge.....................19
7.1.5 Authenticate.........................................19
7.1.6 Check Authentication Response........................19
7.2 Brand Selection Related API Calls..........................20
7.2.1 Find Payment Instrument..............................20
7.2.2 Check Payment Possibility............................21
7.3 Payment Transaction Related API Calls......................22
7.3.1 Start Payment Consumer...............................22
7.3.2 Start Payment Payment Handler........................23
7.3.3 Resume Payment Consumer..............................24
7.3.4 Continue Process.....................................25
7.3.5. Change Process State................................26
7.4 General Inquiry API Calls..................................26
7.4.1 Payment Instrument Inquiry...........................26
7.4.2 Inquire Pending Payment..............................26
7.4.3 Remove Payment Log...................................27
7.5 Payment Related Inquiry API Calls..........................27
7.5.1 Check Payment Receipt................................27
7.5.2 Expand Payment Receipt...............................27
7.5.3 Inquire Process State................................28
7.5.4 Start Payment Inquiry................................29
7.5.5 Inquire Payment Status...............................30
8. SET dependent Process..........................................30
8.1 Relationships between them for IOTP Purchase/Cash Advances.30
8.2 Definition of Identifiers..................................31
8.2.1 Definition of BrandId................................31
8.2.2 Definition of ProtocolBrandId........................31
8.2.3 Definition of ProtocolId.............................33
8.2.4 Relationship between Ids.............................33
8.3 Process prior to Payment...................................34
8.3.1 FindAcceptedPaymentProtocol Function.................34
8.3.2 FindPaymentInstrument Function.......................35
8.3.3 GetPaymentInitializationData Function................36
8.4 Process of Payment.........................................37
8.4.1 StartPaymentConsumer Function........................37
8.4.2 StartPaymentPaymentHandler Function..................41
8.4.3 ContinueProcess Function (Consumer Side).............42
6. General Flow of SET/IOTP........................................8
6.1 Baseline Purchase...........................................9
6.1.1 Brand Independent Baseline Purchase...................9
6.1.2 Brand Dependent Baseline Purchase....................13
6.2 Cash Advances..............................................14
6.3 Status Inquiry.............................................15
7. IOTP Payment APIs..............................................16
7.1 Brand Compilation Related API Calls........................16
7.1.1 Find Accepted Payment Brand..........................16
7.1.2 Find Accepted Payment Protocol.......................17
7.1.3 Get Payment Initialization Data......................18
7.1.4 Inquire Authentication Challenge.....................19
7.1.5 Authenticate.........................................19
7.1.6 Check Authentication Response........................19
7.2 Brand Selection Related API Calls..........................20
7.2.1 Find Payment Instrument..............................20
7.2.2 Check Payment Possibility............................21
7.3 Payment Transaction Related API Calls......................22
7.3.1 Start Payment Consumer...............................22
7.3.2 Start Payment Payment Handler........................23
7.3.3 Resume Payment Consumer..............................24
7.3.4 Continue Process.....................................25
7.3.5. Change Process State................................26
7.4 General Inquiry API Calls..................................26
7.4.1 Payment Instrument Inquiry...........................26
7.4.2 Inquire Pending Payment..............................26
7.4.3 Remove Payment Log...................................27
7.5 Payment Related Inquiry API Calls..........................27
7.5.1 Check Payment Receipt................................27
7.5.2 Expand Payment Receipt...............................27
7.5.3 Inquire Process State................................28
7.5.4 Start Payment Inquiry................................29
7.5.5 Inquire Payment Status...............................30
8. SET dependent Process..........................................30
8.1 Relationships between them for IOTP Purchase/Cash Advances.30
8.2 Definition of Identifiers..................................31
8.2.1 Definition of BrandId................................31
8.2.2 Definition of ProtocolBrandId........................31
8.2.3 Definition of ProtocolId.............................33
8.2.4 Relationship between Ids.............................33
8.3 Process prior to Payment...................................34
8.3.1 FindAcceptedPaymentProtocol Function.................34
8.3.2 FindPaymentInstrument Function.......................35
8.3.3 GetPaymentInitializationData Function................36
8.4 Process of Payment.........................................37
8.4.1 StartPaymentConsumer Function........................37
8.4.2 StartPaymentPaymentHandler Function..................41
8.4.3 ContinueProcess Function (Consumer Side).............42
8.4.4 ContinueProcess Function (Payment Handler Side)......43
8.4.5 InquireProcessState Function.........................45
8.5 Payment Receipt............................................45
8.5.1 CheckPayReceipt Function.............................45
8.5.2 ExpandPayReceipt Function............................45
8.6 Status Inquiry.............................................46
8.7 Resume Process.............................................47
8.8 SET Scheme Specific Authentication on IOTP.................47
8.9 SET Bridge ProcessState....................................48
8.9.1 SET Bridge ProcessState of Consumer..................48
8.9.2 SET Bridge ProcessState of Payment Handler...........49
8.10 Relationship between Pay Step and Deliv Step on SET/IOTP..49
8.11 Completion Code...........................................50
8.12 PercentComplete...........................................50
8.13 Severity..................................................51
9. Error Handling.................................................51
9.1 Types of Errors............................................51
9.2 IOTP Level Error (OAC Error)...............................52
9.3 IOTP Level Error (SET Bridge Error)........................52
9.4 SET Level Error (SET Technical Error)......................52
9.4.1 SET Initiation Error.................................52
9.4.2 SET Transaction Error................................53
9.5 SET Level Error (SET Business Error).......................53
10. Security Considerations.......................................54
11. References....................................................54
12. IANA Considerations...........................................55
13. Acknowledgement...............................................55
14. Author's Address..............................................55
15. Full Copyright Statement......................................56
8.4.4 ContinueProcess Function (Payment Handler Side)......43
8.4.5 InquireProcessState Function.........................45
8.5 Payment Receipt............................................45
8.5.1 CheckPayReceipt Function.............................45
8.5.2 ExpandPayReceipt Function............................45
8.6 Status Inquiry.............................................46
8.7 Resume Process.............................................47
8.8 SET Scheme Specific Authentication on IOTP.................47
8.9 SET Bridge ProcessState....................................48
8.9.1 SET Bridge ProcessState of Consumer..................48
8.9.2 SET Bridge ProcessState of Payment Handler...........49
8.10 Relationship between Pay Step and Deliv Step on SET/IOTP..49
8.11 Completion Code...........................................50
8.12 PercentComplete...........................................50
8.13 Severity..................................................51
9. Error Handling.................................................51
9.1 Types of Errors............................................51
9.2 IOTP Level Error (OAC Error)...............................52
9.3 IOTP Level Error (SET Bridge Error)........................52
9.4 SET Level Error (SET Technical Error)......................52
9.4.1 SET Initiation Error.................................52
9.4.2 SET Transaction Error................................53
9.5 SET Level Error (SET Business Error).......................53
10. Security Considerations.......................................54
11. References....................................................54
12. IANA Considerations...........................................55
13. Acknowledgement...............................................55
14. Author's Address..............................................55
15. Full Copyright Statement......................................56
This chapter describes the outline of this document.
本章介绍了本文件的概要。
This document describes how SET (SET Secure Electronic Transaction) works within the IOTP (Internet Open Trading Protocol).
本文件描述SET（SET安全电子交易）如何在IOTP（互联网开放交易协议）内工作。
This document is written based on IOTP Version 1.0 [RFC 2801].
本文件基于IOTP 1.0版[RFC 2801]编写。
This document is written based on SET Version 1.0 [SET].
本文件基于SET版本1.0[SET]编写。
This document is written based on IOTP Payment API document Version 1.0 [IOTP Payment API].
本文件基于IOTP支付API文件1.0版[IOTP支付API]编写。
This document is indented for readers who are familiar with the following documents:
本文档为熟悉以下文档的读者缩进：
1) IOTP Specification Version 1.0 [RFC 2801] 2) SET Specification, in particular Book 2:Programmer's Guide and Book3:Formal Protocol Definition, 3) External Interface Guide to SET Secure Electronic Transaction 4) Internet Open Trading Supplement: Architecture and Payment API [IOTP API]
1) IOTP规范1.0版[RFC 2801]2）SET规范，特别是第2册：程序员指南和第3册：正式协议定义，3）设置安全电子交易的外部接口指南4）互联网开放交易补充：架构和支付API[IOTP API]
SET Messages and Elements are described with the prefix "SET".
SET消息和元素以前缀“SET”描述。
Examples: SET PRes SET OD SET SaleDetail
示例：集合压力集合OD集合细节
This document uses the following terms:
本文件使用以下术语：
SET/IOTP The specification described in this document. SET related message Both SET Messages and SET Initiation Messages
设置/IOTP本文件中描述的规范。设置相关消息设置消息和设置启动消息
This chapter describes the requirements and development policies of SET/IOTP.
本章描述了SET/IOTP的要求和开发策略。
The requirements of SET/IOTP are as follows:
SET/IOTP的要求如下：
o To be based on SET specifications. Interoperability at the payment level must be maintained.
o 以设定的规格为基础。必须保持支付层面的互操作性。
o To not enforce modifications which are specific to SET/IOTP. General features of IOTP should not be tampered with to cater to a particular payment method.
o 不强制执行特定于SET/IOTP的修改。IOTP的一般功能不应被篡改，以适应特定的支付方式。
o To keep integrity between IOTP and SET. Inconstancy must not be raised between IOTP and SET elements when they have the same meaning.
o 保持IOTP和SET之间的完整性。当IOTP和SET元素具有相同含义时，不得在它们之间引发不一致性。
The development policy of SET/IOTP is as follows:
SET/IOTP的发展政策如下：
o To minimize the number of message round trips
o 尽量减少邮件往返次数
o To minimize the length of messages
o 最小化消息长度的步骤
This chapter describes the difference in entity models between SET and IOTP, the definitions of Trading Roles in SET/IOTP, and the scope of SET/IOTP.
本章描述了SET和IOTP之间实体模型的差异、SET/IOTP中交易角色的定义以及SET/IOTP的范围。
The following table describes how SET and IOTP entities correspond to each other.
下表描述了SET和IOTP实体如何相互对应。
| IOTP Entity SET Entity |
| ------------------------------------------------ |
| Consumer <---> Card Holder |
| Merchant <---> Merchant (Initiation) |
| Payment Handler <---> Merchant (Payment) |
| Delivery Handler<---> None |
| None <---> Acquirer |
| IOTP Entity SET Entity |
| ------------------------------------------------ |
| Consumer <---> Card Holder |
| Merchant <---> Merchant (Initiation) |
| Payment Handler <---> Merchant (Payment) |
| Delivery Handler<---> None |
| None <---> Acquirer |
Figure 1 Entity Models between SET and IOTP
图1 SET和IOTP之间的实体模型
The following table describes the trading roles in SET/IOTP.
下表描述了SET/IOTP中的交易角色。
Trading Roles Role
-------------------------------------------------------------
Consumer An Individual who purchases goods and/or
services, and pays for the value received
by choosing a SET Transaction. This
individual corresponds with the
CardHolder in SET.
Trading Roles Role
-------------------------------------------------------------
Consumer An Individual who purchases goods and/or
services, and pays for the value received
by choosing a SET Transaction. This
individual corresponds with the
CardHolder in SET.
Merchant An organization that provides goods and/or services for purchase, accepts payment methods, delivers invoices and triggers payment processes.
商户为采购提供商品和/或服务、接受付款方式、交付发票并触发付款流程的组织。
Payment Handler An organization that processes negotiations on payments including SET payment transactions.
付款处理人处理付款谈判（包括设置付款交易）的组织。
Delivery Handler An Organization that ships digital or physical goods to the Consumer.
送货员向消费者运送数字或实物商品的组织。
Customer Care The same as in [RFC 2801]. Provider
客户服务与[RFC 2801]中的相同。供应商
Merchant Care The same as in [RFC 2801]. Provider
商户服务与[RFC 2801]中的相同。供应商
The types of IOTP transactions that are supported in this document are as follows:
本文件支持的IOTP交易类型如下：
o Brand Independent Baseline Purchase when SET is used for payment
o 当SET用于付款时，品牌独立基线购买
o Brand Dependent Baseline Purchase when SET is used for payment
o 当SET用于付款时，品牌相关基线购买
o Cash Advances (Brand Independent and Brand Dependent case)
o 现金预付款（品牌独立和品牌依赖案例）
o Status Inquiry on SET payments
o 定期付款情况查询
The types of transactions that are NOT covered in this document are as follows:
本文件未涵盖的交易类型如下：
o Credit Reversal Process
o 信用撤销过程
o Customer Care Service with Consumer Related SET Certificate Registration
o 客户服务与消费者相关的SET证书注册
o Customer Care Service with Consumer Related SET Certificate Registration Inquiry
o 客户服务与消费者相关设置证书注册查询
SET/IOTP Architecture is as follows:
SET/IOTP架构如下：
IOTP client (Consumer) <---------------> IOTP server (Merchant)
^ Internet ^
| IOTP Payment | IOTP Payment
| API | API
v v
IOTP/Payment Bridge IOTP/Payment Bridge
^ ^
| Existing Payment APIs, e.g., |
| SET, Mondex, etc. |
v v
Existing Payment Software Existing Payment Software
IOTP client (Consumer) <---------------> IOTP server (Merchant)
^ Internet ^
| IOTP Payment | IOTP Payment
| API | API
v v
IOTP/Payment Bridge IOTP/Payment Bridge
^ ^
| Existing Payment APIs, e.g., |
| SET, Mondex, etc. |
v v
Existing Payment Software Existing Payment Software
Figure 2 SET/IOTP Architecture
图2 SET/IOTP体系结构
IOTP Application Core (OAC): Software that processes IOTP messages. IOTP Payment Bridge (OPB): Interface between OAC and Existing Payment Software. SET Bridge is also an interface between OAC and SET Core.
IOTP应用核心（OAC）：处理IOTP消息的软件。IOTP支付桥（OPB）：OAC和现有支付软件之间的接口。SET桥接器也是OAC和SET核心之间的接口。
Existing Payment Software (EPS): Existing Software that processes Payments. The SET Core is software that supports mechanisms in SET specification from Book1 to Book3. EPS does NOT necessarily have to implement the SET Initiation Processor, which is specified in SET EIG. SET Related Module Both SET related OPB and EPS.
现有付款软件（EPS）：处理付款的现有软件。SET-Core是一种软件，支持从Book1到Book3的SET规范中的机制。EPS不一定必须实现SET EIG中规定的SET启动处理器。设置相关模块设置相关OPB和EPS。
This chapter describes the outline of SET/IOTP trading types.
本章介绍SET/IOTP交易类型的概述。
Three steps will take place in a Baseline Purchase in the following order:
基线采购将按以下顺序进行三个步骤：
(1) Offer Step
(1) 提供步骤
Consumer selects goods/services over the Internet, for instance on the web, and then chooses the payment method (SET is selected), the SET brand, the payment currency, and then confirms the invoice.
消费者通过互联网（例如在web上）选择商品/服务，然后选择付款方式（选择SET）、SET品牌、付款货币，然后确认发票。
There are two Offer Process types, Brand Independent and Brand Dependent.
有两种报价流程类型，品牌独立和品牌依赖。
(1-a) Brand Independent Purchase
（1-a）品牌自主购买
In a Brand Independent Purchase, the Merchant sends the TPO Block and Offer Response Block simultaneously after the consumer's purchase decision. The Brand Independent Purchase has the merit of eliminating one round of messages compared with the Brand Dependent Purchase because the contents of the Offer Response Block (for example, the description on the invoice) do not change based on the selected brand.
在品牌独立购买中，商户在消费者做出购买决定后同时发送TPO块和报价响应块。与品牌相关购买相比，品牌独立购买具有消除一轮消息的优点，因为报价响应块的内容（例如，发票上的描述）不会根据所选品牌而改变。
(1-b) Brand Dependent Purchase
（1-b）品牌相关购买
Brand Dependent Purchase is used when the contents of the Offer Response Block are dependent on the selected Payment Brand. With this method, the currency selection and discounts based on payment method can be implemented.
当报价响应块的内容取决于所选支付品牌时，使用品牌相关购买。通过该方法，可以实现基于付款方式的币种选择和折扣。
(2) Payment Step
(2) 付款步骤
The Consumer confirms the order and then pays for the order with a SET Transaction. The SET Transaction messages will be encapsulated in IOTP Messages.
消费者确认订单，然后通过设置的交易支付订单。设置的事务消息将封装在IOTP消息中。
(3) Delivery Step
(3) 交付步骤
After completing the Payment, the Consumer receives the goods/services via either on-line or physical delivery.
完成付款后，消费者通过在线或实物交付方式接收商品/服务。
Cash Advances can be made via a Value Exchange Transaction in IOTP. A first Payment by SET and a second Payment by some other payment mechanism is supported in Baseline IOTP. The Cash Advance has two types - Brand Independent and Brand Dependent Cases.
现金预付款可通过IOTP中的价值交换交易进行。基线IOTP支持通过SET进行第一次支付，并通过其他一些支付机制进行第二次支付。现金预付款有两种类型-品牌独立和品牌依赖案例。
A Consumer can send a SET Payment Inquiry in IOTP. The SET Message is encapsulated in an IOTP Message.
消费者可以在IOTP中发送一组付款查询。SET消息封装在IOTP消息中。
This chapter illustrates the general SET/IOTP message flows.
本章说明了常规SET/IOTP消息流。
Baseline purchases consist of two types, Brand Independent Purchase and Brand Dependent Purchase. Each type is illustrated in the charts below.
基线购买包括两种类型，品牌独立购买和品牌依赖购买。每种类型如下图所示。
The general flow of a Brand Independent Purchase is as follows:
品牌独立购买的一般流程如下：
(1) Consumer Side (Before PayRequest Message)
(1) 消费者端（付款请求消息之前）
SET Core SET Bridge OAC
| | | TPO & OfferResp message
| | |<------------------- From
| |<------------| Merchant
| | FindPayment |
| | Instrument|
| |------------>|
| | Response |
| |<------------|
| | CheckPayment|
| | Possibility|
| |------------>|
| | Response |
| |<------------|
|<------------| StartPayment|
|------------>| Consumer|
| |------------>| PayRequest Message
| | Response |-------------------> To Payment
(SET Init Resp/ Handler
SET PInitReq)
SET Core SET Bridge OAC
| | | TPO & OfferResp message
| | |<------------------- From
| |<------------| Merchant
| | FindPayment |
| | Instrument|
| |------------>|
| | Response |
| |<------------|
| | CheckPayment|
| | Possibility|
| |------------>|
| | Response |
| |<------------|
|<------------| StartPayment|
|------------>| Consumer|
| |------------>| PayRequest Message
| | Response |-------------------> To Payment
(SET Init Resp/ Handler
SET PInitReq)
Figure 3 Consumer Side for Brand Independent (1)
图3独立品牌的消费者端（1）
(2) Consumer Side (After PayRequest Message)
(2) 消费者端（在PayRequest消息之后）
SET Core SET Bridge OAC
| | | Pay Exch Message
| | |<------------------- From
| SET PInitRes|<------------| (SET PInitRes) P.H.
|<------------| Continue |
|------------>| Process |
| SET PReq |------------>| Pay Exch Message
| | Response |-------------------> To P.H.
| | | (SET PReq)
| | | Pay Exch Message
| | |<------------------ From P.H.
| SET PRes |<------------| (SET PRes)
|<------------| Continue |
|------------>| Process |
| |------------>|
| |Response[END]|
| |<------------|
| | CheckPayment|
| | Receipt |
| |------------>|
| | Response |
| |<------------|
| |ExpandPayment|
| | Receipt |
| |------------>|
| | Response |
| |<------------|
| |ChangeProcess|
| | State |
| |------------>|
| | Response |
SET Core SET Bridge OAC
| | | Pay Exch Message
| | |<------------------- From
| SET PInitRes|<------------| (SET PInitRes) P.H.
|<------------| Continue |
|------------>| Process |
| SET PReq |------------>| Pay Exch Message
| | Response |-------------------> To P.H.
| | | (SET PReq)
| | | Pay Exch Message
| | |<------------------ From P.H.
| SET PRes |<------------| (SET PRes)
|<------------| Continue |
|------------>| Process |
| |------------>|
| |Response[END]|
| |<------------|
| | CheckPayment|
| | Receipt |
| |------------>|
| | Response |
| |<------------|
| |ExpandPayment|
| | Receipt |
| |------------>|
| | Response |
| |<------------|
| |ChangeProcess|
| | State |
| |------------>|
| | Response |
Figure 4 Consumer Side flow for Brand Independent (2)
图4独立品牌的消费者侧流程（2）
(3) Merchant Side
(3) 商户方
OAC SET Bridge
|--------------->|
|FindAccepted |
| PaymentBrand |
|<---------------|
| Response |
|--------------->|
|FindAccepted |
| PaymentProtocol|
|<---------------|
| Response |
|--------------->|
|GetPaymentInit- |
| lizationData |
TPO & Offer Resp Msg. |<---------------|
<------------------------| Response |
To Consumer
OAC SET Bridge
|--------------->|
|FindAccepted |
| PaymentBrand |
|<---------------|
| Response |
|--------------->|
|FindAccepted |
| PaymentProtocol|
|<---------------|
| Response |
|--------------->|
|GetPaymentInit- |
| lizationData |
TPO & Offer Resp Msg. |<---------------|
<------------------------| Response |
To Consumer
Figure 5 Merchant Side flow for Brand Independent
图5独立品牌的商户端流程
(4) Payment Handler Side.
(4) 付款处理方。
OAC SET Bridge SET Core
PayRequest Message | | |
From ---------------------->| | |
Consumer (SET Init Res/ |--------------->| |
SET PInitReq) |StartPayment |------------>|
| PaymentHandler |<------------|
PayExch Message |<---------------| |
To <----------------------| Response | |
Consumer (SET Init Req/ . . .
SET PInitRes) . . .
PayExch Mssage | | |
---------------------->| | |
From Consumer (SET PReq) |--------------->| SET PReq |
| Continue |------------>|
| Process |<------------|
|<---------------| SET PRes |
| Response | |
|--------------->| |
| Inquire | |
| ProcessState | |
|<---------------| |
| Response | |
|--------------->| |
| ChangeProcess | |
| State | |
PayResponse Message |<---------------| |
<------------------------| Response | |
To Consumer (SET PRes)
OAC SET Bridge SET Core
PayRequest Message | | |
From ---------------------->| | |
Consumer (SET Init Res/ |--------------->| |
SET PInitReq) |StartPayment |------------>|
| PaymentHandler |<------------|
PayExch Message |<---------------| |
To <----------------------| Response | |
Consumer (SET Init Req/ . . .
SET PInitRes) . . .
PayExch Mssage | | |
---------------------->| | |
From Consumer (SET PReq) |--------------->| SET PReq |
| Continue |------------>|
| Process |<------------|
|<---------------| SET PRes |
| Response | |
|--------------->| |
| Inquire | |
| ProcessState | |
|<---------------| |
| Response | |
|--------------->| |
| ChangeProcess | |
| State | |
PayResponse Message |<---------------| |
<------------------------| Response | |
To Consumer (SET PRes)
Figure 6 Payment Handler side flow for Brand Independent
图6独立品牌的支付处理程序侧流程
The general flow of a Brand Dependent Purchase is as follows:
品牌相关购买的一般流程如下所示：
(1) Consumer Side (Before PayRequest Message)
(1) 消费者端（付款请求消息之前）
SET Core SET Bridge OAC
| | | TPO message
| | |<------------------- From
| |<------------| Merchant
| | FindPayment |
| | Instrument|
| |------------>|
| | Response |
| |<------------|
| | CheckPayment|
| | Possibility|
| |------------>| TPO Selection Msg.
| | Response |-------------------> To Merchant
| | |<------------------ From Merchant
| |<------------| Offer Response Msg.
|<------------| StartPayment|
|------------>| Consumer|
| |------------>| PayRequest Message
| | Response |-------------------> To Payment
(SET Init Resp/ Handler
SET PInitReq)
SET Core SET Bridge OAC
| | | TPO message
| | |<------------------- From
| |<------------| Merchant
| | FindPayment |
| | Instrument|
| |------------>|
| | Response |
| |<------------|
| | CheckPayment|
| | Possibility|
| |------------>| TPO Selection Msg.
| | Response |-------------------> To Merchant
| | |<------------------ From Merchant
| |<------------| Offer Response Msg.
|<------------| StartPayment|
|------------>| Consumer|
| |------------>| PayRequest Message
| | Response |-------------------> To Payment
(SET Init Resp/ Handler
SET PInitReq)
Figure 7 Consumer Side flow for Brand Dependent (1)
图7品牌相关的消费者侧流程（1）
(2) Consumer Side (After PayRequest Message)
(2) 消费者端（在PayRequest消息之后）
This flow is the same as Brand Independent.
此流程与品牌独立相同。
(3) Merchant Side
(3) 商户方
OAC SET Bridge
|--------------->|
|FindAccepted |
| PaymentBrand |
|<---------------|
| Response |
|--------------->|
|FindAccepted |
| PaymentProtocol|
TPO Message |<---------------|
<------------------------| Response |
To Consumer | |
TPO Selection Message | |
------------------------>| |
From Consumer |--------------->|
|GetPaymentInit- |
| lizationData |
Offer Response Message |<---------------|
<------------------------| Response |
To Consumer
OAC SET Bridge
|--------------->|
|FindAccepted |
| PaymentBrand |
|<---------------|
| Response |
|--------------->|
|FindAccepted |
| PaymentProtocol|
TPO Message |<---------------|
<------------------------| Response |
To Consumer | |
TPO Selection Message | |
------------------------>| |
From Consumer |--------------->|
|GetPaymentInit- |
| lizationData |
Offer Response Message |<---------------|
<------------------------| Response |
To Consumer
Figure 8 Merchant Side flow for Brand Dependent (1)
图8品牌相关的商户端流程（1）
(4) Payment Handler Side
(4) 付款处理方
This flow is the same as Brand Independent.
此流程与品牌独立相同。
IOTP Cash Advances processes can be made with a credit card using an IOTP Value Exchange Transaction. In Cash Advances a first Payment by a SET Transaction, and a second Payment by some other payment mechanism, is supported in Baseline IOTP. The general flow is omitted.
IOTP现金预付款流程可以通过使用IOTP价值交换交易的信用卡进行。在现金预付款中，基线IOTP支持通过集合交易进行第一次支付，并通过其他一些支付机制进行第二次支付。省略了一般流程。
The general flow of a Status Inquiry is as follows:
状态查询的一般流程如下所示：
(1) Consumer Side
(1) 消费者方面
SET Core SET Bridge OAC
| | |
| | |
| |<------------|
|<------------| StartPayment|
|------------>| Inquiry|
| SET InqReq |------------>| Inquiry Request
| | Response |-------------------> To P.H.
| | | (SET InqReq)
| | |
| | | Inquiry Response
| | |<------------------- From P.H.
| | | (SET InqRes)
| SET Inq Res |<------------|
|<------------| Continue |
|------------>| Process|
| SET InqReq |------------>|
| | [End] |
| |ChangeProcess|
| | State|
| |<------------|
|<------------|
SET Core SET Bridge OAC
| | |
| | |
| |<------------|
|<------------| StartPayment|
|------------>| Inquiry|
| SET InqReq |------------>| Inquiry Request
| | Response |-------------------> To P.H.
| | | (SET InqReq)
| | |
| | | Inquiry Response
| | |<------------------- From P.H.
| | | (SET InqRes)
| SET Inq Res |<------------|
|<------------| Continue |
|------------>| Process|
| SET InqReq |------------>|
| | [End] |
| |ChangeProcess|
| | State|
| |<------------|
|<------------|
Figure 9 Consumer Side flow for Status Inquiry
图9状态查询的用户端流程
(2) Payment Handler Side
(2) 付款处理方
OAC SET Bridge SET Core
InquiryReq message | | |
From ------------------------>| | |
Consumer (SET InqReq) |------------->| |
|InquirePayment|------------>|
| Status| SET InqReq |
| |<------------|
| | SET InqRes |
InquiryResp message |<-------------| |
To <------------------------| Response | |
Consumer (SET InqRes) |
OAC SET Bridge SET Core
InquiryReq message | | |
From ------------------------>| | |
Consumer (SET InqReq) |------------->| |
|InquirePayment|------------>|
| Status| SET InqReq |
| |<------------|
| | SET InqRes |
InquiryResp message |<-------------| |
To <------------------------| Response | |
Consumer (SET InqRes) |
Figure 10 Payment Handler Side flow for Status Inquiry
图10状态查询的支付处理程序端流程
This section provides a summary of SET/IOTP interactions with API calls as in [IOTP Payment API].
本节总结了SET/IOTP与[IOTP支付API]中的API调用的交互。
The description of parameters hereafter are written as follows:
下文对参数的说明如下：
Parameter name : Mandatory (M) or Optional (O) : Description
参数名称：强制（M）或可选（O）：说明
For more details on the IOTP Payment APIs, see [IOTP Payment API]. "-" in the Description is the same as description in the [IOTP Payment API].
有关IOTP支付API的更多详细信息，请参阅[IOTP支付API]。描述中的“-”与[IOTP支付API]中的描述相同。
Notice: Status is the status of SET/IOTP. Though some Fields are specified "#IMPLIED" in [IOTP Payment API], if the fields must be used in SET/IOTP, this document specifies the status as Mandatory, (M).
注意：状态是SET/IOTP的状态。尽管某些字段在[IOTP支付API]中指定为“#隐含”，但如果这些字段必须在SET/IOTP中使用，则本文档将其状态指定为强制性（M）。
Receive the payment scheme specific packaged data to generate Brand Component. In this version of SET/IOTP, This API must be called before Find Accepted Payment Protocol function.
接收特定于支付方案的打包数据，以生成品牌组件。在此版本的SET/IOTP中，必须在查找接受的支付协议函数之前调用此API。
Input Parameters
----------------
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
MerchantPayId : M : -
MerchantOrgId : M : -
WalletId : O : -
MerchantData : O : The details are not specified in
this document.
Output Parameters
-----------------
BrandItem : M : See NOTE below.
Input Parameters
----------------
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
MerchantPayId : M : -
MerchantOrgId : M : -
WalletId : O : -
MerchantData : O : The details are not specified in
this document.
Output Parameters
-----------------
BrandItem : M : See NOTE below.
NOTE: Parameters of BrandItem
-----------------------------
BrandId : M : This is defined in the section 8.2.1.
xml:lang : M : -
BrandName : M : Brand Name, such as "MasterCard".
BrandLogoNetLocn : M : -
BrandNarrative : O : This is not specified in this document.
BrandPackaged : O : This is not used in the SET/IOTP.
Content
NOTE: Parameters of BrandItem
-----------------------------
BrandId : M : This is defined in the section 8.2.1.
xml:lang : M : -
BrandName : M : Brand Name, such as "MasterCard".
BrandLogoNetLocn : M : -
BrandNarrative : O : This is not specified in this document.
BrandPackaged : O : This is not used in the SET/IOTP.
Content
Receive the payment scheme specific packaged data to generate the PayProtocol Component.
接收特定于支付方案的打包数据以生成PayProtocol组件。
Input Parameters
----------------
BrandId : M : This is defined in the section 8.2.1.
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
MerhcantPayId : M : -
MercahntOrgId : M : -
WalletId : O : -
BrandPackaged : O : This is not used in the SET/IOTP.
Content
MerchantData : O : This is not specified in the SET/IOTP.
Input Parameters
----------------
BrandId : M : This is defined in the section 8.2.1.
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
MerhcantPayId : M : -
MercahntOrgId : M : -
WalletId : O : -
BrandPackaged : O : This is not used in the SET/IOTP.
Content
MerchantData : O : This is not specified in the SET/IOTP.
Output Parameters
-----------------
ProtocolItem : M : See NOTE below.
BrandItem : M : -
Output Parameters
-----------------
ProtocolItem : M : See NOTE below.
BrandItem : M : -
NOTE Parameters of ProtocolItem
-------------------------------
ProtocolId : M : This is set "SETv1.0".
ProtocolBrandId : M : This is set the Payment Protocol Specific
ID corresponding to the BrandId as Input
Parameter and ProtocolId as the
Output Parameter. For the detail,
see 8.2.2.
xml:lang : M : -
ProtocolName : M : This is not specified in this document
but must be included the protocol name
and its version at least.
NOTE Parameters of ProtocolItem
-------------------------------
ProtocolId : M : This is set "SETv1.0".
ProtocolBrandId : M : This is set the Payment Protocol Specific
ID corresponding to the BrandId as Input
Parameter and ProtocolId as the
Output Parameter. For the detail,
see 8.2.2.
xml:lang : M : -
ProtocolName : M : This is not specified in this document
but must be included the protocol name
and its version at least.
PayReqNetLocn : O : The Net Location indicating where a unsecured Payment Request Message should be sent if this protocol choice is used. SecPayReqNetLocn : O : The Net Location indicating where a secured Payment Request Message should be sent if this protocol choice is used. ProtocolAmount : O : This is not used in the SET/IOTP. PackagedContent PayProtocol : M : The XML Packaged Data, which includes PackagedContent the information for the 1st SET Initiation Process. See for the details to section 8.3.1. Brand : M : In this document, BrandId, which is the same as Input Parameter,must be set ONLY. See NOTE below. CurrencyAmount : M : See NOTE below. ProtocolBrand : M : Multiple Components are not arrowed in the current version of SET/IOTP.
PayReqNetLocn:O：净位置，指示如果使用此协议选项，则应在何处发送不安全的支付请求消息。SecPayReqNetLocn:O：净位置，指示如果使用此协议选项，应将安全支付请求消息发送到何处。协议金额：O：这不在SET/IOTP中使用。PackagedContent PayProtocol:M：XML打包数据，其中包括PackagedContent第一套启动过程的信息。详见第8.3.1节。品牌：M：在本文档中，BrandId与输入参数相同，只能设置。见下文注释。货币金额：M：见下面的注释。ProtocolBrand:M：当前版本的SET/IOTP中没有用箭头标出多个组件。
Note Parameters of CurrencyAmount
---------------------------------
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
Note Parameters of CurrencyAmount
---------------------------------
CurrCodeType : M : This should be set "ISO4217-A".
CurrCode : M : -
Amount : M : -
Note Parameters of Brand
------------------------
BrandId : M : -
Note Parameters of Brand
------------------------
BrandId : M : -
This API is used to get the packaged content in Payment Component.
此API用于获取支付组件中的打包内容。
Input Parameters
----------------
BrandId : M : See the details of section 8.2.1.
MerchantPayId : M : -
PayDirection : M : This is set "Debit".
CurrCodeType : M : This is set "ISO5217-A".
CurrCode : M : -
Amount : M : -
OkFrom : M : -
OkTo : M : -
ReceiverOrgId : M : Organization ID which is used to get
TradingRolePackagedContents, which
depend on the organizations for each.
MerchantOrgId : M : -
Input Parameters
----------------
BrandId : M : See the details of section 8.2.1.
MerchantPayId : M : -
PayDirection : M : This is set "Debit".
CurrCodeType : M : This is set "ISO5217-A".
CurrCode : M : -
Amount : M : -
OkFrom : M : -
OkTo : M : -
ReceiverOrgId : M : Organization ID which is used to get
TradingRolePackagedContents, which
depend on the organizations for each.
MerchantOrgId : M : -
ProtocolId : M : This field must be set "SETv1.0".
WalletId : O : -
PassPhrase : O : -
ProtocolBrand : M : -
BrandPackaged : O : This is not used in the current version
Content of SET/IOTP.
ProtocolAmount : O : This is not used in the current version
PackagedContent of SET/IOTP.
PayProtocolPackaged: M : This field is copied from the
Content PayProtocol Component.
OrderPackaged : M : Packaged Data regarding the Order data,
Content which the Merchant's OAC sets.
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfoPackaged current version of SET/IOTP.
Content
BrandSelCurrency : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
ProtocolId : M : This field must be set "SETv1.0".
WalletId : O : -
PassPhrase : O : -
ProtocolBrand : M : -
BrandPackaged : O : This is not used in the current version
Content of SET/IOTP.
ProtocolAmount : O : This is not used in the current version
PackagedContent of SET/IOTP.
PayProtocolPackaged: M : This field is copied from the
Content PayProtocol Component.
OrderPackaged : M : Packaged Data regarding the Order data,
Content which the Merchant's OAC sets.
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfoPackaged current version of SET/IOTP.
Content
BrandSelCurrency : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
Output Parameters
-----------------
OkFrom : M : -
OkTo : M : -
OrderPackaged : M :Changed OrderPackagedContent if
Content it rewrites the order information.
Otherwise, passed the same input
data to OAC.
TradingRole : O : The receiver depended
PackagedContent TradingRolePackagedContent. The Name
Attribute of the packaged contents
must include "Payment:" as the prefix,
for example "Payment:SET-OD". Multiple
TradingRoleData may be returned.
Output Parameters
-----------------
OkFrom : M : -
OkTo : M : -
OrderPackaged : M :Changed OrderPackagedContent if
Content it rewrites the order information.
Otherwise, passed the same input
data to OAC.
TradingRole : O : The receiver depended
PackagedContent TradingRolePackagedContent. The Name
Attribute of the packaged contents
must include "Payment:" as the prefix,
for example "Payment:SET-OD". Multiple
TradingRoleData may be returned.
This is not used in the current version of SET/IOTP.
这在当前版本的SET/IOTP中未使用。
This is not used in the current version of SET/IOTP.
这在当前版本的SET/IOTP中未使用。
This is not used in the current version of SET/IOTP.
这在当前版本的SET/IOTP中未使用。
This API is used to get the Payment Instruments that can be accepted by the Payment Handler on behalf of the Merchant.
此API用于获取支付处理程序可以代表商户接受的支付工具。
Input Parameters
----------------
BrandId : M : See the details of section 8.2.2.
ProtocolId : M : This must be set "SETv1.0".
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO5217-A".
CurrCode : M : -
Amount : M : -
ConsumerPayId : M : -
WalletId : O : -
ProtocolBrand : M : -
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged: M : See details for section 8.3.1.
Content
Input Parameters
----------------
BrandId : M : See the details of section 8.2.2.
ProtocolId : M : This must be set "SETv1.0".
PayDirection : M : This must be set "Debit".
CurrCodeType : M : This should be set "ISO5217-A".
CurrCode : M : -
Amount : M : -
ConsumerPayId : M : -
WalletId : O : -
ProtocolBrand : M : -
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged: M : See details for section 8.3.1.
Content
Output Parameters
-----------------
PayInstrument : M : Multiple PayInstrument Ids may
be returned. See NOTE below.
Output Parameters
-----------------
PayInstrument : M : Multiple PayInstrument Ids may
be returned. See NOTE below.
NOTE Parameters of PayInstrument
--------------------------------
Id : M : This must be unique each SET
Certificates which the
Consumer can use.
xml:lang : M : -
PayInstName : M : -
NOTE Parameters of PayInstrument
--------------------------------
Id : M : This must be unique each SET
Certificates which the
Consumer can use.
xml:lang : M : -
PayInstName : M : -
If the SET Bridge receives this API Message, the SET Bridge returns three packaged content fields.
如果SET桥收到此API消息，SET桥将返回三个打包的内容字段。
Input Parameters
----------------
BrandId : M : This is set the consumer selected
BrandId.
PaymentInstrumentId: M : This is set the consumer selected
PaymentInstrumentID.
PayDirection : M : This is set "Debit".
CurrCodeType : M : This is set "ISO4217-A".
CurrCode : M : -
Amount : M : -
ProtocolId : M : This must be set "SETv1.0".
WalletId : O : -
Passphrase : O : -
ConsumerPayId : M : -
ProtocolBrand : M : This is set the consumer selected
ProtocolBrand Component.
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocol : M : This field is copied from the PayProtocol
PackagedContent Component
Input Parameters
----------------
BrandId : M : This is set the consumer selected
BrandId.
PaymentInstrumentId: M : This is set the consumer selected
PaymentInstrumentID.
PayDirection : M : This is set "Debit".
CurrCodeType : M : This is set "ISO4217-A".
CurrCode : M : -
Amount : M : -
ProtocolId : M : This must be set "SETv1.0".
WalletId : O : -
Passphrase : O : -
ConsumerPayId : M : -
ProtocolBrand : M : This is set the consumer selected
ProtocolBrand Component.
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocol : M : This field is copied from the PayProtocol
PackagedContent Component
Output Parameter
---------------
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfoPackaged current version of SET/IOTP.
Content
Output Parameter
---------------
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfoPackaged current version of SET/IOTP.
Content
BrandSelCurrency : O : This is not used in the AmountInfoPackaged current version of SET/IOTP. Content
BrandSelCurrency:O:这在当前版本的SET/IOTP中未使用。所容纳之物
In SET/IOTP, this API is used for the Consumer's SET Bridge to process the 1st SET Initiation and any subsequent SET messages.
在SET/IOTP中，此API用于消费者的SET桥接器，以处理第一次SET启动和任何后续SET消息。
Input Parameters
----------------
BrandId : M : ID for the consumer selected
Brand. See the details of
section 8.2.1.
PaymentInstrumentId: M : ID for the consumer selected
Instrument.
CurrCodeType : M : The consumer selected CurrCodeType.
CurrCode : M : The consumer selected CurrCode.
Amount : M : The consumer selected Amount.
PayDirection : M : Indicates the payment direction
from the Consumer's prospective.
ProtocolId : M : The consumer selected ProtocolId.
OkFrom : M : -
OkTo : M : -
ConsumerPayId : M : -
WalletID : O : -
Passphrase : O : -
CallBackFunction : O : This is not used in the SET/IOTP.
CallBackLanguage : O : This is not used in the SET/IOTP.
List
ProtocolBrand : M : ID for the consumer selected
Protocol dependent Brand information.
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged : M : See section 8.2.2.
Content
Input Parameters
----------------
BrandId : M : ID for the consumer selected
Brand. See the details of
section 8.2.1.
PaymentInstrumentId: M : ID for the consumer selected
Instrument.
CurrCodeType : M : The consumer selected CurrCodeType.
CurrCode : M : The consumer selected CurrCode.
Amount : M : The consumer selected Amount.
PayDirection : M : Indicates the payment direction
from the Consumer's prospective.
ProtocolId : M : The consumer selected ProtocolId.
OkFrom : M : -
OkTo : M : -
ConsumerPayId : M : -
WalletID : O : -
Passphrase : O : -
CallBackFunction : O : This is not used in the SET/IOTP.
CallBackLanguage : O : This is not used in the SET/IOTP.
List
ProtocolBrand : M : ID for the consumer selected
Protocol dependent Brand information.
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmount : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged : M : See section 8.2.2.
Content
Output Parameters
-----------------
ContStatus : M : "Continue" must be set if there is
in no problem
PaySchemePackaged : M : See section 6.5.1.
Content
Output Parameters
-----------------
ContStatus : M : "Continue" must be set if there is
in no problem
PaySchemePackaged : M : See section 6.5.1.
Content
This API is used to initiate a payment on the Payment Handler's side. The SET Related Module does a payment initialization. The SET Related Module processes SET Message received and returns the appropriate SET Message (e.g., 2nd SET Initiation or SET PinitRes message).
此API用于在支付处理程序端发起支付。设置相关模块执行付款初始化。SET相关模块处理接收到的SET消息，并返回相应的SET消息（例如，第二次SET启动或SET PinitRes消息）。
Input Parameters
----------------
BrandId : M : ID for the consumer selected Brand.
See the details of section 8.2.1.
ConsumerPayId : O : ID for the consumer generated payment
transaction.
CurrCodeType : M : The consumer selected CurrCodeType.
This should be set "ISO4217-A".
CurrCode : M : The consumer selected CurrCode.
Amount : M : The consumer selected Amount.
PayDirection : M : This is set "Debit".
ProtocolId : M : The consumer selected ProtocolId.
This must be set "SETv1.0".
OkFrom: : M : -
OkTo : M : -
PaymentHandlerPayId: M : -
MerchantOrgId : M : -
WalletID : O : -
Passphrase : O : -
CallBackFunction : O : This is not used in the SET/IOTP.
CallBackLanguage : O : This is not used in the SET/IOTP.
List
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmountP : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged: M : -
Content
ProtocolBrand : M : Information for the consumer selected
Protocol dependent Brand.
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
BrandSelCurrency : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
Input Parameters
----------------
BrandId : M : ID for the consumer selected Brand.
See the details of section 8.2.1.
ConsumerPayId : O : ID for the consumer generated payment
transaction.
CurrCodeType : M : The consumer selected CurrCodeType.
This should be set "ISO4217-A".
CurrCode : M : The consumer selected CurrCode.
Amount : M : The consumer selected Amount.
PayDirection : M : This is set "Debit".
ProtocolId : M : The consumer selected ProtocolId.
This must be set "SETv1.0".
OkFrom: : M : -
OkTo : M : -
PaymentHandlerPayId: M : -
MerchantOrgId : M : -
WalletID : O : -
Passphrase : O : -
CallBackFunction : O : This is not used in the SET/IOTP.
CallBackLanguage : O : This is not used in the SET/IOTP.
List
BrandPackaged : O : This is not used in the current
Content version of SET/IOTP.
ProtocolAmountP : O : This is not used in the current
PackagedContent version of SET/IOTP.
PayProtocolPackaged: M : -
Content
ProtocolBrand : M : Information for the consumer selected
Protocol dependent Brand.
BrandSelBrandInfo : O : This is not used in the current
PackagedContent version of SET/IOTP.
BrandSelProtocol : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
BrandSelCurrency : O : This is not used in the
AmountInfo current version of SET/IOTP.
PackagedContent
TradingRolePackaged: O : Copied from the TradingRoleData Content Component. The Name Attribute of the packaged contents must include "Payment:" as the prefix, for example "Payment:SET-OD". PaySchemePackaged : M : See section 6.5.2. Content
TradingRolePackaged:O：从TradingRoleData内容组件复制。打包内容的Name属性必须包含“Payment:”作为前缀，例如“Payment:SET-OD”。PaySchemePackaged:M：见第6.5.2节。所容纳之物
Output Parameters
-----------------
PaySchemePackaged : M : See section 6.5.2.
Content
ContStatus : M : "Continue" must be set if there
is no problem.
Output Parameters
-----------------
PaySchemePackaged : M : See section 6.5.2.
Content
ContStatus : M : "Continue" must be set if there
is no problem.
This API is used to restart a payment transaction when the transaction is suspended for some reason such as a time out. The last SET Message relevant to this suspended transaction is returned as the Response.
此API用于在交易因某些原因（如超时）暂停时重新启动支付交易。与此挂起事务相关的最后一条SET消息将作为响应返回。
Input Parameters
----------------
ConsumerPayId : M : -
WalletId : O : -
PassPhrase : O : -
CallBackFunction : O : This is not used in the current version
of SET/IOTP.
CallBack : O : This is not used in the current version
LanguageList of SET/IOTP.
Input Parameters
----------------
ConsumerPayId : M : -
WalletId : O : -
PassPhrase : O : -
CallBackFunction : O : This is not used in the current version
of SET/IOTP.
CallBack : O : This is not used in the current version
LanguageList of SET/IOTP.
Output Parameters
-----------------
ContStatus : M : -
PaySchamePackaged : M : See section 8.7.
Content
Output Parameters
-----------------
ContStatus : M : -
PaySchamePackaged : M : See section 8.7.
Content
This API is used to pass a SET related message, received from the counter party, to the SET Bridge, and accept the next SET message as a response.
此API用于将从对方接收的与集合相关的消息传递到集合网桥，并接受下一个集合消息作为响应。
(1) Consumer Side Payment Bridge
(1) 消费者端支付桥
Input Parameters
----------------
PayId : M : Set ConsumerPayId
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.4.3.
Content
Input Parameters
----------------
PayId : M : Set ConsumerPayId
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.4.3.
Content
Output Parameters
-----------------
ContStatus : M : Set "End" if SET PRes message is
received in the PaySchemePackagedContent
as the input parameter, otherwise set
"Continue".
PaySchemePackaged : O : If ContStatus is set "End", this is not
Content used. See 8.4.3.
Output Parameters
-----------------
ContStatus : M : Set "End" if SET PRes message is
received in the PaySchemePackagedContent
as the input parameter, otherwise set
"Continue".
PaySchemePackaged : O : If ContStatus is set "End", this is not
Content used. See 8.4.3.
(2) Payment Handler Side Payment Bridge
(2) 付款处理方付款桥
Input Parameters
----------------
PayId : M : Set PaymentHandlerPayId
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.4.4.
Content
Input Parameters
----------------
PayId : M : Set PaymentHandlerPayId
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.4.4.
Content
Output Parameters
-----------------
ContStatus : M : Set "End" if SET PRes message is
received in the
PaySchemePackagedContent as the
output parameter, otherwise set
"Continue".
PaySchemePackaged : M : See section 8.4.4.
Content
Output Parameters
-----------------
ContStatus : M : Set "End" if SET PRes message is
received in the
PaySchemePackagedContent as the
output parameter, otherwise set
"Continue".
PaySchemePackaged : M : See section 8.4.4.
Content
This API is used by the OAC to change the Process State of the OPB. For instance, it is used to change the Payment Status after a SET Payment Transaction was completed. When an error or suspend happens, this API is also used.
OAC使用此API更改OPB的进程状态。例如，用于在设置的付款交易完成后更改付款状态。当发生错误或挂起时，也会使用此API。
(1) Consumer Side Payment Bridge
(1) 消费者端支付桥
Input Parameters
----------------
PayId : M : Set ConsumerPayId
ProcessState : M : -
CompletionCode : M : -
ProcessType : M : -
WalletID : O : -
PassPhrase : O : -
Input Parameters
----------------
PayId : M : Set ConsumerPayId
ProcessState : M : -
CompletionCode : M : -
ProcessType : M : -
WalletID : O : -
PassPhrase : O : -
Output Parameters
-----------------
ProcessState : M : -
CompletionCode : M : -
PercentComplete : O : See section 8.13.
xml:lang : O : -
StatusDesc : O : This field is not specified in SET/IOTP.
Output Parameters
-----------------
ProcessState : M : -
CompletionCode : M : -
PercentComplete : O : See section 8.13.
xml:lang : O : -
StatusDesc : O : This field is not specified in SET/IOTP.
This API is not used in the current version of SET/IOTP.
当前版本的SET/IOTP中未使用此API。
This API is used to check whether the payment Bridge or its wallet is currently in use, or not.
此API用于检查支付桥或其钱包当前是否正在使用。
Input Parameters
----------------
WalletID : O : -
Input Parameters
----------------
WalletID : O : -
Output Parameters
-----------------
PayId : M : -
Output Parameters
-----------------
PayId : M : -
This API is used both Consumer and Payment Handler.
此API用于消费者和支付处理程序。
Input Parameters
----------------
PayId : M : -
WallerId : O : -
Passphrase : O : -
Input Parameters
----------------
PayId : M : -
WallerId : O : -
Passphrase : O : -
There is no output parameters.
没有输出参数。
This API is used to check a Payment Receipt. However since the current SET specification does not support Receipts, SET/IOTP sends its own visual information of a Receipt to the SET Bridge.
此API用于检查付款收据。但是，由于当前的SET规范不支持收据，SET/IOTP将其自己的收据可视信息发送到SET桥接器。
Input Parameters
----------------
PayId : M : -
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.5.1.
Content
Input Parameters
----------------
PayId : M : -
WalletId : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.5.1.
Content
Output Parameters
-----------------
There is no output Parameter.
Output Parameters
-----------------
There is no output Parameter.
This expands an IOTP Payment Receipt Component packaged data into a form which may be used for display or printing purposes.
这将IOTP付款收据组件打包数据扩展为可用于显示或打印目的的表单。
Input Parameters
----------------
PayId : M : -
WalletId : O : -
PassPhrase : O : -
PackagedContent : M : See section 8.5.2.
Input Parameters
----------------
PayId : M : -
WalletId : O : -
PassPhrase : O : -
PackagedContent : M : See section 8.5.2.
Output Parameters
-----------------
BrandId : M : -
ProtocolBrandId : M : -
PayInstrumentId : M : -
PaySchemePayId : M : LID_M in the SET PRes message is
set. (The format of this value must
be same as SET Initiation.)
Amount : M : Amount * AuthRatio (or CapRatio if
available). CapRatio should be the
high priority than AuthRatio.
CurrCodeType : M : -
CurrCode : M : -
PayDirection : M : -
ProtocolId : M : -
ProtocolTransId : O : -
TimeStamp : M : This value should be used the
Date field of MessageWrapper in the
SET PRes message
xml:lang : O : This is not used in the SET/IOTP.
ConsumerDesc : O : This is not used in the SET/IOTP.
Output Parameters
-----------------
BrandId : M : -
ProtocolBrandId : M : -
PayInstrumentId : M : -
PaySchemePayId : M : LID_M in the SET PRes message is
set. (The format of this value must
be same as SET Initiation.)
Amount : M : Amount * AuthRatio (or CapRatio if
available). CapRatio should be the
high priority than AuthRatio.
CurrCodeType : M : -
CurrCode : M : -
PayDirection : M : -
ProtocolId : M : -
ProtocolTransId : O : -
TimeStamp : M : This value should be used the
Date field of MessageWrapper in the
SET PRes message
xml:lang : O : This is not used in the SET/IOTP.
ConsumerDesc : O : This is not used in the SET/IOTP.
PaymentHandlerDesc : O : This is not used in the SET/IOTP. StyleNetLocn : O : This is not used in the SET/IOTP. PaymentProperty : O : This is not used in the SET/IOTP.
PaymentHandlerDesc:O:这不在SET/IOTP中使用。StyleNetLocn:O:这在集合/IOTP中未使用。PaymentProperty:O:这不在集合/IOTP中使用。
This API is used to check the payment status. For example, when the OAC receives a Continue Payment Response API, it uses this API if the ContStatus is set to "End". This API can be used at anytime.
此API用于检查付款状态。例如，当OAC接收到持续付款响应API时，如果ContStatus设置为“End”，它将使用此API。这个API可以在任何时候使用。
(1) Consumer Payment Bridge
(1) 消费者支付桥
Input Parameters
----------------
PayId : M : Set ConsumerPayId
WalletId : O : -
PassPhrase : O : -
Input Parameters
----------------
PayId : M : Set ConsumerPayId
WalletId : O : -
PassPhrase : O : -
Output Parameters
-----------------
ProcessState : M : -
PercentComplete : O : See 8.13 for the guideline of
setting value.
CompletionCode : O : See section 8.12.
xml:lang : O : -
StatusDesc : O : -
PayReceiptNameRefs : O : This is not used in the SET/IOTP.
PayReceiptPackConts: O : This is not used in the SET/IOTP.
Output Parameters
-----------------
ProcessState : M : -
PercentComplete : O : See 8.13 for the guideline of
setting value.
CompletionCode : O : See section 8.12.
xml:lang : O : -
StatusDesc : O : -
PayReceiptNameRefs : O : This is not used in the SET/IOTP.
PayReceiptPackConts: O : This is not used in the SET/IOTP.
(2) Payment Handler Payment Bridge
(2) 支付处理人支付桥
Input Parameters
----------------
PayId : M : Set PaymentHandlerPayId
WalletId : O : -
PassPhrase : O : -
Input Parameters
----------------
PayId : M : Set PaymentHandlerPayId
WalletId : O : -
PassPhrase : O : -
Output Parameters
-----------------
ProcessState : M : -
PercentComplete : O : See section 8.13 for the guideline
of setting value.
CompletionCode : O : See section 8.12.
xml:lang : O : -
StatusDesc : O : -
PayReceiptNameRefs : O : This is set "PRes".
PayReceiptPackConts: O : This is not used in the SET/IOTP.
Output Parameters
-----------------
ProcessState : M : -
PercentComplete : O : See section 8.13 for the guideline
of setting value.
CompletionCode : O : See section 8.12.
xml:lang : O : -
StatusDesc : O : -
PayReceiptNameRefs : O : This is set "PRes".
PayReceiptPackConts: O : This is not used in the SET/IOTP.
This API call returns the SET InqReq Message in order to process a SET Inquiry.
此API调用返回SET InqReq消息以处理集合查询。
Input Parameters
----------------
ConsumerPayId : M : -
WalletId : O : -
Passphrase : O : -
Input Parameters
----------------
ConsumerPayId : M : -
WalletId : O : -
Passphrase : O : -
Output Parameters
-----------------
PaySchemePackaged : M: Packaged Data to include SET
Content InqReq message. See section 8.6.
Output Parameters
-----------------
PaySchemePackaged : M: Packaged Data to include SET
Content InqReq message. See section 8.6.
The Payment Handler uses this API request for Consumer initiated inquiry processing. In SET/IOTP, the Payment Handler's SET Bridge receives a SET InqReq message in an InquirePaymentDetail API. The SET Core processes it, and creates a SET InqRes message. The response encapsulates the SET InqRes message.
支付处理程序使用此API请求进行消费者发起的查询处理。在SET/IOTP中，支付处理程序的SET桥接器在InquirePaymentDetail API中接收SET InqReq消息。SET核心处理它，并创建SET InqRes消息。响应封装了SET InqRes消息。
Input Parameters
----------------
PaymentHandlerPayId: M : -
WalletID : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.6.
Content
Input Parameters
----------------
PaymentHandlerPayId: M : -
WalletID : O : -
PassPhrase : O : -
PaySchemePackaged : M : See section 8.6.
Content
Output Parameters
-----------------
PaymentHandlerPayId: M : -
ProcessState : M : -
CompletionCode : O : -
xml:lang : O : -
StatusDesc : O : -
PaySchamePackaged : M : See section 8.6.
Content
Output Parameters
-----------------
PaymentHandlerPayId: M : -
ProcessState : M : -
CompletionCode : O : -
xml:lang : O : -
StatusDesc : O : -
PaySchamePackaged : M : See section 8.6.
Content
This chapter describes the core concepts for the development of SET/IOTP.
本章描述了SET/IOTP开发的核心概念。
This document describes SET Initiation Messages based on the [SET EIG]. Merchant sends the 1st SET Initiation Message to the Consumer in order to activate a SET payment transaction. After this message, the other SET Initiation Messages (JPO, etc.) and the SET payment Transaction (SET PinitReq message, etc.) are exchanged between the Consumer and the Payment Handler.
本文档描述了基于[SET EIG]的SET启动消息。商户向消费者发送第一个集合启动消息，以激活集合支付交易。在该消息之后，消费者和支付处理程序之间交换其他SET初始消息（JPO等）和SET支付事务（SET PinitReq消息等）。
+------------+ +----------+
| | | |
| |<----------------| Merchant |
| | 1st SET InitMsg | |
| | +----------+
| Consumer | +----------+
| | | |
| |<--------------->| P.H. |
| | Other SET Init/ | |
+------------+ SET Message +----------+
+------------+ +----------+
| | | |
| |<----------------| Merchant |
| | 1st SET InitMsg | |
| | +----------+
| Consumer | +----------+
| | | |
| |<--------------->| P.H. |
| | Other SET Init/ | |
+------------+ SET Message +----------+
Figure 11 Relationship between IOTP Messages and SET Messages
图11 IOTP消息和SET消息之间的关系
When the Merchant sends any data (e.g., SET SaleDetail) except a SET Related messages (e.g., SET PinitRes message), it can send it by two different methods:
当商户发送任何数据（如SET SaleDetail）时，除了与SET相关的消息（如SET PinitRes消息），它可以通过两种不同的方法发送：
(a) The Merchant sends the data via the Consumer. (b) The Merchant sends the data out-of-band.
(a) 商户通过消费者发送数据。（b） 商户将数据发送到带外。
In case (a), the Merchant sends the data by encapsulating it into TradingRoleData.PackagedContent inside the Offer Response Block sent to Consumer. The data is copied to the Payment Request Block and sent to the Payment Handler. This case assumes that the format of the data is already agreed upon between the Merchant and the Payment Handler.
在案例（a）中，商户通过将数据封装到发送给消费者的报价响应块内的TradingRoleData.PackagedContent中来发送数据。数据被复制到付款请求块并发送到付款处理程序。本案例假设商户和支付处理人之间已就数据格式达成一致。
This document does not specify case (b).
本文件未规定案例（b）。
BrandId should be used registered identification for IANA. Now, the following BrandIds have registered:
BrandId应作为IANA的注册标识。现在，以下BrandID已注册：
Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits, EZpay, GeldKarte, Mondex, paybox
美国运通、丹科特、JCB、迈斯卓、万事达卡、MICOS、VISA、atCredits、EZpay、GeldKarte、Mondex、paybox
ProtocolBrandID is defined as follows:
ProtocolBrandID的定义如下：
<Premise> SET BrandID is defined as brand[:Product]. ([] is indicated as optional.) In SET, The brandID is a brand name, which corresponds to the brand of the payment card. Additionally the Product is a product name, which is defined as the type of product within the specific brand such as Gold Card.
<Premise>SET BrandID定义为品牌[：产品]。（[]表示为可选。）在SET中，brandID是一个品牌名称，对应于支付卡的品牌。此外，产品是一个产品名称，定义为特定品牌（如金卡）内的产品类型。
Set IOTP ProtocolBrandId as follows:
按如下方式设置IOTP协议BrandId：
brand:Product:PCN
品牌：产品：PCN
In here,
在这里，
o The brand above is the same as the sub data of SET BrandID, as Brand Name (brand), defined in SET. o Product above is the same as the sub data of SET BrandID, as Product Name (Product), defined in SET. o PCN above is the Promotional Card Name, and is written in the SET Certificates.
o 以上品牌与SET BrandID的子数据相同，为SET中定义的品牌名称（brand）。o上述产品与集合BrandID的子数据相同，如集合中定义的产品名称（产品）。o上面的PCN是促销卡名称，并写在设置的证书中。
Example:
例子：
Visa:Gold:WalMart
签证：黄金：沃尔玛
Since SET Brand ID has a colon between brand and Product, the two colons should be able to delimit Brand, Product, and PCN.
因为SET Brand ID在品牌和产品之间有一个冒号，所以这两个冒号应该能够界定品牌、产品和PCN。
Product and PCN can omit if necessary. For the detail of these definitions are follows:
如有必要，产品和PCN可以省略。这些定义的详细信息如下：
(1) The case of omitting Product
(1) 省略乘积的情况
Definition: brand::PCN
Example: VISA::UC_VISA
Definition: brand::PCN
Example: VISA::UC_VISA
(2) The case of omitting PCN
(2) 省略PCN的情况
Definition: brand:Product
Example: VISA:Gold
Definition: brand:Product
Example: VISA:Gold
(3) The case of omitting Product, PCN
(3) 省略产品PCN的情况
Definition: brand Example: VISA
定义：品牌示例：VISA
Invalid Examples: VISA:Gold: VISA:: VISA: ProtocolBrandId which there is no brand.
无效示例：VISA:Gold:VISA:：VISA:ProtocolBrandId，其中没有品牌。
Protocolld defines as follows:
Protocolld定义如下：
ProtocolId := SETName + Version
SETName := "SET"
Version := "v" + version + "." + revision
ProtocolId := SETName + Version
SETName := "SET"
Version := "v" + version + "." + revision
Where the version is number matching a major SET version, and the revision is the number matching a minor SET revision. Example: "SETv1.0","SETv2.0"
其中，版本号与主要版本集版本匹配，版本号与次要版本集版本匹配。示例：“SETv1.0”、“SETv2.0”
NOTE: In the current version of SET/IOTP, "SETv1.0" is fixed as ProtocolId.
注：在当前版本的SET/IOTP中，“SETv1.0”固定为ProtocolId。
ProtocolBrandId must be unique and depends on BrandId and ProtocolId. The followings are map among BrandId and ProtocolId, which have registered in IANA, and ProtocolBrandId.
ProtocolBrandId必须是唯一的，并且依赖于BrandId和ProtocolId。以下是在IANA注册的BrandId和ProtocolId之间的地图，以及ProtocolBrandId。
BrandId ProtocolId ProtocolBrandId
-----------------------------------------
Amex SETv1.0 Amex
Dankort SETv1.0 Dankort
JCB SETv1.0 JCB
MasterCard SETv1.0 MasterCard
Nicos SETv1.0 Amex
VISA SETv1.0 VISA
BrandId ProtocolId ProtocolBrandId
-----------------------------------------
Amex SETv1.0 Amex
Dankort SETv1.0 Dankort
JCB SETv1.0 JCB
MasterCard SETv1.0 MasterCard
Nicos SETv1.0 Amex
VISA SETv1.0 VISA
Regarding to the BrandIds except above, the BrandId registrant (e.g., credit card company) MUST register it in order to be able to map one to one between ProtocolBrandId and the pair of BrandId and ProtocolId.
关于除上述以外的BrandId，BrandId注册人（如信用卡公司）必须进行注册，以便能够在ProtocolBrandId与BrandId和ProtocolId对之间一一对应。
(1) Parameter of PayProtocolPackagedContent
(1) PayProtocolPackagedContent的参数
Name : O : This is not used in SET/IOTP. Content : M : This should be set "PCDATA". Transform : M : This is set "BASE64". ContentData : M : SET specific protocol data. Includes data that is used to create the 1st SET Initiation Message that is not contained in other IOTP elements.
名称：O：这不用于SET/IOTP。内容：M：应设置为“PCDATA”。转换：M：这是设置为“BASE64”。ContentData:M：设置特定的协议数据。包括用于创建未包含在其他IOTP元素中的第一组启动消息的数据。
(2) Parameter in the ContentData
(2) ContentData中的参数
Parameters of ContentData are described below. The Field Values follow the [SET EIG].
ContentData的参数如下所述。字段值遵循[SET EIG]。
Field Required
------------------------------------
MIME-Version Optional
Content-Transfer-Encoding Mandatory
SET-Initiation-Type Mandatory
SET-LID-M Optional
SET-InstallTotalTrance Optional
SET-Recurring Optional
SET-Ext-OID Optional
SET-Ext-Data Optional
SET-Ext-Mandatory Optional
SET-Echo-In-Response Optional
SET-Echo-In-Request Optional
Field Required
------------------------------------
MIME-Version Optional
Content-Transfer-Encoding Mandatory
SET-Initiation-Type Mandatory
SET-LID-M Optional
SET-InstallTotalTrance Optional
SET-Recurring Optional
SET-Ext-OID Optional
SET-Ext-Data Optional
SET-Ext-Mandatory Optional
SET-Echo-In-Response Optional
SET-Echo-In-Request Optional
For Example:
例如：
MIME-Version: 1.0
Content-Transfer-Encoding: Binary
SET-Initiation-Type: Payment-Initiation
SET-Recurring: 31 19960223
SET-Service-URL: http://www.custcare.com/index.html
SET-LID-M: 515A533033363632594B
MIME-Version: 1.0
Content-Transfer-Encoding: Binary
SET-Initiation-Type: Payment-Initiation
SET-Recurring: 31 19960223
SET-Service-URL: http://www.custcare.com/index.html
SET-LID-M: 515A533033363632594B
Note: The contents in ProtoclPackagedContent must be US-ASCII and encoded by BASE64.
注意：ProtoclPackagedContent中的内容必须是US-ASCII，并由BASE64编码。
(1) Information of PayInstrument
(1) 支付工具信息
Returns a list of Payment Instrument IDs related to the BrandId and ProtocolBrandId. In this document, BrandId and ProtocolId are defined in section 8.2.
返回与BrandId和ProtocolBrandId相关的支付工具ID列表。在本文件中，BrandId和ProtocolId的定义见第8.2节。
In this document, Brand has two recognized meanings in SET/IOTP, as follows:
在本文件中，品牌在SET/IOTP中有两个公认的含义，如下所示：
Brand as Primary Brand: The Primary Brand is the Brand which is defined as brand in SET, such as VISA, MasterCard, Nicos.
品牌作为主品牌：主品牌是指在集合中定义为品牌的品牌，如VISA、MasterCard、Nicos。
Brand as Dual Brand or Promotional Brand: The Dual Brand is the payment instrument which has two Brand, such as UC-VISA (UC Card and VISA Card) This style is popular in Japan.
品牌分为双品牌或促销品牌：双品牌是指有两个品牌的支付工具，如UC-VISA（UC卡和VISA卡），这种风格在日本很流行。
A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit such as discount or frequent flyer point.
促销品牌意味着，如果消费者使用该品牌付款，那么消费者将获得一些额外的好处，如折扣或常旅客积分。
1. ProtocolBrandId as a Primary Brand
1. ProtocolBrandId作为主要品牌
Example:
例子：
"MasterCard", "MasterCard::UC", "MasterCard:Gold:" and "MasterCard::WalMart" are all MasterCard Brands.
“万事达卡”、“万事达卡：：加州大学”、“万事达卡：黄金：”和“万事达卡：：沃尔玛”都是万事达卡品牌。
2. ProtocolBrandId as a Dual Brand or a Promotional Brand
2. ProtocolBrandId作为双重品牌或促销品牌
Example:
例子：
"MasterCard::UC" is Dual Brand of "MasterCard" and "UC". "SET:MasterCard::WalMart" is Promotional Brand of MasterCard-WallMart.
“万事达卡：：UC”是“万事达卡”和“UC”的双重品牌。“SET:MasterCard:：WalMart”是MasterCard WalMart的促销品牌。
The SET Bridge receives the ProtocolBrandId from the OAC in the FindPaymentInstrument Function,
SET桥接器在FindPaymentInstrument函数中从OAC接收ProtocolBrandId，
(1) If the accepted ProtocolBrandId is XXX:YYY
(1) 如果接受的ProtocolBrandId为XXX:YYY
The SET Related Module searches for ProtocolBrandIds with the string "XXX:YYY:*" (* is wild card), the corresponding PaymentInstrumentIds of all ProtocolBrandIds with the matching Primary Brand (regardless of also being a Dual Brand or Promotional Brand) will be returned to the OAC, for the Consumer to select from.
集合相关模块搜索字符串为“XXX:YYY:*”（*为通配符）的ProtocolBrandId，所有ProtocolBrandId的对应PaymentInstrumentId与匹配的主品牌（无论是双品牌还是促销品牌）将返回给OAC，供消费者选择。
(2) If the accepted ProtocolBrandId is XXX:YYY:ZZZ
(2) 如果接受的ProtocolBrandId为XXX:YYY:ZZZ
The SET Related Module searches for ProtocolBrandIDs with the string "XXX:YYY:ZZZ", only the corresponding PaymentInstrumentIds of the ProtocolBrandIds that match the Dual Brand or Promotional Brand will be returned to OAC, for the Consumer to select from.
集合相关模块搜索字符串为“XXX:YYY:ZZZ”的ProtocolBrandId，只有与双品牌或促销品牌匹配的ProtocolBrandId的对应PaymentInstrumentId才会返回给OAC，供消费者选择。
Example:
例子：
Assume ProtocolBrandIds are correspond to PaymentInstrumentIds in the SET Bridge as follows,
假设ProtocolBrandId对应于集合桥中的PaymentInstrumentId，如下所示，
ProtocolBrandId PaymentInstrumentId
------------------------------------------
MasterCard 1
MasterCard::UC 2
MasterCard::WallMart 3
VISA::UC 4
ProtocolBrandId PaymentInstrumentId
------------------------------------------
MasterCard 1
MasterCard::UC 2
MasterCard::WallMart 3
VISA::UC 4
If the SET Bridge receives a ProtocolBrandId as "MasterCard" in the FindPaymentInstrument Function, the SET Bridge will return "1","2", and "3". However, if the SET Bridge receives a ProtocolBrandId as "MasterCard::UC" to OAC, SET Bridge will returns only "2".
如果SET Bridge在FindPaymentInstrument函数中接收到ProtocolBrandId作为“MasterCard”，SET Bridge将返回“1”、“2”和“3”。但是，如果SET网桥接收到OAC的ProtocolBrandId为“MasterCard:：UC”，SET网桥将只返回“2”。
(1) Create TradingRolePackagedContent
(1) 创建TradingRolePackagedContent
If necessary, The SET Related Module generates TradingRolePackagedContent corresponded to the received ReceiverOrgID. The ContentData of TradingRolePackagedContent is the information which the Payment Handler needs to process the SET Transaction (for example, the SET SaleDetail. and the SET OD). The ContentData, Content, and the Transform must be agreed upon between the Merchant and the Payment Handler beforehand.
如有必要，集合相关模块将生成与接收到的ReceiverOrgID对应的TradingRolePackagedContent。TradingRolePackagedContent的内容数据是支付处理程序处理集合交易所需的信息（例如，集合SaleDetail.和集合OD）。内容数据、内容和转换必须事先在商户和支付处理人之间达成一致。
The Name Attribute of the packaged contents must include "Payment:" as the prefix, for example "Payment:SET-OD". If there is no PackagedContent corresponding to ReceiverOrgID, such that the SET Related Module does not need to create the PackagedContent, the TradingRolePackagedContent is not created.
打包内容的Name属性必须包含“Payment:”作为前缀，例如“Payment:SET-OD”。如果没有与ReceiverOrgID对应的PackagedContent，因此集合相关模块不需要创建PackagedContent，则不会创建TradingRolePackagedContent。
Parameters in TradingRolePackagedContent
----------------------------------------
Name : O : This is not specified in the current SET/IOTP.
Content : M : Should be identical between the Payment
Handler and the Merchant.
Transform : M : Should be identical between the Payment
Handler and the Merchant.
ContentData : M : Element Data for the Payment Handler to
process the SET Transaction. Should be
identical between the Payment Handler and
the Merchant.
Parameters in TradingRolePackagedContent
----------------------------------------
Name : O : This is not specified in the current SET/IOTP.
Content : M : Should be identical between the Payment
Handler and the Merchant.
Transform : M : Should be identical between the Payment
Handler and the Merchant.
ContentData : M : Element Data for the Payment Handler to
process the SET Transaction. Should be
identical between the Payment Handler and
the Merchant.
(1) Process of the 1st SET Initiation Message
(1) 第一套启动报文的处理
Since there are similar items between the SET Initiation Message Fields and IOTP Elements, IOTP elements can be used for the corresponding SET Initiation Fields. Other SET Initiation Fields, except URL information (for detail, see below), is encapsulated in the PayProtocolPackagedContent.
由于集合启动消息字段和IOTP元素之间存在类似的项目，因此IOTP元素可用于相应的集合启动字段。除了URL信息（有关详细信息，请参见下文）之外，其他集合启动字段都封装在PayProtocolPackagedContent中。
This document does not specify how the SET Related Module implements the 1st SET Initiation Process.
本文档未指定集合相关模块如何实施第一个集合启动过程。
The following table shows the list of SET Initiation Fields that corresponds to IOTP Elements.
下表显示了与IOTP元素对应的集合启动字段列表。
SET Initiation Field IOTP Element (in TPO.Brandlist)
---------------------------------------------------------------
SET-Version Consumer selected ProtocolId
SET-Brand Consumer selected ProtocolBrandId
SET-Amount Consumer selected Amount Data in
CurrencyAmount.
--------------------------------------------------------------
SET Initiation Field IOTP Element (in OfferResp)
--------------------------------------------------------------
Order Description The hash data of ContentData of
PackagedContent of Order Component.
SET Initiation Field IOTP Element (in TPO.Brandlist)
---------------------------------------------------------------
SET-Version Consumer selected ProtocolId
SET-Brand Consumer selected ProtocolBrandId
SET-Amount Consumer selected Amount Data in
CurrencyAmount.
--------------------------------------------------------------
SET Initiation Field IOTP Element (in OfferResp)
--------------------------------------------------------------
Order Description The hash data of ContentData of
PackagedContent of Order Component.
(b) SET-Version:
(b) 设置版本：
SET-Version can be corresponded to ProtocolId. The version number appears after the "v" for the SET-Version.
集合版本可以对应于ProtocolId。版本号显示在设置版本的“v”之后。
ProtocolId -> _______
SETv1.0
~~~<- SET-Version
ProtocolId -> _______
SETv1.0
~~~<- SET-Version
Figure 12 ProtocolId vs SET-Version
图12 ProtocolId与SET版本
(c) SET-Brand:
(c) 设置品牌：
SET-Brand can be corresponded to ProtocolBrandId.
SET Brand可以对应于ProtocolBrandId。
(d) SET-PurchAmt: It is necessary to adjust the format of the Amount between IOTP and SET, since IOTP and SET use different syntax.
(d) SET PurchAmt：需要调整IOTP和SET之间的金额格式，因为IOTP和SET使用不同的语法。
Assumption:
假设：
o In SET/IOTP, The "ISO4217-A" (the currency code which is represented by three alphabet, such as "USD") is mandatory.
o 在SET/IOTP中，“ISO4217-A”（由三个字母表示的货币代码，如“USD”）是强制性的。
o Consumer Side SET Related Module should have a mapping table between "ISO4217-A" and "ISO4217-N" (the currency code which is represented by three digit, such as "840").
o 用户端集合相关模块应具有“ISO4217-a”和“ISO4217-N”之间的映射表（由三位数字表示的货币代码，如“840”）。
(d) -1 Content of the SET-PurchAmt
(d) -1集PurchAmt的内容
The content of the SET-PurchAmt is as follows:
该套PurchAmt的内容如下：
SET PurchAmt: currency amount amtExp10
设置PurchAmt：货币金额amtExp10
For a description see [SET] Book 2, page 299. For example, $129.50 is represented by "840 12950 -2". In this case, the corresponding values for the "currency", "amount" and "amtExp10" are "840", "12950" and "-2" respectively.
有关说明，请参见[SET]第2册第299页。例如，129.50美元由“840 12950-2”表示。在这种情况下，“货币”、“金额”和“amtExp10”的对应值分别为“840”、“12950”和“-2”。
(d) -2 Content of IOTP Amount Elements
(d) -2物联网金额要素的内容
The content of the three IOTP amount elements consist of the following: Amount, CurrCodeType and CurrCode. For a description of each, see [RFC 2801]. For example, $129.50 is represented by the following:
三个IOTP金额元素的内容包括以下内容：金额、CurrCodeType和CurrCode。有关每种方法的说明，请参见[RFC 2801]。例如，129.50美元由以下各项表示：
CurrCodeType="ISO4217-A" CurrCode="USD"
CurrCodeType=“ISO4217-A”CurrCode=“USD”
Amount="129.50"
金额=“129.50”
(d) -3 Example of how-to-translate
(d) -3如何翻译的例子
The one-to-one mapping between the IOTP format and the SET format is very simple. This example of sequence below uses the example of IOTP amount Element above.
IOTP格式和SET格式之间的一对一映射非常简单。下面的序列示例使用上面的IOTP amount元素示例。
1) Translate from IOTP CurrCode (ISO4217-A) to SET currency (ISO-4217-N). For example, if CurrCode="USD", then the value of currency is "840".
1) 将IOTP货币代码（ISO4217-A）转换为设置货币（ISO-4217-N）。例如，如果CurrCode=“USD”，则货币值为“840”。
2) Calculate how many decimal places are represented in the Amount. For example, if Amount="129.50", there are "2" decimal places.
2) 计算金额中的小数位数。例如，如果Amount=“129.50”，则小数点后有“2”位。
3) [The number of decimal places] *( -1) corresponds to the SET amtExp10. In the above case, SET amtExp10 = 2 * (-1) = -2.
3) [小数位数]*（-1）对应于设置的amtExp10。在上述情况下，设置amtExp10=2*（-1）=-2。
4) 10^[The number of the Amount's decimal places] * Amount corresponds to the SET amount. In the above example, SET amount = 10^2 * 129.50 = 12950.
4) 10^[金额的小数位数]*金额对应于设定的金额。在上面的示例中，设置amount=10^2*129.50=12950。
5) Concatenate three integers and use white spaces as a delimiter.
5) 连接三个整数并使用空格作为分隔符。
Finally, in the above case, the SET PurchAmt is represented as "840 12950 -2".
最后，在上述情况下，集合PurchAmt表示为“840 12950-2”。
(e) SET OD (Order Description) vs. IOTP Order Information
(e) 设置OD（订单描述）与IOTP订单信息
In the IOTP, the OAC handles the Order Information, such as display use, as SET uses the Order Information. Payment Handler does not know the actual Order Information because the Merchant and Payment Handler may exist in the separate domains. However, Payment Handler needs to get the SET OD from Merchant via the Consumer or directly because Payment Handler needs the SET OD to create 2nd SET Initiation message and after. In this situation, the Merchant should not pass the actual order information to the Payment Handler because the order information may be considered private data. Therefore, SET/IOTP defines SET OD as the hash of IOTP Order Information. The hash algorithm must be SHA1.
在IOTP中，OAC处理订单信息，例如显示使用，因为SET使用订单信息。支付处理程序不知道实际订单信息，因为商户和支付处理程序可能存在于不同的域中。但是，支付处理程序需要通过消费者或直接从商户处获取设置OD，因为支付处理程序需要设置OD来创建第二个设置启动消息以及之后。在这种情况下，商户不应将实际订单信息传递给支付处理程序，因为订单信息可能被视为私人数据。因此，SET/IOTP将SET OD定义为IOTP订单信息的散列。哈希算法必须是SHA1。
But the Order Component may be included two or more Packaged Content (see [RFC 2801]). Therefore SET/IOTP specifies to create hash as follows:
但订单组件可能包含两个或多个打包内容（请参见[RFC 2801]）。因此，SET/IOTP指定创建哈希，如下所示：
(e) -1. If the Name attribute does not have the Name attribute, such that the Order Component have only one Packaged Content, hash the Contents Data using SHA1 simply and be encoded by BASE64.
(e) -1.如果Name属性没有Name属性，使得Order组件只有一个打包的内容，那么使用SHA1简单地散列内容数据，并用BASE64编码。
(e) -2. Otherwise, such that there exists the Name attribute, sort the Packaged Contents in the UTF-16 character code order of Name attribute and hash the Content Data using SHA1 and concatenate them in proper sequence, then hash it using SHA1 again and be encoded by BASE64.
(e) -2.否则，如果存在名称属性，则按照名称属性的UTF-16字符编码顺序对打包内容进行排序，并使用SHA1对内容数据进行哈希，并按正确的顺序连接，然后再次使用SHA1对其进行哈希，并使用BASE64进行编码。
NOTE: To avoid different character encodings between applications, in this document, SET OD MUST be constructed from the ContentData in OrderPackagedContent as follows:
注意：为了避免应用程序之间的字符编码不同，在本文档中，必须根据OrderPackagedContent中的ContentData构建SET OD，如下所示：
(1) Convert it to network byte ordered Unicode encoding data. (2) Hash (1) using SHA1 (3) Convert (2) to BASE64 US-ASCII data
(1) 将其转换为网络字节顺序的Unicode编码数据。（2） 使用SHA1（3）将哈希（1）转换为BASE64 US-ASCII数据
Therefore, "Content-Type","charset" MUST be "text/plain","us-ascii" respectively when SET Initiation message is constructed.
因此，在构造集合启动消息时，“内容类型”、“字符集”必须分别为“文本/普通”、“us ascii”。
(f) SET-***-URL vs. IOTP Net Location
(f) SET-***-URL vs. IOTP Net Location
In IOTP, the OAC handles location data therefore the OAC does not
need to pass net location data on to the OPB. However, some vender
implemented consumer SET/IOTP wallets may need the URL information to
process the SET Initiation. Thus, if necessary, the Consumer's SET
Related Module must set appropriate URL data to SET-***-URL.
In IOTP, the OAC handles location data therefore the OAC does not
need to pass net location data on to the OPB. However, some vender
implemented consumer SET/IOTP wallets may need the URL information to
process the SET Initiation. Thus, if necessary, the Consumer's SET
Related Module must set appropriate URL data to SET-***-URL.
(2) Create the next SET related message
(2) 创建下一个集合相关消息
Generate SET related message (SET PInitReq or SET Initiation Response) at the SET Related Module, to be sent to the Payment Handler.
在SET相关模块生成SET相关消息（SET PInitReq或SET INITION Response），发送给支付处理程序。
(3) Error check of the next SET related message.
(3) 下一个集合相关消息的错误检查。
If SET related message which is created in (2) is SET Initiation Response and includes any error in it, SET Related Module creates an ErrorResponse message with ErrorCode to "EncapProtErr" and the Severity to "HardError" and sent it to the OAC.
如果在（2）中创建的SET相关消息是SET INITION Response，并且其中包含任何错误，则SET相关模块将创建一条ErrorResponse消息，其中ErrorCode为“Encaproperter”，Severity为“HardError”，并将其发送给OAC。
(4) Create PaySchemePackagedContent
(4) 创建PaySchemePackagedContent
The followings are the parameter of PaySchemePackagedContent in StartPaymentConsumerResponse.
以下是StartPaymentConsumerResponse中PaySchemePackagedContent的参数。
ContentData : M : SET Related Message which is encoded by BASE64. (e.g., SET PinitRes message or SET Initiation Response Message) Name : O : This is not used in the current SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64".
ContentData:M：设置相关消息，由BASE64编码。（例如，SET PinitRes消息或SET INITION Response消息）名称：O：当前SET/IOTP中不使用该名称。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。
(5) Store of the Payment Information
(5) 支付信息的存储
SET Bridge should store the following in the DataBase:
SET Bridge应在数据库中存储以下内容：
o ConsumerPayId o PaySchemePackagedContent o ContStatus o ContentSoftwareId (corresponding to the PaySchemePackagedContent) o ProcessState
o ConsumerPayId o PaySchemePackagedContent o ContStatus o ContentSoftwareId（对应于PaySchemePackagedContent）o ProcessState
(1) Process for TradingRoleData
(1) TradingRoleData流程
SET Bridge must processes appropriately, for example pass it to the SET Core, if there exists the TradingRolePackagedContent as the input Parameter.
如果存在TradingRolePackagedContent作为输入参数，则SET Bridge必须进行适当的处理，例如将其传递给SET Core。
(2) SET Specific Process
(2) 设定具体流程
The SET Related Module processes the SET Initiation Response or the SET Transaction (SET PInitReq). In addition, the SET Related Module generates a message (the next SET Initiation Message or SET PInitRes) corresponding to the results of the processed message. This message will be sent to the Consumer.
SET相关模块处理SET启动响应或SET事务（SET PInitReq）。此外，SET相关模块生成一条消息（下一个SET INITION消息或SET PInitRes），该消息与处理后的消息的结果相对应。此消息将发送给消费者。
(3) Error check of the next SET related message.
(3) 下一个集合相关消息的错误检查。
If SET related message which is created in (2) includes any error, SET Related Module create an ErrorResponse message with ErrorCode to "EncapProtErr" and the Severity to "HardError" and sent it to the OAC.
如果在（2）中创建的SET-related message（设置相关消息）包含任何错误，则将related Module create ErrorResponse message（设置相关模块创建一条ErrorCode为“Encaproperter”且严重性为“HardError”的ErrorResponse message（错误响应消息），并将其发送给OAC。
(4) Generate PaySchemePackagedContent
(4) 生成PaySchemePackagedContent
PaySchemePackagedContent which Encapsulate the SET Initiation Message or SET PInitRes into ContentData and generate the PaySchemePackagedContent. The Parameters of PaySchemePackagedContent as Output is as follows:
PaySchemePackagedContent，它将SET启动消息或SET PInitRes封装到ContentData中，并生成PaySchemePackagedContent。PaySchemePackagedContent作为输出的参数如下：
ContentData : M : SET Related Message which is encoded by
BASE64 (e.g., SET PinitRes message or
SET Initiation Response Message).
Name : O : This is not used in the current SET/IOTP.
Content : M : This field should be set to "PCDATA".
Transform : M : This must be set "BASE64"
ContentData : M : SET Related Message which is encoded by
BASE64 (e.g., SET PinitRes message or
SET Initiation Response Message).
Name : O : This is not used in the current SET/IOTP.
Content : M : This field should be set to "PCDATA".
Transform : M : This must be set "BASE64"
(1) SET Specific Process
(1) 设定具体流程
The Parameters of PaySchemePackagedContent as Input is as follows:
PaySchemePackagedContent作为输入的参数如下：
ContentData : M : SET Related Message which is encoded by
BASE64 (e.g., SET PinitRes message,
SET PRes message or SET Initiation
Response Message).
Name : O : This is not used in the current SET/IOTP.
Content : M : This field should be set to "PCDATA".
Transform : M : This must be set "BASE64"
ContentData : M : SET Related Message which is encoded by
BASE64 (e.g., SET PinitRes message,
SET PRes message or SET Initiation
Response Message).
Name : O : This is not used in the current SET/IOTP.
Content : M : This field should be set to "PCDATA".
Transform : M : This must be set "BASE64"
SET Related Module processes the SET Related Message in the PaySchemePackagedContent, then SET Related Message corresponding to the processed message is created if necessary.
SET-Related模块处理PaySchemePackagedContent中的SET-Related消息，然后根据需要创建与处理的消息相对应的SET-Related消息。
(2) SET Related Message Error Check
(2) 设置相关消息错误检查
If SET related message which is created in (2) includes any error, SET Related Module create an ErrorResponse message with ErrorCode to "EncapProtErr" and the Severity to "HardError" and sent it to the OAC.
如果在（2）中创建的SET-related message（设置相关消息）包含任何错误，则将related Module create ErrorResponse message（设置相关模块创建一条ErrorCode为“Encaproperter”且严重性为“HardError”的ErrorResponse message（错误响应消息），并将其发送给OAC。
(3) Create PaySchemePackagedContent
(3) 创建PaySchemePackagedContent
The followings are the parameter of PaySchemePackagedContent in ContinueProcessResponse.
以下是ContinueProcessResponse中PaySchemePackagedContent的参数。
ContentData : M : SET Related Message which is encoded by BASE64 (e.g., SET PinitReq message, SET PReq message or SET Initiation Response Message).
ContentData:M：设置相关消息，由BASE64编码（例如，设置PinitReq消息、设置PReq消息或设置启动响应消息）。
Name : O : This is not used in the current SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64".
名称：O：当前集合/IOTP中未使用此选项。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。
If the ContentData which has received from Payment Handler is SET PRes message, this data is not created.
如果从付款处理程序接收的ContentData设置为PRes message，则不会创建此数据。
(1) Brand Integrity Check between IOTP Elements and SET Elements
(1) IOTP元素和SET元素之间的品牌完整性检查
Since the Consumer sets the Amount and Brand in the SET Message, based on the IOTP message, it might be altered when the IOTP message is copied to the SET message. Thus, the Payment Handler needs to check the Elements in IOTP components (Payment, etc.) and the Elements in the SET message to make sure they are consistent. The IOTP Brand specified by the Merchant should correspond to the Brand used in the SET payment.
由于消费者根据IOTP消息在SET消息中设置了数量和品牌，因此当IOTP消息复制到SET消息时，可能会对其进行更改。因此，支付处理程序需要检查IOTP组件（支付等）中的元素和SET消息中的元素，以确保它们一致。商户指定的IOTP品牌应与设置支付中使用的品牌相对应。
The Brand Integrity check sequence is as follows:
品牌完整性检查顺序如下：
(a) After receiving the SET PReq message, check the Consumer selected Brand information (e.g., ProtocolBrandId) in the IOTP Payment Request against information in the SET certificate in the SET PReq message.
(a) 收到SET PReq消息后，对照SET PReq消息中SET证书中的信息，检查IOTP付款请求中消费者选择的品牌信息（如ProtocolBrandId）。
(b) If they do not match, return a SET Bridge Level Error (Severity="HardError", ErrorCode="AttNotValid" and Names="BrandId").
(b) 如果它们不匹配，则返回一个设置网桥级别的错误（Severity=“hardrerror”、ErrorCode=“AttNotValid”和Names=“BrandId”）。
Additionally, the SET PReq message signature must be verified with the SET CardHolder's certificate. (This is done during a normal SET Transaction.)
此外，必须使用SET持卡人证书验证SET PReq消息签名。（这是在正常设置事务期间完成的。）
NOTE: This integrity check is necessary evenif There is no Promotional Card Name in the ProtocolBrandId because SET may have selected the MasterCard even though IOTP has selected the VISA.
注意：即使ProtocolBrandId中没有促销卡名称，此完整性检查也是必要的，因为即使IOTP选择了VISA，SET也可能选择了MasterCard。
(2) SET Related Process
(2) 集合相关过程
Encapsulate the SET related Message (SET Initiation Message or SET Transaction Message) in to Content Data of PaySchemePackagedContent and send it to the Sender.
将与设置相关的消息（设置启动消息或设置事务消息）封装到PaySchemePackagedContent的内容数据中，并将其发送给发送方。
The followings are the parameters of PaySchemePackagedContent as output.
以下是PaySchemePackagedContent作为输出的参数。
ContentData : M : SET Related Message which is encoded by BASE64 (e.g., SET PinitReq message, SET PReq message or SET Initiation Response Message). Name : O : This is not used in the current SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64".
ContentData:M：设置相关消息，由BASE64编码（例如，设置PinitReq消息、设置PReq消息或设置启动响应消息）。名称：O：当前集合/IOTP中未使用此选项。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。
(3) SET Related Message Error Check
(3) 设置相关消息错误检查
If SET related message which is created in (2) includes any error, SET Related Module create an ErrorResponse message with ErrorCode to "EncapProtErr" and the Severity to "HardError" and sent it to the OAC.
如果在（2）中创建的SET-related message（设置相关消息）包含任何错误，则将related Module create ErrorResponse message（设置相关模块创建一条ErrorCode为“Encaproperter”且严重性为“HardError”的ErrorResponse message（错误响应消息），并将其发送给OAC。
If SET related message which is created in (2) is SET PRes message, and its message includes except:
如果在（2）中创建的SET相关消息是SET PRes消息，其消息包括但不包括：
(a) CompletionCode in SET PRes message is "authorizationPerformed" and AuthCode is "Approved" or (b) CompletionCode in SET PRes message is "capurePerformed" and CapCode "Success",
(a) SET PRes消息中的CompletionCode为“authorizationPerformed”，AuthCode为“Approved”，或（b）SET PRes消息中的CompletionCode为“capurePerformed”，CapCode为“Success”，
SET Related Module create ErrorResponse message with ErrorCode to "BusinessError"and the Severity to "HardError" and sent it to the OAC.
将错误代码为“BusinessError”且严重性为“HardError”的相关模块创建错误响应消息设置为“HardError”，并将其发送给OAC。
(4) Create PaySchemePackagedContent
(4) 创建PaySchemePackagedContent
The followings are the parameter of PaySchemePackagedContent in ContinueProcessResponse.
以下是ContinueProcessResponse中PaySchemePackagedContent的参数。
ContentData : M : SET Related Message which is encoded by BASE64 (e.g., SET PinitRes message, SET PRes message or next SET Initiation Message). Name : O : "PRes" only if ContentData includes SET PRes message, otherwise this is not used in the current SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64".
ContentData:M：由BASE64编码的SET相关消息（例如SET PinitRes消息、SET PRes消息或next SET INITION消息）。名称：O：仅当ContentData包含SET PRes消息时：“PRes”，否则在当前SET/IOTP中不使用此消息。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。
If ContentData includes the SET PRes message, ContStatus MUST be "End".
如果ContentData包含SET PRes消息，ContStatus必须为“End”。
(1) Setting ProcessState
(1) 设置进程状态
Values for the ProcessState are described in section 8.9.2.
ProcessState的值见第8.9.2节。
(2) Setting CompletionCode
(2) 设置完成代码
Set to "Unspecified" when a SET Business Failure has occurred, and set StatusDesc to the value corresponding to AuthCode or CapCode.
发生Set业务故障时设置为“未指定”，并将STATUSSDESC设置为与AuthCode或CapCode对应的值。
(3) Setting StatusDesc
(3) 设置状态描述
The values for PayStatusDesc are not specified in the SET/IOTP.
集合/IOTP中未指定PayStatusDesc的值。
(4) Create PayReceiptNameRefs
(4) 创建PayReceiptNameRefs
Set to "PRes" in the PayReceiptNameRefs
在PayReceiptNameRefs中设置为“PRes”
SET Related Module does not check the Payment Receipt Information especially, sends the general response message as long as valid request message.
设置相关模块不特别检查收付款信息，只要请求消息有效，就发送一般响应消息。
The Parameters of PayReceiptPackagedContent are followings:
PayReceiptPackagedContent的参数如下：
Name : O : This MUST be set "PRes" Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET PRes message which is encoded by BASE64.
名称：O:必须设置为“PRes”内容：M:此字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET PRes消息，由BASE64编码。
(1) PayReceiptPackagedContents
(1) PayReceiptPackagedContents
The Parameters of PayReceiptPackagedContent are as follows:
PayReceiptPackagedContent的参数如下：
Name : O : This MUST be set "PRes" Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET PRes message which is encoded by BASE64.
名称：O:必须设置为“PRes”内容：M:此字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET PRes消息，由BASE64编码。
(2) Get the current status information
(2) 获取当前状态信息
SET Related Module gets out the following element from Data Base using ConsumerPayId, PaymentHandlerPayId as keys.
SET-Related模块使用ConsumerPayId、PaymentHandlerPayId作为键从数据库中获取以下元素。
o BrandId o ProtocolBrandId o PayInstrumentId o Amount o CurrCodeType o CurrCode o PayDirection
o BrandId o协议BrandId o付款工具ID o金额o货币代码类型o货币代码o付款方向
(3) Get the SET Data
(3) 获取集合数据
SET Related Module gets the following data from SET PRes message which take as the Request Message.
SET相关模块从SET PRes消息中获取以下数据，该消息作为请求消息。
(a) Date Field in the MessageWrapper Date field between SET and IOTP is slightly different. The different things are as follows:
(a) SET和IOTP之间的MessageWrapper日期字段中的日期字段略有不同。不同之处如下：
o There is no TimeZone in the Date field of SET.
o 集合的日期字段中没有时区。
o Second and Milli-second can be omitted in the Date field of SET
o 在集合的日期字段中可以省略秒和毫秒
Therefore, SET Related Module needs to compensate the Date information when TimeStamp field is set.
因此，设置时间戳字段时，设置相关模块需要对日期信息进行补偿。
(b) AuthRatio in SET PRes message. (CapRatio is high priority than AuthRatio if available.)
(b) SET PRes消息中的AuthRatio。（如果可用，CapRatio的优先级高于AuthRatio。）
(c) LID_M in SET PRes message. (The style of this value is the same as it of SET Initiation message.)
(c) 设置压力信息中的盖子。（此值的样式与设置启动消息的样式相同。）
In SET/IOTP, SET Inquiry Initiation is not supported (i.e., omitted). SET Inquiry Messages are embedded in the PaySchemeData element in IOTP Inquiry Messages.
在SET/IOTP中，不支持SET查询启动（即省略）。设置查询消息嵌入IOTP查询消息中的PaySchemeData元素中。
The Parameters of PaySchemePackagedContent in StartPaymentInquiryResponse are follows:
StartPaymentQueryResponse中PaySchemePackagedContent的参数如下：
Name : O : This is not used in the SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET InqReq message which is encoded by BASE64.
名称：O：这不在SET/IOTP中使用。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET InqReq消息，由BASE64编码。
The Parameters of PaySchemePackagedContent in InqurePaymentStatus are follows:
InQuReturnmentStatus中PaySchemePackagedContent的参数如下：
Name : O : This is not used in the SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET InqReq message which is encoded by BASE64.
名称：O：这不在SET/IOTP中使用。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET InqReq消息，由BASE64编码。
The Parameters of PaySchemePackagedContent in InquirePaymentStatusResponse are follows:
InquirePaymentStatusResponse中PaySchemePackagedContent的参数如下：
Name : O : This is not used in the SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET InqRes message which is encoded by BASE64.
名称：O：这不在SET/IOTP中使用。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET InqRes消息，由BASE64编码。
The Parameter of PaySchemePackagedContent in ContinueProcess are follows:
ContinueProcess中PaySchemePackagedContent的参数如下：
Name : O : This is not used in the SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET InqRes message which is encoded by BASE64.
名称：O：这不在SET/IOTP中使用。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M:SET InqRes消息，由BASE64编码。
The Parameter of PaySchemePackagedContent in RequmePaymentConsumerResponse are as follows:
RequimePaymentConsumerResponse中PaySchemePackagedContent的参数如下：
Name : O : This is not used in the SET/IOTP. Content : M : This field should be set to "PCDATA". Transform : M : This must be set "BASE64". ContentData : M : SET Related Message which is encoded by BASE64 (e.g., SET PinitRes message or SET Initiation Response Message).
名称：O：这不在SET/IOTP中使用。内容：M：该字段应设置为“PCDATA”。转换：M：必须将其设置为“BASE64”。ContentData:M：设置相关消息，由BASE64编码（例如，设置PinitRes消息或设置启动响应消息）。
IOTP authentication, which uses the SET Scheme, is not used in SET/IOTP.
使用SET方案的IOTP身份验证未在SET/IOTP中使用。
No Status ----> InProgress : When StartPaymentConsumer Function
is called
No Status ----> InProgress : When StartPaymentConsumer Function
is called
InProgress ---> InProgress : When ContinueProcess Function
is called
: When ChangeProcessState Function
(ProcessState="Failed") is called
InProgress ---> InProgress : When ContinueProcess Function
is called
: When ChangeProcessState Function
(ProcessState="Failed") is called
InProgress ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called
: The Technical Error (Hard Error)
is occurred in SET Bridge
InProgress ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called
: The Technical Error (Hard Error)
is occurred in SET Bridge
InProgress ---> CompletedOK : When ChangeProcessState Function
(ProcessState="CompletedOK") is
called
InProgress ---> CompletedOK : When ChangeProcessState Function
(ProcessState="CompletedOK") is
called
InProgress ---> Failed : When ChangeProcessState Function
(ProcessState="failed") is called
: The Business Error is occurred
in SET Bridge
InProgress ---> Failed : When ChangeProcessState Function
(ProcessState="failed") is called
: The Business Error is occurred
in SET Bridge
InProgress ---> Suspended : When ChangeProcessState Function
(ProcessState="Suspended") is
called
: ErrorCode="ResumeRequired" is
is occurred.
InProgress ---> Suspended : When ChangeProcessState Function
(ProcessState="Suspended") is
called
: ErrorCode="ResumeRequired" is
is occurred.
Suspend ---> InProgress : ResumePaymentConsumer Function
is called
Suspend ---> InProgress : ResumePaymentConsumer Function
is called
Suspend ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called (the Technical Error is
occurred prior to ResumePayment-
Consumer Function call)
: The Technical Error (Hard Error)
is occurred in SET Bridge (the
Technical Error is occurred while
ResumePaymentConsumer is calling)
Suspend ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called (the Technical Error is
occurred prior to ResumePayment-
Consumer Function call)
: The Technical Error (Hard Error)
is occurred in SET Bridge (the
Technical Error is occurred while
ResumePaymentConsumer is calling)
No Status ----> InProgress : When StartPaymentPaymentHandler
is called
No Status ----> InProgress : When StartPaymentPaymentHandler
is called
InProgress ---> InProgress : When ContinueProcess Function
is called
: When ChangeProcessState Function
(ProcessState="Failed") is called
InProgress ---> InProgress : When ContinueProcess Function
is called
: When ChangeProcessState Function
(ProcessState="Failed") is called
InProgress ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called
: The Technical Error (Hard Error)
is occurred in SET Bridge
: SET Error Message is occurred
InProgress ---> ProcessError : When ChangeProcessState Function
(ProcessState="ProcessError") is
called
: The Technical Error (Hard Error)
is occurred in SET Bridge
: SET Error Message is occurred
InProgress ---> CompletedOK : When SET Transaction is completed.
InProgress ---> CompletedOK : When SET Transaction is completed.
InProgress ---> Failed : When ChangeProcessState Function
(ProcessState="failed") is called
: The Business Error is occurred
in SET Bridge
InProgress ---> Failed : When ChangeProcessState Function
(ProcessState="failed") is called
: The Business Error is occurred
in SET Bridge
CompletedOK ---> Failed : When ChangeProcessState Function
or CancelPayment Function
(ProcessState="Failed") is called
and the payment is cancelled.
CompletedOK ---> Failed : When ChangeProcessState Function
or CancelPayment Function
(ProcessState="Failed") is called
and the payment is cancelled.
SET/IOTP recommends the following regarding Delivery:
SET/IOTP就交付提出以下建议：
Physical Goods
--------------
For physical goods, the IOTP Delivery Exchanges should be omitted.
That is, set DelivExch=False and DelivAndPayResp=False in the
Delivery Component. This is to avoid the situation where the IOTP
Delivery Handler must check with the IOTP Payment Handler on the
status of a credit authorization. When a Delivery Inquiry
transaction might occur, the DelivReqNetLocn attribute in the
DeliveryData Element must have been specified at the time of the
original Offer Response Message. If you want to use the Delivery
Exchange, you need to process the inquiry of the credit authorization
out of IOTP between IOTP Payment Handler and Delivery Handler.
Physical Goods
--------------
For physical goods, the IOTP Delivery Exchanges should be omitted.
That is, set DelivExch=False and DelivAndPayResp=False in the
Delivery Component. This is to avoid the situation where the IOTP
Delivery Handler must check with the IOTP Payment Handler on the
status of a credit authorization. When a Delivery Inquiry
transaction might occur, the DelivReqNetLocn attribute in the
DeliveryData Element must have been specified at the time of the
original Offer Response Message. If you want to use the Delivery
Exchange, you need to process the inquiry of the credit authorization
out of IOTP between IOTP Payment Handler and Delivery Handler.
Digital Goods
-------------
For digital goods sold through SET/IOTP, authorization should be
processed on a real-time basis.
Digital Goods
-------------
For digital goods sold through SET/IOTP, authorization should be
processed on a real-time basis.
In SET/IOTP, the CompletionCode, which is a Business Error Code, is set as follows:
在SET/IOTP中，CompletionCode是一个业务错误代码，设置如下：
Value Description
------------------------------------------------------
BrandNotSupp This value is not used.
CurrNotSupp This value is not used.
AuthError The IOTP Authentication has
failed for any reason.
InsuffFunds This value is not used.
InstBrandInvalid This value is not used.
PaymentDecl A SET business failure has occurred.
InstNotValid This value is not used.
BadInstrument This value is not used.
Unspecified Unspecified error. There is some known
problem or error, which does not fall
into one of the other CompletionCodes.
Value Description
------------------------------------------------------
BrandNotSupp This value is not used.
CurrNotSupp This value is not used.
AuthError The IOTP Authentication has
failed for any reason.
InsuffFunds This value is not used.
InstBrandInvalid This value is not used.
PaymentDecl A SET business failure has occurred.
InstNotValid This value is not used.
BadInstrument This value is not used.
Unspecified Unspecified error. There is some known
problem or error, which does not fall
into one of the other CompletionCodes.
This document recommends to set the PercentComplete as follows:
本文件建议按如下方式设置完成百分比：
SET Related Setting for Setting for Value of
Message Consumer Paymnet Handler PercentComplete
------------+---------------+------------------+-----------------
SET Initia- |After 1st SET |After 1st SET |20
tion |Initiation |Initiation |
|Response has |Response has |
|Cteated |Processed |
|(See Note) |(See Note) |
------------+---------------+------------------+----------------
SET PinitReq|After Created |After Processed |40
------------+---------------+------------------+----------------
SET PinitRes|After Processed|After Created |60
------------+---------------+------------------+----------------
SET PReq |After Created |After Processed |80
------------+---------------+------------------+----------------
SET PRes |After Processed|After Created |100
------------+---------------+------------------+----------------
SET Related Setting for Setting for Value of
Message Consumer Paymnet Handler PercentComplete
------------+---------------+------------------+-----------------
SET Initia- |After 1st SET |After 1st SET |20
tion |Initiation |Initiation |
|Response has |Response has |
|Cteated |Processed |
|(See Note) |(See Note) |
------------+---------------+------------------+----------------
SET PinitReq|After Created |After Processed |40
------------+---------------+------------------+----------------
SET PinitRes|After Processed|After Created |60
------------+---------------+------------------+----------------
SET PReq |After Created |After Processed |80
------------+---------------+------------------+----------------
SET PRes |After Processed|After Created |100
------------+---------------+------------------+----------------
Note: According to the SET Initiation, PercentComplete should be set "20" at the timing of 1st SET Initiation Response is created/processed because number of its message is variable.
注：根据集合启动，应在创建/处理第一个集合启动响应时将PercentComplete设置为“20”，因为其消息的数量是可变的。
In the current version of SET/IOTP, if a technical error occurs in the SET Bridge, the Severity has to be always set to "HardError".
在当前版本的SET/IOTP中，如果SET桥接器中发生技术错误，则严重性必须始终设置为“HardError”。
This chapter describes types of handling Errors.
本章介绍处理错误的类型。
SET/IOTP defines the following error types:
SET/IOTP定义了以下错误类型：
(1) IOTP Level Error
(1) IOTP电平错误
This is defined as an error which is NOT specified in [SET EIG] nor [SET]. IOTP Level Errors are divided into two types according to the following:
这被定义为[SET EIG]或[SET]中未指定的错误。IOTP级别错误根据以下内容分为两种类型：
OAC Level Error: Error in the OAC. This error is defined in the [IOTP].
OAC级别错误：OAC中的错误。此错误在[IOTP]中定义。
SET Related Module Level Error: Error generated in by process on the SET Related Module, not specified in [SET EIG] nor [SET]. For example, when checking the consistency between SET and IOTP elements on SET Related Module, an error might be returned to OAC.
集合相关模块级错误：进程在集合相关模块上生成的错误，未在[SET EIG]或[SET]中指定。例如，在检查集合相关模块上集合和IOTP元素之间的一致性时，可能会向OAC返回错误。
(2) SET Level Error
(2) 设置级别错误
This is defined as an error which is specified in [SET EIG] or [SET]. SET Level Errors have been divided into two types of error according to following:
这被定义为[SET EIG]或[SET]中指定的错误。设置级别错误根据以下内容分为两种类型：
SET Technical Level Error: Error in the SET Related Module. This error is defined in [SET] or [SET EIG]. SET Technical Level Errors are further subdivided into two types of errors:
设置技术级别错误：设置相关模块中的错误。此错误在[SET]或[SET EIG]中定义。SET技术级错误进一步细分为两种类型的错误：
(a) SET Initiation Error Error while the SET Initiation Process is in progress.
(a) 设置初始化过程正在进行时，设置初始化错误。
(b) SET Transaction Error Error when the SET Transaction (SET PInitReq message, SET PReq message, etc.) is in progress.
(b) SET Transaction Error当SET事务（SET PInitReq消息、SET PReq消息等）正在进行时出错。
SET Business Level Error: Error when a business error (e.g., an authorization failure) occurs while the SET Transaction is being processed. In SET, Business Level Errors will be returned in the SET PRes message. SET does not use a SET Error Message for this type of error. However, it is necessary to present the OAC with what kind of SET Business Error has occurred.
设置业务级别错误：在处理设置事务时发生业务错误（例如授权失败）时发生的错误。在SET中，业务级错误将在SET PRes消息中返回。SET不对此类错误使用SET错误消息。但是，有必要向OAC说明发生了何种SET业务错误。
In this below, the details of each errors above are described.
在下文中，描述了上述每个错误的详细信息。
When OAC Level Errors have occurred, if necessary, the sender and receiver must issue ChangeProcessState API and change the status. For the detail of these errors, see [IOTP].
发生OAC级别错误时，如果需要，发送方和接收方必须发出ChangeProcessState API并更改状态。有关这些错误的详细信息，请参见[IOTP]。
This is the error generated in a process on the SET Related Module, not specified in [SET EIG] nor [SET]. For example, when checking the inconsistency between SET and IOTP elements on SET Related Module, it might cause an error. This error should be notified to OAC.
这是在SET相关模块的过程中产生的错误，在[SET EIG]或[SET]中未指定。例如，在检查集合相关模块上集合和IOTP元素之间的不一致性时，可能会导致错误。此错误应通知OAC。
In this case, as a response message, Payment Scheme Data is not returned. An appropriate information must be set to Status Response.
在这种情况下，作为响应消息，不会返回支付方案数据。必须将适当的信息设置为状态响应。
There are two SET Initiation errors as follows:
有两个集合启动错误，如下所示：
o Error generated in SET Initiation Message
o 集合启动消息中生成错误
o Error generated in SET Initiation Response Message.
o 设置启动响应消息中生成错误。
(1) SET Initiation Message Error
(1) 设置启动消息错误
[SET EIG] describes the error handling when a problem rises in SET Initiation Message. So the Consumer will do the same error handling in 9.4.2.
[SET EIG]描述在SET启动消息中出现问题时的错误处理。因此，消费者将执行9.4.2中相同的错误处理。
When SET Initiation Error rises in 1st Initiation Message, an error message will be returned to the Merchant. If an error occurs after 2nd Initiation Message, an error message will be returned to the Payment Handler. SET Initiation Response will be generated having SET-Error-Field in Response Message Header and will be returned ErrorCode as "PayEncapError" and Severity as "HardError".
当第一条启动消息中出现设置启动错误时，将向商户返回一条错误消息。如果在第二次启动消息之后发生错误，则将向支付处理程序返回错误消息。将在响应消息头中设置错误字段后生成设置启动响应，并将错误代码返回为“PayEncapError”，严重性返回为“HardError”。
(a) SET Initiation Response Error
(a) 设置启动响应错误
In SET EIG, there is no description about the handling on the problems in SET Initiation Response. However, it is necessary to define some handling for the problems in SET/IOTP
SET EIG中没有关于SET初始化响应中问题处理的说明。但是，有必要为SET/IOTP中的问题定义一些处理方法
(b) Process of Payment Handler
(b) 付款处理程序
When a problem rises in SET Initiation Response, SET Related Module generates ErrorResponse, which is included the "EnCapProtoErr" as ErrorCode and the "HardError" as Severity. But PaySchemePackagedContent is not included in this API.
当SET启动响应中出现问题时，SET相关模块会生成ErrorResponse，其中“EnCapProtoErr”为错误代码，“HardError”为严重性。但此API中不包括PaySchemePackagedContent。
(2) Process of Consumer
(2) 消费过程
ChangeProcessState API must be issued, and ProcessState must be modified.
必须发布ChangeProcessState API，并且必须修改ProcessState。
(1) Process of Sender
(1) 发送程序
When a SET Transaction Error rises, SET Core creates SET Error Message. Then the SET Related Module creates ErrorResponse Message which includes "HardError" as Severity, "EnCapProtoErr" as ErrorCode and PaySchemePackagedContent. The SET Bridge passes the ErrorResponse Message to OAC. OAC will generate an Error Block which includes PaySchemePackagedContent and sends it to the Receiver side.
当SET事务错误出现时，SET Core将创建SET错误消息。然后，集合相关模块创建ErrorResponse消息，该消息包括“HardError”作为严重性，“EncapProtoError”作为ErrorCode和PaySchemePackagedContent。SET桥接器将ErrorResponse消息传递给OAC。OAC将生成一个包含PaySchemePackagedContent的错误块，并将其发送到接收方。
(2) Process of Receiver
(2) 接收过程
With ContinueProcess API, receiver's OAC sends the message including the PaySchemeData to SET Bridge. SET Bridge passes the SET Error Message to SET Core for this process. After that, SET Bridge sends "End" status with ContinueProcessResponse API.
使用ContinueProcess API，接收方的OAC将包含PaySchemeData的消息发送到SET Bridge。SET Bridge将SET错误消息传递给此进程的SET Core。之后，SET桥接器使用ContinueProcessResponse API发送“结束”状态。
(1) Process of Payment Handler
(1) 付款处理程序
SET Related Module checks the SET Business Error in StatusCode in SET PRes message. When SET Transaction Error occurs, SET Related Module creates ErrorResponse Message which is included SET PRes as PaySchemePackagedContent and ErrorCode as "BusinessError" and returns it to OAC. OAC creates Payment Response Block after gets the SET scheme specific receipt in InquireProcessState/Response, and sends it to the Consumer.
SET相关模块检查SET PRes消息中状态码中的SET业务错误。当发生SET事务错误时，SET相关模块创建错误响应消息，该消息包括SET PRes作为PaySchemePackagedContent和ErrorCode作为“BusinessError”并返回给OAC。OAC在InquireProcessState/Response中获取设置的方案特定收据后创建付款响应块，并将其发送给消费者。
(2) Process of Consumer
(2) 消费过程
SET Related Module conducts the same process as in the process that Consumer receives Payment Response Block.
设置相关模块执行的流程与消费者接收支付响应块的流程相同。
In the IOTP, Merchant and Payment Handler may exist in different domains. So, if the Merchant passes the payment related information to the Payment Handler via the Consumer, the payment security level may depend on the IOTP. If you want to avoid this, you will need to check integrity of these data by using out-of-band communication between the Merchant and the Payment Handler. In this case, the security level depends on the communication path between them.
在IOTP中，商户和支付处理人可能存在于不同的域中。因此，如果商户通过消费者将支付相关信息传递给支付处理程序，则支付安全级别可能取决于IOTP。如果要避免这种情况，您需要使用商户和支付处理程序之间的带外通信来检查这些数据的完整性。在这种情况下，安全级别取决于它们之间的通信路径。
The following books provide essential background material. Readers are strongly encouraged to consult these references for more information.
以下书籍提供了基本的背景资料。强烈建议读者查阅这些参考资料以了解更多信息。
[BASE64] Base64 Content-Transfer-Encoding. A method of transporting binary data defined by MIME. See: RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N.Borenstein. November 1996.
[BASE64]BASE64内容传输编码。一种传输MIME定义的二进制数据的方法。请参阅：RFC 2045：多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式。弗里德和博伦斯坦。1996年11月。
[RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP, Version 1.0", RFC 2081, April 2000.
[RFC 2801]Burdett，D.，“互联网开放交易协议-IOTP，1.0版”，RFC 2081，2000年4月。
[SET] SET Secure Electronic Transaction (TM) , Version 1.0, May 31, 1997 Book 1: Business Description Book 2: Programmer's Guide Book 3: Formal Protocol Definition
[SET]SET-Secure Electronic Transaction（TM），1.0版，1997年5月31日第1册：业务描述第2册：程序员指南第3册：正式协议定义
[SET EIG] External Interface Guide to SET Secure Electronic Transaction, Sep 24, 1997.
[SET EIG]设置安全电子交易的外部接口指南，1997年9月24日。
[SJR] "SET Secure Electronic Transaction Specification" Support for Japanese Requirements, Mar 16, 1998.
[SJR]“设置安全电子交易规范”对日本要求的支持，1998年3月16日。
[IOTP Payment API] Hans, W., et al., "Payment API for v1.0 Internet Open Trading Protocol (IOTP)", Work in Progress.
[IOTP支付API]Hans，W.等人，“v1.0互联网开放交易协议（IOTP）的支付API”，正在进行中。
[ISO4217] ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.
[ISO4217]ISO 4217：表示货币的代码。可从ANSI或ISO获得。
[XML] Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.
[XML]可扩展标记语言。W3C建议。看见http://www.w3.org/TR/1998/REC-xml-19980210 1998年2月10日的版本。
This document does not ask for any action from IANA. It references an existing registry, iotp-codes, where at the time of publication of this RFC the following BrandID's are registered:
本文件不要求IANA采取任何行动。它引用了一个现有的注册表iotp代码，在发布本RFC时，注册了以下BrandID：
Amex, Dankort, JCB, Maestro, MasterCard, MICOS, VISA, atCredits, EZpay, GeldKarte, Mondex, paybox
美国运通、丹科特、JCB、迈斯卓、万事达卡、MICOS、VISA、atCredits、EZpay、GeldKarte、Mondex、paybox
The author of this document appreciates the following contributors to this protocol (in alphabetic order of company) without which it could not have been developed.
本文件的作者感谢本协议的以下贡献者（按公司字母顺序排列），如果没有这些贡献者，本协议将无法制定。
Andrew Drapp Hitachi Europe, Ltd.
安德鲁·德拉普日立欧洲有限公司。
David Burdett Commerce One (ex. Mondex International)
David Burdett Commerce One（前Mondex International）
Donald Eastlake 3rd Motorola (ex. IBM)
唐纳德·伊斯特莱克第三摩托罗拉公司（前IBM）
Hans-Bernhard Beykirch SIZ
汉斯·伯恩哈德·贝基奇·西兹
John Wankmuller MasterCard International
约翰·旺克穆勒万事达卡国际有限公司
Mark Linehan IBM
Mark Linehan IBM
Richad D. Brown Kedemon (ex. Globe SET)
Richad D.Brown Kedemon（前全球套装）
Werner Hans SIZ
沃纳·汉斯·西兹
Yoshiaki Kawatsura Hitachi, Ltd. 890 Kashimada Saiwai-ku Kawasaki-shi Kanagawa, 212-8567 Japan
日本Kashimada Saiwai ku Kawasaki shi Kanagawa Kawaki Kawatsura Hitachi有限公司890号，邮编212-8567
EMail: kawatura@bisd.hitachi.co.jp
EMail: kawatura@bisd.hitachi.co.jp
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。