[要約] RFC 3867は、IOTPのv1.0インターネットオープン取引プロトコル（IOTP）のための支払いアプリケーションプログラマーインターフェース（API）に関する要約です。このRFCの目的は、IOTPを使用して支払い処理を行うためのAPI仕様を提供することです。
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)
V1.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）The Internet Society（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
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]および[IOTPBook]を参照してください。
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アプリケーションは、複数の支払い方法のサポートを目指しています。消費者は、ほぼ同一の動作とユーザーインターフェイスを備えた1つの取引アプリケーション内のさまざまなシームレスな統合支払い方法の柔軟な使用を好みます。明確に定義されたインターフェイスの存在により、支払いソフトウェア開発者は、コンポーネントを他の開発者の一般的なIOTPアプリケーションコアにボルトで固定できます。
Initially, this consideration leads to the two-level layered view of the IOTP software for each role, consisting of:
当初、この考慮事項は、次の役割のIOTPソフトウェアの2レベルの層状ビューにつながります。
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取引アプリケーションは3層化されています。
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支払いブリッジは、他の2つのおそらく互換性のないコンポーネントを接着します。既存のレガシーシステムの特定のインターフェイスと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やGeldkarteなどのチップカード、および（3）典型的な模倣および（3）送金、口座振替、預金、引き出し、金銭交換、価値ポイントなどの従来の支払い方法。明示的な消費者承認と自動繰り返しの支払いで両方の支払いをサポートする必要があります。セットの詳細については、[セット]を参照してください。
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.
次の2つのサブセクションでは、一般的な支払いシナリオと、粗くスケッチされたソフトウェアコンポーネントに関するいくつかの仮定について説明します。
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.
次の表には、多くの支払いスキームの4つの論理的手順をスケッチします。商品、支払い方法、購入金額、または配達規則に関する前の契約は省略されています。
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
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認証とキャプチャを区別しないでください。限られたバリアント。
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が支払い終了を信号するまで、2つの当事者間で継続します。例外的には、各システムコンポーネントが障害を信号する場合があります。
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-T-M-Mannerで互いに関連している可能性があります。
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 1つのIOTPアプリケーションコアは、複数のIOTP支払いブリッジを管理する場合があり、後者は複数のIOTPアプリケーションコア間で共有される場合があります。o各支払いブリッジは、複数の既存の支払いソフトウェアモジュールを管理する場合があり、後者は複数の支払いブリッジ間で共有される場合があります。o既存の各支払いソフトウェアは、複数の支払いスキーム（セットなど）を管理する場合があり、後者は複数の既存の支払いソフトウェアモジュールによってサポートされる場合があります。セットの詳細については、[セット]を参照してください。
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 各支払いスキームは、複数の支払い手段（特定のカードなど）または方法（セット経由のビザなど）をサポートし、後者は複数の既存の支払いソフトウェアコンポーネントで共有される場合があります。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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]および[IOTPBook]を参照してください。
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トランザクション処理の一般的なおよび支払いスキームの独立部分を実装し、適切なユーザーインターフェイスを提供します。支払い関連のタスクに焦点を当てています
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支払いブリッジはパッシブコンポーネントであると仮定します。つまり、入力データを厳密に待ち望んでいて、各リクエストに対する1つの応答を生成します。
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 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.
o 各支払いトランザクションを複数の支払いパラメーター（IOTPトランザクション識別子、取引プロトコルオプション、支払い手段/メソッド、応答、IOTP支払いブリッジ、および財布識別子、関連するリモートパーティ）で関連付けます。関係は、実際の支払いトランザクションが正常に開始されたときに、当事者の支払い識別子、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 既存の支払いソフトウェアのインタラクティブモードの呼び出しをサポートします。これは、支払いスキームに使用される可能性があります。）新しい支払い手段/スキームの登録、または（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 Protocolおよび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 Payment Bridgeの機能は、消費者と支払いハンドラーの間の実際の支払いを扱うだけでなく、次のものに拡張します。
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 支払い取引の一時停止と再開。既存の支払いソフトウェアが扱う可能性のある2種類の失敗は、（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 Inquirer -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).
既存の支払いソフトウェアは、これらの機能の完全なサポートを提供しない場合があります。たとえば、一部の支払いスキームは、支払いプロセスのarbitrary意的なフェーズでの明示的なトランザクションキャンセルをサポートしていない、または防止する場合があります。この場合、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.
「Find Compated Payned Payment Protocol」は、指定された通貨額（およびブランド）に対して受け入れられている支払いプロトコルを識別し、ブランド選択目的で支払いスキーム固有のパッケージコンテンツを返します。
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.
「Get Payment Intialization Data」は、支払いハンドラーによる支払い処理のために追加の支払いスキーム固有のパッケージ化されたコンテンツを返します。
"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).
「変更プロセス状態の変更」は、異常な終了に（ここでのみ）使用されます。（cf。支払い処理関連の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).
「変更プロセス状態の変更」は、異常な終了に（ここでのみ）使用されます。（cf。支払い処理関連の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.
「支払いを開始または再開する消費者/支払いハンドラー」は、支払い取引を開始または再開します。消費者と支払いハンドラーの2つの取引役割に特定の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支払い領収書の一貫性と有効性をチェックするか、「Inquire Process State」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
------------ -------- --------------- --------
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 # ?
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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. （Authenticator Process）なし、1つまたは複数のIOTP支払いブリッジ（IPB）が1つまたは複数の認証チャレンジ値を要求されます（「認証チャレンジ」）。各値は、IOTP認証要求コンポーネントにカプセル化されています。さらに、IOTPアプリケーションコアは、支払いスキームに独立した認証方法を追加する場合があります。それらはすべて最終的なIOTP認証要求ブロックを形成します。これは、認証機によってサポートされている認証メソッドのセットを記述し、そこからAuthenticateeは1つのメソッドを選択する必要があります。
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関数のインターフェイスは、呼び出しごとに1つのアルゴリズムの応答に限定されていることに注意してください。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認証ブロックが存在すると、Authenticateeの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やチップカードの挿入などの明示的なユーザーインタラクションが必要な2つ以上の認証アルゴリズムが受信された場合、適切かもしれません。
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.
Authenticateeの組織データは、コンテンツ要素のない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. （Authenticator Process）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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. MerchantのCommerce Serverは、消費者がショッピングカートをチェックアウトし、支払いの意図を示すまで、独自のメカニズムでショッピングダイアログを制御します。この概念ショッピングは、IOTPオーダーコンポーネントのコンテンツを交渉するために、商人取引ロール（金融機関を包含）Webサイトの非OITPベースの訪問を抑えます。その後の処理は、商人の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支払いブリッジは、W.R.T。他の入力パラメーター。
5. The steps 3 and 4 are repeated during IOTP Value Exchange transactions - these steps are omitted in the previous figure.
5. 手順3と4は、IOTP値交換トランザクション中に繰り返されます。これらの手順は、前の図で省略されています。
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 the Brand List Component. However, the compilation must consider several aspects in order to prevent conflicts - sharing detection might be textual matching (after normalization):
6. IOTPアプリケーションコアは、ブランドリストコンポーネントとIOTP取引プロトコルオプションブロックをコンパイルします。IOTP支払いブリッジ機能コールによって返される「等しい」アイテムは、ブランドリストコンポーネント内の広範なリンク機能があるため共有することをお勧めします。ただし、紛争を防ぐためには、コンピレーションではいくつかの側面を考慮する必要があります。共有の検出は、テキストマッチング（正規化後）である可能性があります。
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 Consumerの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 Brandselsselinfo要素に依存しません。
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ブロックを含むIOTP TPOメッセージをコンパイルし、メッセージを消費者に送信します。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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. MerchantのCommerce Serverは、消費者がショッピングカートをチェックアウトして支払いの意図を示すまで、独自のメカニズムでショッピングダイアログを制御します。その後の処理は、商人の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アプレットや外部アプリケーションなど）を呼び出します。そのIOTPアプリケーションコア
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 1つまたは複数のブランドとプロトコルのセットを編集して、すべてのセットの結合が、商人が提供する支払いの代替案を正確に説明します。
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 Payment Bridges and payment software modules should provide a thin and fast implementation - without lengthy initialization processes - for this initial inquiry step.
IOTPアプリケーションコアがウォレット識別子を管理することをお勧めします。ただし、セキュリティ上の理由から、パスフレーズはランタイムメモリにのみプレーンテキストに保存する必要があります。IOTP支払いブリッジと支払いソフトウェアモジュールの開発者は、この最初の問い合わせステップのために、長い初期化プロセスなしで、薄くて迅速な実装を提供する必要があります。
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 消費者の選択を要求するか、構成された設定から自動的に導出されます。選択は、1つの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必要な周辺機器は利用できません。O（非OITP）リモートパーティ（発行者、サーバーウォレットなど）は利用できません。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 to suspend the transaction, e.g., initiating a nested transaction for uploading an electronic purse.
o 問題を解決するために、例えば別の支払い手段を挿入したり、周辺を検証したりするために、o続行する（成功を仮定する）、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. 手順2から5は、IOTP値交換トランザクション中に2番目の支払い機器を選択するために繰り返され、場合によってはインターレースされます。これは上の図で省略されています。
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に示されています。オプションを示します。
(Technically, two payments happen during IOTP Value Exchange transactions.)
（技術的には、IOTP価値交換トランザクション中に2つの支払いが発生します。）
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
| 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 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前の問い合わせステップからの支払い手段、o選択された通貨額要素、ブランドリストコンポーネント、および選択した通貨額の要素、およびその他の支払いパラメーター（通貨、金額、方向、有効期限）からの支払い手段IOTPの支払いコンポーネントは、選択されたIOTP Pay Protocol要素からの支払いプロトコルを提供するIOTPの支払いブロック、o支払いスキーム固有のIOTP ORDERコンポーネントに含まれるORDERの詳細、IOTPからの支払いプロトコルの説明を含む支払いスキーム固有のデータプロトコルの量要素、およびIOTP Pay Protocol要素、およびo支払いスキームの特定のデータを含む特定のデータの説明。名前属性には、トレーディングロールデータコンポーネントからの「支払い：」としてプレフィックスが含まれています。
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）は、埋め込み支払いスキーム固有のデータを適切なIOTP支払いブリッジに透過的に提出します。このブロックからカウンターパーティー。
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.
最後に、支払いハンドラーは、消費者からのさらなる応答を待つことなく、「変更プロセス状態」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支払いブリッジが、継続ステータス「End」で以前の支払いスキーム固有のデータを返した可能性があることに注意してください。この知識がない場合でも、このステータスは消費者と支払いハンドラーの間で交換されません - 支払いハンドラーは、それ以上の支払いスキーム固有のデータを提供してはなりません。このようなデータは、消費者の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アプリケーションコアは「質問プロセス状態」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.
最後に、トランザクションは、報告された支払いステータスをローカルのものと検証および同期する「変更プロセス状態」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は、1番目と2番目の給与パッケージコンテンツデータを示しており、[]はオプションを示しています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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アプリケーションコアは、「開始支払い照会」APIリクエストを使用して、ブランド選択中に修正されたIOTP支払いブリッジからの追加の特定の支払いスキームデータを要求します。
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 errors are reported by Status Components within IOTP Response Blocks while technical errors are signaled by Error Components within IOTP Error Blocks.
IOTP支払いAPIは、失敗通知の受信と障害応答に対処する必要があります。この提案は、IOTPアプリケーションコアと実際のプロトコルからのIOTP支払いブリッジ間のエラーレポートの基本的なメカニズムを借用しました。ビジネスエラーは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は、ビジネスエラーの表示に1つの追加のエラーコード値を導入します。すべての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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
特定の完了コードは、「Quire Process State」によって返された「Finctioned」、「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関数「Change Process State」により、支払い（中間）終了、つまり障害、キャンセル、さらには成功が常に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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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メカニズムを使用する場合があります。ただし、カウンターパーティーとChIPカードリーダーや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 1つの当事者が送信した1つの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アプリケーションコアは、知識の欠如を更新するために「Inquire Process State」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」で返す必要があります。
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. 1つ以上の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 | findPaymentPossiblity | StartPaymentConsumer | StartPaymentPaymentHandler | ResumementMentmentMentumermentementmentementPaymentmentmenter ESSSTATE | InquireAuthChallenge |認証|
CheckAuthResponse | CheckPaymentReceipt | ExpandPaymentReceipt | RemovePaymentLog | PaymentInstrumentInquiry | InquirePendingPayment | ManagePaymentSoftware | StartPaymentInquiry | InquirePaymentStatus | CallBack )>
CheckAuthResponse |CheckPaymentReceipt |ExpandPaymentReceipt |RemovePaymentLog |PayuntInstrumentInquiry |InquirEpending -Payment |managementsoftware |startpaymentinquiry |InquirEpaymentStatus |コールバック）>
<!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 )?)>
| StartPaymentInQuiryResponse | InquirePaymentStatusResponse | callbackResponse）？）>
<!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 >
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):
属性（cf.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 ソフトウェアメーカーの名前、oソフトウェアの名前、oソフトウェアのバージョン、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 Transienterror。これは、「名前」属性によって言及されている誤差のメッセージがresである場合、誤差のエラーが回復する可能性があることを示しています。
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「重大度」が「トランジェレール」に設定されている場合、この属性が存在する必要があります。「エラーロケーション」属性によって識別されたエラーを控える前に、エラーを報告するメッセージを受け取ったIOTP認識アプリケーションが最小秒数秒です。
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.
エラーロケーションこれは、可能であれば、エラー要素を生成する原因となったエラーのメッセージ内の要素と属性を識別します。エラーの「重大度」が「Transienterror」ではない場合、エラーの性質とIOTP支払いブリッジのベンダー/開発者の裁量に応じて、1つの「エラーロケーション」が適切に指定される可能性があります。
Its definition coincides with the IOTP specification whereby the attributes "IotpMsgRef", "BlkRef" and "CompRef" are left blank, intentionally.
その定義は、「IOTPMSGREF」、「BLKREF」、および「compref」が意図的に空白のままになる属性により、IOTP仕様と一致します。
PaySchemePackagedContent cf. Table 5
payschemepackagedcontent cf.表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.
次の表には、エラー応答要素のエラーコード属性の有効な値を示します。エラー説明の最初の文には、表示または報告されたときにエラーを説明するために使用できるデフォルトのテキストが含まれています。個々の実装は、裁量でこれを代替言語に変換する場合があります。ただし、すべてのエラーコードがすべての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支払いブリッジによって省略されているエラーロケーション要素内に属性（および値）を追加する場合があります。
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
----------- -----------------
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.
名前属性は、入力パラメーターリストのいくつかの属性と要素を参照する場合があります。
(*)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).
エラーロケーション要素の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 EXMENSION ELEMENT。XMLドキュメントは適切に形成され、有効ですが、この仕様に含まれるルールと制約に従って特定のコンテキストでは予想されない要素が存在します。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
エラーロケーション要素の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 この仕様に含まれるルールと制約と一致していますが、OはIOTPメッセージを処理しているIOTP認識アプリケーションによってサポートされていません。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
エラーロケーション要素の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.
エルミス要素がありません。ドキュメントは適切に形成されていて有効ですが、この仕様に含まれるルールと制約が守られている場合、存在するはずの要素が欠落しています。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
エラーロケーション要素の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.
Elcontillegal Element Content違法。ドキュメントは適切に形成されていて有効ですが、要素には、この仕様に含まれるルールと制約に準拠していない値が含まれています。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding element (if they have ID attributes).
エラーロケーション要素の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.
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.
Encapproterrカプセル化プロトコルエラー。ドキュメントは適切に形成されていて有効ですが、要素のパッケージコンテンツには、エラーを含むカプセル化されたプロトコルからのデータが含まれています。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding element (if they have ID attributes).
エラーロケーション要素の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.
AstunExpectedの予期しない属性。XMLドキュメントは適切に形成され、有効ですが、この仕様に含まれるルールと制約に従って、特定のコンテキストでは属性の存在は予想されません。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
エラーロケーション要素の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.
エラーロケーション要素の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 Awareアプリケーションではサポートされていません。
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.
ATTMISSING属性がありません。ドキュメントは適切に形成されていて有効ですが、この仕様に含まれるルールと制約が順守されている場合、存在するはずの属性が欠落しています。
The AttName attributes of ErrorLocation elements might refer to the corresponding attribute tags.
エラーロケーション要素の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:
エラーロケーション要素の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.
PayantInStrumentID：違法/不明な支払い機器識別子 - これは、以前の問い合わせリクエストで同じ「ウォレット」によって属性値が報告されている場合、深刻な通信の問題を示します。IOTPアプリケーションコアは、カウンターパーティに送信する前に、エラーコードを「不明」に置き換える必要があります。
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アプリケーションコアは、カウンターパーティに送信する前に、エラーコードを「不明」に置き換える必要があります。
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.
PassPhrase：違法/不明なパスフレーズ-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
PayDirection：違法/不明/サポートされていない支払い方向
ProtocolId: illegal/unknown/unsupported Protocol Identifier 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
PaybureHandlerPayID：違法/不明な支払いハンドラー支払い識別子
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.
エラーロケーション要素の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).
Eltoolarge要素が大きすぎます。要素は大きすぎて、IOTP支払いブリッジ（またはIOTPアプリケーションコア）によって処理できません。
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements.
エラーロケーション要素の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.
ValueToosmallは小さすぎるか早すぎます。要素コンテンツまたは属性のすべてまたは一部の値は、有効ですが、小さすぎます。
The ErrorLocation elements might refer to the corresponding attribute tags or elements.
エラーロケーション要素は、対応する属性タグまたは要素を参照する場合があります。
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.
エラーロケーション要素は、対応する属性タグまたは要素を参照する場合があります。
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 属性の値は、他の1つ以上の属性の値と矛盾しています。
The Error Description may contain further explanations.
エラーの説明には、さらに説明が含まれる場合があります。
The ErrorLocation elements might refer to the corresponding attribute tags or elements that are inconsistent.
エラーロケーション要素は、一貫性のない対応する属性タグまたは要素を指す場合があります。
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の失われたインターネット接続」、「インターネット接続なし」、「モデム接続なし」、または「シリアル」、「リモートアカウントマネージャー」、「リモートアカウントマネージャーが到達できない」、さらに物語の説明が含まれる場合があります。別のアプリケーションで使用されるポートからモデムへのポート」。このテキストは、エンドユーザーに表示される必要があります。消費者でタイムアウトが発生した場合、このテキストが表示され、消費者が進行方法を決定する場合があります - 代替案は再試行、支払い取引の停止、およびキャンセルです。
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メッセージが処理されています。このエラーコードは、過渡エラーの重大度でのみ使用されます。これは、Exchangeメッセージまたは要求メッセージである可能性のある以前のメッセージが処理されていることを示しており、「Minretrysecs」属性で示された時間までに応答がない場合、元のメッセージがresする必要があります。
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.
忙しいSystembusyシステム。このエラーコードは、過渡エラーの重大度でのみ使用されます。これは、APIリクエストを受け取ったIOTP支払いブリッジまたは既存の支払いソフトウェアが現在、それを処理するには忙しすぎることを示しています。「Minretrysecs」属性で示される時間までに応答がない場合、元のメッセージはresする必要があります。
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.
エラーロケーション要素は、一貫性のない対応する属性タグまたは要素を指す場合があります。
(*)SyntaxError Syntax Error. An (unknown) syntax error has occurred.
（*）Syntaxerror構文エラー。（不明）構文エラーが発生しました。
The ErrorLocation elements might refer to the corresponding attribute tags or elements that are inconsistent.
エラーロケーション要素は、一貫性のない対応する属性タグまたは要素を指す場合があります。
The IOTP Application Core has to replace the error code with "XmlNotValid" or "UnknownError" before transmission to the counter party.
IOTPアプリケーションコアは、カウンターパーティに送信する前に、エラーコードを「xmlnotvalid」または「uncrederror」に置き換える必要があります。
(*)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".
（*）再洗浄リクエストは拒否されました。APIリクエストは（現在）IOTP支払いブリッジによって拒否されます。エラーの説明では、さらに説明が提供される場合があります。たとえば、「ウォレット /チップカードリーダーは別の支払いトランザクションによって利用できないか、ロックされています」、「支払いゲートウェイが過負荷になります」、「不明なチップカードリーダー」、または「認識されていないチップカードが挿入され、チップカードの変更「。
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」または「UncondError」にマップします。
(*)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リクエストはサポートされていません。API関数（Ality）はIOTP支払いブリッジに実装されていません。通常、この種のエラーは、カウンターパーティのIOTPアプリケーションコアに渡されません。それ以外の場合は、「Transporterror」または「UncondError」にマップします。
(*)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.
（*）Buserrorビジネスエラー。一部の支払い取引には違法な支払いステータスがあるため、API要求は拒否されました。特に、このエラーコードは、支払い事業層の障害の増加を通知するために使用されます。
The ErrorLocation elements may refer to payment transactions using the party's Payment Identifier - it defaults to the 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".
エラーロケーション要素は、当事者の支払い識別子を使用した支払いトランザクションを指す場合があります - デフォルトで現在のトランザクションを使用するか、現在の支払いトランザクション当事者の支払い識別子が含まれている場合があります。
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
--------- -----------
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）で支払われる支払い額を示します。たとえば、$ 245.35などの金額（11）は「245.35」と表現されます。最小の宗派よりも小さい値が許可されていることに注意してください。たとえば、10分の1は「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 Authenticatorが指定した識別子は、認証要求を受信する組織によって返された場合、認証機が参照されている認証を識別できるようにします。
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.
Brandnameこれには、「MasterCard Credit」など、ブランドの名前が含まれています。これは、「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.
Brandnarrativeこのオプションの属性は、消費者がそのブランドを選択した場合に適用される特別な条件または利点を示すために商人によって使用されます。たとえば、「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.
CompleateCode（14）は、プロセスがどのように完了したかを示します。ProcessStateが「故障」に設定されている場合、それ以外の場合は無視されます。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.
ConsumerDesc消費者の物語の説明。
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 ソフトウェアメーカーの名前、oソフトウェアの名前、oソフトウェアのバージョン、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]に準拠した3文字のアルファベットコードであることを示しています。o IoTPは、[IOTP]で説明されている手順の下で、Currcodeの値が管理されていることを示します。
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.
cf.独自性についての注意のために「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>
The "Name" attribute may be omitted, for example if there is only one Packaged Content element.
たとえば、パッケージ化されたコンテンツ要素が1つしかない場合、「名前」属性は省略できます。
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形式の範囲の日付と時刻は、支払いハンドラーが支払いを受け入れる可能性のある商人によって示されています。詳細については、[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.
PassPhrase（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およびPaying Handler Pay IDを特定する必要があります。
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.
PaymentHandlerDesc支払いハンドラーの物語の説明。
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.
PaybureHandlerPayID（14）支払いハンドラーによって指定された一意の識別子。これは、消費者が別の支払いスキームコンポーネントまたは他の手段で返送する場合、支払いハンドラーがどの支払いが参照されているかを特定できるようにする。それが知られているときはいつでも必要です。
Cf. To "ConsumerPayId" for note about uniqueness.
cf.独自性についての注意のために「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 instrument identifier is unique within each payment brand. It is displayed to the Consumer during brand selection.
PaymentInStrumentID特定の支払いの識別子（32）機器、例えば「クレジットカード」、「英語ポンドのMondexカード」。この識別子は完全にカスタマイズ可能です。機密情報やそれの兆候さえ含まれていないと想定されています。支払い機器識別子は、各支払いブランド内で一意です。ブランド選択中に消費者に表示されます。
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は、登録を構成する他の要素（支払いスキーム固有のデータを含む）への要素参照をオプションで含んでいます。各支払いスキームは、そのサプリメントで参照する必要がある要素を定義していることに注意してください
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.
パーセントcomplete（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 ProcessError。この値は、お問い合わせリクエスト取引ブロックに関連してステータスコンポーネントが使用されている場合にのみ使用されます。これは、処理されているリクエストブロックに技術的なエラーがあったか、内部処理エラーがあったことを示しています。各当事者の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.
PropertyDescプロパティの説明には、それぞれの人間の読み取り可能なプロパティ（値）の説明が含まれています。
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には、各プロトコルで使用されるブランド識別子の独自の明確な、しかし異なる値があります。この属性の有効な値は、支払いプロトコルがIOTPでどのように機能するかを説明する「プロトコリッド」によって識別される支払いプロトコルのサプリメントで定義されています。識別子は、最大で1つのプロトコルブランド識別子にマップします。
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.
プロトコルネーム「XML：Lang」で識別された言語の支払いプロトコルとそのバージョンの物語の説明。たとえば、「Secure Electronic Transactionバージョン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 Payment Bridge Processing Tradingロールデータパッケージコンテンツを受信する組織の識別。
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
------- -----------
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 authentication response value. The content of this information is defined in the supplement for a payment protocol.
その宣言は、パッケージ化されたコンテンツの宣言（IOTP仕様を参照）と一致します。認証応答値をカプセル化します。この情報の内容は、支払いプロトコルのサプリメントで定義されています。
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).
BrandPackagedContent Container追加支払いブランドの説明。そのコンテンツは、最も外側の要素タグに「ブランド」が付いているブランド要素コンテンツに由来します。その宣言は、パッケージ化されたコンテンツの宣言（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.
BrandselBrandinFopagedContentこれには、特定の支払いブランドが必要とする可能性のある追加データが含まれています。ブランド選択ブランド情報要素のコンテンツを形成します。
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.
BrandselProtocolamountInfopAgedContentこれには、特定の支払いブランドが形式で必要とする可能性のある追加データが含まれています。ブランド選択プロトコル量情報要素のコンテンツを形成します。
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.
BrandselCurrencyAmountInFopagedContentこれには、この形式で支払いブランドと通貨固有の追加データが含まれています。ブランド選択通貨量情報要素のコンテンツを形成します。
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支払いブリッジが使用する可能性のあるマーチャント関連のデータ。パッケージ化された宣言は、コンテンツの宣言（IOTP仕様を参照）と一致します。
PackagedContent Generic Container for non-IOTP data (cf. IOTP Specification).
PackagedContent非OITPデータ用の一般的な汎用コンテナ（IOTP仕様を参照）。
PayProtocolPackagedContent The Pay Protocol Packaged Content originates from a Pay Protocol Element's content whereby the outermost element tags are prefixed with
PayProtocolpackagedContent Pay Protocol Packaged Contentは、最も外側の要素タグが付いているPayプロトコル要素のコンテンツに由来します。
"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).
「PayProtocol」。支払いプロトコルで使用されるプロトコルに関する情報が含まれています。この情報の内容は、支払いプロトコルのサプリメントで定義されています。その宣言は、パッケージ化されたコンテンツの宣言（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.
PayschemepackagedContent 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プロトコルブランドのパッケージ化されたコンテンツは、最も外側の要素タグに「プロトコルブランド」が付いているプロトコルブランド要素のコンテンツに由来します。その宣言は、パッケージ化されたコンテンツの宣言（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コンテナ認証応答データのためのコンテントコンテナ。そのコンテンツは、認証応答コンポーネントのパッケージ化されたコンテンツに由来します。そのパッケージ化されたコンテンツでは、最も外側の要素タグに「応答」が付いています。その宣言は、パッケージ化されたコンテンツの宣言（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.
cradingroledatapagedcontent Tradingroledataパッケージ化されたコンテンツは、最も外側の要素タグに「Tradingroledata」が付いているTradingroledataコンポーネントのコンテンツに由来します。その宣言は、パッケージ化されたコンテンツの宣言（IOTP仕様を参照）と一致します。これには、支払いによって使用されるプロトコルに関する消費者を介して、販売者から支払いハンドラーへの情報が含まれています。この情報の内容は、支払いプロトコルのサプリメントで定義されています。このパッケージ化されたコンテンツの名前属性には、Prefixを「支払い：」として含める必要があります。詳細については、[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 % 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">
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の観点からトランザクションステータスをエンコードする6つの異なる属性値、つまり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.
次の3つの表は、商人、消費者、および支払いハンドラーの環境を区別します。彼らは、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
------------ -----------
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.
notyetStartは、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.
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 be initiated out-of-band to IOTP, e.g., by electronic statements of account or payment scheme specific mechanisms.
IOTPは商人と支払いハンドラーの間に通信チャネルを提供していないため、支払いプロセスの変更は、たとえば、アカウントの電子声明または支払いスキーム固有のメカニズムにより、帯域外に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からBAND外のハンドラーを使用して）を逆にするために使用される場合があります。
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.
IOTPトランザクション、つまり注文処理をProcessErrorは、いくつかの（技術的な）理由で失敗し、支払いが発生しないことが知られています。
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からBAND外のハンドラーを使用して）を逆にするために使用される場合があります。
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アプリケーションコアは、支払いトランザクションの視点を制限します。IOTP支払いブリッジは、前述のブランド選択プロセスを無国籍方法で処理すると想定されています。
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.
NotyETSTARTは、IOTP支払いトランザクションの初期プロセス状態をエンコードします。この値はブランド選択中に設定されますが、通常、ブランド選択プロセス全体では変更されません。
InProgress With the issuance of the Start Payment Consumer API call, the IOTP Application Core changes the process state to this value.
Inprogress開始支払い消費者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支払いブリッジは、他の内部データを使用して、ブランド選択または実際の支払い処理を継続する必要があるかどうかを決定する必要があります。。
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.
完了した支払いの成功は、支払いハンドラーによって認められています。つまり、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.
IOTPトランザクション、つまり注文または支払い処理をProcessERRORは、（技術的な）理由で失敗しました。
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
------------ -----------
NotYetStarted This encodes the initial process state of any payment transaction. Typically, this value will last for a short amount of time.
NotyETSTARTは、これが支払い取引の初期プロセス状態をエンコードします。通常、この値は短時間続きます。
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.
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.
完了した支払いは、成功して処理されました。つまり、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.
この値は、「InquireProcessState」のIOTP支払いブリッジによって報告された支払い状態をコードすることに注意してください。支払い領収書が尋ねられたかどうか、またはIOTP支払い応答ブロックが作成され、消費者に提出されたかどうかは反映されません。
ProcessError The payment transaction, has finally failed for some (technical) reason.
プロセスエラー支払いトランザクションは、いくつかの（技術的な）理由でついに失敗しました。
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アプリケーションCOREによって提供されるCORE 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 >
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（ブランド）パッケージコンテンツに挿入するため - ブランドリストコンポーネントのブランド要素に挿入するためのさらなる支払いブランド説明
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 >
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関数は、商人に代わって支払いハンドラーによって受け入れられる支払いプロトコル（およびオプションでは支払いブランド）のインスタンスを決定します。この関数は、2つのバリアントで呼び出される場合があります。
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 >
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ブランドアイテムリスト（セクション4.1.1を参照） - 入力パラメーターリストにブランド識別子が提供されていない場合、少なくとも1つの要素。O（プロトコル量）パッケージコンテンツ - ブランドリストコンポーネントのプロトコル量要素O（PAYプロトコル）パッケージコンテンツに挿入 - ブランドリストコンポーネントの賃金プロトコル要素O通貨量要素 - [IOTP]の定義と非常に類似しています、それには、洗練された通貨コードと通貨 - ブランドリストコンポーネントの通貨金額要素に挿入するための洗練された通貨 - 洗練された支払い額 - ブランドリストコンポーネントの通貨額要素oブランドに挿入 - 各プロトコル項目に少なくとも1つの要素が必要な場合は、入力パラメーターリストにブランド識別子は提供されていません。
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 Brand EMPTY >
<!ATTLIST Brand
BrandId CDATA #REQUIRED >
<!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関数は、消費者または支払いハンドラーの既存の支払いソフトウェアで必要とされる残りの初期化データを提供します。この関数は、「ブランド依存」と「ブランド独立」トランザクションタイプの両方に対して呼ばれる場合があります。どちらの場合でも、この関数は1つの特定のブランドで呼び出されます。
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（tradingroledata）レシーバー組織識別子、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マーチャントシステムを共有する複数の商人oウォレット識別子および/またはパスフレーズを共有する複数の商人間の区別に使用される
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.
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 >
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）パッケージコンテンツに挿入 - さらなる支払いプロトコルの説明。パッケージ化されたコンテンツ要素の名前属性には、「支払い：」をプレフィックスとして含める必要があります。たとえば、「支払い：set-od」です。詳細については、[set/iotp]を参照してください。o（注文）パッケージ化されたコンテンツ - 省略された場合、供給された注文パッケージコンテンツにデフォルトです。
XML definition:
XML定義：
<!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 >
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) >
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アプリケーションコアは、Active 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".
認証の失敗は、詳細の問い合わせをトリガーする可能性のあるビジネスエラーコードによって報告されています（「プロセス状態」）。最終的な障害は、プロセス状態によってエンコードされる可能性があります。
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 >
Output Parameters
出力パラメーター
o Authentication Response Packaged Content - for insertion into the IOTP Authentication Response Component
o 認証応答パッケージコンテンツ - IOTP認証応答コンポーネントへの挿入用
XML definition:
XML定義：
<!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支払いブリッジに提出されます。認証障害は、「完了」とは異なるプロセス状態によって報告されます。
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 >
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 empt> <！attlist checkauthResponseresponse processState（notyetstarted | inprogress | suspended | rectremedok | failed | processerror）#required compretedcode nmtoken
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関数は、2つの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アプリケーションコートに複数の可能な支払いブランド/プロトコルがある場合、この関数を順番に呼び出すことができます。
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.
既存の支払いソフトウェアは、特定の支払いの代替品について異なる支払い手段を区別しない場合、空のPayInStid属性を持つPayinstrument要素で応答します。
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 >
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.
既存の支払いソフトウェアは、異なる支払い手段を区別しない場合、または少なくとも1つの（特定されていない）支払いプロトコルのブランドサポートにもかかわらず、登録された支払い手段がない場合、識別子の空のリストで応答します。後者の場合、IOTP支払いブリッジは、支払いプロセスのその後のステップで適切な支払い手段の登録を要求する必要があります。
XML definition:
XML定義：
<!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 Protocol Brand Identifier-選択されたブランド要素に関連するブランドリストコンポーネントの選択されたプロトコルブランド要素からコピーされます。）パッケージ化されたコンテンツ - 選択したブランド要素oからコピーされたO（プロトコル量）パッケージコンテンツ - 選択したプロトコル量要素O（プロトコル）パッケージコンテンツからコピー - 選択したPayプロトコル要素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 >
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 3つのブランド選択情報パッケージ化されたコンテンツ要素 - ブランド選択コンポーネントoブランドへの挿入用ブランド - 支払いブランドに関する追加データoプロトコル額 - 支払いプロトコルに関する追加データo通貨額 - 追加支払いブランドと通貨固有のデータ
XML definition:
XML定義：
<!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）インターネット接続が再確立される場合があります。セキュリティハードウェアに相互排他的なセッションを開きます。
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がokto- o okto-支払いコンポーネントo消費者支払い識別子からコピー - 現在の支払いトランザクションoウォレット識別子および/またはパスフレーズoコールバック関数 - エンドユーザー通知/ロギング目的で使用されますoコールバック言語リスト。コールバック関数が設定されている場合、このリストが必要です。選択したブランド要素のコンテンツo（プロトコル量）パッケージコンテンツからコピーされた - さらなる支払いプロトコル説明。選択したプロトコル量要素のコンテンツo（支払いプロトコル）パッケージコンテンツからコピーされた - さらなる支払いプロトコル説明。選択したPay Protocol Elementのコンテンツ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 >
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 >
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支払いハンドラー識別子 - 支払いハンドラーの現在の支払い取引への一意の参照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コールバック言語リスト。コールバック関数が設定されている場合、このリストが必要です。Consumer Selected Brand Elementのコンテンツo（プロトコルブランド）パッケージコンテンツからコピーされました - 詳細情報。消費者が選択したブランド要素に関連するブランドリストコンポーネントのプロトコルブランド要素からコピーされました。o（プロトコル量）パッケージコンテンツ - さらなる支払いプロトコルの説明。消費者から選択されたプロトコル量要素のコンテンツo（プロトコル）パッケージコンテンツからコピー - さらなる支払いプロトコルの説明。消費者が選択した有料プロトコル要素のコンテンツo（TradingroleData）パッケージコンテンツからコピー - さらなる支払いプロトコルの説明。パッケージ化されたコンテンツの名前属性には、「支払い：」をプレフィックスとして含める必要があります。たとえば、「支払い：set-od」です。詳細については、[set/iotp]を参照してください。o 3つのブランド選択情報パッケージ化されたコンテンツ要素 - ブランド選択コンポーネント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
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
PaymentHandlerPayId CDATA #REQUIRED
MerchantOrgId 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 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 >
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アプリケーションコア次第です。1つの指標は、支払いハンドラーからの以前のIOTP支払い交換ブロックの受領、たとえば支払いハンドラー支払い識別子の知識です。
Input Parameters
入力パラメーター
o Consumer Payment Identifier o Wallet Identifier and/or Pass Phrase o Call Back Function - used for end user notification/logging purposes
o 消費者支払い識別子oウォレット識別子および/またはパスフレーズoコールバック機能 - エンドユーザー通知/ロギング目的で使用
XML definition:
XML定義：
<!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 >
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 コールバック関数 - エンドユーザー通知/ロギング目的で使用されますoコールバック言語リスト。コールバック関数が設定されている場合、このリストが必要です。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 >
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 >
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関数は、1つの特定の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; merchant：merchantpayid; Paymenthandlerpayid）に支払い識別子を設定する必要があります。
XML definition:
XML定義：
<!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 >
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」は、支払い取引がすでに失敗した場合、支払いステータスが失敗する可能性があります。
Transaction Suspension is notified by the newly introduced Process State "Suspended". The other attribute values have been taken from the IOTP specification.
トランザクションサスペンションは、新しく導入されたプロセス状態「停止」によって通知されます。他の属性値は、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.
このAPI関数は、消費者による「FindPaymentInstrument」の「FindPaymentInstrument」の発行後、各支払い取引の消費者、商人、または支払いハンドラーが、販売者による「FindAcceptedPaymentBrand」の発行、または支払いハンドラーによる「StartPaymentPaymentHandler」。
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.
このプロセスでは、後続の呼び出しで変更できないという意味で、「完了」、「失敗」、および「プロセスエラー」が最終的に述べています。ただし、このような互換性のない呼び出しが発行されている場合、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 XML definition:
o 当事者の支払い識別子o意図された支払いステータスo意図された完了コードoプロセス（トランザクション）タイプの支払いと問い合わせを区別します。oウォレット識別子および/またはパスフレーズ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 >
<！要素変化プロセスステート空き> <！ATTLIST CHANGESPROCESSSTATE PAYID CDATA #Required ProcessState（notyetStarted | inprogress | inprogress | cuspedend | completedok | compreded | processerror）暗示>
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 >
<！要素変化プロセスステーターエスパン空空vent> <！attlist changeprocessstateresponse processState（notyetStarted | inprogress | suspended |完了| compredok | failed | processerror）#required complete 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 >
Output Parameters
出力パラメーター
XML definition:
XML定義：
<!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 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支払い機器識別子oプロトコル識別子oウォレット識別子および/またはパスフレーズoプロパティタイプリスト - 言語がXMLによって識別される値のシーケンス：lang O（ブランド）パッケージコンテンツコンテンツ - さらなる支払いブランド説明oプロトコルブランドコンテンツ - さらに支払いブランド情報o（プロトコル量）パッケージコンテンツコンテンツ - さらなる支払いプロトコル説明o（Pay Protocol）パッケージコンテンツコンテンツ - さらなる支払いプロトコルの説明
The codes in the property type list are of two types:
プロパティタイプリストのコードには、2つのタイプがあります。
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
XML definition:
XML定義：
<!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 >
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 >
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 XML definition:
o ウォレット識別子および/またはパスフレーズXML定義：
<!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 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支払い領収書コンポーネントから-Payment Handlerの「Inquire Process State」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 消費者の「お問い合わせプロセス状態」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 >
Output Parameters
出力パラメーター
XML definition:
XML定義：
<!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 XML definition:
o 当事者の支払い識別子oウォレット識別子および/またはパスフレーズo支払い領収書XML定義を構築するすべてのパッケージ化されたコンテンツ要素：
<!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スタイルシートネットロケーションo支払いプロパティリスト。他の出力パラメーターのいずれでもカバーされていない支払いに関する追加情報を含むタイプ/値/説明トリプルのリスト。プロパティの説明は、言語注釈を考慮する必要があります。
The Style Sheet Net Location refers to a Style Sheet (e.g., [XSLT]) that contains presentation information about the reported XML encoded data.
スタイルシートネットの場所は、報告されたXMLエンコードデータに関するプレゼンテーション情報を含むスタイルシート（[XSLT]など）を指します。
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
PaymentHandlerDesc CDATA #IMPLIED
StyleSheetNetLocn CDATA #IMPLIED>
<!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 >
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を参照）、すべてのパッケージ化されたコンテンツ要素（セクション4.5.1を参照）を参照してください（セクション4.5.1を参照）（セクション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 >
<！要素InquireProcessstateresponse（PackagedContent*）> <！ATTLIST InquireProcessStateresponse ProcessState（notyetStarted | inprogress | cuspended | completedok | processError） nmtokens＃暗示>
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 XML definition:
o 消費者支払い識別子oウォレット識別子および/またはパスフレーズXML定義：
<!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*) >
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 >
Output Parameters
出力パラメーター
o Current Process State o Completion Code 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完了コード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 >
<！要素InquiceEpaymentStatusResponse（PayschemepackagedContent*）> < ied>
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（Pay Protocol）パッケージコンテンツ - さらなる支払いプロトコル説明
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.
アクション属性が設定されている場合、ブランドとプロトコル識別子も設定する必要があります。IOTP支払いブリッジは、必要なユーザーダイアログと選択メカニズムを提供する必要があります。たとえば、更新と削除には、支払い手段の選択が必要になる場合があります。新しいウォレット識別子のサプリメントで、または追加のエンドユーザーが確認した後、新しいウォレットが静かに生成される場合があります。IOTPアプリケーションコアは、新しいウォレットにパスフレーズを提供しないでください。代わりに、IOTP支払いブリッジはそれらを要求して検証する必要があります。これにより、その価値は、プレーンテキストのIOTPアプリケーションコアに戻す可能性があります。さらに、IOTP Payment Bridgeは、新しいブランドとプロトコルペアが登録されているときに、サポートされている認証アルゴリズムを返します。
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.
「アクション」属性が省略されている場合、既存の支払いソフトウェアを担当する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 >
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更新 - ウォレットの構成を変更して削除 - ウォレットを削除してウォレット識別子および/またはパスフレーズ
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, 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 Payment Bridgeは、各IOTPトランザクションの開始時のブランド選択プロセス中にこれらのデータ項目が動的に推測されるため、登録された支払い手段のセットに関する情報を返しません。ただし、IOTPアプリケーションコアに新しいウォレットについて通知する必要があり、更新および削除されたウォレット（識別子）について通知する必要があります。または、削除されたウォレットを次のブランド選択フェーズで暗黙的に検出することができます。更新されたウォレットは、IOTPアプリケーションコアの処理に影響を与えません。IOTP支払いブリッジは、IOTPアプリケーションコアに一度に複数の追加を報告できないため、最大1つのウォレットの追加のみをサポートする必要があります。
XML definition:
XML定義：
<!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.
IOTP Payment Bridgeによって呼び出されるこのAPI関数は、消費者または支払いハンドラーに支払い取引の進捗状況に関する情報を提供するために使用されます。
Its use is illustrated in the diagram below.
その使用は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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 「12.30 USDにXYZ INCに支払う「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.
有効な言語は、「Start Payment X」および「Resume 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コールバックContentsOftWareIDCDATA #Implied PayID CDATA #Required ProcessState（notyetStarted | inprogress | rectremendok | compreded | processerror）#implied>
Output Parameters
出力パラメーター
XML definition:
XML定義：
<!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").
一部の支払いスキームは、消費者がいつでも支払いをキャンセルできることをサポートまたは要求する場合があります。コールバック関数は、次の呼び出しでキャンセル要求を返すことにより、これを容易にするために使用できます（ビジネスエラーコードと完了コード「Fincescancelled」を使用）。
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関数は、このような種類の通知の2番目のメカニズムを提供することに注意してください。したがって、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 Payment APIは、パスフレーズを使用して支払いウォレットにアクセスするためのセキュリティのみをサポートします。これらは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」、RFC 2801、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、「Uniform Resource Locators（URL）」、RFC 1738、1994年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]拡張可能なマークアップ言語（XML）1.0（第3版）。W3Cの推奨。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] XML推奨の名前空間。T.ブレイ、D。ホランダー、A。レイマン。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]拡張スタイル言語変換1.0、1999年11月、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。ISBN0-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
[セット]セットセキュアエレクトロニックトランザクション（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起源のWerner Hansの貢献は感謝されています。
Authors' Addresses
著者のアドレス
Hans-Bernhard Beykirch
Hans-Bernhard Beykirch
EMail: hbbeykirch@web.de
Yoshiaki Kawatsura Hitachi, Ltd. 890 Kashimada Saiwai-ku Kawasaki-shi Kanagawa, Japan 212-8567
ヨシアキ・カワツーラ・ヒタチ、リミテッド890カシマダ・サイワイ・クワサキ・シシ・カナガワ、日本212-8567
EMail: ykawatsu@itg.hitachi.co.jp
Masaaki Hiroya Technoinfo Service, Inc. 333-2-718 Uchikoshi-machi Hachioji-shi Tokyo 192-0911 JAPAN
Masaaki Hiroya Technoinfo Service、Inc。333-2-718 Uchikoshi-Machi Hachioji-Shi Tokyo 192-0911 Japan
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。