Network Working Group Y. Kawatsura
Request for Comments: 3867 Hitachi
Category: Informational M. Hiroya
Technoinfo Service
H. Beykirch
Atos Origin
November 2004
Network Working Group Y. Kawatsura
Request for Comments: 3867 Hitachi
Category: Informational M. Hiroya
Technoinfo Service
H. Beykirch
Atos Origin
November 2004
Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP)
1.0版互联网开放交易协议（IOTP）的支付应用程序编程接口（API）
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.
互联网开放交易协议（IOTP）为交易目的提供了数据交换格式，同时无缝集成了现有的纯支付协议。这推动了多层系统架构的发展，该架构至少由一些通用的IOTP应用核心和多个特定的支付模块组成。
This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.
本文档介绍了IOTP应用核心和支付模块之间的通用接口，实现了这些模块之间的互操作性。此外，这种接口为IOTP应用核心的实际实现中的插件机制提供了基础。
Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems.
此类接口存在于消费者、商家和支付处理程序的安装处，连接IOTP应用程序核心和支付软件组件/遗留系统。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General payment phases . . . . . . . . . . . . . . . . . 5
1.2. Assumptions. . . . . . . . . . . . . . . . . . . . . . . 6
2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Authentication Documentation Exchange. . . . . . . . . . 15
2.2. Brand Compilation. . . . . . . . . . . . . . . . . . . . 17
2.3. Brand Selection. . . . . . . . . . . . . . . . . . . . . 21
2.4. Successful Payment . . . . . . . . . . . . . . . . . . . 24
2.5. Payment Inquiry. . . . . . . . . . . . . . . . . . . . . 29
2.6. Abnormal Transaction Processing. . . . . . . . . . . . . 30
2.6.1. Failures and Cancellations . . . . . . . . . . . 30
2.6.2. Resumption . . . . . . . . . . . . . . . . . . . 32
2.7. IOTP Wallet Initialization . . . . . . . . . . . . . . . 33
2.8. Payment Software Management. . . . . . . . . . . . . . . 34
3. Mutuality. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1. Error Codes. . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Attributes and Elements. . . . . . . . . . . . . . . . . 48
3.3. Process States . . . . . . . . . . . . . . . . . . . . . 61
3.3.1. Merchant . . . . . . . . . . . . . . . . . . . . 61
3.3.2. Consumer . . . . . . . . . . . . . . . . . . . . 63
3.3.3. Payment Handler. . . . . . . . . . . . . . . . . 65
4. Payment API Calls. . . . . . . . . . . . . . . . . . . . . . . 66
4.1. Brand Compilation Related API Calls. . . . . . . . . . . 66
4.1.1. Find Accepted Payment Brand. . . . . . . . . . . 66
4.1.2. Find Accepted Payment Protocol . . . . . . . . . 68
4.1.3. Get Payment Initialization Data. . . . . . . . . 70
4.1.4. Inquire Authentication Challenge . . . . . . . . 72
4.1.5. Authenticate . . . . . . . . . . . . . . . . . . 73
4.1.6. Check Authentication Response. . . . . . . . . . 74
4.2. Brand Selection Related API Calls. . . . . . . . . . . . 76
4.2.1. Find Payment Instrument. . . . . . . . . . . . . 76
4.2.2. Check Payment Possibility. . . . . . . . . . . . 78
4.3. Payment Transaction Related API calls. . . . . . . . . . 80
4.3.1. Start Payment Consumer . . . . . . . . . . . . . 80
4.3.2. Start Payment Payment Handler. . . . . . . . . . 82
4.3.3. Resume Payment Consumer. . . . . . . . . . . . . 84
4.3.4. Resume Payment Payment Handler . . . . . . . . . 85
4.3.5. Continue Process . . . . . . . . . . . . . . . . 86
4.3.6. Change Process State . . . . . . . . . . . . . . 88
4.4. General Inquiry API Calls. . . . . . . . . . . . . . . . 89
4.4.1. Remove Payment Log . . . . . . . . . . . . . . . 90
4.4.2. Payment Instrument Inquiry . . . . . . . . . . . 90
4.4.3. Inquire Pending Payment. . . . . . . . . . . . . 92
4.5. Payment Related Inquiry API Calls. . . . . . . . . . . . 93
4.5.1. Check Payment Receipt. . . . . . . . . . . . . . 93
4.5.2. Expand Payment Receipt . . . . . . . . . . . . . 94
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General payment phases . . . . . . . . . . . . . . . . . 5
1.2. Assumptions. . . . . . . . . . . . . . . . . . . . . . . 6
2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Authentication Documentation Exchange. . . . . . . . . . 15
2.2. Brand Compilation. . . . . . . . . . . . . . . . . . . . 17
2.3. Brand Selection. . . . . . . . . . . . . . . . . . . . . 21
2.4. Successful Payment . . . . . . . . . . . . . . . . . . . 24
2.5. Payment Inquiry. . . . . . . . . . . . . . . . . . . . . 29
2.6. Abnormal Transaction Processing. . . . . . . . . . . . . 30
2.6.1. Failures and Cancellations . . . . . . . . . . . 30
2.6.2. Resumption . . . . . . . . . . . . . . . . . . . 32
2.7. IOTP Wallet Initialization . . . . . . . . . . . . . . . 33
2.8. Payment Software Management. . . . . . . . . . . . . . . 34
3. Mutuality. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1. Error Codes. . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Attributes and Elements. . . . . . . . . . . . . . . . . 48
3.3. Process States . . . . . . . . . . . . . . . . . . . . . 61
3.3.1. Merchant . . . . . . . . . . . . . . . . . . . . 61
3.3.2. Consumer . . . . . . . . . . . . . . . . . . . . 63
3.3.3. Payment Handler. . . . . . . . . . . . . . . . . 65
4. Payment API Calls. . . . . . . . . . . . . . . . . . . . . . . 66
4.1. Brand Compilation Related API Calls. . . . . . . . . . . 66
4.1.1. Find Accepted Payment Brand. . . . . . . . . . . 66
4.1.2. Find Accepted Payment Protocol . . . . . . . . . 68
4.1.3. Get Payment Initialization Data. . . . . . . . . 70
4.1.4. Inquire Authentication Challenge . . . . . . . . 72
4.1.5. Authenticate . . . . . . . . . . . . . . . . . . 73
4.1.6. Check Authentication Response. . . . . . . . . . 74
4.2. Brand Selection Related API Calls. . . . . . . . . . . . 76
4.2.1. Find Payment Instrument. . . . . . . . . . . . . 76
4.2.2. Check Payment Possibility. . . . . . . . . . . . 78
4.3. Payment Transaction Related API calls. . . . . . . . . . 80
4.3.1. Start Payment Consumer . . . . . . . . . . . . . 80
4.3.2. Start Payment Payment Handler. . . . . . . . . . 82
4.3.3. Resume Payment Consumer. . . . . . . . . . . . . 84
4.3.4. Resume Payment Payment Handler . . . . . . . . . 85
4.3.5. Continue Process . . . . . . . . . . . . . . . . 86
4.3.6. Change Process State . . . . . . . . . . . . . . 88
4.4. General Inquiry API Calls. . . . . . . . . . . . . . . . 89
4.4.1. Remove Payment Log . . . . . . . . . . . . . . . 90
4.4.2. Payment Instrument Inquiry . . . . . . . . . . . 90
4.4.3. Inquire Pending Payment. . . . . . . . . . . . . 92
4.5. Payment Related Inquiry API Calls. . . . . . . . . . . . 93
4.5.1. Check Payment Receipt. . . . . . . . . . . . . . 93
4.5.2. Expand Payment Receipt . . . . . . . . . . . . . 94
4.5.3. Inquire Process State. . . . . . . . . . . . . . 96
4.5.4. Start Payment Inquiry. . . . . . . . . . . . . . 97
4.5.5. Inquire Payment Status . . . . . . . . . . . . . 98
4.6. Other API Calls. . . . . . . . . . . . . . . . . . . . . 99
4.6.1. Manage Payment Software. . . . . . . . . . . . . 99
5. Call Back Function . . . . . . . . . . . . . . . . . . . . . .101
6. Security Considerations. . . . . . . . . . . . . . . . . . . .103
7. References . . . . . . . . . . . . . . . . . . . . . . . . . .103
7.1. Normative References . . . . . . . . . . . . . . . . . .103
7.2. Informative References . . . . . . . . . . . . . . . . .104
Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . . .105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .105
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .106
4.5.3. Inquire Process State. . . . . . . . . . . . . . 96
4.5.4. Start Payment Inquiry. . . . . . . . . . . . . . 97
4.5.5. Inquire Payment Status . . . . . . . . . . . . . 98
4.6. Other API Calls. . . . . . . . . . . . . . . . . . . . . 99
4.6.1. Manage Payment Software. . . . . . . . . . . . . 99
5. Call Back Function . . . . . . . . . . . . . . . . . . . . . .101
6. Security Considerations. . . . . . . . . . . . . . . . . . . .103
7. References . . . . . . . . . . . . . . . . . . . . . . . . . .103
7.1. Normative References . . . . . . . . . . . . . . . . . .103
7.2. Informative References . . . . . . . . . . . . . . . . .104
Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . . .105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .105
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .106
Common network technologies are based on standardized and established Internet technologies. The Internet technologies provide mechanisms and tools for presentation, application development, network infrastructure, security, and basic data exchange.
通用网络技术基于标准化和成熟的互联网技术。互联网技术为演示、应用程序开发、网络基础设施、安全和基础数据交换提供了机制和工具。
Due to the presence of already installed trading roles' systems with their own interfaces (Internet shop, order management, payment, billing, and delivery management systems, or financial institute's legacy systems), IOTP has been limited to the common external interface over the Internet. However, some of these internal interfaces might be also standardized for better integration of IOTP aware components with of the existing infrastructure and its cost effective reuse. For more information on IOTP, see [IOTP] and [IOTPBOOK].
由于存在已安装的交易角色系统及其自己的接口（网店、订单管理、支付、计费和交付管理系统或金融机构的遗留系统），IOTP仅限于互联网上的公共外部接口。然而，这些内部接口中的一些也可能被标准化，以便更好地将支持IOTP的组件与现有基础设施的集成及其经济高效的重用。有关IOTP的更多信息，请参阅[IOTP]和[IoTPook]。
The typical Payment Handlers (i.e., financial institutes or near-bank organizations) as well as Merchants require an IOTP aware application that easily fits into their existing financial infrastructure. The Payment Handler might even insist on the reuse of special in-house solutions for some subtasks of the IOTP aware application, e.g., reflecting their cryptography modules, gateway interfaces, or physical environment. Therefore, their IOTP aware implementation really requires such clear internal interfaces.
典型的支付处理机构（即金融机构或银行附近的组织）以及商户需要一个能够轻松融入其现有金融基础设施的IOTP感知应用程序。支付处理程序甚至可能坚持对IOTP感知应用程序的某些子任务重用特殊的内部解决方案，例如，反映其加密模块、网关接口或物理环境。因此，他们的IOTP感知实现确实需要如此清晰的内部接口。
More important, consumers demand modularization and clear internal interfaces: Their IOTP application aims at the support of multiple payment methods. Consumers prefer the flexible use of different seamless integrating payment methods within one trading application with nearly identical behavior and user interface. The existence of a well-defined interface enables payment software developers to bolt on their components to other developer's general IOTP Application Core.
更重要的是，消费者要求模块化和清晰的内部接口：他们的物联网应用旨在支持多种支付方式。消费者更喜欢在一个交易应用程序中灵活使用不同的无缝集成支付方法，其行为和用户界面几乎相同。定义良好的接口使支付软件开发人员能够将其组件连接到其他开发人员的通用IOTP应用程序核心。
Initially, this consideration leads to the two-level layered view of the IOTP software for each role, consisting of:
最初，考虑到这一点，每个角色的IOTP软件都有两个层次的视图，包括：
o some generic IOTP system component, the so-called IOTP application core - providing IOTP based gateway services and generic business logic and
o 一些通用的IOTP系统组件，即所谓的IOTP应用程序核心-提供基于IOTP的网关服务和通用业务逻辑和
o the trading roles' specific back-end systems implementing the specific trading transaction types' functionality.
o 交易角色的特定后端系统实现特定交易类型的功能。
In order to isolate the changes on the infrastructure, the IOTP trading application has been three-layered:
为了隔离基础设施上的变化，IOTP交易应用程序分为三层：
o the IOTP Application Core processes the generic parts of the IOTP transaction and holds the connection to the Internet,
o IOTP应用核心处理IOTP事务的通用部分，并保持与互联网的连接，
o the Existing Legacy System or Existing Payment Software which processes the actual transaction type, and particular payment transaction, and
o 处理实际交易类型和特定支付交易的现有遗留系统或现有支付软件，以及
o the IOTP Middle-ware or IOTP Payment Bridge which glues the other two possibly incompatible components. It brokers between the specific interface of the Existing Legacy System and the standardized interfaces of the IOTP Application Core.
o 将其他两个可能不兼容的组件粘合在一起的IOTP中间件或IOTP支付桥。它在现有遗留系统的特定接口和IOTP应用核心的标准化接口之间进行代理。
As IOTP extends payment schemes to a trading scheme, primarily, this document focuses on payment modules, i.e., the interface between the IOTP Payment Bridge and the IOTP Application Core. It provides a standard method for exchanging payment protocol messages between the parties involved in a payment. But, it does not specify any interface for order or delivery processing.
由于IOTP将支付方案扩展为交易方案，本文件主要关注支付模块，即IOTP支付桥和IOTP应用核心之间的接口。它为参与支付的各方之间交换支付协议消息提供了标准方法。但是，它没有为订单或交付处理指定任何接口。
Such a Payment Application Programmers Interface (API) must suit for a broad range of payment methods: (1) software based like Credit Card SET or CyberCoin, (2) chip card based like Mondex or GeldKarte, and (3) mimicries of typical and traditional payment methods like money transfer, direct debit, deposit, withdrawal, money exchange and value points. It should support both payments with explicit consumer acknowledge and automatic repeated payments, which have been consumer approved in advance. For more information on SET, see [SET].
这种支付应用程序编程接口（API）必须适用于广泛的支付方式：（1）基于软件的支付方式，如信用卡或赛博币；（2）基于芯片卡的支付方式，如Mondex或Geldkart；（3）模仿典型和传统的支付方式，如转账、直接借记、存款、取款，货币兑换和价值点。它应该支持带有明确消费者确认的支付和自动重复支付，这两种支付都是消费者事先批准的。有关SET的详细信息，请参见[SET]。
The following discussion focuses on the Consumer's point of view and uses the associated terminology. When switching to Merchants' or Delivery Handlers' IOTP aware applications, the payment related components should be implicitly renamed by Existing Legacy Systems to the IOTP Middle-ware.
以下讨论的重点是消费者的观点，并使用相关术语。当切换到商家或交付处理程序的IOTP感知应用程序时，与支付相关的组件应由现有遗留系统隐式重命名为IOTP中间件。
The next two sub-sections describe the general payment scenario and several assumptions about the coarsely sketched software components.
接下来的两个小节描述了一般支付场景和关于粗略绘制的软件组件的几个假设。
Section 2 illustrates the payment transaction progress and message flow of different kinds of transaction behavior. Sections 3 to 4 provide the details of the API functions and Section 5 elaborates the call back interface.
第2节说明了不同类型交易行为的支付交易进度和消息流。第3至第4节提供了API函数的详细信息，第5节详细介绍了回调接口。
The following table sketches the four logical steps of many payment schemes. The preceding agreements about the goods, payment method, purchase amount, or delivery rules are omitted.
下表概述了许多支付方案的四个逻辑步骤。上述关于货物、付款方式、采购金额或交货规则的协议被省略。
Payment State Party Example Behavior
------------- ----- ----------------
Payment State Party Example Behavior
------------- ----- ----------------
Mutual Payment Handler Generation of identification Authentication request, solvency request, or and some nonce Initialization Consumer Responses to the requests and generation of own nonce
相互支付处理程序生成身份验证请求、偿付能力请求或某些nonce初始化消费者对请求的响应，并生成自己的nonce
Authorization Payment Handler Generation of the authorization request (for consumer) Consumer Agreement to payment (by reservation of the Consumer's e-money) Payment Handler Acceptance or rejection of the agreement (consumer's authorization response), generation of the authorization request (for issuer/acquirer), and processing of its response
授权支付处理程序生成授权请求（针对消费者）消费者支付协议（通过保留消费者的电子货币）支付处理程序接受或拒绝协议（针对消费者的授权响应），生成授权请求（针对发卡机构/收单机构），并处理其响应
Capture Generation of the capture request (for issuer/acquirer) Consumer Is charged Payment Handler Acceptance or rejection of the e-money, close of the payment transaction
捕获请求的捕获生成（针对发卡机构/收单机构）消费者在支付处理程序接受或拒绝电子货币、支付交易结束时收取费用
Reversal On rejection (online/delayed): generation of the reversal data Consumer Receipt of the refund
拒绝时冲销（在线/延迟）：生成冲销数据消费者收到退款
However, some payment schemes:
然而，有些付款方案：
o limit themselves to one-sided authentication, o perform off-line authorization without any referral to any issuer/acquirer, o apply capture processing in batch mode, or o do not distinguish between authorization and capture, o lack an inbound mechanism for reversals or implement a limited variant.
o 将自身限制为单边认证，o在不向任何发卡机构/收单机构转介的情况下执行离线授权，o在批处理模式下应用捕获处理，或o不区分授权和捕获，o缺少反向输入机制或实施有限的变体。
This model applies not only to payments at the typical points of sales but extends to refunds, deposits, withdrawals, electronic cheques, direct debits, and money transfers.
该模型不仅适用于典型销售点的付款，还扩展到退款、存款、取款、电子支票、直接借记和转账。
In outline, the IOTP Payment Bridge processes some input sequence of payment protocol messages being forwarded by the IOTP Application Core. It (1) disassembles the messages, (2) maps them onto the formats of the Existing Payment Software, (3) assembles its responses, and (4) returns another sequence of payment protocol messages that is mostly intended for transparent transmission by the IOTP Application Core to some IOTP aware remote party. Normally, this process continues between the two parties until the Payment Handler's Payment API signals the payment termination. Exceptionally, each system component may signal failures.
大体上，IOTP支付网桥处理IOTP应用核心转发的支付协议消息的一些输入序列。它（1）分解消息，（2）将它们映射到现有支付软件的格式上，（3）组装其响应，以及（4）返回另一个支付协议消息序列，该序列主要用于由IOTP应用程序核心向某些IOTP感知的远程方进行透明传输。通常，此过程在双方之间继续，直到支付处理程序的支付API发出支付终止信号。例外情况下，每个系统部件都可能发出故障信号。
The relationship between the aforementioned components is illustrated in the following figure. These components might be related to each other in a flexible n-to-m-manner:
下图说明了上述组件之间的关系。这些组件可能以灵活的n到m方式相互关联：
o One IOTP Application Core may manage multiple IOTP Payment Bridges and the latter might be shared between multiple IOTP Application Cores. o Each Payment Bridge may manage multiple Existing Payment Software modules and the latter might be shared between multiple Payment Bridges. o Each Existing Payment Software may manage multiple payment schemes (e.g., SET) and the latter might be supported by multiple Existing Payment Software modules. For more information on SET see [SET].
o 一个IOTP应用核心可以管理多个IOTP支付网桥，后者可以在多个IOTP应用核心之间共享。o每个支付桥可管理多个现有支付软件模块，后者可在多个支付桥之间共享。o每个现有支付软件可管理多个支付方案（如SET），后者可由多个现有支付软件模块支持。有关SET的更多信息，请参见[SET]。
o Each payment scheme may support multiple payment instruments (e.g., particular card) or methods (e.g., Visa via SET) and the latter might be shared by multiple Existing Payment Software Components.
o 每个支付方案可支持多种支付工具（例如，特定卡）或方法（例如，Visa via via via SET），后者可由多个现有支付软件组件共享。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant)
( contains Internet ( contains
IOTP Application Core) IOTP Application Core)
^ ^
| 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)
( contains Internet ( contains
IOTP Application Core) IOTP Application Core)
^ ^
| 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 1: Relationship of the Components
图1：组件之间的关系
The Payment API considers the following transaction types of Baseline IOTP:
支付API考虑了基线IOTP的以下交易类型：
o Baseline Purchase, o Baseline Refund, o Baseline Value Exchange, o Baseline Withdrawal, and o Baseline (Payment) Inquiry.
o 基线购买、o基线退款、o基线值交换、o基线取款和o基线（付款）查询。
For more information on Baseline IOTP, see [IOTP] and [IOTPBOOK].
有关基线IOTP的更多信息，请参阅[IOTP]和[IOTPOOK]。
First, the authors' vision of the IOTP aware application's and its main components' capabilities are clarified: On the one hand, the Payment API should be quite powerful and flexible for sufficient connection of the generic and specific components. On the other hand, the Payment API should not be overloaded with nice-to-haves being unsupported by Existing Payment Software.
首先，作者对IOTP感知应用程序及其主要组件功能的愿景得到了澄清：一方面，支付API应该非常强大和灵活，以充分连接通用和特定组件。另一方面，支付API不应因现有支付软件不支持的“好东西”而过载。
Despite the strong similarities on the processing of successful payments, failure resolution and inquiry capabilities differ extremely among different payment schemes. These aspects may even vary between different payment instrument using the same payment schemes. Additionally, the specific requirements of Consumers, Merchants and Payment Handlers add variance and complexity. Therefore, it is envisioned that the IOTP Application Core provides only very basic inquiry mechanisms while complex and payment scheme specific inquiries, failure analysis, and failure resolution are fully deferred to the actual Existing Payment Software - including the user interface.
尽管在成功支付的处理上有很大的相似性，但不同支付方案的故障解决和查询能力却有很大的不同。这些方面甚至可能在使用相同支付方案的不同支付工具之间有所不同。此外，消费者、商家和支付处理人员的特定要求增加了差异和复杂性。因此，可以预见，IOTP应用程序核心只提供非常基本的查询机制，而复杂的和特定于支付方案的查询、故障分析和故障解决完全取决于实际的现有支付软件，包括用户界面。
The IOTP Application Core processes payments transparently, i.e., it forwards the wrapped payment scheme specific messages to the associated IOTP Payment Bridge/Existing Payment Software. The Existing Payment Software might even use these messages for inbound failure resolution. It reports only the final payment status to the IOTP Application Core or some intermediate - might be also final - status on abnormal interruption.
IOTP应用程序核心以透明方式处理支付，即将包装好的特定于支付方案的消息转发给相关的IOTP支付桥/现有支付软件。现有的支付软件甚至可能使用这些消息来解决入站故障。它仅向IOTP应用程序核心报告最终支付状态，或在异常中断时向某些中间状态报告最终支付状态。
The IOTP Application Core implements the generic and payment scheme independent part of the IOTP transaction processing and provides the suitable user interface. Focusing on payment related tasks, it
IOTP应用核心实现IOTP交易处理的通用和支付方案独立部分，并提供合适的用户界面。专注于支付相关任务，it
o manages the registered IOTP Payment Bridges and provides a mechanism for their registration - the latter is omitted by this document.
o 管理已注册的IOTP支付桥，并为其注册提供机制——本文件省略了后者。
o assumes that any IOTP Payment Bridge is a passive component, i.e., it strictly awaits input data and generates one response to each request,
o 假设任何IOTP支付桥都是被动组件，即它严格等待输入数据并对每个请求生成一个响应，
o supports the payment negotiation (Consumer: selection of the actual payment instrument or method; Merchant: selection of the payment methods being offered to the Consumer) preceding the payment request,
o 支持支付请求之前的支付协商（消费者：选择实际支付工具或方法；商户：选择向消费者提供的支付方法），
o requests additional payment specific support from the Existing Payment Software via the selected and registered the IOTP Payment Bridge,
o 通过选定并注册的IOTP支付桥，请求现有支付软件提供额外的特定于支付的支持，
o initializes and terminates the Existing Payment Software via the IOTP Payment Bridge,
o 通过IOTP支付桥初始化和终止现有支付软件，
o inquires authentication data (for subsequent request or response) from the Existing Payment Software, specific authentication component - omitted in this document - or Consumer (by a suitable user interface),
o 从现有支付软件、特定认证组件（本文档中省略）或消费者（通过合适的用户界面）查询认证数据（用于后续请求或响应），
o supervises the online transaction process and traces its progress,
o 监督在线交易流程并跟踪其进度，
o stores the transaction data being exchanged over the IOTP wire - payment scheme specific data is handled transparently,
o 存储通过IOTP电汇交换的交易数据-支付方案特定数据的处理是透明的，
o relates each payment transaction with multiple payment parameters (IOTP Transaction Identifier, Trading Protocol Options, Payment Instrument/Method, Offer Response, IOTP Payment Bridge, and Wallet Identifier, associated remote Parties). The relation might be
o 将每个支付交易与多个支付参数（IOTP交易标识符、交易协议选项、支付工具/方法、报价响应、IOTP支付桥和钱包标识符、相关远程方）关联。这种关系可能是
lowered to the party's Payment Identifier, IOTP Payment Bridge, Wallet Identifier, and the remote parties when the actual payment transaction has been successfully started.
当实际支付交易成功启动时，降低至当事方的支付标识符、IOTP支付桥、钱包标识符和远程当事方。
o implements a payment transaction progress indicator,
o 实现付款交易进度指示器，
o enables the inquiry of pending and completed payment transactions,
o 允许查询未决和已完成的付款交易，
o implements generic dialogs, e.g., brand selection, payment acknowledge, payment suspension / cancellation, receipt visualization, basic transaction inquiry, balance inquiry, or receipt validation,
o 实现通用对话框，例如品牌选择、付款确认、付款暂停/取消、收据可视化、基本交易查询、余额查询或收据验证，
o defers payment specific processing, supervision, validation, and error resolution to the Existing Payment Software. It is expected, that the Existing Payment Software will try to resolve many errors first by the extended exchange of Payment Exchange messages. The most significant and visible failures arise from sudden unavailability or lapses of the local or opposing payment component.
o 将特定于支付的处理、监督、验证和错误解决延迟到现有支付软件。预计现有的支付软件将首先通过扩展支付交换消息的交换来解决许多错误。最重要和最明显的故障源于本地或对方支付部分的突然不可用或失效。
o supports the invocation of any Existing Payment Software in an interactive mode, which might be used (1) for the payment scheme specific post-processing of a (set of) payment transactions, (2) for the analysis of a payment instrument, (3) for the registration of a new payment instrument/scheme, or (4) re-configuration of a payment instrument/scheme.
o 支持以交互模式调用任何现有支付软件，可用于（1）特定于支付方案的（一组）支付交易后处理，（2）分析支付工具，（3）注册新的支付工具/方案，或（4）重新配置支付工具/方案。
o exports call back functions for use by the IOTP Payment Bridge or Existing Payment Software for progress indication.
o 导出回拨功能，供IOTP支付桥或现有支付软件用于进度指示。
In addition, the IOTP Application Core
此外，IOTP应用程序核心
o manages the IOTP message components and IOTP message blocks exchanged during the transaction which may be referenced and accessed during the processing of subsequent messages, e.g., for signature verification. In particular, it stores named Packaged Content elements exchanged during payments.
o 管理在事务期间交换的IOTP消息组件和IOTP消息块，这些消息块可在后续消息处理期间被引用和访问，例如用于签名验证。特别是，它存储支付期间交换的命名打包内容元素。
o manages several kinds of identifiers, i.e., transaction, message, component, and block identifiers,
o 管理多种标识符，即事务、消息、组件和块标识符，
o implements a message caching mechanism,
o 实现消息缓存机制，
o detects time-outs at the protocol and API level reflecting the communication with both the IOTP aware remote party and the Payment API aware local periphery, e.g., chip card (reader) may raise time-outs.
o 在协议和API级别检测超时，反映与IOTP感知远程方和支付API感知本地外围设备的通信，例如芯片卡（读卡器）可能引发超时。
However, the IOTP Payment Bridge and Existing Payment Software do not have to rely on all of these IOTP Application Core's capabilities. E.g., some Consumer's Existing Payment Software may refuse the disclosure of specific payment instruments at brand selection time and may delay this selection to the "Check Payment Possibility" invocation using its own user interface.
然而，IOTP支付桥和现有支付软件不必依赖所有这些IOTP应用核心的功能。例如，一些消费者的现有支付软件可能会在品牌选择时拒绝披露特定的支付工具，并可能会使用其自己的用户界面将选择延迟到“检查支付可能性”调用。
The IOTP Payment Bridge's capabilities do not only deal with actual payments between the Consumer and the Payment Handler but extend to the following:
IOTP支付桥的功能不仅处理消费者和支付处理者之间的实际支付，还扩展到以下方面：
o translation and (dis)assemblage of messages between the formats of the IOTP Payment API and those of the Existing Payment Software. Payment API requests and response are strictly 1-to-1 related.
o IOTP支付API格式和现有支付软件格式之间的消息翻译和（dis）组装。支付API请求和响应严格地1对1相关。
o Consumer's payment instrument selection by the means of an unsecured/public export of the relationship of payment brands, payment protocols, and payment instruments (identifiers). Generally, this includes not just the brand (Mondex, GeldKarte, etc.) but also which specific instance of the instrument and currency to use (e.g., which specific Mondex card and which currency of all those available).
o 消费者通过支付品牌、支付协议和支付工具（标识符）关系的无担保/公开导出选择支付工具。通常，这不仅包括品牌（Mondex、GeldKarte等），还包括使用哪种特定的工具和货币（例如，哪种特定的Mondex卡和所有可用货币中的哪种货币）。
However, some Existing Payment Software may defer the selection of the payment instrument to the actual payment carrying-out or it may even lack any management of payment instruments. E.g., chip card based payment methods may offer - Point of Sale like - implicit selection of the payment instrument by simple insertion of the chip card into the chip card reader or it interrogates the inserted card and requests an acknowledge (or selection) of the detected payment instrument(s).
然而，一些现有的支付软件可能会将支付工具的选择推迟到实际执行的支付，甚至可能缺乏对支付工具的任何管理。例如，基于芯片卡的支付方法可以通过简单地将芯片卡插入芯片卡读取器来提供类似销售点的支付工具隐式选择，或者它询问插入的卡并请求确认（或选择）检测到的支付工具。
o payment progress checks, e.g., is there enough funds available to carry out the purchase, or enough funds left for the refund,
o 付款进度检查，例如，是否有足够的资金进行购买，或是否有足够的资金用于退款，
o IOTP Payment Receipt checks which might be performed over its Packaged Content or by other means.
o IOTP付款收据检查，可通过其包装内容或其他方式执行。
o recoding of payment scheme specific receipts into a format which can be displayed to the user or printed,
o 将特定于付款方案的收据重新编码为可向用户显示或打印的格式，
o cancellation of payment, even though it is not complete,
o 取消付款，即使未完成，
o suspension and resumption of payment transactions. Two kinds of failures the Existing Payment Software might deal with are (1) the time-out of the network connection and (2) lack of funds. For resolution, the IOTP Application Core may try the suspension with a view to later possible resumption.
o 暂停和恢复支付交易。现有支付软件可能会处理两种故障：（1）网络连接超时；（2）资金不足。为了解决问题，IOTP应用程序核心可能会尝试暂停，以期稍后可能恢复。
o recording the payment progress and status on a database. E.g., information about pending payments might be used to assist their continuation when the next payment protocol message is received.
o 在数据库上记录付款进度和状态。例如，当收到下一个付款协议消息时，有关未决付款的信息可用于帮助继续付款。
o payment transaction status inquiry, so that the inquirer - IOTP Application Core or User - can determine the appropriate next step.
o 支付交易状态查询，以便查询者-IOTP应用程序核心或用户-可以确定适当的下一步。
o balance inquiry or transaction history, e.g., consumers may interrogate their chip card based payment instrument or remotely administer some account in advance of a payment transaction acknowledge,
o 余额查询或交易历史记录，例如，消费者可以在支付交易确认之前查询其基于芯片卡的支付工具或远程管理某些帐户，
o inquiry on abnormal interrupted payment transactions, which might be used by the IOTP Application Core to resolve these pending transactions at startup (after power failure).
o 对异常中断支付交易的查询，IOTP应用程序核心可能使用该查询在启动时（断电后）解决这些未决交易。
o payment progress indication. This could be used to inform the end user of details on what is happening with the payment.
o 付款进度指示。这可用于通知最终用户有关付款情况的详细信息。
o payment method specific authentication methods.
o 支付方式特定的身份验证方法。
Existing Payment Software may not provide full support of these capabilities. E.g., some payment schemes may not support or may even prevent the explicit transaction cancellation at arbitrary phases of the payment process. In this case, the IOTP Payment Bridge has to implement at least skeletons that signal such lack of support by the use of specific error codes (see below).
现有的支付软件可能无法完全支持这些功能。例如，某些支付方案可能不支持或甚至可能阻止在支付过程的任意阶段进行明确的交易取消。在这种情况下，IOTP支付桥必须至少实现通过使用特定错误代码（见下文）来表示缺乏支持的框架。
The Existing Payment Software's capabilities vary extremely. It
现有支付软件的功能差异极大。信息技术
o supports payment scheme specific processing, supervision, validation, and error resolution. It is expected, that many errors are tried to be resolved first by the extended exchange of Payment Exchange messages.
o 支持特定于支付方案的处理、监督、验证和错误解决。预计许多错误将首先通过支付交换消息的扩展交换来解决。
o provides hints for out-of-band failure resolution on failed inbound resolution - inbound resolution is invisible to the IOTP Application Core.
o 为失败的入站解析提供带外故障解析提示-入站解析对IOTP应用程序核心不可见。
o may implement arbitrary transaction data management and inquiry mechanisms ranging from no transaction recording, last transaction recording, chip card deferred transaction recording, simple transaction history to sophisticated persistent data management with flexible user inquiry capabilities. The latter is required by Payment Handlers for easy and cost effective failure resolution.
o 可实现任意交易数据管理和查询机制，包括无交易记录、上次交易记录、芯片卡延迟交易记录、简单交易历史记录到复杂的持久数据管理，并具有灵活的用户查询功能。支付处理人员需要后者，以方便且经济高效地解决故障。
o implements the payment scheme specific dialog boxes.
o 实现特定于付款方案的对话框。
Even the generic dialog boxes of the IOTP Application Core might be unsuitable: Particular (business or scheme) rules may require some dedicated appearance / structure / content or the dialog boxes, may prohibit the unsecured export of payment instruments, or may prescribe the pass phrase input under its own control.
即使是IOTP应用程序核心的通用对话框也可能不适用：特定（业务或方案）规则可能需要一些专用的外观/结构/内容或对话框，可能禁止支付工具的无担保出口，或者可能规定在其自身控制下的通行短语输入。
The following lists all functions of the IOTP Payment API:
以下列出了IOTP支付API的所有功能：
o Brand Compilation Related API Functions
o 品牌编译相关API函数
"Find Accepted Payment Brand" identifies the accepted payment brands for any indicated currency amount.
“查找已接受的支付品牌”标识任何指定货币金额的已接受支付品牌。
"Find Accepted Payment Protocol" identifies the accepted payment protocols for any indicated currency amount (and brand) and returns payment scheme specific packaged content for brand selection purposes.
“查找已接受的支付协议”标识任何指定货币金额（和品牌）的已接受支付协议，并返回特定于支付方案的打包内容，用于品牌选择。
This function might be used in conjunction with the aforementioned function or called without any brand identifier.
此函数可以与上述函数一起使用，也可以在没有任何品牌标识符的情况下调用。
"Get Payment Initialization Data" returns additional payment scheme specific packaged content for payment processing by the payment handler.
“获取支付初始化数据”返回额外的支付方案特定的打包内容，供支付处理程序进行支付处理。
"Inquire Authentication Challenge" returns the payment scheme specific authentication challenge value.
“查询验证质询”返回特定于支付方案的验证质询值。
"Check Authentication Response" verifies the returned payment scheme specific authentication response value.
“检查验证响应”验证返回的特定于支付方案的验证响应值。
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
“变更过程状态”用于（仅限此处）异常终止。（参见支付处理相关API函数）。
o Brand Selection Related API Functions
o 与品牌选择相关的API函数
"Find Payment Instrument" identifies which instances of a payment instrument of a particular payment brand are available for use in a payment.
“查找支付工具”标识特定支付品牌的支付工具的哪些实例可用于支付。
"Check Payment Possibility" checks whether a specific payment instrument is able to perform a payment.
“检查支付可能性”检查特定支付工具是否能够执行支付。
"Authenticate" forwards any payment scheme specific authentication data to the IOTP Payment Bridge for processing.
“认证”将任何特定于支付方案的认证数据转发给IOTP支付桥进行处理。
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
“变更过程状态”用于（仅限此处）异常终止。（参见支付处理相关API函数）。
o Payment Processing Related API Functions
o 支付处理相关API函数
"Start or Resume Payment Consumer/Payment Handler" initiate or resume a payment transaction. There exist specific API functions for the two trading roles Consumer and Payment Handler.
“启动或恢复支付消费者/支付处理人”启动或恢复支付交易。对于消费者和支付处理程序这两个交易角色，存在特定的API函数。
"Continue Process" forwards payment scheme specific data to the Existing Payment Software and returns more payment scheme specific data for transmission to the counter party.
“继续处理”将特定于支付方案的数据转发到现有的支付软件，并返回更多特定于支付方案的数据以传输给交易对手。
"Change Process State" changes the current status of payment transactions. Typically, this call is used for termination or suspension without success.
“更改流程状态”更改付款交易的当前状态。通常，此呼叫用于终止或暂停，但未成功。
o General Inquiry API Functions
o 通用查询API函数
"Remove Payment Log" notifies the IOTP Payment Bridge that a particular entry has been removed from the Payment Log of the IOTP Application Core.
“删除支付日志”通知IOTP支付网桥某个特定条目已从IOTP应用程序核心的支付日志中删除。
"Payment Instrument Inquiry" retrieves the properties of Payment Instruments.
“支付工具查询”检索支付工具的属性。
"Inquire Pending Payment" reports any abnormal interrupted payment transaction known by the IOTP Payment Bridge.
“查询待付款”报告IOTP支付桥已知的任何异常中断付款交易。
Payment Processing Related Inquiry API Functions
支付处理相关查询API函数
"Check Payment Receipt" checks the consistency and validity of IOTP Payment Receipts, received from the Payment Handler or returned by "Inquire Process State" API calls. Typically, this function is called by the Consumer during the final processing of payment transactions. Nevertheless, this check might be advantageous both for Consumers and Payment Handlers on failure resolution.
“检查付款收据”检查IOTP付款收据的一致性和有效性，这些付款收据是从付款处理程序收到的，或是通过“查询流程状态”API调用返回的。通常，消费者在支付交易的最终处理过程中调用此函数。然而，这种检查可能对消费者和支付处理人员在故障解决方面都有利。
"Expand Payment Receipt" expands the Packaged Content of IOTP Payment Receipts as well as payment scheme specific payment receipts into a form which can be used for display or printing purposes.
“扩展付款收据”将IOTP付款收据以及特定于付款方案的付款收据的打包内容扩展为可用于显示或打印的形式。
"Inquire Process State" responds with the payment state and the IOTP Payment Receipt Component. Normally, this function is called by the Payment Handler for final processing of the payment transaction.
“查询流程状态”响应付款状态和IOTP付款收据组件。通常，付款处理程序会调用此函数以最终处理付款交易。
"Start Payment Inquiry" prepares the remote inquiry of the payment transaction status and responds with payment scheme specific data that might be needed by the Payment Handler for the Consumer initiated inquiry processing.
“启动付款查询”准备付款交易状态的远程查询，并使用付款处理程序可能需要的特定于付款方案的数据进行响应，以进行消费者发起的查询处理。
"Inquire Payment Status" is called by the Payment Handler on Consumer initiated inquiry requests. This function returns the payment scheme specific content of the Inquiry Response Block.
“查询支付状态”由支付处理程序在消费者发起查询请求时调用。此函数返回查询响应块中特定于付款方案的内容。
"Continue Process" and "Change Process State" (cf. Payment Processing Related API Calls)
“继续处理”和“更改处理状态”（参见与支付处理相关的API调用）
o Other API Functions
o 其他API函数
"Manage Payment Software" enables the immediate activation of the Existing Payment Software. Further user input is under control of the Existing Payment Software.
“管理支付软件”允许立即激活现有支付软件。进一步的用户输入由现有的支付软件控制。
"Call Back" provides a general interface for the visualization of transaction progress by the IOTP Application Core.
“回调”提供了一个通用接口，用于通过IOTP应用程序核心可视化事务进度。
The following table shows which API functions must (+), should (#), or might (?) be implemented by which Trading Roles.
下表显示了哪些交易角色必须（+）、应该（#）或可能（？）实现哪些API函数。
API function Consumer Payment Handler Merchant
------------ -------- --------------- --------
API function Consumer Payment Handler Merchant
------------ -------- --------------- --------
Find Accepted Payment Brand + Find Accepted Payment Protocol # Find Payment Instrument +
查找接受的支付品牌+查找接受的支付协议#查找支付工具+
Get Payment Initialization Data + Check Payment Possibility +
获取付款初始化数据+检查付款可能性+
Start Payment Consumer + Start Payment Payment Handler + Resume Payment Consumer # Resume Payment Payment Handler #
启动支付消费者+启动支付处理程序+恢复支付消费者#恢复支付处理程序#
Continue Process + +
Inquire Process State + + ?
Change Process State + + ?
Check Payment Receipt + ?
Expand Payment Receipt # ?
Continue Process + +
Inquire Process State + + ?
Change Process State + + ?
Check Payment Receipt + ?
Expand Payment Receipt # ?
Remove Payment Log ? ? ?
删除付款日志？
Inquire Authentication Challenge ?
询问身份验证挑战？
Authenticate + Check Authentication Response ?
验证+检查验证响应？
Payment Instrument Inquiry ? Inquire Pending Payment # # Start Payment Inquiry ? Inquire Payment Status ?
付款工具查询？查询待付款##开始付款查询？查询付款状态？
Manage Payment Software # ? ?
管理支付软件？
Call Back #
回电#
Table 1: Requirements on API Functions by the Trading Roles
表1：交易角色对API功能的要求
The next sections sketch the relationships and the dependencies between the API functions. They provide the informal description of the progress alternatives and depict the communication and synchronization between the general IOTP Application Core and the payment scheme specific modules.
下一节将概述API函数之间的关系和依赖关系。它们提供了进度备选方案的非正式描述，并描述了通用IOTP应用核心和支付方案特定模块之间的通信和同步。
This section describes how the functions in this document are used together to process authentication.
本节介绍如何将本文档中的函数一起用于处理身份验证。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Authenticator Inquire Authentication Challenge(Alg1*) -> IPB
Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB
. . .
Inquire Authentication Challenge(Algn*) -> IPB
Inq. Auth. Challenge Response(Algn,Chn) <- IPB
Create and transmit Authentication Request Block
Authenticatee Authenticate(Alg1, Ch1) -> IPB
AuthenticateResponse(...) <- IPB
. . .
Authenticate(Algm, Chm) -> IPB
AuthenticateResponse(Res) <- IPB
Create and transmit Authentication Response Block
Authenticator Check Authentication Response(Algm,Chm,Res)->IPB
Check Auth. Response() <-IPB
Create and transmit Authentication Status Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Authenticator Inquire Authentication Challenge(Alg1*) -> IPB
Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB
. . .
Inquire Authentication Challenge(Algn*) -> IPB
Inq. Auth. Challenge Response(Algn,Chn) <- IPB
Create and transmit Authentication Request Block
Authenticatee Authenticate(Alg1, Ch1) -> IPB
AuthenticateResponse(...) <- IPB
. . .
Authenticate(Algm, Chm) -> IPB
AuthenticateResponse(Res) <- IPB
Create and transmit Authentication Response Block
Authenticator Check Authentication Response(Algm,Chm,Res)->IPB
Check Auth. Response() <-IPB
Create and transmit Authentication Status Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 2. Authentication Message Flows
图2。身份验证消息流
1. (Authenticator Process) None, one or multiple IOTP Payment Bridges (IPB) are requested for one or multiple authentication challenge values ("Inquire Authentication Challenge"). Each value is encapsulated in an IOTP Authentication Request Component. In addition, the IOTP Application Core may add payment scheme independent authentication methods. All of them form the final IOTP Authentication Request Block, which describes the set of authentication methods being supported by the authenticator and from which the Authenticatee has to choose one method.
1. （身份验证程序流程）对于一个或多个身份验证质询值（“查询身份验证质询”），未请求任何、一个或多个IOTP支付桥（IPB）。每个值都封装在IOTP身份验证请求组件中。此外，IOTP应用核心可以添加独立于支付方案的认证方法。所有这些都构成了最终的IOTP身份验证请求块，该块描述了身份验证程序支持的身份验证方法集，被身份验证人必须从中选择一种方法。
Note that the interface of the API function is limited to the response of exactly one algorithm per call. If the IOTP Application Core provides a choice of algorithms for input, this choice should be reduced successively by the returned algorithm ({Alg(i+1)*} is subset of {Algi*}).
请注意，API函数的接口仅限于每个调用一个算法的响应。如果IOTP应用程序核心为输入提供了算法选择，则应通过返回的算法（{Alg（i+1）*}是{Algi*}的子集）依次减少该选择。
During the registration of new Payment Instruments, the IOTP Payment Bridge notifies the IOTP Application Core about the supported authentication algorithms.
在新支付工具注册期间，IOTP支付网桥通知IOTP应用核心支持的认证算法。
2. On the presence of an IOTP Authentication Block within the received IOTP message, the Authenticatee's IOTP Application Core checks whether the IOTP transaction type in the current phase actually supports the authentication process.
2. 在接收到的IOTP消息中存在IOTP认证块时，被认证者的IOTP应用程序核心检查当前阶段的IOTP事务类型是否实际支持认证过程。
For each provided Authentication Request Component, the IOTP Application Core analyzes the algorithms' names, the transaction context, and optionally user preferences in order to determine the system components which are capable to process the authentication request items. Such system components might be the IOTP Application Core itself or any of the registered IOTP Payment Bridges.
对于每个提供的认证请求组件，IOTP应用程序核心分析算法名称、事务上下文和可选的用户偏好，以确定能够处理认证请求项的系统组件。此类系统组件可能是IOTP应用程序核心本身或任何已注册的IOTP支付桥。
Subsequently, the IOTP Application Core requests the responses to the supplied challenges from the determined system components in any order. The authentication trials stop with the first successful response, which is included in the IOTP Authentication Response Block.
随后，IOTP应用程序核心以任何顺序从确定的系统组件请求对所提供挑战的响应。认证试验随着第一个成功响应停止，该响应包含在IOTP认证响应块中。
Alternatively, the IOTP Application might ask for a user selection. This might be appropriate, if two or more authentication algorithms are received that require explicit user interaction, like PIN or chip card insertion.
或者，IOTP应用程序可能要求用户选择。如果接收到两个或多个需要显式用户交互（如PIN或芯片卡插入）的身份验证算法，这可能是合适的。
The Authenticatee's organizational data is requested by an IOTP Authentication Request Block without any content element. On failure, the authentication (sequence) might be retried, or the whole transaction might be suspended or cancelled.
被认证者的组织数据由IOTP认证请求块请求，无任何内容元素。失败时，可能会重试身份验证（序列），或者整个事务可能会暂停或取消。
3. (Authenticator Process) The IOTP Application Core checks the presence of the IOTP Authentication Response Component in the Authentication Response Block and forwards its content to the generator of the associated authentication challenge for verification ("Check Authentication Response").
3. （认证者过程）IOTP应用核心检查认证响应块中是否存在IOTP认证响应组件，并将其内容转发给相关认证质询的生成器进行验证（“检查认证响应”）。
On sole organizational data request, its presence is checked.
对于唯一的组织数据请求，将检查其存在性。
Any verification must succeed in order to proceed with the transaction.
任何验证都必须成功才能继续交易。
The following shows how the API functions are used together so that the Merchant can (1) compile the Brand List Component, (2) generate the Payment Component, and (3) adjust the Order Component with payment scheme specific packaged content.
下面显示了如何将API函数一起使用，以便商户可以（1）编译品牌列表组件，（2）生成支付组件，以及（3）使用特定于支付方案的打包内容调整订单组件。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant For each registered IOTP Payment Bridge
| Find Accepted Payment Brand() -> IPB
| Find Accepted Payment Brand Response (B*) <- IPB
| Find Accepted Payment Protocol(B1) -> IPB
| Find Accepted Payment Protocol Res.(P1*) <- IPB
| . . .
| Find Accepted Payment Protocol(Bn) -> IPB
| Find Accepted Payment Protocol Res.(Pn*) <- IPB
Create one Brand List Component, ideally sharing
common Brand, Protocol Amount, Currency Amount,
and Pay Protocol Elements
Create Trading Protocol Options Block
On brand independent transactions
| Create Brand Selection Component, implicitly
| Get Payment Initialization Data(B1,P1) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
Transmit newly created Block(s)
Consumer Consumer selects Brand (Bi)/Currency/Protocol (Pj)
from those that will work and generates Brand
Selection Component - at least logically
On brand dependent transaction
| Transmit Brand Selection Component
Merchant On brand dependent transaction
| Get Payment Initialization Data(Bi,Pj) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
| Transmit newly created Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant For each registered IOTP Payment Bridge
| Find Accepted Payment Brand() -> IPB
| Find Accepted Payment Brand Response (B*) <- IPB
| Find Accepted Payment Protocol(B1) -> IPB
| Find Accepted Payment Protocol Res.(P1*) <- IPB
| . . .
| Find Accepted Payment Protocol(Bn) -> IPB
| Find Accepted Payment Protocol Res.(Pn*) <- IPB
Create one Brand List Component, ideally sharing
common Brand, Protocol Amount, Currency Amount,
and Pay Protocol Elements
Create Trading Protocol Options Block
On brand independent transactions
| Create Brand Selection Component, implicitly
| Get Payment Initialization Data(B1,P1) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
Transmit newly created Block(s)
Consumer Consumer selects Brand (Bi)/Currency/Protocol (Pj)
from those that will work and generates Brand
Selection Component - at least logically
On brand dependent transaction
| Transmit Brand Selection Component
Merchant On brand dependent transaction
| Get Payment Initialization Data(Bi,Pj) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
| Transmit newly created Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 3. Brand Compilation Message Flows
图3。品牌信息流
1. The Merchant's commerce server controls the shopping dialog with its own mechanisms until the Consumer checks out the shopping cart and indicates the payment intention. The notion shopping subsumes any non-IOTP based visit of the Merchant Trading Role's (which subsumes Financial Institutes) web site in order to negotiate the content of the IOTP Order Component. The subsequent processing switches to the IOTP based form by the activation of the Merchant's IOTP aware application.
1. 商户的商务服务器使用其自己的机制控制购物对话框，直到消费者签出购物车并指示付款意图。购物概念包括商户交易角色（包括金融机构）网站的任何非基于IOTP的访问，以便协商IOTP订单组件的内容。随后的处理通过激活商户的IOTP感知应用程序切换到基于IOTP的表单。
2. The IOTP Application Core inquires for the IOTP level trading parameters (Consumer's shopping identifier, payment direction, initial currency amounts, discount rates, Merchant's and Delivery Handler's Net Locations, Non-Payment Handler's Organizational Data, initial order information, ....).
2. IOTP应用程序核心查询IOTP级别的交易参数（消费者的购物标识符、付款方向、初始货币金额、折扣率、商户和送货经办人的净位置、非付款经办人的组织数据、初始订单信息等）。
3. The registered IOTP Payment Bridges are inquired by the IOTP Application Core about the accepted payment brands ("Find Accepted Payment Brand"). Their responses provide most of the attribute values for the compilation of the Brand List Component's Brand Elements. The IOTP Application Core might optionally match the returned payment brands with Merchant's general preferences.
3. IOTP应用核心向注册的IOTP支付桥查询接受的支付品牌（“查找接受的支付品牌”）。他们的回答为品牌列表组件的品牌元素的编制提供了大多数属性值。IOTP应用程序核心可以选择将退回的支付品牌与商户的一般偏好相匹配。
The IOTP Application Core must provide any wallet identifiers, if they are required by the IOTP Payment Bridges which signal their need by specific error codes (see below). Any signaled error that could not be immediately solved by the IOTP Application Core should be logged - this applies also to the subsequent API calls of this section. In this case, the IOTP Application Core creates an IOTP Error Block (hard error), transmits it to the Consumer, and terminates the current transaction.
IOTP应用程序核心必须提供任何钱包标识符，如果IOTP支付网桥需要这些标识符，则这些标识符通过特定错误代码（见下文）表示其需要。应记录IOTP应用程序核心无法立即解决的任何信号错误-这也适用于本节的后续API调用。在这种情况下，IOTP应用程序核心创建IOTP错误块（硬错误），将其传输给消费者，并终止当前事务。
4. The IOTP Application Core interrogates the IOTP Payment Bridges for each accepted payment brand about the supported payment protocols ("Find Accepted Payment Protocol"). These responses provide the remaining attribute values of the Brand Elements as well as all attribute values for the compilation of the Brand List Component's Protocol Amount and Pay Protocol Elements.
4. IOTP应用程序核心询问每个接受支付品牌的IOTP支付桥，了解支持的支付协议（“查找接受支付协议”）。这些响应提供品牌元素的剩余属性值以及品牌列表组件的协议金额和支付协议元素编译的所有属性值。
Furthermore, the organisational data about the Payment Handler is returned. The IOTP Application Core might optionally match the returned payment brands with Merchant's general preferences.
此外，还将返回有关支付处理程序的组织数据。IOTP应用程序核心可以选择将退回的支付品牌与商户的一般偏好相匹配。
Alternatively, the IOTP Application Core might skip the calls of "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find Accepted Payment Protocol" call without any Brand given on the input parameter list. In this case, the IOTP Payment Bridge responds to the latter call with the whole set of payment schemes supported w.r.t. the other input parameters.
或者，IOTP应用程序核心可能会跳过“查找接受的支付品牌”（参见步骤3）的调用，并在输入参数列表中没有给出任何品牌的情况下发出“查找接受的支付协议”调用。在这种情况下，IOTP支付网桥使用其他输入参数支持的整套支付方案响应后一个呼叫。
5. The steps 3 and 4 are repeated during IOTP Value Exchange transactions - these steps are omitted in the previous figure.
5. IOTP价值交换交易期间重复步骤3和4-上图中省略了这些步骤。
6. The IOTP Application Core compiles the Brand List Component(s) and the IOTP Trading Protocol Options Block. It is recommended that the "equal" items returned by IOTP Payment Bridge function calls are shared due to the extensive linking capabilities within
6. IOTP应用程序核心编译品牌列表组件和IOTP交易协议选项块。由于IOTP支付桥函数调用中广泛的链接功能，建议共享IOTP支付桥函数调用返回的“相等”项
the Brand List Component. However, the compilation must consider several aspects in order to prevent conflicts - sharing detection might be textual matching (after normalization):
品牌列表组件。然而，编译必须考虑几个方面，以防止冲突共享检测可能是文本匹配（归一化后）：
o Packaged Content Elements contained in the Brand List Component (and subsequently generated Payment and Order Components) might be payment scheme specific and might depend on each other.
o 品牌列表组件（以及随后生成的付款和订单组件）中包含的打包内容元素可能是特定于付款方案的，并且可能相互依赖。
o Currently, IOTP lacks precise rules for the content of the Packaged Content Element. Therefore, transaction / brand / protocol / currency amount (in)dependent data might share the same Packaged Content Element or might spread across multiple Packaged Content Elements.
o 目前，IOTP缺乏对打包内容元素内容的精确规则。因此，依赖于交易/品牌/协议/货币金额（in）的数据可能共享相同的打包内容元素，或者可能分布在多个打包内容元素上。
o The Consumer's IOTP Application Core transparently passes the Packaged Content Elements to the IOTP Payment Bridges which might not be able to handle payment scheme data of other payment schemes, accurately.
o 消费者的IOTP应用程序核心将打包的内容元素透明地传递给IOTP支付桥，后者可能无法准确地处理其他支付方案的支付方案数据。
The rules and mechanisms of how this could be accomplished are out of the scope of this document. Furthermore, this document does not define any further restriction to the IOTP specification.
如何实现这一点的规则和机制不在本文件的范围之内。此外，本文件未定义对IOTP规范的任何进一步限制。
7. The IOTP Application Core determines whether the IOTP message can be enriched with an Offer Response Block. This is valid under the following conditions:
7. IOTP应用程序核心确定IOTP消息是否可以通过要约响应块来丰富。这在以下条件下有效：
o All payment alternatives share the attribute values and Packaged Content Elements of the subsequently generated IOTP Payment and Order Components.
o 所有支付方案共享随后生成的IOTP支付和订单组件的属性值和打包内容元素。
o The subsequently generated data does not depend on any IOTP BrandSelInfo Elements that might be reported by the consumer within the TPO Selection Block in the brand dependent variant.
o 随后生成的数据不依赖于消费者可能在品牌相关变型的TPO选择块中报告的任何IOTP BrandSelInfo元素。
If both conditions are fulfilled, the IOTP Application Core might request the remaining payment scheme specific payment initialization data from the IOTP Payment Bridge ("Get Payment Initialization Data") and compile the IOTP Offer Response Block.
如果两个条件都满足，IOTP应用程序核心可能会从IOTP支付桥请求剩余的特定于支付方案的支付初始化数据（“获取支付初始化数据”），并编译IOTP提供响应块。
Optionally, the IOTP Application Core might request the current process state from the IOTP Payment Bridge and add the inferred order status to the IOTP Offer Response Block. Alternatively, IOTP Application might determine the order status on its own.
可选地，IOTP应用程序核心可以从IOTP支付桥请求当前流程状态，并将推断的订单状态添加到IOTP报价响应块。或者，IOTP应用程序可以自行确定订单状态。
As in step 6, the rules and mechanisms of how this could be accomplished are out of the scope of this document.
与步骤6一样，如何实现这一点的规则和机制不在本文件的范围之内。
8. The IOTP Application Core compiles the IOTP TPO Message including all compiled IOTP Blocks and transmits the message to the Consumer. The IOTP Application Core terminates if an IOTP Offer Response Block has been created.
8. IOTP应用程序核心编译IOTP TPO消息，包括所有编译的IOTP块，并将消息传输给消费者。如果已创建IOTP提供响应块，IOTP应用程序核心将终止。
9. The Consumer performs the Brand Selection Steps (cf. Section 2.3) and responds with a TPO Selection Block if no IOTP Offer Response Block has been received. Otherwise, the following step is skipped.
9. 消费者执行品牌选择步骤（参见第2.3节），如果未收到IOTP报价响应块，则使用TPO选择块进行响应。否则，将跳过以下步骤。
10. On brand dependent transactions, the IOTP Application Core requests the remaining payment scheme specific payment initialization data from the IOTP Payment Bridge ("Get Payment Initialization Data"), compiles the IOTP Offer Response Block, transmits it to the Consumer, and terminates. Like Step 7, the IOTP Application Core might access the current process state of the IOTP Payment Bridge for the compilation of the order status.
10. 在品牌相关交易中，IOTP应用程序核心从IOTP支付桥请求剩余的特定于支付方案的支付初始化数据（“获取支付初始化数据”），编译IOTP报价响应块，将其传输给消费者，然后终止。与步骤7类似，IOTP应用程序核心可能访问IOTP支付桥的当前进程状态，以编译订单状态。
Any error during this process raises an IOTP Error Block.
此过程中的任何错误都会引发IOTP错误块。
This section describes the steps that happen mainly after the Merchant's Brand Compilation (in a brand independent transaction). However, these steps might partially interlace the previous process (in a brand dependent transaction).
本节描述了主要在商户品牌汇编（在品牌独立交易中）之后发生的步骤。然而，这些步骤可能会部分地交错在前面的过程中（在品牌相关的交易中）。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Merchant generates Brand List(s) containing
Brands, Payment Protocols and Currency Amounts
On brand independent transactions
| Merchant generates Offer Response Block
Consumer Compile set(s) of Brands B/Protocols P
for each set
| Find Payment Instrument(B, P, C) -> IPB
| Find Payment Instrument Response (PI*) <- IPB
Consumer selects Brand/Currency/Payment Instrument
from those that will work and generates Brand
Selection Component
For the Selection
| Get Payment Initialization Data(B,C,PI,P) -> IPB
| Get Payment Initialization Data Response()<- IPB
On brand dependent transaction
| Generate and transmit TPO Selection Block
Merchant On brand dependent transaction
| Merchant checks Brand Selection and generates
| and transmits Offer Response Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Merchant generates Brand List(s) containing
Brands, Payment Protocols and Currency Amounts
On brand independent transactions
| Merchant generates Offer Response Block
Consumer Compile set(s) of Brands B/Protocols P
for each set
| Find Payment Instrument(B, P, C) -> IPB
| Find Payment Instrument Response (PI*) <- IPB
Consumer selects Brand/Currency/Payment Instrument
from those that will work and generates Brand
Selection Component
For the Selection
| Get Payment Initialization Data(B,C,PI,P) -> IPB
| Get Payment Initialization Data Response()<- IPB
On brand dependent transaction
| Generate and transmit TPO Selection Block
Merchant On brand dependent transaction
| Merchant checks Brand Selection and generates
| and transmits Offer Response Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 4. Brand Selection Message Flows
图4。品牌选择信息流
1. The Merchant's commerce server controls the shopping dialog with its own mechanisms until the Consumer checks out the shopping cart and indicates his payment intention. The subsequent processing switches to the IOTP based form by the activation of the Merchant's IOTP aware application.
1. 商户的商务服务器通过自己的机制控制购物对话框，直到消费者签出购物车并表明其付款意图。随后的处理通过激活商户的IOTP感知应用程序切换到基于IOTP的表单。
2. The IOTP Application Core compiles the IOTP Trading Protocol Options Block which contains the IOTP Brand List Component(s) enumerating Merchant's accepted payment brands and payment protocols and initiates the Brand Selection process.
2. IOTP应用核心编译IOTP交易协议选项块，其中包含IOTP品牌列表组件，列举商户接受的支付品牌和支付协议，并启动品牌选择过程。
3. This first IOTP message activates the Consumer's IOTP aware application, e.g., the Web browser invokes a helper application (e.g., Java applet or external application). Its IOTP Application Core
3. 此第一条IOTP消息激活消费者的IOTP感知应用程序，例如，Web浏览器调用助手应用程序（例如，Java小程序或外部应用程序）。其物联网应用核心
o infers the accepted payment brands, payment protocols, payment direction, currencies, payment amounts, any descriptions etc., and their relationships from the IOTP message,
o 从IOTP消息中推断接受的支付品牌、支付协议、支付方向、货币、支付金额、任何描述等及其关系，
o determines the registered IOTP Payment Bridges,
o 确定已注册的IOTP支付桥，
o compiles one or multiple sets of brand and protocol such that the join of all sets describes exactly the payment alternatives being offered by the Merchant.
o 汇编一套或多套品牌和协议，以便所有品牌和协议集的合并准确描述商户提供的支付备选方案。
o inquires payment (protocol) support and the known payment instruments from each registered IOTP Payment Bridge for each compiled set ("Find Payment Instrument"). However, some IOTP Payment Bridges may refuse payment instrument distinction.
o 从每个已注册的IOTP支付桥查询每个已编译集的支付（协议）支持和已知支付工具（“查找支付工具”）。然而，一些IOTP支付桥可能拒绝支付工具区分。
The payment protocol support may differ between payment instruments if the IOTP Payment Bridge supports payment instrument distinction.
如果IOTP支付桥支持支付工具区分，则支付协议支持在支付工具之间可能有所不同。
These API calls are used to infer the payment alternatives at the startup of any payment transaction (without user unfriendly explicit user interaction).
这些API调用用于在任何支付事务启动时推断支付替代方案（没有用户不友好的显式用户交互）。
The IOTP Application Core must provide wallet identifiers, if they are requested by the IOTP Payment Bridges which signal their need by specific error codes (see below).
IOTP应用核心必须提供钱包标识符，如果IOTP支付网桥要求提供钱包标识符，则该支付网桥通过特定错误代码（见下文）表示需要钱包标识符。
It is recommended that the IOTP Application Core manages wallet identifiers. But for security reasons, it should store pass phrases in plain text only in runtime memory. Developers of IOTP
建议IOTP应用程序核心管理钱包标识符。但出于安全原因，它应该仅在运行时内存中以纯文本形式存储传递短语。物联网开发者
Payment Bridges and payment software modules should provide a thin and fast implementation - without lengthy initialization processes - for this initial inquiry step.
支付桥和支付软件模块应为初始查询步骤提供精简快速的实现，无需冗长的初始化过程。
4. The IOTP Application Core verifies the Consumer's payment capabilities with the Merchant's accepted payment brands and currencies,
4. IOTP应用核心使用商户认可的支付品牌和货币验证消费者的支付能力，
o displays the valid payment instruments and payment instrument independent payment brands (brand and protocol) together with their purchase parameters (payment direction, currency, amount), and
o 显示有效的支付工具和支付工具独立的支付品牌（品牌和协议）及其购买参数（支付方向、货币、金额）和
o requests the Consumer's choice or derives it automatically from any configured preferences. Any selection ties one IOTP Payment Bridge with the following payment transaction.
o 请求消费者的选择，或从任何配置的首选项自动获取选择。任何选择都会将一个IOTP支付桥与以下支付交易联系起来。
The handling and resolution of unavailable IOTP Payment Bridges during the inquiry in Step 3 is up to the IOTP Application Core. It may skip these IOTP Payment Bridges or may allow user supported resolution.
在步骤3的查询过程中，不可用的IOTP支付桥的处理和解决取决于IOTP应用程序核心。它可能跳过这些IOTP支付桥，或允许用户支持的解决方案。
Furthermore, it may offer the registration of new payment instruments when the Consumer is asked for payment instrument selection.
此外，当消费者被要求选择支付工具时，它可以提供新支付工具的注册。
5. The IOTP Application Core interrogates the fixed IOTP Payment Bridge whether the payment might complete with success ("Check Payment Possibility"). At this step, the IOTP Payment Bridge may issue several signals, e.g.,
5. IOTP应用程序核心询问固定IOTP支付桥是否可以成功完成支付（“检查支付可能性”）。在此步骤中，IOTP支付桥可能会发出多个信号，例如：。，
o payment can proceed immediately, o required peripheral inclusive of some required physical payment instrument (chip card) is unavailable, o (non-IOTP) remote party (e.g., issuer, server wallet) is not available, o wallet identifier or pass phrase is required, o expired payment instrument (or certificate), insufficient funds, or o physical payment instrument unreadable.
o 支付可以立即进行，o所需外围设备（包括某些所需的物理支付工具（芯片卡）不可用，o（非IOTP）远程方（如发卡机构、服务器钱包）不可用，o需要钱包标识符或通行短语，o支付工具（或证书）过期，资金不足，或不可读的实物支付工具。
In any erroneous case, the user should be notified and offered accurate alternatives. Most probably, the user might be offered
在任何错误情况下，应通知用户并提供准确的替代方案。最有可能的是，可能会向用户提供
o to resolve the problem, e.g., to insert another payment instrument or to verify the periphery, o to proceed (assuming its success), o to cancel the whole transaction, or
o 解决问题，例如插入另一个支付工具或验证外围设备，o继续（假设成功），o取消整个交易，或
o to suspend the transaction, e.g., initiating a nested transaction for uploading an electronic purse.
o 暂停交易，例如，启动用于上载电子钱包的嵌套交易。
If the payment software implements payment instrument selection on its own, it may request the Consumer's choice at this step.
如果支付软件自行执行支付工具选择，则可在此步骤请求消费者选择。
If the check succeeds, it returns several IOTP Brand Selection Info Elements.
如果检查成功，它将返回多个IOTP品牌选择信息元素。
6. The Steps 2 to 5 are repeated and possibly interlaced for the selection of the second payment instrument during IOTP Value Exchange transactions - this is omitted in the figure above.
6. 在IOTP价值交换交易期间，重复步骤2至步骤5并可能交错选择第二种支付工具-上图中省略了这一点。
7. The IOTP Brand Selection Component is generated and enriched with the Brand Selection Info elements. This component is transmitted to the Merchant inside a TPO Selection Block if the received IOTP message lacks the IOTP Offer Response Block. The Merchant will then respond with an IOTP Offer Response Block (following the aforementioned compilation rules).
7. IOTP品牌选择组件由品牌选择信息元素生成和丰富。如果接收到的IOTP消息缺少IOTP要约响应块，则该组件将在TPO选择块内传输给商户。商户随后将使用IOTP报价响应块进行响应（遵循上述编译规则）。
An example of how the functions in this document are used together to effect a successful payment is illustrated in the Figure 5. In the figure 5, PS0, PS1, ..., and PSn indicate the nth PayScheme Packaged Content data, and [ ] indicates optional.
图5举例说明了如何将本文档中的功能结合使用以实现成功付款。在图5中，PS0、PS1、…、和PSn表示第n个PayScheme打包的内容数据，而[]表示可选。
(Technically, two payments happen during IOTP Value Exchange transactions.)
（从技术上讲，IOTP价值交换交易期间发生两次支付。）
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB
Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB
Create and transmit Payment Request Block
Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB
Start Payment PH Response(PS2, CS=Cont.) <- IPB
Create and transmit Payment Exchange Block
Consumer Continue Process(PS2) -> IPB
Continue Process Response(PS3, CS=Cont.) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB
Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB
Create and transmit Payment Request Block
Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB
Start Payment PH Response(PS2, CS=Cont.) <- IPB
Create and transmit Payment Exchange Block
Consumer Continue Process(PS2) -> IPB
Continue Process Response(PS3, CS=Cont.) <- IPB
... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
... 继续交换支付交换，直到。。。
Payment Handler Continue Process Response([PSn], CS=End) <- IPB
Request any local payment receipt
| Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Create and transmit Payment Response Block
Terminate transaction, actively
Payment Handler Continue Process Response([PSn], CS=End) <- IPB
Request any local payment receipt
| Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Create and transmit Payment Response Block
Terminate transaction, actively
| Change Process State(State) -> IPB
| Change PS Response(State=CompletedOK) <- IPB
Consumer On receipt of final payment scheme data
| Continue Process(PSn) -> IPB
| Continue Process Response(CS=End) <- IPB
Check Payment Receipt(Receipt) -> IPB
Check Payment Receipt Response() <- IPB
Request any local payment receipt
| Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Terminate transaction, actively
| Change Process State(State) -> IPB
| Change PS Response(State=CompletedOk) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
| Change Process State(State) -> IPB
| Change PS Response(State=CompletedOK) <- IPB
Consumer On receipt of final payment scheme data
| Continue Process(PSn) -> IPB
| Continue Process Response(CS=End) <- IPB
Check Payment Receipt(Receipt) -> IPB
Check Payment Receipt Response() <- IPB
Request any local payment receipt
| Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Terminate transaction, actively
| Change Process State(State) -> IPB
| Change PS Response(State=CompletedOk) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 5. Example Payment Message Flows
图5。支付消息流示例
1. After Brand Selection and receipt of the IOTP Offer Response Block, the Consumer switches from communicating with the Merchant to communicating with the Payment Handler.
1. 在品牌选择和收到IOTP优惠响应块后，消费者从与商户通信切换到与支付处理程序通信。
This might be a milestone requiring the renewed Consumer's agreement about the payment transaction's continuation. Particularly, this is a good moment for payment suspension (and even cancellation), which will be most probably supported by all payment schemes. Simply, because the actual payment legacy systems have not yet been involved in the current transaction.
这可能是一个里程碑，要求消费者就支付交易的继续达成新的协议。特别是，现在是暂停付款（甚至取消付款）的好时机，所有付款计划都很可能支持暂停付款（甚至取消付款）。简单地说，因为当前交易中尚未涉及实际的支付遗留系统。
Such an agreement might be explicit per transaction or automatic based on configured preferences, e.g., early acknowledgments for specific payment limits.
这种协议可以是每笔交易的明确协议，也可以是基于配置的首选项的自动协议，例如，特定支付限额的早期确认。
It is assumed, that the transaction proceeds with minimal user (Consumer and Payment Handler) interaction and that its progress is controlled by the IOTP Application Core and IOTP Payment Bridge.
假设交易以最小的用户（消费者和支付处理人）交互进行，其进度由IOTP应用程序核心和IOTP支付桥控制。
2. In order to open the actual payment transaction, the IOTP Application Core issues the "Start Payment Consumer" request towards the IOTP Payment Bridge. This request carries the whole initialization data of the payment transaction being referred to by the IOTP Payment Bridge for subsequent consistency checks:
2. 为了打开实际的支付交易，IOTP应用核心向IOTP支付桥发出“启动支付消费者”请求。此请求包含IOTP支付桥引用的支付交易的全部初始化数据，以进行后续一致性检查：
o payment brand and its description from the selected Brand Element of the IOTP Brand List Component, o payment instrument from preceding inquiry step,
o IOTP品牌列表组件中所选品牌元素中的支付品牌及其描述，o前一查询步骤中的支付工具，
o further payment parameters (currency, amount, direction, expiration) from the selected Currency Amount element, Brand List Component, and Payment Component of the IOTP Offer Response Block, o payment protocol from the selected IOTP Pay Protocol Element, o order details contained in the IOTP Order Component which might be payment scheme specific, o payment scheme specific data inclusive of the payment protocol descriptions from the IOTP Protocol Amount Element, and IOTP Pay Protocol Element, and o payment scheme specific data inclusive of the payment protocol descriptions, in which the name attribute includes the prefix as "Payment:" from the Trading Role Data Component.
o IOTP报价响应块的选定货币金额元素、品牌列表组件和支付组件中的其他支付参数（货币、金额、方向、到期），o选定IOTP支付协议元素中的支付协议，o IOTP订单组件中包含的订单详细信息，可能是特定于支付方案的，o包含来自IOTP协议金额元素和IOTP支付协议元素的支付协议描述的特定于支付方案的数据，以及o包含支付协议描述的特定于支付方案的数据，其中name属性包含来自交易角色数据组件的前缀“payment:”。
Generally, the called API function re-does most checks of the "Check Payment Possibility" call due to lack of strong dependencies between both requests: There might be a significant delay between both API requests.
通常，由于两个请求之间缺乏强烈的依赖关系，被调用的API函数会重新执行“检查支付可能性”调用的大多数检查：两个API请求之间可能存在显著的延迟。
The called API function may return further payment scheme specific data being considered as payment specific initialization data for the Payment Handler's IOTP Payment Bridge.
被调用的API函数可以返回更多的特定于支付方案的数据，这些数据被视为支付处理程序的IOTP支付桥的特定于支付的初始化数据。
If the fixed Existing Payment Software implements payment instrument selection on its own, it may request the Consumer's choice at this step.
如果固定现有支付软件自行执行支付工具选择，则可在此步骤请求消费者选择。
The IOTP Payment Bridge reports lack of capability quite similarly to the "Check Payment Possibility" request to the IOTP Application Core. The Consumer may decide to resolve the problem, to suspend, or to cancel the transaction, but this function call must succeed in order to proceed with the transaction.
IOTP支付桥报告的能力不足与IOTP应用核心的“检查支付可能性”请求非常类似。消费者可能决定解决问题、暂停或取消交易，但此函数调用必须成功才能继续交易。
Developers of payment modules may decide to omit payment instrument related checks like expiration date or refunds sufficiency, if such checks are part of the specific payment protocol.
支付模块的开发者可以决定省略与支付工具相关的检查，如到期日或退款充分性，如果这些检查是特定支付协议的一部分。
If the IOTP Payment Bridge requests wallet identifiers or pass phrases anywhere during the payment process, they should be requested by this API function, too. It is recommended that the IOTP Application Core stores plain text pass phrases only in runtime memory.
如果IOTP支付网桥在支付过程中的任何位置请求钱包标识符或传递短语，则此API函数也应请求它们。建议IOTP应用程序核心仅在运行时内存中存储纯文本密码短语。
Finally, the IOTP Application Core generates the IOTP Payment Request Block, inserts any returned payment scheme data, and submits it to the Payment Handler's system.
最后，IOTP应用程序核心生成IOTP支付请求块，插入任何返回的支付方案数据，并将其提交给支付处理程序的系统。
3. The Payment Handler's IOTP Application Core opens the payment transaction calling the "Start Payment Payment Handler" API function. The payment brand, its description, payment protocol, payment specific data, payment direction, currency and payment amount are determined quite similar to the Consumer's IOTP Application Core. Furthermore, the content of the IOTP Payment Scheme Component and the IOTP Brand Selection Info Elements are passed to this function.
3. 支付处理程序的IOTP应用程序核心打开支付事务，调用“启动支付处理程序”API函数。支付品牌、其描述、支付协议、支付特定数据、支付方向、货币和支付金额的确定与消费者的IOTP应用核心非常相似。此外，IOTP支付方案组件的内容和IOTP品牌选择信息元素被传递给该功能。
On success, the Payment Handler's IOTP Payment Bridge responds with payment scheme specific data. On failures, this non-interactive server application has to resolve any problems on its own or to give up aborting the payment transaction. However, the Consumer may restart the whole payment transaction. Anyway, the payment log file should reflect any trials of payments.
成功后，支付处理程序的IOTP支付桥将使用特定于支付方案的数据进行响应。失败时，此非交互式服务器应用程序必须自行解决任何问题，或放弃中止支付交易。但是，消费者可以重新启动整个支付交易。无论如何，付款日志文件应该反映任何付款尝试。
Eventually, the Payment Handler informs the Consumer about the current IOTP Process State using the IOTP Payment Response or IOTP Error Block.
最终，支付处理程序使用IOTP支付响应或IOTP错误块通知消费者当前IOTP过程状态。
Note that the "Start Payment Payment Handler" call might return the Continuation Status "End" such that payment processing proceeds with Step 7.
请注意，“开始付款处理程序”调用可能返回继续状态“结束”，以便付款处理继续执行步骤7。
4. The IOTP Application Core verifies the presence of the Payment Exchange Block in the IOTP message and passes the contained payment scheme specific data to the fixed IOTP Payment Bridge ("Continue Process") which returns the next IOTP Payment Scheme Component.
4. IOTP应用程序核心验证IOTP消息中是否存在支付交换块，并将包含的支付方案特定数据传递给固定IOTP支付桥（“继续处理”），后者返回下一IOTP支付方案组件。
This Payment Scheme Component is encapsulated in an IOTP Payment Exchange Block and transmitted to the Payment Handler.
此支付方案组件封装在IOTP支付交换块中，并传输到支付处理程序。
5. The Payment Handler's IOTP Application Core verifies the presence of the Payment Exchange Block and passes the contained payment scheme specific data to the fixed IOTP Payment Bridge ("Continue Process") which returns the next IOTP Payment Scheme Component for encapsulation and transmission to the Consumer.
5. 支付处理程序的IOTP应用程序核心验证支付交换块的存在，并将包含的特定于支付方案的数据传递给固定IOTP支付桥（“继续处理”），该桥返回下一个IOTP支付方案组件，以便封装和传输给消费者。
6. The payment process continues with IOTP Payment Exchange Block exchanges, carrying the payment scheme specific data. Each party (1) submits the embedded payment scheme specific data transparently to the appropriate IOTP Payment Bridge calling the "Continue Process" API function, (2) wraps the returned payment scheme specific data into an IOTP Payment Exchange Block, and (3) transmits this block to the counter party.
6. 支付过程继续进行IOTP支付交换区块交换，携带特定于支付方案的数据。各方（1）通过调用“继续处理”API函数，将嵌入式支付方案特定数据透明地提交给相应的IOTP支付网桥，（2）将返回的支付方案特定数据包装到IOTP支付交换块中，（3）将该块传输给对方。
However, the processing of the payment scheme specific data may fail for several reasons. These are signaled by specific error codes which are transformed to IOTP Payment Response Blocks (generated by Payment Handler) or IOTP Error Blocks (both parties may generate them) and transmitted to the counter party.
但是，由于多种原因，支付方案特定数据的处理可能会失败。这些由特定错误代码发出信号，这些错误代码被转换为IOTP支付响应块（由支付处理程序生成）或IOTP错误块（双方均可生成）并传输给对方。
7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes the termination of the payment transaction and reports this by the continuation status "End" on the output parameter of "Continue Process" (or "Start Payment Payment Handler"). Then, the IOTP Application Core issues the "Inquire Process State" API call and verifies whether an IOTP Payment Receipt Component has been returned. The IOTP Application Core wraps the payment receipt, the status response, and the optional payment scheme specific data in an IOTP Payment Response Block and transmits this block to the Consumer.
7. 最终，支付处理程序的IOTP支付桥接器识别支付交易的终止，并通过“继续处理”（或“开始支付处理程序”）输出参数上的持续状态“结束”报告该终止。然后，IOTP应用程序核心发出“查询流程状态”API调用，并验证是否已返回IOTP付款收据组件。IOTP应用程序核心将付款收据、状态响应和可选的付款方案特定数据封装在IOTP付款响应块中，并将该块传输给消费者。
However, any of these API calls may fail or any response might be incomplete (e.g., lack of payment receipt). Then, the Consumer has to be notified about the failed processing by an IOTP Error Block.
但是，这些API调用中的任何一个都可能失败，或者任何响应都可能不完整（例如，缺少付款收据）。然后，必须通过IOTP错误块通知消费者处理失败。
Finally, the Payment Handler terminates the payment transaction with the "Change Process State" API call without awaiting any further response from the Consumer. Further failures are not reported to the Consumer.
最后，支付处理程序使用“ChangeProcessState”API调用终止支付事务，而无需等待消费者的任何进一步响应。进一步的故障不会报告给消费者。
Note that it might be possible that the Consumer's IOTP Payment Bridge has returned the previous payment scheme specific data with the continuation status "End". Even in the absence of this knowledge - this status is not exchanged between the Consumer and the Payment Handler - the Payment Handler must not supply any further payment scheme specific data. Such data will be rejected by the Consumer's IOTP Payment Bridge.
请注意，消费者的IOTP支付桥接器可能已返回先前的支付方案特定数据，且继续状态为“结束”。即使在没有这方面知识的情况下（消费者和支付处理人之间不交换此状态），支付处理人也不得提供任何其他特定于支付方案的数据。此类数据将被消费者的IOTP支付桥拒绝。
8. The Consumer passes the optional payment scheme specific data and the payment receipt to the fixed IOTP Payment Bridge by "Continue Process" and "Check Payment Receipt" API calls.
8. 消费者通过“继续处理”和“检查付款收据”API调用将可选的付款方案特定数据和付款收据传递给固定IOTP付款桥。
Afterwards, the IOTP Application Core issues the "Inquire Process State" API call and verifies whether extensions to the payment receipt have been returned.
之后，IOTP应用程序核心发出“Inquire Process State”API调用，并验证是否已返回付款收据的扩展。
Finally, the transaction is terminated by calling the "Change Process State" API function which verifies and synchronizes the reported payment status with the local one and signals any inconsistencies. Any Inconsistency and returned status text should be displayed to the Consumer.
最后，通过调用“Change Process State”API函数终止交易，该函数验证并同步报告的支付状态与本地支付状态，并发出任何不一致的信号。应向消费者显示任何不一致和返回的状态文本。
At this point, the payment transaction has already been closed by the Payment Handler. Therefore, any failure has to be resolved locally or out-of-band.
此时，支付处理程序已关闭支付交易。因此，任何故障都必须在本地或带外解决。
In Baseline IOTP, Payment inquiries are initiated by the Consumer in order to verify the current payment progress and process state at the remote Payment Handler. In the figure 6, PS1 and PS2 indicate the first and second PayScheme Packaged Content data, and [ ] indicates optional.
在基线IOTP中，消费者发起付款查询，以验证远程付款处理程序的当前付款进度和流程状态。在图6中，PS1和PS2表示第一个和第二个PayScheme打包内容数据，[]表示可选。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Inquiry() -> IPB
Start Payment Inquiry Response([PS1]) <- IPB
Create and transmit Inquiry Request Trading Block
Payment Handler Inquire Payment Status([PS1]) -> IPB
Inquire Payment Status Res.(State, [PS2]) -> IPB
Create and transmit Inquiry Response Trading
Block
Consumer If Payment Scheme Data present
| Continue Process(PS2) -> IPB
| Continue Process Response(CS=End) <- IPB
Change Process State(State) -> IPB
Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Inquiry() -> IPB
Start Payment Inquiry Response([PS1]) <- IPB
Create and transmit Inquiry Request Trading Block
Payment Handler Inquire Payment Status([PS1]) -> IPB
Inquire Payment Status Res.(State, [PS2]) -> IPB
Create and transmit Inquiry Response Trading
Block
Consumer If Payment Scheme Data present
| Continue Process(PS2) -> IPB
| Continue Process Response(CS=End) <- IPB
Change Process State(State) -> IPB
Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 6. Remote Process State Inquiry
图6。远程进程状态查询
1. The Consumer might initiate a payment inquiry once the payment transaction has been opened by the IOTP Application Core, i.e., at any time after the initial submission of the IOTP Payment Request Block. The IOTP Application Core requests any additional specific payment scheme data from the IOTP Payment Bridge which has been fixed during brand selection (cf. Section 2.3) using the "Start Payment Inquiry" API request.
1. 一旦IOTP应用程序核心打开支付交易，即在初始提交IOTP支付请求块之后的任何时间，消费者可以发起支付查询。IOTP应用程序核心从IOTP支付桥请求任何额外的特定支付方案数据，该数据已在品牌选择期间（参见第2.3节）使用“开始支付查询”API请求修复。
Erroneous API responses should be reported to the Consumer and valid alternatives (typically retry and cancellation) should be presented by the IOTP Application Core.
应向消费者报告错误的API响应，IOTP应用程序核心应提供有效的替代方案（通常为重试和取消）。
This request might perform the complete initialization, e.g., availability check of periphery or pass phrase supplement, and the IOTP Payment Bridge reports lack of capability quite similarly to the "Check Payment Possibility" request to the IOTP Application Core.
该请求可能会执行完整的初始化，例如外围设备的可用性检查或通行短语补充，而IOTP支付桥报告的能力不足与向IOTP应用核心发出的“检查支付可能性”请求非常类似。
If the IOTP Payment Bridge requests wallet identifiers or pass phrases anywhere during the payment process, they should be requested by this API function, too. It is recommended that the IOTP Application Core store plain text pass phrases only in runtime memory.
如果IOTP支付网桥在支付过程中的任何位置请求钱包标识符或传递短语，则此API函数也应请求它们。建议IOTP应用程序核心仅在运行时内存中存储纯文本密码短语。
The IOTP Application Core encapsulates any Payment Scheme Component in an IOTP Inquiry Request Block and submits the block to the Payment Handler.
IOTP应用程序核心将任何支付方案组件封装在IOTP查询请求块中，并将该块提交给支付处理程序。
2. The Payment Handler analyses the IOTP Inquire Request Block, maps the Transaction Identifier to payment related attributes (brand, consumer and payment identifiers), determines the appropriate IOTP Payment Bridge, and forwards the request to the this IOTP Payment Bridge ("Inquire Payment Status"). The IOTP Application Core transforms the response to an IOTP Inquiry Response Block and transmits it to the Consumer.
2. 支付处理程序分析IOTP查询请求块，将交易标识符映射到支付相关属性（品牌、消费者和支付标识符），确定适当的IOTP支付桥，并将请求转发到此IOTP支付桥（“查询支付状态”）。IOTP应用程序核心将响应转换为IOTP查询响应块，并将其传输给消费者。
3. On receipt of the respective IOTP Inquiry Response Block the Consumer's IOTP Application Core submits any encapsulated payment scheme specific data to the IOTP Payment Bridge for verification ("Continue Process").
3. 在收到相应的IOTP查询响应块后，消费者的IOTP应用程序核心将任何封装的支付方案特定数据提交给IOTP支付桥进行验证（“继续处理”）。
4. The IOTP Application Core passes the reported payment status (except textual descriptions) to the IOTP Payment Bridge ("Change Process State") for verification purposes and payment status change. The IOTP Payment Bridge reports any inconsistencies as well as the final payment status to the IOTP Application Core.
4. IOTP应用程序核心将报告的支付状态（文本描述除外）传递给IOTP支付桥（“变更流程状态”），以进行验证和支付状态变更。IOTP支付桥向IOTP应用程序核心报告任何不一致以及最终支付状态。
Any additional information that might be of interest to the Consumer has to be displayed by the IOTP Payment Bridge or Existing Payment Software on their own.
消费者可能感兴趣的任何附加信息必须由IOTP支付桥或现有支付软件自行显示。
The IOTP specification distinguishes between several classes of failures:
IOTP规范区分了几类故障：
o Business and technical errors o Error depths of transport, message and block level o Transient errors, warnings, and hard errors.
o 业务和技术错误o传输错误深度、消息和块级别o暂时错误、警告和硬错误。
Any IOTP Payment API has to deal with the receipt of failure notifications by and failure responses. This proposal has borrowed the basic mechanisms for error reporting between the IOTP Application Core and the IOTP Payment Bridge from the actual protocol: Business
任何IOTP支付API都必须处理接收故障通知和故障响应。本提案借用了IOTP应用程序核心和IOTP支付桥之间错误报告的基本机制，来自实际协议：业务
errors are reported by Status Components within IOTP Response Blocks while technical errors are signaled by Error Components within IOTP Error Blocks.
IOTP响应块内的状态组件报告错误，而IOTP错误块内的错误组件发出技术错误信号。
Cancellations are mimicked as specific business errors which might be initiated by each trading party.
取消被模拟为每个交易方可能发起的特定业务错误。
Preferring slim interfaces, this IOTP Payment API introduces one additional Error Code value for business error indication - errors can be raised on every API call. On receipt of this value, the IOTP Application Core has to infer further details by the issuance of the API function call "Inquire Process State".
IOTP支付API更倾向于使用超薄接口，它为业务错误指示引入了一个额外的错误代码值——每次API调用都会引发错误。收到该值后，IOTP应用程序核心必须通过发出API函数调用“Inquire Process State”来推断进一步的细节。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Issue some API request -> IPB
Error Response(Error Code) <- IPB
On "Business Error" response
| Inquire Process State() -> IPB
| Inquire P.S. Resp.(State, Receipt) <- IPB
Analyze local process state and try to resolve
with optional user interaction
If Process State Change needed
| Change Process State (State) -> IPB
| Change Process State Response(State) <- IPB
If counter party's notification required
| Create Error or Cancel Block (, add to next
| message, ) and transmit it to counter party
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Issue some API request -> IPB
Error Response(Error Code) <- IPB
On "Business Error" response
| Inquire Process State() -> IPB
| Inquire P.S. Resp.(State, Receipt) <- IPB
Analyze local process state and try to resolve
with optional user interaction
If Process State Change needed
| Change Process State (State) -> IPB
| Change Process State Response(State) <- IPB
If counter party's notification required
| Create Error or Cancel Block (, add to next
| message, ) and transmit it to counter party
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 7. Error Response from IPB
图7。来自IPB的错误响应
The specific Completion Codes "ConsCancelled", "MerchCancelled", and "PaymCancelled" - returned by "Inquire Process State" - determine that the IOTP Cancel Block has to be created instead of an IOTP Error Block.
“查询进程状态”返回的特定完成代码“ConsCancelled”、“MerchCancelled”和“PaymCancelled”确定必须创建IOTP取消块而不是IOTP错误块。
The rules for determining the required behavior of the IOTP Application Core are given in the IOTP specification.
IOTP规范中给出了确定IOTP应用程序核心所需行为的规则。
Note that any payment (intermediate) termination, i.e., failures, cancellations, and even successes are always reported to the IOTP Payment Bridge by the API function "Change Process State". This API function does both status changes and consistency checking / synchronization. Any suspicion of inconsistency should be reported by the IOTP Payment Bridge for display by the IOTP Application Core.
请注意，任何支付（中间）终止，即失败、取消，甚至成功，总是通过API函数“更改流程状态”报告给IOTP支付桥。此API函数执行状态更改和一致性检查/同步。IOTP支付桥应报告任何不一致的怀疑，以供IOTP应用核心显示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Error Block or Cancel Block Received
If Change Process State required
| Change Process State (State) -> IPB
| Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Error Block or Cancel Block Received
If Change Process State required
| Change Process State (State) -> IPB
| Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 8. Error Notification from counter party
图8。来自对方的错误通知
Not every failure might be visible at the IOTP layer, e.g., the processing of payment transactions might temporarily be hampered by intermediate failures at the payment scheme or protocol transport layer which might be resolved by the actual components.
并非所有故障都在IOTP层可见，例如，支付方案或协议传输层的中间故障可能会暂时阻碍支付交易的处理，而这些故障可能由实际组件解决。
However, final failures or cancellations have to be reported at the IOTP layer. E.g., communication time-outs and heavily faulty communication channels may disable the transaction.
但是，最终故障或取消必须在IOTP层报告。例如，通信超时和严重故障的通信通道可能会禁用事务。
Any system component may implement time-out recognition and use the aforementioned API mechanisms for the notification of process state changes. But, time-outs may happens while communicating with both the counter party and local system components, like chip card readers or IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core should notify the Consumer about the resolution alternatives, i.e., retry, suspension, and cancellation.
任何系统组件都可以实现超时识别，并使用上述API机制通知进程状态更改。但是，与对方和本地系统组件（如芯片卡读卡器或IOTP支付桥）通信时可能会发生超时。无论如何，消费者的IOTP应用程序核心应通知消费者解决方案备选方案，即重试、暂停和取消。
Payment transaction resumption may apply at different steps of a payment transaction:
支付交易恢复可能适用于支付交易的不同步骤：
o The Consumer's and Payment Handler's view of the transaction might not be synchronized: Due to different time-out values the payment transaction may not have been suspended by the counter party.
o 消费者和支付处理程序的交易视图可能不同步：由于不同的超时值，支付交易可能未被对方暂停。
Any "Resume Payment ..." API function responds with an Error Code on non-suspended payment transaction that signals a business error. Afterwards the IOTP Application Core has to issue the "Inquire Process State" API call for further analysis of the process state.
任何“恢复支付…”API函数都会在未暂停的支付交易上响应一个错误代码，表示业务错误。之后，IOTP应用程序核心必须发出“查询进程状态”API调用，以进一步分析进程状态。
o One IOTP message sent by one party might not be processed successfully or even received by the counter party. This needs to be handled by the actual payment scheme. It is expected that the IOTP Application Core will not recognize anything.
o 一方发送的一条IOTP消息可能无法成功处理，甚至无法被对方接收。这需要由实际的支付方案来处理。预计IOTP应用程序核心不会识别任何东西。
o IOTP does not provide any specific signal for payment resumption. On receipt of every IOTP Payment Exchange Block, the IOTP Application Core has to decide whether this Block belongs to a pending transaction or to a suspended transaction that should be resumed. The IOTP Application Core might call the "Inquire Process State" API function to update any lack of knowledge.
o IOTP不提供任何恢复支付的具体信号。收到每个IOTP支付交换块后，IOTP应用程序核心必须决定该块属于未决交易还是应恢复的暂停交易。IOTP应用程序核心可能会调用“查询进程状态”API函数来更新任何缺乏的知识。
Any "Resume Payment" API function responds with an Error Code on non-suspended payment transaction that signals a business error. Similar, the "Continue Process" API function should report business errors on non-pending payment transactions.
任何“恢复支付”API函数都会在未暂停的支付交易上响应一个错误代码，表示业务错误。类似地，“Continue Process”API函数应该报告非挂起支付交易的业务错误。
o The payment transaction may not have been created at the Payment Handler (early suspension and failed data transmission). In that case, the IOTP Application Core should respond with a business error that signals the repetition of the payment transaction (by the Consumer).
o 支付交易可能尚未在支付处理程序中创建（提前暂停和数据传输失败）。在这种情况下，IOTP应用程序核心应响应一个业务错误，表示（消费者）重复支付交易。
Any "Resume Payment", "Continue Process" or "Inquire Process State" API function should return with an Error Code "AttValIllegal" on non-existent payment transaction whereby the further Error Attribute "Names" denote the payment identifier.
对于不存在的支付交易，任何“恢复支付”、“继续处理”或“查询处理状态”API函数都应返回错误代码“AttValIllegal”，其中进一步的错误属性“Names”表示支付标识符。
o The IOTP Application Core should always request fresh payment scheme specific data on resumption - for synchronization purposes with the Existing Payment Software. Old data in the cache that has not been sent to the counter party should not be accessed.
o IOTP应用核心应始终在恢复时请求新的支付方案特定数据，以便与现有支付软件同步。缓存中未发送给对方的旧数据不应被访问。
If the Consumer does not reconnect within an acceptable amount of time, the Payment Handler's system may perform local failure resolution in order to close the transaction and to retain resources for other transactions ("Change Process State"). If the Consumer reconnect afterwards, an IOTP Payment Response or IOTP Error Block could be generated.
如果消费者未在可接受的时间内重新连接，则支付处理程序的系统可能会执行本地故障解决，以关闭交易并保留其他交易的资源（“更改流程状态”）。如果消费者随后重新连接，可能会生成IOTP支付响应或IOTP错误块。
At startup or on explicit user request the IOTP Application Core should check its IOTP Payment Bridges' internal status by searching for pending payment transactions.
在启动时或根据明确的用户请求，IOTP应用程序核心应通过搜索未决支付交易来检查其IOTP支付桥的内部状态。
1. The IOTP Application Core interrogates the registered IOTP Payment Bridges about pending payment transactions. The IOTP Application Core may store indicators for pending transactions and use them for driving any subsequent inquiry ("Inquire Pending Payment").
1. IOTP应用程序核心询问已注册的IOTP支付桥有关未决支付交易。IOTP应用程序核心可存储未决交易的指标，并将其用于驱动任何后续查询（“查询未决支付”）。
2. If one or more IOTP Payment Bridges report the presence of pending transactions, the IOTP Application Core may try to suspend ("Change Process State") or resume (only Consumer: "Resume Payment Consumer") the pending transactions (on user request).
2. 如果一个或多个IOTP支付桥报告存在未决交易，则IOTP应用核心可尝试暂停（“更改流程状态”）或恢复（仅消费者：“恢复支付消费者”）未决交易（根据用户请求）。
The IOTP Payment Bridge may deny the processing of any new payment transactions until the pending transactions have been processed. Such denials are signaled by the error code "Business Error".
IOTP支付桥可拒绝处理任何新的支付交易，直到未决交易得到处理。此类拒绝由错误代码“业务错误”表示。
The IOTP Application Core provides only a simple and generic interface for the registration of new payment methods / instruments ("Manage Payment Software"). It receives the initial user request and defers the actual registration to the corresponding IOTP Payment Bridge.
IOTP应用程序核心仅提供一个简单通用的界面，用于注册新的支付方法/工具（“管理支付软件”）。它接收初始用户请求，并将实际注册延迟到相应的IOTP支付桥。
The IOTP Application Core may also activate the Existing Payment Software for further payment instrument and wallet administration.
IOTP应用核心还可以激活现有的支付软件，用于进一步的支付工具和钱包管理。
The Payment API is formalized using the eXtensible Markup Language (XML). It defines wrapper elements for both the input parameters and the API function's response. In particular, the response wrapper provides common locations for Error Codes and Error Descriptions.
支付API是使用可扩展标记语言（XML）形式化的。它为输入参数和API函数的响应定义包装器元素。特别是，响应包装器为错误代码和错误描述提供了公共位置。
It is anticipated that this description reflects the logical structure of the API parameter and might be used to derive implementation language specific API definitions.
预计该描述反映了API参数的逻辑结构，并可用于派生特定于实现语言的API定义。
XML definition:
XML定义：
<!ELEMENT IotpPaymentApiRequest ( FindAcceptedPaymentBrand | FindAcceptedPaymentProtocol | GetPaymentInitializationData | FindPaymentInstrument | CheckPaymentPossiblity | StartPaymentConsumer | StartPaymentPaymentHandler | ResumePaymentConsumer | ResumePaymentPaymentHandler | ContinueProcess | InquireProcessState | ChangeProcessState | InquireAuthChallenge | Authenticate |
<!元素IotpPaymentApiRequest（FindAcceptedPaymentBrand | FindAcceptedPaymentProtocol | GetPaymentInitializationData | FindPaymentInstrument |支票支付可能性| StartPaymentConsumer | StartPaymentPaymentHandler | ResumPaymentConsumer | ResumePaymentPaymentPaymentHandler |持续处理|查询处理状态|更改处理状态|查询授权质疑|验证）|
CheckAuthResponse | CheckPaymentReceipt | ExpandPaymentReceipt | RemovePaymentLog | PaymentInstrumentInquiry | InquirePendingPayment | ManagePaymentSoftware | StartPaymentInquiry | InquirePaymentStatus | CallBack )>
CheckAuthResponse | CheckPaymentReceipt | ExpandPaymentReceipt | RemovePaymentLog | PaymentInstrumentInquiry | InquiredPendingPayment | ManagePaymentSoftware | StartPaymentRequesty | InquiredPaymentStatus | CallBack）>
<!ATTLIST IotpPaymentApi
xml:lang NMTOKEN #IMPLIED
ContentSoftwareID CDATA #IMPLIED
xmlns CDATA #FIXED
"http://www.iotp.org/2000/08/PaymentAPI" >
<!ATTLIST IotpPaymentApi
xml:lang NMTOKEN #IMPLIED
ContentSoftwareID CDATA #IMPLIED
xmlns CDATA #FIXED
"http://www.iotp.org/2000/08/PaymentAPI" >
<!ELEMENT IotpPaymentApiResponse (ErrorResponse?, ( FindAcceptedPaymentBrandResponse | FindAcceptedPaymentProtocolResponse | GetPaymentInitializationDataResponse | FindPaymentInstrumentResponse | CheckPaymentPossiblityResponse | StartPaymentConsumerResponse | StartPaymentPaymentHandlerResponse | ResumePaymentConsumerResponse | ResumePaymentPaymentHandlerResponse | ContinueProcessResponse | InquireProcessStateResponse | ChangeProcessStateResponse | InquireAuthChallengeResponse | AuthenticateResponse | CheckAuthResponseResponse | CheckPaymentReceiptResponse | ExpandPaymentReceiptResponse | RemovePaymentLogResponse | PaymentInstrumentInquiryResponse | InquirePendingPaymentResponse | ManagePaymentSoftwareResponse | StartPaymentInquiryResponse | InquirePaymentStatusResponse | CallBackResponse )?)>
<!元素IoTPaymentaPiResponse（错误响应？，（FindAcceptedPaymentBrandResponse | FindAcceptedPaymentProtocolResponse | GetPaymentInitializationDataResponse | FindPaymentInstrumentResponse |支票支付可能性响应|开始支付消费者响应| ResumePaymentPaymentHandlerResponse | Response | Response | Response |继续处理响应|eProcessStateResponse | ChangeProcessStateResponse | InquirementAuthChallengeResponse | AuthenticateResponse | CheckAuthResponse | CheckPaymentReceiptResponse | ExpandPaymentReceiptResponse | RemovePaymentLogResponse | PaymentInstruments Inquirements | InquirementPaymentPaymentPaymentResponse | InquirementPaymentPaymentPaymentResponse| InquirePaymentStatusResponse | CallBackResponse）？）>
<!ATTLIST IotpPaymentApiResponse
xml:lang NMTOKEN #IMPLIED
ContentSoftwareID CDATA #IMPLIED
xmlns CDATA #FIXED
"http://www.iotp.org/2000/08/PaymentAPI" >
<!ATTLIST IotpPaymentApiResponse
xml:lang NMTOKEN #IMPLIED
ContentSoftwareID CDATA #IMPLIED
xmlns CDATA #FIXED
"http://www.iotp.org/2000/08/PaymentAPI" >
<!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) >
<!ATTLIST ErrorResponse
xml:lang NMTOKEN #IMPLIED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity(Warning |
TransientError |
HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) >
<!ATTLIST ErrorResponse
xml:lang NMTOKEN #IMPLIED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity(Warning |
TransientError |
HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
Most of the attribute items are intended for immediate insertion in the IOTP Error Block. The attribute values of the Error Location elements attribute have to enriched and transformed into Error Location Elements of the Error Component (cf. IOTP Specification).
大多数属性项用于立即插入IOTP错误块。错误位置元素属性的属性值必须丰富并转换为错误组件的错误位置元素（参见IOTP规范）。
Attributes (cf. IOTP Specification):
属性（参见IOTP规范）：
xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element.
xml:lang定义此组件中的属性或子元素所使用的语言，除非被子元素上的xml:lang属性覆盖。
ContentSoftwareId Contains information which identifies the software that generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by "xml:lang". It must contain, as a minimum problems that might occur as a result of
ContentSoftwareId包含标识生成元素内容的软件的信息。其目的是帮助解决由于不同软件生成的消息之间不兼容而可能出现的互操作性问题。它是由“xml:lang”定义的语言中的单个文本字符串。它必须至少包含由于以下原因而可能出现的问题：
o the name of the software manufacturer, o the name of the software, o the version of the software, and o the build of the software.
o 软件制造商的名称、软件的名称、软件的版本和软件的版本。
ErrorCode Contains an error code which indicates the nature of the error in the message in error. Valid values for the Error Code are given in the following section. This mnemonic enables the automatic failure resolution of the IOTP Application Core which analyzes the error code value in order to determine the continuation alternatives.
ErrorCode包含一个错误代码，指示出错消息中错误的性质。以下部分给出了错误代码的有效值。该助记符支持IOTP应用程序核心的自动故障解决，该应用程序核心分析错误代码值，以确定继续替代方案。
ErrorDesc Contains a description of the error in the language defined by xml:lang. The content of this attribute is defined by the vendor/developer of the software that generated the Error Response Element. It is intended for user display and provides detailed explanations about the failure and its (out-of-band) resolution alternatives.
ErrorDesc包含用xml:lang定义的语言描述的错误。此属性的内容由生成错误响应元素的软件的供应商/开发人员定义。它用于用户显示，并提供有关故障及其（带外）分辨率备选方案的详细说明。
Severity Indicates the severity of the error. Valid values are:
严重性指示错误的严重性。有效值为：
o Warning. This indicates that although there is a message in error the IOTP Transaction can still continue.
o 警告这表明，尽管存在错误消息，但IOTP事务仍可以继续。
o TransientError. This indicates that the error in the message in error may be recovered if the message in error that is referred to by the "Names" attribute is resent.
o Transinerror。这表明，如果重新发送“名称”属性所引用的错误消息，则可能会恢复错误消息中的错误。
o HardError. This indicates that there is an unrecoverable error in the message in error and the IOTP Transaction must stop.
o 硬错误。这表示错误消息中存在不可恢复的错误，必须停止IOTP事务。
MinRetrySecs This attribute should be present if "Severity" is set to "TransientError". It is the minimum number of whole seconds which the IOTP aware application which received the message reporting the error should wait before resending the message in error identified by the "ErrorLocation" attribute.
MinRetrySecs如果“严重性”设置为“TransientError”，则此属性应存在。它是接收到报告错误消息的IOTP感知应用程序在重新发送由“ErrorLocation”属性标识的错误消息之前应等待的最小整秒数。
If Severity is not set to "TransientError" then the value of this attribute is ignored.
如果严重性未设置为“TransientError”，则忽略此属性的值。
SwVendorErrorRef This attribute is a reference whose value is set by the vendor/developer of the software that generated the Error Element. It should contain data that enables the vendor to identify the precise location in their software and the set of circumstances that caused the software to generate a message reporting the error.
SwVendorErrorRef此属性是一个引用，其值由生成错误元素的软件的供应商/开发人员设置。它应包含数据，使供应商能够识别其软件中的精确位置，以及导致软件生成报告错误的消息的一组情况。
Content:
内容：
ErrorLocation This identifies, where possible, the element and attribute in the message in error that caused the Error Element to be generated. If the "Severity" of the error is not "TransientError", more that one "ErrorLocation" may be specified as appropriate depending on the nature of the error and at the discretion of the vendor/developer of the IOTP Payment Bridge.
ErrorLocation在可能的情况下，标识导致生成错误元素的错误消息中的元素和属性。如果错误的“严重性”不是“TransientError”，则根据错误的性质以及IOTP支付桥的供应商/开发商的决定，可酌情指定多个“错误位置”。
Its definition coincides with the IOTP specification whereby the attributes "IotpMsgRef", "BlkRef" and "CompRef" are left blank, intentionally.
其定义与IOTP规范一致，其中属性“IotpMsgRef”、“BlkRef”和“CompRef”故意留空。
PaySchemePackagedContent cf. Table 5
付款方案包装内容参见表5
The following table lists the valid values for the ErrorCode attribute of the Error Response Element. The first sentence of the error description contains the default text that can be used to describe the error when displayed or otherwise reported. Individual implementations may translate this into alternative languages at their discretion. However, not every error code may apply to every API call. An Error Code must not be more than 14 characters long. The Error Codes have been taken from the IOTP Specification and extended by some additional codes which are highlighted by a preceding asterisk.
下表列出了错误响应元素的ErrorCode属性的有效值。错误描述的第一句包含默认文本，可用于在显示或以其他方式报告时描述错误。个别实现可自行决定将其转换为其他语言。然而，并非每个错误代码都适用于每个API调用。错误代码的长度不得超过14个字符。错误代码取自IOTP规范，并通过一些附加代码进行扩展，这些代码由前面的星号突出显示。
Generally, if the corrupt values have been user supplied, the IOTP Application Core might prompt for their correction. If the renewal fails or if the IOTP Application Core skips any renewals and some notification has to be send to the counter-party, the error code is encapsulated within an IOTP Error Block.
通常，如果用户提供了损坏的值，IOTP应用程序核心可能会提示更正。如果续订失败或IOTP应用程序核心跳过任何续订，并且必须向对方发送一些通知，则错误代码将封装在IOTP错误块中。
However, the IOTP server application reports business errors - visible at the IOTP layer - in the Status Component of the respective Response Block.
但是，IOTP服务器应用程序在相应响应块的状态组件中报告业务错误（在IOTP层可见）。
The IOTP Application Core may add the attributes (and values) within the ErrorLocation elements that are omitted by the IOTP Payment Bridge.
IOTP应用程序核心可在IOTP支付桥忽略的ErrorLocation元素中添加属性（和值）。
The following table mentions any modification from this general processing for particular error values. Furthermore, it contains hints for developers of IOTP Application Core software components about the processing of error codes. Conversely, developers of IOTP Payment Bridges get impressions about the expected behavior of the IOTP Application Core.
下表列出了针对特定错误值的一般处理的任何修改。此外，它还为IOTP应用程序核心软件组件的开发人员提供了有关错误代码处理的提示。相反，IOTP支付桥的开发人员会对IOTP应用程序核心的预期行为产生印象。
The IOTP Payment API assumes that the IOTP Application Core implements the dialog boxes needed for error resolution. But it does not assume, that the IOTP Payment Bridge actually relies on them. Instead, the IOTP Payment Bridge may try resolution on its own, may implement specific dialog boxes, and may signal only final failures.
IOTP支付API假定IOTP应用程序核心实现错误解决所需的对话框。但它并不认为IOTP支付桥实际上依赖于它们。相反，IOTP支付网桥可能会自行尝试解决方案，可能会实现特定的对话框，并且可能只会发出最终失败的信号。
Note: This abstract document assumes that the API parameters are exchanged XML encoded. Therefore, several error values might disappear in lower level language specific derivations.
注意：这个抽象文档假设API参数是XML编码的。因此，一些错误值可能会在较低级别的特定于语言的派生中消失。
Error Value Error Description
----------- -----------------
Error Value Error Description
----------- -----------------
Reserved Reserved. This error is reserved by the vendor/developer of the software. Contact the vendor/developer of the software for more information (see the SoftwareId attribute of the Message Id element in the Transaction Reference Block [IOTP]).
保留的。此错误由软件供应商/开发人员保留。有关更多信息，请联系软件的供应商/开发人员（请参阅事务参考块[IOTP]中消息Id元素的SoftwareId属性）。
XmlNotWellFrmd XML not well formed. The XML document is not well formed. See [XML] for the meaning of "well formed".
XmlNotWellFrmd XML格式不正确。XML文档的格式不正确。有关“格式良好”的含义，请参见[XML]。
XmlNotValid XML not valid. The XML document is well formed but the document is not valid. See [XML] for the meaning of "valid". Specifically:
XmlNotValid XML无效。XML文档格式正确，但文档无效。有关“有效”的含义，请参见[XML]。明确地：
o the XML document does not comply with the constraints defined in the IOTP document type declaration, and o the XML document does not comply with the constraints defined in the document type declaration of any additional [XML-NS] that are declared.
o 该XML文档不符合IOTP文档类型声明中定义的约束，并且该XML文档不符合所声明的任何其他[XML-NS]的文档类型声明中定义的约束。
The Names attribute might refer some attributes and elements of the input parameter list.
Names属性可能引用输入参数列表中的某些属性和元素。
(*)ElNotValid Element not valid. Invalid element in terms of prescribed syntactical characteristics.
（*）ElNotValid元素无效。根据规定的句法特征，元素无效。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
The IOTP Application Core has to replace the error code with "XmlNotValid" before transmission to the counterparty.
IOTP应用程序核心必须在传输给交易对手之前将错误代码替换为“XmlNotValid”。
ElUnexpected Unexpected element. Although the XML document is well formed and valid, an element is present that is not expected in the particular context according to the rules and constraints contained in this specification.
ElUnexpected意外元素。尽管XML文档格式良好且有效，但根据本规范中包含的规则和约束，存在特定上下文中不需要的元素。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
ElNotSupp Element not supported. Although the document is well formed and valid, an element is present that
不支持ElNotSupp元素。尽管文档格式良好且有效，但存在一个元素
o is consistent with the rules and constraints contained in this specification, but o is not supported by the IOTP Aware Application which is processing the IOTP Message.
o 与本规范中包含的规则和约束一致，但处理IOTP消息的IOTP感知应用程序不支持o。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
ElMissing Element missing. Although the document is well formed and valid, an element is missing that should have been present if the rules and constraints contained in this specification are followed.
缺少ElMissing元素。尽管文档格式良好且有效，但如果遵循本规范中包含的规则和约束，则缺少本应存在的元素。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
ElContIllegal Element content illegal. Although the document is well formed and valid, the element contains values which do not conform the rules and constraints contained in this specification.
ELCONTLIVALL元素内容非法。尽管文档格式良好且有效，但元素包含的值不符合本规范中包含的规则和约束。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding element (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
The IOTP Application Core has to replace the Error Code with "ElNotSupp" before transmission to the counter party, if the ErrorLocation elements refer to non-PackagedContent element.
如果ErrorLocation元素指的是非PackagedContent元素，则IOTP应用程序核心必须在传输到对方之前将错误代码替换为“ElNotSupp”。
EncapProtErr Encapsulated protocol error. Although the document is well formed and valid, the Packaged Content of an element contains data from an encapsulated protocol which contains errors.
EncapProperter封装的协议错误。尽管文档格式良好且有效，但元素的打包内容包含来自包含错误的封装协议的数据。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding element (if they have ID attributes).
ErrorLocation元素的ElementRef属性可能引用相应的元素（如果它们具有ID属性）。
AttUnexpected Unexpected attribute. Although the XML document is well formed and valid, the presence of the attribute is not expected in the particular context according to the rules and constraints contained in this specification.
意外属性。尽管XML文档格式良好且有效，但根据本规范中包含的规则和约束，在特定上下文中不需要属性的存在。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
ErrorLocation元素的AttName属性可能引用相应的属性标记。
(*)AttNotValid Attribute not valid. Invalid attribute value in terms of prescribed syntactical characteristics.
（*）AttNotValid属性无效。根据规定的语法特征，属性值无效。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
ErrorLocation元素的AttName属性可能引用相应的属性标记。
The IOTP Application Core has to replace the error code with "XmlNotValid" before transmission to the counter party.
IOTP应用程序核心必须在传输到对方之前将错误代码替换为“XmlNotValid”。
AttNotSupp Attribute not supported. Although the XML document is well formed and valid, and the presence of the attribute in an element is consistent with the rules and constraints contained in this specification, it is not supported by the IOTP Aware Application which is processing the IOTP Message.
不支持AttNotSupp属性。尽管XML文档格式良好且有效，并且元素中属性的存在符合本规范中包含的规则和约束，但处理IOTP消息的IOTP感知应用程序不支持该文档。
AttMissing Attribute missing. Although the document is well formed and valid, an attribute is missing that should have been present if the rules and constraints contained in this specification are followed.
属性缺失。尽管文档格式良好且有效，但如果遵循本规范中包含的规则和约束，则缺少本应存在的属性。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
ErrorLocation元素的AttName属性可能引用相应的属性标记。
If the attribute is required by the IOTP Document Type Declaration (#REQUIRED) the hints for non-valid attributes should be adopted, otherwise these for illegal attribute values.
如果IOTP文档类型声明需要该属性（#required），则应采用无效属性的提示，否则应采用非法属性值的提示。
AttValIllegal Attribute value illegal. The attribute contains a value which does not conform to the rules and constraints contained in this specification.
AttValIllegal属性值非法。该属性包含的值不符合本规范中包含的规则和约束。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags - valid values are:
ErrorLocation元素的AttName属性可能引用相应的属性标记-有效值为：
BrandId: illegal/unknown Brand Identifier - If the brand is not recognized/known by any IOTP Payment Bridge, the IOTP Application Core may offer the registration of a new Payment Instrument.
BrandId：非法/未知品牌标识符-如果任何IOTP支付桥都无法识别/知道该品牌，则IOTP应用核心可能会提供新支付工具的注册。
PaymentInstrumentId: illegal/unknown Payment Instrument Identifier - This indicates a serious communication problem if the attribute value has been reported by the same "wallet" on a previous inquiry requests. The IOTP Application Core has to replace the error code with "UnknownError" before transmission to the counter party.
PaymentInstrumentId：非法/未知的支付工具标识符-如果在以前的查询请求中同一个“钱包”报告了属性值，则表示存在严重的通信问题。IOTP应用程序核心必须在传输到对方之前将错误代码替换为“UnknownError”。
WalletId: illegal/unknown Wallet Identifier - It is assumed that the wallet identifier is checked before the pass phrase. On invalid wallet identifiers, the IOTP Application Core may open the dialog in order to request the correct wallet identifier. In addition, any pass phrase may be supplied by the user. The dialog should indicate the respective payment brand(s). The IOTP Application Core has to replace the error code with "UnknownError" before transmission to the counter party.
WalletId：非法/未知钱包标识符-假定在密码短语之前检查了钱包标识符。对于无效的钱包标识符，IOTP应用程序核心可能会打开该对话框以请求正确的钱包标识符。此外，用户可以提供任何通行短语。该对话框应指明相应的支付品牌。IOTP应用程序核心必须在传输到对方之前将错误代码替换为“UnknownError”。
Passphrase: illegal/unknown Pass Phrase - The IOTP Application Core may open the dialog in order to request the correct pass phrase. If the pass phrase is wallet identifier specific the dialog should display the wallet identifier. The IOTP Application Core has to replace the error code with "TransportError" before transmission to the counter party.
密码短语：非法/未知密码短语-IOTP应用程序核心可能会打开该对话框以请求正确的密码短语。如果密码短语是特定于钱包标识符的，则对话框应显示钱包标识符。IOTP应用程序核心必须在传输到对方之前将错误代码替换为“TransportError”。
Action: illegal / unknown / unsupported Action
操作：非法/未知/不支持的操作
PropertyTypeList: lists contains illegal / unknown / unsupported Property Types - The IOTP Application Core tries only the local resolution but does never transmit any IOTP Error Block to the counter party.
PropertyTypeList：列表包含非法/未知/不受支持的属性类型-IOTP应用程序核心仅尝试本地解析，但从不向对方传输任何IOTP错误块。
CurrCode: illegal/unknown/unsupported Currency Code
CurrCode:非法/未知/不支持的货币代码
CurrCodeType: illegal/unknown/unsupported Currency Code Type
CurrCodeType:非法/未知/不支持的货币代码类型
Amount: illegal/unknown/unsupported Payment Amount
金额：非法/未知/不支持的付款金额
PayDirection: illegal/unknown/unsupported Payment Direction
付款方向：非法/未知/不支持的付款方向
ProtocolId: illegal/unknown/unsupported Protocol Identifier
ProtocolId:非法/未知/不受支持的协议标识符
OkFrom: illegal/unknown/unsupported OkFrom Timestamp
OkFrom：非法/未知/不支持的OkFrom时间戳
OkTo: illegal/unknown/unsupported OkTo Timestamp
OkTo:非法/未知/不支持的OkTo时间戳
ConsumerPayId: illegal/unknown Consumer Payment Identifier
ConsumerPayId:非法/未知的消费者支付标识符
PaymentHandlerPayId: illegal/unknown Payment Handler Payment Identifier
PaymentHandlerPayId:非法/未知的支付处理程序支付标识符
PayId: illegal/unknown Payment Identifier
PayId:非法/未知的支付标识符
AttValNotRecog Attribute Value Not Recognized. The attribute contains a value which the IOTP Aware Application generating the message reporting the error could not recognize.
无法识别AttValNotRecog属性值。该属性包含一个值，生成报告错误的消息的IOTP感知应用程序无法识别该值。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
ErrorLocation元素的AttName属性可能引用相应的属性标记。
MsgTooLarge Message too large. The message is too large to be processed by the IOTP Payment Bridge (or IOTP Application Core).
MsgTooLarge消息太大。消息太大，无法由IOTP支付桥（或IOTP应用程序核心）处理。
ElTooLarge Element too large. The element is too large to be processed by the IOTP Payment Bridge (or IOTP Application Core).
ELTOOLAGE元素太大。该元素太大，无法由IOTP支付桥（或IOTP应用程序核心）处理。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements.
ErrorLocation元素的ElementRef属性可能引用相应的元素。
ValueTooSmall Value too small or early. The value of all or part of an element content or an attribute, although valid, is too small.
值太小值太小或太早。元素内容或属性的全部或部分值虽然有效，但太小。
The ErrorLocation elements might refer to the corresponding attribute tags or elements.
ErrorLocation元素可能引用相应的属性标记或元素。
ValueTooLarge Value too large or in the future. The value of all or part of an element content or an attribute, although valid, is too large.
ValueTooLarge值太大或在将来。元素内容或属性的全部或部分值（虽然有效）太大。
The ErrorLocation elements might refer to the corresponding attribute tags or elements.
ErrorLocation元素可能引用相应的属性标记或元素。
ElInconsistent Element Inconsistent. Although the document is well formed and valid, according to the rules and constraints contained in this specification:
元素不一致。尽管文件格式良好且有效，但根据本规范中包含的规则和约束：
o the content of an element is inconsistent with the content of other elements or their attributes, or
o 元素的内容与其他元素的内容或其属性不一致，或
o the value of an attribute is inconsistent with the value of one or more other attributes.
o 属性的值与一个或多个其他属性的值不一致。
The Error Description may contain further explanations.
错误描述可能包含进一步的解释。
The ErrorLocation elements might refer to the corresponding attribute tags or elements that are inconsistent.
ErrorLocation元素可能引用相应的属性标记或不一致的元素。
TransportError Transport Error. This error code is used to indicate that there is a problem with the transport mechanism that is preventing the message from being received. It is typically associated with a "Transient Error".
传输错误传输错误。此错误代码用于指示阻止接收消息的传输机制存在问题。它通常与“瞬时误差”相关。
The connection to some periphery or the counter party could not be established, is erroneous, or has been lost.
与某些外围国家或对方的联系无法建立、错误或已丢失。
The Error Description may contain further narrative explanations, e.g., "chip card does not respond", "remote account manager unreachable", "Internet connection to xyz lost", "no Internet connection available", "no modem connected", or "serial port to modem used by another application". This text should be shown to the end user. If timeout has occurred at the Consumer this text should be shown and the Consumer may decide how to proceed - alternatives are retry, payment transaction suspension, and cancellation.
错误描述可能包含进一步的叙述性解释，例如，“芯片卡没有响应”、“无法访问远程帐户管理器”、“与xyz的Internet连接丢失”、“没有可用的Internet连接”、“没有连接调制解调器”或“其他应用程序使用的调制解调器的串行端口”。此文本应显示给最终用户。如果消费者出现超时，则应显示此文本，消费者可决定如何继续-备选方案为重试、支付交易暂停和取消。
MsgBeingProc Message Being Processed. This error code is only used with a Severity of Transient Error. It indicates that the previous message, which may be an exchange message or a request message, is being processed and, if no response is received by the time indicated by the "MinRetrySecs" attribute, then the original message should be resent.
正在处理MsgBeingProc消息。此错误代码仅在严重程度为暂时错误时使用。它表示前一条消息（可能是交换消息或请求消息）正在处理中，如果在“MinRetrySecs”属性指示的时间内未收到响应，则应重新发送原始消息。
SystemBusy System Busy. This error code is only used with a Severity of Transient Error. It indicates that the IOTP Payment Bridge or Existing Payment Software that received the API request is currently too busy to handle it. If no response is received by the time indicated by the "MinRetrySecs" attribute, then the original message should be resent.
系统忙系统忙。此错误代码仅在严重程度为暂时错误时使用。它表示收到API请求的IOTP支付桥或现有支付软件当前太忙，无法处理该请求。如果在“MinRetrySecs”属性指示的时间内未收到响应，则应重新发送原始消息。
The Error Description may provide further explanations, e.g., "wallet / chip card reader is unavailable or locked by another payment transaction", "payment gateway is overloaded", "unknown chip card reader", or "unrecognized chip card inserted, change chip card".
错误描述可能提供进一步的解释，例如，“钱包/芯片卡读卡器不可用或被另一个支付交易锁定”、“支付网关过载”、“未知芯片卡读卡器”或“插入无法识别的芯片卡，更换芯片卡”。
The Consumer's IOTP Application Core may display the error description and ask the Consumer about the continuation - alternatives are retry, payment transaction suspension, and cancellation.
消费者的IOTP应用程序核心可能会显示错误描述，并询问消费者关于继续的问题-备选方案有重试、支付交易暂停和取消。
UnknownError Unknown Error. Indicates that the transaction cannot complete for some reason that is not covered explicitly by any of the other errors. The Error description attribute should be used to indicate the nature of the problem.
未知错误未知错误。表示由于其他任何错误都没有明确说明的原因，事务无法完成。错误描述属性应用于指示问题的性质。
The ErrorLocation elements might refer to the corresponding attribute tags or elements that are inconsistent.
ErrorLocation元素可能引用相应的属性标记或不一致的元素。
(*)SyntaxError Syntax Error. An (unknown) syntax error has occurred.
（*）语法错误。发生（未知）语法错误。
The ErrorLocation elements might refer to the corresponding attribute tags or elements that are inconsistent.
ErrorLocation元素可能引用相应的属性标记或不一致的元素。
The IOTP Application Core has to replace the error code with "XmlNotValid" or "UnknownError" before transmission to the counter party.
IOTP应用程序核心必须在传输到对方之前，将错误代码替换为“XmlNotValid”或“UnknownError”。
(*)ReqRefused Request refused. The API request is (currently) refused by the IOTP Payment Bridge. The error description may provide further explanations, e.g., "wallet / chip card reader is unavailable or locked by another payment transaction", "payment gateway is overloaded", "unknown chip card reader", or "unrecognized chip card inserted, change chip card".
（*）请求被拒绝。IOTP支付桥（目前）拒绝API请求。错误描述可能提供进一步的解释，例如，“钱包/芯片卡读卡器不可用或被另一个支付交易锁定”、“支付网关过载”、“未知芯片卡读卡器”或“插入无法识别的芯片卡，更换芯片卡”。
The Consumer's IOTP Application Core may display the error description and ask the Consumer about the continuation - alternatives are retry, payment transaction suspension, and cancellation. Denials due to invalid Process States should be signaled by "BusinessError". Typically, this kind of error is not passed to the counter party's IOTP Application Core. Otherwise, it maps to "TransportError" or "UnknownError".
消费者的IOTP应用程序核心可能会显示错误描述，并询问消费者关于继续的问题-备选方案有重试、支付交易暂停和取消。由于流程状态无效而导致的拒绝应以“BusinessError”表示。通常，此类错误不会传递给对方的IOTP应用程序核心。否则，它将映射到“TransportError”或“UnknownError”。
(*)ReqNotSupp Request not supported. The API function(ality) has not been implemented in the IOTP Payment Bridge. Typically, this kind of error is not passed to the counter party's IOTP Application Core. Otherwise, it maps to "TransportError" or "UnknownError".
（*）不支持ReqNotSupp请求。IOTP支付桥中未实现API功能（ALI）。通常，此类错误不会传递给对方的IOTP应用程序核心。否则，它将映射到“TransportError”或“UnknownError”。
(*)BusError Business Error. The API request has been rejected because some payment transaction has an illegal payment status. Particularly, this error code is used to signal any raise of payment business layered failures.
（*）总线错误业务错误。API请求已被拒绝，因为某些支付交易具有非法支付状态。特别是，此错误代码用于表示任何支付业务分层失败。
The ErrorLocation elements may refer to payment transactions using the party's Payment Identifier - it defaults to the
ErrorLocation元素可能指使用一方支付标识符的支付交易-默认为
current transaction or might contain the current payment transaction party's Payment Identifier - identified by the ElementRef attribute while the AttName attribute is fixed with "PayId".
当前交易或可能包含当前支付交易方的支付标识符-由ElementRef属性标识，而AttName属性用“PayId”固定。
The IOTP Application Core must inquire the IOTP Payment Bridge about the actual Process State which actually encodes the business error ("Inquire Process State"). This error code must not be passed to the counter party's IOTP Application Core.
IOTP应用程序核心必须向IOTP支付桥查询实际编码业务错误的实际流程状态（“查询流程状态”）。不得将此错误代码传递给对方的IOTP应用程序核心。
Table 2: Common Error Codes
表2：常见错误代码
The IOTP Payment Bridge may also use the error description in order to notify the Consumer about further necessary steps for failure resolution, e.g., "Sorry, your payment transaction failed. Unfortunately, you have been charged, please contact your issuer."
IOTP支付桥也可能使用错误描述来通知消费者故障解决的进一步必要步骤，例如，“对不起，您的支付交易失败。很遗憾，您已被收取费用，请联系您的发卡机构。”
The following table explains the XML attributes in alphabetical order - any parenthesized number after the attribute tag is a recommended maximal length of the attribute value in characters:
下表按字母顺序解释了XML属性-属性标记后的任何括号数字都是建议的属性值最大长度（以字符为单位）：
Attribute Description
--------- -----------
Attribute Description
--------- -----------
Amount (11) Indicates the payment amount to be paid in AmountFrom(11) whole and fractional units of the currency. AmountTo (11) For example $245.35 would be expressed "245.35". Note that values smaller than the smallest denomination are allowed. For example one tenth of a cent would be "0.001".
金额（11）表示以（11）整单位和分数单位的货币支付的金额。例如，金额（11）245.35美元将表示为“245.35”。请注意，允许使用小于最小面额的值。例如，十分之一美分将是“0.001”。
AuthenticationId An identifier specified by the authenticator which, if returned by the organization that receives the authentication request, will enable the authenticator to identify which authentication is being referred to.
AuthenticationId由身份验证人指定的标识符，如果接收身份验证请求的组织返回该标识符，则该标识符将使身份验证人能够识别引用的身份验证。
BrandId (128) This contains a unique identifier for the brand (or promotional brand). It is used to match against a list of Payment Instruments which the Consumer holds to determine whether or not the Consumer can pay with the Brand.
BrandId（128）包含品牌（或促销品牌）的唯一标识符。它用于匹配消费者持有的支付工具列表，以确定消费者是否可以使用品牌支付。
Values of BrandId are managed under procedure being described in the IOTP protocol specification.
BrandId值根据IOTP协议规范中描述的程序进行管理。
BrandLogoNetLocn The net location which can be used to download the logo for the organization (cf. IOTP Specification).
BrandLogoNetLocn可用于下载组织徽标的网络位置（参见IOTP规范）。
The content of this attribute must conform to [URL].
此属性的内容必须符合[URL]。
BrandName This contains the name of the brand, for example "MasterCard Credit". This is the description of the Brand which is displayed to the consumer in the Consumer's language defined by "xml:lang". For example it might be "American Airlines Advantage Visa". Note that this attribute is not used for matching against the payment instruments held by the Consumer.
品牌名称包含品牌名称，例如“万事达信用卡”。这是以“xml:lang”定义的消费者语言向消费者显示的品牌描述。例如，它可能是“美国航空公司优势签证”。请注意，此属性不用于与消费者持有的支付工具进行匹配。
BrandNarrative This optional attribute is used by the Merchant to indicate some special conditions or benefit which would apply if the Consumer selected that brand. For example "5% discount", "free shipping and handling", "free breakage insurance for 1 year", "double air miles apply", etc.
品牌说明：商户使用此可选属性表示一些特殊条件或好处，如果消费者选择该品牌，这些条件或好处将适用。例如“5%折扣”、“免费装运和搬运”、“1年免费破碎险”、“适用双倍航空里程”等。
CallBackFunction A function which is called whenever there is a change of Process State or payment progress, e.g., for display updates. However, the IOTP Payment Bridge may use its own mechanisms and dialog boxes.
CallBackFunction当流程状态或付款进度发生变化时调用的函数，例如，用于显示更新。然而，IOTP支付桥可能使用其自身的机制和对话框。
CallBackLanguageList A list of language codes which contain, in order of preference, the languages in which the text passed to the Call Back function will be encoded.
CallBackLanguageList语言代码列表，按优先顺序包含传递给回调函数的文本将采用的编码语言。
CompletionCode (14) Indicates how the process completed. It is required if ProcessState is set to "Failed" otherwise it is ignored. Valid values as well as recovery options are given in the IOTP specification.
CompletionCode（14）指示流程是如何完成的。如果ProcessState设置为“Failed”，则它是必需的，否则将被忽略。IOTP规范中给出了有效值和恢复选项。
The IOTP Payment Bridge may also use the Status Description to notify the Consumer about further necessary steps in order to resolve some kind of business failures, e.g.,
IOTP支付桥还可以使用状态描述通知消费者进一步的必要步骤，以解决某些类型的业务故障，例如：。，
o "sorry, your payment transaction failed. Unfortunately, you have been charged, please contact your issuer." o "insufficient capacity left (on your stored value card) for refund", o "payment failed/chip card error/internal error, please contact your payment instrument's issuer"
o 很抱歉，您的支付交易失败。很遗憾，您已被收取费用，请与您的发卡机构联系。“o”剩余容量不足（在您的储值卡上）无法退款，“o”支付失败/芯片卡错误/内部错误，请与您的支付工具的发卡机构联系”
ConsumerDesc A narrative description of the Consumer.
消费者对消费者的叙述性描述。
ConsumerPayId (14) An unique identifier specified by the Consumer that, if returned by the Payment Handler in another Payment Scheme Component or by other means, enables the Consumer to identify which payment is being referred to.
ConsumerPayId（14）由消费者指定的唯一标识符，如果由另一个支付方案组件中的支付处理程序或通过其他方式返回，则该标识符使消费者能够识别所引用的支付。
This unique identifier is generated by the IOTP Application Core and submitted to the IOTP Payment Bridge on every API call. It may equal the Payment Handler Payment Identifiers but need not necessarily be so.
该唯一标识符由IOTP应用程序核心生成，并在每次API调用时提交给IOTP支付桥。它可能等于支付处理程序支付标识符，但不一定如此。
The uniqueness extends to multiple payment instruments, payment brands, payment protocols, wallet identifiers, and even multiple IOTP Payment Bridges.
这种独特性延伸到多种支付工具、支付品牌、支付协议、钱包标识符，甚至多个IOTP支付桥。
ContStatus During payment progress, this status value indicates whether the payment needs to be continued with further IOTP Payment Scheme Component exchanges with the remote party. "End" indicates that the reported payment scheme data is the last data to be exchanged with the counter party.
ContStatus在支付过程中，此状态值指示是否需要继续支付，并与远程方进一步交换IOTP支付方案组件。“结束”表示报告的付款方案数据是与对方交换的最后一个数据。
ContentSoftwareId This contains information that identifies the software that generated the content of the element. Its purpose is to help resolve interoperability problems that might occur as a result of incompatibilities between messages produced by different software. It is a single text string in the language defined by xml:lang. It must contain, as a minimum:
ContentSoftwareId包含标识生成元素内容的软件的信息。其目的是帮助解决由于不同软件生成的消息之间不兼容而可能出现的互操作性问题。它是xml:lang定义的语言中的单个文本字符串。它必须至少包含：
o the name of the software manufacturer, o the name of the software, o the version of the software, and o the build of the software.
o 软件制造商的名称、软件的名称、软件的版本和软件的版本。
CurrCodeType (14) Indicates the domain of the CurrCode. This attribute is included so that the currency code may support nonstandard currencies such as frequent flyer point, trading stamps, etc. Its values may be
CurrCodeType（14）表示CurrCode的域。包含此属性是为了使货币代码可以支持非标准货币，例如飞行常客积分、交易邮票等。其值可能为
o ISO-4217-A, the default, indicates the currency code is the three-letter alphabetic code that conform to ISO-4217 [ISO4217]. o IOTP indicates that the values of CurrCode are managed under the procedure described in [IOTP].
o 默认值ISO-4217-A表示货币代码是符合ISO-4217[ISO4217]的三字母字母字母代码。o IOTP表示CurrCode的值按照[IOTP]中所述的程序进行管理。
CurrCode (14) A code which identifies the currency to be used in the payment. The domain of valid currency codes is defined by "CurrCodeType"
CurrCode（14）用于识别付款中使用的货币的代码。有效货币代码的域由“CurrCodeType”定义
MerchantPayId (14) An private identifier specified by the Merchant which will enable the Merchant to identify which payment is being referred to. It is a pure private item and is never sent to any other party. It is provided by the IOTP Payment Bridge on payment preparation during brand compilation.
MerchantPayId（14）商户指定的私人标识符，可使商户识别所参考的付款。这是一个纯粹的私人物品，从未发送给任何其他方。由IOTP支付桥提供，用于品牌编制期间的支付准备。
Cf. To "ConsumerPayId" for note about uniqueness.
请参阅“ConsumerPayId”，了解关于唯一性的注意事项。
MerchantOrgId (64) A local item that might refer to some specific shop in a multi shop environment. This item is optional and might enrich the Wallet Identifier which itself can be used for the same purpose.
MerchantOrgId（64）在多商店环境中可能涉及特定商店的本地商品。此项目是可选的，可能会丰富钱包标识符，钱包标识符本身也可用于相同目的。
Name Distinguishes between multiple occurrences of Packaged Content Elements at the same point in IOTP. For example:
名称区分IOTP中同一点上多次出现的打包内容元素。例如：
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
The "Name" attribute may be omitted, for example if there is only one Packaged Content element.
例如，如果只有一个打包的内容元素，则可以省略“Name”属性。
OkFrom (30) The date and time in UTC Format range OkTo (30) indicated by the merchant in which the Payment Handler may accept the payment. For more information, see [UTC].
OkFrom（30）商户指示的UTC格式范围为OkTo（30）的日期和时间，在该日期和时间内，支付经办人可以接受付款。有关详细信息，请参阅[UTC]。
Passphrase (32) Payment wallets may use pass phrase protection for transaction data and payment instruments' data. However, it is assumed that there exists a public and customizable payment instrument identifier such that these identifiers together with their relationship to payment brands, payment protocols, payment directions, and currency amounts can be queried by the IOTP application without any pass phrase knowledge.
密码短语（32）支付钱包可对交易数据和支付工具数据使用密码短语保护。然而，假设存在一个公共的、可定制的支付工具标识符，使得IOTP应用程序可以查询这些标识符及其与支付品牌、支付协议、支付方向和货币金额的关系，而无需任何通行短语知识。
PayDirection Indicates the direction in which the payment for which a Brand is being selected is to be made. Its values may be:
PayDirection表示选择品牌的付款方向。其值可能是：
o Debit: The sender of the Payment Request Block (e.g., the Consumer) to which this Brand List relates will make the payment to the Payment Handler, or
o 借记：与此品牌列表相关的付款请求块的发送者（例如消费者）将向付款处理程序付款，或
o Credit: The sender of the Payment Request Block to which this Brand List relates will receive a payment from the Payment Handler.
o 信用：与此品牌列表相关的付款请求块的发件人将从付款处理程序接收付款。
PayId (14) This attribute is introduced for API simplification:
PayId（14）引入此属性是为了简化API：
o The Consumer has to identify PayId and ConsumerPayId.
o 消费者必须识别PayId和ConsumerPayId。
o The Merchant has to identify PayId and MerchantPayId.
o 商户必须识别PayId和MerchantPayId。
o The Payment Handler has to identify PayId and Payment Handler Pay Id.
o 支付处理程序必须识别PayId和支付处理程序PayId。
PayInstId This contains the unique identifier used internally by the IOTP Payment Bridge/Existing Payment Software.
PayInstId包含IOTP支付桥/现有支付软件内部使用的唯一标识符。
PayInstName This contains the user-defined name of the payment instrument. There exist no (technical) constraints like uniqueness. The "xml:lang" attribute denotes the language encoding of its value.
PayInstName包含付款工具的用户定义名称。不存在唯一性等（技术）约束。“xml:lang”属性表示其值的语言编码。
PaymentHandlerDesc A narrative description of the Payment Handler.
PaymentHandler描述支付处理程序的叙述性描述。
PaymentHandlerPayId An unique identifier specified by the (14) Payment Handler that, if returned by the Consumer in another Payment Scheme Component or by other means, enables the Payment Handler to identify which payment is being referred to. It is required whenever it is known.
PaymentHandlerPayId（14）支付处理程序指定的唯一标识符，如果消费者在另一个支付方案组件中或通过其他方式返回该标识符，则该标识符使支付处理程序能够识别所引用的付款。只要知道它，就需要它。
Cf. To "ConsumerPayId" for note about uniqueness.
请参阅“ConsumerPayId”，了解关于唯一性的注意事项。
PaymentInstrumentId An identifier for a specific payment (32) instrument, e.g., "credit card", "Mondex card for English Pounds". This identifier is fully customizable. It is assumed, that it does not contain confidential information or even an indication of it. The payment
PaymentInstrumentId特定支付（32）工具的标识符，例如“信用卡”、“英国英镑的Mondex卡”。此标识符是完全可自定义的。假设它不包含机密信息，甚至不表示机密信息。付款
instrument identifier is unique within each payment brand. It is displayed to the Consumer during brand selection.
仪器标识符在每个支付品牌中都是唯一的。在品牌选择过程中，它会显示给消费者。
PayReceiptNameRefs Optionally contains element references to (32) other elements (containing payment scheme specific data) that together make up the receipt. Note that each payment scheme defines in its supplement the elements that must be referenced
PayReceiptNameRefs可选地包含对（32）个其他元素（包含付款方案特定数据）的元素引用，这些元素共同构成收据。请注意，每个付款方案在其补充文件中定义了必须引用的元素
The IOTP Application Core should save all the components referenced so that the payment receipt can be reconstructed when required.
IOTP应用程序核心应保存所有引用的组件，以便在需要时重建付款收据。
PayReqNetLocn The Net Location indicating where an unsecured Payment Request message should be sent if this protocol choice is used.
PayReqNetLocn如果使用此协议选项，则指示应在何处发送不安全支付请求消息的净位置。
The content of this attribute must conform to [URL] and depends on the Transport Mechanism.
此属性的内容必须符合[URL]，并取决于传输机制。
PercentComplete (3) A number between 0 and 100 which indicates the progress of the payment transaction. The values range between 0 and 99 for pending and suspended transactions.
完成百分比（3）介于0和100之间的数字，表示支付交易的进度。挂起和挂起事务的值范围在0到99之间。
ProcessState Contains a Process State Code that indicates the current state of the process being carried out. Valid values are:
ProcessState包含进程状态代码，该代码指示正在执行的进程的当前状态。有效值为：
o NotYetStarted. The Payment Request Block has been received but processing of the Payment Request has not yet started
o 没有开始。已收到付款请求块，但尚未开始处理付款请求
o InProgress. The payment transaction is pending. The processing of the (Payment) Request Block has started but it is not yet complete.
o 正在进行中。付款交易处于挂起状态。（付款）请求块的处理已开始，但尚未完成。
o (*)Suspended: The payment transaction has been suspended and can be resumed.
o （*）暂停：支付交易已暂停，可以恢复。
This process state is mapped to "InProgress", if it is passed to the counter party's IOTP Application Core.
如果将该进程状态传递给对方的IOTP应用程序核心，则该进程状态将映射到“InProgress”。
o CompletedOk. The processing of the (Payment) Request Block and any following Payment Exchange Blocks has completed successfully.
o 完成了。（付款）请求块和任何后续付款交换块的处理已成功完成。
o Failed. The payment processing has finally failed for a Business Error.
o 失败。由于业务错误，付款处理最终失败。
o ProcessError. This value is only used when the Status Component is being used in connection with an Inquiry Request Trading Block. It indicates there was a Technical Error in the Request Block which is being processed or some internal processing error. Each party's IOTP Payment Bridge uses this value in order to notify the IOTP Application Core about the presence of technical errors.
o 进程错误。此值仅在状态组件与查询请求交易块一起使用时使用。它表示正在处理的请求块中存在技术错误或某些内部处理错误。各方的IOTP支付桥使用该值通知IOTP应用核心存在技术错误。
PropertyType (14) The property type defines codes used for interrogation of specific properties about a payment instrument. They are unique for each payment brand. The predefined property "all" is used on general inquiries. However, these property types are not used during normal payment processing. E.g., they may apply to payment brand specific transactions or out-of-band failure resolution.
PropertyType（14）属性类型定义用于查询支付工具特定属性的代码。它们对于每个支付品牌都是独一无二的。预定义属性“all”用于常规查询。但是，这些属性类型在正常付款处理过程中不使用。例如，它们可能适用于特定于支付品牌的交易或带外故障解决。
PropertyDesc The property description carries the respective human readable property (value)'s description.
属性描述包含相应的人类可读属性（值）的描述。
PropertyValue The actual property value intends automatic post processing.
PropertyValue实际属性值用于自动后处理。
ProtocolBrandId (64)This is an identifier to be used with a particular payment protocol. For example, SET and EMV have their own well defined, yet different, values for the Brand identifier to be used with each protocol. The valid values of this attribute are defined in the supplement for the payment protocol identified by "ProtocolId" that describes how the payment protocol works with IOTP. Identifier maps to at most one Protocol Brand Identifier.
ProtocolBrandId（64）这是用于特定支付协议的标识符。例如，SET和EMV对每个协议使用的品牌标识符都有自己定义良好但不同的值。该属性的有效值在“ProtocolId”标识的支付协议补充中定义，该补充描述了支付协议如何与IOTP一起工作。标识符映射到最多一个协议品牌标识符。
ProtocolId (64) An identifier for a specific payment protocol and version, e.g., "SETv1.0", "ecash". Valid values are defined by supplements to the IOTP specification and they are unique within each payment brand.
ProtocolId（64）特定支付协议和版本的标识符，如“SETv1.0”、“ecash”。有效值由IOTP规范的补充定义，在每个支付品牌中都是唯一的。
ProtocolIds A sequence of Protocol Identifiers
协议标识符序列
ProtocolName A narrative description of the payment protocol and its version in the language identified by "xml:lang". For example "Secure Electronic Transaction Version 1.0". Its purpose is to help provide information on the payment protocol being used if problems arise.
ProtocolName以“xml:lang”标识的语言对支付协议及其版本进行叙述性描述。例如“安全电子交易1.0版”。其目的是在出现问题时帮助提供有关所使用的支付协议的信息。
SecPayReqNetLocn The Net Location indicating where a secured Payment Request message should be sent if this protocol choice is used.
SecPayReqNetLocn如果使用此协议选项，则指示应在何处发送安全支付请求消息的净位置。
A secured payment involves the use of a secure channel such as [TLS] in order to communicate with the Payment Handler.
安全支付涉及使用安全通道，如[TLS]，以便与支付处理程序进行通信。
The content of this attribute must conform to [URL].
此属性的内容必须符合[URL]。
ReceiverOrgId The Organization Identification which receives the payment bridge processing Trading Role Data PackagedContent.
ReceiverOrgId接收支付桥处理交易角色数据包内容的组织标识。
StatusDesc (256) An optional textual description of the current process state in the language identified by "xml:lang" that should be displayed to the Consumer. The usage of this attribute is defined in the payment supplement for the payment method being used. Particularly, it provides hints for out-of-band failure resolution. Its length is limited to 256 characters.
StatusDesc（256）当前流程状态的可选文本描述，使用“xml:lang”标识的语言，应显示给使用者。此属性的用法在正在使用的付款方法的付款补充中定义。特别是，它为带外故障解决提供了提示。其长度限制为256个字符。
StyleSheetNetLocn This contains the net location to a style sheet with visualisation rules for XML encoded data.
StyleSheetNetLocn包含样式表的净位置，其中包含XML编码数据的可视化规则。
TimeStamp (30) The date and time in UTC Format when the payment transaction has been started. For more information on UTC, see [UTC].
时间戳（30）支付交易开始时UTC格式的日期和时间。有关UTC的更多信息，请参阅[UTC]。
WalletId (32) Many existing payment wallet software are multiple wallet capable. The Wallet Identifier selects the actual wallet. It is assumed, that the wallet identifier is a public item, that might be stored by the IOTP Application Core.
WalletId（32）许多现有的支付钱包软件都支持多钱包功能。钱包标识符选择实际的钱包。假定钱包标识符是公共物品，可由IOTP应用核心存储。
xml:lang Defines the language used by the Process State Description attribute (cf. IOTP Specification)
xml:lang定义流程状态描述属性所使用的语言（参见IOTP规范）
Table 3: Attributes
表3：属性
The following table explains the XML elements in alphabetical order:
下表按字母顺序解释了XML元素：
Element Description
------- -----------
Element Description
------- -----------
Algorithm This contains information which describes an Algorithm that may be used to generate the Authentication response.
算法包含描述可用于生成认证响应的算法的信息。
The algorithm that may be used is identified by the Name attribute (cf. IOTP Specification).
可使用的算法由名称属性标识（参见IOTP规范）。
AuthReqPackagedContent The Authentication Request Packaged Content originates from a Authentication (Data/Response) Component's content whereby the outermost element tags are prefixed with "AuthReq". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It encapsulates the authentication challenge value. The content of this information is defined in the supplement for a payment protocol.
AuthReqPackagedContent身份验证请求打包内容源自身份验证（数据/响应）组件的内容，其中最外层的元素标记以“AuthReq”作为前缀。其声明与打包内容的声明一致（参见IOTP规范）。它封装了身份验证质询值。该信息的内容在支付协议补充文件中定义。
AuthResPackagedContent The Authentication Response Packaged Content originates from a Authentication Response Component's content whereby the outermost element tags are prefixed with "AuthRes".
AuthResPackagedContent身份验证响应打包内容源自身份验证响应组件的内容，其中最外层的元素标记以“AuthRes”作为前缀。
Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It encapsulates the
其声明与打包内容的声明一致（参见IOTP规范）。它封装了
authentication response value. The content of this information is defined in the supplement for a payment protocol.
身份验证响应值。该信息的内容在支付协议补充文件中定义。
BrandPackagedContent Container for further payment brand description. Its content originates from a Brand Element content whose outermost element tags are prefixed with "Brand". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification).
品牌包装内容容器，用于进一步支付品牌说明。其内容来源于品牌元素内容，其最外层的元素标记以“品牌”为前缀。其声明与打包内容的声明一致（参见IOTP规范）。
BrandSelBrandInfoPackagedContent This contains any additional data that may be required by a particular payment brand. It forms the content of the Brand Selection Brand Info Element.
BrandSelBrandInfoPackagedContent包含特定支付品牌可能需要的任何其他数据。它构成了品牌选择的品牌信息元素的内容。
BrandSelProtocolAmountInfoPackagedContent This contains any additional data that may be required by a particular payment brand in the format. It forms the content of the Brand Selection Protocol Amount Info Element.
BrandSelProtocolAmountInfo PackagedContent包含特定支付品牌可能需要的格式的任何附加数据。它构成了品牌选择协议金额信息元素的内容。
BrandSelCurrencyAmountInfoPackagedContent This contains any additional data that is payment brand and currency specific in the format. It forms the content of the Brand Selection Currency Amount Info Element.
BrandSelCurrencyAmountInfo PackagedContent包含格式中特定于支付品牌和货币的任何附加数据。它形成品牌选择货币金额信息元素的内容。
MerchantData Any merchant related data that might be used by the IOTP Payment Bridge for different purposes, e.g., it might contain IDs to access some mall data, but not cryptographic keys. Its Packaged declaration coincides with the Content's declaration (cf. IOTP Specification).
MerchantData IOTP支付桥可能用于不同目的的任何商户相关数据，例如，它可能包含访问某些商场数据的ID，但不包含加密密钥。其打包声明与内容声明一致（参见IOTP规范）。
PackagedContent Generic Container for non-IOTP data (cf. IOTP Specification).
PackagedContent非IOTP数据的通用容器（参见IOTP规范）。
PayProtocolPackagedContent The Pay Protocol Packaged Content originates from a Pay Protocol Element's content whereby the outermost element tags are prefixed with
PayProtocolPackagedContent支付协议打包内容源自支付协议元素的内容，最外层的元素标记以
"PayProtocol". It contains information about the protocol which is used by the payment protocol. The content of this information is defined in the supplement for a payment protocol. Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification).
“付费协议”。它包含关于支付协议所使用的协议的信息。该信息的内容在支付协议补充文件中定义。其声明与打包内容的声明一致（参见IOTP规范）。
PaySchemePackagedContent The PayScheme Packaged Content originates from a Payment Scheme Component's content whereby the outermost element tags are prefixed with "PayScheme". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It carries the payment specific data. The content of this information is defined in the supplement for a payment protocol.
PayScheme打包内容PayScheme打包内容源自支付方案组件的内容，其中最外层的元素标记以“PayScheme”作为前缀。其声明与打包内容的声明一致（参见IOTP规范）。它携带特定于支付的数据。该信息的内容在支付协议补充文件中定义。
ProtocolAmountPackagedContent The Protocol Amount Packaged Content originates from a Protocol Amount Element's content whereby the outermost element tags are prefixed with "Amount". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It contains information about the protocol which is used by the payment protocol. The content of this information is defined in the supplement for a payment protocol.
ProtocolAmountPackagedContent协议金额打包内容源自协议金额元素的内容，最外层的元素标记以“金额”作为前缀。其声明与打包内容的声明一致（参见IOTP规范）。它包含关于支付协议所使用的协议的信息。该信息的内容在支付协议补充文件中定义。
ProtocolBrandPackagedContent The Protocol Brand Packaged Content originates from a Protocol Brand Element's content whereby the outermost element tags are prefixed with "ProtocolBrand". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It contains information about the brand which might be used by the payment protocol. The content of this information is defined in the supplement for a payment protocol.
ProtocolBrandPackagedContent协议品牌包装内容源自协议品牌元素的内容，其中最外层的元素标记以“ProtocolBrand”作为前缀。其声明与打包内容的声明一致（参见IOTP规范）。它包含有关支付协议可能使用的品牌的信息。该信息的内容在支付协议补充文件中定义。
ResponsePackagedContent Container for authentication response data. Its content originates from a Authentication Response Component's Packaged Content whose outermost element tags are prefixed with "Response". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification).
用于身份验证响应数据的ResponsePackagedContent容器。其内容来源于身份验证响应组件的打包内容，其最外层的元素标记前缀为“Response”。其声明与打包内容的声明一致（参见IOTP规范）。
TradingRoleDataPackagedContent The TradingRoleData Packaged Content originates from a TradingRoleData Component's content whereby the outermost element tags are prefixed with "TradingRoleData". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification). It contains information from Merchant to Payment Handler via Consumer about the protocol which is used by the payment. The content of this information is defined in the supplement for a payment protocol. The Name attribute in this packaged contents must include prefix as "Payment:" to indicate that the payment bridge processes this, for example "Payment:SET-OD". See [SET/IOTP] for more information.
TradingRoleData打包内容TradingRoleData打包内容源自TradingRoleData组件的内容，其中最外层的元素标记以“TradingRoleData”为前缀。其声明与打包内容的声明一致（参见IOTP规范）。它包含商户通过消费者向支付处理程序提供的关于支付所使用协议的信息。该信息的内容在支付协议补充文件中定义。此打包内容中的Name属性必须包含前缀“Payment:”以指示支付桥处理此项，例如“Payment:SET-OD”。有关更多信息，请参阅[SET/IOTP]。
The element's declaration coincides with the Packaged Content's declaration (cf. IOTP Specification).
元素的声明与打包内容的声明一致（参见IOTP规范）。
Table 4: Elements
表4：要素
XML definition:
XML定义：
<!ENTITY % AuthReqPackagedContent "PackagedContent">
<!ENTITY % AuthResPackagedContent "PackagedContent">
<!ENTITY % AuthReqPackagedContent "PackagedContent">
<!ENTITY % AuthResPackagedContent "PackagedContent">
<!ENTITY % BrandPackagedContent "PackagedContent">
<!ENTITY % BrandSelInfoPackagedContent "PackagedContent">
<!ENTITY % BrandSelProtocolAmountPackagedContent
"PackagedContent">
<!ENTITY % BrandSelCurrencyAmountPackagedContent
"PackagedContent">
<!ENTITY % ProtocolAmountPackagedContent
<!ENTITY % BrandPackagedContent "PackagedContent">
<!ENTITY % BrandSelInfoPackagedContent "PackagedContent">
<!ENTITY % BrandSelProtocolAmountPackagedContent
"PackagedContent">
<!ENTITY % BrandSelCurrencyAmountPackagedContent
"PackagedContent">
<!ENTITY % ProtocolAmountPackagedContent
"PackagedContent">
<!ENTITY % PayProtocolPackagedContent "PackagedContent">
<!ENTITY % TradingRoleDataPackagedContent "PackagedContent">
<!ENTITY % MerchantData "PackagedContent">
<!ENTITY % PaySchemePackagedContent "PackagedContent">
"PackagedContent">
<!ENTITY % PayProtocolPackagedContent "PackagedContent">
<!ENTITY % TradingRoleDataPackagedContent "PackagedContent">
<!ENTITY % MerchantData "PackagedContent">
<!ENTITY % PaySchemePackagedContent "PackagedContent">
The IOTP Payment API supports six different attribute values that encode the transaction status from the IOTP's point of view, i.e., the appropriate point of view at the interface between the IOTP Application Core and IOTP Payment Bridge. This point of view does not completely mimic the more detailed view on the actual payment by the actual Existing Payment Software or IOTP Payment Bridge.
IOTP支付API支持六个不同的属性值，这些属性值从IOTP的角度编码交易状态，即IOTP应用核心和IOTP支付桥之间接口的适当角度。该观点并不完全模仿实际现有支付软件或IOTP支付桥对实际支付的更详细的观点。
The following three tables distinguish between the Merchant's, Consumer's, and Payment Handlers' environment. They extend the aforementioned explanations towards the mapping between IOTP process states and the internal payment scheme related states of the Existing Payment Software/IOTP Payment Bridge.
以下三个表区分了商户、消费者和支付处理人员的环境。他们将上述解释扩展到现有支付软件/IOTP支付桥的IOTP流程状态和内部支付方案相关状态之间的映射。
The Merchant's point of view of payment is limited to the local payment initiation being interlaced with order processing because IOTP assigns the actual payment processing to the Payment Handler.
商户的支付观点仅限于与订单处理交错的本地支付发起，因为IOTP将实际支付处理分配给支付处理人。
ProcessState Description
------------ -----------
ProcessState Description
------------ -----------
NotYetStarted The Payment Transaction exists within the IOTP Application Core, i.e., the Merchant's shop has already signaled to the IOTP Application Core that an IOTP transaction has been initiated by the Consumer.
NotYetStarted支付交易存在于IOTP应用核心内，即商户商店已向IOTP应用核心发出信号，表明消费者已发起IOTP交易。
However, neither any API call has been issued to the IOTP Payment Bridge nor has the IOTP Order Request has been created.
但是，尚未向IOTP支付桥发出任何API调用，也未创建IOTP订单请求。
InProgress The IOTP Application changes the process state to this value when it issues the first API call to the Payment Bridge during Brand List compilation.
InProgress IOTP应用程序在品牌列表编译期间向支付桥发出第一个API调用时，会将流程状态更改为此值。
This value indicates that the Payment Bridge might have some knowledge about the expected payment or might have performed some preparatory tasks (even with the Payment Handler out-of-band to IOTP).
该值表示支付桥可能对预期支付有一些了解，或者可能已经执行了一些准备任务（即使支付处理程序带外到IOTP）。
However, this value does not indicate that any IOTP Order Request has been created and transmitted to the Consumer.
但是，该值并不表示已创建任何IOTP订单请求并已将其发送给消费者。
Suspended The IOTP transaction has been suspended before the order request block has been transmitted to the Consumer.
暂停在订单请求块传输给消费者之前，IOTP交易已暂停。
Implicitly, the payment is also deferred.
隐含地，付款也被推迟。
CompletedOk The IOTP Order Request has been successfully created and transmitted to the Consumer. Actually, this process state indicates only that the order processing has been finished.
CompletedOk IOTP订单请求已成功创建并传输给消费者。实际上，此流程状态仅表示订单处理已完成。
But it contains no indication about the status of the actual payment, which is accepted by the Payment Handler.
但它不包含支付处理程序接受的实际支付状态的指示。
However, successful order processing signals the IOTP Application Core that a payment with some specific parameters is expected within the near future. And this signal might be used by the Existing Payment Software for similar purposes. This attribute might be interpreted as successful preparation of the payment system.
然而，成功的订单处理向IOTP应用程序核心发出信号，表明预计在不久的将来将支付带有某些特定参数的款项。现有的支付软件可能会将此信号用于类似目的。此属性可能被解释为支付系统的成功准备。
Particularly, it is expected that the Existing Payment Software maps this IOTP status value to some other internal value, e.g., "NotYetStarted", that is more accurate from its point of view.
特别是，预计现有支付软件会将该IOTP状态值映射到其他一些内部值，例如“NotYetStarted”，从其角度来看，该值更准确。
As IOTP provides no communication channel between the Merchant and Payment Handler, any change of payment process state will
由于IOTP在商户和支付处理人之间不提供任何通信渠道，因此支付过程状态的任何更改都将
be initiated out-of-band to IOTP, e.g., by electronic statements of account or payment scheme specific mechanisms.
可在带外启动到IOTP，例如通过电子对账单或特定于支付方案的机制。
Failed The IOTP transaction, i.e., order processing, has failed for some (business) reason and it is known that no payment will occur.
失败由于某些（业务）原因，IOTP交易（即订单处理）失败，并且已知不会发生付款。
This indication might be used to clear all data about this transaction within the Existing Payment Bridge (by "RemovePaymentLog" or "ChangeProcessState") or to reverse any preparation (with the Payment Handler out-of-band to IOTP).
此指示可用于清除现有支付桥中有关此交易的所有数据（通过“RemovePaymentLog”或“ChangeProcessState”）或撤销任何准备（支付处理程序带外到IOTP）。
However, the ideal point of view of IOTP suspects that the actual payment transaction has been neither started nor initiated.
然而，IOTP的理想观点怀疑实际支付交易既没有启动也没有启动。
ProcessError The IOTP transaction, i.e., order processing, has failed for some (technical) reason and it is known that no payment will occur.
ProcessError由于某些（技术）原因，IOTP交易（即订单处理）失败，并且已知不会发生付款。
This indication might be used to clear all data about this transaction within the Existing Payment Bridge (by "RemovePaymentLog" or "ChangeProcessState") or to reverse any preparation (with the Payment Handler out-of-band to IOTP).
此指示可用于清除现有支付桥中有关此交易的所有数据（通过“RemovePaymentLog”或“ChangeProcessState”）或撤销任何准备（支付处理程序带外到IOTP）。
However, the ideal point of view of IOTP suspects that the actual payment transaction has been neither started nor initiated.
然而，IOTP的理想观点怀疑实际支付交易既没有启动也没有启动。
Table 5: Merchant
表5：商户
The Consumer's IOTP Application Core restricts its point of view to the payment transaction. It is assumed that the IOTP Payment Bridge handles the preceding brand selection process in a stateless manner.
消费者的物联网应用程序核心将其观点限制在支付交易上。假设IOTP支付桥以无状态方式处理之前的品牌选择过程。
ProcessState Description
------------ -----------
ProcessState Description
------------ -----------
NotYetStarted This encodes the initial process state of any IOTP payment transaction. This value is set during brand selection but it normally will not change during the whole brand selection process.
NotYetStarted此代码对任何IOTP支付交易的初始流程状态进行编码。该值在品牌选择过程中设置，但在整个品牌选择过程中通常不会改变。
InProgress With the issuance of the Start Payment Consumer API call, the IOTP Application Core changes the process state to this value.
在启动支付消费者API调用的过程中，IOTP应用程序核心将流程状态更改为该值。
Suspended The payment transaction has been suspended. Suspension may occur anywhere during brand selection (with the Merchant) or payment processing (with the Payment Handler). On resumption, the IOTP Application Core and the IOTP Payment Bridge have to use other internal data to decide whether brand selection or actual payment processing needs to be continued, i.e., whether the process state needs to be reset to "NotYetStarted" or "InProgress".
已暂停付款交易已暂停。暂停可能发生在品牌选择（与商户）或支付处理（与支付处理人）期间的任何地方。在恢复时，IOTP应用核心和IOTP支付桥必须使用其他内部数据来决定是否需要继续进行品牌选择或实际支付处理，即是否需要将处理状态重置为“NotYetStarted”或“InProgress”。
Note that the Payment API assumes stateless brand selection by the IOTP Payment Bridge. Typically, any suspension during brand selection requires the repetition of the whole process. Hereby, the IOTP Application Core might need to consider any already negotiated conditions in a brand depended purchase (brand, protocol).
请注意，支付API假设IOTP支付桥选择无状态品牌。通常，品牌选择过程中的任何暂停都需要重复整个过程。因此，IOTP应用程序核心可能需要考虑在品牌依赖性购买（品牌、协议）中的任何已经协商的条件。
CompletedOk The successful payment has been acknowledged by the Payment Handler, i.e., the successful IOTP Payment Response has been received.
CompletedOk付款处理程序已确认成功付款，即已收到成功的IOTP付款响应。
Implicitly, this implies successful order processing.
这隐含着订单处理的成功。
Failed The IOTP transaction, i.e., order or payment processing, has failed for some (business) reason. In either case it is known that the payment will not succeed.
失败由于某些（业务）原因，IOTP交易（即订单或付款处理）失败。在这两种情况下，我们都知道付款不会成功。
ProcessError The IOTP transaction, i.e., order or payment processing, has failed for some (technical) reason.
ProcessError由于某些（技术）原因，IOTP交易（即订单或付款处理）失败。
However, the local process state might be different from that of Payment Handler.
但是，本地进程状态可能不同于支付处理程序的状态。
Table 6: Consumer
表6：消费者
The Payment Handler is responsible for the actual payment processing. New payment transactions are reported by the Consumer with the transmission of new IOTP Payment Request Blocks. IOTP Payment Exchange Block are send by the Consumer for payment transaction continuation and resumption.
付款处理人负责实际的付款处理。消费者通过传输新的IOTP支付请求块来报告新的支付交易。IOTP支付交换块由消费者发送，用于继续和恢复支付交易。
ProcessState Description
------------ -----------
ProcessState Description
------------ -----------
NotYetStarted This encodes the initial process state of any payment transaction. Typically, this value will last for a short amount of time.
NotYetStarted这对任何支付交易的初始流程状态进行编码。通常，此值将持续很短的时间。
InProgress The IOTP Application Core changes the process state changes to "InProgress" when the Payment Handler starts with the actual processing of the IOTP Payment Request Block.
InProgress当支付处理程序开始实际处理IOTP支付请求块时，IOTP应用程序核心将流程状态更改为“InProgress”。
Note that this does not assume that the "StartPaymentPaymentHandler" API function has been called.
请注意，这并不假定已调用“StartPaymentPaymentHandler”API函数。
Suspended The payment transaction has been suspended.
已暂停付款交易已暂停。
CompletedOk The payment has been processed, successfully, i.e., the IOTP Payment Response Block was created and transmitted to the Consumer.
CompletedOk付款已成功处理，即IOTP付款响应块已创建并传输给消费者。
Failed The payment transaction, has finally failed for some (business) reason.
支付交易失败，由于某些（业务）原因最终失败。
Note that this value encodes the payment state reported by the IOTP Payment Bridge on "InquireProcessState". It neither reflects whether the payment receipt has been inquired nor whether the IOTP Payment Response Block has been created and submitted to the Consumer.
请注意，该值对IOTP支付桥在“InquireProcessState”上报告的支付状态进行编码。它既不反映是否已查询付款收据，也不反映是否已创建IOTP付款响应块并将其提交给消费者。
ProcessError The payment transaction, has finally failed for some (technical) reason.
ProcessError由于某些（技术）原因，支付交易最终失败。
Note that this value encodes the payment state reported by the IOTP Payment Bridge. It does not reflect whether some IOTP Error Block has been created and submitted to the Consumer.
请注意，该值对IOTP支付桥报告的支付状态进行编码。它不反映是否已创建某些IOTP错误块并提交给消费者。
Table 7: Consumer
表7：消费者
This API function determines the payment brands being accepted by the Payment Handler on behalf of the Merchant.
此API函数确定支付处理程序代表商户接受的支付品牌。
Input Parameters
输入参数
o Payment Direction - provided by the IOTP Application Core o Currency Code and Currency - provided by the IOTP Application Core o Payment Amount - provided by the IOTP Application Core o Merchant Payment Identifier - Merchant's unique private reference to the payment transaction o Merchant Organisation Identifier - used for distinction between multiple merchants that share the some IOTP merchant system o Wallet Identifier - managed by the IOTP Application Core o Merchant Data - specific data used by the IOTP Payment Bridge which is managed in the IOTP Application Core.
o 支付方向-由IOTP应用程序核心o货币代码和货币提供-由IOTP应用程序核心o支付金额提供-由IOTP应用程序核心o商户支付标识符提供-商户对支付交易的唯一私人参考o商户组织标识符-用于区分多个商户共享某些IOTP商户系统o钱包标识符-由IOTP应用核心管理o商户数据-由IOTP应用核心管理的IOTP支付桥使用的特定数据。
XML definition:
XML定义：
<!ELEMENT FindAcceptedPaymentBrand (MerchantData*) >
<!ATTLIST FindAcceptedPaymentBrand
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentBrand (MerchantData*) >
<!ATTLIST FindAcceptedPaymentBrand
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
Output Parameters
输出参数
o Payment Brand Identifier - for insertion in the Brand List Component's Brand Element o Payment Brand Name and language annotation - for insertion in the Brand List Component's Brand Element o Payment Brand Logo Net Location - for insertion in the Brand List Component's Brand Element o Payment Brand Narrative Description - for insertion in the Brand List Component's Brand Element o (Brand) Packaged Content - further payment brand description for insertion in the Brand List Component's Brand Element
o 支付品牌标识符-用于插入品牌列表组件的品牌元素o支付品牌名称和语言注释-用于插入品牌列表组件的品牌元素o支付品牌徽标净位置-用于插入品牌列表组件的品牌元素o支付品牌叙述性描述-用于插入品牌列表组件的品牌元素o（品牌）包装内容-插入品牌列表组件的品牌元素的进一步付款品牌描述
The Existing Payment Software returns an empty list of brand items, if it does not support any payment brand/payment protocol combination for the given payment parameters.
如果现有支付软件不支持给定支付参数的任何支付品牌/支付协议组合，则会返回品牌项目的空列表。
XML definition:
XML定义：
<!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) >
<!ELEMENT BrandItem (BrandPackagedContent*) >
<!ATTLIST BrandItem
BrandId CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) >
<!ELEMENT BrandItem (BrandPackagedContent*) >
<!ATTLIST BrandItem
BrandId CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function determines the instances of payment protocols (and optionally the payment brands) being accepted by the Payment Handler on behalf of the Merchant. The function might be called in two variants:
此API函数确定支付处理程序代表商户接受的支付协议实例（以及可选的支付品牌）。该函数可以在两种变体中调用：
o With the Brand Identifier set on the input parameter list: The function responds with the payment protocols that fits to the submitted brand.
o 在输入参数列表上设置品牌标识符时：该函数使用适合所提交品牌的支付协议进行响应。
o Without any Brand Identifier - that allows the omission of the "Find Accepted Payment Brand" API call (cf. Section 4.1.1): This function responds with both the supported brand identifiers and the payment protocols being specified by the Brand Elements.
o 无任何品牌标识符-允许省略“查找已接受的支付品牌”API调用（参见第4.1.1节）：此函数使用受支持的品牌标识符和品牌元素指定的支付协议进行响应。
Input Parameters
输入参数
o Brand Identifier - returned by "Find Accepted Payment Brand" o Payment Direction o Currency Code and Currency o Payment Amount o Merchant Payment Identifier - Merchant's unique private reference to the payment transaction o Merchant Organisation Identifier - used for distinction between multiple merchants that share the some IOTP merchant system o Wallet Identifier - managed by the IOTP Application Core o (Brand) Packaged Content - further payment brand description; returned by "Find Accepted Payment Brand"; this elements are only provided if the Brand Identifier is set o Merchant Data - specific data used by the IOTP Payment Bridge which is managed in the IOTP Application Core.
o 品牌标识符-由“查找接受的支付品牌”返回o支付方向o货币代码和货币o支付金额o商户支付标识符-商户对支付交易的唯一私人参考o商户组织标识符-用于区分共享某个IOTP商户系统的多个商户o钱包标识符-由IOTP应用核心管理o（品牌）打包内容-进一步的支付品牌描述；由“查找接受的支付品牌”返回；仅当品牌标识符设置为商户数据-IOTP支付桥使用的特定数据（在IOTP应用程序核心中管理）时，才提供此元素。
XML definition:
XML定义：
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
MerchantData?) >
<!ATTLIST FindAcceptedPaymentProtocol
BrandId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
MerchantData?) >
<!ATTLIST FindAcceptedPaymentProtocol
BrandId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
Output Parameters
输出参数
o Payment Protocol Identifier - for insertion in the Brand List Component's Pay Protocol Element o Protocol Brand Identifier - for insertion in the Protocol Brand Element of the Brand List Component's Brand Element o Payment Protocol Name and language annotation- for insertion in the Brand List Component's Pay Protocol Element o Payment Request Net Location - for insertion in the Brand List Component's Pay Protocol Element o Secured Payment Request Net Location - for insertion in the Brand List Component's Pay Protocol Element o Brand Item List (cf. Section 4.1.1) - there must be at least one element if no brand identifier has been provided on the input parameter list. o (Protocol Amount) Packaged Content - for insertion in the Brand List Component's Protocol Amount Element o (Pay Protocol) Packaged Content - for insertion in the Brand List Component's Pay Protocol Element o Currency Amount element - quite similar to the definition in [IOTP], that contain - refined Currency Code and Currency - for insertion in the Brand List Component's Currency Amount Element - refined Payment Amount - for insertion in the Brand List Component's Currency Amount Element o Brand - there must be at least one element in each Protocol Item if no brand identifier has been provided on the input parameter list.
o 支付协议标识符-用于插入品牌列表组件的支付协议元素o协议品牌标识符-用于插入品牌列表组件的品牌元素o支付协议名称和语言注释-用于插入品牌列表组件的支付协议元素o支付请求网位置-插入品牌列表组件的支付协议元素o安全支付请求净位置-插入品牌列表组件的支付协议元素o品牌项目列表（参见第4.1.1节）-如果输入参数列表中未提供品牌标识符，则必须至少有一个元素。o（协议金额）打包内容-用于插入品牌列表组件的协议金额元素o（支付协议）打包内容-用于插入品牌列表组件的支付协议元素o货币金额元素-与[IOTP]中的定义非常相似，包含-精炼货币代码和货币-用于插入品牌列表组件的货币金额元素-精炼支付金额-用于插入品牌列表组件的货币金额元素o品牌-如果输入参数上未提供品牌标识符，则每个协议项中必须至少有一个元素列表
XML definition:
XML定义：
<!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+,
BrandItem*) >
<!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*
CurrencyAmount+, Brand*,ProtocolBrand*)>
<!ATTLIST ProtocolItem
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
ProtocolName CDATA #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+,
BrandItem*) >
<!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*
CurrencyAmount+, Brand*,ProtocolBrand*)>
<!ATTLIST ProtocolItem
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
ProtocolName CDATA #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED >
<!ELEMENT Brand EMPTY >
<!ATTLIST Brand
BrandId CDATA #REQUIRED >
<!ELEMENT Brand EMPTY >
<!ATTLIST Brand
BrandId CDATA #REQUIRED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #IMPLIED
Amount CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #IMPLIED
Amount CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function provides the remaining initialization data being required by the Consumer's or Payment Handler's Existing Payment Software. This function might be called both for "brand dependent" and "brand independent" transaction types. In either case, this function is called with one particular brand.
此API函数提供消费者或支付处理程序的现有支付软件所需的其余初始化数据。此函数可用于“品牌相关”和“品牌独立”交易类型。在任何一种情况下，都会使用一个特定品牌调用此函数。
Input Parameters
输入参数
o Brand Identifier - returned by "Find Accepted Payment Brand" o Merchant Payment Identifier - Merchant's unique private reference to the payment transaction o Payment Direction o Currency Code and Currency - from the Brand List Component's Currency Amount Element o Payment Amount - from the Brand List Component's Currency Amount Element o Payment Protocol Identifier - from the Brand List Component's Pay Protocol Element o Protocol Brand Identifier - from the Protocol Brand Element which relates to the selected Brand Element, if any o (TradingRoleData) Receiver Organization Identifier o OkFrom, OkTo - identical to the entries of the Order Component
o 品牌标识符-由“查找接受的支付品牌”返回o商户支付标识符-商户对支付交易的唯一私人参考o支付方向o货币代码和货币-来自品牌列表组件的货币金额元素o支付金额-来自品牌列表组件的货币金额元素o支付协议标识符-来自品牌列表组件的支付协议元素o协议品牌标识符-来自与所选品牌元素相关的协议品牌元素，如果有o（TradingRoleData）接收方组织标识符o OkFrom，OkTo-与订单组件的条目相同
Merchant Payment Identifier
商户支付标识符
o Merchant Organisation Identifier - used for distinction between multiple merchants that share the some IOTP merchant system o Wallet Identifier and/or Pass Phrase
o 商户组织标识符-用于区分共享某个IOTP商户系统的多个商户和/或钱包标识符和/或通行短语
Protocol Brand Element
协议品牌要素
o (Brand) Packaged Content - further payment brand description, from the Brand List Component's Brand Element o (Protocol Amount) Packaged Content - further payment protocol description, from the Brand List Component's Protocol Amount Element
o （品牌）打包内容-来自品牌列表组件的品牌元素的进一步支付品牌描述o（协议金额）打包内容-来自品牌列表组件的协议金额元素的进一步支付协议描述
o (Pay Protocol) Packaged Content - further payment protocol
description, from the Brand List Component's Pay Protocol
Element
o (Protocol Brand) Packaged Content - further brand information,
from the Protocol Brand Element of the Brand List Component
which relates to the selected Brand Element, if any
o (Order) Packaged Content - further order description, from the
Order Element
o three Brand Selection Info Packaged Content elements - copied
from the Brand Selection Component on brand dependent purchases
o Brand - additional data about the payment brand
o Protocol Amount - additional data about the payment protocol
o Currency Amount - additional payment brand and currency
specific data
o Merchant Data - specific data used by the IOTP Payment Bridge
which is managed in the IOTP Application Core.
o (Pay Protocol) Packaged Content - further payment protocol
description, from the Brand List Component's Pay Protocol
Element
o (Protocol Brand) Packaged Content - further brand information,
from the Protocol Brand Element of the Brand List Component
which relates to the selected Brand Element, if any
o (Order) Packaged Content - further order description, from the
Order Element
o three Brand Selection Info Packaged Content elements - copied
from the Brand Selection Component on brand dependent purchases
o Brand - additional data about the payment brand
o Protocol Amount - additional data about the payment protocol
o Currency Amount - additional payment brand and currency
specific data
o Merchant Data - specific data used by the IOTP Payment Bridge
which is managed in the IOTP Application Core.
XML definition:
XML定义：
<!ELEMENT GetPaymentInitializationData (ProtocolBrand?
BrandPackagedContent*
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
MerchantData*) >
<!ATTLIST GetPaymentInitializationData
BrandId CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ReceiverOrgId CDATA #IMPLIED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT GetPaymentInitializationData (ProtocolBrand?
BrandPackagedContent*
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
MerchantData*) >
<!ATTLIST GetPaymentInitializationData
BrandId CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ReceiverOrgId CDATA #IMPLIED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o OkFrom, OkTo - for insertion in the Payment Component o (TradingRoleData) Packaged Content - further payment protocol description; the Name Attribute of the packaged Content element must include "Payment:" as the prefix, for example "Payment:SET-OD". For more information, see [SET/IOTP]. o (Order) Packaged Content - defaults to the supplied order packaged content if omitted.
o OkFrom，OkTo-用于插入支付组件o（TradingRoleData）打包内容-进一步的支付协议说明；打包内容元素的Name属性必须包含“Payment:”作为前缀，例如“Payment:SET-OD”。有关更多信息，请参阅[SET/IOTP]。o（订单）打包内容-如果省略，则默认为提供的订单打包内容。
XML definition:
XML定义：
<!ELEMENT GetPaymentInitializationDataResponse
(OrderPackagedContent*,
TradingRoleDataPackagedContent*) >
<!ATTLIST GetPaymentInitializationDataResponse
OkFrom CDATA #IMPLIED
OkTo CDATA #IMPLIED>
<!ELEMENT GetPaymentInitializationDataResponse
(OrderPackagedContent*,
TradingRoleDataPackagedContent*) >
<!ATTLIST GetPaymentInitializationDataResponse
OkFrom CDATA #IMPLIED
OkTo CDATA #IMPLIED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function inquires any payment protocol specific authentication challenge value from the IOTP Payment Bridge. In Baseline IOTP this API function is called by the Merchant (or Financial Institution). The IOTP Application Core may propose a choice of algorithms to the IOTP Payment Bridge. However, the IOTP Payment Bridge may ignore the proposal and select some other algorithm.
此API函数从IOTP支付桥查询任何特定于支付协议的身份验证质询值。在基线IOTP中，商户（或金融机构）调用此API函数。IOTP应用核心可向IOTP支付桥提出算法选择。然而，IOTP支付桥可能会忽略该提议，并选择其他一些算法。
The inquiry is assumed to be stateless. E.g., the IOTP Application Core may check the returned algorithm and stop transaction processing without notifying the IOTP Payment Bridge.
调查被认为是无国籍的。例如，IOTP应用核心可以检查返回的算法并停止事务处理，而无需通知IOTP支付桥。
The IOTP Application Core may issue several API calls to the IOTP Payment Bridge to build up the IOTP Authentication Request Block. Any subsequently submitted choice of algorithms should be constrained by the accepted algorithms from earlier API responses.
IOTP应用核心可向IOTP支付桥发出若干API调用，以建立IOTP认证请求块。任何随后提交的算法选择都应受到来自早期API响应的可接受算法的约束。
The IOTP Payment Bridge responds with the Business Error Code if it does not provide any (more) authentication algorithms and challenges.
如果IOTP支付网桥不提供任何（更多）认证算法和挑战，则会以业务错误代码进行响应。
Input Parameters
输入参数
o Authentication Identifier - the authenticator may provide its payment identifier, i.e., Payment Handler or Merchant Payment Identifier. o Wallet Identifier and/or Pass Phrase o set of pre-selected algorithms for authentication
o 身份验证标识符-身份验证人可提供其支付标识符，即支付处理人或商户支付标识符。o钱包标识符和/或密码o一组预先选定的身份验证算法
XML definition:
XML定义：
<!ELEMENT InquireAuthChallenge (Algorithm*) >
<!ATTLIST InquireAuthChallenge
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT InquireAuthChallenge (Algorithm*) >
<!ATTLIST InquireAuthChallenge
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o list of Authentication Challenge Packaged Contents - for insertion into the IOTP Authentication Request Component o Algorithm Element - for insertion into the IOTP Authentication Request Component
o 身份验证质询打包内容列表-用于插入IOTP身份验证请求组件o算法元素-用于插入IOTP身份验证请求组件
XML definition:
XML定义：
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
Algorithm) >
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
Algorithm) >
The Consumer's IOTP Application Core defers payment protocol specific authentication processing and the current challenge value to the active IOTP Payment Bridge. Alternative authentication algorithms might be tried sequentially or offered to the user for selection.
消费者的IOTP应用程序核心将特定于支付协议的认证处理和当前质询值延迟到活动IOTP支付桥。可选的身份验证算法可以按顺序尝试，也可以提供给用户选择。
Note that the IOTP Application Core has to consider both the current context and the algorithm in order to determine the responsible IOTP Payment Bridge.
请注意，IOTP应用程序核心必须考虑当前上下文和算法，以确定负责的IOTP支付桥。
Failed authentication is reported by the Business Error Code which might trigger the inquiry of the details ("Inquire Process State"). Final failures might be encoded by the process state "Failed".
失败的身份验证由业务错误代码报告，该错误代码可能会触发对详细信息的查询（“查询流程状态”）。最终失败可能由进程状态“Failed”编码。
Input Parameters
输入参数
o Authentication Identifier o Wallet Identifier and/or Pass Phrase o Authentication Challenge Packaged Content - copied from the IOTP Authentication Request Component o Algorithm Element - copied from the IOTP Authentication Request Component
o 身份验证标识符o钱包标识符和/或密码o身份验证挑战打包内容-从IOTP身份验证请求组件复制o算法元素-从IOTP身份验证请求组件复制
XML definition:
XML定义：
<!ELEMENT Authenticate (Algorithm, AuthReqPackagedContent*) >
<!ATTLIST Authenticate
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT Authenticate (Algorithm, AuthReqPackagedContent*) >
<!ATTLIST Authenticate
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Authentication Response Packaged Content - for insertion into the IOTP Authentication Response Component
o 身份验证响应打包内容-用于插入IOTP身份验证响应组件
XML definition:
XML定义：
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function verifies the Consumer's payment protocol specific authentication response. In Baseline IOTP this API function is called by the Merchant (or the Financial Institution). It is called only if the counter party has responded with an IOTP Authentication Response Component within the Authentication Response Block. Of course, the IOTP Application Core traces the need of such an response.
此API函数验证消费者的特定于支付协议的身份验证响应。在基线IOTP中，商户（或金融机构）调用此API函数。仅当对方已在身份验证响应块中使用IOTP身份验证响应组件进行响应时，才会调用该函数。当然，IOTP应用程序核心追踪了此类响应的需求。
Due to the authentication's statelessness, all parameters (algorithm, challenge and response) are submitted to the IOTP Payment Bridge. Authentication failure is reported by a Process State different from "CompletedOK".
由于身份验证的无状态性，所有参数（算法、质询和响应）都提交给IOTP支付桥。身份验证失败由不同于“CompletedOK”的进程状态报告。
Input Parameters
输入参数
o Authentication Identifier o Wallet Identifier and/or Pass Phrase o Authentication Challenge Packaged Content - generated by previous "Inquire Authentication Challenge" API call o Algorithm Element o Authentication Response Packaged Content - copied from the Authentication Response Component
o 身份验证标识符o钱包标识符和/或密码o身份验证质询打包内容-由以前的“查询身份验证质询”API调用生成o算法元素o身份验证响应打包内容-从身份验证响应组件复制
XML definition:
XML定义：
<!ELEMENT CheckAuthResponse (Algorithm, AuthReqPackagedContent*,
AuthResPackagedContent*) >
<!ATTLIST CheckAuthResponse
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT CheckAuthResponse (Algorithm, AuthReqPackagedContent*,
AuthResPackagedContent*) >
<!ATTLIST CheckAuthResponse
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Current Process (Authentication) State o Completion Code o Status Description and its language annotation
o 当前进程（身份验证）状态o完成代码o状态描述及其语言注释
XML definition:
XML定义：
<!ELEMENT CheckAuthResponseResponse EMPTY > <!ATTLIST CheckAuthResponseResponse ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError)#REQUIRED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED >
<!元素CheckAuthResponseResponse空><！ATTLIST CheckAuthResponseResponse进程状态（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError）#必需的完成代码NMTOKEN#隐含xml:lang NMTOKEN#隐含状态描述CDATA#隐含>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function determines which instances of a Payment Brand, e.g., two Mondex cards, are present. The same physical card may even represent multiple payment instruments.
此API函数确定存在支付品牌的哪些实例，例如两张Mondex卡。同一张物理卡甚至可能代表多个支付工具。
The IOTP Application Core supplies possible payment brand and payment protocol to the IOTP Payment Bridge that has to be considered when the IOTP Payment Bridge searches for appropriate payment instruments. This set represents the (sub)set of payment alternatives being supported by the Merchant. If the IOTP Application Cote has multiple possible payment brand/protocol, it can call this function in turn.
IOTP应用核心向IOTP支付桥提供可能的支付品牌和支付协议，当IOTP支付桥搜索适当的支付工具时，必须考虑这一点。此集合表示商户支持的支付备选方案（子）集合。如果IOTP应用程序Cote具有多个可能的支付品牌/协议，则可以依次调用此函数。
The Existing Payment Software responds with PayInstrument Elements with empty PayInstId attributes if it does not distinguish between different payment instruments for the particular payment alternatives.
如果现有支付软件不区分特定支付方案的不同支付工具，则会使用PayInstitd属性为空的PayInstit元素进行响应。
Note that the Payment API assumes that the values of the attributes BrandId, ProtocolId, ProtocolBrandId and the currency amount suffice for the determination of the appropriate Packaged Content Element that will be transmitted to the Payment Handler later on.
请注意，支付API假定属性BrandId、ProtocolId、ProtocolBrandId和货币金额的值足以确定稍后将传输到支付处理程序的适当打包内容元素。
Input Parameters
输入参数
o Brand Identifier - copied from the Brand List Component's Brand Element o Payment Protocol Identifier and associated Protocol Brand Identifier o Payment Direction - copied from the Brand List Component o Currency Code and Currency - copied from the Currency Amount Element o Payment Amount - copied from the Currency Amount Element o Consumer Payment Identifier - Consumer's unique reference to the current payment transaction o Wallet Identifier - managed by the IOTP Application Core o (Brand) Packaged Content - further payment brand description; copied from the Brand List Component's Brand Element o (Protocol Brand) Element - further information; copied from the Protocol Brand Element of the Brand List Component which relates to the Consumer selected Brand Element, if any. o (Protocol Amount) Packaged Content - further payment protocol description, copied from the Brand List Component's Protocol Amount Element
o 品牌标识符-从品牌列表组件的品牌元素复制o支付协议标识符和关联协议品牌标识符o支付方向-从品牌列表组件复制o货币代码和货币-从货币金额元素复制o支付金额-从货币金额元素复制o消费者支付标识符-消费者对当前支付交易的唯一引用o钱包标识符-由IOTP应用程序核心o（品牌）打包内容管理-进一步的支付品牌描述；复制自品牌列表组件的品牌元素o（协议品牌）元素-进一步信息；复制自品牌列表组件的协议品牌元素，该组件与消费者选择的品牌元素（如果有）相关。o（协议金额）打包内容-进一步的支付协议描述，从品牌列表组件的协议金额元素复制
o Element (Protocol) Packaged Content - further payment protocol description, copied from the Brand List Component's Pay Protocol Element
o 元素（协议）打包内容-进一步的支付协议描述，从品牌列表组件的支付协议元素复制
XML definition:
XML定义：
<!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
ProtocolBrand?,
PayProtocolPackagedContent*,
ProtocolAmountPackagedContent*) >
<!ATTLIST FindPaymentInstrument
BrandId CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED >
<!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
ProtocolBrand?,
PayProtocolPackagedContent*,
ProtocolAmountPackagedContent*) >
<!ATTLIST FindPaymentInstrument
BrandId CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED >
Output Parameters
输出参数
o The known Payment Instrument Identifiers, these are internal values o The user-defined names of the payment instrument and their language encoding
o 已知的支付工具标识符，这些是支付工具的用户定义名称及其语言编码的内部值
The Existing Payment Software responds with an empty list of identifiers, either if it does not distinguish between different payment instruments or if there are no registered payment instruments available despite brand support for at least one (unspecified) payment protocol. In the latter case, the IOTP Payment Bridge has to request the registration of a suitable payment instrument at a subsequent step of the payment process.
如果现有支付软件不区分不同的支付工具，或者尽管品牌支持至少一个（未指定）支付协议，但没有可用的注册支付工具，则现有支付软件会以空标识符列表进行响应。在后一种情况下，IOTP支付桥必须在支付流程的后续步骤中请求注册合适的支付工具。
XML definition:
XML定义：
<!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) >
<!ELEMENT PayInstrument EMPTY >
<!ATTLIST PayInstrument
Id CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED
PayInstName CDATA #REQUIRED >
<!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) >
<!ELEMENT PayInstrument EMPTY >
<!ATTLIST PayInstrument
Id CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED
PayInstName CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function checks whether a payment (both debit and credit) can go ahead. It can be used, for example, to check
此API函数检查付款（借记和贷记）是否可以进行。例如，它可以用来检查
o if there are sufficient funds available in a particular currency for an electronic cash payment brand, o whether there is sufficient value space left on the payment instrument for payment refund, o whether required system resources are available and properly configured, e.g., serial ports or baud rate, o whether environment requirements are fulfilled, e.g., chip card reader presence or Internet connection.
o 如果电子现金支付品牌有足够的特定货币资金可用，o支付工具上是否有足够的价值空间用于支付退款，o所需的系统资源是否可用并正确配置，例如串行端口或波特率，o是否满足环境要求，例如芯片卡读卡器存在或互联网连接。
If the payment method is based on external components, e.g., magnetic stripe or chip cards, and the check accesses the medium, the existing payment method should not mutually exclusive lock system resources, e.g., serial port or modem, that may also be required by other Existing Payment Software, e.g., multiple payment software components may share the same card reader. If this happens for API internal request processing, the function has to unlock these components prior to return. Otherwise, the payment may not proceed if the Consumer cancels immediately and decides to use another payment instrument. In this event the previous IOTP Payment Bridge is not notified about the change.
如果支付方法基于外部组件，例如磁条或芯片卡，并且支票访问介质，则现有支付方法不应相互排斥地锁定系统资源，例如串行端口或调制解调器，其他现有支付软件也可能需要这些资源，例如。，多个支付软件组件可能共享同一个读卡器。如果API内部请求处理发生这种情况，函数必须在返回之前解锁这些组件。否则，如果消费者立即取消并决定使用其他支付工具，则可能无法继续支付。在这种情况下，之前的IOTP支付桥不会收到有关变更的通知。
This function call happens immediately after the Consumer's payment instrument selection. For example, if the payment instrument is a chip card, that is not inserted in the chip card reader, the Consumer may be prompted for its insertion. However, the Consumer should be able to hit some 'skip' button, if the payment check is part of the actual payment protocol, too. Finally, the IOTP Payment Bridge may provide only a subset of these capabilities or may even directly generate a successful response without any checks.
此函数调用在消费者选择支付工具后立即发生。例如，如果支付工具是未插入芯片卡读取器中的芯片卡，则可能会提示消费者插入芯片卡。然而，如果支付检查也是实际支付协议的一部分，消费者应该能够点击一些“跳过”按钮。最后，IOTP支付桥可能仅提供这些功能的一个子集，甚至可能直接生成成功响应，而无需任何检查。
Input Parameters
输入参数
o Brand Identifier - user selection o Payment Instrument Identifier - user selection o Currency Code and Currency Code Type - copied from the selected Currency Amount Element o Payment Amount - copied from the selected Currency Amount Element o Payment Direction - copied from the selected Trading Protocol Option Block o Protocol Identifier - copied from the selected Pay Protocol Element
o 品牌标识符-用户选择o支付工具标识符-用户选择o货币代码和货币代码类型-从所选货币金额元素复制o支付金额-从所选货币金额元素复制o支付方向-从所选交易协议选项块复制o协议标识符-复制从选定的支付协议元素
o Protocol Brand Identifier - copied from the selected Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o Consumer Payment Identifier - Consumer's unique reference to the current payment transaction o Wallet Identifier and/or Pass Phrase o (Brand) Packaged Content - copied from the selected Brand Element o (Protocol Amount) Packaged Content - copied from the selected Protocol Amount Element o (Protocol) Packaged Content - copied from the selected Pay Protocol Element o (Protocol Brand) Packaged Content - copied from the selected Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any
o 协议品牌标识符-从与所选品牌元素相关的品牌列表组件的所选协议品牌元素（如果有）复制o消费者支付标识符-消费者对当前支付交易的唯一引用o钱包标识符和/或通行短语o（品牌）打包内容-从选定的品牌元素o（协议金额）复制打包内容-从选定的协议金额元素o（协议）复制打包内容-从选定的支付协议元素o（协议品牌）复制打包内容-从与所选品牌元素（如果有）相关的品牌列表组件的所选协议品牌元素复制
XML definition:
XML定义：
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*>
<!ATTLIST CheckPaymentPossibility
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*>
<!ATTLIST CheckPaymentPossibility
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o three Brand Selection Info Packaged Content elements - for insertion into the Brand Selection component o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data
o 三个品牌选择信息打包内容元素-用于插入品牌选择组件o品牌-关于支付品牌的附加数据o协议金额-关于支付协议的附加数据o货币金额-附加支付品牌和特定于货币的数据
XML definition:
XML定义：
<!ELEMENT CheckPaymentPossibilityResponse
(BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*) >
<!ATTLIST CheckPaymentPossibilityResponse >
<!ELEMENT CheckPaymentPossibilityResponse
(BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*) >
<!ATTLIST CheckPaymentPossibilityResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
These Payment API calls may be made either by the Consumer's or Payment Handler's IOTP Application Core.
这些支付API调用可以由消费者或支付处理程序的IOTP应用程序核心进行。
This API function initiates the actual payment transaction at the Consumer side. The IOTP Payment Bridge and the Existing Payment Software perform all necessary initialization and preparation for payment transaction processing. This includes the reservation of external periphery. E.g., 1) the Consumer's chip card reader needs to be protected against access from other software components, 2) the insertion of the chip card may be requested, 3) the Internet connection may be re-established, or 4) the Payment Handler may open a mutual exclusive session to the security hardware.
此API函数在消费者端启动实际支付交易。IOTP支付桥和现有支付软件执行支付交易处理的所有必要初始化和准备。这包括保留外部外围设备。例如，1）需要保护消费者的芯片卡读卡器免受其他软件组件的访问，2）可以请求插入芯片卡，3）可以重新建立互联网连接，或者4）支付处理程序可以打开与安全硬件的互斥会话。
The IOTP Payment Bridge monitors the payment progress and stores the current payment states such that resumption - even after power failures - remains possible. Note that the IOTP Application Core supplies only a subset of the following input parameter to the associated resumption API function and refers to the payment transaction through the party's payment identifier.
IOTP支付网桥监控支付进度并存储当前支付状态，以便即使在断电后也可以恢复。请注意，IOTP应用程序核心仅向关联的恢复API函数提供以下输入参数的子集，并通过一方的支付标识符引用支付交易。
Input Parameters
输入参数
o Brand Identifier - copied from the selected Brand Element o Payment Instrument Identifier - the user selection o Currency Code and Currency - copied from the selected Currency Amount Element o Payment Amount - copied from the selected Currency Amount Element o Payment Direction - copied from the Brand List Component o Protocol Identifier - copied from the selected Payment Protocol Element
o 品牌标识符-从所选品牌元素复制o支付工具标识符-用户选择o货币代码和货币-从所选货币金额元素复制o支付金额-从所选货币金额元素复制o支付方向-从品牌列表组件复制o协议标识符-复制从所选的支付协议元素
o Protocol Brand Element - further information; copied from the Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o OkFrom, OkTo - copied from the Payment Component o Consumer Payment Identifier - Consumer's unique reference to the current payment transaction o Wallet Identifier and/or Pass Phrase o Call Back Function - used for end user notification/logging purposes o Call Back Language List. This list is required if the Call Back Function is set o (Brand) Packaged Content - further payment brand description; copied from the selected Brand Element's content o (Protocol Amount) Packaged Content - further payment protocol description; copied from the selected Protocol Amount Element's content o (Payment Protocol) Packaged Content - further payment protocol description; copied from the selected Pay Protocol Element's content o (Order) Packaged Content - further order description, copied from the Order Component
o 协议品牌要素-进一步信息；从与所选品牌元素相关的品牌列表组件的协议品牌元素（如果有）中复制，OkTo-从支付组件复制o消费者支付标识符-消费者对当前支付交易的唯一引用o钱包标识符和/或密码短语o回拨功能-用于最终用户通知/记录o回拨语言列表。如果回拨功能设置为（品牌）打包内容-进一步支付品牌说明，则需要此列表；复制自所选品牌元素的内容o（协议金额）打包内容-进一步的支付协议说明；复制自所选协议金额元素的内容o（支付协议）打包内容-进一步的支付协议说明；从所选支付协议元素的内容复制o（订单）打包内容-进一步的订单说明，从订单组件复制
XML definition:
XML定义：
<!ELEMENT StartPaymentConsumer (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*) >
<!ATTLIST StartPaymentConsumer
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
<!ELEMENT StartPaymentConsumer (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*) >
<!ATTLIST StartPaymentConsumer
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters
输出参数
o Continuation Status o (Payment Scheme) Packaged Content - for insertion into the Payment Scheme Component of the IOTP Payment Request Block
o 延续状态o（付款方案）打包内容-用于插入IOTP付款请求块的付款方案组件
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
IOTP应用程序核心可以在响应分析失败时多次重新发出此请求。
XML definition:
XML定义：
<!ELEMENT StartPaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT StartPaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function initializes the Consumer initiated payment transaction at the Payment Handler's side. Similar to the Consumer's system, the IOTP Payment Bridge and the Existing Payment Software perform all necessary initialization and preparation for payment transaction processing.
此API函数在支付处理程序端初始化消费者发起的支付交易。与消费者系统类似，IOTP支付桥和现有支付软件执行支付交易处理的所有必要初始化和准备。
Input Parameters
输入参数
o Brand Identifier - copied from the Consumer selected Brand Element o Consumer Payment Identifier - copied from the Payment Scheme Component o Currency Code and Currency - copied from the Consumer selected Currency Amount Element o Payment Amount - copied from the Consumer selected Currency Amount Element o Payment Direction - copied from the Brand List Component o Protocol Identifier - copied from the Consumer selected Payment Protocol Element o Protocol Brand Identifier - copied from the Brand Protocol Element of the Brand List Component which relates to the Consumer selected Brand Element, if any o OkFrom, OkTo - copied from the Payment Component o Payment Handler Payment Identifier - Payment Handler's unique reference to the current payment transaction o Merchant Organisation Identifier - copied from the Merchant's Organisation Element
o 品牌标识符-从消费者选择的品牌元素复制o消费者支付标识符-从支付方案组件复制o货币代码和货币-从消费者选择的货币金额元素复制o支付金额-从消费者选择的货币金额元素复制o支付方向-从品牌复制列表组件o协议标识符-从消费者选择的支付协议元素复制o协议品牌标识符-从与消费者选择的品牌元素（如果有）相关的品牌列表组件的品牌协议元素复制o协议品牌标识符，OkTo-从支付组件复制o支付处理程序支付标识符-支付处理程序对当前支付交易的唯一引用o商户组织标识符-从商户组织元素复制
o Wallet Identifier - renaming to till identifier neglected - and/or Pass Phrase o Call Back Function - used for end user notification/logging purposes o Call Back Language List. This list is required if the call back function is set o (Brand) Packaged Content - further payment brand description; copied from the Consumer selected Brand Element's content o (Protocol Brand) Packaged Content - further information; copied from the Protocol Brand Element of the Brand List Component which relates to the Consumer selected Brand Element, if any. o (Protocol Amount) Packaged Content - further payment protocol description; copied from the Consumer selected Protocol Amount Element's content o (Protocol) Packaged Content - further payment protocol description; copied from the Consumer selected Pay Protocol Element's content o (TradingRoleData) Packaged Content - further payment protocol description; the Name Attribute of the packaged contents must include "Payment:" as the prefix, for example "Payment:SET-OD". For more information, see [SET/IOTP]. o Three Brand Selection Info Packaged Content Elements - copied from the Brand Selection Component o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data o (Payment Scheme) Packaged Content.
o 钱包标识符-重命名为直到忽略标识符-和/或传递短语o回拨功能-用于最终用户通知/记录o回拨语言列表。如果回拨功能设置为（品牌）打包内容-进一步支付品牌说明，则需要此列表；复制自消费者选定品牌元素的内容o（协议品牌）包装内容-进一步信息；复制自品牌列表组件的协议品牌元素，该组件与消费者选择的品牌元素（如果有）相关。o（协议金额）打包内容-进一步的支付协议说明；复制自消费者选择的协议金额元素的内容o（协议）打包内容-进一步的支付协议描述；复制自消费者选择的支付协议元素的内容o（TradingRoleData）打包内容-进一步的支付协议描述；打包内容的Name属性必须包含“Payment:”作为前缀，例如“Payment:SET-OD”。有关更多信息，请参阅[SET/IOTP]。o三个品牌选择信息打包内容元素-复制自品牌选择组件o品牌-关于支付品牌的附加数据o协议金额-关于支付协议的附加数据o货币金额-附加支付品牌和特定于货币的数据o（支付方案）打包内容。
XML definition:
XML定义：
<!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
TradingRoleDataPackagedContent*,
PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandler
BrandId CDATA #REQUIRED
ConsumerPayId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
<!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
TradingRoleDataPackagedContent*,
PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandler
BrandId CDATA #REQUIRED
ConsumerPayId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED PaymentHandlerPayId CDATA #REQUIRED MerchantOrgId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
OkFrom CDATA#REQUIRED OkTo CDATA#REQUIRED PaymentHandlerPayId CDATA#REQUIRED MerchanitorGID CDATA#REQUIRED WalletID CDATA#隐含密码短语CDATA#隐含CallBackFunction CDATA#隐含CallBackLanguageList NMTOKENS#隐含>
Output Parameters
输出参数
o Continuation Status o (Payment Scheme) Packaged Content - for insertion into the Payment Scheme Component of the IOTP Payment Exchange Block
o 继续状态o（支付方案）打包内容-用于插入IOTP支付交换块的支付方案组件
The response message must contain payment schema data if the continuation status signals "Continue". The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
如果继续状态信号为“继续”，则响应消息必须包含付款模式数据。IOTP应用程序核心可以在响应分析失败时多次重新发出此请求。
XML definition:
XML定义：
<!ELEMENT StartPaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT StartPaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function resumes a previously suspended payment at the Consumer side. Resumption includes the internal inquiry of the payment transaction data, e.g., payment amount, protocol identifier, and the whole initialization as it has been applied on the "Start Payment Consumer" API request.
此API函数在消费者端恢复先前暂停的付款。恢复包括支付交易数据的内部查询，例如支付金额、协议标识符，以及应用于“启动支付消费者”API请求的整个初始化。
It is up to the IOTP Application Core to decide whether an IOTP Payment Request Block or a IOTP Payment Exchange Block needs to be generated. One indicator might be the receipt of a previous IOTP Payment Exchange Block from the Payment Handler, e.g., the knowledge of the Payment Handler Payment Identifier.
IOTP应用程序核心决定是否需要生成IOTP支付请求块或IOTP支付交换块。一个指标可能是从支付处理程序收到以前的IOTP支付交换块，例如，了解支付处理程序支付标识符。
Input Parameters
输入参数
o Consumer Payment Identifier o Wallet Identifier and/or Pass Phrase
o 消费者支付标识符o钱包标识符和/或密码短语
o Call Back Function - used for end user notification/logging purposes
o 回调功能-用于最终用户通知/记录目的
XML definition:
XML定义：
<!ELEMENT ResumePaymentConsumer EMPTY >
<!ATTLIST ResumePaymentConsumer
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
<!ELEMENT ResumePaymentConsumer EMPTY >
<!ATTLIST ResumePaymentConsumer
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters
输出参数
o Continuation Status o (Payment Scheme) Packaged Content - for insertion in the Payment Scheme Component of the next IOTP message (Payment Exchange or Request Block).
o 继续状态o（支付方案）打包内容-用于插入下一条IOTP消息（支付交换或请求块）的支付方案组件中。
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response. However, the IOTP Payment Bridge might reject the resumption request by using the "AttNotSupp" Error Code "naming" the Consumer Payment Identifier attribute. Then the Consumer has to apply normal error processing to the current (sub-)transaction and to issue a new Payment Request Block to the Payment Handler.
IOTP应用程序核心可以在响应分析失败时多次重新发出此请求。但是，IOTP支付网桥可能会通过使用“AttNotSupp”错误代码“命名”消费者支付标识符属性来拒绝恢复请求。然后，消费者必须对当前（子）交易应用正常的错误处理，并向支付处理程序发出新的支付请求块。
XML definition:
XML定义：
<!ELEMENT ResumePaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT ResumePaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function resumes a payment at the Payment Handler side.
此API函数在付款处理程序端恢复付款。
Input Parameters
输入参数
o Payment Handler Payment Identifier o Wallet Identifier - renaming to till identifier neglected - and Pass Phrase
o 支付处理程序支付标识符o钱包标识符-重命名为直到忽略标识符-并传递短语
o Call Back Function - used for end user notification/logging purposes o Call Back Language List. This list is required if the Call Back Function is set o (Payment Scheme) Packaged Content - copied from the Payment Scheme Component of the received IOTP message (Payment Exchange or Request Block).
o 回调函数-用于最终用户通知/记录回调语言列表。如果回拨功能设置为（支付方案）打包内容，则需要此列表-从收到的IOTP消息（支付交换或请求块）的支付方案组件复制。
XML definition:
XML定义：
<!ELEMENT ResumePaymentPaymentHandler
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandler
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
<!ELEMENT ResumePaymentPaymentHandler
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandler
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters
输出参数
o Continuation Status o (Payment Scheme) Packaged Content - for insertion in the Payment Scheme Component of the next Payment Exchange Block.
o 连续状态o（支付方案）打包内容-用于插入下一个支付交换块的支付方案组件。
The response message contains payment schema specific data if the continuation status signals "Continue". The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
如果继续状态信号为“继续”，则响应消息包含特定于支付模式的数据。IOTP应用程序核心可以在响应分析失败时多次重新发出此请求。
XML definition:
XML定义：
<!ELEMENT ResumePaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT ResumePaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function passes one specific IOTP Payment Scheme Component, i.e., the encapsulated Packaged Content elements, received from the counter party (e.g., Consumer) to the IOTP Payment Bridge and responds with the next IOTP Payment Scheme Component for submission to the counter party.
此API函数将从对方（例如消费者）接收的一个特定IOTP支付方案组件（即封装的打包内容元素）传递给IOTP支付桥，并使用下一个IOTP支付方案组件进行响应，以提交给对方。
Input Parameters
输入参数
o Payty's Payment Identifier o Process (Transaction) Type which distinguishes between Payments and Inquiries. o Wallet Identifier and/or Pass Phrase o (Payment Scheme) Packaged Content - copied from the Payment Scheme Component of the received Payment Exchange Block or from the Error Block.
o Payty的付款标识符o处理（交易）类型，用于区分付款和查询。o钱包标识符和/或密码短语o（支付方案）打包内容-从收到的支付交换块的支付方案组件或错误块复制。
Each party should set the payment identifier with the local identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment Handler: PaymentHandlerPayId).
各方应使用本地标识符（消费者：ConsumerPayId；商户：MerchantPayId；支付处理人：PaymentHandlerPayId）设置支付标识符。
XML definition:
XML定义：
<!ELEMENT ContinueProcess (PaySchemePackagedContent+) >
<!ATTLIST ContinueProcess
PayId CDATA #REQUIRED
ProcessType (Payment | Inquiry) 'Payment'
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT ContinueProcess (PaySchemePackagedContent+) >
<!ATTLIST ContinueProcess
PayId CDATA #REQUIRED
ProcessType (Payment | Inquiry) 'Payment'
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Continuation Status o (Payment Scheme) Packaged Content - for insertion in the Payment Scheme Component of the next Payment Exchange Block or final Payment Response Block
o 连续状态o（付款方案）打包内容-用于插入下一个付款交换块或最终付款响应块的付款方案组件
The response message contains payment schema data if the continuation status signals "Continue". The IOTP Payment Bridge must signal "End", if the payment scheme data was received within an IOTP Error Block containing an Error Component with severity HardError.
如果继续状态信号为“继续”，则响应消息包含支付模式数据。如果在包含严重错误的错误组件的IOTP错误块内接收到支付方案数据，则IOTP支付桥必须发出“结束”信号。
XML definition:
XML定义：
<!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) >
<!ATTLIST ContinueProcessResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) >
<!ATTLIST ContinueProcessResponse
ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
The IOTP Application Core changes the current payment status by this request. The IOTP Payment Bridge may be notified about business level normal termination, cancellation, suspension, and processing errors. Notification happens by requesting the intended process state.
IOTP应用程序核心通过此请求更改当前付款状态。IOTP支付桥接器可能会收到关于业务级正常终止、取消、暂停和处理错误的通知。通知是通过请求预期的进程状态来实现的。
The IOTP Payment Bridge processes the status change and reports the result.
IOTP支付桥处理状态更改并报告结果。
The IOTP Application Core has to analyze any returned process status in order to check whether the IOTP Payment Bridge has agreed to or declined the status switch. E.g., the submitted Process State "CompleteOk" may lead to the Payment Status "Failed" if the payment transaction has already failed.
IOTP应用核心必须分析任何返回的流程状态，以检查IOTP支付桥是否同意或拒绝状态切换。例如，如果支付交易已经失败，提交的流程状态“CompleteOk”可能导致支付状态“Failed”。
Transaction Suspension is notified by the newly introduced Process State "Suspended". The other attribute values have been taken from the IOTP specification.
事务暂停由新引入的进程状态“Suspended”通知。其他属性值取自IOTP规范。
This API function might be called by the Consumer, Merchant, or Payment Handler for each payment transaction anytime after the issuance of "FindPaymentInstrument" to the IOTP Payment Bridge by the Consumer, the issuance of "FindAcceptedPaymentBrand" by the Merchant, or the issuance of "StartPaymentPaymentHandler" by the Payment Handler.
在消费者向IOTP支付桥发出“FindPaymentInstrument”、商户发出“FindAcceptedPaymentBrand”或支付处理程序发出“StartPaymentPaymentHandler”后的任何时间，消费者、商户或支付处理程序都可以为每一笔支付交易调用此API函数。
The Process States "CompletedOk", "Failed", and "ProcessError" are final in the sense that they can not be changed on subsequent calls. However, the API function should not return with an error code if such an incompatible call has been issued. Instead it should report the old unchanged Process State.
流程状态“CompletedOk”、“Failed”和“ProcessError”是最终状态，因为它们不能在后续调用中更改。但是，如果发出了此类不兼容的调用，则API函数不应返回错误代码。相反，它应该报告旧的未更改进程状态。
Unknown payment transactions are reported by the Error Code "AttValInvalid" pointing to the PayId attribute.
指向PayId属性的错误代码“AttValInvalid”报告未知支付交易。
Input Parameters
输入参数
o Party's Payment Identifier o intended Payment Status o intended Completion Code o Process (Transaction) Type which distinguishes between Payments and Inquiries. o Wallet Identifier and/or Pass Phrase
o 一方的付款标识符o预期付款状态o预期完成代码o区分付款和查询的流程（交易）类型。o钱包标识符和/或密码短语
XML definition:
XML定义：
<!ELEMENT ChangeProcessState EMPTY > <!ATTLIST ChangeProcessState PayId CDATA #REQUIRED ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED ProcessType (Payment | Inquiry) 'Payment' WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<!元素ChangeProcessState为空><！ATTLIST ChangeProcessState PayId CDATA#必需的进程状态（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError | REQUIRED CompletionCode NMTOKEN#隐含的进程类型（支付|查询）"支付| WalletID CDATA#隐含的密码CDATA#隐含的>
Output Parameters
输出参数
o Process State and Percent Complete o Completion Code o Status Description and its language annotation
o 进程状态和完成百分比o完成代码o状态描述及其语言注释
XML definition:
XML定义：
<!ELEMENT ChangeProcessStateResponse EMPTY > <!ATTLIST ChangeProcessStateResponse ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED PercentComplete CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED >
<!元素ChangeProcessStateResponse为空><！ATTLIST ChangeProcessStateResponse ProcessState（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError）#所需完成百分比CDATA#隐含完成代码NMTOKEN#隐含xml:lang NMTOKEN#隐含状态描述CDATA#隐含>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
The following calls are not necessarily assigned to a payment transaction and may be issued at any time. There are no dependencies on any other calls.
以下呼叫不一定分配给支付交易，可以随时发出。不依赖于任何其他调用。
The IOTP Application Core notifies the IOTP Payment Bridge and/or the corresponding Existing Payment Software via IOTP Payment Bridge that any record in the Payment Log file, that deals with the listed payment transaction, might be removed.
IOTP应用程序核心通过IOTP支付桥通知IOTP支付桥和/或相应的现有支付软件，支付日志文件中处理列出的支付交易的任何记录都可能被删除。
Input Parameters
输入参数
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase
o 一方的支付标识符o钱包标识符和/或通行短语
XML definition:
XML定义：
<!ELEMENT RemovePaymentLog EMPTY >
<!ATTLIST RemovePaymentLog
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT RemovePaymentLog EMPTY >
<!ATTLIST RemovePaymentLog
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
XML definition:
XML定义：
<!ELEMENT RemovePaymentLogResponse EMPTY >
<!ATTLIST RemovePaymentLogResponse >
<!ELEMENT RemovePaymentLogResponse EMPTY >
<!ATTLIST RemovePaymentLogResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function retrieves the properties of the Payment Instrument. The Payment Instrument Identifier could be omitted if this identifier is derived by other means, e.g., by analysis of the currently inserted chip card. If the Payment instrument could not uniquely determined, the IOTP Payment Bridge may provide suitable dialogs for user input.
此API函数检索支付工具的属性。如果通过其他方式（例如，通过分析当前插入的芯片卡）导出支付工具标识符，则可以省略该标识符。如果无法唯一确定支付工具，IOTP支付桥可为用户输入提供合适的对话框。
E.g., this API function might be used during problem resolution with the Customer Care Provider of the issuer of the payment instrument, in order to inquire payment instrument specific values.
例如，在与支付工具发行人的客户服务提供商解决问题期间，可以使用此API函数来查询支付工具的特定值。
Input parameters
输入参数
o Brand Identifier o Payment Instrument Identifier o Protocol Identifier
o 品牌标识符o支付工具标识符o协议标识符
o Wallet Identifier and/or Pass Phrase o Property Type List - sequence of values whose language is identified by xml:lang o (Brand) PackagedContent Content - further payment brand description o Protocol Brand Content - further payment brand information o (Protocol Amount) PackagedContent Content - further payment protocol description o (Pay Protocol) PackagedContent Content - further payment protocol description
o 钱包标识符和/或通行短语o财产类型列表-由xml标识语言的值序列：lang o（品牌）PackagedContent内容-进一步支付品牌说明o协议品牌内容-进一步支付品牌信息o（协议金额）PackagedContent内容-进一步支付协议说明o（支付协议）PackagedContent内容-进一步的支付协议说明
The codes in the property type list are of two types:
“特性类型”列表中的代码有两种类型：
o generic codes which apply to all payment methods but might be unavailable o Payment Brand specific codes.
o 适用于所有支付方式但可能不适用于支付品牌特定代码的通用代码。
Generic codes for the Property Type List are:
特性类型列表的通用代码为：
Property Type Meaning Balance Current balance Limit Maximum balance PaymentLimit Maximum payment transaction limit Expiration Expiration date Identifier Issuer assigned identifier of the payment instrument. Usually, it does not match with the API's payment instrument identifier. LogEntries Number of stored payment transaction entries. The entries are numbered from 0 (the most recent) to some non-negative value for the oldest entry. PayAmountn Payment Amount of the n-th recorded payment transaction, n may negative PayPartyn Remote party of the n-th payment recorded transaction, n may negative PayTimen Time of the n-th payment recorded transaction, n may negative
属性类型表示余额当前余额限额最大余额付款限额最大付款交易限额到期日期标识符发卡行分配的支付工具标识符。通常，它与API的支付工具标识符不匹配。日志条目存储的支付交易条目的数量。条目编号从0（最近的）到最早条目的某个非负值。PayAmountn第n笔记录的付款交易的付款金额，n可能为负PayParty第n笔记录的付款交易的远程方，n可能为负PayTimen第n笔记录的付款交易的时间，n可能为负
XML definition:
XML定义：
<!ELEMENT PaymentInstrumentInquiry (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*) >
<!ATTLIST PaymentInstrumentInquiry
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
ProtocolId CDATA #REQUIRED
<!ELEMENT PaymentInstrumentInquiry (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*) >
<!ATTLIST PaymentInstrumentInquiry
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
ProtocolId CDATA #REQUIRED
PropertyTypeList NMTOKENS #REQUIRED
xml:lang NMTOKEN #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
PropertyTypeList NMTOKENS #REQUIRED
xml:lang NMTOKEN #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output parameters
输出参数
o a list of zero or more unavailable property values whose language are identified by xml:lang. o a list of zero or more sets of "Properties Types", "Property Values" and "Property Descriptions"
o 零个或多个不可用属性值的列表，其语言由xml:lang标识。o零个或多个“属性类型”、“属性值”和“属性描述”集合的列表
XML definition:
XML定义：
<!ELEMENT PaymentInstrumentInquiryResponse
(PaymentInstrumentProperty*) >
<!ATTLIST PaymentInstrumentInquiryResponse
xml:lang NMTOKEN #REQUIRED
UnavailablePropertyList NMTOKENS #IMPLIED >
<!ELEMENT PaymentInstrumentProperty EMPTY >
<!ATTLIST PaymentInstrumentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
<!ELEMENT PaymentInstrumentInquiryResponse
(PaymentInstrumentProperty*) >
<!ATTLIST PaymentInstrumentInquiryResponse
xml:lang NMTOKEN #REQUIRED
UnavailablePropertyList NMTOKENS #IMPLIED >
<!ELEMENT PaymentInstrumentProperty EMPTY >
<!ATTLIST PaymentInstrumentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function reports the party's payment identifiers of any pending payment transactions that the IOTP Payment Bridge/Existing Payment Software recommends be completed or suspended prior to the processing of new payment transactions. It does not respond with further transaction details. These have to be requested with "Inquire Process State".
此API功能报告IOTP支付桥/现有支付软件建议在处理新支付交易之前完成或暂停的任何未决支付交易的当事方支付标识符。它不会回复进一步的交易细节。必须使用“查询进程状态”请求这些。
Note that the IOTP Payment Bridge has to respond without the benefit of any pass phrase if there exist no pending payment transaction. But if there are some pending payment transactions, the IOTP Payment Bridge may refuse the immediate response and may instead request the appropriate pass phase from the IOTP Application Core.
请注意，如果不存在未决支付交易，IOTP支付桥必须在没有任何通行短语的情况下响应。但是，如果存在一些未决的支付交易，IOTP支付桥可能会拒绝立即响应，而可能会从IOTP应用核心请求适当的通过阶段。
Input Parameters
输入参数
o Wallet Identifier and/or Passphrase
o 钱包标识符和/或密码短语
XML definition:
XML定义：
<!ELEMENT InquirePendingPayment EMPTY >
<!ATTLIST InquirePendingPayment
WalletId CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT InquirePendingPayment EMPTY >
<!ATTLIST InquirePendingPayment
WalletId CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Party's Payment Identifier
o 一方的支付标识符
XML definition:
XML定义：
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<!ELEMENT PaymentId EMPTY >
<!ATTLIST PaymentId
PayId CDATA #REQUIRED >
<!ELEMENT PaymentId EMPTY >
<!ATTLIST PaymentId
PayId CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This function is used by the Consumer and might be used by the Payment Handler to check the consistency, validity, and integrity of IOTP payment receipts which might consist of Packaged Content Elements
消费者使用此功能，支付处理程序可能使用此功能检查IOTP付款收据的一致性、有效性和完整性，这些付款收据可能由打包的内容元素组成
o from the IOTP Payment Receipt Component - provided by the Payment Handler's "Inquire Process State" API call shortly before payment completion,
o 从IOTP付款收据组件-在付款完成前不久由付款处理程序的“查询流程状态”API调用提供，
o from Payment Scheme Components being exchanged during the actual payment, or
o 在实际支付期间交换的支付方案组件，或
o being returned by the Consumer's "Inquire Process State" API call shortly before payment completion
o 在支付完成前不久，由消费者的“Inquire Process State”API调用返回
The IOTP Application Core has to check the PayReceiptNameRefs attribute of the IOTP Payment Receipt Component and to supply exactly the Packaged Content Elements being referred to.
IOTP应用程序核心必须检查IOTP付款收据组件的PayReceiptNameRefs属性，并准确提供所引用的打包内容元素。
Failed verification is returns a business error.
验证失败将返回一个业务错误。
Note that this Payment API assumes that any payment receipt builds upon a subset of elements with reference to [IOTP]. Furthermore, the Packaged Content Element have to be distinguishable by their Name attribute.
请注意，此支付API假定任何支付收据都是基于参考[IOTP]的元素子集生成的。此外，打包的内容元素必须通过其名称属性来区分。
Input Parameters
输入参数
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase o All Packaged Content Elements in the payment receipt
o 一方的支付标识符o钱包标识符和/或通行短语o付款收据中的所有打包内容元素
XML definition:
XML定义：
<!ELEMENT CheckPaymentReceipt (PackagedContent*) >
<!ATTLIST CheckPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT CheckPaymentReceipt (PackagedContent*) >
<!ATTLIST CheckPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
XML definition:
XML定义：
<!ELEMENT CheckPaymentReceiptResponse EMPTY >
<!ATTLIST CheckPaymentReceiptResponse >
<!ELEMENT CheckPaymentReceiptResponse EMPTY >
<!ATTLIST CheckPaymentReceiptResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function expands any IOTP payment receipt into a form which may be used for display or printing purposes. "Check Payment Receipt" should be used first if there is any question of the payment receipt containing errors.
此API函数将任何IOTP付款收据扩展为可用于显示或打印目的的表单。若付款收据有任何错误，应首先使用“检查付款收据”。
The same conventions apply to the input parameter as for "Check Payment Receipt" (cf. Section 4.5.1).
与“支票付款收据”（参见第4.5.1节）相同的约定适用于输入参数。
Input Parameters
输入参数
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase o All Packaged Content Elements that build the payment receipt
o 当事方的支付标识符o钱包标识符和/或密码o构建支付收据的所有打包内容元素
XML definition:
XML定义：
<!ELEMENT ExpandPaymentReceipt (PackagedContent*) >
<!ATTLIST ExpandPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT ExpandPaymentReceipt (PackagedContent*) >
<!ATTLIST ExpandPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Brand Identifier o Protocol specific Brand Identifier o Payment Instrument Identifier o Currency Code and Currency Code Type o Payment Amount o Payment Direction o Time Stamp - issuance of the receipt o Protocol Identifier o Protocol specific Transaction Identifier - this is an internal reference number which identifies the payment o Consumer Description, Payment Handler Description, and a language annotation o Style Sheet Net Location o Payment Property List. A list of type/value/description triples which contains additional information about the payment which is not covered by any of the other output parameters; property descriptions have to consider the language annotation.
o 品牌标识符o协议特定品牌标识符o支付工具标识符o货币代码和货币代码类型o支付金额o支付方向o时间戳-收据的签发o协议标识符o协议特定交易标识符-这是一个内部参考号，用于识别支付o消费者说明、付款处理程序说明和语言注释o样式表净位置o付款属性列表。类型/值/描述三元组列表，其中包含任何其他输出参数未涵盖的有关付款的附加信息；属性描述必须考虑语言注释。
The Style Sheet Net Location refers to a Style Sheet (e.g., [XSLT]) that contains presentation information about the reported XML encoded data.
样式表净位置指的是一个样式表（例如，[XSLT]），其中包含有关报告的XML编码数据的表示信息。
XML definition:
XML定义：
<!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) >
<!ATTLIST ExpandPaymentReceiptResponse
BrandId CDATA #IMPLIED
PaymentInstrumentId CDATA #IMPLIED
Amount CDATA #IMPLIED
CurrCodeType NMTOKEN #IMPLIED
CurrCode CDATA #IMPLIED
PayDirection (Debit|Credit) #IMPLIED
TimeStamp CDATA #IMPLIED
ProtocolId CDATA #IMPLIED
ProtocolBrandId CDATA #IMPLIED
ProtocolTransId CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
ConsumerDesc CDATA #IMPLIED
<!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) >
<!ATTLIST ExpandPaymentReceiptResponse
BrandId CDATA #IMPLIED
PaymentInstrumentId CDATA #IMPLIED
Amount CDATA #IMPLIED
CurrCodeType NMTOKEN #IMPLIED
CurrCode CDATA #IMPLIED
PayDirection (Debit|Credit) #IMPLIED
TimeStamp CDATA #IMPLIED
ProtocolId CDATA #IMPLIED
ProtocolBrandId CDATA #IMPLIED
ProtocolTransId CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
ConsumerDesc CDATA #IMPLIED
PaymentHandlerDesc CDATA #IMPLIED StyleSheetNetLocn CDATA #IMPLIED>
PaymentHandlerDesc CDATA#隐含样式表Netlocn CDATA#隐含>
<!ELEMENT PaymentProperty EMPTY >
<!ATTLIST PaymentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
<!ELEMENT PaymentProperty EMPTY >
<!ATTLIST PaymentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
The Existing Payment Software should return as many attributes as possible from the supplied IOTP Payment Receipt. The payment supplement defines the attribute values for the payment properties.
现有支付软件应从提供的IOTP付款收据中返回尽可能多的属性。付款补充定义了付款属性的属性值。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function returns the current payment state and optionally further Packaged Content Elements that form the payment receipt. Called by the Payment Handler, the IOTP Payment Bridge might respond with data intended for inclusion in the IOTP Payment Receipt Component's Packaged Content. When the Consumer calls this function shortly before payment completion, it may respond with further items of the payment receipt. Such items might be created by a chip card.
此API函数返回当前付款状态，并可选地返回构成付款收据的进一步打包的内容元素。由支付处理程序调用，IOTP支付桥接器可能会使用打算包含在IOTP支付收据组件打包内容中的数据进行响应。当消费者在付款完成前不久调用此功能时，它可能会以付款收据的其他项目进行响应。这些项目可能由芯片卡创建。
Input Parameters
输入参数
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase
o 一方的支付标识符o钱包标识符和/或通行短语
XML definition:
XML定义：
<!ELEMENT InquireProcessState EMPTY >
<!ATTLIST InquireProcessState
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT InquireProcessState EMPTY >
<!ATTLIST InquireProcessState
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Current Process State and Percent Complete o Completion Code o Status Description and its language annotation o Payment Receipt Name References to all Packaged Content Elements that build the payment receipt (cf. Section 4.5.1), even if they have not been created so far (Consumer's share)
o 当前流程状态和完成百分比o完成代码o状态描述及其语言注释o付款收据名称引用所有生成付款收据的打包内容元素（参见第4.5.1节），即使它们尚未创建（消费者共享）
o Any Packaged Content Element being available that form the payment receipt
o 构成付款收据的任何打包内容元素
The IOTP provides a linking capability to the payment receipt delivery. Instead of encapsulating the whole payment specific data into the packaged content of the payment receipt, other Payment Scheme Components' Packaged Content might be referred to.
IOTP提供了与付款收据交付的链接功能。可以引用其他支付方案组件的打包内容，而不是将整个特定于支付的数据封装到支付收据的打包内容中。
XML definition:
XML定义：
<!ELEMENT InquireProcessStateResponse (PackagedContent*) > <!ATTLIST InquireProcessStateResponse ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED PercentComplete CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED PayReceiptNameRefs NMTOKENS #IMPLIED >
<!元素查询ProcessStateResponse（PackagedContent*）><！ATTLIST InquiredProcessStateResponse ProcessState（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError）#所需完成百分比CDATA#隐含完成代码NMTOKEN#隐含xml:lang NMTOKEN#隐含状态描述CDATA#隐含工资收据名称参考NMTOKEN#隐含>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function responds with any additional payment scheme specific data that is needed by the Payment Handler for Consumer initiated payment transaction inquiry processing. Probably, the IOTP Payment Bridge (or the corresponding Existing Payment Software) has to determine the payment related items that were provided with the "Start Payment Consumer" API function call.
此API函数使用支付处理程序为消费者发起的支付交易查询处理所需的任何其他特定于支付方案的数据进行响应。IOTP支付桥接器（或相应的现有支付软件）可能必须确定“启动支付消费者”API函数调用提供的支付相关项目。
Input Parameters
输入参数
o Consumer Payment Identifier o Wallet Identifier and/or Pass Phrase
o 消费者支付标识符o钱包标识符和/或密码短语
XML definition:
XML定义：
<!ELEMENT StartPaymentInquiry EMPTY >
<!ATTLIST StartPaymentInquiry
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT StartPaymentInquiry EMPTY >
<!ATTLIST StartPaymentInquiry
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o (Payment Scheme) Packaged Content - intended for insertion in the Payment Scheme Component of the Inquiry Request Block
o （支付方案）打包内容-用于插入查询请求块的支付方案组件中
XML definition:
XML定义：
<!ELEMENT StartPaymentInquiryResponse
(PaySchemePackagedContent*) >
<!ELEMENT StartPaymentInquiryResponse
(PaySchemePackagedContent*) >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
The Payment Handler calls this API function for Consumer initiated inquiry processing. It differs from the previous "Inquire Process State" API function by the optional inclusion of payment scheme specific data. The response may encapsulate further details about the payment transaction.
支付处理程序调用此API函数进行消费者发起的查询处理。它与以前的“查询流程状态”API函数的不同之处在于可选地包含特定于支付方案的数据。响应可能包含有关支付交易的更多详细信息。
Input Parameters
输入参数
o Payment Handler Payment Identifier o Wallet Identifier and/or Pass Phrase o (Payment Scheme) Packaged Content - copied from the Inquiry Request Block's Payment Scheme Component
o 支付处理程序支付标识符o钱包标识符和/或密码短语o（支付方案）打包内容-从查询请求块的支付方案组件复制
XML definition:
XML定义：
<!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) >
<!ATTLIST InquirePaymentStatus
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) >
<!ATTLIST InquirePaymentStatus
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o Current Process State o Completion Code
o 当前进程状态o完成代码
o Status Description and its language annotation o (Payment Scheme) Packaged Content - intended for insertion in the Payment Scheme Component of the Inquiry Response Block
o 状态描述及其语言注释o（支付方案）打包内容-用于插入查询响应块的支付方案组件
XML definition:
XML定义：
<!ELEMENT InquirePaymentStatusResponse (PaySchemePackagedContent*) > <!ATTLIST InquirePaymentStatusResponse PaymentHandlerPayId CDATA #REQUIRED ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED >
<!元素查询PaymentStatusResponse（PaySchemePackagedContent*）><！ATTLIST查询PaymentStatusResponse PaymentHandlerPayId CDATA#必需的进程状态（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError | REQUIRED CompletionCode NMTOKEN#隐含xml:lang NMTOKEN#隐含状态描述CDATA#隐含>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
The following API function notifies the IOTP Payment Bridge about the intended registration, modification, or deletion of a payment instrument. The actual processing is up to the IOTP Payment Bridge.
以下API函数通知IOTP支付桥有关支付工具的预定注册、修改或删除。实际处理取决于IOTP支付桥。
This API request may also be used to activate the IOTP Payment Bridge (and the corresponding Existing Payment Software) for general administration purposes.
该API请求还可用于激活IOTP支付桥（以及相应的现有支付软件），以实现一般管理目的。
Input Parameters
输入参数
o Brand Identifier o Protocol Identifier o Any action code: o New - add new payment method / instrument o Update - change the payment method's / instrument's data o Delete - delete a payment method / instrument o Wallet Identifier and/or Pass Phrase o (Brand) Packaged Content - further payment brand description o (Pay Protocol) Packaged Content - further payment protocol description
o 品牌标识符o协议标识符o任何操作代码：o新-添加新的支付方式/工具o更新-更改支付方式/工具的数据o删除-删除支付方式/工具o钱包标识符和/或密码o（品牌）打包内容-进一步的支付品牌说明o（支付协议）打包内容-进一步的支付协议说明
o (Protocol Amount) Packaged Content - further payment protocol description
o （协议金额）打包内容-进一步的支付协议说明
If the Action attribute is set, the Brand and Protocol Identifier have to also be set. The IOTP Payment Bridge has to provide the required user dialogs and selection mechanisms. E.g., updates and deletions may require the selection of the payment instrument. A new wallet might be silently generated on the supplement of a new Wallet Identifier or after an additional end user acknowledge. The IOTP Application Core should not provide any pass phrases for new wallets. Instead, the IOTP Payment Bridge has to request and verify them, which may return their value to the IOTP Application Core in plain text. In addition, the IOTP Payment Bridge returns the supported authentication algorithms when a new brand and protocol pair has been registered.
如果设置了Action属性，则还必须设置品牌和协议标识符。IOTP支付桥必须提供所需的用户对话框和选择机制。例如，更新和删除可能需要选择支付工具。新钱包可能在补充新钱包标识符时或在附加最终用户确认后以静默方式生成。IOTP应用核心不应为新钱包提供任何通行短语。相反，IOTP支付桥必须请求并验证它们，这可能会以明文形式将它们的值返回给IOTP应用程序核心。此外，当注册了新品牌和协议对时，IOTP支付网桥将返回支持的认证算法。
If the "Action" attribute is omitted, the IOTP Payment Bridge which is responsible for the Existing Payment Software pops up in a general interactive mode.
如果省略“Action”属性，则负责现有支付软件的IOTP支付桥将以通用交互模式弹出。
XML definition:
XML定义：
<!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*) >
<!ATTLIST ManagePaymentSoftware
BrandId CDATA #IMPLIED
ProtocolId CDATA #IMPLIED
Action (New |
Update |
Delete) #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*) >
<!ATTLIST ManagePaymentSoftware
BrandId CDATA #IMPLIED
ProtocolId CDATA #IMPLIED
Action (New |
Update |
Delete) #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
Output Parameters
输出参数
o An action code: o New - added new wallet o Update - changed wallet's configuration o Delete - removed a wallet o Wallet Identifier and/or Pass Phrase
o 操作代码：o新建-添加新钱包o更新-更改钱包配置o删除-删除钱包o钱包标识符和/或密码
The IOTP Payment Bridge does not return any information about the set of registered payment instruments because these data items are dynamically inferred during the brand selection process at the beginning of each IOTP transaction. However, the IOTP Application Core has to be notified about new wallets and should be notified about updated and removed wallets (identifier). Alternatively,
IOTP支付桥不会返回任何有关已注册支付工具集的信息，因为这些数据项是在每个IOTP交易开始时的品牌选择过程中动态推断的。但是，必须通知IOTP应用程序核心有关新钱包的信息，并应通知更新和删除的钱包（标识符）。或者，
removed wallets can be implicitly detected during the next brand selection phase. Updated wallets do no affect the processing of the IOTP Application Core. The IOTP Payment Bridge should only support the addition of at most one wallet because it is not able to report multiple additions at once back to the IOTP Application Core.
在下一个品牌选择阶段，可以隐式检测到移除的钱包。更新的钱包不会影响IOTP应用程序核心的处理。IOTP支付网桥应仅支持最多添加一个钱包，因为它无法一次向IOTP应用程序核心报告多个添加。
XML definition:
XML定义：
<!ELEMENT ManagePaymentSoftwareResponse EMPTY >
<!ATTLIST ManagePaymentSoftwareResponse
Action (New |
Update |
Delete) #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
AuthNames NMTOKENS #REQUIRED >
<!ELEMENT ManagePaymentSoftwareResponse EMPTY >
<!ATTLIST ManagePaymentSoftwareResponse
Action (New |
Update |
Delete) #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
AuthNames NMTOKENS #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
This API function, called by the IOTP Payment Bridge, is used to provide information for Consumer or Payment Handler notification about the progress of the payment transaction.
此API函数由IOTP支付桥调用，用于向消费者或支付处理程序提供有关支付交易进度的通知信息。
Its use is illustrated in the diagram below.
下图说明了它的用途。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP Application ----calls----
| Core | |
display | | v
to <---------- Call Back <--calls--- Payment
user | | Software
----------------
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP Application ----calls----
| Core | |
display | | v
to <---------- Call Back <--calls--- Payment
user | | Software
----------------
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 9. Call Back Function
图9。回拨功能
Whenever this function is called, the content of the status description should be made available to the user. For example on a status bar, a pop up window, etc.
无论何时调用此函数，都应向用户提供状态描述的内容。例如，在状态栏、弹出窗口等上。
A reference to the Call Back function is passed as an input parameter to the "Start Payment X" and "Resume Payment X" API function. Afterwards, this function might be called whenever the status changes or progress needs to be reported.
回调函数的引用作为输入参数传递给“开始付款X”和“恢复付款X”API函数。之后，只要状态更改或需要报告进度，就可以调用此函数。
Input Parameters
输入参数
o the software identifier of the caller o Party's Payment Identifier o Process State and Percent Complete o Completion Code o Status Description and its language annotation, text which provides information about the progress of the call. It should be displayed or made available to, for example, the Consumer.
o 呼叫方的支付标识符o进程状态和完成百分比o完成代码o状态描述及其语言注释的软件标识符o提供呼叫进度信息的文本。例如，应将其显示或提供给消费者。
Examples of Status Description could be:
状态描述的示例可以是：
o "Paying 12.30 USD to XYZ Inc" o "Payment completed" o "Payment aborted"
o 向XYZ公司支付12.30美元“o”付款已完成“o”付款中止
The valid languages are announced in the Call Back Language List attribute in "Start Payment X" and "Resume Payment X" API function calls.
有效语言在“开始付款X”和“恢复付款X”API函数调用中的回调语言列表属性中宣布。
XML definition:
XML定义：
<!ELEMENT CallBack EMPTY > <!ATTLIST CallBack ContentSoftwareID CDATA #IMPLIED PayId CDATA #REQUIRED ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #IMPLIED PercentComplete CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED >
<!元素回调空><！ATTLIST回调ContentSoftwareID CDATA#隐含的PayId CDATA#必需的进程状态（NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError）#隐含的完成百分比CDATA#隐含的完成代码NMTOKEN#隐含的xml:lang NMTOKEN#隐含的状态描述CDATA#隐含的>
Output Parameters
输出参数
XML definition:
XML定义：
<!ELEMENT CallBackResponse EMPTY >
<!ATTLIST CallBackResponse <!-- see below --> >
<!ELEMENT CallBackResponse EMPTY >
<!ATTLIST CallBackResponse <!-- see below --> >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4和表5解释了属性和要素；表3介绍了错误代码。
Basically, the call back function accepts all input arguments or rejects the whole request. It may even accept malformed requests.
基本上，回调函数接受所有输入参数或拒绝整个请求。它甚至可以接受格式错误的请求。
Some payment schemes may support or require that the Consumer might be able to cancel the payment at any time. The Call Back function can be used to facilitate this by returning the cancellation request on the next call (using the Business Error Code and Completion Code "ConsCancelled").
一些支付方案可能支持或要求消费者可以随时取消支付。回拨功能可通过在下次通话时返回取消请求（使用业务错误代码和完成代码“ConsCancelled”）来促进这一点。
Vice versa the Payment Handler's Application Core might use the similar mechanism to signal its IOTP Payment Bridges any exceptional need for a fast shutdown. These IOTP Payment Bridges may initiate the appropriate steps for terminating/cancelling all pending payment transactions.
反之亦然，支付处理程序的应用程序核心可能会使用类似的机制向其IOTP支付桥发出快速关闭的任何异常需要的信号。这些IOTP支付桥可启动适当步骤，终止/取消所有未决支付交易。
Note that the "Change Process State" API function provides the second mechanism for such kind of notification. Therefore, the IOTP Payment Bridge or Existing Payment Software may ignore the details of the "Call Back" response.
请注意，“更改流程状态”API函数为此类通知提供了第二种机制。因此，IOTP支付桥或现有支付软件可能会忽略“回拨”响应的细节。
The IOTP Payment APIs only supports security using pass phrase to access to payment Wallet. These can be protected over TLS, which provides stronger security at the transport layer, but implementations are out the scope of this document.
IOTP支付API仅支持使用密码短语访问支付钱包的安全性。这些可以通过TLS进行保护，TLS在传输层提供了更强的安全性，但实现超出了本文的范围。
See also security consideration section of [IOTP].
另请参见[IOTP]的安全考虑部分。
[IOTP] Burdett, D., "Internet Open Trading Protocol - IOTP version 1.0", RFC 2801, April 2000.
[IOTP]Burdett，D.，“互联网开放交易协议-IOTP版本1.0”，RFC2801，2000年4月。
[ISO4217] ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.
[ISO4217]ISO 4217：表示货币的代码。可从ANSI或ISO获得。
[URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[URL]Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[UTC] Universal Time Coordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601.
[UTC]协调世界时。一种相对于格林威治标准时间（GMT）绝对确定时间的方法。通常的形式为：“CCYY-MM-DDTHH:MM:SS.sssZ+n”，其中“+n”定义了从GMT开始的小时数。参见ISO DIS8601。
[XML] Extensible Mark Up Language (XML) 1.0 (Third Edition). A
W3C recommendation. See http://www.w3.org/TR/REC-xml
[XML] Extensible Mark Up Language (XML) 1.0 (Third Edition). A
W3C recommendation. See http://www.w3.org/TR/REC-xml
[XML-NS] Namespaces in XML Recommendation. T. Bray, D. Hollander,
A. Layman. Janaury 1999. http://www.w3.org/TR/REC-xml-
names
[XML-NS] Namespaces in XML Recommendation. T. Bray, D. Hollander,
A. Layman. Janaury 1999. http://www.w3.org/TR/REC-xml-
names
[XSLT] Extensible Style Language Transformations 1.0, November
1999, See http://www.w3.org/TR/xslt
[XSLT] Extensible Style Language Transformations 1.0, November
1999, See http://www.w3.org/TR/xslt
[IOTPBOOK] D. Burdett, D.E. Eastlake III, and M. Goncalves, Internet Open Trading Protocol, McGraw-Hill, 2000. ISBN 0-07- 135501-4.
[IOTPBOOK]D.Burdett，D.E.Eastlake III和M.Goncalves，互联网开放交易协议，McGraw-Hill，2000年。ISBN 0-07-135501-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/IOTP] Kawatsura, Y., "Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 3538, June 2003.
[SET/IOTP]Kawatsura，Y.，“v1.0互联网开放交易协议（IOTP）的安全电子交易（SET）补充”，RFC 3538，2003年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
Acknowledgement
确认
The contributions of Werner Hans of Atos Origin are gratefully acknowledged.
感谢来自Atos的沃纳·汉斯的贡献。
Authors' Addresses
作者地址
Hans-Bernhard Beykirch
汉斯·伯恩哈德·贝基奇
EMail: hbbeykirch@web.de
EMail: hbbeykirch@web.de
Yoshiaki Kawatsura Hitachi, Ltd. 890 Kashimada Saiwai-ku Kawasaki-shi Kanagawa, Japan 212-8567
日本Kashimada Saiwai ku Kawasaki shi Kanagawa Kawaki Kawatsura Hitachi有限公司890号，邮编212-8567
EMail: ykawatsu@itg.hitachi.co.jp
EMail: ykawatsu@itg.hitachi.co.jp
Masaaki Hiroya Technoinfo Service, Inc. 333-2-718 Uchikoshi-machi Hachioji-shi Tokyo 192-0911 JAPAN
Masaaki Hiroya技术信息服务公司333-2-718 Uchikoshi machi Hachioji shi东京192-0911日本
EMail: hiroya@st.rim.or.jp
EMail: hiroya@st.rim.or.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。