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)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.
インターネットオープン取引プロトコル（IOTP）シームレスに既存の純粋な支払いプロトコルを統合しながら、トレーディング目的のためのデータ交換フォーマットを提供します。これは、少なくともいくつかの一般的なIOTPアプリケーションコアと複数の特定の支払いモジュールで構成多層システムアーキテクチャを動機付けます。
This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.
この文書では、モジュールのこれらの種類の間の相互運用性を可能にする、IOTPアプリケーションコアおよび決済モジュール間の共通のインタフェースに対応しています。さらに、そのようなインターフェースは、プラグイン機構IOTPアプリケーションコアの実際の実装にするための基盤を提供します。
Such interfaces exist at the Consumers', the Merchants' and the Payment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems.
そのようなインタフェースは、消費者、商人および支払いハンドラインストールがIOTPアプリケーションコアと支払いソフトウェアコンポーネント/レガシーシステムを接続で存在します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General payment phases . . . . . . . . . . . . . . . . . 5
1.2. Assumptions. . . . . . . . . . . . . . . . . . . . . . . 6
2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Authentication Documentation Exchange. . . . . . . . . . 15
2.2. Brand Compilation. . . . . . . . . . . . . . . . . . . . 17
2.3. Brand Selection. . . . . . . . . . . . . . . . . . . . . 21
2.4. Successful Payment . . . . . . . . . . . . . . . . . . . 24
2.5. Payment Inquiry. . . . . . . . . . . . . . . . . . . . . 29
2.6. Abnormal Transaction Processing. . . . . . . . . . . . . 30
2.6.1. Failures and Cancellations . . . . . . . . . . . 30
2.6.2. Resumption . . . . . . . . . . . . . . . . . . . 32
2.7. IOTP Wallet Initialization . . . . . . . . . . . . . . . 33
2.8. Payment Software Management. . . . . . . . . . . . . . . 34
3. Mutuality. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1. Error Codes. . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Attributes and Elements. . . . . . . . . . . . . . . . . 48
3.3. Process States . . . . . . . . . . . . . . . . . . . . . 61
3.3.1. Merchant . . . . . . . . . . . . . . . . . . . . 61
3.3.2. Consumer . . . . . . . . . . . . . . . . . . . . 63
3.3.3. Payment Handler. . . . . . . . . . . . . . . . . 65
4. Payment API Calls. . . . . . . . . . . . . . . . . . . . . . . 66
4.1. Brand Compilation Related API Calls. . . . . . . . . . . 66
4.1.1. Find Accepted Payment Brand. . . . . . . . . . . 66
4.1.2. Find Accepted Payment Protocol . . . . . . . . . 68
4.1.3. Get Payment Initialization Data. . . . . . . . . 70
4.1.4. Inquire Authentication Challenge . . . . . . . . 72
4.1.5. Authenticate . . . . . . . . . . . . . . . . . . 73
4.1.6. Check Authentication Response. . . . . . . . . . 74
4.2. Brand Selection Related API Calls. . . . . . . . . . . . 76
4.2.1. Find Payment Instrument. . . . . . . . . . . . . 76
4.2.2. Check Payment Possibility. . . . . . . . . . . . 78
4.3. Payment Transaction Related API calls. . . . . . . . . . 80
4.3.1. Start Payment Consumer . . . . . . . . . . . . . 80
4.3.2. Start Payment Payment Handler. . . . . . . . . . 82
4.3.3. Resume Payment Consumer. . . . . . . . . . . . . 84
4.3.4. Resume Payment Payment Handler . . . . . . . . . 85
4.3.5. Continue Process . . . . . . . . . . . . . . . . 86
4.3.6. Change Process State . . . . . . . . . . . . . . 88
4.4. General Inquiry API Calls. . . . . . . . . . . . . . . . 89
4.4.1. Remove Payment Log . . . . . . . . . . . . . . . 90
4.4.2. Payment Instrument Inquiry . . . . . . . . . . . 90
4.4.3. Inquire Pending Payment. . . . . . . . . . . . . 92
4.5. Payment Related Inquiry API Calls. . . . . . . . . . . . 93
4.5.1. Check Payment Receipt. . . . . . . . . . . . . . 93
4.5.2. Expand Payment Receipt . . . . . . . . . . . . . 94
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の詳細については、[IOTPBOOK] [IOTP]を参照して。
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
いくつかの一般的なIOTPシステムコンポーネント、いわゆるIOTPアプリケーションコアO - IOTPベースのゲートウェイサービスと汎用ビジネス・ロジックを提供し、
o the trading roles' specific back-end systems implementing the specific trading transaction types' functionality.
機能取引役割特定の取引トランザクションタイプ実装する特定のバックエンド・システムを、O。
In order to isolate the changes on the infrastructure, the IOTP trading application has been three-layered:
インフラに変更を単離するために、IOTP取引アプリケーションは三層されています：
o the IOTP Application Core processes the generic parts of the IOTP transaction and holds the connection to the Internet,
IOTPアプリケーションコアはIOTPトランザクションの一般的な部分を処理し、インターネットへの接続を保持しているO、
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.
他の二つの可能性が互換性のない部品を接着するIOTPミドルウェアやIOTP支払い橋O。また既存のレガシーシステムと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）ソフトウェアクレジットカードSETやサイバーコイン、モンデックスまたはゲルトカルテのようなベース（2）チップカード、および典型的なの（3）mimicriesのように基づいており、送金、口座引き落とし、預金、撤退、両替と値のポイントのような伝統的な支払方法。これは、消費者が事前に承認されている消費者が認める明示的および自動繰り返し支払い、との両方の支払いをサポートする必要があります。 SETの詳細については、[SET]を参照してください。
The following discussion focuses on the Consumer's point of view and uses the associated terminology. When switching to Merchants' or Delivery Handlers' IOTP aware applications, the payment related components should be implicitly renamed by Existing Legacy Systems to the IOTP Middle-ware.
以下の議論は、消費者の視点に焦点を当て、関連する用語を使用しています。商人や配達ハンドラIOTP対応のアプリケーションに切り替えると、支払い関連のコンポーネントは、暗黙的にIOTPミドルウェアへの既存のレガシーシステムで名前を変更する必要があります。
The next two sub-sections describe the general payment scenario and several assumptions about the coarsely sketched software components.
次の二つのサブセクションでは、一般的な支払いシナリオと粗くスケッチソフトウェアコンポーネントに関するいくつかの仮定を記述します。
Section 2 illustrates the payment transaction progress and message flow of different kinds of transaction behavior. Sections 3 to 4 provide the details of the API functions and Section 5 elaborates the call back interface.
第2節では、トランザクション動作の異なる種類の支払い取引の進捗状況やメッセージの流れを示しています。セクション3〜4は、API関数の詳細を提供し、第5節では、コールバックインターフェースを詳しく説明します。
The following table sketches the four logical steps of many payment schemes. The preceding agreements about the goods, payment method, purchase amount, or delivery rules are omitted.
次の表は、多くの決済スキームの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反転のためのインバウンドのメカニズムが欠けていますか、限られたバリアントを実装します。
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対M-方法で相互に関連するかもしれません。
o One IOTP Application Core may manage multiple IOTP Payment Bridges and the latter might be shared between multiple IOTP Application Cores. o Each Payment Bridge may manage multiple Existing Payment Software modules and the latter might be shared between multiple Payment Bridges. o Each Existing Payment Software may manage multiple payment schemes (e.g., SET) and the latter might be supported by multiple Existing Payment Software modules. For more information on SET see [SET].
OつIOTPアプリケーションコアは、複数のIOTP支払い橋を管理することができ、後者は、複数のIOTPアプリケーションコア間で共有されるかもしれません。 O各支払ブリッジは、複数の既存の支払ソフトウェア・モジュールを管理することができ、後者は、複数の支払橋の間で共有される可能性があります。 O既存の各支払ソフトウェアは、複数の支払い方式（例えば、SET）を管理することができ、後者は、複数の既存の支払ソフトウェアモジュールによってサポートされるかもしれません。 SETの詳細については、[SET]を参照してください。
o Each payment scheme may support multiple payment instruments (e.g., particular card) or methods (e.g., Visa via SET) and the latter might be shared by multiple Existing Payment Software Components.
O各支払い方式は、（SETを介して、例えば、ビザ）は、複数の決済手段（例えば、特定のカード）またはメソッドをサポートしてもよいし、後者は、複数の既存の支払ソフトウェアコンポーネントによって共有されるかもしれません。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant)
( contains Internet ( contains
IOTP Application Core) IOTP Application Core)
^ ^
| IOTP Payment | IOTP Payment
| API | API
v v
IOTP Payment Bridge IOTP Payment Bridge
^ ^
| Existing Payment APIs, e.g., |
| SET, Mondex, etc. |
v v
Existing Payment Software Existing Payment Software
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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、およびベースライン（支払い）お問い合わせ〇〇ベースラインの購入、。
For more information on Baseline IOTP, see [IOTP] and [IOTPBOOK].
ベースラインIOTPの詳細については、[IOTPBOOK] [IOTP]を参照して。
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は（、決済手段の解析のための支払取引、（2）（のセット）の支払いスキームの特定の後処理のために（1）で使用される可能性がありますインタラクティブモード、のいずれかの既存の支払ソフトウェアの起動をサポート3）新しい支払い手段/スキーム、または（4）支払い手段の再構成/スキームの登録。
o exports call back functions for use by the IOTP Payment Bridge or Existing Payment Software for progress indication.
Oの輸出はIOTP支払いの橋や進捗表示のための既存の支払ソフトウェアで使用するための関数をコールバック。
In addition, the IOTP Application Core
また、IOTPアプリケーションコア
o manages the IOTP message components and IOTP message blocks exchanged during the transaction which may be referenced and accessed during the processing of subsequent messages, e.g., for signature verification. In particular, it stores named Packaged Content elements exchanged during payments.
oはIOTPメッセージコンポーネントを管理し、IOTPメッセージブロックは、署名検証のために、例えば、後続のメッセージの処理中に参照され、アクセスされるトランザクション中に交換しました。特に、それは支払いの際に交換という名前のパッケージ化されたコンテンツ要素を格納します。
o manages several kinds of identifiers, i.e., transaction, message, component, and block identifiers,
oは、いくつかの識別子の種類、すなわち、トランザクション、メッセージ、コンポーネント、およびブロック識別子を管理します
o implements a message caching mechanism,
oは、メッセージ・キャッシング・メカニズムを実装します
o detects time-outs at the protocol and API level reflecting the communication with both the IOTP aware remote party and the Payment API aware local periphery, e.g., chip card (reader) may raise time-outs.
oはタイムアウトを高めることができるIOTP認識相手と支払いAPI認識ローカル周囲、例えば、チップカード（リーダー）の両方との通信を反映するプロトコルおよびAPIレベルでのタイムアウトを検出します。
However, the IOTP Payment Bridge and Existing Payment Software do not have to rely on all of these IOTP Application Core's capabilities. E.g., some Consumer's Existing Payment Software may refuse the disclosure of specific payment instruments at brand selection time and may delay this selection to the "Check Payment Possibility" invocation using its own user interface.
しかし、IOTP支払いの橋と既存の支払ソフトウェアは、これらのIOTPアプリケーションコアのすべての機能に依存する必要はありません。例えば、一部の消費者の既存の支払ソフトウェアは、ブランドの選択時に、特定の決済手段の開示を拒否することができるし、独自のユーザー・インタフェースを使用した「支払可能性を確認し、」呼び出しにこの選択を遅らせる可能性があります。
The IOTP Payment Bridge's capabilities do not only deal with actual payments between the Consumer and the Payment Handler but extend to the following:
IOTP支払いの橋の機能は、唯一の消費者と支払ハンドラが、以下に及ぶとの間の実際の支払いに対処していません。
o translation and (dis)assemblage of messages between the formats of the IOTP Payment API and those of the Existing Payment Software. Payment API requests and response are strictly 1-to-1 related.
Oの翻訳とIOTP支払いのAPIの形式と既存の支払ソフトウェアのそれらの間のメッセージの（DIS）集合。支払APIリクエストとレスポンスは、厳密に1対1に関連しています。
o Consumer's payment instrument selection by the means of an unsecured/public export of the relationship of payment brands, payment protocols, and payment instruments (identifiers). Generally, this includes not just the brand (Mondex, GeldKarte, etc.) but also which specific instance of the instrument and currency to use (e.g., which specific Mondex card and which currency of all those available).
ペイメントブランド、支払いプロトコル、および決済手段（識別子）の関係の無担保/公共の輸出によるO消費者の決済手段の選択。一般に、このことは、ブランド（モンデックス、ゲルトカルテ、等）だけでなく、器具及び通貨の特定のインスタンスを使用する（例えば、特定モンデックスカードと利用可能なすべてのこれらのどの通貨）だけでなく、を含みます。
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).
しかし、いくつかの既存の支払ソフトウェアは、実際の支払搬出に支払い機器の選択を延期するか、それも決済手段のいずれかの管理を欠いている可能性があります。検出のチップカードリーダにICカードの簡単な挿入によって支払い手段の暗黙の選択またはそれが挿入されたカードに問い合わせ及び確認（または選択）を要求する - 例えば、チップカードベースの支払い方法を提供することができる - のような販売時点を決済手段（複数可）。
o payment progress checks, e.g., is there enough funds available to carry out the purchase, or enough funds left for the refund,
O、例えば、払い戻しのための左の購入、または十分な資金を行うのに十分な資金が利用できる決済進捗の確認があり、
o IOTP Payment Receipt checks which might be performed over its Packaged Content or by other means.
そのパッケージ化されたコンテンツを介して、または他の手段によって実行される可能性がありますO IOTP支払いの領収書をチェックします。
o recoding of payment scheme specific receipts into a format which can be displayed to the user or printed,
Oユーザーに表示または印刷可能な形式に支払い方式、特定の領収書の再符号化、
o cancellation of payment, even though it is not complete,
支払いのO取消、それが完了していないにもかかわらず、
o suspension and resumption of payment transactions. Two kinds of failures the Existing Payment Software might deal with are (1) the time-out of the network connection and (2) lack of funds. For resolution, the IOTP Application Core may try the suspension with a view to later possible resumption.
Oサスペンションと支払取引の再開。既存のお支払いのソフトウェアがネットワーク接続の（1）、タイムアウトと資金の（2）不足しているに対処する可能性がある障害の二種類。解決のために、IOTPアプリケーションコアは、後述可能再開を視野に入れた懸濁液を試みることができます。
o recording the payment progress and status on a database. E.g., information about pending payments might be used to assist their continuation when the next payment protocol message is received.
Oデータベース上の決済進捗や状況を記録します。例えば、保留中の支払いについての情報は次の支払いプロトコルメッセージを受信したときに彼らの継続を支援するために使用される可能性があります。
o payment transaction status inquiry, so that the inquirer - IOTP Application Core or User - can determine the appropriate next step.
○お支払取引状況照会、照会者ように - 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).
（停電後の）起動時にこれらの保留中のトランザクションを解決するためにIOTPアプリケーションコアで使用されるかもしれない異常中断した支払取引、上のO照会。
o payment progress indication. This could be used to inform the end user of details on what is happening with the payment.
○お支払進捗表示。これは、支払いで何が起こっているかについての詳細をエンドユーザーに通知するために使用することができます。
o payment method specific authentication methods.
O支払方法の特定の認証方法。
Existing Payment Software may not provide full support of these capabilities. E.g., some payment schemes may not support or may even prevent the explicit transaction cancellation at arbitrary phases of the payment process. In this case, the IOTP Payment Bridge has to implement at least skeletons that signal such lack of support by the use of specific error codes (see below).
既存のお支払いのソフトウェアは、これらの機能の完全なサポートを提供することはできません。例えば、いくつかの支払い方式はサポートしていない可能性、あるいは決済プロセスの任意の段階で明示的なトランザクションの取り消しを防ぐことができます。この場合、IOTP支払いブリッジは、特定のエラーコード（下記参照）を用いて、支持体のこのような欠如を知らせる少なくともスケルトンで実装しなければなりません。
The Existing Payment Software's capabilities vary extremely. It
既存のお支払いのソフトウェアの機能は非常に異なります。それ
o supports payment scheme specific processing, supervision, validation, and error resolution. It is expected, that many errors are tried to be resolved first by the extended exchange of Payment Exchange messages.
oは支払制度の具体的な処理、監督、検証、およびエラーの解像度をサポートしています。多くのエラーが支払取引メッセージの拡張交換によって最初に解決しようとしていることを、期待されています。
o provides hints for out-of-band failure resolution on failed inbound resolution - inbound resolution is invisible to the IOTP Application Core.
oは失敗したインバウンド解像度にアウトオブバンド障害解決のためのヒントを提供 - インバウンド解像度はIOTPアプリケーションコアには見えません。
o may implement arbitrary transaction data management and inquiry mechanisms ranging from no transaction recording, last transaction recording, chip card deferred transaction recording, simple transaction history to sophisticated persistent data management with flexible user inquiry capabilities. The latter is required by Payment Handlers for easy and cost effective failure resolution.
O柔軟なユーザーの問い合わせ機能を持つ洗練された永続的なデータ管理にノーと取引記録に至るまで、任意のトランザクションデータの管理と照会メカニズムを実装、最後のトランザクションの記録、チップカード繰延取引記録、シンプルな取引履歴があります。後者は、簡単かつコスト効率の障害解決のための支払いハンドラによって必要とされます。
o implements the payment scheme specific dialog boxes.
oは、支払スキーム、特定のダイアログボックスを実装します。
Even the generic dialog boxes of the IOTP Application Core might be unsuitable: Particular (business or scheme) rules may require some dedicated appearance / structure / content or the dialog boxes, may prohibit the unsecured export of payment instruments, or may prescribe the pass phrase input under its own control.
IOTPアプリケーションコアのさえ、一般的なダイアログボックスが不適当であるかもしれない：特定の（ビジネスやスキーム）のルールは、いくつかの専用の出現/構造/コンテンツまたはダイアログボックスを必要とするかもしれない決済手段の無担保輸出を禁止してもよい、またはパスフレーズを定めることができます独自の制御下に入力。
The following lists all functions of the IOTP Payment API:
次のリストIOTP決済APIのすべての機能：
o Brand Compilation Related API Functions
Oブランドコンパイル関連API関数
"Find Accepted Payment Brand" identifies the accepted payment brands for any indicated currency amount.
「受け入れられた支払いブランドを探す」いずれかの指定された通貨量のために受け入れペイメントブランドを識別します。
"Find Accepted Payment Protocol" identifies the accepted payment protocols for any indicated currency amount (and brand) and returns payment scheme specific packaged content for brand selection purposes.
「受け入れられた支払いプロトコルを探す」いずれかの指定された通貨額（ブランド）のために受け入れ支払いプロトコルを識別し、ブランド選択の目的のために支払いスキーム特定のパッケージ化されたコンテンツを返します。
This function might be used in conjunction with the aforementioned function or called without any brand identifier.
この関数は、前述の機能と組み合わせて使用したり、任意のブランドの識別子なしで呼ばれるかもしれません。
"Get Payment Initialization Data" returns additional payment scheme specific packaged content for payment processing by the payment handler.
「支払いの初期化データを取得し、」支払いハンドラによって、決済処理のための追加の支払い体系特定のパッケージ化されたコンテンツを返します。
"Inquire Authentication Challenge" returns the payment scheme specific authentication challenge value.
「照会]認証チャレンジは、」決済スキーム特定の認証チャレンジ値を返します。
"Check Authentication Response" verifies the returned payment scheme specific authentication response value.
「認証応答を確認すると、」返さ決済スキーム特定の認証応答値を検証します。
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
「変更プロセスの状態は」異常終了のために（ここでのみ）使用されています。 （参照の支払い処理関連API関数を）。
o Brand Selection Related API Functions
Oブランドセレクション関連API関数
"Find Payment Instrument" identifies which instances of a payment instrument of a particular payment brand are available for use in a payment.
特定のペイメントブランドの支払い楽器のインスタンスが支払いで使用可能な識別「支払手段を探します」。
"Check Payment Possibility" checks whether a specific payment instrument is able to perform a payment.
特定の支払い機器が支払いを行うことが可能であるかどうかをチェックし、「支払いの可能性を確認してください」。
"Authenticate" forwards any payment scheme specific authentication data to the IOTP Payment Bridge for processing.
「認証」は、処理のためにIOTP支払いの橋に任意の支払い方式で特定の認証データを転送します。
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
「変更プロセスの状態は」異常終了のために（ここでのみ）使用されています。 （参照の支払い処理関連API関数を）。
o Payment Processing Related API Functions
O支払い処理関連API関数
"Start or Resume Payment Consumer/Payment Handler" initiate or resume a payment transaction. There exist specific API functions for the two trading roles Consumer and Payment Handler.
「開始または再開支払いコンシューマー/支払ハンドラ」を開始したり、支払い取引を再開する。 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
一般的な照会API関数O
"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.
お支払いハンドラから受信または「プロセスの状態を照会し、」API呼び出しによって返され、IOTP支払いの領収書の一貫性と妥当性をチェックする「支払領収書を確認してください」。通常、この機能は、支払取引の最終処理中に消費者によって呼び出されます。それにもかかわらず、このチェックは、障害解決の消費者と支払ハンドラの両方に有利であるかもしれません。
"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
他のAPI関数O
"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 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *認証問い合わせる認証チャレンジ（ALG1 *） - > IPB該Inq。認証。チャレンジ・レスポンス（ALG1、Ch1の）< - IPB。 。 。問い合わせ認証チャレンジ（Algn *） - > IPB該Inq。認証。チャレンジ・レスポンス（Algn、CHN）は< - IPBの作成と認証リクエストブロック被認証者認証（ALG1、CH1）を送信 - > IPB AuthenticateResponse（...）< - IPB。 。 。 <> IPB AuthenticateResponse（RES） - - （Algm、CHM）の認証IPB作成し、送信認証応答ブロックオーセンティケータは、認証応答（Algm、CHM、RES）を確認してください - > IPBが認証を確認してください。レスポンス（）<-IPB作成し、認証ステータスブロックを送信* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
Figure 2. Authentication Message Flows
図2認証メッセージフロー
1. (Authenticator Process) None, one or multiple IOTP Payment Bridges (IPB) are requested for one or multiple authentication challenge values ("Inquire Authentication Challenge"). Each value is encapsulated in an IOTP Authentication Request Component. In addition, the IOTP Application Core may add payment scheme independent authentication methods. All of them form the final IOTP Authentication Request Block, which describes the set of authentication methods being supported by the authenticator and from which the Authenticatee has to choose one method.
1.（認証処理）なし、一つまたは複数のIOTP支払いブリッジ（IPB）は、1つのまたは複数の認証チャレンジ値（「問い合わせる認証チャレンジ」）のために要求されません。各値はIOTP認証要求コンポーネントにカプセル化されます。また、IOTPアプリケーションコアは、決済スキームの独立した認証方式を追加することもできます。それらの全ては、認証方法のセットがオーセンティケータによって支持され、かつそこから被認証は一つの方法を選択しなければなら説明最終IOTP認証要求ブロックを形成します。
Note that the interface of the API function is limited to the response of exactly one algorithm per call. If the IOTP Application Core provides a choice of algorithms for input, this choice should be reduced successively by the returned algorithm ({Alg(i+1)*} is subset of {Algi*}).
API関数のインタフェースは、呼び出しごとに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.
受信IOTPメッセージ内IOTP認証ブロックの存在2.、被認証者のIOTPアプリケーションコアは電流位相でIOTPトランザクションタイプは、実際の認証プロセスをサポートするかどうかをチェックします。
For each provided Authentication Request Component, the IOTP Application Core analyzes the algorithms' names, the transaction context, and optionally user preferences in order to determine the system components which are capable to process the authentication request items. Such system components might be the IOTP Application Core itself or any of the registered IOTP Payment Bridges.
各提供された認証要求コンポーネントのために、IOTPアプリケーションコアは、認証要求のアイテムを処理することが可能なシステム・コンポーネントを決定するためにアルゴリズムの名前、トランザクションコンテキスト、および必要に応じてユーザの嗜好を解析します。このようなシステムコンポーネントがIOTPアプリケーションコア自体または登録IOTP支払いの橋のいずれかであるかもしれません。
Subsequently, the IOTP Application Core requests the responses to the supplied challenges from the determined system components in any order. The authentication trials stop with the first successful response, which is included in the IOTP Authentication Response Block.
その後、IOTPアプリケーションコアは、任意の順序で決定したシステムコンポーネントからの供給の課題への対応を要求します。認証試験はIOTP認証応答ブロック内に含まれる最初の成功した応答と停止します。
Alternatively, the IOTP Application might ask for a user selection. This might be appropriate, if two or more authentication algorithms are received that require explicit user interaction, like PIN or chip card insertion.
また、IOTPアプリケーションは、ユーザの選択を求めるかもしれません。二つ以上の認証アルゴリズムは、PINまたはチップカードの挿入と同様に、明示的なユーザーとの対話を必要とする受信された場合、これは、適切な場合があります。
The Authenticatee's organizational data is requested by an IOTP Authentication Request Block without any content element. On failure, the authentication (sequence) might be retried, or the whole transaction might be suspended or cancelled.
被認証者の組織データは、任意のコンテンツ要素なしIOTP認証要求ブロックで要求されています。失敗した場合、認証（シーケンス）が再試行される可能性がある、またはトランザクション全体が中断または中止される可能性があります。
3. (Authenticator Process) The IOTP Application Core checks the presence of the IOTP Authentication Response Component in the Authentication Response Block and forwards its content to the generator of the associated authentication challenge for verification ("Check Authentication Response").
3.（認証処理）IOTPアプリケーションコアは、認証応答ブロックでIOTP認証応答成分の存在を確認し、確認のために関連した認証チャレンジ（「認証応答を確認」）の発生にその内容を転送します。
On sole organizational data request, its presence is checked.
唯一の組織データ要求に、その存在が確認されています。
Any verification must succeed in order to proceed with the transaction.
任意の検証は、取引を進めるために成功しなければなりません。
The following shows how the API functions are used together so that the Merchant can (1) compile the Brand List Component, (2) generate the Payment Component, and (3) adjust the Order Component with payment scheme specific packaged content.
商人は、（1）ブランドリストコンポーネントをコンパイルし、（2）支払コンポーネントを生成し、そして（3）決済スキームの特定のパッケージ化されたコンテンツで次成分を調整できるように、API関数を一緒に使用する方法を以下に示します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *各登録IOTP支払いブリッジの商人| ）（受理支払いブランドを探す - > IPB | <受理支払いブランドレスポンス（B *）を検索 - IPBを|受け入れられる支払プロトコル（B1）を見つける - > IPB | <受理支払いプロトコルRES（P1 *）を検索 - IPBを| 。 。 。 |受け入れられる支払プロトコル（BN）を見つける - > IPB |受け入れられる支払プロトコルにRESを探す（PN *）< - IPBは、理想的には、共通のブランド、議定書の金額、通貨額、および支払プロトコル要素のブランドの独立したトランザクションで取引プロトコル・オプションブロックを作成し共有する、1つのブランドリストコンポーネントを作成します。| |暗黙のうちに、ブランド選択のコンポーネントを作成します。 |> IPB - 支払初期化データ（B1、P1）を取得お支払いの初期化データRESを取得（）< - IPB。|オプション| |プロセスの状態を問い合わせる（） - > IPB | |プロセスの状態応答（状態）<お問い合わせ - IPBを|オファー応答ブロックの送信を作成し、新しく作成されたブロック（複数可）消費者の消費者が仕事やブランド選択コンポーネントを生成しますものからブランド（BI）/通貨/プロトコル（Pjの）を選択 - 少なくとも論理的にブランド依存トランザクションで| |ブランド依存トランザクションでブランドセレクションコンポーネントの商人を送信お支払いの初期化データ（バイ、Pjの）を取得する - > IPB |お支払いの初期化データRESを取得（）< - IPB。|オプション| |プロセスの状態を問い合わせる（） - > IPB | |プロセスの状態応答（状態）<お問い合わせ - IPBを|オファー応答ブロックを作成| * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * +新しく作成されたブロックを送信* + * + * + * + * + * + * + * + * + *
Figure 3. Brand Compilation Message Flows
図3.ブランドコンパイルメッセージフロー
1. The Merchant's commerce server controls the shopping dialog with its own mechanisms until the Consumer checks out the shopping cart and indicates the payment intention. The notion shopping subsumes any non-IOTP based visit of the Merchant Trading Role's (which subsumes Financial Institutes) web site in order to negotiate the content of the IOTP Order Component. The subsequent processing switches to the IOTP based form by the activation of the Merchant's IOTP aware application.
消費者がショッピングカートをチェックアウトし、支払意思を示すまで1.商人のコマースサーバは、独自のメカニズムとショッピングダイアログを制御します。概念のショッピングはIOTP注文成分の含有量を交渉するために、商人の取引の役割の（金融機関を包含している）は、Webサイトのいずれかの非IOTPベースの訪問を包含し。その後の処理は、マーチャントIOTP対応するアプリケーションの起動によってIOTPベースのフォームに切り替わります。
2. The IOTP Application Core inquires for the IOTP level trading parameters (Consumer's shopping identifier, payment direction, initial currency amounts, discount rates, Merchant's and Delivery Handler's Net Locations, Non-Payment Handler's Organizational Data, initial order information, ....).
2. IOTPアプリケーションコアはIOTPレベルの取引パラメータ（消費者のショッピング識別子、支払い方向、初期通貨額、割引率、商人のと配信ハンドラのNet場所、非支払いハンドラの組織データ、最初の注文情報については、問い合わせる.... ）。
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.
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.
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アプリケーションコアはブランド一覧（S）成分と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は、パッケージ化されたコンテンツ要素の内容の正確なルールを欠いています。したがって、トランザクション/ブランド/プロトコル/通貨量（中）に依存するデータは、同じパッケージ化されたコンテンツ要素を共有したり、複数のパッケージ化されたコンテンツ要素に広がる可能性があります。
o The Consumer's IOTP Application Core transparently passes the Packaged Content Elements to the IOTP Payment Bridges which might not be able to handle payment scheme data of other payment schemes, accurately.
O消費者のIOTPアプリケーションコアは透過的に正確に、他の決済スキームの決済スキームのデータを処理することができない場合がありますIOTP支払いの橋にパッケージ化されたコンテンツの要素を渡します。
The rules and mechanisms of how this could be accomplished are out of the scope of this document. Furthermore, this document does not define any further restriction to the IOTP specification.
これを達成することができる方法のルールや仕組みは、この文書の範囲外です。また、この文書はIOTP仕様にさらなる制限を定義していません。
7. The IOTP Application Core determines whether the IOTP message can be enriched with an Offer Response Block. This is valid under the following conditions:
7. IOTPアプリケーションCoreはIOTPメッセージがオファー応答ブロックで強化することができるか否かを判断します。これは、以下の条件で有効です。
o All payment alternatives share the attribute values and Packaged Content Elements of the subsequently generated IOTP Payment and Order Components.
Oすべての支払い選択肢が属性値とその後に発生したIOTP支払いおよび注文コンポーネントのパッケージ化されたコンテンツ要素を共有しています。
o The subsequently generated data does not depend on any IOTP BrandSelInfo Elements that might be reported by the consumer within the TPO Selection Block in the brand dependent variant.
Oその後、生成されたデータは、ブランドに依存するバリアントでTPO選択ブロック内の消費者によって報告される可能性があります任意のIOTP BrandSelInfoの要素に依存しません。
If both conditions are fulfilled, the IOTP Application Core might request the remaining payment scheme specific payment initialization data from the IOTP Payment Bridge ("Get Payment Initialization Data") and compile the IOTP Offer Response Block.
両方の条件が満たされている場合は、IOTPアプリケーションコアはIOTP支払いの橋から、残りの支払い体系特定の支払の初期化データを要求することがあります（「支払いの初期化データの取得」）とIOTPオファー応答ブロックをコンパイルします。
Optionally, the IOTP Application Core might request the current process state from the IOTP Payment Bridge and add the inferred order status to the IOTP Offer Response Block. Alternatively, IOTP Application might determine the order status on its own.
必要に応じて、IOTPアプリケーションコアはIOTP支払いの橋から現在のプロセスの状態を要求し、IOTPオファー応答ブロックに推測され、注文ステータスが追加される場合があります。また、IOTPアプリケーションは、独自の注文状況を判断する場合があります。
As in step 6, the rules and mechanisms of how this could be accomplished are out of the scope of this document.
ステップ6のように、これを達成することができる方法のルールとメカニズムはこの文書の範囲外です。
8. The IOTP Application Core compiles the IOTP TPO Message including all compiled IOTP Blocks and transmits the message to the Consumer. The IOTP Application Core terminates if an IOTP Offer Response Block has been created.
8. IOTPアプリケーションコアは、すべてのコンパイルIOTPブロックを含む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 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *商人の商人は、ブランド、支払いプロトコルとブランドの独立した取引で通貨額を含むブランド一覧（複数可）を生成|商人は、セットごとにブランドB /プロトコルPの応答ブロック消費者のコンパイルセット（複数可）を提供生成| |> IPB - 支払手段（B、P、C）を検索支払手段レスポンス（PI *）<検索 - IPB消費者が仕事や選択のためのブランド選択のコンポーネントを生成しますものからブランド/通貨/決済手段を選択|取得支払いの初期化データ（B、C、PI、P） - > IPB | <）（支払初期化データのレスポンスを取得する - IPBのブランド依存トランザクションで|ブランド依存トランザクションでTPO選択ブロック商人を生成して送信|マーチャントチェックブランド選択と生成|そして、応答ブロック* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *を提供送信+ * + * + * + * + * + * + * + * + * + *
Figure 4. Brand Selection Message Flows
図4.ブランド選択メッセージフロー
1. The Merchant's commerce server controls the shopping dialog with its own mechanisms until the Consumer checks out the shopping cart and indicates his payment intention. The subsequent processing switches to the IOTP based form by the activation of the Merchant's IOTP aware application.
消費者がショッピングカートをチェックアウトし、彼の支払意思を示すまで1.商人のコマースサーバは、独自のメカニズムとショッピングダイアログを制御します。その後の処理は、マーチャントIOTP対応するアプリケーションの起動によってIOTPベースのフォームに切り替わります。
2. The IOTP Application Core compiles the IOTP Trading Protocol Options Block which contains the IOTP Brand List Component(s) enumerating Merchant's accepted payment brands and payment protocols and initiates the Brand Selection process.
2. IOTPアプリケーションコアは、商人の受け入れ支払いブランド、支払いプロトコルを列挙IOTPブランドリストコンポーネント（複数可）を含んでおり、ブランドの選択プロセスを開始IOTP取引プロトコル・オプションのブロックをコンパイルします。
3. This first IOTP message activates the Consumer's IOTP aware application, e.g., the Web browser invokes a helper application (e.g., Java applet or external application). Its IOTP Application Core
3.この最初のIOTPメッセージは、消費者の意識IOTPアプリケーションを起動し、例えば、Webブラウザはヘルパーアプリケーション（例えば、Javaアプレットや外部アプリケーション）を起動します。その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はすべてのセットを結合するようなブランドとプロトコルの一つまたは複数のセットをコンパイルすると、商人によって提供されている正確に支払いの選択肢を説明します。
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.
○お支払（プロトコル）をサポートし、各コンパイル済みのセットに対する各登録IOTP支払いの橋から知られている決済手段を（「支払手段を探す」）を問い合わせます。しかし、いくつかのIOTP支払いの橋は、決済手段の区別を拒否することができます。
The payment protocol support may differ between payment instruments if the IOTP Payment Bridge supports payment instrument distinction.
IOTP支払いの橋が支払い機器の区別をサポートしている場合、支払いプロトコルのサポートは、決済手段の間で異なる場合があります。
These API calls are used to infer the payment alternatives at the startup of any payment transaction (without user unfriendly explicit user interaction).
これらのAPIの呼び出しは任意の支払いトランザクションの起動時に支払いの選択肢を推測するために使用されている（ユーザー非友好的な明示的なユーザーとの対話なし）。
The IOTP Application Core must provide wallet identifiers, if they are requested by the IOTP Payment Bridges which signal their need by specific error codes (see below).
それらは特定のエラーコード（下記参照）によって彼らの必要性を知らせるIOTP支払いの橋によって要求された場合はIOTPアプリケーションコアは、財布の識別子を提供する必要があります。
It is recommended that the IOTP Application Core manages wallet identifiers. But for security reasons, it should store pass phrases in plain text only in runtime memory. Developers of IOTP
IOTPアプリケーションコアは財布識別子を管理することをお勧めします。しかし、セキュリティ上の理由から、それが唯一のランタイムメモリにプレーンテキストでパスフレーズを保存する必要があります。 IOTPの開発
Payment Bridges and payment software modules should provide a thin and fast implementation - without lengthy initialization processes - for this initial inquiry step.
支払橋と支払いソフトウェアモジュールは薄いと高速な実装を提供する必要があります - 長い初期化プロセスなし - この最初の照会ステップのために。
4. The IOTP Application Core verifies the Consumer's payment capabilities with the Merchant's accepted payment brands and currencies,
4. IOTPアプリケーションコアは、商人の受け入れペイメントブランドと通貨で消費者の支払い能力を確認します
o displays the valid payment instruments and payment instrument independent payment brands (brand and protocol) together with their purchase parameters (payment direction, currency, amount), and
O一緒に購入パラメータ（支払い方向、通貨、金額）で、有効な決済手段と決済手段の独立したペイメントブランド（ブランドとプロトコル）を表示し、
o requests the Consumer's choice or derives it automatically from any configured preferences. Any selection ties one IOTP Payment Bridge with the following payment transaction.
O消費者の選択を要求したり、設定済みの設定から自動的に導出します。任意の選択には、以下の決済取引で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.
○お支払すぐに進むことができ、いくつかの必要な物理的な決済手段（チップカード）の入出力に必要な周辺inclusiveが利用できない、O（非IOTP）相手（例えば、発行者、サーバーWallet）が利用できない、財布識別子Oまたはパスフレーズです必要に応じ、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をキャンセルする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.
この文書に記載されている関数は成功した支払いを行うために一緒に使用される方法の例は...、PS0、PS1、図5に図5に示されており、PSNがn番目PaySchemeパッケージコンテンツデータを示し、[]れますオプションを示します。
(Technically, two payments happen during IOTP Value Exchange transactions.)
（技術的には、2回の支払いはIOTPバリュー為替取引の際に起こります。）
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB Create and transmit Payment Request Block Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB Start Payment PH Response(PS2, CS=Cont.) <- IPB Create and transmit Payment Exchange Block Consumer Continue Process(PS2) -> IPB Continue Process Response(PS3, CS=Cont.) <- IPB
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費スタート支払消費者（金額、[PS0] ...） - > IPBは、お支払いの短所を開始します。 RES（[PS1]、CS =続き）< - 。IPB支払要求ブロック支払いハンドラを作成し、送信支払賃金を開始します。ハンドラ（金額、[PS1]） - > IPB支払PH応答開始します<（PS2、CS =続きを。） - IPBが支払取引ブロックの消費者を作成し、送信（PS2）プロセスを継続 - > IPBは、プロセス応答（PS3、CS =続きを続行。）< - IPB
... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
... UNTIL PAYMENT交換を交換CONTINUE ...
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
支払ハンドラは、プロセス応答（[PSnに]、CS =エンド）<続行 - IPBの要求任意のローカル領収書|プロセスの状態を問い合わせる（） - > IPB | PROCをお問い合わせください。国家Respの（状態、[RCPを使用します。]）< - 。IPBは積極的に、トランザクションを終了支払応答ブロックを作成して送信します
| Change Process State(State) -> IPB | Change PS Response(State=CompletedOK) <- IPB Consumer On receipt of final payment scheme data | Continue Process(PSn) -> IPB | Continue Process Response(CS=End) <- IPB Check Payment Receipt(Receipt) -> IPB Check Payment Receipt Response() <- IPB Request any local payment receipt | Inquire Process State() -> IPB | Inquire Proc. State Resp.(State, [Rcp.])<- IPB Terminate transaction, actively | Change Process State(State) -> IPB | Change PS Response(State=CompletedOk) <- IPB *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
|変更プロセスの状態（ステート） - > IPB |変更PS応答（状態= CompletedOK）< - 最終的な支払い方式でデータを受信するとIPBの消費者|プロセス（PSN）を続行 - > IPB | < - IPBチェック支払領収書（レシート） - > IPBチェック支払受信応答（）< - プロセス応答（CS =終了）を続行IPB要求任意のローカル領収書|プロセスの状態を問い合わせる（） - > IPB | PROCをお問い合わせください。国家Respの（状態、[RCPを使用します。]）< - IPB積極的に、トランザクションを終了します。|変更プロセスの状態（ステート） - > IPB |変更PS応答（状態= 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.
ブランド選択とIOTPオファー応答ブロック、支払ハンドラーとの通信に商人との通信から消費者スイッチの受領後1。
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支払いのブランドと先行問い合わせステップから支払い器具O IOTPブランドリストコンポーネントの選択されたブランド要素からの説明、選択された通貨額要素、ブランドリストコンポーネントからさらに支払パラメータ（通貨、金額、方向、有効期限）O、から支払プロトコルの説明の包括支払い方式で特定のデータOの特定の支払い方式で、あるかもしれないIOTP次成分に含まれる注文の詳細O選択IOTPペイプロトコル要素からの支払いプロトコル、O IOTPオファー応答ブロックのと支払いのコンポーネント、 IOTPプロトコル金額要素、およびIOTP支払いプロトコル要素、およびOの決済スキームname属性は「お支払い方法：」として接頭辞が含まれている支払プロトコルの説明、特定のデータを含め取引役割データコンポーネントから。
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アプリケーションCoreはIOTPメッセージに支払い取引ブロックの存在を確認し、次IOTP支払いスキームコンポーネントを返す固定IOTP支払いブリッジ（「プロセスを続行」）に含まれる支払い方式固有のデータを渡します。
This Payment Scheme Component is encapsulated in an IOTP Payment Exchange Block and transmitted to the Payment Handler.
この支払スキームのコンポーネントはIOTP支払い取引所のブロックにカプセル化し、支払いハンドラに送信されます。
5. The Payment Handler's IOTP Application Core verifies the presence of the Payment Exchange Block and passes the contained payment scheme specific data to the fixed IOTP Payment Bridge ("Continue Process") which returns the next IOTP Payment Scheme Component for encapsulation and transmission to the Consumer.
5.お支払いハンドラのIOTPアプリケーションコアは、（「プロセスを続行」）支払取引所のブロックの存在を確認し、固定IOTP支払いの橋に含まれる決済スキーム固有のデータを渡すにカプセル化して送信するために次のIOTP支払いスキームコンポーネントを返します消費者。
6. The payment process continues with IOTP Payment Exchange Block exchanges, carrying the payment scheme specific data. Each party (1) submits the embedded payment scheme specific data transparently to the appropriate IOTP Payment Bridge calling the "Continue Process" API function, (2) wraps the returned payment scheme specific data into an IOTP Payment Exchange Block, and (3) transmits this block to the counter party.
6.支払方法は、支払スキーム固有のデータを運ぶ、IOTP支払いの交換ブロックの交換を続行します。各当事者（1）は、「プロセスを続行」API関数を呼び出し、適切なIOTP支払橋、（2）IOTP支払い取引ブロックに返さ決済スキーム固有のデータをラップし、そして（3）送信に透過的に組み込まれた支払い体系特定のデータを提出しますカウンターパーティにこのブロック。
However, the processing of the payment scheme specific data may fail for several reasons. These are signaled by specific error codes which are transformed to IOTP Payment Response Blocks (generated by Payment Handler) or IOTP Error Blocks (both parties may generate them) and transmitted to the counter party.
しかし、決済スキーム具体的なデータの処理にはいくつかの理由で失敗することがあります。これらは、（支払いハンドラによって生成された）IOTP支払い応答ブロックまたはIOTPのエラーブロック（両当事者がそれらを発生させることができる）に変換して相手に送信されている特定のエラーコードによって通知されます。
7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes the termination of the payment transaction and reports this by the continuation status "End" on the output parameter of "Continue Process" (or "Start Payment Payment Handler"). Then, the IOTP Application Core issues the "Inquire Process State" API call and verifies whether an IOTP Payment Receipt Component has been returned. The IOTP Application Core wraps the payment receipt, the status response, and the optional payment scheme specific data in an IOTP Payment Response Block and transmits this block to the Consumer.
7.結局、支払ハンドラのIOTP支払いの橋は、「プロセスを続行」（または「支払決済ハンドラを起動します」）の出力パラメータの継続状態「終了」でのお支払いの取引の終了と報告し、これを認識しています。その後、IOTPアプリケーションコアは、「プロセスの状態を照会し、」APIコールを発行し、IOTP支払いの領収書のコンポーネントが返されたかどうかを検証します。 IOTPアプリケーションコアはIOTP支払い応答ブロックに領収書、ステータス応答、およびオプションの決済スキーム固有のデータをラップし、消費者にこのブロックを送信します。
However, any of these API calls may fail or any response might be incomplete (e.g., lack of payment receipt). Then, the Consumer has to be notified about the failed processing by an IOTP Error Block.
しかし、これらのAPI呼び出しのいずれかが失敗する可能性がありますまたは任意の応答が不完全であるかもしれない（例えば、領収書の欠如）。次に、消費者はIOTP誤差ブロックによって失敗した処理について通知する必要があります。
Finally, the Payment Handler terminates the payment transaction with the "Change Process State" API call without awaiting any further response from the Consumer. Further failures are not reported to the Consumer.
最後に、お支払いハンドラは、消費者からの任意のさらなる応答を待たずに「変更プロセス状態の」API呼び出しで支払い取引を終了します。さらに、障害は消費者に報告されていません。
Note that it might be possible that the Consumer's IOTP Payment Bridge has returned the previous payment scheme specific data with the continuation status "End". Even in the absence of this knowledge - this status is not exchanged between the Consumer and the Payment Handler - the Payment Handler must not supply any further payment scheme specific data. Such data will be rejected by the Consumer's IOTP Payment Bridge.
消費者のIOTP支払いの橋が継続状態「終了」で前回のお支払いスキーム固有のデータを返送している可能性があるかもしれないことに注意してください。でもこの知識がない状態で - 支払いハンドラはそれ以上の支払い体系特定のデータを提供してはいけません - このステータスは、消費者と支払ハンドラの間で交換されていません。このようなデータは、消費者のIOTP支払いの橋によって拒否されます。
8. The Consumer passes the optional payment scheme specific data and the payment receipt to the fixed IOTP Payment Bridge by "Continue Process" and "Check Payment Receipt" API calls.
8.消費者は、オプションの決済スキーム固有のデータと「支払領収書を確認し、」API呼び出しを「プロセスを続ける」とすることにより、固定IOTP支払いの橋への支払いの領収書を渡します。
Afterwards, the IOTP Application Core issues the "Inquire Process State" API call and verifies whether extensions to the payment receipt have been returned.
その後、IOTPアプリケーションコアは、「お問い合わせプロセス状態」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は、コンテンツデータをパッケージ化第一及び第二PaySchemeを示し、[]オプションを示しています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer Start Payment Inquiry() -> IPB Start Payment Inquiry Response([PS1]) <- IPB Create and transmit Inquiry Request Trading Block Payment Handler Inquire Payment Status([PS1]) -> IPB Inquire Payment Status Res.(State, [PS2]) -> IPB Create and transmit Inquiry Response Trading Block Consumer If Payment Scheme Data present | Continue Process(PS2) -> IPB | Continue Process Response(CS=End) <- IPB Change Process State(State) -> IPB Change Process State Response(State) <- IPB *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費スタート支払お問い合わせ（） - > IPBが支払照会応答（[PS1]）<を開始 - IPBの作成と送信問い合わせ要求取引ブロック支払いハンドラは、（支払い状況をお問い合わせ[ PS1]） - > IPBに問い合わせるの支払い状況RES（州、[PS2]） - > IPB問い合わせレスポンス取引を作成し、送信ブロックの消費者支払スキームのデータが存在する場合。|プロセス（PS2）を続行 - > IPB | < - IPBの変更プロセスの状態（ステート） - > IPB変更処理状態応答（状態）< - IPB * + * + * + * + * + * + * + * + * + * +プロセス応答（CS =終了）続行* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
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.
支払い取引がIOTP支払い要求ブロックの初期提出後の任意の時点で、すなわち、IOTPアプリケーションコアによって開かれた後1.消費者は支払い問い合わせを開始する可能性があります。 IOTPアプリケーションコアは「支払お問い合わせを起動し、」API要求を使用して、ブランドの選択（節参照2.3）の間に固定された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アプリケーションCoreは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").
それぞれのIOTP問い合わせ応答ブロックを受け取る3.は、消費者の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輸送、メッセージやブロックレベルのエラー深〇〇ビジネスと技術的なエラー。
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関数呼び出し「に問い合わせるプロセスの状態」の発行により、更なる詳細を推測することがあります。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *締約国の問題いくつかのAPIリクエスト - > IPBエラー応答（エラーコード）< - "ビジネスエラー" 応答にIPB |プロセスの状態を問い合わせる（） - > IPB | P.S.を問い合わせますRESP（州、領収書）< - IPBローカルプロセスの状態を分析し、プロセス状態変更が必要な場合は、オプションのユーザーとの対話で解決してみてください。|変更プロセスの状態（ステート） - > IPB |変更処理状態応答（状態）< - IPBカウンターパーティの通知が必要な場合| * + * + * + * + * + * + * + * + * + * + * + * + * + * + * +と党に対抗するためにそれを伝える|エラーを作成するか、またはブロックをキャンセル（メッセージ、次に追加） * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
Figure 7. Error Response from IPB
IPBから図7.エラー応答
The specific Completion Codes "ConsCancelled", "MerchCancelled", and "PaymCancelled" - returned by "Inquire Process State" - determine that the IOTP Cancel Block has to be created instead of an IOTP Error Block.
特定の完了コード「ConsCancelled」、「MerchCancelled」、および「PaymCancelled」 - 「プロセスの状態を問い合わせ」によって返さ - IOTPはブロックがIOTPエラーブロックの代わりに作成する必要があり、キャンセルすることを決定。
The rules for determining the required behavior of the IOTP Application Core are given in the IOTP specification.
IOTPアプリケーションコアの必要な動作を決定するための規則はIOTP仕様で与えられています。
Note that any payment (intermediate) termination, i.e., failures, cancellations, and even successes are always reported to the IOTP Payment Bridge by the API function "Change Process State". This API function does both status changes and consistency checking / synchronization. Any suspicion of inconsistency should be reported by the IOTP Payment Bridge for display by the IOTP Application Core.
任意の支払い（中間）終了、すなわち、失敗、キャンセル、とさえ成功は常にAPI機能「の変更プロセスの状態」によるIOTP支払橋に報告されていることに注意してください。このAPI関数は、ステータスの変化との整合性チェック/同期の両方を行います。矛盾の任意の疑いがIOTPアプリケーションコアによる表示のためにIOTP支払いブリッジによって報告されるべきです。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Any Party Error Block or Cancel Block Received If Change Process State required | Change Process State (State) -> IPB | Change Process State Response(State) <- IPB *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *どれパーティーエラーブロックまたはブロックをキャンセル変更プロセスの状態が必要な場合は受信|変更プロセスの状態（ステート） - > IPB |変更処理状態応答（状態）< - IPB * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *
Figure 8. Error Notification from counter party
相手から図8.エラー通知
Not every failure might be visible at the IOTP layer, e.g., the processing of payment transactions might temporarily be hampered by intermediate failures at the payment scheme or protocol transport layer which might be resolved by the actual components.
すべての障害がIOTP層で目に見えるかもしれない、例えば、支払取引の処理が一時的に実際の構成要素によって解決されるかもしれない支払方式やプロトコルトランスポート層で中間障害によって妨げられる可能性があります。
However, final failures or cancellations have to be reported at the IOTP layer. E.g., communication time-outs and heavily faulty communication channels may disable the transaction.
しかし、最終的に失敗やキャンセルはIOTP層で報告する必要があります。例えば、通信タイムアウトと重く障害のある通信チャネルは、トランザクションを無効にすることがあります。
Any system component may implement time-out recognition and use the aforementioned API mechanisms for the notification of process state changes. But, time-outs may happens while communicating with both the counter party and local system components, like chip card readers or IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core should notify the Consumer about the resolution alternatives, i.e., retry, suspension, and cancellation.
すべてのシステムコンポーネントはタイムアウトの認識を実装し、プロセスの状態変化を通知するため、前述のAPIメカニズムを使用してもよいです。しかし、タイムアウトかもしれチップカードリーダーやIOTP支払いの橋のように、カウンターパーティとローカルのシステム・コンポーネントの両方と通信しながら起こります。とにかく、消費者のIOTPアプリケーションコアは、すなわち、解像度の選択肢について消費者に通知しなければならないサスペンション、キャンセル、再試行してください。
Payment transaction resumption may apply at different steps of a payment transaction:
支払取引再開は、支払いトランザクションの異なる段階で適用される場合があります。
o The Consumer's and Payment Handler's view of the transaction might not be synchronized: Due to different time-out values the payment transaction may not have been suspended by the counter party.
トランザクションの消費者と支払いハンドラのビューoを同期していない可能性があります：により異なるタイムアウト値に決済取引は、カウンターパーティによって中断されていない可能性があります。
Any "Resume Payment ..." API function responds with an Error Code on non-suspended payment transaction that signals a business error. Afterwards the IOTP Application Core has to issue the "Inquire Process State" API call for further analysis of the process state.
どれでも「お支払いを再開...」API関数は、ビジネス・エラーを通知する非中断支払い取引上のエラーコードで応答します。その後IOTPアプリケーションコアは、プロセスの状態をさらに分析するために、「プロセスの状態を照会し、」APIコールを発行する必要があります。
o One IOTP message sent by one party might not be processed successfully or even received by the counter party. This needs to be handled by the actual payment scheme. It is expected that the IOTP Application Core will not recognize anything.
O一方の当事者によって送られた一つのIOTPメッセージは正常に処理され、さらには相手によって受信されない場合があります。これは、実際の支払方式で処理する必要があります。 IOTPアプリケーションコアは何も認識しないことが期待されます。
o IOTP does not provide any specific signal for payment resumption. On receipt of every IOTP Payment Exchange Block, the IOTP Application Core has to decide whether this Block belongs to a pending transaction or to a suspended transaction that should be resumed. The IOTP Application Core might call the "Inquire Process State" API function to update any lack of knowledge.
O IOTPは支払再開のための任意の特定の信号を提供していません。すべてのIOTP支払い取引所のブロックを受信すると、IOTPアプリケーションコアは、このブロックが保留トランザクションまたは再開されなければならない中断されたトランザクションに属しているかどうかを決定しなければなりません。 IOTPアプリケーションコアは、知識の欠如を更新するために、「プロセスの状態を照会し、」API関数を呼び出すことができます。
Any "Resume Payment" API function responds with an Error Code on non-suspended payment transaction that signals a business error. Similar, the "Continue Process" API function should report business errors on non-pending payment transactions.
どれでも「お支払いを再開」API関数は、ビジネス・エラーを通知する非中断支払い取引上のエラーコードで応答します。同様に、「続行プロセス」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).
支払い取引○お支払ハンドラで作成された（早期中止とデータ送信を失敗した）されていないかもしれません。その場合には、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.
IOTPアプリケーションコアoを常に再開に新鮮な決済スキームの特定のデータを要求しなければならない - 既存の支払ソフトウェアとの同期のために。カウンターパーティに送信されていないキャッシュ内の古いデータにアクセスするべきではありません。
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).
ユーザの要求に保留中のトランザクション（：一つ以上のIOTP支払いの橋は、保留中のトランザクションの存在を報告した場合、IOTPアプリケーションコアは、（「変更プロセスの状態」）を中断しようとするかもしれ2.または履歴書（「支払消費の再開」のみ消費者） ）。
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 |
<！ELEMENT IotpPaymentApiRequest（FindAcceptedPaymentBrand | FindAcceptedPaymentProtocol | GetPaymentInitializationData | FindPaymentInstrument | CheckPaymentPossiblity | StartPaymentConsumer | StartPaymentPaymentHandler | ResumePaymentConsumer | ResumePaymentPaymentHandler | ContinueProcess | InquireProcessState | ChangeProcessState | InquireAuthChallenge |認証|
CheckAuthResponse | CheckPaymentReceipt | ExpandPaymentReceipt | RemovePaymentLog | PaymentInstrumentInquiry | InquirePendingPayment | ManagePaymentSoftware | StartPaymentInquiry | InquirePaymentStatus | CallBack )>
CheckAuthResponse | CheckPaymentReceipt | ExpandPaymentReceipt | RemovePaymentLog | PaymentInstrumentInquiry | InquirePendingPayment | ManagePaymentSoftware | StartPaymentInquiry | InquirePaymentStatus |コールバック）>
<!ATTLIST IotpPaymentApi xml:lang NMTOKEN #IMPLIED ContentSoftwareID CDATA #IMPLIED xmlns CDATA #FIXED "http://www.iotp.org/2000/08/PaymentAPI" >
<！ATTLIST IotpPaymentApiのXML：CDATA #FIXEDのxmlnsのlang NMTOKEN #IMPLIED ContentSoftwareID CDATA #IMPLIED "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 )?)>
<！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））>？
<!ATTLIST IotpPaymentApiResponse xml:lang NMTOKEN #IMPLIED ContentSoftwareID CDATA #IMPLIED xmlns CDATA #FIXED "http://www.iotp.org/2000/08/PaymentAPI" >
<！ATTLIST IotpPaymentApiResponseのXML：CDATA #FIXEDのxmlnsのlang NMTOKEN #IMPLIED ContentSoftwareID CDATA #IMPLIED "http://www.iotp.org/2000/08/PaymentAPI">
<!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) > <!ATTLIST ErrorResponse xml:lang NMTOKEN #IMPLIED ErrorCode NMTOKEN #REQUIRED ErrorDesc CDATA #REQUIRED Severity(Warning | TransientError | HardError) #REQUIRED MinRetrySecs CDATA #IMPLIED SwVendorErrorRef CDATA #IMPLIED >
<！ELEMENTはErrorResponse（ErrorLocation +、PaySchemePackagedContent *）> <！ATTLISTのはErrorResponseのXML：LANG NMTOKEN #IMPLIEDのErrorCode NMTOKEN #REQUIRED ErrorDesc CDATA #REQUIRED重大度（警告| TransientError | HardError）#REQUIRED MinRetrySecs CDATA #IMPLIED SwVendorErrorRef CDATA #IMPLIED>
Most of the attribute items are intended for immediate insertion in the IOTP Error Block. The attribute values of the Error Location elements attribute have to enriched and transformed into Error Location Elements of the Error Component (cf. IOTP Specification).
属性項目のほとんどはIOTP誤差ブロックで即時挿入するために意図されています。エラー位置要素は属性の属性値が富化されたとエラー成分（参照IOTP仕様）のエラーロケーション要素に変換しなければなりません。
Attributes (cf. IOTP Specification):
属性（参照IOTP仕様）：
xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element.
XML：XMLで上書きされない限りlangは、このコンポーネント内の属性または子要素で使用する言語を定義します：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は、要素の内容を生成したソフトウェアを特定する情報が含まれています。その目的は、異なるソフトウェアによって生成されたメッセージの間の非互換性の結果として発生する可能性のある相互運用性の問題を解決することです。それは「：LANG XML」によって定義された言語での単一のテキスト文字列です。これは、結果として発生する可能性のある最小の問題として、含まれている必要があります
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.
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.
LANG：ErrorDescは、XMLで定義された言語で、エラーの説明が含まれています。この属性の内容は、エラー応答エレメントを生成したソフトウェアのベンダー/開発者によって定義されます。これは、ユーザーが表示するためのものと、障害とその（アウト・オブ・バンド）解像度の選択肢についての詳細な説明を提供しています。
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 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.
TransientError O。これは、「名前」属性によって参照されるとエラーにメッセージが再送される場合は、エラーメッセージ中にエラーが回復することができることを示しています。
o HardError. This indicates that there is an unrecoverable error in the message in error and the IOTP Transaction must stop.
HardError 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.
「重要度」を「TransientError」に設定されている場合MinRetrySecsは、この属性は存在しなければなりません。これは、エラーを報告するメッセージを受け取ったIOTP対応アプリケーションは、「ErrorLocation」属性によって識別されるエラーでメッセージを再送信するまで待つ必要があり、全体の秒数の最小値です。
If Severity is not set to
"TransientError" then the value of this
attribute is ignored.
SwVendorErrorRef This attribute is a reference whose value is set by the vendor/developer of the software that generated the Error Element. It should contain data that enables the vendor to identify the precise location in their software and the set of circumstances that caused the software to generate a message reporting the error.
SwVendorErrorRefこの属性は、値が要素のエラーを生成したソフトウェアのベンダー/開発者によって設定された基準です。それは彼らのソフトウェアの正確な位置及びソフトウェアがエラーを報告するメッセージを発生させる状況のセットを識別するためにベンダーを可能にするデータを含むべきです。
Content:
コンテンツ：
ErrorLocation This identifies, where possible, the element and attribute in the message in error that caused the Error Element to be generated. If the "Severity" of the error is not "TransientError", more that one "ErrorLocation" may be specified as appropriate depending on the nature of the error and at the discretion of the vendor/developer of the IOTP Payment Bridge.
ErrorLocationこれは、可能な場合、エラー要素が生成される原因となったエラーでメッセージ内の要素と属性を識別する。エラーの「重要度」は「TransientError」、つ以上の「ErrorLocation」でない場合は、エラーの性質とIOTP支払いの橋のベンダー/開発者の裁量に応じて適宜指定することができます。
Its definition coincides with the
IOTP specification whereby the
attributes "IotpMsgRef", "BlkRef" and
"CompRef" are left blank,
intentionally.
PaySchemePackagedContent cf. Table 5
PaySchemePackagedContent参照表5
The following table lists the valid values for the ErrorCode attribute of the Error Response Element. The first sentence of the error description contains the default text that can be used to describe the error when displayed or otherwise reported. Individual implementations may translate this into alternative languages at their discretion. However, not every error code may apply to every API call. An Error Code must not be more than 14 characters long. The Error Codes have been taken from the IOTP Specification and extended by some additional codes which are highlighted by a preceding asterisk.
次の表は、エラー応答エレメントののErrorCode属性の有効な値を示しています。エラーの説明の最初の文が表示されるか、そうでない場合は報告されたときにエラーを記述するために使用することができ、デフォルトのテキストが含まれています。個々の実装は、その裁量で代替言語にこれを翻訳することができます。ただし、すべてのエラー・コードは、すべてのAPIコールに適用されることがありません。エラーコードは、15文字以上の長であってはなりません。エラーコード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アプリケーションCoreはIOTP支払いブリッジによって省略されErrorLocation要素内の属性と値を追加することができます。
The following table mentions any modification from this general processing for particular error values. Furthermore, it contains hints for developers of IOTP Application Core software components about the processing of error codes. Conversely, developers of IOTP Payment Bridges get impressions about the expected behavior of the IOTP Application Core.
次の表は、特定のエラー値は、この一般的な処理からの任意の修飾に言及しています。さらに、それはエラーコードの処理に関するIOTPアプリケーションコア・ソフトウェア・コンポーネントの開発者のためのヒントが含まれています。逆に、IOTP支払いの橋の開発者は、IOTPアプリケーションコアの予想される動作についての感想を取得します。
The IOTP Payment API assumes that the IOTP Application Core implements the dialog boxes needed for error resolution. But it does not assume, that the IOTP Payment Bridge actually relies on them. Instead, the IOTP Payment Bridge may try resolution on its own, may implement specific dialog boxes, and may signal only final failures.
IOTP支払いAPIはIOTPアプリケーションコアは、エラーの解決のために必要なダイアログボックスを実装していることを前提としています。しかし、それはIOTP支払いの橋が実際にそれらに依存していることを、想定していません。代わりに、IOTP支払いの橋は、特定のダイアログボックスを実装することができ、自分自身で解決を試みることが、唯一の最後の障害を知らせることができます。
Note: This abstract document assumes that the API parameters are exchanged XML encoded. Therefore, several error values might disappear in lower level language specific derivations.
注意：この抽象ドキュメントはAPIのパラメータは、XMLエンコードに交換されることを前提としています。そのため、いくつかのエラー値は、低いレベルの言語固有の派生で消えるかもしれません。
Error Value Error Description
----------- -----------------
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.
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).
The IOTP Application Core has to replace the error code with "XmlNotValid" before transmission to the counterparty.
IOTPアプリケーションコアは、相手方への送信前に「XmlNotValid」とのエラーコードを交換する必要があります。
ElUnexpected Unexpected element. Although the XML document is well formed and valid, an element is present that is not expected in the particular context according to the rules and constraints contained in this specification.
ElUnexpected予期しない要素。 XML文書が十分に形成され、有効であるが、要素は、本明細書に含まれている規則と制約に応じて特定の文脈で予想されていない存在です。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
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.
The ElementRef attributes of ErrorLocation elements might refer to the corresponding elements (if they have ID attributes).
ElementRefが対応する要素を参照するかもしれないErrorLocation要素の属性（彼らはID属性を持っている場合）。
ElMissing Element missing. Although the document is well formed and valid, an element is missing that should have been present if the rules and constraints contained in this specification are followed.
ElMissing要素が欠落しています。文書がうまく形成されており、有効ですが、要素は、この仕様書に含まれているルールと制約に従っている場合はそれが存在しているはずがありません。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
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要素内容違法。文書が整形して有効であるが、要素は、この仕様書に含まれているルールと制約を準拠していない値が含まれています。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
element (if they have ID attributes).
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アプリケーションコアはErrorLocation要素が非PackagedContent要素を参照する場合、相手先に送信される前に「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).
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.
予期しない属性をAttUnexpected。 XML文書がうまく形成され、有効なされているが、属性の存在は、本明細書に含まれているルールと制約に応じて、特定のコンテキストでは期待されていません。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
(*)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.
The IOTP Application Core has to replace the error code with "XmlNotValid" before transmission to the counter party.
IOTPアプリケーションコアは、相手への送信前に「XmlNotValid」とのエラーコードを交換する必要があります。
AttNotSupp Attribute not supported. Although the XML document is well formed and valid, and the presence of the attribute in an element is consistent with the rules and constraints contained in this specification, it is not supported by the IOTP Aware Application which is processing the IOTP Message.
AttNotSuppはサポートされていない属性。 XML文書が十分に形成され、有効な、及び要素内の属性の存在がルール及び本明細書に含まれる制約と一致しているが、それはIOTPメッセージを処理しているIOTP対応のアプリケーションによってサポートされていません。
AttMissing Attribute missing. Although the document is well formed and valid, an attribute is missing that should have been present if the rules and constraints contained in this specification are followed.
不足している属性をAttMissing。文書がうまく形成されており、有効ですが、属性は、この仕様書に含まれているルールと制約に従っている場合はそれが存在しているはずがありません。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
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:
BrandId: illegal/unknown Brand Identifier - If the brand is not recognized/known by any IOTP Payment Bridge, the IOTP Application Core may offer the registration of a new Payment Instrument.
BrandId：違法/未知のブランド識別子 - ブランドはどんなIOTP支払いの橋で知ら/認識されない場合は、IOTPアプリケーションコアは、新たな支払手段の登録を提供することがあります。
PaymentInstrumentId: illegal/unknown Payment Instrument Identifier - This indicates a serious communication problem if the attribute value has been reported by the same "wallet" on a previous inquiry requests. The IOTP Application Core has to replace the error code with "UnknownError" before transmission to the counter party.
PaymentInstrumentId：違法/未知の支払手段識別子 - 属性値が前の照会要求に同じ「財布」で報告されている場合、これは深刻なコミュニケーションの問題を示しています。 IOTPアプリケーションコアは、相手への送信前に、「ないUnknownError」でエラーコードを交換する必要があります。
WalletId: illegal/unknown Wallet Identifier - It is assumed that the wallet identifier is checked before the pass phrase. On invalid wallet identifiers, the IOTP Application Core may open the dialog in order to request the correct wallet identifier. In addition, any pass phrase may be supplied by the user. The dialog should indicate the respective payment brand(s). The IOTP Application Core has to replace the error code with "UnknownError" before transmission to the counter party.
WalletId：違法/不明ウォレット識別子を - 財布識別子がパスフレーズ前にチェックされているものとします。無効な財布識別子では、IOTPアプリケーションコアは正しい財布識別子を要求するためにダイアログを開くことができます。加えて、任意のパスフレーズは、ユーザによって供給されてもよいです。ダイアログには、各ペイメントブランド（複数可）を示す必要があります。 IOTPアプリケーションコアは、相手への送信前に、「ないUnknownError」でエラーコードを交換する必要があります。
Passphrase: illegal/unknown Pass Phrase - The IOTP Application Core may open the dialog in order to request the correct pass phrase. If the pass phrase is wallet identifier specific the dialog should display the wallet identifier. The IOTP Application Core has to replace the error code with "TransportError" before transmission to the counter party.
パスフレーズ：違法/未知のパスフレーズ - IOTPアプリケーションコアは、正しいパスフレーズを要求するためにダイアログを開くことができます。パスフレーズは、特定の財布識別子である場合、ダイアログは財布識別子が表示されます。 IOTPアプリケーションコアは、相手への送信前に「TransportError」とのエラーコードを交換する必要があります。
Action: illegal / unknown / unsupported Action
処置：無効/不明/サポートされていないアクション
PropertyTypeList: lists contains illegal / unknown / unsupported Property Types - The IOTP Application Core tries only the local resolution but does never transmit any IOTP Error Block to the counter party.
PropertyTypeList：リストは違法/不明/サポートされていないプロパティタイプが含まれている - IOTPアプリケーションコアは、ローカル解決をしようとしますが、相手にどんなIOTP誤差ブロックを送信することはありませんありません。
CurrCode: illegal/unknown/unsupported Currency Code
CurrCode：違法/不明/サポートされていない通貨コード
CurrCodeType: illegal/unknown/unsupported Currency Code Type
CurrCodeType：違法/不明/サポートされていない通貨コードの種類
Amount: illegal/unknown/unsupported Payment Amount
金額：違法/不明/サポートされていないお支払い額
PayDirection: illegal/unknown/unsupported Payment Direction
PayDirection：違法/不明/サポートされていないお支払いディレクション
ProtocolId: illegal/unknown/unsupported Protocol Identifier
ProtocolId：違法/不明/サポートされていないプロトコル識別子
OkFrom: illegal/unknown/unsupported OkFrom Timestamp
OkFrom：違法/不明/サポートされていないOkFromタイムスタンプ
OkTo: illegal/unknown/unsupported OkTo Timestamp
OkTo：違法/不明/サポートされていないOkToタイムスタンプ
ConsumerPayId: illegal/unknown Consumer Payment Identifier
ConsumerPayId：違法/未知の消費者の支払い識別子
PaymentHandlerPayId: illegal/unknown Payment Handler Payment Identifier
PaymentHandlerPayId：違法/未知の支払いハンドラ支払い識別子
PayId: illegal/unknown Payment Identifier
PayId：違法/未知の支払い識別子
AttValNotRecog Attribute Value Not Recognized. The attribute contains a value which the IOTP Aware Application generating the message reporting the error could not recognize.
AttValNotRecog属性値が認識されません。属性はIOTP Awareのアプリケーションが認識できなかったエラーを報告するメッセージを生成する値が含まれています。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
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.
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:
ElInconsistent要素に一貫性がありません。文書は、この仕様書に含まれているルールと制約に応じて、十分に形成され、有効ではあるが。
o the content of an element is inconsistent
with the content of other elements or
their attributes, or
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.
ErrorLocation要素が矛盾している、対応する属性タグまたは要素を参照する場合があります。
TransportError Transport Error. This error code is used to indicate that there is a problem with the transport mechanism that is preventing the message from being received. It is typically associated with a "Transient Error".
TransportErrorトランスポートエラーが発生しました。このエラーコードは、受信されるメッセージを妨げている搬送機構に問題があることを示すために使用されます。これは、典型的には、「一時的なエラー」に関連しています。
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メッセージが処理されています。このエラーコードは、のみ一時的なエラーの重大度で使用されます。応答が「MinRetrySecs」属性で示される時間によって受信されない場合、それは、交換メッセージまたはリクエストメッセージとすることができる前のメッセージが、処理されていることを示していると、元のメッセージを再送信すべきです。
SystemBusy System Busy. This error code is only used with a Severity of Transient Error. It indicates that the IOTP Payment Bridge or Existing Payment Software that received the API request is currently too busy to handle it. If no response is received by the time indicated by the "MinRetrySecs" attribute, then the original message should be resent.
SystemBusyシステムビジー。このエラーコードは、のみ一時的なエラーの重大度で使用されます。それはIOTP支払いの橋やAPIリクエストを受け、既存の支払ソフトウェアがそれを処理するために、現在ビジー状態であることを示しています。応答が「MinRetrySecs」属性で示される時間によって受信されない場合、元のメッセージを再送信すべきです。
The Error Description may provide further
explanations, e.g., "wallet / chip card
reader is unavailable or locked by another
payment transaction", "payment gateway is
overloaded", "unknown chip card reader", or
"unrecognized chip card inserted, change
chip card".
The Consumer's IOTP Application Core may display the error description and ask the Consumer about the continuation - alternatives are retry, payment transaction suspension, and cancellation.
消費者のIOTPアプリケーションコアは、エラーの説明を表示し、継続についての消費者を求めることができる - の選択肢が支払い取引停止、キャンセル、再試行しています。
UnknownError Unknown Error. Indicates that the transaction cannot complete for some reason that is not covered explicitly by any of the other errors. The Error description attribute should be used to indicate the nature of the problem.
ないUnknownError不明なエラー。トランザクションは、他のエラーのいずれかによって明示的に覆われていない何らかの理由で完了できないことを示します。エラーの説明属性は、問題の性質を示すために使用されなければなりません。
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」または「ないUnknownError」でエラーコードを交換する必要があります。
(*)ReqRefused Request refused. The API request is (currently) refused by the IOTP Payment Bridge. The error description may provide further explanations, e.g., "wallet / chip card reader is unavailable or locked by another payment transaction", "payment gateway is overloaded", "unknown chip card reader", or "unrecognized chip card inserted, change chip card".
（*）ReqRefused要求を拒否しました。 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".
(*)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支払Bridgeで実装されていません。一般的に、この種のエラーは、カウンターパーティのIOTPアプリケーションコアに渡されていません。それ以外の場合は、「TransportError」または「ないUnknownError」にマッピングします。
(*)BusError Business Error. The API request has been rejected because some payment transaction has an illegal payment status. Particularly, this error code is used to signal any raise of payment business layered failures.
（*）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）がAmountFrom（11）全体と通貨の端数単位で支払うべき支払額を示します。例えば、$ 245.35のためにAmountTo（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。
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.
BrandLogoNetLocn The net location which can be used to download the logo for the organization (cf. IOTP Specification).
組織（参照IOTP仕様）のロゴをダウンロードするために使用することができますBrandLogoNetLocnネットロケーション。
The content of this attribute must conform
to [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.
新しい名称は、これは、ブランド、例えば「マスターカードクレジット」の名前が含まれています。これは「：LANG XML」によって定義された消費者の言語で消費者に表示されているブランドの説明です。例えば、それは、「アメリカン航空メリットビザ」であるかもしれません。この属性は、消費者が保有する決済手段に対して照合に使用されていないことに注意してください。
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.
CompletionCode（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.,
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.
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。その目的は、異なるソフトウェアによって生成されたメッセージの間の非互換性の結果として発生する可能性のある相互運用性の問題を解決することです。 LANG：これは、XMLで定義された言語での単一のテキスト文字列です。それは最低限として、含まれている必要があります：
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.
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].
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.
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.
唯一のパッケージ化されたコンテンツ要素がある場合は、「名前」属性は、たとえば、省略することができます。
OkFrom (30) The date and time in UTC Format range OkTo (30) indicated by the merchant in which the Payment Handler may accept the payment. For more information, see [UTC].
OkFrom（30）支払ハンドラが支払いを受け入れる可能性のある商人で示されるUTCフォーマット範囲OkTo（30）で日付と時刻。詳細については、[UTC]を参照してください。
Passphrase (32) Payment wallets may use pass phrase protection for transaction data and payment instruments' data. However, it is assumed that there exists a public and customizable payment instrument identifier such that these identifiers together with their relationship to payment brands, payment protocols, payment directions, and currency amounts can be queried by the IOTP application without any pass phrase knowledge.
パスフレーズ（32）支払財布は、トランザクションデータと決済手段のデータのためのパスフレーズの保護を使用することができます。しかし、公共およびカスタマイズ可能な決済手段の識別子が存在することが想定されるペイメントブランド、支払いプロトコル、支払い方向、および通貨の金額との関係と一緒にこれらの識別子は、任意のパスフレーズの知識がなくてもIOTPアプリケーションによって照会することができるようになっています。
PayDirection Indicates the direction in which the payment for which a Brand is being selected is to be made. Its values may be:
PayDirectionはブランドが選択されているために支払いが行われるべき方向を示しています。その値は次のようになります。
o Debit: The sender of the Payment Request
Block (e.g., the Consumer) to which this
Brand List relates will make the payment
to the Payment Handler, or
o 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 The Merchant has to identify PayId and MerchantPayId.
O商人はPayIdと商人PayIdを識別することがあります。
o The Payment Handler has to identify PayId and Payment Handler Pay Id.
○お支払ハンドラはPayIdと支払いハンドラペイ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.
、別の支払いスキームコンポーネントまたは他の手段によって消費者によって返された場合、参照されている支払いを識別するために支払いハンドラを可能にする（14）支払いハンドラによって指定された一意の識別子をPaymentHandlerPayId。それが知られるたびにそれが必要です。
Cf. To "ConsumerPayId" for note about
uniqueness.
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.
特定の支払い（32）楽器、例えば、「クレジットカード」、「英語のポンドのためのモンデックスカード」の識別子をPaymentInstrumentId。この識別子は、完全にカスタマイズ可能です。それが機密情報またはそれさえ表示を含んでいないことを、想定しています。支払い機器識別子は、各ペイメントブランド内で一意です。これは、ブランドの選択時に消費者に表示されます。
PayReceiptNameRefs Optionally contains element references to (32) other elements (containing payment scheme specific data) that together make up the receipt. Note that each payment scheme defines in its supplement the elements that must be referenced
PayReceiptNameRefs必要に応じて一緒に領収書を構成する（32）他の要素（支払い方式固有のデータを含む）への要素の参照が含まれています。各支払い方式はそのサプリメントで参照しなければならない要素を定義することに注意してください
The IOTP Application Core should save all
the components referenced so that the
payment receipt can be reconstructed when
required.
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.
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.
PERCENTCOMPLETE支払取引の進捗状況を示す0と100との間の（3）数。値は、保留中の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 InProgress. The payment transaction is pending. The processing of the (Payment) Request Block has started but it is not yet complete.
InProgress 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.
CompletedOk 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.
ProcessError O。状況コンポーネントは、問い合わせ要求貿易ブロックに関連して使用されている場合、この値はのみ使用されます。これは、処理されている要求ブロックにおける技術的なエラーまたは何らかの内部処理エラーがあったことを示します。各当事者のIOTP支払いの橋は、技術的なエラーの存在についてIOTPアプリケーションコアを通知するために、この値を使用しています。
PropertyType (14) The property type defines codes used for interrogation of specific properties about a payment instrument. They are unique for each payment brand. The predefined property "all" is used on general inquiries. However, these property types are not used during normal payment processing. E.g., they may apply to payment brand specific transactions or out-of-band failure resolution.
PropertyTypeは（14）プロパティタイプは、支払機器に関する特定のプロパティの問い合わせのために使用されるコードを定義します。彼らは、各ペイメントブランドのためにユニークです。事前に定義されたプロパティ「すべて」は、一般の問い合わせに使用されています。しかし、これらのプロパティタイプは、通常の支払処理中に使用されていません。例えば、彼らは、ペイメントブランド特定の取引またはアウトオブバンド故障解像度に適用される場合があります。
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でどのように機能するかを説明し、「ProtocolId」で識別される支払プロトコルのためのサプリメントで定義されています。識別子は、最大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」、「イー」。有効な値はIOTP仕様にサプリメントで定義されていると、彼らは、各ペイメントブランド内で一意です。
ProtocolIds A sequence of Protocol Identifiers
ProtocolIdsプロトコル識別子のシーケンス
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.
「：LANG XML」によって識別された言語で物語の支払プロトコルの説明とそのバージョンをProtocolName。たとえば、「電子取引のバージョン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.
The content of this attribute must conform to [URL].
この属性の内容は、[URL]に従わなければなりません。
ReceiverOrgId The Organization Identification which receives the payment bridge processing Trading Role Data PackagedContent.
支払ブリッジ処理取引の役割データPackagedContentを受ける組織の識別をReceiverOrgId。
StatusDesc (256) An optional textual description of the current process state in the language identified by "xml:lang" that should be displayed to the Consumer. The usage of this attribute is defined in the payment supplement for the payment method being used. Particularly, it provides hints for out-of-band failure resolution. Its length is limited to 256 characters.
StatusDesc（256）「のxml：langの」によって識別される言語で、現在のプロセスの状態のオプションのテキスト記述消費者に表示されるべきです。この属性の使用は、使用されている支払方法のための支払サプリメントで定義されています。特に、アウトオブバンド障害解決のためのヒントを提供します。その長さは256文字に制限されています。
StyleSheetNetLocn This contains the net location to a style sheet with visualisation rules for XML encoded data.
StyleSheetNetLocnこれは、XMLにエンコードされたデータの可視化ルールにスタイルシートへのネットの場所が含まれています。
TimeStamp (30) The date and time in UTC Format when the payment transaction has been started. For more information on UTC, see [UTC].
タイムスタンプ（30）支払い取引が開始されたUTC形式で日付と時刻。 UTCの詳細については、[UTC]を参照してください。
WalletId (32) Many existing payment wallet software are multiple wallet capable. The Wallet Identifier selects the actual wallet. It is assumed, that the wallet identifier is a public item, that might be stored by the IOTP Application Core.
WalletIdは（32）多くの既存の支払い財布ソフトウェアは、複数の財布が可能です。ウォレット識別子は、実際の財布を選択します。財布識別子がIOTPアプリケーションコアによって格納されるかもしれない公共の項目であることが、想定されます。
xml:lang Defines the language used by the Process State Description attribute (cf. IOTP Specification)
XML：langはプロセスの状態説明属性で使用する言語を定義します（参照IOTP仕様）
Table 3: Attributes
表3：属性
The following table explains the XML elements in alphabetical order:
次の表は、アルファベット順にXML要素について説明します。
Element Description
------- -----------
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).
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.
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コンテナ。その内容は、その最も外側の要素タグが「ブランド」が付いているブランドの要素内容に由来します。その宣言は、パッケージ化されたコンテンツの宣言（参照IOTP仕様）と一致しています。
BrandSelBrandInfoPackagedContent This contains any additional data that may be required by a particular payment brand. It forms the content of the Brand Selection Brand Info Element.
BrandSelBrandInfoPackagedContentこれは、特定のペイメントブランドによって必要とされる任意の追加データが含まれています。それはブランドセレクションブランド情報要素の内容を形成しています。
BrandSelProtocolAmountInfoPackagedContent This contains any additional data that may be required by a particular payment brand in the format. It forms the content of the Brand Selection Protocol Amount Info Element.
BrandSelProtocolAmountInfoPackagedContentこれは形式で特定のペイメントブランドによって必要とされる任意の追加データが含まれています。これは、ブランドの選択議定書金額情報要素の内容を形成しています。
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.
BrandSelCurrencyAmountInfoPackagedContentこれは形式内の特定のペイメントブランドと通貨である任意の追加データが含まれています。これは、ブランドの選択通貨金額情報要素の内容を形成しています。
MerchantData Any merchant related data that might be used by the IOTP Payment Bridge for different purposes, e.g., it might contain IDs to access some mall data, but not cryptographic keys. Its Packaged declaration coincides with the Content's declaration (cf. IOTP Specification).
MerchantData異なる目的のためにIOTP支払いの橋で使用されるかもしれない任意の加盟店関連データは、例えば、それはいくつかのモールのデータにアクセスするためのIDが含まれているかもしれないが、ない暗号化キー。そのパッケージ化された宣言は、コンテンツの宣言（参照IOTP仕様）と一致しています。
PackagedContent Generic Container for non-IOTP data (cf. IOTP Specification).
非IOTPデータのPackagedContent汎用コンテナ（参照IOTP仕様）。
PayProtocolPackagedContent The Pay Protocol Packaged Content originates from a Pay Protocol Element's content whereby the outermost element tags are prefixed with
最も外側の要素タグが接頭辞が付きますことにより、ペイ・プロトコルパッケージ化されたコンテンツは有料プロトコル要素の内容に由来PayProtocolPackagedContent
"PayProtocol". It contains information
about the protocol which is used by
the payment protocol. The content of
this information is defined in the
supplement for a payment protocol. Its
declaration coincides with the Packaged
Content's declaration (cf. IOTP
Specification).
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ザ・プロトコルブランドパッケージ化されたコンテンツは、最も外側の要素タグは「ProtocolBrand」が付いていることにより、議定ブランド要素の内容に由来します。その宣言は、パッケージ化されたコンテンツの宣言（参照IOTP仕様）と一致しています。これは、支払プロトコルによって使用される可能性のあるブランドに関する情報が含まれています。この情報の内容は、支払プロトコルのためのサプリメントで定義されています。
ResponsePackagedContent Container for authentication response data. Its content originates from a Authentication Response Component's Packaged Content whose outermost element tags are prefixed with "Response". Its declaration coincides with the Packaged Content's declaration (cf. IOTP Specification).
認証応答データのResponsePackagedContentコンテナ。その内容は、その最も外側の要素タグが「応答」が付いている認証応答コンポーネントのパッケージ化されたコンテンツに由来します。その宣言は、パッケージ化されたコンテンツの宣言（参照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.
TradingRoleDataPackagedContentザ・TradingRoleDataパッケージ化されたコンテンツは、最も外側の要素タグは「TradingRoleData」が付いていることにより、TradingRoleDataコンポーネントのコンテンツに由来します。その宣言は、パッケージ化されたコンテンツの宣言（参照IOTP仕様）と一致しています。これは、支払いで使用されるプロトコルについての消費者を経由してお支払いハンドラへの商人からの情報が含まれています。この情報の内容は、支払プロトコルのためのサプリメントで定義されています。示すためにその支払ブリッジプロセス本、例えば「お支払い方法：SET-OD」：このパッケージ化された内容のname属性は、「お支払い」などの接頭辞を含める必要があります。詳細については、[SET / IOTP]を参照してください。
The element's declaration coincides with
the Packaged Content's declaration (cf.
IOTP Specification).
Table 4: Elements
表4：要素
XML definition:
XML定義：
<!ENTITY % AuthReqPackagedContent "PackagedContent"> <!ENTITY % AuthResPackagedContent "PackagedContent">
<！ENTITY％AuthReqPackagedContent "PackagedContent"> <！ENTITY％のAuthResPackagedContent "PackagedContent">
<!ENTITY % BrandPackagedContent "PackagedContent"> <!ENTITY % BrandSelInfoPackagedContent "PackagedContent"> <!ENTITY % BrandSelProtocolAmountPackagedContent "PackagedContent"> <!ENTITY % BrandSelCurrencyAmountPackagedContent "PackagedContent"> <!ENTITY % ProtocolAmountPackagedContent
<！ENTITY％BrandPackagedContent "PackagedContent"> <！ENTITY％BrandSelInfoPackagedContent "PackagedContent"> <！ENTITY％BrandSelProtocolAmountPackagedContent "PackagedContent"> <！ENTITY％BrandSelCurrencyAmountPackagedContent "PackagedContent"> <！ENTITY％以下のProtocolAmountPackagedContent
"PackagedContent"> <!ENTITY % PayProtocolPackagedContent "PackagedContent"> <!ENTITY % TradingRoleDataPackagedContent "PackagedContent"> <!ENTITY % MerchantData "PackagedContent"> <!ENTITY % PaySchemePackagedContent "PackagedContent">
"PackagedContent"> <！ENTITY％PayProtocolPackagedContent "PackagedContent"> <！ENTITY％TradingRoleDataPackagedContent "PackagedContent"> <！ENTITY％MerchantData "PackagedContent"> <！ENTITY％PaySchemePackagedContent "PackagedContent">
The IOTP Payment API supports six different attribute values that encode the transaction status from the IOTP's point of view, i.e., the appropriate point of view at the interface between the IOTP Application Core and IOTP Payment Bridge. This point of view does not completely mimic the more detailed view on the actual payment by the actual Existing Payment Software or IOTP Payment Bridge.
IOTP支払いのAPIは、ビューのIOTPの視点からトランザクション状態を符号化する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.
支払トランザクションがIOTPアプリケーションコア内に存在するNotYetStarted、すなわち、商人の店はすでにIOTPトランザクションが消費者によって開始されたことIOTPアプリケーションコアに通知しています。
However, neither any API call has been
issued to the IOTP Payment Bridge nor has
the IOTP Order Request has been created.
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.
それはブランドのリストのコンパイル時にお支払いの橋への最初のAPIコールを発行する際のInProgressザ・IOTPアプリケーションは、この値にプロセスの状態を変更します。
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).
However, this value does not indicate that any IOTP Order Request has been created and transmitted to the Consumer.
ただし、この値は、任意のIOTP注文要求が作成され、消費者に送信されたことを示すものではありません。
Suspended The IOTP transaction has been suspended before the order request block has been transmitted to the Consumer.
注文要求ブロックが消費者に送信される前に一時停止IOTPトランザクションが中断されました。
Implicitly, the payment is also deferred.
暗黙のうち、支払いも延期されます。
CompletedOk The IOTP Order Request has been successfully created and transmitted to the Consumer. Actually, this process state indicates only that the order processing has been finished.
CompletedOkザ・IOTP注文要求が正常に作成され、消費者に送信されてきました。実際には、このプロセスの状態は、注文処理が終了しただけであることを示します。
But it contains no indication about the
status of the actual payment, which is
accepted by the Payment Handler.
However, successful order processing signals the IOTP Application Core that a payment with some specific parameters is expected within the near future. And this signal might be used by the Existing Payment Software for similar purposes. This attribute might be interpreted as successful preparation of the payment system.
しかし、成功した注文処理は、いくつかの特定のパラメータを使用して支払いが近い将来以内に期待されていることをIOTPアプリケーションコアを知らせます。そして、この信号は、同様の目的のために既存の決済ソフトウェアによって使用される可能性があります。この属性は、決済システムの成功準備として解釈される可能性があります。
Particularly, it is expected that the Existing Payment Software maps this IOTP status value to some other internal value, e.g., "NotYetStarted", that is more accurate from its point of view.
特に、それは、ビューのその点から、より正確で、既存の支払ソフトウェアは、他のいくつかの内部値、例えば、「NotYetStarted」に、このIOTPのステータス値をマップすることが期待されます。
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).
However, the ideal point of view of IOTP suspects that the actual payment transaction has been neither started nor initiated.
しかし、IOTPのビューの理想的な点は、実際の支払い取引が開始されていないにも開始されたどちらもないかと疑っています。
ProcessError The IOTP transaction, i.e., order processing, has failed for some (technical) reason and it is known that no payment will occur.
ProcessError IOTPトランザクション、すなわち、注文処理は、いくつかの（技術的な）理由で失敗した、何の支払いが発生しないことが知られています。
This indication might be used to clear
all data about this transaction within
the Existing Payment Bridge (by
"RemovePaymentLog" or
"ChangeProcessState") or to reverse any
preparation (with the Payment Handler
out-of-band to IOTP).
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.
これは、任意のIOTPの支払いトランザクションの初期プロセスの状態を符号化するNotYetStarted。この値は、ブランドの選択時に設定されているが、それは通常、全体のブランドの選択プロセスの間に変更されません。
InProgress With the issuance of the Start Payment Consumer API call, the IOTP Application Core changes the process state to this value.
スタート支払消費者のAPIコールの発行でのInProgress、IOTPアプリケーションコアは、この値にプロセスの状態を変更します。
Suspended The payment transaction has been suspended. Suspension may occur anywhere during brand selection (with the Merchant) or payment processing (with the Payment Handler). On resumption, the IOTP Application Core and the IOTP Payment Bridge have to use other internal data to decide whether brand selection or actual payment processing needs to be continued, i.e., whether the process state needs to be reset to "NotYetStarted" or "InProgress".
トランザクションが中断された支払いを停止しました。サスペンションは、（支払ハンドラ付）（マーチャント付き）ブランドの選択や支払い処理中にどこにでも発生する可能性があります。再開には、IOTPアプリケーションコアとIOTP支払いの橋は、プロセスの状態が「NotYetStarted」または「のInProgress」にリセットする必要があるかどうか、すなわち、銘柄選択や実際の支払処理を継続する必要があるかどうかを決定するために、他の内部データを使用する必要があります。
Note that the Payment API assumes
stateless brand selection by the IOTP
Payment Bridge. Typically, any suspension
during brand selection requires the
repetition of the whole process. Hereby,
the IOTP Application Core might need to
consider any already negotiated
conditions in a brand depended purchase
(brand, protocol).
CompletedOk The successful payment has been acknowledged by the Payment Handler, i.e., the successful IOTP Payment Response has been received.
CompletedOk成功した支払いは、すなわち、成功したIOTP支払い応答が受信された、支払ハンドラによって認められています。
Implicitly, this implies successful order
processing.
Failed The IOTP transaction, i.e., order or payment processing, has failed for some (business) reason. In either case it is known that the payment will not succeed.
IOTPトランザクション、すなわち、オーダーや決済処理を失敗し、いくつかの（ビジネス）の理由で失敗しました。いずれの場合も、支払いが成功しないことが知られています。
ProcessError The IOTP transaction, i.e., order or payment processing, has failed for some (technical) reason.
ProcessError IOTPトランザクション、すなわち、オーダーや決済処理は、いくつかの（技術的な）理由で失敗しました。
However, the local process state might be
different from that of Payment Handler.
Table 6: Consumer
表6：消費者
The Payment Handler is responsible for the actual payment processing. New payment transactions are reported by the Consumer with the transmission of new IOTP Payment Request Blocks. IOTP Payment Exchange Block are send by the Consumer for payment transaction continuation and resumption.
お支払いハンドラは、実際の支払処理を担当しています。新しい支払取引は、新たなIOTP支払い要求ブロックの伝送と消費者によって報告されています。 IOTP支払い交換ブロックは、支払取引の継続や再開のための消費者によって送信されます。
ProcessState Description
------------ -----------
NotYetStarted This encodes the initial process state of any payment transaction. Typically, this value will last for a short amount of time.
NotYetStartedこれは、任意の支払い取引の初期プロセスの状態を符号化します。通常、この値は、短い時間持続します。
InProgress The IOTP Application Core changes the process state changes to "InProgress" when the Payment Handler starts with the actual processing of the IOTP Payment Request Block.
支払ハンドラはIOTP支払い要求ブロックの実際の処理を開始したときのInProgressザ・IOTPアプリケーションコア「のInProgress」へのプロセスの状態の変更を変更します。
Note that this does not assume that the
"StartPaymentPaymentHandler" API function
has been called.
Suspended The payment transaction has been suspended.
トランザクションが中断された支払いを停止しました。
CompletedOk The payment has been processed, successfully, i.e., the IOTP Payment Response Block was created and transmitted to the Consumer.
CompletedOk支払いが処理された、成功した、すなわち、IOTP支払い応答ブロックが作成され、消費者に送信されました。
Failed The payment transaction, has finally failed for some (business) reason.
支払い取引を失敗し、最終的にいくつか（ビジネス）の理由で失敗しました。
Note that this value encodes the payment
state reported by the IOTP Payment Bridge
on "InquireProcessState". It neither
reflects whether the payment receipt has
been inquired nor whether the IOTP
Payment Response Block has been created
and submitted to the Consumer.
ProcessError The payment transaction, has finally failed for some (technical) reason.
ProcessError支払い取引は、最終的にいくつか（技術的な）理由で失敗しました。
Note that this value encodes the payment
state reported by the IOTP Payment
Bridge. It does not reflect whether some
IOTP Error Block has been created and
submitted to the Consumer.
Table 7: Consumer
表7：消費者
This API function determines the payment brands being accepted by the Payment Handler on behalf of the Merchant.
このAPI関数は、ペイメントブランドが商人に代わって支払いハンドラによって受け入れられて決定します。
Input Parameters
入力パラメータ
o Payment Direction - provided by the IOTP Application Core o Currency Code and Currency - provided by the IOTP Application Core o Payment Amount - provided by the IOTP Application Core o Merchant Payment Identifier - Merchant's unique private reference to the payment transaction o Merchant Organisation Identifier - used for distinction between multiple merchants that share the some IOTP merchant system o Wallet Identifier - managed by the IOTP Application Core o Merchant Data - specific data used by the IOTP Payment Bridge which is managed in the IOTP Application Core.
○お支払方向 - 通貨コード及び通貨oをIOTPアプリケーションコアが提供する - マーチャント支払い識別子oをIOTPアプリケーションコアが提供する - - 商人組織識別子○お支払取引の商人独自のプライベート参照支払額oをIOTPアプリケーションコアが提供します - 商人データoをIOTPアプリケーションコアによって管理される - - IOTPアプリケーションコアに管理されているIOTP支払いの橋で使用される特定のデータウォレット識別子oをいくつかIOTP商人システムを共有する複数の商人の間の区別のために使用。
XML definition:
XML定義：
<!ELEMENT FindAcceptedPaymentBrand (MerchantData*) > <!ATTLIST FindAcceptedPaymentBrand PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED MerchantPayId CDATA #REQUIRED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED >
<！ELEMENT FindAcceptedPaymentBrand（MerchantData *）> <ATTLIST FindAcceptedPaymentBrand PayDirection（デビット|クレジット）！#REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED額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 >
<！ELEMENT FindAcceptedPaymentBrandResponse（BrandItem *）> <ELEMENT BrandItem（BrandPackagedContent *）> <！ATTLIST BrandItem BrandId CDATA #REQUIREDのXML：LANG NMTOKEN #IMPLIED新しい名称CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED BrandNarrative CDATA #IMPLIED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function determines the instances of payment protocols (and optionally the payment brands) being accepted by the Payment Handler on behalf of the Merchant. The function might be called in two variants:
このAPI関数は、商人に代わって支払いハンドラによって受け入れられている（およびペイメントブランドをオプションで）支払いプロトコルのインスタンスを決定します。この関数は二つの変種で呼ばれるかもしれません。
o With the Brand Identifier set on the input parameter list: The function responds with the payment protocols that fits to the submitted brand.
ブランド識別子が入力パラメータリストに設定すると○：機能が提出ブランドに合う支払プロトコルで応答します。
o 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一部のIOTPのマーチャントシステム - O IOTPアプリケーションコア（ブランド）パッケージ化されたコンテンツによって管理 - さらにペイメントブランド説明。 「受け入れられた支払いブランドを探す」で返されます。 IOTPアプリケーションコアに管理されているIOTP支払いの橋で使用される特定のデータを - ブランド識別子がマーチャントデータoを設定されている場合は、この要素にのみ提供されています。
XML definition:
XML定義：
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*, MerchantData?) > <!ATTLIST FindAcceptedPaymentProtocol BrandId CDATA #IMPLIED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED MerchantPayId CDATA #REQUIRED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED >
<！ELEMENT FindAcceptedPaymentProtocol（BrandPackagedContent *、MerchantData？）> <ATTLIST FindAcceptedPaymentProtocol BrandId CDATA #IMPLIED PayDirection（デビット|クレジット）！#REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED額CDATA #REQUIRED MerchantPayId CDATA #REQUIRED MerchantOrgId CDATAの＃黙示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.
○お支払プロトコル識別子 - ブランドリストコンポーネントの支払に挿入するための支払プロトコル名と言語annotation- Oブランドリストコンポーネントのブランド要素のprotocolブランド要素に挿入するための - プロトコルブランド識別子Oブランドリストコンポーネントのペイプロトコル要素に挿入するための支払い要求の純場所Oプロトコル要素 - ブランドリストコンポーネントのペイプロトコル要素に挿入するためのセキュリティ保護で安心決済リクエストネット場所O - 挿入のためのブランドのリストコンポーネントのペイプロトコル要素でブランドアイテム一覧（節参照4.1.1）O - そこになければなりません何のブランドの識別子が入力パラメータリストの上に提供されていない場合には少なくとも一つの要素です。 O（プロトコル量）パッケージ化されたコンテンツ - 挿入のためのブランドのリストコンポーネントのプロトコル量要素O（ペイ・プロトコル）パッケージ化されたコンテンツで - 通貨金額要素Oブランドリストコンポーネントのペイプロトコル要素に挿入するための - [IOTP]における定義に非常によく似、含まれていること - 洗練通貨コードと通貨 - 洗練された支払額 - - ブランドOブランドリストコンポーネントの通貨金額要素に挿入するための - ブランドリストコンポーネントの通貨額の要素に挿入するための場合は、各プロトコルの項目に少なくとも一つの要素が存在しなければなりません何のブランドの識別子が入力パラメータリストの上に提供されていません。
XML definition:
XML定義：
<!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+, BrandItem*) > <!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*, PayProtocolPackagedContent* CurrencyAmount+, Brand*,ProtocolBrand*)> <!ATTLIST ProtocolItem ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIED xml:lang NMTOKEN #IMPLIED ProtocolName CDATA #REQUIRED PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED >
<！ELEMENT FindAcceptedPaymentProtocolResponse（ProtocolItem +、BrandItem *）> <ATTLIST ProtocolItem ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIEDのXML <ELEMENT ProtocolItem（ProtocolAmountPackagedContent *、PayProtocolPackagedContent * CurrencyAmount +、ブランド*、ProtocolBrand *）！>：！LANG NMTOKEN #IMPLIED ProtocolName CDATA #REQUIRED PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED>
<!ELEMENT Brand EMPTY > <!ATTLIST Brand BrandId CDATA #REQUIRED >
<！ELEMENTブランドEMPTY> <！ATTLISTブランドBrandId CDATA #REQUIRED>
<!ELEMENT CurrencyAmount EMPTY > <!ATTLIST CurrencyAmount CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #IMPLIED Amount CDATA #IMPLIED >
<！ELEMENT CurrencyAmount EMPTY> <！ATTLIST CurrencyAmount CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #IMPLIED量CDATA #IMPLIED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function provides the remaining initialization data being required by the Consumer's or Payment Handler's Existing Payment Software. This function might be called both for "brand dependent" and "brand independent" transaction types. In either case, this function is called with one particular brand.
このAPI関数は、消費者や支払ハンドラの既存の支払ソフトウェアによって必要とされている残りの初期化データを提供します。この機能は、両方の「依存ブランド」と「ブランドの独立した」トランザクションタイプのために呼ばれるかもしれません。いずれの場合も、この機能は、ある特定のブランドと呼ばれています。
Input Parameters
入力パラメータ
o Brand Identifier - returned by "Find Accepted Payment Brand" o Merchant Payment Identifier - Merchant's unique private reference to the payment transaction o Payment Direction o Currency Code and Currency - from the Brand List Component's Currency Amount Element o Payment Amount - from the Brand List Component's Currency Amount Element o Payment Protocol Identifier - from the Brand List Component's Pay Protocol Element o Protocol Brand Identifier - from the Protocol Brand Element which relates to the selected Brand Element, if any o (TradingRoleData) Receiver Organization Identifier o OkFrom, OkTo - identical to the entries of the Order Component
Oブランド識別子 - 支払通貨コードO方向と通貨○お支払取引の商人独自のプライベート参照 - - ブランドリストコンポーネントの通貨額の要素から支払金額O - ブランドリストからで返さはマーチャント支払い識別子o「が認められた支払いブランドを探します」コンポーネントの通貨金額要素支払プロトコル識別子O - ブランドリストコンポーネントのペイプロトコル要素から議定ブランド識別子O - プロトコルブランドの要素から選択されたブランド要素に関する、OkFrom、OkTo O任意のO（TradingRoleData）レシーバー組織識別子の場合 - 同じ次成分のエントリーへ
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マーチャント組織識別子 - 財布識別子および/またはパスフレーズoを一部IOTP商人システムを共有する複数の商人の間の区別のために使用
Protocol Brand Element
プロトコルのブランド要素
o (Brand) Packaged Content - further payment brand description, from the Brand List Component's Brand Element o (Protocol Amount) Packaged Content - further payment protocol description, from the Brand List Component's Protocol Amount Element
O（ブランド）パッケージ化されたコンテンツ - さらにペイメントブランドの説明、ブランドリストコンポーネントのブランド要素O（プロトコル量）パッケージ化されたコンテンツから - ブランドリストコンポーネントのプロトコル量要素からさらに支払プロトコルの記述、
o (Pay Protocol) Packaged Content - further payment protocol description, from the Brand List Component's Pay Protocol Element o (Protocol Brand) Packaged Content - further brand information, from the Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o (Order) Packaged Content - further order description, from the Order Element o three Brand Selection Info Packaged Content elements - copied from the Brand Selection Component on brand dependent purchases o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data o Merchant Data - specific data used by the IOTP Payment Bridge which is managed in the IOTP Application Core.
さらに、支払プロトコルの説明、ブランドリストコンポーネントのペイプロトコル要素O（プロトコルブランド）パッケージ化されたコンテンツから - - さらなるブランド情報、選択されたブランド要素に関するブランドリストコンポーネントの議定ブランド要素から（ペイ・プロトコル）パッケージ化されたコンテンツO議定書の金額Oペイメントブランドに関する追加データ - ブランドOブランド依存購入にブランドセレクションコンポーネントからコピー - 3つのブランドセレクション情報パッケージ化されたコンテンツ要素O、さらにオーダーの説明、注文の要素から - 、任意のO（注文）パッケージ化されたコンテンツであれば - 追加の支払いブランドと通貨商人データO固有のデータ - - IOTPアプリケーションコアに管理されているIOTP支払いの橋で使用される特定のデータ通貨額○お支払プロトコルに関する追加データ。
XML definition:
XML定義：
<!ELEMENT GetPaymentInitializationData (ProtocolBrand? BrandPackagedContent* ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, OrderPackagedContent*, BrandSelBrandInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*, BrandSelCurrencyAmountInfoPackagedContent*, MerchantData*) > <!ATTLIST GetPaymentInitializationData BrandId CDATA #REQUIRED MerchantPayId CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ProtocolId CDATA #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ReceiverOrgId CDATA #IMPLIED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT GetPaymentInitializationData（？ProtocolBrand BrandPackagedContent * ProtocolAmountPackagedContent *、PayProtocolPackagedContent *、OrderPackagedContent *、BrandSelBrandInfoPackagedContent *、BrandSelProtocolAmountInfoPackagedContent *、BrandSelCurrencyAmountInfoPackagedContent *、MerchantData *）> <ATTLIST GetPaymentInitializationData BrandId CDATA #REQUIRED MerchantPayId CDATA #REQUIRED PayDirection（デビット|クレジット）！＃ REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED量CDATA #REQUIRED ProtocolId CDATA #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ReceiverOrgId CDATA #IMPLIED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIEDパスフレーズ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.
OkFrom O、OkTo - 支払い成分O（TradingRoleData）パッケージ化されたコンテンツに挿入するための - さらに支払プロトコル記述。接頭辞として、例えば、「お支払い方法：SET-OD」：パッケージ化されたコンテンツ要素のname属性は、「お支払い」を含める必要があります。詳細については、[SET / IOTP]を参照してください。 O（注文）パッケージ化されたコンテンツ - 供給順序パッケージ化されたコンテンツへのデフォルトがあれば、省略します。
XML definition:
XML定義：
<!ELEMENT GetPaymentInitializationDataResponse (OrderPackagedContent*, TradingRoleDataPackagedContent*) > <!ATTLIST GetPaymentInitializationDataResponse OkFrom CDATA #IMPLIED OkTo CDATA #IMPLIED>
<！ELEMENT GetPaymentInitializationDataResponse（OrderPackagedContent *、TradingRoleDataPackagedContent *）> <！ATTLIST GetPaymentInitializationDataResponse OkFrom CDATA #IMPLIED OkTo CDATA #IMPLIED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function inquires any payment protocol specific authentication challenge value from the IOTP Payment Bridge. In Baseline IOTP this API function is called by the Merchant (or Financial Institution). The IOTP Application Core may propose a choice of algorithms to the IOTP Payment Bridge. However, the IOTP Payment Bridge may ignore the proposal and select some other algorithm.
このAPI関数はIOTP支払いの橋から任意の支払いプロトコル固有の認証チャレンジ値を問い合わせます。ベースラインIOTPでは、このAPI関数は、マーチャント（または金融機関）によって呼び出されます。 IOTPアプリケーションコアはIOTP支払いの橋にアルゴリズムの選択肢を提案することができます。しかし、IOTP支払橋の提案を無視して、他のいくつかのアルゴリズムを選択することもできます。
The inquiry is assumed to be stateless. E.g., the IOTP Application Core may check the returned algorithm and stop transaction processing without notifying the IOTP Payment Bridge.
問い合わせはステートレスであると仮定されます。例えば、IOTPアプリケーションコアは、返されたアルゴリズムをチェックし、IOTP支払いのブリッジに通知することなく、トランザクション処理を停止することがあります。
The IOTP Application Core may issue several API calls to the IOTP Payment Bridge to build up the IOTP Authentication Request Block. Any subsequently submitted choice of algorithms should be constrained by the accepted algorithms from earlier API responses.
IOTPアプリケーションコアはIOTP認証要求ブロックを構築するためにIOTP支払いの橋には、いくつかのAPI呼び出しを発行することができます。アルゴリズムのいずれか後に提出した選択は、以前のAPIレスポンスから受け入れられたアルゴリズムによって制約されなければなりません。
The IOTP Payment Bridge responds with the Business Error Code if it does not provide any (more) authentication algorithms and challenges.
それはどんな（もっと）認証アルゴリズムと課題を提供していない場合はIOTP支払いの橋は、ビジネスのエラーコードで応答します。
Input Parameters
入力パラメータ
o Authentication Identifier - the authenticator may provide its payment identifier, i.e., Payment Handler or Merchant Payment Identifier. o Wallet Identifier and/or Pass Phrase o set of pre-selected algorithms for authentication
認証識別子O - オーセンティケータは、その支払識別子、即ち、支払いハンドラまたはマーチャント支払い識別子を提供することができます。ウォレット識別子および/または認証のために予め選択されたアルゴリズムのパスフレーズOセットO
XML definition:
XML定義：
<!ELEMENT InquireAuthChallenge (Algorithm*) > <!ATTLIST InquireAuthChallenge AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT InquireAuthChallenge（アルゴリズム*）> <！ATTLIST InquireAuthChallenge AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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
IOTP認証要求コンポーネントに挿入するために - アルゴリズムの要素O IOTP認証要求コンポーネントに挿入するために - 認証チャレンジのOリストが内容をパッケージ化
XML definition:
XML定義：
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*, Algorithm) >
<！ELEMENT InquireAuthChallengeResponse（AuthReqPackagedContent *、アルゴリズム）>
The Consumer's IOTP Application Core defers payment protocol specific authentication processing and the current challenge value to the active IOTP Payment Bridge. Alternative authentication algorithms might be tried sequentially or offered to the user for selection.
消費者のIOTPアプリケーションコアは、支払プロトコル固有の認証処理とアクティブIOTP支払いの橋への現在のチャレンジ値を延期します。代替認証アルゴリズムは、連続して試してみましたか選択のためにユーザに提供されることがあります。
Note that the IOTP Application Core has to consider both the current context and the algorithm in order to determine the responsible IOTP Payment Bridge.
IOTPアプリケーションコアが責任IOTP支払いの橋を決定するために、現在のコンテキストとアルゴリズムの両方を考慮しなければならないことに注意してください。
Failed authentication is reported by the Business Error Code which might trigger the inquiry of the details ("Inquire Process State"). Final failures might be encoded by the process state "Failed".
失敗した認証は（「プロセスの状態を問い合わせ」）の詳細の問い合わせをトリガする可能性があるビジネスのエラーコードで報告されます。最終的な故障は「失敗」プロセスの状態によって符号化される可能性があります。
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財布識別子および/またはパスフレーズ - アルゴリズムエレメントO IOTP認証要求コンポーネントからコピーは - IOTP認証要求コンポーネントからコピー
XML definition:
XML定義：
<!ELEMENT Authenticate (Algorithm, AuthReqPackagedContent*) > <!ATTLIST Authenticate AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT認証（アルゴリズム、AuthReqPackagedContent *）> <！ATTLIST認証AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o Authentication Response Packaged Content - for insertion into the IOTP Authentication Response Component
IOTP認証応答コンポーネントに挿入するために - O認証レスポンスのコンテンツをパッケージ化
XML definition:
XML定義：
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
<！ELEMENT AuthenticateResponse（AuthResPackagedContent *）>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function verifies the Consumer's payment protocol specific authentication response. In Baseline IOTP this API function is called by the Merchant (or the Financial Institution). It is called only if the counter party has responded with an IOTP Authentication Response Component within the Authentication Response Block. Of course, the IOTP Application Core traces the need of such an response.
このAPI関数は、消費者の支払プロトコル固有の認証応答を検証します。ベースラインIOTPでは、このAPI関数は、マーチャント（または金融機関）によって呼び出されます。相手が認証応答ブロック内IOTP認証レスポンスコンポーネントで応答した場合にのみ呼び出されます。もちろん、IOTPアプリケーションコアは、そのような応答の必要性をトレースします。
Due to the authentication's statelessness, all parameters (algorithm, challenge and response) are submitted to the IOTP Payment Bridge. Authentication failure is reported by a Process State different from "CompletedOK".
認証のステートレスに、すべてのパラメータ（アルゴリズム、チャレンジとレスポンス）はIOTP支払いの橋に提出されています。認証の失敗は、「CompletedOK」とは異なるプロセス状態によって報告されました。
Input Parameters
入力パラメータ
o Authentication Identifier o Wallet Identifier and/or Pass Phrase o Authentication Challenge Packaged Content - generated by previous "Inquire Authentication Challenge" API call o Algorithm Element o Authentication Response Packaged Content - copied from the Authentication Response Component
O認証識別子認証チャレンジOウォレット識別子および/またはパスフレーズOパッケージ化されたコンテンツ - 認証応答コンポーネントからコピー - 認証応答パッケージ化されたコンテンツOアルゴリズム要素O前の「照会]認証チャレンジ」APIの呼び出しによって生成されました
XML definition:
XML定義：
<!ELEMENT CheckAuthResponse (Algorithm, AuthReqPackagedContent*, AuthResPackagedContent*) > <!ATTLIST CheckAuthResponse AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT CheckAuthResponse（アルゴリズム、AuthReqPackagedContent *、AuthResPackagedContent *）> <！ATTLIST CheckAuthResponse AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o Current Process (Authentication) State o Completion Code o Status Description and its language annotation
ステータス説明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 >
<！ELEMENT CheckAuthResponseResponse EMPTY> <！ATTLIST CheckAuthResponseResponse ProcessState（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#REQUIRED CompletionCode NMTOKEN #IMPLIEDのXML：LANG NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED>
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枚のモンデックスカードは、存在する支払いブランドのインスタンスを決定します。同じ物理的なカードであっても、複数の決済手段を表すことができます。
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現在の支払い取引に消費者の固有の参照、さらにペイメントブランド説明。ブランドリストコンポーネントのブランド要素0（プロトコールブランド）の要素からコピー - さらに情報。もしあれば消費者に関連するブランドリストコンポーネントの議定ブランド要素からコピー、ブランド要素を選択しました。 O（プロトコル量）パッケージ化されたコンテンツ - さらに、支払プロトコルの説明、ブランドリストコンポーネントのプロトコル額の要素からコピー
o Element (Protocol) Packaged Content - further payment protocol description, copied from the Brand List Component's Pay Protocol Element
Oエレメント（プロトコル）パッケージ化されたコンテンツ - さらに、支払プロトコルの説明、ブランドリストコンポーネントのペイプロトコル要素からコピー
XML definition:
XML定義：
<!ELEMENT FindPaymentInstrument (BrandPackagedContent*, ProtocolBrand?, PayProtocolPackagedContent*, ProtocolAmountPackagedContent*) > <!ATTLIST FindPaymentInstrument BrandId CDATA #REQUIRED ProtocolId CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED >
<！ELEMENT FindPaymentInstrument（BrandPackagedContent *、ProtocolBrand？PayProtocolPackagedContent *、ProtocolAmountPackagedContent *）> <ATTLIST FindPaymentInstrument BrandId CDATA #REQUIRED ProtocolId CDATA #REQUIRED PayDirection（デビット|クレジット）！#REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED額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、これらは、ユーザー定義の支払い楽器の名前とその言語エンコーディングO内部値であります
The Existing Payment Software responds with an empty list of identifiers, either if it does not distinguish between different payment instruments or if there are no registered payment instruments available despite brand support for at least one (unspecified) payment protocol. In the latter case, the IOTP Payment Bridge has to request the registration of a suitable payment instrument at a subsequent step of the payment process.
それは別の決済手段の間、または少なくとも一つの（未指定）支払プロトコルのためのブランドのサポートにもかかわらず、利用可能な登録済みの決済手段が存在しないかどうかを区別しない場合は、既存の支払ソフトウェアは、識別子の空のリストで応答し、どちらか。後者の場合には、IOTP支払いブリッジは、支払プロセスの次のステップに適切な支払い手段の登録を要求しなければなりません。
XML definition:
XML定義：
<!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) > <!ELEMENT PayInstrument EMPTY > <!ATTLIST PayInstrument Id CDATA #REQUIRED xml:lang NMTOKEN #IMPLIED PayInstName CDATA #REQUIRED >
<！ELEMENT FindPaymentInstrumentResponse（PayInstrument *）> <！ELEMENT PayInstrument EMPTY> <！ATTLIST PayInstrument IdをCDATA #REQUIREDのXML：LANG NMTOKEN #IMPLIED PayInstName CDATA #REQUIRED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function checks whether a payment (both debit and credit) can go ahead. It can be used, for example, to check
このAPI関数は、支払い（借方と貸方の両方）が先に行くことができるかどうかチェックします。例えば、チェックするために、使用することができます
o if there are sufficient funds available in a particular currency for an electronic cash payment brand, o whether there is sufficient value space left on the payment instrument for payment refund, o whether required system resources are available and properly configured, e.g., serial ports or baud rate, o whether environment requirements are fulfilled, e.g., chip card reader presence or Internet connection.
O十分な電子現金決済ブランドのための特定の通貨で利用可能な資金、支払い還付のための支払機器に残さ十分な値のスペースがあるかどうかoを、必要なシステムリソースが利用可能であり、適切に設定するかどうかをO、例えば、シリアルポートまたはが存在する場合環境要件が満たされているかどうか、例えば、チップカードリーダーの存在またはインターネット接続Oボーレート、。
If the payment method is based on external components, e.g., magnetic stripe or chip cards, and the check accesses the medium, the existing payment method should not mutually exclusive lock system resources, e.g., serial port or modem, that may also be required by other Existing Payment Software, e.g., multiple payment software components may share the same card reader. If this happens for API internal request processing, the function has to unlock these components prior to return. Otherwise, the payment may not proceed if the Consumer cancels immediately and decides to use another payment instrument. In this event the previous IOTP Payment Bridge is not notified about the change.
支払方法は、外付け部品、例えば、磁気ストライプまたはチップカードに基づいて、チェックがメディアにアクセスしている場合は、既存のお支払い方法は、相互に排他的ではないロックシステムリソースは、例えば、シリアルポートまたはモデムもが必要とするべきです他の既存の支払ソフトウェア、例えば、複数の支払いのソフトウェアコンポーネントは、同じカードリーダーを共有することがあります。これはAPI内部要求を処理するために発生した場合、この関数は返す前に、これらのコンポーネントのロックを解除する必要があります。消費者はすぐにキャンセルし、別の支払い手段を使用することを決定した場合にはそうでない場合は、支払いが進まない場合があります。このイベントでは、以前のIOTP支払いの橋は、変更について通知されません。
This function call happens immediately after the Consumer's payment instrument selection. For example, if the payment instrument is a chip card, that is not inserted in the chip card reader, the Consumer may be prompted for its insertion. However, the Consumer should be able to hit some 'skip' button, if the payment check is part of the actual payment protocol, too. Finally, the IOTP Payment Bridge may provide only a subset of these capabilities or may even directly generate a successful response without any checks.
この関数呼び出しは、消費者の決済手段を選択した直後に発生します。決済手段は、チップカードリーダーに挿入されていないチップカード、例えば、もし、消費者はその挿入のために要求されることがあります。しかし、消費者は、入金確認は、実際の支払プロトコルの一部である場合も、いくつかの「スキップ」ボタンを打つことができるはずです。最後に、IOTP支払いの橋は、これらの機能のサブセットのみを提供することができる、あるいは直接任意のチェックをせずに正常な応答を生成してもよいです。
Input Parameters
入力パラメータ
o Brand Identifier - user selection o Payment Instrument Identifier - user selection o Currency Code and Currency Code Type - copied from the selected Currency Amount Element o Payment Amount - copied from the selected Currency Amount Element o Payment Direction - copied from the selected Trading Protocol Option Block o Protocol Identifier - copied from the selected Pay Protocol Element
Oブランド識別子 - 支払手段識別子Oユーザ選択 - 通貨コードと通貨コードタイプOユーザ選択 - 支払O方向選択通貨額の要素からコピー - - 選択した取引プロトコルオプションからコピーされた支払額oを選択した通貨額の要素からコピー選択されたペイプロトコル要素からコピー - プロトコル識別子Oブロック
o Protocol Brand Identifier - copied from the selected Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o Consumer Payment Identifier - Consumer's unique reference to the current payment transaction o Wallet Identifier and/or Pass Phrase o (Brand) Packaged Content - copied from the selected Brand Element o (Protocol Amount) Packaged Content - copied from the selected Protocol Amount Element o (Protocol) Packaged Content - copied from the selected Pay Protocol Element o (Protocol Brand) Packaged Content - copied from the selected Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any
Oプロトコルブランド識別子 - 消費者のユニークなウォレット識別子O現在の支払い取引への参照および/またはパスフレーズ0（ - 任意のO消費者の支払い識別子あれば、選択されたブランド要素に関するブランドリストコンポーネントの選択議定ブランド要素からコピーブランド）パッケージ化されたコンテンツ - からコピー - 選択ペイプロトコル要素O（プロトコルブランド）パッケージ化されたコンテンツからコピー - 選択議定書金額要素O（プロトコル）パッケージ化されたコンテンツからコピー - 選択したブランド要素O（プロトコル量）パッケージ化されたコンテンツからコピーもしあれば、選択されたブランド要素に関するブランドリストコンポーネントの選択議定ブランド要素
XML definition:
XML定義：
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*, ProtocolBrand? ProtocolAmountPackagedContent*, PayProtocolPackagedContent*> <!ATTLIST CheckPaymentPossibility BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ProtocolId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<ATTLIST CheckPaymentPossibility BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED PayDirection（デビット<ELEMENT CheckPaymentPossibility（BrandPackagedContent *、ProtocolBrand ProtocolAmountPackagedContent *、PayProtocolPackagedContent *！？> |！クレジット）#REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED金額CDATAの＃ REQUIRED ProtocolId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o three Brand Selection Info Packaged Content elements - for insertion into the Brand Selection component o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data
ペイメントブランドOプロトコルの金額に関する追加データ - - 追加の決済ブランドや通貨、特定のデータ - 支払プロトコルO通貨額に関する追加データブランドセレクション成分Oブランドへの挿入のために - 3つのブランドセレクション情報パッケージ化されたコンテンツ要素O
XML definition:
XML定義：
<!ELEMENT CheckPaymentPossibilityResponse (BrandSelBrandInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*, BrandSelCurrencyAmountInfoPackagedContent*) > <!ATTLIST CheckPaymentPossibilityResponse >
<！ELEMENT CheckPaymentPossibilityResponse（BrandSelBrandInfoPackagedContent *、BrandSelProtocolAmountInfoPackagedContent *、BrandSelCurrencyAmountInfoPackagedContent *）> <！ATTLIST CheckPaymentPossibilityResponse>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
These Payment API calls may be made either by the Consumer's or Payment Handler's IOTP Application Core.
これらの決済APIの呼び出しは、消費者や支払ハンドラのIOTPアプリケーションコアのいずれかによって行うことができます。
This API function initiates the actual payment transaction at the Consumer side. The IOTP Payment Bridge and the Existing Payment Software perform all necessary initialization and preparation for payment transaction processing. This includes the reservation of external periphery. E.g., 1) the Consumer's chip card reader needs to be protected against access from other software components, 2) the insertion of the chip card may be requested, 3) the Internet connection may be re-established, or 4) the Payment Handler may open a mutual exclusive session to the security hardware.
このAPI関数は、消費者側の実際の支払い取引を開始します。 IOTP支払いの橋と既存の支払ソフトウェアは、支払取引処理のために必要なすべての初期化と準備を行います。これは、外周の予約が含まれています。例えば、1）消費者のチップカードリーダは、他のソフトウェアコンポーネントからのアクセスから保護される必要がある、2）チップカードの挿入が要求されてもよい、3）インターネット接続を再確立することができる、または4）支払ハンドラよいですセキュリティハードウェアへの相互排他的なセッションを開きます。
The IOTP Payment Bridge monitors the payment progress and stores the current payment states such that resumption - even after power failures - remains possible. Note that the IOTP Application Core supplies only a subset of the following input parameter to the associated resumption API function and refers to the payment transaction through the party's payment identifier.
IOTP支払いの橋は、支払いの進捗状況を監視し、再開するように、現在の支払い状態保存 - でも、停電後には - 可能性が残っています。 IOTPアプリケーションコアが関連再開API関数に次の入力パラメータのサブセットだけを供給し、当事者の支払識別子を通じて支払い取引をいいます。
Input Parameters
入力パラメータ
o Brand Identifier - copied from the selected Brand Element o Payment Instrument Identifier - the user selection o Currency Code and Currency - copied from the selected Currency Amount Element o Payment Amount - copied from the selected Currency Amount Element o Payment Direction - copied from the Brand List Component o Protocol Identifier - copied from the selected Payment Protocol Element
Oブランド識別子は - 支払O方向選択された通貨額素子からのコピー - - 支払金額oを選択した通貨額素子からのコピー - 通貨コード及び通貨Oユーザーの選択 - 選択されたブランド要素O支払機器識別子からコピーされたブランドからコピー選択した支払プロトコル要素からコピー - プロトコル識別子Oリストコンポーネント
o Protocol Brand Element - further information; copied from the Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o OkFrom, OkTo - copied from the Payment Component o Consumer Payment Identifier - Consumer's unique reference to the current payment transaction o Wallet Identifier and/or Pass Phrase o Call Back Function - used for end user notification/logging purposes o Call Back Language List. This list is required if the Call Back Function is set o (Brand) Packaged Content - further payment brand description; copied from the selected Brand Element's content o (Protocol Amount) Packaged Content - further payment protocol description; copied from the selected Protocol Amount Element's content o (Payment Protocol) Packaged Content - further payment protocol description; copied from the selected Pay Protocol Element's content o (Order) Packaged Content - further order description, copied from the Order Component
Oプロトコルブランド要素 - さらに情報。消費者の支払識別子○お支払コンポーネントからコピー - - 財布識別子O現在の支払い取引に消費者の一意の参照および/または任意のO OkFrom、OkTo場合は、選択したブランド要素に関するブランドリストコンポーネントの議定ブランド要素からコピーコールバック機能Oパスフレーズ - コールバック言語一覧O、エンドユーザ通知/ロギングの目的で使用されます。コールバック機能は、（ブランド）パッケージ化されたコンテンツoを設定されている場合、このリストは必要になる - さらにペイメントブランド説明。選択したブランド要素のコンテンツO（プロトコル量）パッケージ化されたコンテンツからコピー - さらに、支払プロトコルの記述。選択議定書金額要素のコンテンツO（支払プロトコル）パッケージ化されたコンテンツからコピー - さらに、支払プロトコルの記述。さらにオーダーの説明、次成分からコピー - 選択ペイプロトコル要素のコンテンツO（注文）パッケージ化されたコンテンツからコピー
XML definition:
XML定義：
<!ELEMENT StartPaymentConsumer (BrandPackagedContent*, ProtocolBrand? ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, OrderPackagedContent*) > <!ATTLIST StartPaymentConsumer BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
<！ELEMENT StartPaymentConsumer（BrandPackagedContent *、ProtocolBrand？ProtocolAmountPackagedContent *、PayProtocolPackagedContent *、OrderPackagedContent *）> <！ATTLIST StartPaymentConsumer BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED額CDATA #REQUIRED PayDirection（デビット|クレジット）#REQUIRED ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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
IOTP支払いの要求ブロックの決済スキームのコンポーネントへの挿入のための - （決済スキーム）パッケージ化されたコンテンツのO継続ステータス
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
IOTPアプリケーションコアは、応答の失敗の分析にこの要求を数回再発行することが許可されています。
XML definition:
XML定義：
<!ELEMENT StartPaymentConsumerResponse (PaySchemePackagedContent*) > <!ATTLIST StartPaymentConsumerResponse ContStatus (End|Continue) #REQUIRED >
<！ELEMENT StartPaymentConsumerResponse（PaySchemePackagedContent *）> <ATTLIST StartPaymentConsumerResponse ContStatus（エンド|続行）！#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ブランドリストコンポーネントからコピーされた任意の入出力OkFrom場合に消費者に関連するブランドリストコンポーネントのブランドプロトコル要素からコピーは、ブランド要素を選択しました商人の組織要素からコピー - OkTo - 支払いハンドラ支払い識別子○お支払コンポーネントからコピー - 商人組織識別子O現在の支払取引の決済ハンドラの一意の参照
o Wallet Identifier - renaming to till identifier neglected - and/or Pass Phrase o Call Back Function - used for end user notification/logging purposes o Call Back Language List. This list is required if the call back function is set o (Brand) Packaged Content - further payment brand description; copied from the Consumer selected Brand Element's content o (Protocol Brand) Packaged Content - further information; copied from the Protocol Brand Element of the Brand List Component which relates to the Consumer selected Brand Element, if any. o (Protocol Amount) Packaged Content - further payment protocol description; copied from the Consumer selected Protocol Amount Element's content o (Protocol) Packaged Content - further payment protocol description; copied from the Consumer selected Pay Protocol Element's content o (TradingRoleData) Packaged Content - further payment protocol description; the Name Attribute of the packaged contents must include "Payment:" as the prefix, for example "Payment:SET-OD". For more information, see [SET/IOTP]. o Three Brand Selection Info Packaged Content Elements - copied from the Brand Selection Component o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data o (Payment Scheme) Packaged Content.
識別子は無視までにリネーム - - 財布識別子Oおよび/またはコールバック機能Oパスフレーズ - コールバック言語一覧O、エンドユーザへの通知/ロギングの目的で使用されます。コールバック関数は（ブランド）パッケージ化されたコンテンツoを設定されている場合、このリストは必要になる - さらにペイメントブランド説明。消費者からコピーブランド要素のコンテンツO（プロトコルブランド）パッケージ化されたコンテンツ選択 - さらなる情報は、もしあれば消費者に関連するブランドリストコンポーネントの議定ブランド要素からコピー、ブランド要素を選択しました。 O（プロトコル量）パッケージ化されたコンテンツ - さらに、支払プロトコルの記述。議定金額要素のコンテンツO（プロトコル）パッケージ化されたコンテンツ選択の消費者からコピー - さらに、支払プロトコルの記述。ペイ・プロトコル要素のコンテンツO（TradingRoleData）パッケージ化されたコンテンツ選択の消費者からコピー - さらに、支払プロトコルの記述。接頭辞として、例えば、「お支払い方法：SET-OD」：パッケージ化された内容のname属性は、「お支払い」を含める必要があります。詳細については、[SET / IOTP]を参照してください。 O三ブランドセレクション情報パッケージ化されたコンテンツ要素 - ブランドセレクション成分Oブランドからコピー - プロトコル金額Oペイメントブランドに関する追加データ - 通貨金額○お支払プロトコルに関する追加データ - 追加の決済ブランドや通貨、特定のデータO（決済スキーム）パッケージ化されたコンテンツ。
XML definition:
XML定義：
<!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*, ProtocolBrand?, ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, BrandSelBrandInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*, BrandSelCurrencyAmountInfoPackagedContent*, TradingRoleDataPackagedContent*, PaySchemePackagedContent*) > <!ATTLIST StartPaymentPaymentHandler BrandId CDATA #REQUIRED ConsumerPayId CDATA #IMPLIED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED ProtocolId CDATA #REQUIRED
<！ELEMENT StartPaymentPaymentHandler（BrandPackagedContent *、ProtocolBrand？ProtocolAmountPackagedContent *、PayProtocolPackagedContent *、BrandSelBrandInfoPackagedContent *、BrandSelProtocolAmountInfoPackagedContent *、BrandSelCurrencyAmountInfoPackagedContent *、TradingRoleDataPackagedContent *、PaySchemePackagedContent *）> <！ATTLIST StartPaymentPaymentHandler BrandId CDATA #REQUIRED ConsumerPayId CDATA #IMPLIED CurrCodeType NMTOKEN「ISO4217- 」CurrCode CDATA #REQUIRED額CDATA #REQUIRED PayDirection（デビット|クレジット）#REQUIRED ProtocolId CDATA #REQUIRED
OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED PaymentHandlerPayId CDATA #REQUIRED MerchantOrgId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED PaymentHandlerPayId CDATA #REQUIRED MerchantOrgId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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
IOTP支払いの交換ブロックの支払いスキームコンポーネントへの挿入のための - （決済スキーム）パッケージ化されたコンテンツのO継続ステータス
The response message must contain payment schema data if the continuation status signals "Continue". The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
継続状態信号場合、応答メッセージは、「続行」支払スキーマデータが含まれている必要があります。 IOTPアプリケーションコアは、応答の失敗の分析にこの要求を数回再発行することが許可されています。
XML definition:
XML定義：
<!ELEMENT StartPaymentPaymentHandlerResponse (PaySchemePackagedContent*) > <!ATTLIST StartPaymentPaymentHandlerResponse ContStatus (End|Continue) #REQUIRED >
<！ELEMENT StartPaymentPaymentHandlerResponse（PaySchemePackagedContent *）> <ATTLIST StartPaymentPaymentHandlerResponse ContStatus（エンド|続行）！#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支払い要求をブロックまたはExchangeブロックを生成する必要があるIOTP支払いかどうかを決定するためにIOTPアプリケーションコアまでです。一つの指標は、例えば、支払ハンドラ支払い識別子の知識支払ハンドラから前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財布識別子および/またはパスフレーズ〇〇消費者の支払識別子 - エンドユーザ通知/ロギングの目的で使用されます
XML definition:
XML定義：
<!ELEMENT ResumePaymentConsumer EMPTY > <!ATTLIST ResumePaymentConsumer ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
<！ELEMENT ResumePaymentConsumer EMPTY> <！ATTLIST ResumePaymentConsumer ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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).
次回のOTPメッセージ（支払Exchangeまたは要求ブロック）の支払いスキームコンポーネントに挿入するための - （決済スキーム）パッケージ化されたコンテンツのO継続ステータス。
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response. However, the IOTP Payment Bridge might reject the resumption request by using the "AttNotSupp" Error Code "naming" the Consumer Payment Identifier attribute. Then the Consumer has to apply normal error processing to the current (sub-)transaction and to issue a new Payment Request Block to the Payment Handler.
IOTPアプリケーションコアは、応答の失敗の分析にこの要求を数回再発行することが許可されています。しかし、IOTP支払いの橋は、消費者の支払い識別子属性を「命名」「AttNotSupp」エラーコードを使用して再開要求を拒否することがあります。そして、消費者は、現在の（サブ）トランザクションに通常のエラー処理を適用すると支払いハンドラに新しい支払要求ブロックを発行する必要があります。
XML definition:
XML定義：
<!ELEMENT ResumePaymentConsumerResponse (PaySchemePackagedContent*) > <!ATTLIST ResumePaymentConsumerResponse ContStatus (End|Continue) #REQUIRED >
<！ELEMENT ResumePaymentConsumerResponse（PaySchemePackagedContent *）> <ATTLIST ResumePaymentConsumerResponse ContStatus（エンド|続行）！#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 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、エンドユーザへの通知/ロギングの目的で使用されます。受信IOTPメッセージ（支払Exchangeまたは要求ブロック）の支払いスキームコンポーネントからコピー - コールバック関数は（支払スキーム）パッケージ化されたコンテンツoを設定されている場合、このリストが必要です。
XML definition:
XML定義：
<!ELEMENT ResumePaymentPaymentHandler (PaySchemePackagedContent*) > <!ATTLIST ResumePaymentPaymentHandler PaymentHandlerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
<！ELEMENT ResumePaymentPaymentHandler（PaySchemePackagedContent *）> <！ATTLIST ResumePaymentPaymentHandler PaymentHandlerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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継続ステータス。
The response message contains payment schema specific data if the continuation status signals "Continue". The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
継続状態信号場合、応答メッセージは、「続行」支払スキーマ固有のデータが含まれています。 IOTPアプリケーションコアは、応答の失敗の分析にこの要求を数回再発行することが許可されています。
XML definition:
XML定義：
<!ELEMENT ResumePaymentPaymentHandlerResponse (PaySchemePackagedContent*) > <!ATTLIST ResumePaymentPaymentHandlerResponse ContStatus (End|Continue) #REQUIRED >
<！ELEMENT ResumePaymentPaymentHandlerResponse（PaySchemePackagedContent *）> <ATTLIST ResumePaymentPaymentHandlerResponse ContStatus（エンド|続行）！#REQUIRED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function passes one specific IOTP Payment Scheme Component, i.e., the encapsulated Packaged Content elements, received from the counter party (e.g., Consumer) to the IOTP Payment Bridge and responds with the next IOTP Payment Scheme Component for submission to the counter party.
このAPI関数は、ある特定のIOTP支払いスキーム成分を通過させる、すなわち、カプセル化されたパッケージ化されたコンテンツ要素、IOTP支払いの橋にカウンターパーティ（例えば、消費者）から受信した相手への提出については、次のIOTP支払いスキームコンポーネントで応答します。
Input Parameters
入力パラメータ
o Payty's Payment Identifier o Process (Transaction) Type which distinguishes between Payments and Inquiries. o Wallet Identifier and/or Pass Phrase o (Payment Scheme) Packaged Content - copied from the Payment Scheme Component of the received Payment Exchange Block or from the Error Block.
O Paytyの支払識別子O処理（トランザクション）は、支払いと問い合わせを区別どのタイプ。受け取った支払取引ブロックの支払いスキームComponentからか、エラーブロックからコピー - （決済スキーム）パッケージ化されたコンテンツOウォレット識別子および/またはパスフレーズO。
Each party should set the payment identifier with the local identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment Handler: PaymentHandlerPayId).
各当事者は、ローカル識別子（：;：MerchantPayId;支払ハンドラ：PaymentHandlerPayId商人ConsumerPayId消費者）に支払い識別子を設定する必要があります。
XML definition:
XML定義：
<!ELEMENT ContinueProcess (PaySchemePackagedContent+) > <!ATTLIST ContinueProcess PayId CDATA #REQUIRED ProcessType (Payment | Inquiry) 'Payment' WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT ContinueProcess（PaySchemePackagedContent +）> <ATTLIST ContinueProcess PayId CDATA #REQUIRED PROCESSTYPE（お支払い|お問い合わせ）！ 'お支払い' WalletID CDATA #IMPLIEDパスフレーズ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継続ステータス
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.
継続状態信号場合、応答メッセージは、「続行」支払スキーマデータが含まれています。支払方式でデータが重要度HardErrorとエラーコンポーネントを含むIOTP誤差ブロック内に受信された場合IOTP支払いの橋は、「終了」を知らせる必要があります。
XML definition:
XML定義：
<!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) > <!ATTLIST ContinueProcessResponse ContStatus (End|Continue) #REQUIRED >
<！ELEMENT ContinueProcessResponse（PaySchemePackagedContent *）> <ATTLIST ContinueProcessResponse ContStatus（エンド|続行）！#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関数はいつでも消費者、商人によって「FindAcceptedPaymentBrand」の発行、またはの発行により、IOTP支払いの橋に「FindPaymentInstrument」の発行後の各支払トランザクションのための消費者、商人、または支払ハンドラによって呼び出されるかもしれません支払ハンドラによって「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.
プロセスの状態「CompletedOkは」、「失敗」、および「ProcessErrorは、」彼らは、その後の呼び出しで変更することができないという意味では最終的なものです。こうした互換性のないコールが発行されている場合は、API関数は、エラーコードを返すべきではありません。その代わりに、古い変わらないプロセス状態を報告する必要があります。
Unknown payment transactions are reported by the Error Code "AttValInvalid" pointing to the PayId attribute.
不明な支払取引はPayId属性を指しているエラーコード「AttValInvalid」によって報告されています。
Input Parameters
入力パラメータ
o Party's Payment Identifier o intended Payment Status o intended Completion Code o Process (Transaction) Type which distinguishes between Payments and Inquiries. o Wallet Identifier and/or Pass Phrase
O意図支払い状況の〇〇党の支払い識別子は、支払いおよびお問い合わせを区別し、どのタイプのプロセス（トランザクション）O完了コードを意図しました。 Oウォレット識別子および/またはパスフレーズ
XML definition:
XML定義：
<!ELEMENT ChangeProcessState EMPTY > <!ATTLIST ChangeProcessState PayId CDATA #REQUIRED ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED CompletionCode NMTOKEN #IMPLIED ProcessType (Payment | Inquiry) 'Payment' WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT ChangeProcessState EMPTY> <ATTLIST ChangeProcessState PayId CDATA #REQUIRED ProcessState！（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#REQUIRED CompletionCode NMTOKEN #IMPLIED PROCESSTYPE（お支払い|お問い合わせ） '支払い' WalletID CDATA #IMPLIEDパスフレーズのCDATA＃黙示>
Output Parameters
出力パラメータ
o Process State and Percent Complete o Completion Code o Status Description and its language annotation
Oプロセスの状態とパーセントステータス説明O完了コードOの完了とその言語の注釈
XML definition:
XML定義：
<!ELEMENT ChangeProcessStateResponse EMPTY > <!ATTLIST ChangeProcessStateResponse ProcessState (NotYetStarted | InProgress | Suspended | CompletedOk | Failed | ProcessError) #REQUIRED PercentComplete CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED >
<！ELEMENT ChangeProcessStateResponse EMPTY> <！ATTLIST ChangeProcessStateResponse ProcessState（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#REQUIRED PERCENTCOMPLETE CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIEDのXML：LANG NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED>
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
ウォレット識別子および/またはパスフレーズ〇〇党の支払い識別子
XML definition:
XML定義：
<!ELEMENT RemovePaymentLog EMPTY > <!ATTLIST RemovePaymentLog PayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT RemovePaymentLog EMPTY> <！ATTLIST RemovePaymentLog PayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
XML definition:
XML定義：
<!ELEMENT RemovePaymentLogResponse EMPTY > <!ATTLIST RemovePaymentLogResponse >
<！ELEMENT RemovePaymentLogResponse EMPTY> <！ATTLIST RemovePaymentLogResponse>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function retrieves the properties of the Payment Instrument. The Payment Instrument Identifier could be omitted if this identifier is derived by other means, e.g., by analysis of the currently inserted chip card. If the Payment instrument could not uniquely determined, the IOTP Payment Bridge may provide suitable dialogs for user input.
このAPI関数は、支払手段のプロパティを取得します。この識別子は、現在挿入チップカードの分析により、例えば、他の手段によって導出された場合に支払機器識別子は省略することができます。支払機器が一意に決定できなかった場合は、IOTP支払いの橋は、ユーザの入力に適したダイアログを提供することができます。
E.g., this API function might be used during problem resolution with the Customer Care Provider of the issuer of the payment instrument, in order to inquire payment instrument specific values.
例えば、このAPI関数は、支払い機器固有の値を問い合わせるために、支払い機器の発行者の顧客ケアプロバイダとの問題解決の際に使用される可能性があります。
Input parameters
入力パラメータ
o Brand Identifier o Payment Instrument Identifier o Protocol Identifier o 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
言語XMLで識別される値の列 - 施設のタイプ一覧Oウォレット識別子および/またはパスフレーズOプロトコル識別子〇〇ブランド識別子Oの支払手段の識別子： - プロトコルブランドコンテンツOさらにペイメントブランドの説明（ブランド）PackagedContentコンテンツO LANG - さらに、支払プロトコル記述0（ペイ・プロトコル）PackagedContentコンテンツ - - さらに、支払プロトコル記述（プロトコル金額）PackagedContentコンテンツOさらにペイメントブランド情報
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利用できない場合がありますジェネリック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
プロパティの型意味バランス現在の残高の最大値を制限バランスPaymentLimit最大支払取引制限の有効期限有効期限識別子発行者は、決済手段の識別子を割り当てます。通常、それはAPIの支払い機器識別子と一致していません。保存された支払いトランザクションエントリの数をLOGENTRIES。エントリは最も古いエントリのためのいくつかの非負の値に（直近の）0から番号が付けられています。 n番目の記録決済取引のPayAmountn支払額、nはn番目の支払記録されたトランザクションのかもしれ負PayPartynリモートパーティ、nはn番目の支払記録されたトランザクションのかもしれ負PayTimen時間、nは負のかもしれません
XML definition:
XML定義：
<!ELEMENT PaymentInstrumentInquiry (BrandPackagedContent*, ProtocolBrand?, ProtocolAmountPackagedContent*, PayProtocolPackagedContent*) > <!ATTLIST PaymentInstrumentInquiry BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED ProtocolId CDATA #REQUIRED
<！ELEMENT PaymentInstrumentInquiry（BrandPackagedContent *、ProtocolBrand？ProtocolAmountPackagedContent *、PayProtocolPackagedContent *）> <！ATTLIST PaymentInstrumentInquiry BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED ProtocolId CDATA #REQUIRED
PropertyTypeList NMTOKENS #REQUIRED xml:lang NMTOKEN #IMPLIED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
PropertyTypeList NMTOKENS #REQUIREDのXML：LANG NMTOKEN #IMPLIED WalletID CDATA #IMPLIEDパスフレーズ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"
LANG：言語XMLで識別されるゼロ個以上使用できないプロパティ値のリストを、O。 「プロパティタイプ」、「プロパティ値」と「プロパティの説明」のゼロ以上のセットのリストO
XML definition:
XML定義：
<!ELEMENT PaymentInstrumentInquiryResponse (PaymentInstrumentProperty*) > <!ATTLIST PaymentInstrumentInquiryResponse xml:lang NMTOKEN #REQUIRED UnavailablePropertyList NMTOKENS #IMPLIED > <!ELEMENT PaymentInstrumentProperty EMPTY > <!ATTLIST PaymentInstrumentProperty PropertyType NMTOKEN #REQUIRED PropertyValue CDATA #REQUIRED PropertyDesc CDATA #REQUIRED >
<！ELEMENT PaymentInstrumentInquiryResponse（PaymentInstrumentProperty *）> <！ATTLIST PaymentInstrumentInquiryResponseのXML：LANG NMTOKEN #REQUIRED UnavailablePropertyList NMTOKENS #IMPLIED> <ATTLIST PaymentInstrumentProperty PropertyTypeはNMTOKEN #REQUIRED PropertyValueをCDATA #REQUIRED PropertyDesc CDATA #REQUIRED> <！ELEMENT PaymentInstrumentProperty EMPTY！>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function reports the party's payment identifiers of any pending payment transactions that the IOTP Payment Bridge/Existing Payment Software recommends be completed or suspended prior to the processing of new payment transactions. It does not respond with further transaction details. These have to be requested with "Inquire Process State".
このAPI関数はIOTP支払いの橋/既存の支払ソフトウェアは前の新しい支払取引の処理に完了または中止することをお勧めします保留中の支払取引の当事者の支払い識別子を報告します。さらに、取引内容で応答しません。これらは、「照会]プロセスの状態」で要求する必要があります。
Note that the IOTP Payment Bridge has to respond without the benefit of any pass phrase if there exist no pending payment transaction. But if there are some pending payment transactions, the IOTP Payment Bridge may refuse the immediate response and may instead request the appropriate pass phase from the IOTP Application Core.
IOTP支払いの橋は、保留中の支払い取引が存在しない場合は任意のパスフレーズの恩恵なしで対応しなければならないことに注意してください。いくつかの保留支払取引がある場合でも、IOTP支払いの橋は、即時応答を拒否することができ、代わりにIOTPアプリケーションコアから適切なパス相を要求することができます。
Input Parameters
入力パラメータ
o Wallet Identifier and/or Passphrase
O財布識別子および/またはパスフレーズ
XML definition:
XML定義：
<!ELEMENT InquirePendingPayment EMPTY > <!ATTLIST InquirePendingPayment WalletId CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT InquirePendingPayment EMPTY> <！ATTLIST InquirePendingPayment WalletId CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o Party's Payment Identifier
O党の支払い識別子
XML definition:
XML定義：
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<！ELEMENT InquirePendingPaymentResponse（PaymentId *）>
<!ELEMENT PaymentId EMPTY > <!ATTLIST PaymentId PayId CDATA #REQUIRED >
<！ELEMENT PaymentId EMPTY> <！ATTLIST PaymentId PayId CDATA #REQUIRED>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This function is used by the Consumer and might be used by the Payment Handler to check the consistency, validity, and integrity of IOTP payment receipts which might consist of Packaged Content Elements
この機能は、消費者によって使用され、パッケージ化されたコンテンツ要素で構成されることがありますIOTP支払いの領収書の一貫性、有効性、および整合性をチェックするためにお支払いハンドラによって使用されるかもしれません
o from the IOTP Payment Receipt Component - provided by the Payment Handler's "Inquire Process State" API call shortly before payment completion,
O IOTP支払いの領収書のコンポーネントから - まもなく支払完了前に支払いハンドラの「照会]プロセスの状態」APIの呼び出しによって提供、
o from Payment Scheme Components being exchanged during the actual payment, or
お支払いスキームコンポーネントは、実際の支払いの際に交換されてから、O、または
o being returned by the Consumer's "Inquire Process State" API call shortly before payment completion
まもなく支払いが完了する前に消費者の「お問い合わせプロセスの状態」APIの呼び出しによって返されるO
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ウォレット識別子および/またはパスフレーズ〇〇党の支払い識別子
XML definition:
XML定義：
<!ELEMENT CheckPaymentReceipt (PackagedContent*) > <!ATTLIST CheckPaymentReceipt PayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT CheckPaymentReceipt（PackagedContent *）> <！ATTLIST CheckPaymentReceipt PayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
XML definition:
XML定義：
<!ELEMENT CheckPaymentReceiptResponse EMPTY > <!ATTLIST CheckPaymentReceiptResponse >
<！ELEMENT CheckPaymentReceiptResponse EMPTY> <！ATTLIST CheckPaymentReceiptResponse>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function expands any IOTP payment receipt into a form which may be used for display or printing purposes. "Check Payment Receipt" should be used first if there is any question of the payment receipt containing errors.
このAPI関数は、表示や印刷の目的で使用することができる形式に任意のIOTP支払いの領収書を拡張します。エラーを含む領収書のいずれかの問題がある場合、「支払いの領収書を確認し、」最初に使用する必要があります。
The same conventions apply to the input parameter as for "Check Payment Receipt" (cf. Section 4.5.1).
同じ規則は、「支払領収書を確認してください」（節参照4.5.1）用として、入力パラメータに適用されます。
Input Parameters
入力パラメータ
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase o All Packaged Content Elements that build the payment receipt
領収書を構築するすべてのパッケージ化されたコンテンツの要素Oウォレット識別子および/またはパスフレーズ〇〇党の支払い識別子
XML definition:
XML定義：
<!ELEMENT ExpandPaymentReceipt (PackagedContent*) > <!ATTLIST ExpandPaymentReceipt PayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT ExpandPaymentReceipt（PackagedContent *）> <！ATTLIST ExpandPaymentReceipt PayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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スタイルシートネット場所○お支払プロパティリスト。他の出力パラメータのいずれによっても覆われていない支払いに関する追加情報を含むタイプ/値/説明トリプルのリスト。プロパティの説明は、言語の注釈を考慮する必要があります。
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
<！ELEMENT ExpandPaymentReceiptResponse（PaymentProperty *）> <ATTLIST ExpandPaymentReceiptResponse BrandId CDATA #IMPLIED PaymentInstrumentId CDATA #IMPLIED額CDATA #IMPLIED CurrCodeType NMTOKEN #IMPLIED CurrCode CDATA #IMPLIED PayDirection（デビット|クレジット）！#IMPLIEDタイムスタンプCDATA #IMPLIED ProtocolId CDATA #IMPLIED ProtocolBrandId CDATA #IMPLIED ProtocolTransId CDATA #IMPLIEDのxml：langのNMTOKEN #IMPLIED ConsumerDesc CDATA #IMPLIED
PaymentHandlerDesc CDATA #IMPLIED StyleSheetNetLocn CDATA #IMPLIED>
PaymentHandlerDesc CDATA #IMPLIED StyleSheetNetLocn CDATA #IMPLIED>
<!ELEMENT PaymentProperty EMPTY > <!ATTLIST PaymentProperty PropertyType NMTOKEN #REQUIRED PropertyValue CDATA #REQUIRED PropertyDesc CDATA #REQUIRED >
<！ELEMENT PaymentProperty EMPTY> <！ATTLIST PaymentProperty PropertyTypeはNMTOKEN #REQUIRED PropertyValueをCDATA #REQUIRED PropertyDesc CDATA #REQUIRED>
The Existing Payment Software should return as many attributes as possible from the supplied IOTP Payment Receipt. The payment supplement defines the attribute values for the payment properties.
既存のお支払いソフトウェアが付属IOTP支払いの領収書から、できるだけ多くの属性を返す必要があります。支払サプリメントは、支払いのプロパティの属性値を定義します。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
This API function returns the current payment state and optionally further Packaged Content Elements that form the payment receipt. Called by the Payment Handler, the IOTP Payment Bridge might respond with data intended for inclusion in the IOTP Payment Receipt Component's Packaged Content. When the Consumer calls this function shortly before payment completion, it may respond with further items of the payment receipt. Such items might be created by a chip card.
このAPI関数は、現在の支払い状況や領収書を形成し、必要に応じてさらにパッケージ化されたコンテンツの要素を返します。支払ハンドラによって呼び出され、IOTP支払いの橋は、コンポーネントのパッケージ化されたコンテンツIOTP支払いの領収書に含めるために意図されたデータで応答することがあります。消費者はすぐに支払いが完了する前にこの関数を呼び出すと、それは領収書の更なる項目で応答することができます。このようなアイテムは、チップカードによって作成されることがあります。
Input Parameters
入力パラメータ
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase
ウォレット識別子および/またはパスフレーズ〇〇党の支払い識別子
XML definition:
XML定義：
<!ELEMENT InquireProcessState EMPTY > <!ATTLIST InquireProcessState PayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT InquireProcessState EMPTY> <！ATTLIST InquireProcessState PayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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ステータス説明し、彼らがこれまでに作成されていない場合でも、支払いの領収書（参照：セクション4.5.1）を構築するすべてのパッケージ化されたコンテンツ要素にその言語の注釈○お支払領収書名参照O完了コードOコンプリート現在のプロセスの状態およびパーセント（消費者のシェア）
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 >
<！ELEMENT InquireProcessStateResponse（PackagedContent *）> <ATTLIST InquireProcessStateResponse ProcessState（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#REQUIRED PERCENTCOMPLETE CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIEDのXML：LANG NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED PayReceiptNameRefs 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:
XML定義：
<!ELEMENT StartPaymentInquiry EMPTY > <!ATTLIST StartPaymentInquiry ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT StartPaymentInquiry EMPTY> <！ATTLIST StartPaymentInquiry ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o (Payment Scheme) Packaged Content - intended for insertion in the Payment Scheme Component of the Inquiry Request Block
O（決済スキーム）パッケージ化されたコンテンツ - お問い合わせリクエストブロックの決済スキームのコンポーネントに挿入するためのもの
XML definition:
XML定義：
<!ELEMENT StartPaymentInquiryResponse (PaySchemePackagedContent*) >
<！ELEMENT StartPaymentInquiryResponse（PaySchemePackagedContent *）>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
The Payment Handler calls this API function for Consumer initiated inquiry processing. It differs from the previous "Inquire Process State" API function by the optional inclusion of payment scheme specific data. The response may encapsulate further details about the payment transaction.
消費者は、問い合わせ処理を開始するために支払ハンドラは、このAPI関数を呼び出します。これは、支払スキームの特定のデータのオプションを含めることによってAPI機能「プロセスの状態を照会し、」前回とは異なります。応答は、支払取引についての詳細をカプセル化することができます。
Input Parameters
入力パラメータ
o Payment Handler Payment Identifier o Wallet Identifier and/or Pass Phrase o (Payment Scheme) Packaged Content - copied from the Inquiry Request Block's Payment Scheme Component
問い合わせ要求ブロックの決済スキームComponentからコピーされた - （決済スキーム）パッケージ化されたコンテンツOウォレット識別子および/またはパスフレーズ〇〇支払ハンドラ支払い識別子
XML definition:
XML定義：
<!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) > <!ATTLIST InquirePaymentStatus PaymentHandlerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
<！ELEMENT InquirePaymentStatus（PaySchemePackagedContent *）> <！ATTLIST InquirePaymentStatus PaymentHandlerPayId CDATA #REQUIRED WalletID CDATA #IMPLIEDパスフレーズ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完了コード0ステータス説明し、その言語の注釈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 >
<！ELEMENT InquirePaymentStatusResponse（PaySchemePackagedContent *）> <！ATTLIST InquirePaymentStatusResponse PaymentHandlerPayId CDATA #REQUIRED ProcessState（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#REQUIRED CompletionCode NMTOKEN #IMPLIEDのXML：LANG NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED>
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 (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支払いの橋は新しいブランドとプロトコルのペアが登録されているサポートされる認証アルゴリズムを返します。
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 >
<！ELEMENT ManagePaymentSoftware（BrandPackagedContent *、ProtocolAmountPackagedContent *、PayProtocolPackagedContent *）> <ATTLIST ManagePaymentSoftware BrandId CDATA #IMPLIED ProtocolId CDATA #IMPLIEDアクション（新|アップデート|削除）！#IMPLIED WalletID CDATA #IMPLIEDパスフレーズCDATA #IMPLIED>
Output Parameters
出力パラメータ
o An action code: o New - added new wallet o Update - changed wallet's configuration o Delete - removed a wallet o Wallet Identifier and/or Pass Phrase
Oアクションコード：新は、O - 財布の設定oが削除変更 - - 新しい財布O更新を追加したウォレット識別子および/またはフレーズを渡しO財布を取り出し
The IOTP Payment Bridge does not return any information about the set of registered payment instruments because these data items are dynamically inferred during the brand selection process at the beginning of each IOTP transaction. However, the IOTP Application Core has to be notified about new wallets and should be notified about updated and removed wallets (identifier). Alternatively, removed wallets can be implicitly detected during the next brand selection phase. Updated wallets do no affect the processing of the IOTP Application Core. The IOTP Payment Bridge should only support the addition of at most one wallet because it is not able to report multiple additions at once back to the IOTP Application Core.
これらのデータ項目が動的に各IOTPトランザクションの開始時にブランドの選択プロセス中に推論されているので、IOTP支払いの橋は、登録された決済手段のセットに関する情報を返しません。しかし、IOTPアプリケーションコアは新しい財布について通知する必要があり、更新、削除財布（識別子）を通知しなければなりません。また、削除財布は暗黙のうちに次のブランドの選択フェーズ中に検出することができます。更新された財布には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 >
<！ELEMENT ManagePaymentSoftwareResponse EMPTY> <ATTLIST ManagePaymentSoftwareResponseアクション（新|アップデート|削除）！#IMPLIED WalletID CDATA #IMPLIEDパスフレーズ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支払いの橋で呼ばれるこの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コンプリート党の支払い識別子0のプロセスの状態およびパーセントO呼び出し側のソフトウェア識別子O、コールの進行状況についての情報を提供したテキスト。それは、消費者に表示されるか、例えば、に利用できるようにすべきです。
Examples of Status Description could be:
ステータス説明の例としては次のようになります。
o "Paying 12.30 USD to XYZ Inc" o "Payment completed" o "Payment aborted"
O「XYZ社に12.30ドルを支払う」o「のお支払いが完了し」o「のお支払いは中止します」
The valid languages are announced in the Call Back Language List attribute in "Start Payment X" and "Resume Payment X" API function calls.
有効な言語は「支払いを開始X」と「支払Xの再開」API関数呼び出しでコールバック言語List属性で発表されています。
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 >
<！ELEMENTコールバックEMPTY> <ATTLISTコールバックContentSoftwareID CDATA #IMPLIED PayId CDATA #REQUIRED ProcessState（NotYetStarted |のInProgress |吊り| CompletedOk |失敗| ProcessError）#IMPLIED PERCENTCOMPLETE CDATA #IMPLIED CompletionCode NMTOKEN #IMPLIEDのXML：LANG NMTOKEN #IMPLIED StatusDesc CDATA #IMPLIED>
Output Parameters
出力パラメータ
XML definition:
XML定義：
<!ELEMENT CallBackResponse EMPTY > <!ATTLIST CallBackResponse <!-- see below --> >
<！ELEMENT CallBackResponse EMPTY> <！ATTLIST CallBackResponse <！ - 下記参照 - >>
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
表4および5は、属性および要素を説明します。表3は、エラーコードを紹介します。
Basically, the call back function accepts all input arguments or rejects the whole request. It may even accept malformed requests.
基本的には、コールバック関数は、すべての入力引数を受け入れるか、全体の要求を拒否します。それも、不正なリクエストを受け入れることができます。
Some payment schemes may support or require that the Consumer might be able to cancel the payment at any time. The Call Back function can be used to facilitate this by returning the cancellation request on the next call (using the Business Error Code and Completion Code "ConsCancelled").
いくつかの支払い方式は、サポートしたり、消費者がいつでも支払いをキャンセルすることができるかもしれないことを要求することができます。コールバック関数は、（ビジネスのエラーコードと完了コード「ConsCancelled」を使用して）次の呼び出しでのキャンセル要求を返すことによって、これを容易にするために使用することができます。
Vice versa the Payment Handler's Application Core might use the similar mechanism to signal its IOTP Payment Bridges any exceptional need for a fast shutdown. These IOTP Payment Bridges may initiate the appropriate steps for terminating/cancelling all pending payment transactions.
逆もまた同様ペイメントハンドラのアプリケーションのコアは、そのIOTP支払いの橋、高速シャットダウンのいずれかの例外的な必要性を知らせるために、同様のメカニズムを使用する場合があります。これらのIOTP支払ブリッジは保留中のすべての支払取引をキャンセル/終了するための適切な措置を開始することができます。
Note that the "Change Process State" API function provides the second mechanism for such kind of notification. Therefore, the IOTP Payment Bridge or Existing Payment Software may ignore the details of the "Call Back" response.
「変更プロセスの状態」API関数は、通知のような種類のための第二のメカニズムを提供することに注意してください。したがって、IOTP支払いの橋や既存の支払ソフトウェアは、「コールバック」応答の詳細を無視することができます。
The IOTP Payment APIs only supports security using pass phrase to access to payment Wallet. These can be protected over TLS, which provides stronger security at the transport layer, but implementations are out the scope of this document.
IOTP支払いAPIは唯一の支払い財布にアクセスするためのパスフレーズを使用してセキュリティをサポートしています。これらは、トランスポート層でより強力なセキュリティを提供TLS、上で保護することができますが、実装は、この文書の範囲外です。
See also security consideration section of [IOTP].
また、[IOTP]のセキュリティ考慮セクションを参照してください。
[IOTP] Burdett, D., "Internet Open Trading Protocol - IOTP version 1.0", RFC 2801, April 2000.
[IOTP]バーデット、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]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（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.バーデット、D.E.イーストレイクIII、およびM.ゴンサルヴェス、インターネットのオープン・トレーディングプロトコル、マグロウヒル、2000年ISBN 0-07- 135501から4。
[SET] SET Secure Electronic Transaction(TM) , Version 1.0, May 31, 1997 Book 1: Business Description Book 2: Programmer's Guide Book 3: Formal Protocol Definition
事業内容帳2：プログラマーズ・ガイドブック3：フォーマルプロトコル定義[SET]セキュア電子取引（TM）、バージョン1.0、1997年5月31日ブック1を設定します
[SET/IOTP] Kawatsura, Y., "Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 3538, June 2003.
、RFC 3538、2003年6月[SET / IOTP] Kawatsura、Y.、 "v1.0のインターネットオープン取引プロトコル（IOTP）のためのセキュアな電子取引（SET）サプリメント"。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
Acknowledgement
謝辞
The contributions of Werner Hans of Atos Origin are gratefully acknowledged.
アトスオリジンのヴェルナー・ハンスの貢献は深く感謝しています。
Authors' Addresses
著者のアドレス
Hans-Bernhard Beykirch
ハンス・ベルンハルトBeykirch
EMail: hbbeykirch@web.de
メールアドレス：hbbeykirch@web.de
Yoshiaki Kawatsura Hitachi, Ltd. 890 Kashimada Saiwai-ku Kawasaki-shi Kanagawa, Japan 212-8567
よしあき かわつら ひたち、 Ｌｔｄ。 ８９０ かしまだ さいわいーく かわさきーし かながわ、 じゃぱん ２１２ー８５６７
EMail: ykawatsu@itg.hitachi.co.jp
メールアドレス：ykawatsu@itg.hitachi.co.jp
Masaaki Hiroya Technoinfo Service, Inc. 333-2-718 Uchikoshi-machi Hachioji-shi Tokyo 192-0911 JAPAN
まさあき ひろや てｃｈのいんふぉ せｒゔぃせ、 いんｃ。 ３３３ー２ー７１８ うちこしーまち はちおじーし ときょ １９２ー０９１１ じゃぱん
EMail: hiroya@st.rim.or.jp
メールアドレス：hiroya@st.rim.or.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。