RFC3867 日本語訳
3867 Payment Application Programmers Interface (API) for v1.0 InternetOpen Trading Protocol (IOTP). Y. Kawatsura, M. Hiroya, H. Beykirch. November 2004. (Format: TXT=234572 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Kawatsura
Request for Comments: 3867 Hitachi
Category: Informational M. Hiroya
Technoinfo Service
H. Beykirch
Atos Origin
November 2004
Kawatsuraがコメントのために要求するワーキンググループY.をネットワークでつないでください: 3867年の日立カテゴリ: 情報のM.のサービスH.Beykirchアトー発生源浩哉Technoinfo2004年11月
Payment Application Programmers Interface (API) for v1.0
Internet Open Trading Protocol (IOTP)
v1.0インターネットオープンTradingプロトコルのための支払いApplication Programmers Interface(API)(IOTP)
Status of this Memo
この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).
Copyright(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.
インターネットオープンTradingプロトコル(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.
'そのようなインタフェースはConsumersに存在しています'、'Merchants Payment HandlersのインストールがIOTPアプリケーションコアと支払いソフトウェアコンポーネント/レガシーシステムを接続して。
Hans, et al. Informational [Page 1] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[1ページ]のRFC3867支払いAPI
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General payment phases . . . . . . . . . . . . . . . . . 5
1.2. Assumptions. . . . . . . . . . . . . . . . . . . . . . . 6
2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Authentication Documentation Exchange. . . . . . . . . . 15
2.2. Brand Compilation. . . . . . . . . . . . . . . . . . . . 17
2.3. Brand Selection. . . . . . . . . . . . . . . . . . . . . 21
2.4. Successful Payment . . . . . . . . . . . . . . . . . . . 24
2.5. Payment Inquiry. . . . . . . . . . . . . . . . . . . . . 29
2.6. Abnormal Transaction Processing. . . . . . . . . . . . . 30
2.6.1. Failures and Cancellations . . . . . . . . . . . 30
2.6.2. Resumption . . . . . . . . . . . . . . . . . . . 32
2.7. IOTP Wallet Initialization . . . . . . . . . . . . . . . 33
2.8. Payment Software Management. . . . . . . . . . . . . . . 34
3. Mutuality. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1. Error Codes. . . . . . . . . . . . . . . . . . . . . . . 38
3.2. Attributes and Elements. . . . . . . . . . . . . . . . . 48
3.3. Process States . . . . . . . . . . . . . . . . . . . . . 61
3.3.1. Merchant . . . . . . . . . . . . . . . . . . . . 61
3.3.2. Consumer . . . . . . . . . . . . . . . . . . . . 63
3.3.3. Payment Handler. . . . . . . . . . . . . . . . . 65
4. Payment API Calls. . . . . . . . . . . . . . . . . . . . . . . 66
4.1. Brand Compilation Related API Calls. . . . . . . . . . . 66
4.1.1. Find Accepted Payment Brand. . . . . . . . . . . 66
4.1.2. Find Accepted Payment Protocol . . . . . . . . . 68
4.1.3. Get Payment Initialization Data. . . . . . . . . 70
4.1.4. Inquire Authentication Challenge . . . . . . . . 72
4.1.5. Authenticate . . . . . . . . . . . . . . . . . . 73
4.1.6. Check Authentication Response. . . . . . . . . . 74
4.2. Brand Selection Related API Calls. . . . . . . . . . . . 76
4.2.1. Find Payment Instrument. . . . . . . . . . . . . 76
4.2.2. Check Payment Possibility. . . . . . . . . . . . 78
4.3. Payment Transaction Related API calls. . . . . . . . . . 80
4.3.1. Start Payment Consumer . . . . . . . . . . . . . 80
4.3.2. Start Payment Payment Handler. . . . . . . . . . 82
4.3.3. Resume Payment Consumer. . . . . . . . . . . . . 84
4.3.4. Resume Payment Payment Handler . . . . . . . . . 85
4.3.5. Continue Process . . . . . . . . . . . . . . . . 86
4.3.6. Change Process State . . . . . . . . . . . . . . 88
4.4. General Inquiry API Calls. . . . . . . . . . . . . . . . 89
4.4.1. Remove Payment Log . . . . . . . . . . . . . . . 90
4.4.2. Payment Instrument Inquiry . . . . . . . . . . . 90
4.4.3. Inquire Pending Payment. . . . . . . . . . . . . 92
4.5. Payment Related Inquiry API Calls. . . . . . . . . . . . 93
4.5.1. Check Payment Receipt. . . . . . . . . . . . . . 93
4.5.2. Expand Payment Receipt . . . . . . . . . . . . . 94
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 一般支払いは.51.2の位相を合わせます。 仮定。 . . . . . . . . . . . . . . . . . . . . . . 6 2. メッセージ流動. . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1。 認証ドキュメンテーション交換。 . . . . . . . . . 15 2.2. 編集に商標を付けてください。 . . . . . . . . . . . . . . . . . . . 17 2.3. 選択に商標を付けてください。 . . . . . . . . . . . . . . . . . . . . 21 2.4. うまくいっている支払い. . . . . . . . . . . . . . . . . . . 24 2.5。 支払い問い合せ。 . . . . . . . . . . . . . . . . . . . . 29 2.6. 異常なトランザクション処理。 . . . . . . . . . . . . 30 2.6.1. 失敗とキャンセル. . . . . . . . . . . 30 2.6.2。 再開. . . . . . . . . . . . . . . . . . . 32 2.7。 IOTP財布初期設定. . . . . . . . . . . . . . . 33 2.8。 支払いソフトウェア・マネジメント。 . . . . . . . . . . . . . . 34 3. 相互関係。 . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1. エラーコード。 . . . . . . . . . . . . . . . . . . . . . . 38 3.2. 属性と要素。 . . . . . . . . . . . . . . . . 48 3.3. .1に州. . . . . . . . . . . . . . . . . . . . . 61 3.3を処理してください。 商人. . . . . . . . . . . . . . . . . . . . 61 3.3.2。 消費者. . . . . . . . . . . . . . . . . . . . 63 3.3.3。 支払い操作者。 . . . . . . . . . . . . . . . . 65 4. 支払いAPIは呼びます。 . . . . . . . . . . . . . . . . . . . . . . 66 4.1. ブランド編集はAPI呼び出しを関係づけました。 . . . . . . . . . . 66 4.1.1. 受け入れられた支払いブランドを見つけてください。 . . . . . . . . . . 66 4.1.2. 支払いプロトコル. . . . . . . . . 68 4.1.3が受け入れたと確かめてください。 支払い初期設定データを得てください。 . . . . . . . . 70 4.1.4. 認証挑戦. . . . . . . . 72 4.1.5について問い合わせてください。 .6に.734.1を認証してください。 認証応答をチェックしてください。 . . . . . . . . . 74 4.2. ブランド選択はAPI呼び出しを関係づけました。 . . . . . . . . . . . 76 4.2.1. 支払い器具を見つけてください。 . . . . . . . . . . . . 76 4.2.2. 支払いの可能性をチェックしてください。 . . . . . . . . . . . 78 4.3. 支払いのTransactionの関連APIは呼びます。 . . . . . . . . . 80 4.3.1. 支払い消費者. . . . . . . . . . . . . 80 4.3.2を始めてください。 支払い支払い操作者を始めてください。 . . . . . . . . . 82 4.3.3. 支払い消費者を再開してください。 . . . . . . . . . . . . 84 4.3.4. 支払い支払い操作者. . . . . . . . . 85 4.3.5を再開してください。 プロセス. . . . . . . . . . . . . . . . 86 4.3.6を続けてください。 プロセス状態. . . . . . . . . . . . . . 88 4.4を変えてください。 一般問い合せAPIは呼びます。 . . . . . . . . . . . . . . . 89 4.4.1. 支払いログ. . . . . . . . . . . . . . . 90 4.4.2を取り除いてください。 支払い器具問い合せ. . . . . . . . . . . 90 4.4.3。 未定の支払いについて問い合わせてください。 . . . . . . . . . . . . 92 4.5. 支払いは問い合せAPI呼び出しを関係づけました。 . . . . . . . . . . . 93 4.5.1. 支払い領収書をチェックしてください。 . . . . . . . . . . . . . 93 4.5.2. 支払い領収書. . . . . . . . . . . . . 94を広げてください。
Hans, et al. Informational [Page 2] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[2ページ]のRFC3867支払いAPI
4.5.3. Inquire Process State. . . . . . . . . . . . . . 96
4.5.4. Start Payment Inquiry. . . . . . . . . . . . . . 97
4.5.5. Inquire Payment Status . . . . . . . . . . . . . 98
4.6. Other API Calls. . . . . . . . . . . . . . . . . . . . . 99
4.6.1. Manage Payment Software. . . . . . . . . . . . . 99
5. Call Back Function . . . . . . . . . . . . . . . . . . . . . .101
6. Security Considerations. . . . . . . . . . . . . . . . . . . .103
7. References . . . . . . . . . . . . . . . . . . . . . . . . . .103
7.1. Normative References . . . . . . . . . . . . . . . . . .103
7.2. Informative References . . . . . . . . . . . . . . . . .104
Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . . .105
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .105
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .106
4.5.3. プロセス状態について問い合わせてください。 . . . . . . . . . . . . . 96 4.5.4. 支払い問い合せを始めてください。 . . . . . . . . . . . . . 97 4.5.5. 支払い状態. . . . . . . . . . . . . 98 4.6について問い合わせてください。 他のAPIは呼びます。 . . . . . . . . . . . . . . . . . . . . 99 4.6.1. 支払いソフトウェアを管理してください。 . . . . . . . . . . . . 99 5. 機能. . . . . . . . . . . . . . . . . . . . . .101 6に電話し直してください。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . .103 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . .103 7.1。 引用規格. . . . . . . . . . . . . . . . . .103 7.2。 有益な参照… .104 承認。 . . . . . . . . . . . . . . . . . . . . . . . . .105人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . .105の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . .106
1. Introduction
1. 序論
Common network technologies are based on standardized and established Internet technologies. The Internet technologies provide mechanisms and tools for presentation, application development, network infrastructure, security, and basic data exchange.
技術に基づいている一般的なネットワークが、インターネット技術を標準化して、確立しました。 インターネット技術はプレゼンテーション、アプリケーション開発、ネットワークインフラ、セキュリティ、および基礎データ交換にメカニズムと道具を供給します。
Due to the presence of already installed trading roles' systems with their own interfaces (Internet shop, order management, payment, billing, and delivery management systems, or financial institute's legacy systems), IOTP has been limited to the common external interface over the Internet. However, some of these internal interfaces might be also standardized for better integration of IOTP aware components with of the existing infrastructure and its cost effective reuse. For more information on IOTP, see [IOTP] and [IOTPBOOK].
それら自身のインタフェース(インターネット店、オーダー管理、支払い、支払い、および配送マネージメントシステム、または金融機関のレガシーシステム)と役割のシステムを貿易しながらインストールされた既にの存在のため、IOTPはインターネットの上の一般的な外部のインタフェースに制限されました。 しかしながら、また、これらの内部のインタフェースのいくつかがIOTPの意識している部品の、より良い統合のために標準化されるかもしれない、既存のインフラストラクチャとその費用効率がよい再利用について。 IOTPの詳しい情報に関しては、[IOTP]と[IOTPBOOK]を見てください。
The typical Payment Handlers (i.e., financial institutes or near-bank organizations) as well as Merchants require an IOTP aware application that easily fits into their existing financial infrastructure. The Payment Handler might even insist on the reuse of special in-house solutions for some subtasks of the IOTP aware application, e.g., reflecting their cryptography modules, gateway interfaces, or physical environment. Therefore, their IOTP aware implementation really requires such clear internal interfaces.
Merchantsと同様に典型的なPayment Handlers(すなわち、金融機関か銀行の近くの組織)は容易に彼らの既存の金融的基盤に収まるIOTPの意識しているアプリケーションを必要とします。 Payment Handlerは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 Application Coreに飛び出すのを可能にします。
Hans, et al. Informational [Page 3] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[3ページ]のRFC3867支払いAPI
Initially, this consideration leads to the two-level layered view of the IOTP software for each role, consisting of:
初めは、以下から成って、この考慮は各役割のためのIOTPソフトウェアの層にされた2レベルの視点につながります。
o some generic IOTP system component, the so-called IOTP application
core - providing IOTP based gateway services and generic business
logic and
o そして何らかのジェネリックIOTPシステムの部品、IOTPがゲートウェイサービスとジェネリックビジネス・ロジックを基礎づけたならアプリケーションが芯を取るいわゆるIOTP。
o the trading roles' specific back-end systems implementing the
specific trading transaction types' functionality.
o 特定の取り引きトランザクションがタイプの機能性であると実装する取り引き役割の特定のバックエンドシステム。
In order to isolate the changes on the infrastructure, the IOTP trading application has been three-layered:
インフラストラクチャで変化を隔離するために、IOTPの取り引きアプリケーションは3によって層にされています:
o the IOTP Application Core processes the generic parts of the IOTP
transaction and holds the connection to the Internet,
o IOTP Application CoreはIOTPトランザクションの汎用パーツを処理して、インターネットに接続を保ちます。
o the Existing Legacy System or Existing Payment Software which
processes the actual transaction type, and particular payment
transaction, and
o そして現物売買タイプ、および特定の支払処理を処理するExisting Legacy SystemかExisting Payment Software。
o the IOTP Middle-ware or IOTP Payment Bridge which glues the other
two possibly incompatible components. It brokers between the
specific interface of the Existing Legacy System and the
standardized interfaces of the IOTP Application Core.
o IOTP Middle-商品か他の2つのことによると両立しないコンポーネントをにかわで接ぐIOTP Payment Bridge。 それはExisting Legacy Systemと標準化の特定のインタフェースの間でIOTP Application Coreのインタフェースを仲介します。
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 Payment BridgeとIOTP Application Coreとのインタフェースに焦点を合わせます。 それは支払いにかかわるパーティーの間で支払いプロトコルメッセージを交換するための標準方法を提供します。 しかし、それはオーダーか配送処理にどんなインタフェースも指定しません。
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].
そのようなPayment Application Programmers Interface(API)は広範囲な支払い方法のために適合しなければなりません: (1) (2) Credit Card SETやサイバーコインのように基づくソフトウェア、モンデックスやGeldKarteのように基づくチップカード、振替のような典型的で伝統的な支払い方法の模倣(口座自動引き落とし)が預ける(3)、退出、銀行両替所、および値は指します。 それは明白な消費者との両方の支払いが承諾するサポートと自動繰り返された支払いがそうするべきです。(支払いは消費者があらかじめ承認したということです)。 SETの詳しい情報に関しては、[SET]を見てください。
The following discussion focuses on the Consumer's point of view and uses the associated terminology. When switching to Merchants' or Delivery Handlers' IOTP aware applications, the payment related components should be implicitly renamed by Existing Legacy Systems to the IOTP Middle-ware.
以下の議論は、Consumerの観点に焦点を合わせて、関連用語を使用します。 MerchantsかDelivery HandlersのIOTPに意識しているアプリケーションを切り換えるとき、支払い関連するコンポーネントはIOTP Middle-商品へのExisting Legacy Systemsによってそれとなく改名されるはずです。
Hans, et al. Informational [Page 4] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[4ページ]のRFC3867支払いAPI
The next two sub-sections describe the general payment scenario and several assumptions about the coarsely sketched software components.
次の2つの小区分が粗末にスケッチされたソフトウェアコンポーネントに関する一般的な支払いシナリオといくつかの仮定について説明します。
Section 2 illustrates the payment transaction progress and message flow of different kinds of transaction behavior. Sections 3 to 4 provide the details of the API functions and Section 5 elaborates the call back interface.
セクション2は異種のトランザクションの振舞いの支払処理進歩とメッセージ流動を例証します。 セクション3〜4はAPI関数の詳細を明らかにします、そして、セクション5は呼び出しの逆インタフェースを練ります。
1.1. General payment phases
1.1. 一般支払いフェーズ
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
または、識別Authentication要求の互いのPayment Handler Generation、資力要求、いくつかの自己の一回だけの要求と世代までの一回だけの初期設定Consumer Responses
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
支払い(Consumerの電子マネーの予約による)支払いHandler Acceptanceへの承認要求(消費者のための)消費者Agreementの承認Payment Handler Generationか協定の拒絶(消費者の承認応答)と、承認要求の世代(発行人/アクワイアラのための)と、応答の処理
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
Payment Handler Acceptanceが請求された捕獲要求(発行人/アクワイアラのための)消費者IsのGenerationか電子マネーの拒絶を得てください、支払処理の閉鎖
Reversal On rejection (online/delayed):
generation of the reversal data
Consumer Receipt of the refund
反転On拒絶(オンラインの、または、遅れた): 還付の反転データConsumer Receiptの世代
Hans, et al. Informational [Page 5] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[5ページ]のRFC3867支払いAPI
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不足の間で本国行きのメカニズムを区別しないでください、または○ 限られた異形を実装しないでください。
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.
このモデルは典型的なポイントの販売での支払いだけに適用するのではなく、還付、預金、退出、電子小切手、口座自動引き落とし、および振替に達します。
1.2. Assumptions
1.2. 仮定
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 Payment BridgeはIOTP Application Coreによって転送される支払いプロトコルメッセージの何らかの入力系列を処理します。 それ、(1)はメッセージを分解して、(2)はExisting Payment Softwareの形式にそれらを写像して、(3)は応答を組み立てて、(4)はわかりやすいトランスミッションのためにIOTP Application CoreによっていくつかのIOTPの意識しているリモートパーティーにほとんど意図される支払いプロトコルメッセージの別の系列を返します。 通常、Payment HandlerのPayment 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 1IOTP Application Coreが複数のIOTP Paymentブリッジスを管理するかもしれません、そして、後者は複数のIOTP Application Coresの間で共有されるかもしれません。o Each Payment Bridgeは複数のExisting Payment Softwareモジュールを管理するかもしれません、そして、後者は平等に割り当てられて、複数のPaymentブリッジスo Each Existing Payment Softwareが複数の支払い体系(例えば、SET)を管理するかもしれなくて、後者が複数のExisting Payment Softwareモジュールでサポートされるかもしれないということであるかもしれません。 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を通したVisa)であるとサポートするかもしれません、そして、後者は複数のExisting Payment Software Componentsによって共有されるかもしれません。
Hans, et al. Informational [Page 6] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[6ページ]のRFC3867支払いAPI
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant)
( contains Internet ( contains
IOTP Application Core) IOTP Application Core)
^ ^
| IOTP Payment | IOTP Payment
| API | API
v v
IOTP Payment Bridge IOTP Payment Bridge
^ ^
| Existing Payment APIs, e.g., |
| SET, Mondex, etc. |
v v
Existing Payment Software Existing Payment Software
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*クライアント..消費者--------------->IOTPサーバ(商人)(インターネット(IOTP Application Coreを含んでいる)IOTP Application Coreを含んでいます)^ ^| IOTP支払い| IOTP支払い| API| API v対IOTP Payment Bridge IOTP Payment Bridge^ ^| 例えば、既存のPayment API| | セット、モンデックスなど | 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:
Payment APIは、Baseline IOTPの以下のトランザクションタイプであると考えます:
o Baseline Purchase,
o Baseline Refund,
o Baseline Value Exchange,
o Baseline Withdrawal, and
o Baseline (Payment) Inquiry.
o 基線Purchase、o Baseline Refund、o Baseline Value Exchange、o Baseline Withdrawal、およびo Baseline(支払い)問い合せ。
For more information on Baseline IOTP, see [IOTP] and [IOTPBOOK].
Baseline IOTPの詳しい情報に関しては、[IOTP]と[IOTPBOOK]を見てください。
First, the authors' vision of the IOTP aware application's and its main components' capabilities are clarified: On the one hand, the Payment API should be quite powerful and flexible for sufficient connection of the generic and specific components. On the other hand, the Payment API should not be overloaded with nice-to-haves being unsupported by Existing Payment Software.
最初に、作者のアプリケーションとその主なコンポーネントの能力がはっきりさせられるのを意識しているIOTPのビジョン: 一方では、ジェネリックと特定のコンポーネントの十分な接続に、Payment APIは、かなり強力であって、フレキシブルであるべきです。 他方では、有産階級に楽しい存在がサポートされない状態でExisting Payment SoftwareはPayment 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.
うまくいっている支払いの処理での強い類似性にもかかわらず、失敗解決と調査能力が異なる、非常に、異なった支払い体系の中で。 これらの局面は、異なった支払い器具の間で同じ支払い体系を使用することで異なりさえするかもしれません。 さらに、Consumers、Merchants、およびPayment Handlersに関する決められた一定の要求は変化と複雑さを加えます。 したがって、思い描かれて、複合体と支払いが特定の問い合せ、故障解析、および失敗解決を計画しますが、IOTP Application Coreが非常に基本的な問い合せメカニズムだけを提供するのは、実際のExisting Payment Softwareに完全に延期されています--ユーザーインタフェースを含んでいるということです。
Hans, et al. Informational [Page 7] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[7ページ]のRFC3867支払いAPI
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 Application Coreは透過的に支払いを処理します、すなわち、それが関連IOTP Payment Bridge/既存のPayment Softwareへの特定のメッセージを包装された支払い体系に転送します。 Existing Payment Softwareは本国行きの失敗解決にこれらのメッセージを使用さえするかもしれません。 それは、IOTP Application Coreかある中間的への最終的な支払い状態だけ--また、最終的であるかもしれないと報告します--異常な中断の状態。
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 Application Coreはジェネリックと支払い体系がIOTPトランザクション処理の独立している部分であると実装して、適当なユーザーインタフェースを前提とします。 支払いに焦点を合わせるのがタスクについて話した、それ
o manages the registered IOTP Payment Bridges and provides a
mechanism for their registration - the latter is omitted by this
document.
o 登録されたIOTP Paymentブリッジスを管理して、提供する、彼らの登録のためのメカニズム--後者はこのドキュメントによって省略されます。
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 Payment Bridgeも受動素子であり、すなわち、厳密に入力データを待って、それぞれ要求する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 支払請求書に先行しながら、支払いが交渉(消費者: 実際の支払い器具かメソッドの選択; 商人: Consumerに提供される支払い方法の品揃え)であるとサポートします。
o requests additional payment specific support from the Existing
Payment Software via the selected and registered the IOTP Payment
Bridge,
o 選択され登録にされるを通したExisting Payment Software IOTP Payment Bridgeから追加支払金の特定のサポートを要求します。
o initializes and terminates the Existing Payment Software via the
IOTP Payment Bridge,
o IOTP Payment Bridgeを通してExisting Payment Softwareを初期化して、終えます。
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 Existing Payment Software、特定の認証コンポーネント(本書では省略される)またはConsumer(適当なユーザーインタフェースによる)から認証データについて問い合わせます(その後の要求か応答のために)。
o supervises the online transaction process and traces its progress,
o オンライン・トランザクションプロセスを監督して、進歩をたどります。
o stores the transaction data being exchanged over the IOTP wire -
payment scheme specific data is handled transparently,
o IOTPの上と交換して、配線してください--支払いの体系の特定のデータが透過的に扱われるということである変更用データを保存します。
o relates each payment transaction with multiple payment parameters
(IOTP Transaction Identifier, Trading Protocol Options, Payment
Instrument/Method, Offer Response, IOTP Payment Bridge, and Wallet
Identifier, associated remote Parties). The relation might be
o 複数の支払いパラメタ(IOTP Transaction Identifier(TradingプロトコルOptions、Payment Instrument/メソッド、Offer Response、IOTP Payment Bridge、およびWallet Identifier)はリモート党を関連づけた)に各支払処理を関連づけります。 関係はそうです。
Hans, et al. Informational [Page 8] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[8ページ]のRFC3867支払いAPI
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.
実際の支払処理が首尾よく始められたとき、パーティーのPayment Identifier、IOTP Payment Bridge、Wallet Identifier、およびリモートパーティーに下ろされます。
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 支払いの特定の処理、指揮、合法化、および誤り解決をExisting Payment Softwareに延期します。 それは予想されて、Existing Payment Softwareが最初に、Payment Exchangeの拡張交換で多くの誤りを決議しようとするのは通信します。 最も重要で目に見える失敗は地方の、または、反対している支払いコンポーネントの突然の使用不能か過失から起こります。
o supports the invocation of any Existing Payment Software in an
interactive mode, which might be used (1) for the payment scheme
specific post-processing of a (set of) payment transactions, (2)
for the analysis of a payment instrument, (3) for the registration
of a new payment instrument/scheme, or (4) re-configuration of a
payment instrument/scheme.
o (セットされます)支払処理の支払いの体系の特定の後工程の間の中古の(1)、支払い器具の分析、新しい支払い器具/体系の登録のための(3)、または支払い器具/体系の(4)再構成のための(2)であるかもしれない会話型によるどんなExisting Payment Softwareの実施もサポートします。
o exports call back functions for use by the IOTP Payment Bridge or
Existing Payment Software for progress indication.
o 輸出はIOTP Payment BridgeかExisting Payment Softwareによる進歩指示の使用のために機能に電話し直します。
In addition, the IOTP Application Core
追加、IOTP Application Coreで
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メッセージブロックを管理します。 特に、それは支払いの間に交換された命名されたPackaged Content要素を保存します。
o manages several kinds of identifiers, i.e., transaction, message,
component, and block identifiers,
o 数種類の識別子、すなわち、トランザクション、メッセージ、コンポーネント、およびブロック識別子を管理します。
o implements a message caching mechanism,
o メカニズムをキャッシュするメッセージを実装します。
o detects time-outs at the protocol and API level reflecting the
communication with both the IOTP aware remote party and the
Payment API aware local periphery, e.g., chip card (reader) may
raise time-outs.
o プロトコルとAPIレベルにおけるタイムアウトがIOTPの意識しているリモートパーティーとPayment APIの地方の周辺、例えば、チップカード(読者)がタイムアウトを上げるかもしれないのを意識している両方とのコミュニケーションを反映するのを検出します。
Hans, et al. Informational [Page 9] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[9ページ]のRFC3867支払い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 Payment BridgeとExisting Payment SoftwareはこれらのIOTP Application Coreの能力のすべてを当てにする必要はありません。 例えばいくらかのConsumerのExisting Payment Softwareは、ブランド選択時間に特定の支払い器具の公開を拒否して、それ自身のユーザーインタフェースを使用することで「チェック支払いの可能性」実施にこの選択を遅らせるかもしれません。
The IOTP Payment Bridge's capabilities do not only deal with actual payments between the Consumer and the Payment Handler but extend to the following:
IOTP Payment Bridgeの能力はConsumerとPayment Handlerの間の実際の支払いに対処するだけではなく、以下に達します:
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 Payment APIの形式の間のメッセージの翻訳と(けなします)アサンブラージュとExisting Payment Softwareのもの。 支払い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 支払いブランド、支払いプロトコル、および支払い器具(識別子)の関係の非機密保護しているか公共の輸出品の手段による消費者の支払い器具選択。 一般に、これはブランド(モンデックス、GeldKarteなど)だけではなく、使用する器具と通貨のどの特定のインスタンス(例えば、どの特定のモンデックスカードとすべての利用可能なそれらのどの通貨)も含んでいるか。
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).
しかしながら、いくらかのExisting Payment Softwareが実際の支払い搬出に支払い器具の選択を延期するかもしれませんか、またはそれは支払い器具のどんな管理も欠きさえするかもしれません。 例えば、ベースの支払い方法が提供するかもしれないカードを欠いてください--銀行POSは好きです--チップカードリーダかそれへのチップカードの単純艘入による支払い器具の暗黙の選択が挿入されたカードと要求について査問する、(s)に器具を取り付けるように検出された支払いを承諾してください(または、選択)。
o payment progress checks, e.g., is there enough funds available to
carry out the purchase, or enough funds left for the refund,
o 支払い進歩はチェックします、例えば、購買を行うために利用可能な基金、または十分な基金が還付のままで十分残っています。
o IOTP Payment Receipt checks which might be performed over its
Packaged Content or by other means.
o IOTP Payment Receiptは、どれがPackaged Contentの上、または、他の手段で実行されるかもしれないかをチェックします。
o recoding of payment scheme specific receipts into a format which
can be displayed to the user or printed,
o recoding of payment scheme specific receipts into a format which can be displayed to the user or printed,
o cancellation of payment, even though it is not complete,
o cancellation of payment, even though it is not complete,
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 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.
Hans, et al. Informational [Page 10] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 10] RFC 3867 Payment API for IOTP November 2004
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 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 payment transaction status inquiry, so that the inquirer - IOTP
Application Core or User - can determine the appropriate next
step.
o payment transaction status inquiry, so that the inquirer - IOTP Application Core or User - can determine the appropriate next step.
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 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 inquiry on abnormal interrupted payment transactions, which might
be used by the IOTP Application Core to resolve these pending
transactions at startup (after power failure).
o inquiry on abnormal interrupted payment transactions, which might be used by the IOTP Application Core to resolve these pending transactions at startup (after power failure).
o payment progress indication. This could be used to inform the end
user of details on what is happening with the payment.
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 payment method specific authentication methods.
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).
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).
The Existing Payment Software's capabilities vary extremely. It
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 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 provides hints for out-of-band failure resolution on failed
inbound resolution - inbound resolution is invisible to the IOTP
Application Core.
o provides hints for out-of-band failure resolution on failed inbound resolution - inbound resolution is invisible to the IOTP Application Core.
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 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.
Hans, et al. Informational [Page 11] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 11] RFC 3867 Payment API for IOTP November 2004
o implements the payment scheme specific dialog boxes.
o implements the payment scheme specific dialog boxes.
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.
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.
2. Message Flow
2. Message Flow
The following lists all functions of the IOTP Payment API:
The following lists all functions of the IOTP Payment API:
o Brand Compilation Related API Functions
o Brand Compilation Related API Functions
"Find Accepted Payment Brand" identifies the accepted payment brands for any indicated currency amount.
"Find Accepted Payment Brand" identifies the accepted payment brands for any indicated currency amount.
"Find Accepted Payment Protocol" identifies the accepted payment protocols for any indicated currency amount (and brand) and returns payment scheme specific packaged content for brand selection purposes.
"Find 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.
This function might be used in conjunction with the aforementioned function or called without any brand identifier.
"Get Payment Initialization Data" returns additional payment scheme specific packaged content for payment processing by the payment handler.
"Get Payment 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.
"Inquire Authentication Challenge" returns the payment scheme specific authentication challenge value.
"Check Authentication Response" verifies the returned payment scheme specific authentication response 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).
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
o Brand Selection Related API Functions
o Brand Selection Related API Functions
"Find Payment Instrument" identifies which instances of a payment instrument of a particular payment brand are available for use in a payment.
"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.
"Check Payment Possibility" checks whether a specific payment instrument is able to perform a payment.
Hans, et al. Informational [Page 12] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 12] RFC 3867 Payment API for IOTP November 2004
"Authenticate" forwards any payment scheme specific authentication data to the IOTP Payment Bridge for processing.
"Authenticate" forwards any payment scheme specific authentication data to the IOTP Payment Bridge for processing.
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
"Change Process State" is used (here only) for abnormal termination. (cf. Payment Processing Related API Functions).
o Payment Processing Related API Functions
o Payment Processing Related API Functions
"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.
"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.
"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.
"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.
"Change Process State" changes the current status of payment transactions. Typically, this call is used for termination or suspension without success.
o General Inquiry API Functions
o General Inquiry API Functions
"Remove Payment Log" notifies the IOTP Payment Bridge that a particular entry has been removed from the Payment Log of the IOTP Application Core.
"Remove Payment Log" notifies the IOTP Payment Bridge that a particular entry has been removed from the Payment Log of the IOTP Application Core.
"Payment Instrument Inquiry" retrieves the properties of Payment Instruments.
"Payment Instrument Inquiry" retrieves the properties of Payment Instruments.
"Inquire Pending Payment" reports any abnormal interrupted payment transaction known by the IOTP Payment Bridge.
"Inquire Pending Payment" reports any abnormal interrupted payment transaction known by the IOTP Payment Bridge.
Payment Processing Related Inquiry API Functions
Payment Processing Related Inquiry API Functions
"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.
"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.
"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.
"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.
"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.
"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.
Hans, et al. Informational [Page 13] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 13] RFC 3867 Payment API for IOTP November 2004
"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.
"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.
"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)
"Continue Process" and "Change Process State" (cf. Payment Processing Related API Calls)
o Other API Functions
o Other API Functions
"Manage Payment Software" enables the immediate activation of the Existing Payment Software. Further user input is under control of the Existing Payment Software.
"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.
"Call Back" provides a general interface for the visualization of transaction progress by the IOTP Application Core.
The following table shows which API functions must (+), should (#), or might (?) be implemented by which Trading Roles.
The following table shows which API functions must (+), should (#), or might (?) be implemented by which Trading Roles.
API function Consumer Payment Handler Merchant ------------ -------- --------------- --------
API function Consumer Payment Handler Merchant ------------ -------- --------------- --------
Find Accepted Payment Brand + Find Accepted Payment Protocol # Find Payment Instrument +
Find Accepted Payment Brand + Find Accepted Payment Protocol # Find Payment Instrument +
Get Payment Initialization Data + Check Payment Possibility +
Get Payment Initialization Data + Check Payment Possibility +
Start Payment Consumer + Start Payment Payment Handler + Resume Payment Consumer # Resume Payment Payment Handler #
Start Payment Consumer + Start Payment Payment Handler + Resume Payment Consumer # Resume Payment Payment Handler #
Continue Process + + Inquire Process State + + ? Change Process State + + ? Check Payment Receipt + ? Expand Payment Receipt # ?
Continue Process + + Inquire Process State + + ? Change Process State + + ? Check Payment Receipt + ? Expand Payment Receipt # ?
Remove Payment Log ? ? ?
Remove Payment Log ? ? ?
Inquire Authentication Challenge ?
Inquire Authentication Challenge ?
Hans, et al. Informational [Page 14] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 14] RFC 3867 Payment API for IOTP November 2004
Authenticate + Check Authentication Response ?
Authenticate + Check Authentication Response ?
Payment Instrument Inquiry ? Inquire Pending Payment # # Start Payment Inquiry ? Inquire Payment Status ?
Payment Instrument Inquiry ? Inquire Pending Payment # # Start Payment Inquiry ? Inquire Payment Status ?
Manage Payment Software # ? ?
Manage Payment Software # ? ?
Call Back #
Call Back #
Table 1: Requirements on API Functions by the Trading Roles
Table 1: Requirements on API Functions by the Trading Roles
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.
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.
2.1. Authentication Documentation Exchange
2.1. Authentication Documentation Exchange
This section describes how the functions in this document are used together to process authentication.
This section describes how the functions in this document are used together to process authentication.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Authenticator Inquire Authentication Challenge(Alg1*) -> IPB
Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB
. . .
Inquire Authentication Challenge(Algn*) -> IPB
Inq. Auth. Challenge Response(Algn,Chn) <- IPB
Create and transmit Authentication Request Block
Authenticatee Authenticate(Alg1, Ch1) -> IPB
AuthenticateResponse(...) <- IPB
. . .
Authenticate(Algm, Chm) -> IPB
AuthenticateResponse(Res) <- IPB
Create and transmit Authentication Response Block
Authenticator Check Authentication Response(Algm,Chm,Res)->IPB
Check Auth. Response() <-IPB
Create and transmit Authentication Status Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Authenticator Inquire Authentication Challenge(Alg1*) -> IPB Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB . . . Inquire Authentication Challenge(Algn*) -> IPB Inq. Auth. Challenge Response(Algn,Chn) <- IPB Create and transmit Authentication Request Block Authenticatee Authenticate(Alg1, Ch1) -> IPB AuthenticateResponse(...) <- IPB . . . Authenticate(Algm, Chm) -> IPB AuthenticateResponse(Res) <- IPB Create and transmit Authentication Response Block Authenticator Check Authentication Response(Algm,Chm,Res)->IPB Check Auth. Response() <-IPB Create and transmit Authentication Status Block *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 2. Authentication Message Flows
Figure 2. Authentication Message Flows
Hans, et al. Informational [Page 15] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 15] RFC 3867 Payment API for IOTP November 2004
1. (Authenticator Process) None, one or multiple IOTP Payment Bridges
(IPB) are requested for one or multiple authentication challenge
values ("Inquire Authentication Challenge"). Each value is
encapsulated in an IOTP Authentication Request Component. In
addition, the IOTP Application Core may add payment scheme
independent authentication methods. All of them form the final
IOTP Authentication Request Block, which describes the set of
authentication methods being supported by the authenticator and
from which the Authenticatee has to choose one method.
1. (Authenticator Process) 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.
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*}).
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*}).
During the registration of new Payment Instruments, the IOTP
Payment Bridge notifies the IOTP Application Core about the
supported authentication algorithms.
During the registration of new Payment Instruments, the IOTP Payment Bridge notifies the IOTP Application Core about the supported authentication algorithms.
2. On the presence of an IOTP Authentication Block within the
received IOTP message, the Authenticatee's IOTP Application Core
checks whether the IOTP transaction type in the current phase
actually supports the authentication process.
2. 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.
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.
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.
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.
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.
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.
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.
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.
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.
Hans, et al. Informational [Page 16] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 16] RFC 3867 Payment API for IOTP November 2004
3. (Authenticator Process) The IOTP Application Core checks the
presence of the IOTP Authentication Response Component in the
Authentication Response Block and forwards its content to the
generator of the associated authentication challenge for
verification ("Check Authentication Response").
3. (Authenticator Process) 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").
On sole organizational data request, its presence is checked.
On sole organizational data request, its presence is checked.
Any verification must succeed in order to proceed with the
transaction.
Any verification must succeed in order to proceed with the transaction.
2.2. Brand Compilation
2.2. Brand Compilation
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.
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.
Hans, et al. Informational [Page 17] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 17] RFC 3867 Payment API for IOTP November 2004
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant For each registered IOTP Payment Bridge
| Find Accepted Payment Brand() -> IPB
| Find Accepted Payment Brand Response (B*) <- IPB
| Find Accepted Payment Protocol(B1) -> IPB
| Find Accepted Payment Protocol Res.(P1*) <- IPB
| . . .
| Find Accepted Payment Protocol(Bn) -> IPB
| Find Accepted Payment Protocol Res.(Pn*) <- IPB
Create one Brand List Component, ideally sharing
common Brand, Protocol Amount, Currency Amount,
and Pay Protocol Elements
Create Trading Protocol Options Block
On brand independent transactions
| Create Brand Selection Component, implicitly
| Get Payment Initialization Data(B1,P1) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
Transmit newly created Block(s)
Consumer Consumer selects Brand (Bi)/Currency/Protocol (Pj)
from those that will work and generates Brand
Selection Component - at least logically
On brand dependent transaction
| Transmit Brand Selection Component
Merchant On brand dependent transaction
| Get Payment Initialization Data(Bi,Pj) -> IPB
| Get Payment Initialization Data Res.() <- IPB
| Optionally
| | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB
| Create Offer Response Block
| Transmit newly created Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Merchant For each registered IOTP Payment Bridge | Find Accepted Payment Brand() -> IPB | Find Accepted Payment Brand Response (B*) <- IPB | Find Accepted Payment Protocol(B1) -> IPB | Find Accepted Payment Protocol Res.(P1*) <- IPB | . . . | Find Accepted Payment Protocol(Bn) -> IPB | Find Accepted Payment Protocol Res.(Pn*) <- IPB Create one Brand List Component, ideally sharing common Brand, Protocol Amount, Currency Amount, and Pay Protocol Elements Create Trading Protocol Options Block On brand independent transactions | Create Brand Selection Component, implicitly | Get Payment Initialization Data(B1,P1) -> IPB | Get Payment Initialization Data Res.() <- IPB | Optionally | | Inquire Process State() -> IPB | | Inquire Process State Response(State) <- IPB | Create Offer Response Block Transmit newly created Block(s) Consumer Consumer selects Brand (Bi)/Currency/Protocol (Pj) from those that will work and generates Brand Selection Component - at least logically On brand dependent transaction | Transmit Brand Selection Component Merchant On brand dependent transaction | Get Payment Initialization Data(Bi,Pj) -> IPB | Get Payment Initialization Data Res.() <- IPB | Optionally | | Inquire Process State() -> IPB | | Inquire Process State Response(State) <- IPB | Create Offer Response Block | Transmit newly created Block *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 3. Brand Compilation Message Flows
Figure 3. Brand Compilation Message Flows
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. 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.
Hans, et al. Informational [Page 18] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 18] RFC 3867 Payment API for IOTP November 2004
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. 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, ....).
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. 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.
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.
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. 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.
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.
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.
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.
5. The steps 3 and 4 are repeated during IOTP Value Exchange
transactions - these steps are omitted in the previous figure.
5. The steps 3 and 4 are repeated during IOTP Value Exchange transactions - these steps are omitted in the previous figure.
6. The IOTP Application Core compiles the Brand List Component(s)
and the IOTP Trading Protocol Options Block. It is recommended
that the "equal" items returned by IOTP Payment Bridge function
calls are shared due to the extensive linking capabilities within
6. 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
Hans, et al. Informational [Page 19] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 19] RFC 3867 Payment API for IOTP November 2004
the Brand List Component. However, the compilation must consider
several aspects in order to prevent conflicts - sharing detection
might be textual matching (after normalization):
the Brand List Component. However, the compilation must consider several aspects in order to prevent conflicts - sharing detection might be textual matching (after normalization):
o Packaged Content Elements contained in the Brand List Component
(and subsequently generated Payment and Order Components) might
be payment scheme specific and might depend on each other.
o 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 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 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 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 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.
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.
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.
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. The IOTP Application Core determines whether the IOTP message can be enriched with an Offer Response Block. This is valid under the following conditions:
o All payment alternatives share the attribute values and
Packaged Content Elements of the subsequently generated IOTP
Payment and Order Components.
o All payment alternatives share the attribute values and Packaged Content Elements of the subsequently generated IOTP Payment and Order Components.
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 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.
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.
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.
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.
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.
As in step 6, the rules and mechanisms of how this could be
accomplished are out of the scope of this document.
As in step 6, the rules and mechanisms of how this could be accomplished are out of the scope of this document.
Hans, et al. Informational [Page 20] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 20] RFC 3867 Payment API for IOTP November 2004
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. 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.
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. 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.
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 Application CoreはIOTP Payment Bridge(「支払い初期設定データを得る」)から残っている支払い体系特定の支払い初期化データを要求して、IOTP Offer Response Blockをコンパイルして、それをConsumerに伝えて、終わります。 Step7のように、IOTP Application Coreは発送状況の編集のためにIOTP Payment Bridgeの現在のプロセス州にアクセスするかもしれません。
Any error during this process raises an IOTP Error Block.
このプロセスの間のどんな誤りもIOTP Error Blockを上げます。
2.3. Brand Selection
2.3. ブランド選択
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).
このセクションは主にマーチャントのBrand Compilation(ブランドの独立しているトランザクションにおける)の後に起こるステップについて説明します。 しかしながら、これらのステップは前のプロセス(ブランドの依存するトランザクションにおける)を部分的に交錯させるかもしれません。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*商人..マーチャント..生成する..含む..プロトコル..商標を付ける..独立..トランザクション| 商人は、Offer Response Block Consumer Compileが各セットのためのBrands B/プロトコルPのセットであると生成します。| 支払い器具(B、P、C)->IPBを見つけてください。| 掘り出し物のPayment Instrument Response(PI*)<IPB Consumerは働いているものからBrand/通貨/支払いInstrumentを選択して、Brand Selection Component ForにSelectionを生成します。| 支払い初期設定データ(B、C、パイ、P)->IPBを手に入れてください。| Data Response()<-IPB Onが商標を付けるPayment初期設定に依存するトランザクションを得てください。| TPO Selection BlockマーチャントOnブランドに依存するトランザクションを生成して、伝えてください。| 商人がBrand Selectionをチェックする、生成する。| 伝える
Hans, et al. Informational [Page 21] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[21ページ]のRFC3867支払いAPI
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. Consumerがショッピングカートを調べて、彼の支払い意志を示すまで、マーチャントのコマースサーバはそれ自身のメカニズムで買い物対話を制御します。 その後の処理はマーチャントの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 Application Coreはマーチャントの受け入れられた支払いブランドと支払いプロトコルを列挙するIOTP Brand List Component(s)を含むIOTP TradingプロトコルOptions Blockをコンパイルして、Brand Selectionプロセスを開始します。
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メッセージはConsumerのIOTPの意識しているアプリケーションを起動します、例えば、ウェブブラウザが支援アプリケーション(例えば、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 Paymentブリッジスを決定します。
o compiles one or multiple sets of brand and protocol such that
the join of all sets describes exactly the payment alternatives
being offered by the Merchant.
o すべてのセットに加わってください。1か複数のセットのブランドをコンパイルして、そのようなものについて議定書の中で述べる、それ、マーチャントによって提供されながら、まさに支払い代替手段を説明します。
o inquires payment (protocol) support and the known payment
instruments from each registered IOTP Payment Bridge for each
compiled set ("Find Payment Instrument"). However, some IOTP
Payment Bridges may refuse payment instrument distinction.
o それぞれのコンパイルされたセット(「支払い器具を見つける」)のためにそれぞれの登録されたIOTP Payment Bridgeから支払い(プロトコル)サポートと知られている支払い器具について問い合わせます。 しかしながら、IOTP Paymentブリッジスは支払い器具区別を拒否するかもしれません。
The payment protocol support may differ between payment
instruments if the IOTP Payment Bridge supports payment instrument
distinction.
IOTP Payment Bridgeが支払い器具区別をサポートするなら、支払いプロトコルサポートは支払い器具の間で異なるかもしれません。
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 Application Coreは財布識別子を提供しなければなりません、それらがIOTP Paymentブリッジスによって要求されるなら(特定のエラーコードで彼らの必要性に合図します)(以下を見てください)。
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 Application Coreが財布識別子を管理するのは、お勧めです。 しかし、安全保障上の理由で、それはランタイムメモリだけのプレーンテキストのパス句を保存するべきです。 IOTPの開発者
Hans, et al. Informational [Page 22] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[22ページ]のRFC3867支払いAPI
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 Application Coreはマーチャントの受け入れられた支払いブランドと通貨があるConsumerの支払い能力について確かめます。
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 Consumerの選択を要求するか、またはどんな構成された好みからもそれを自動的に得ます。 どんな選択も以下の支払処理で1IOTP Payment Bridgeを結びます。
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.
Step3の問い合せの間の入手できないIOTP Paymentブリッジスの取り扱いと解決はIOTP Application Core次第です。 それは、これらのIOTP Paymentブリッジスをスキップするか、または解決であるとサポートされたユーザを許容するかもしれません。
Furthermore, it may offer the registration of new payment
instruments when the Consumer is asked for payment instrument
selection.
支払い器具選択をConsumerに求めるとき、その上、それは新しい支払い器具の登録を提供するかもしれません。
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 Application Coreは固定IOTP Payment Bridgeについて査問します。 このステップでは、IOTP Payment Bridgeは例えばいくつかの信号を支給するかもしれません。
o payment can proceed immediately,
o required peripheral inclusive of some required physical payment
instrument (chip card) is unavailable,
o (non-IOTP) remote party (e.g., issuer, server wallet) is not
available,
o wallet identifier or pass phrase is required,
o expired payment instrument (or certificate), insufficient
funds, or
o physical payment instrument unreadable.
o ○ ある必要な物理的な支払い器具(チップカード)を包含必要な周辺機器が入手できません、o(非IOTP)リモートパーティー(例えば、発行人、サーバウォレット)が手があいていない、支払いはすぐに続くことができて、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 または問題を解決するか、例えば別の支払い器具を挿入するか、または周辺、続かせる(成功を仮定します)○、全体のトランザクションを取り消すoについて確かめる。
Hans, et al. Informational [Page 23] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[23ページ]のRFC3867支払いAPI
o to suspend the transaction, e.g., initiating a nested
transaction for uploading an electronic purse.
o トランザクションを中断させるために、例えば、aを開始すると、トランザクションは電子財布をアップロードするために入れ子にされました。
If the payment software implements payment instrument selection on
its own, it may request the Consumer's choice at this step.
支払いソフトウェアがそれ自身のところで支払い器具選択を実装するなら、それはこのステップでConsumerの選択を要求するかもしれません。
If the check succeeds, it returns several IOTP Brand Selection
Info Elements.
チェックが成功するなら、それは数個のIOTP Brand Selection Info Elementsを返します。
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. Steps2〜5は繰り返されて、2番目の支払い器具の選択のためにことによるとIOTP Value Exchangeトランザクションの間、交錯します--これは上の図形で省略されます。
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 Brand Selection ComponentはBrand Selection Info要素で生成されて、豊かにされます。 受信されたIOTPメッセージがIOTP Offer Response Blockを欠いているなら、このコンポーネントはTPO Selection Blockの中のマーチャントに伝えられます。 そして、マーチャントはIOTP Offer Response Blockと共に応じるでしょう(前述の編集規則に従って)。
2.4. Successful Payment
2.4. うまくいっている支払い
An example of how the functions in this document are used together to effect a successful payment is illustrated in the Figure 5. In the figure 5, PS0, PS1, ..., and PSn indicate the nth PayScheme Packaged Content data, and [ ] indicates optional.
機能がうまくいっている支払いに作用するのにどう本書では一緒に使用されるかに関する例は図5で例証されます。 5図、PS0、PS1で…, そして、PSnは任意の状態でPayScheme Packaged Contentデータ、および[ ]が示すn番目を示します。
(Technically, two payments happen during IOTP Value Exchange transactions.)
(技術的に、2つの支払いがIOTP Value Exchangeトランザクションの間、起こります。)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
*消費者..始め..支払い..消費者..量 ->IPBはPaymentコンズを始めます。 Res([PS1]、CsはContと等しいです。) <。 そして、IPB Create、Payment Request Block Payment Handler Start Payment Payを伝えてください。 操作者(量、[PS1])->IPBは支払いPH応答を始めます(PS2、CsはContと等しいです。)。 <。 IPB Create、Payment Exchange Block Consumer Continue Process(PS2)->IPB Continue Process Response(PS3、CS=Cont)を伝えてください。 <。 IPB
... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
... …まで支払い交換を交換し続けてください。
Payment Handler Continue Process Response([PSn], CS=End) <- IPB
Request any local payment receipt
| Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Create and transmit Payment Response Block
Terminate transaction, actively
終わり) 支払いHandler Continue Process Response[PSn]、<CS=IPB Requestはあらゆるローカルの支払い領収書です。| プロセス状態()->IPBについて問い合わせてください。| Procについて問い合わせてください。 活発にResp(状態、[Rcp]。)<IPB Createを述べてください、そして、Payment Response Block Terminateトランザクションを伝えてください。
Hans, et al. Informational [Page 24] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[24ページ]のRFC3867支払いAPI
| 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 Response(状態はCompletedOKと等しい)<最終的な支払い体系データのIPB Consumer On領収書| プロセス(PSn)->IPBを続けてください。| Process Response(CS=は終わります)<IPB Check Payment Receipt(領収書)->IPB Check Payment Receipt Response()<IPB Requestを続けてください、どんなローカルの支払い領収書| プロセス状態()->IPBについて問い合わせてください。| Procについて問い合わせてください。 州のResp活発な(状態、[Rcp]。)<IPB Terminateトランザクション| 変化プロセス州(状態)の->IPB| 変化..応答..状態..等しい
Figure 5. Example Payment Message Flows
図5。 例の支払いメッセージ流れ
1. After Brand Selection and receipt of the IOTP Offer Response
Block, the Consumer switches from communicating with the Merchant
to communicating with the Payment Handler.
1. IOTP Offer Response BlockのBrand Selectionと領収書の後に、Payment Handlerとコミュニケートすることによって、Consumerは切り替わります。
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.
これは支払処理の継続に関する更新されたConsumerの協定を必要とする重大事件であるかもしれません。 特に、これは支払いサスペンション(そして、キャンセルさえ)のための良い瞬間です。(それは、最もたぶんすべての支払い体系によって支えられるでしょう)。 実際の支払いレガシーシステムがまだ経常取引に絶対にかかわっていないので。
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.
それは想定されて、トランザクションが最小量のユーザ(消費者とPayment Handler)相互作用とそれで進歩を続かせるのはIOTP Application CoreとIOTP Payment Bridgeによって制御されます。
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 Application Coreは「スタート支払い消費者」要求をIOTP Payment Bridgeに向かって出します。 この要求はその後の一貫性チェックについてIOTP Payment Bridgeによって言及される支払処理の全体の初期化データを運びます:
o payment brand and its description from the selected Brand
Element of the IOTP Brand List Component,
o payment instrument from preceding inquiry step,
o 支払いブランドと問い合せに先行するのからのIOTP Brand List Componentの選択されたBrand Elementからの記述、o支払い器具は踏まれます。
Hans, et al. Informational [Page 25] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[25ページ]のRFC3867支払いAPI
o further payment parameters (currency, amount, direction,
expiration) from the selected Currency Amount element, Brand
List Component, and Payment Component of the IOTP Offer
Response Block,
o payment protocol from the selected IOTP Pay Protocol Element,
o order details contained in the IOTP Order Component which might
be payment scheme specific,
o payment scheme specific data inclusive of the payment protocol
descriptions from the IOTP Protocol Amount Element, and IOTP
Pay Protocol Element, and
o payment scheme specific data inclusive of the payment protocol
descriptions, in which the name attribute includes the prefix
as "Payment:" from the Trading Role Data Component.
o IOTP Offer Response Blockの選択されたCurrency Amount要素、Brand List Component、およびPayment Componentからのさらなる支払いパラメタ(通貨、量、方向、満了)、o支払いは選択されたIOTP PayプロトコルElementより議定書を作ります; ○ 支払い体系がIOTPプロトコルAmount Element、IOTP PayプロトコルElement、およびo支払いからの支払いプロトコル記述を包含特定の、そして、o支払い体系特有のデータであったかもしれないなら支払いプロトコル記述を包含特定のデータを計画するIOTP Order Componentに詳細を含むよう命令してください; 名前属性がどれとして接頭語を含んでいるか、「支払い:」 取り引き役割のデータ構成要素から。
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関数はPayment HandlerのIOTP Payment Bridgeのための支払いの特定の初期化データであるとみなされる特定のデータをさらなる支払い体系に返すかもしれません。
If the fixed Existing Payment Software implements payment
instrument selection on its own, it may request the Consumer's
choice at this step.
固定Existing Payment Softwareがそれ自身のところで支払い器具選択を実装するなら、それはこのステップでConsumerの選択を要求するかもしれません。
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 Payment Bridgeは全く同様にIOTP Application Coreへの「チェック支払いの可能性」要求に能力の不足を報告します。 Consumerが決めるかもしれない、トランザクションを続けるために問題を解決して、中断するか、またはしかし、トランザクション、このファンクションコールがそうしなければならないキャンセル引き継ぎます。
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 Payment Bridge要求財布識別子かパス句が処理されるなら、それらはこのAPI関数によっても要求されるべきです。 IOTP Application Coreがランタイムメモリだけのプレーンテキストパス句を保存するのは、お勧めです。
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 Application CoreはIOTP Payment Request Blockを生成して、どんな返された支払い体系データも挿入して、Payment Handlerのシステムにそれを提出します。
Hans, et al. Informational [Page 26] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[26ページ]のRFC3867支払いAPI
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. Payment HandlerのIOTP Application Coreは支払処理の呼ぶ「スタート支払い支払い操作者」API関数を開きます。 支払いブランド、記述、支払いプロトコル、支払いの特定のデータ、支払い方向、通貨、および支払い量はConsumerのIOTP Application Coreと全く同様の状態で決定しています。 その上、IOTP Payment Scheme Componentの内容とIOTP Brand Selection Info Elementsはこの機能に通過されます。
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.
成功では、Payment HandlerのIOTP Payment Bridgeは支払い体系で特定のデータを反応させます。 失敗では、この非インタラクティブのサーバ・アプリケーションは、それ自身のところのどんな問題も解決しなければならないか、または支払処理を中止するのをあきらめなければなりません。 しかしながら、Consumerは全体の支払処理を再開するかもしれません。 とにかく、支払いログファイルは支払いのどんなトライアルも反映するべきです。
Eventually, the Payment Handler informs the Consumer about the
current IOTP Process State using the IOTP Payment Response or IOTP
Error Block.
結局、Payment Handlerは、現在のIOTP Process州に関してIOTP Payment ResponseかIOTP Error Blockを使用することでConsumerに知らせます。
Note that the "Start Payment Payment Handler" call might return
the Continuation Status "End" such that payment processing
proceeds with Step 7.
「スタート支払い支払い操作者」呼び出しがContinuation Status「終わり」を返すかもしれないので支払処理がStep7を続けることに注意してください。
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 Application CoreはIOTPメッセージでのPayment Exchange Blockの存在について確かめて、次のIOTP Payment Scheme Componentを返す固定IOTP Payment Bridge(「プロセスを持続させる」)への特定のデータを含まれた支払い体系に通過します。
This Payment Scheme Component is encapsulated in an IOTP Payment
Exchange Block and transmitted to the Payment Handler.
このPayment Scheme ComponentはIOTP Payment Exchange Blockでカプセル化されて、Payment Handlerに伝えられます。
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. Payment HandlerのIOTP Application CoreはPayment Exchange Blockの存在について確かめて、カプセル化とトランスミッションのために次のIOTP Payment Scheme ComponentをConsumerに返す固定IOTP Payment Bridge(「プロセスを持続させる」)への特定のデータを含まれた支払い体系に通過します。
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 Payment Exchange Block交換を続行します。 各当事者(1)は透過的に「プロセスを持続させてください」というAPI関数を呼ぶ適切なIOTP Payment Bridgeに埋め込まれた支払い体系特定のデータを提出します、そして、(2)は返された支払い体系特定のデータをIOTP Payment Exchange Blockに包装します、そして、(3)はこのブロックをカウンター・パーティに伝えます。
Hans, et al. Informational [Page 27] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[27ページ]のRFC3867支払いAPI
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 Payment Response Blocks(Payment Handlerによって生成される)かIOTP Error Blocks(双方はそれらを生成するかもしれない)に変えられて、カウンター・パーティに伝えられる特定のエラーコードによって合図されます。
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. 結局、Payment HandlerのIOTP Payment Bridgeは「プロセスを持続させてください」の出力パラメタに関して支払処理の終了を認識して、継続状態「終わり」までにこれを報告します(「支払い支払い操作者を始めてください」)。 次に、IOTP Application Coreは、「プロセス状態について問い合わせてください」というAPI呼び出しを発行して、IOTP Payment Receipt Componentが返されたかどうか確かめます。 IOTP Application CoreはIOTP Payment Response Blockで支払い受領、状態応答、および任意の支払い体系特定のデータを包装して、このブロックをConsumerに伝えます。
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呼び出しのどれかは失敗するかもしれませんか、またはどんな応答も不完全であるかもしれません(例えば、支払い領収書の不足)。 そして、Consumerは失敗した処理に関してIOTP Error Blockによって通知されなければなりません。
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.
最終的に、Consumerからどんなさらなる応答も待たないで、Payment Handlerは「変化プロセス状態」API呼び出しで支払処理を終えます。 さらなる失敗はConsumerに報告されません。
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.
ConsumerのIOTP Payment Bridgeが継続状態「終わり」がある特定のデータを前の支払い体系に返したのが、可能であるかもしれないことに注意してください。 この状態がConsumerとPayment Handlerの間で交換されないというこの知識がないときでさえ、Payment Handlerはどんなさらなる支払い体系にも特定のデータを提供してはいけません。 そのようなデータはConsumerのIOTP Payment Bridgeによって拒絶されるでしょう。
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. Consumerは「プロセスを持続させてください」と「チェック支払い領収書」API呼び出しで固定IOTP Payment Bridgeへの特定のデータと支払い領収書を任意の支払い体系に渡します。
Afterwards, the IOTP Application Core issues the "Inquire Process
State" API call and verifies whether extensions to the payment
receipt have been returned.
その後、IOTP Application Coreは、「プロセス状態について問い合わせてください」という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機能を呼ぶことによって終えられて、どんな矛盾も示します。 どんなInconsistencyと返された状態テキストもConsumerに表示するべきです。
Hans, et al. Informational [Page 28] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[28ページ]のRFC3867支払い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.
ここに、支払処理はPayment Handlerによって既に終えられました。 したがって、どんな失敗も局所的かバンドの外で決議されなければなりません。
2.5. Payment Inquiry
2.5. 支払い問い合せ
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.
Baseline IOTPでは、Payment問い合せは、リモートPayment Handlerで現在の支払い進歩とプロセス状態について確かめるためにConsumerによって開始されます。 図では、6、PS1、およびPS2は任意の状態でPayScheme Packaged Contentデータ、および[ ]が示す1番目と2番目を示します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Inquiry() -> IPB
Start Payment Inquiry Response([PS1]) <- IPB
Create and transmit Inquiry Request Trading Block
Payment Handler Inquire Payment Status([PS1]) -> IPB
Inquire Payment Status Res.(State, [PS2]) -> IPB
Create and transmit Inquiry Response Trading
Block
Consumer If Payment Scheme Data present
| Continue Process(PS2) -> IPB
| Continue Process Response(CS=End) <- IPB
Change Process State(State) -> IPB
Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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 | プロセス(PS2)->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.
1. 支払処理がIOTP Application Coreによっていったん開かれると、Consumerは支払い問い合せを開始するかもしれません、IOTP Payment Request Blockの初期の服従の後にいつでもすなわち、。 IOTP Application Coreはブランド選択の間に修理されているIOTP Payment Bridgeからどんな追加特定の支払い体系データも要求します。(Cf。 セクション2.3) 「スタート支払い問い合せ」API要求を使用します。
Erroneous API responses should be reported to the Consumer and
valid alternatives (typically retry and cancellation) should be
presented by the IOTP Application Core.
誤ったAPI応答はConsumerに報告されるべきです、そして、有効な代替手段(通常再試行とキャンセル)はIOTP Application Coreによって提示されるはずです。
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 Payment Bridgeレポート不足をIOTP Application Coreへの「チェック支払いの可能性」要求に実行するかもしれません。
Hans, et al. Informational [Page 29] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[29ページ]のRFC3867支払いAPI
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 Payment Bridge要求財布識別子かパス句が処理されるなら、それらはこのAPI関数によっても要求されるべきです。 IOTP Application Coreがランタイムメモリだけのプレーンテキストパス句を保存するのは、お勧めです。
The IOTP Application Core encapsulates any Payment Scheme
Component in an IOTP Inquiry Request Block and submits the block
to the Payment Handler.
IOTP Application CoreはIOTP Inquiry Request BlockでどんなPayment Scheme Componentもカプセル化して、Payment Handlerにブロックを提出します。
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. Payment HandlerがIOTP Inquire Request Blockを分析して、支払い関連する属性(ブランド、消費者、および支払い識別子)にTransaction Identifierを写像して、適切なIOTP Payment Bridgeを決定して、要求を転送する、このIOTP Payment Bridge(「支払い状態について問い合わせてください」)。 IOTP Application CoreはIOTP Inquiry Response Blockへの応答を変えて、それをConsumerに伝えます。
3. On receipt of the respective IOTP Inquiry Response Block the
Consumer's IOTP Application Core submits any encapsulated payment
scheme specific data to the IOTP Payment Bridge for verification
("Continue Process").
3. ConsumerのIOTP Application Coreが提出するそれぞれのIOTP Inquiry Response Blockを受け取り次第、いずれも、検証のために支払い体系が特定のデータであるとIOTP Payment Bridgeにカプセル化しました(「プロセスを持続させてください」)。
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 Application Coreは検証目的のためのIOTP Payment Bridge(「変化プロセス状態」)への状態(原文の記述を除いた)と支払い状態変化を報告された支払いに通過します。 IOTP Payment BridgeはIOTP Application Coreへの最終的な支払い状態と同様にどんな矛盾も報告します。
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.
Consumerに興味があるかもしれないどんな追加情報も一人でIOTP Payment BridgeかExisting Payment Softwareによって表示されなければなりません。
2.6. Abnormal Transaction Processing
2.6. 異常なトランザクション処理
2.6.1. Failures and Cancellations
2.6.1. 失敗とキャンセル
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 輸送、メッセージ、およびブロックのビジネスと技術的な○誤りError深層はo Transient誤り、警告、および困難な誤りを平らにします。
Any IOTP Payment API has to deal with the receipt of failure notifications by and failure responses. This proposal has borrowed the basic mechanisms for error reporting between the IOTP Application Core and the IOTP Payment Bridge from the actual protocol: Business
通知がIOTP Payment APIが失敗の領収書を取扱わなければならないいずれと失敗応答。 この提案はIOTP Application CoreとIOTP Payment Bridgeの間で実際のプロトコルから報告する誤りによって基本的機構を借りました: ビジネス
Hans, et al. Informational [Page 30] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[30ページ]のRFC3867支払いAPI
errors are reported by Status Components within IOTP Response Blocks while technical errors are signaled by Error Components within IOTP Error Blocks.
技術的な誤りがIOTP Error Blocksの中でError Componentsによって合図されている間、誤りはIOTP Response Blocksの中でStatus Componentsによって報告されます。
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 Payment APIはビジネス誤り表示のために1つの追加Error Code値を導入します--あらゆるAPI呼び出しのときに誤りを上げることができます。 この値を受け取り次第、IOTP Application Coreは「プロセス状態について問い合わせてください」という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について問い合わせてください。| 追伸Resp(状態、Receipt)<のIPB Analyzeの地方のプロセス状態について問い合わせてください、そして、必要であることで、任意のユーザ相互作用でIf Process州Changeを決議するようにしてください。| 変化プロセス州(状態)の->IPB| 変化Process州Response(状態)<IPB Ifカウンター・パーティの通知が必要です。| Create Error or Cancel Block (, add to next | message, ) and transmit it to counter party *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 7. Error Response from IPB
図7。 IPBからの誤り応答
The specific Completion Codes "ConsCancelled", "MerchCancelled", and "PaymCancelled" - returned by "Inquire Process State" - determine that the IOTP Cancel Block has to be created instead of an IOTP Error Block.
特定のCompletion Codes"ConsCancelled"、"MerchCancelled"、および"PaymCancelled"(「プロセス状態について問い合わせてください」で、返す)は、IOTPキャンセルBlockがIOTP Error Blockの代わりに作成されなければならないことを決定します。
The rules for determining the required behavior of the IOTP Application Core are given in the IOTP specification.
IOTP仕様でIOTP Application Coreの必要な動きを決定するための規則を与えます。
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 Payment Bridgeに報告されることに注意してください。 このAPI関数は状態変化と一貫性照合/同期の両方をします。 矛盾のどんな容疑もディスプレイのためにIOTP Application CoreによってIOTP Payment Bridgeによって報告されるはずです。
Hans, et al. Informational [Page 31] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[31ページ]のRFC3867支払いAPI
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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| 変化..プロセス..状態..応答..状態
Figure 8. Error Notification from counter party
エイト環。 カウンター・パーティからの誤りNotification
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 Paymentブリッジスのようにカウンター・パーティとローカルシステムコンポーネントの両方で交信している間、起こります。 とにかく、ConsumerのIOTP Application Coreは解決代替手段、すなわち、再試行、サスペンション、およびキャンセルに関してConsumerに通知するはずです。
2.6.2. Resumption
2.6.2. 再開
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 ConsumerとPayment Handlerのトランザクションの視点は同期しないかもしれません: 異なったタイムアウト値のため、カウンター・パーティは支払処理を中断させていないかもしれません。
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関数はビジネス誤りを示す非吊した支払処理でのError Codeと共に応じます。 その後、IOTP Application Coreはプロセス状態のさらなる分析のための「プロセス状態について問い合わせてください」というAPI呼び出しを発行しなければなりません。
o One IOTP message sent by one party might not be processed
successfully or even received by the counter party. This needs to
be handled by the actual payment scheme. It is expected that the
IOTP Application Core will not recognize anything.
o 1回のパーティーによって送られた1つのIOTPメッセージを、首尾よく処理しないか、カウンター・パーティは受け取ることさえできません。 これは、実際の支払い体系によって扱われる必要があります。 IOTP Application Coreが何も認識しないと予想されます。
Hans, et al. Informational [Page 32] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[32ページ]のRFC3867支払いAPI
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 Payment Exchange Blockを受け取り次第、IOTP Application Coreは、このBlockが未定のトランザクション、または、再開されるべきである吊したトランザクションに属するかどうか決めなければなりません。 IOTP Application Coreは、どんな知識不足もアップデートするために「プロセス状態について問い合わせてください」という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関数もビジネス誤りを示す非吊した支払処理でのError Codeと共に応じます。 同様であることで、「プロセスを持続させてください」というAPI関数は非未定の支払処理に関してビジネス誤りを報告するべきです。
o The payment transaction may not have been created at the Payment
Handler (early suspension and failed data transmission). In that
case, the IOTP Application Core should respond with a business
error that signals the repetition of the payment transaction (by
the Consumer).
o 支払処理はPayment Handler(前のサスペンションと失敗したデータ伝送)に作成されていないかもしれません。 その場合、IOTP Application Coreは支払処理(Consumerによる)の反復を示すビジネス誤りで応じるはずです。
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関数は一層のError Attribute「名前」が支払い識別子を指示する実在しない支払処理のときにError Code"AttValIllegal"とともに帰るべきです。
o The IOTP Application Core should always request fresh payment
scheme specific data on resumption - for synchronization purposes
with the Existing Payment Software. Old data in the cache that
has not been sent to the counter party should not be accessed.
o IOTP Application CoreはExisting Payment Softwareと共に同期目的のための再開に関する新鮮な支払い体系特定のデータをいつも要求するはずです。 カウンター・パーティに送られないキャッシュにおける古いデータにアクセスするべきではありません。
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.
Consumerが許容できる時間以内に再接続しないなら、Payment Handlerのシステムはトランザクションを閉じて、他のトランザクションのためのリソースを保有する局所制御不能解決を実行するかもしれません(「プロセス状態を変えてください」)。 Consumerがその後再接続するなら、IOTP Payment ResponseかIOTP Error Blockが生成されるかもしれません。
2.7. IOTP Wallet Initialization
2.7. 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 Application Coreが未定の支払処理を捜し求めることによってIOTP Paymentブリッジスの内部の状態をチェックするはずであるよう要求してください。
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 Application Coreは未定の支払処理に関して登録されたIOTP Paymentブリッジスについて査問します。 IOTP Application Coreは、未定のトランザクションのためにインディケータを保存して、どんなその後の問い合せも追い立てるのにそれらを使用するかもしれません(「未定の支払いについて問い合わせてください」)。
Hans, et al. Informational [Page 33] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[33ページ]のRFC3867支払いAPI
2. If one or more IOTP Payment Bridges report the presence of pending
transactions, the IOTP Application Core may try to suspend
("Change Process State") or resume (only Consumer: "Resume Payment
Consumer") the pending transactions (on user request).
2. 1IOTP Paymentのブリッジスであるなら、未定のトランザクションの存在、IOTP Application Coreが中断しようとするかもしれないと報告するか(「プロセス状態を変えてください」)、または(Consumerだけ: 「履歴書支払い消費者」)未定のトランザクション(ユーザ要求での)を再開してください。
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 Payment Bridgeはどんな新しい支払処理の処理も否定するかもしれません。 エラーコード「ビジネス誤り」でそのような否定は合図されます。
2.8. Payment Software Management
2.8. 支払いソフトウェア・マネジメント
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 Application Coreは新しい支払い方法/器具の登録に簡単、そして、ジェネリックインタフェースだけを提供します(「支払いソフトウェアを管理してください」)。 それは、初期のユーザ要求を受け取って、対応するIOTP Payment Bridgeに実際の登録を延期します。
The IOTP Application Core may also activate the Existing Payment Software for further payment instrument and wallet administration.
また、IOTP Application Coreは一層の支払い器具と財布管理のためにExisting Payment Softwareを動かすかもしれません。
3. Mutuality
3. 相互関係
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.
Payment APIは、eXtensible Markup Language(XML)を使用することで正式にされます。 それは入力パラメタとAPI関数の応答の両方のためにラッパー要素を定義します。 特に、応答ラッパーはError CodesとError記述に一般的な位置を供給します。
It is anticipated that this description reflects the logical structure of the API parameter and might be used to derive implementation language specific API definitions.
この記述がAPIパラメタの論理構造を反映して、実装の言語の特定のAPI定義を引き出すのに使用されるかもしれないと予期されます。
XML definition:
XML定義:
<!ELEMENT IotpPaymentApiRequest (
FindAcceptedPaymentBrand |
FindAcceptedPaymentProtocol |
GetPaymentInitializationData |
FindPaymentInstrument |
CheckPaymentPossiblity |
StartPaymentConsumer |
StartPaymentPaymentHandler |
ResumePaymentConsumer |
ResumePaymentPaymentHandler |
ContinueProcess |
InquireProcessState |
ChangeProcessState |
InquireAuthChallenge |
Authenticate |
<!要素IotpPaymentApiRequest、(FindAcceptedPaymentBrand|FindAcceptedPaymentProtocol|GetPaymentInitializationData|FindPaymentInstrument|CheckPaymentPossiblity|StartPaymentConsumer|StartPaymentPaymentHandler|ResumePaymentConsumer|ResumePaymentPaymentHandler|ContinueProcess|InquireProcessState|ChangeProcessState|InquireAuthChallenge| 認証します|
Hans, et al. Informational [Page 34] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[34ページ]のRFC3867支払いAPI
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: lang NMTOKEN#IMPLIED ContentSoftwareID CDATA#IMPLIED xmlns CDATA#FIXED" http://www.iotp.org/2000/08/PaymentAPI ">。
<!ELEMENT IotpPaymentApiResponse (ErrorResponse?, (
FindAcceptedPaymentBrandResponse |
FindAcceptedPaymentProtocolResponse |
GetPaymentInitializationDataResponse |
FindPaymentInstrumentResponse |
CheckPaymentPossiblityResponse |
StartPaymentConsumerResponse |
StartPaymentPaymentHandlerResponse |
ResumePaymentConsumerResponse |
ResumePaymentPaymentHandlerResponse |
ContinueProcessResponse |
InquireProcessStateResponse |
ChangeProcessStateResponse |
InquireAuthChallengeResponse |
AuthenticateResponse |
CheckAuthResponseResponse |
CheckPaymentReceiptResponse |
ExpandPaymentReceiptResponse |
RemovePaymentLogResponse |
PaymentInstrumentInquiryResponse |
InquirePendingPaymentResponse |
ManagePaymentSoftwareResponse |
StartPaymentInquiryResponse |
InquirePaymentStatusResponse |
CallBackResponse )?)>
<!要素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: lang NMTOKEN#IMPLIED ContentSoftwareID CDATA#IMPLIED xmlns CDATA#FIXED" http://www.iotp.org/2000/08/PaymentAPI ">。
Hans, et al. Informational [Page 35] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[35ページ]のRFC3867支払いAPI
<!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) >
<!ATTLIST ErrorResponse
xml:lang NMTOKEN #IMPLIED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity(Warning |
TransientError |
HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorResponse(ErrorLocation+、PaySchemePackagedContent*)><!ATTLIST ErrorResponse xml: lang NMTOKEN#IMPLIED ErrorCode NMTOKEN#REQUIRED ErrorDesc CDATA#REQUIRED Severity(警告|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 Error Blockへの即座の挿入のために意図します。 Error Location要素属性の値がそうしなければならない属性は、Error ComponentのElementsを豊かにして、Error Locationに変えました。(Cf。 IOTP仕様).
Attributes (cf. IOTP Specification):
属性(Cf。 IOTP仕様):
xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a child
element.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素の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 Contains情報。 目的は異なったソフトウェアによって出されたメッセージの間の非互換性の結果、起こるかもしれない相互運用性問題を解決するのを助けることです。 「xml: lang」によって定義された言語でそれはただ一つのテキスト文字列です。 それは最小限としてそれがその結果起こるかもしれない問題を含まなければなりません。
o the name of the software manufacturer,
o the name of the software,
o the version of the software, and
o the build of the software.
o ソフトウェア製造業者の名前、○ ソフトウェアの名前、○ ソフトウェアのバージョン、および○ ソフトウェアの体格。
ErrorCode Contains an error code which indicates the
nature of the error in the message in error.
Valid values for the Error Code are given in
the following section. This mnemonic enables
the automatic failure resolution of the IOTP
Application Core which analyzes the error code
value in order to determine the continuation
alternatives.
メッセージにおける誤りの本質を間違って示す誤りがコード化するErrorCode Contains。 以下のセクションでError Codeのための有効値を与えます。 このニーモニックは継続代替手段を決定するために誤りコード値を分析するIOTP Application Coreの自動失敗解決を可能にします。
Hans, et al. Informational [Page 36] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[36ページ]のRFC3867支払いAPI
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.
言語における、誤りの記述がxmlで定義したErrorDesc Contains: lang。 この属性の内容はError Response Elementを生成したソフトウェアのベンダー/開発者によって定義されます。 それは、失敗とその(バンドの外)解決代替手段に関してユーザディスプレイのために意図して、詳説を提供します。
Severity Indicates the severity of the error. Valid
values are:
厳しさIndicates、誤りの厳しさ。 有効値は以下の通りです。
o Warning. This indicates that although there
is a message in error the IOTP Transaction
can still continue.
o 警告。 これは、メッセージが間違ってありますが、IOTP Transactionがまだ続くことができるのを示します。
o TransientError. This indicates that the
error in the message in error may be
recovered if the message in error that is
referred to by the "Names" attribute is
resent.
o TransientError。 これは、間違い属性という「名前」によって示されるメッセージを再送するなら間違いメッセージにおける誤りを回復するかもしれないのを示します。
o HardError. This indicates that there is an
unrecoverable error in the message in error
and the IOTP Transaction must stop.
o HardError。 これは、回復不能エラーが間違いメッセージとIOTP Transaction欠かせない立ち寄り先にあるのを示します。
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 This属性は存在しているべきです。 それはメッセージを間違って再送する前に誤りを報告するメッセージを受け取ったアプリケーションが待つべきであるのを意識しているIOTPが"ErrorLocation"属性で特定した全体の秒の最小の数です。
If Severity is not set to
"TransientError" then the value of this
attribute is ignored.
Severityが"TransientError"に用意ができていないなら、この属性の値は無視されます。
SwVendorErrorRef This attribute is a reference whose value is
set by the vendor/developer of the software
that generated the Error Element. It should
contain data that enables the vendor to
identify the precise location in their
software and the set of circumstances that
caused the software to generate a message
reporting the error.
SwVendorErrorRef This属性は値がError Elementを生成したソフトウェアのベンダー/開発者によって設定される参照です。 それはベンダーがソフトウェアに誤りを報告するメッセージを生成させたそれらのソフトウェアと事情のセットで正確な位置を特定するのを可能にするデータを含むべきです。
Hans, et al. Informational [Page 37] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[37ページ]のRFC3867支払いAPI
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 Thisは可能であるところで間違いError Elementを生成したメッセージの要素と属性を特定します。 誤りの「厳しさ」が"TransientError"でないなら、1"ErrorLocation"が指定されるかもしれない以上は誤りの本質とIOTP Payment Bridgeのベンダー/開発者の裁量における依存を当てます。
Its definition coincides with the
IOTP specification whereby the
attributes "IotpMsgRef", "BlkRef" and
"CompRef" are left blank,
intentionally.
定義は属性"IotpMsgRef"、"BlkRef"、および"CompRef"が左の空白、故意にそうであるIOTP仕様と一致しています。
PaySchemePackagedContent cf. Table 5
PaySchemePackagedContent Cf。 テーブル5
3.1. Error Codes
3.1. エラーコード
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.
以下のテーブルはError Response ElementのErrorCode属性のために有効値を記載します。 エラー記述の最初の文は表示するか、または別の方法で報告すると誤りについて説明するのに使用できるデフォルトテキストを含んでいます。 個々の実装は自己判断で代替の言語にこれを翻訳するかもしれません。 しかしながら、あらゆるエラーコードがあらゆるAPI呼び出しに適用されるかもしれないというわけではありません。 長い間、Error Codeは14以上のキャラクタであるはずがありません。 Error CodesはIOTP Specificationから取られて、前のアスタリスクによって目立たされるいくつかの追加コードによって広げられました。
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 Application Coreは彼らの修正のためにうながすかもしれません。 更新が失敗するか、またはどんな更新と何らかの通知もIOTP Application Coreスキップでなければならないことがカウンター・パーティに発信するなら、エラーコードはIOTP Error Blockの中でカプセル化されます。
However, the IOTP server application reports business errors - visible at the IOTP layer - in the Status Component of the respective Response Block.
しかしながら、IOTPサーバ・アプリケーションはそれぞれのResponse BlockのStatus ComponentでIOTP層で目に見えるビジネス誤りを報告します。
The IOTP Application Core may add the attributes (and values) within the ErrorLocation elements that are omitted by the IOTP Payment Bridge.
IOTP Application CoreはIOTP Payment Bridgeによって省略されるErrorLocation要素の中で属性(そして、値)を加えるかもしれません。
Hans, et al. Informational [Page 38] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[38ページ]のRFC3867支払いAPI
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 Application Coreソフトウェアコンポーネントの開発者のためのヒントを含んでいます。 逆に、IOTP Paymentブリッジスの開発者はIOTP Application Coreの予想された動きに関する印象を受けます。
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 Payment APIは、IOTP Application Coreが誤り解決に必要であるダイアログボックスを実装すると仮定します。 しかし、仮定しない、IOTP Payment Bridgeは実際にそれらを当てにします。 代わりに、IOTP Payment Bridgeはそれ自身のところで解決を試みて、特定のダイアログボックスを実装して、最終的な失敗だけに合図するかもしれません。
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]).
予約されていた状態で、予約されます。 この誤りはソフトウェアのベンダー/開発者によって控えられます。 詳しい情報のためのソフトウェアのベンダー/開発者に連絡してください(Transaction Reference Block[IOTP]のMessage Id要素のSoftwareId属性を見てください)。
XmlNotWellFrmd XML not well formed. The XML document is not
well formed. See [XML] for the meaning of
"well formed".
XmlNotWellFrmd XML、整形式ではありません。 XMLドキュメントは整形式ではありません。 「整形式」の意味に関して[XML]を見てください。
XmlNotValid XML not valid. The XML document is well
formed but the document is not valid. See
[XML] for the meaning of "valid".
Specifically:
XmlNotValid XML、有効ではありません。 XMLドキュメントは整形式ですが、ドキュメントは有効ではありません。 「有効」の意味に関して[XML]を見てください。 明確に:
o the XML document does not comply with the
constraints defined in the IOTP document
type declaration, and
o the XML document does not comply with the
constraints defined in the document type
declaration of any additional [XML-NS]
that are declared.
o ○ XMLドキュメントはIOTPドキュメント型の宣言で定義される規制に応じません、そして、XMLドキュメントは宣言されるどんな追加[XML-NS]のドキュメント型の宣言でも定義される規制に応じません。
The Names attribute might refer some
attributes and elements of the input
parameter list.
Names属性は入力パラメータ・リストのいくつかの属性と要素を参照するかもしれません。
Hans, et al. Informational [Page 39] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[39ページ]のRFC3867支払いAPI
(*)ElNotValid Element not valid. Invalid element in terms
of prescribed syntactical characteristics.
(*)ElNotValid Element、有効ではありません。 処方された構文の特性に関する無効の要素。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
The IOTP Application Core has to replace the
error code with "XmlNotValid" before
transmission to the counterparty.
IOTP Application Coreはカウンターパーティへのトランスミッションの前にエラーコードを"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 Unexpected要素。 XMLドキュメントは、整形式であって有効ですが、要素は、規則に従って特定の文脈で予想されないプレゼントとこの仕様に含まれた規制です。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
ElNotSupp Element not supported. Although the document
is well formed and valid, an element is
present that
サポートされなかったElNotSupp Element。 ドキュメントは、整形式であって有効ですが、要素はそれを提示することです。
o is consistent with the rules and
constraints contained in this
specification, but
o is not supported by the IOTP Aware
Application which is processing the IOTP
Message.
o この仕様に含まれている規則と規制と一致しています、oだけがIOTP Messageを処理しているIOTP Aware Applicationによってサポートされません。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
ElMissing Element missing. Although the document is
well formed and valid, an element is missing
that should have been present if the rules
and constraints contained in this
specification are followed.
ElMissing Elementの取り逃がすこと。 ドキュメントは、整形式であって有効ですが、要素はこの仕様に含まれた規則と規制が従われているなら存在するべきであった取り逃がすことです。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
Hans, et al. Informational [Page 40] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[40ページ]のRFC3867支払いAPI
ElContIllegal Element content illegal. Although the
document is well formed and valid, the
element contains values which do not conform
the rules and constraints contained in this
specification.
ElContIllegal Elementの満足している不法入国者。 ドキュメントは、整形式であって有効ですが、要素は規則を従わせない値とこの仕様に含まれた規制を含んでいます。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
element (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
The IOTP Application Core has to replace the
Error Code with "ElNotSupp" before
transmission to the counter party, if the
ErrorLocation elements refer to
non-PackagedContent element.
IOTP Application Coreはカウンター・パーティへのトランスミッションの前にError Codeを"ElNotSupp"に取り替えなければなりません、ErrorLocation要素が非PackagedContent要素を示すなら。
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 Encapsulatedは誤りについて議定書の中で述べます。 ドキュメントは、整形式であって有効ですが、要素のPackaged Contentは誤りを含むカプセル化されたプロトコルからのデータを含んでいます。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
element (if they have ID attributes).
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません(それらにID属性があるなら)。
AttUnexpected Unexpected attribute. Although the XML
document is well formed and valid, the
presence of the attribute is not expected in
the particular context according to the
rules and constraints contained in this
specification.
AttUnexpected Unexpected属性。 XMLドキュメントは、整形式であって有効ですが、この仕様に含まれた規則と規制に従って、属性の存在は特定の文脈で予想されません。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
ErrorLocation要素のAttName属性は対応する属性タグについて言及するかもしれません。
(*)AttNotValid Attribute not valid. Invalid attribute value
in terms of prescribed syntactical
characteristics.
(*)AttNotValid Attribute、有効ではありません。 処方された構文の特性に関する無効の属性値。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
ErrorLocation要素のAttName属性は対応する属性タグについて言及するかもしれません。
The IOTP Application Core has to replace the
error code with "XmlNotValid" before
transmission to the counter party.
IOTP Application Coreはカウンター・パーティへのトランスミッションの前にエラーコードを"XmlNotValid"に取り替えなければなりません。
Hans, et al. Informational [Page 41] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[41ページ]のRFC3867支払いAPI
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 Attribute。 XMLドキュメントは、整形式であって有効です、そして、要素での属性の存在はこの仕様に含まれている規則と規制と一致していますが、それはIOTP Messageを処理しているIOTP Aware Applicationによってサポートされません。
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 Attributeの取り逃がすこと。 ドキュメントは、整形式であって有効ですが、属性はこの仕様に含まれた規則と規制が従われているなら存在するべきであった取り逃がすことです。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
ErrorLocation要素のAttName属性は対応する属性タグについて言及するかもしれません。
If the attribute is required by the IOTP
Document Type Declaration (#REQUIRED) the
hints for non-valid attributes should be
adopted, otherwise these for illegal
attribute values.
属性がIOTP Document Type Declaration(#REQUIRED)によって必要とされるなら、非有効な属性のためのヒントは採用されるべきです、そうでなければ、不法な属性値のためのこれら。
AttValIllegal Attribute value illegal. The attribute
contains a value which does not conform to
the rules and constraints contained in this
specification.
AttValIllegal Attributeは不法入国者を評価します。 属性は規則に従わない値とこの仕様に含まれた規制を含んでいます。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags - valid values are:
ErrorLocation要素のAttName属性は対応する属性タグについて言及するかもしれません--有効値は以下の通りです。
BrandId: illegal/unknown Brand Identifier -
If the brand is not recognized/known by any
IOTP Payment Bridge, the IOTP Application
Core may offer the registration of a new
Payment Instrument.
BrandId: 不法であるか未知のBrand Identifier--ブランドがどんなIOTP Payment Bridgeによっても認識されるか、または知られていないなら、IOTP Application Coreは新しいPayment Instrumentの登録を提供するかもしれません。
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: 不法であるか未知のPayment Instrument Identifier--属性値が同じ「財布」によって前の問い合せ要求に関して報告されたなら、これは重大な意思疎通の問題を示します。 IOTP Application Coreはカウンター・パーティへのトランスミッションの前にエラーコードを"UnknownError"に取り替えなければなりません。
Hans, et al. Informational [Page 42] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[42ページ]のRFC3867支払いAPI
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: 不法であるか未知のWallet Identifier--財布識別子がパス句の前にチェックされると思われます。 無効の財布識別子では、IOTP Application Coreは、正しい財布識別子を要求するために対話を開くかもしれません。 さらに、どんなパス句もユーザによって提供されるかもしれません。 対話はそれぞれの支払いブランドを示すべきです。 IOTP Application Coreはカウンター・パーティへのトランスミッションの前にエラーコードを"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.
パスフレーズ: 不法であるか未知のPass Phrase--IOTP Application Coreは、正しいパス句を要求するために対話を開くかもしれません。 パス句が財布識別子特有であるなら、対話は財布識別子を表示するべきです。 IOTP Application Coreはカウンター・パーティへのトランスミッションの前にエラーコードを"TransportError"に取り替えなければなりません。
Action: illegal / unknown / unsupported
Action
動作: 不法であるか未知の、または、サポートされない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: リストは不法であるか未知の、または、サポートされないProperty Typesを入れてあます--IOTP Application Coreは地方の解決だけを試みますが、どんなIOTP Error Blockもカウンター・パーティに決して伝えません。
CurrCode: illegal/unknown/unsupported
Currency Code
CurrCode: 不法であるか未知の、または、サポートされないCurrency Code
CurrCodeType: illegal/unknown/unsupported
Currency Code Type
CurrCodeType: 不法であるか未知の、または、サポートされないCurrency Code Type
Amount: illegal/unknown/unsupported Payment
Amount
量: 不法であるか未知の、または、サポートされないPayment Amount
PayDirection: illegal/unknown/unsupported
Payment Direction
PayDirection: 不法であるか未知の、または、サポートされないPayment Direction
ProtocolId: illegal/unknown/unsupported
Protocol Identifier
ProtocolId: 不法であるか未知の、または、サポートされないプロトコルIdentifier
Hans, et al. Informational [Page 43] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[43ページ]のRFC3867支払いAPI
OkFrom: illegal/unknown/unsupported OkFrom
Timestamp
OkFrom: 不法であるか未知の、または、サポートされないOkFrom Timestamp
OkTo: illegal/unknown/unsupported OkTo
Timestamp
OkTo: 不法であるか未知の、または、サポートされないOkTo Timestamp
ConsumerPayId: illegal/unknown Consumer
Payment Identifier
ConsumerPayId: 不法であるか未知のConsumer Payment Identifier
PaymentHandlerPayId: illegal/unknown Payment
Handler Payment Identifier
PaymentHandlerPayId: 不法であるか未知のPayment Handler Payment Identifier
PayId: illegal/unknown Payment Identifier
PayId: 不法であるか未知のPayment Identifier
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 Applicationが含むことができた値を含んでいます。認識しません。
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
ErrorLocation要素のAttName属性は対応する属性タグについて言及するかもしれません。
MsgTooLarge Message too large. The message is too large
to be processed by the IOTP Payment Bridge
(or IOTP Application Core).
MsgTooLarge Message、大き過ぎます。 メッセージはIOTP Payment Bridge(または、IOTP Application Core)が処理できないくらい大きいです。
ElTooLarge Element too large. The element is too large
to be processed by the IOTP Payment Bridge
(or IOTP Application Core).
ElTooLarge Element、大き過ぎます。 要素はIOTP Payment Bridge(または、IOTP Application Core)が処理できないくらい大きいです。
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements.
ErrorLocation要素のElementRef属性は対応する要素を示すかもしれません。
ValueTooSmall Value too small or early. The value of all
or part of an element content or an
attribute, although valid, is too small.
ValueTooSmall Value、小さ過ぎるか、または早いです。 有効ですが、すべての値か要素含有量か属性の部分が小さ過ぎます。
The ErrorLocation elements might refer to
the corresponding attribute tags or
elements.
ErrorLocation要素は対応する属性タグか要素を示すかもしれません。
ValueTooLarge Value too large or in the future. The value
of all or part of an element content or an
attribute, although valid, is too large.
または、ValueTooLarge Value、大き過ぎる、将来。 有効ですが、すべての値か要素含有量か属性の部分がかなり過ぎます。
Hans, et al. Informational [Page 44] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[44ページ]のRFC3867支払いAPI
The ErrorLocation elements might refer to
the corresponding attribute tags or
elements.
ErrorLocation要素は対応する属性タグか要素を示すかもしれません。
ElInconsistent Element Inconsistent. Although the document
is well formed and valid, according to the
rules and constraints contained in this
specification:
ElInconsistent要素矛盾しています。 この仕様に含まれた規則と規制に従って、ドキュメントは、整形式であって有効ですが:
o the content of an element is inconsistent
with the content of other elements or
their attributes, or
o または要素の内容が他の要素かそれらの属性の内容に反している。
o the value of an attribute is inconsistent
with the value of one or more other
attributes.
o 属性の値は他の1つ以上の属性の値に反しています。
The Error Description may contain further
explanations.
Error記述はさらなる説明を含むかもしれません。
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.
Error記述は例えば、さらなる物語の説明、「リモート会計主任手の届かない」「チップカードは反応しない」か、「xyzへのインターネット接続は失った」「いいえ、手があいているインターネット接続」、「モデムは全く接続しなかった」か、または「別のアプリケーションによる使用モデムへのシリアルポート」を含むかもしれません。 本稿はエンドユーザに示されるべきです。 Consumerは続く方法を決めるかもしれません--選択肢は、タイムアウトがConsumerに起こったなら、本稿が示されるべきであり、再試行と、支払処理サスペンションと、キャンセルです。
Hans, et al. Informational [Page 45] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[45ページ]のRFC3867支払いAPI
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メッセージ。 このエラーコードはTransient ErrorのSeverityと共に使用されるだけです。 それは、前のメッセージ(交換メッセージか要求メッセージであるかもしれない)が処理されていて、どんな応答も「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システム忙しいです。 このエラーコードはTransient ErrorのSeverityと共に使用されるだけです。 それは、API要求を受け取ったIOTP Payment BridgeかExisting Payment Softwareが現在それを扱うことができないくらい忙しいのを示します。 どんな応答も「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".
Error記述はさらなる説明、例えば、「財布/チップカードリーダは、入手できなく、別の支払処理でロックされる」か、「支払いゲートウェイは積みすぎられる」か、「未知のチップカードリーダ」、または「挿入された、認識されていないチップカード、変化チップカード」を提供するかもしれません。
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.
ConsumerのIOTP Application Coreはエラー記述を表示して、継続に関してConsumerに尋ねるかもしれません--選択肢は、再試行と、支払処理サスペンションと、キャンセルです。
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の未知の誤り。 トランザクションがいくつかのために他の誤りのいずれでも明らかにカバーされていない理由を完成できないのを示します。 Error記述属性は、問題の性格を示すのに使用されるべきです。
The ErrorLocation elements might refer to
the corresponding attribute tags or elements
that are inconsistent.
ErrorLocation要素は対応する属性タグか首尾一貫しない要素を示すかもしれません。
(*)SyntaxError Syntax Error. An (unknown) syntax error has
occurred.
(*)SyntaxError構文エラー。 (未知)の構文エラーは起こりました。
Hans, et al. Informational [Page 46] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[46ページ]のRFC3867支払いAPI
The ErrorLocation elements might refer to
the corresponding attribute tags or elements
that are inconsistent.
ErrorLocation要素は対応する属性タグか首尾一貫しない要素を示すかもしれません。
The IOTP Application Core has to replace the
error code with "XmlNotValid" or
"UnknownError" before transmission to the
counter party.
IOTP Application Coreはカウンター・パーティへのトランスミッションの前にエラーコードを"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 Requestは拒否しました。 API要求は(現在、)IOTP Payment Bridgeによって拒否されます。 エラー記述はさらなる説明、例えば、「財布/チップカードリーダは、入手できなく、別の支払処理でロックされる」か、「支払いゲートウェイは積みすぎられる」か、「未知のチップカードリーダ」、または「挿入された、認識されていないチップカード、変化チップカード」を提供するかもしれません。
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".
ConsumerのIOTP Application Coreはエラー記述を表示して、継続に関してConsumerに尋ねるかもしれません--選択肢は、再試行と、支払処理サスペンションと、キャンセルです。 無効のProcess Statesによる否定は"BusinessError"によって合図されるべきです。 通常、この種類の誤りはカウンター・パーティのIOTP Application Coreに通過されません。 さもなければ、それは"TransportError"か"UnknownError"に写像します。
(*)ReqNotSupp Request not supported. The API
function(ality) has not been implemented in
the IOTP Payment Bridge. Typically, this
kind of error is not passed to the
counter party's IOTP Application Core.
Otherwise, it maps to "TransportError" or
"UnknownError".
ReqNotSupp Requestがサポートしなかった(*。) API関数(ality)はIOTP Payment Bridgeで実装されていません。 通常、この種類の誤りはカウンター・パーティのIOTP Application Coreに通過されません。 さもなければ、それは"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
パーティーのPayment Identifierを使用することでErrorLocation要素は支払処理について言及するかもしれません--それはデフォルトとします。
Hans, et al. Informational [Page 47] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[47ページ]のRFC3867支払いAPI
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".
経常取引か力が現在の支払処理パーティーのPayment Identifierを含んでいます--ElementRef属性で、AttName属性は"PayId"と共に修理されていますが、特定されます。
The IOTP Application Core must inquire the
IOTP Payment Bridge about the actual Process
State which actually encodes the business
error ("Inquire Process State").
This error code must not be
passed to the counter party's IOTP
Application Core.
IOTP Application Coreは実際にビジネス誤りをコード化する実際のProcess州に関してIOTP Payment Bridgeについて問い合わせなければなりません(「プロセス状態について問い合わせてください」)。 このエラーコードをカウンター・パーティのIOTP Application Coreに通過してはいけません。
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 Payment Bridgeは失敗解決のためのさらなる必要なステップに関してConsumerに通知するのにエラー記述を使用するかもしれません、例えば、「すみません、あなたの支払処理は失敗しました」。 「あなたは残念ながら、あなたの発行人に連絡してくださいと宣言されました。」
3.2. Attributes and Elements
3.2. 属性と要素
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属性がわかります--属性タグの後のどんなparenthesized数もキャラクタの属性値のお勧めの最大限度の長さです:
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)の全体の、そして、断片的な単位で支払うために支払い量を示します。 AmountTo(11)は例えば、245.35ドル言い表すでしょう。「245.35」言い表されます。 最も小さい宗派より小さい値が許容されていることに注意してください。 例えば、1セントの1/10は「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 An識別子は、固有識別文字で認証要求を受け取る組織によって返されるとどれが、固有識別文字が、どの認証が言及されているかを特定するのを可能にするかを指定しました。
Hans, et al. Informational [Page 48] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[48ページ]のRFC3867支払いAPI
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) これはブランド(または、宣伝のブランド)のためのユニークな識別子を含んでいます。 それは、ConsumerがConsumerがBrandと共に支払うことができるかどうか決定するために持っているPayment Instrumentsのリストに対して合うのに使用されます。
Values of BrandId are managed under
procedure being described in the IOTP
protocol specification.
BrandIdの値はIOTPプロトコル仕様で説明される手順の下で管理されます。
BrandLogoNetLocn The net location which can be used to
download the logo for the organization (cf.
IOTP Specification).
BrandLogoNetLocnは組織のためにロゴをダウンロードするのに使用できるネットの位置です。(Cf。 IOTP仕様).
The content of this attribute must conform
to [URL].
この属性の内容は[URL]に従わなければなりません。
BrandName This contains the name of the brand, for
example "MasterCard Credit". This is the
description of the Brand which is displayed
to the consumer in the Consumer's language
defined by "xml:lang". For example it might
be "American Airlines Advantage Visa". Note
that this attribute is not used for matching
against the payment instruments held by the
Consumer.
BrandName Thisはブランドの名前、例えば、「マスターカードクレジット」を含んでいます。 これは「xml: lang」によって定義されたConsumerの言語で消費者に表示されるBrandの記述です。 例えば、それは「アメリカン航空利点ビザ」であるかもしれません。 この属性がConsumerによって持たれていた支払い器具に対して合うのに使用されないことに注意してください。
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 Thisの任意の属性は、Consumerがそのブランドを選択するなら申請される何らかの特別な状態か利益を示すのにマーチャントによって使用されます。 例えば、「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 A機能はProcess州か支払い進歩の変化です、例えば、ディスプレイアップデートのために。 しかしながら、IOTP Payment Bridgeはそれ自身のメカニズムとダイアログボックスを使用するかもしれません。
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.
好みの順にテキストがCall Back機能に終わった言語を含む言語コードのCallBackLanguageList Aリストはコード化されるでしょう。
Hans, et al. Informational [Page 49] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[49ページ]のRFC3867支払いAPI
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.,
また、IOTP Payment Bridgeは、例えばある種の商売の失敗を決議するためにさらなる必要なステップに関してConsumerに通知するのにStatus記述を使用するかもしれません。
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 「すみません、あなたの支払処理は失敗しました。」 「残念ながら、あなたは請求されました、とあなたの発行人は連絡してください」。○ 「不十分な容量は還付にいなくなあなたのストアードバリューカードの上に()でした」、○ 「という支払いが/チップカード誤り/内部エラーに失敗して、器具の支払いものに連絡してください発行人」
ConsumerDesc A narrative description of the Consumer.
ConsumerのConsumerDesc A物語記述。
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.
ユニークな識別子が別のPayment Scheme ComponentのPayment Handlerか他の手段で返すならConsumerがどの支払いを特定するかを可能にするConsumerで指定したConsumerPayId(14)は言及されています。
This unique identifier is generated by the
IOTP Application Core and submitted to the
IOTP Payment Bridge on every API call. It
may equal the Payment Handler Payment
Identifiers but need not necessarily be so.
このユニークな識別子をIOTP Application Coreが生成して、あらゆるAPI呼び出しのときにIOTP Payment Bridgeに提出します。 それは、Payment Handler Payment Identifiersと等しいかもしれませんが、したがって、必ず等しくなければならないというわけではありません。
The uniqueness extends to multiple payment
instruments, payment brands, payment
protocols, wallet identifiers, and even
multiple IOTP Payment Bridges.
ユニークさは複数の支払い器具、支払いブランド、支払いプロトコル、財布識別子、および複数のIOTP Paymentブリッジスにさえ達します。
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 During支払い進歩、この状態値は支払いが、リモートパーティーと共にさらなるIOTP Payment Scheme Component交換で続けられる必要であるかどうかを示します。 「終わり」は、報告された支払い体系データが最後のカウンター・パーティと共に交換されるべきデータであることを示します。
Hans, et al. Informational [Page 50] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[50ページ]のRFC3867支払いAPI
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 Thisは要素の内容を生成したソフトウェアを特定する情報を含んでいます。 目的は異なったソフトウェアによって出されたメッセージの間の非互換性の結果、起こるかもしれない相互運用性問題を解決するのを助けることです。 xmlによって定義された言語でそれはただ一つのテキスト文字列です: lang。 それは最小限として以下を含まなければなりません。
o the name of the software manufacturer,
o the name of the software,
o the version of the software, and
o the build of the software.
o ソフトウェア製造業者の名前、○ ソフトウェアの名前、○ ソフトウェアのバージョン、および○ ソフトウェアの体格。
CurrCodeType (14) Indicates the domain of the CurrCode. This
attribute is included so that the currency
code may support nonstandard currencies
such as frequent flyer point, trading
stamps, etc. Its values may be
CurrCodeType(14)はCurrCodeのドメインを示します。 この属性は、通貨コードがフリークエントフライヤーポイント、商品引換えスタンプなどの標準的でない通貨を支えることができるように、含まれています。 値はそうです。
o ISO-4217-A, the default, indicates the
currency code is the three-letter
alphabetic code that conform to ISO-4217
[ISO4217].
o IOTP indicates that the values of
CurrCode are managed under the procedure
described in [IOTP].
o ISO-4217-A(デフォルト)は、通貨コードがISO-4217[ISO4217]に従う3文字の英字コードであることを示します。o IOTPは、CurrCodeの値が[IOTP]で説明された手順の下で管理されるのを示します。
CurrCode (14) A code which identifies the currency to be
used in the payment. The domain of valid
currency codes is defined by "CurrCodeType"
支払いに使用されるために通貨を特定するCurrCode(14)Aコード。 有効な通貨コードのドメインは"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 Payment Bridgeによって提供されます。
Cf. To "ConsumerPayId" for note about
uniqueness.
Cf。 ユニークさに関する注のための"ConsumerPayId"に。
Hans, et al. Informational [Page 51] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[51ページ]のRFC3867支払いAPI
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)Aローカルの項目。 この項目は、任意であり、同じ目的にそれ自体で使用できるWallet Identifierを豊かにするかもしれません。
Name Distinguishes between multiple occurrences
of Packaged Content Elements at the same
point in IOTP. For example:
IOTPの同じポイントでPackaged Contentの複数の発生の間のDistinguishesをElementsと命名してください。 例えば:
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
<ABCD><PackagedContent Nameは'FirstPiece'>snroasdfnas934k</PackagedContent><PackagedContent Nameは'SecondPiece'>dvdsjnl5poidsdsflkjnw45</PackagedContent></ABCD>と等しいこと'と等しいです。
The "Name" attribute may be omitted, for
example if there is only one Packaged
Content element.
例えば、1つのPackaged Content要素しかなければ、「名前」属性は省略されるかもしれません。
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].
UTC Format範囲OkTo(30)の日時がPayment Handlerが支払いを受け入れるかもしれない商人で示したOkFrom(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 Indicates、作られているBrandが選択されている支払いがことである方向。 値は以下の通りです。
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 以下を借り方に記入してください。 またはこのBrand Listが関係するPayment Request Block(例えば、Consumer)の送付者が支払いをPayment Handlerにする。
Hans, et al. Informational [Page 52] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[52ページ]のRFC3867支払いAPI
o Credit: The sender of the Payment Request
Block to which this Brand List relates
will receive a payment from the Payment
Handler.
o クレジット: このBrand Listが関係するPayment Request Blockの送付者はPayment Handlerから支払いを受け取るでしょう。
PayId (14) This attribute is introduced for API
simplification:
API簡素化のためにこれが結果と考えるPayId(14)を導入します:
o The Consumer has to identify PayId and
ConsumerPayId.
o ConsumerはPayIdとConsumerPayIdを特定しなければなりません。
o The Merchant has to identify PayId and
MerchantPayId.
o マーチャントはPayIdとMerchantPayIdを特定しなければなりません。
o The Payment Handler has to identify PayId
and Payment Handler Pay Id.
o Payment HandlerはPayIdとPayment Handler Payアイダホ州を特定しなければなりません。
PayInstId This contains the unique identifier used
internally by the IOTP Payment
Bridge/Existing Payment Software.
PayInstId ThisはIOTP Payment Bridge/既存のPayment Softwareによって内部的に使用されたユニークな識別子を含んでいます。
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 Thisは支払い器具のユーザによって定義された名前を含んでいます。 ユニークさのような(技術的)の規制は全く存在していません。 「xml: lang」属性は価値の言語コード化を指示します。
PaymentHandlerDesc A narrative description of the Payment
Handler.
Payment HandlerのPaymentHandlerDesc A物語記述。
PaymentHandlerPayId An unique identifier specified by the
(14) Payment Handler that, if returned by the
Consumer in another Payment Scheme Component
or by other means, enables the Payment
Handler to identify which payment is being
referred to. It is required whenever it is
known.
PaymentHandlerPayId Anのユニークな識別子は別のPayment Scheme ComponentのConsumerか他の手段で返すならPayment Handlerが、どの支払いが言及されているかを特定するのを可能にする(14)支払いHandlerで指定しました。 知られているときはいつも、それが必要です。
Cf. To "ConsumerPayId" for note about
uniqueness.
Cf。 ユニークさに関する注のための"ConsumerPayId"に。
PaymentInstrumentId An identifier for a specific payment
(32) instrument, e.g., "credit card", "Mondex card
for English Pounds". This identifier is
fully customizable. It is assumed, that it
does not contain confidential information or
even an indication of it. The payment
特定の支払い(32)器具のためのPaymentInstrumentId An識別子、例えば、「クレジットカード」、「イギリス人のパウンズのためのモンデックスカード。」 この識別子は完全にカスタマイズ可能です。 それは想定されて、するのはそれの秘密情報かしるしさえ含んでいません。 支払い
Hans, et al. Informational [Page 53] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[53ページ]のRFC3867支払いAPI
instrument identifier is unique within each
payment brand. It is displayed to the
Consumer during brand selection.
器具識別子はそれぞれの支払いブランドの中でユニークです。 ブランド選択の間、Consumerにそれを表示します。
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 Optionallyはそんなに一緒にいる他の要素(支払いを含んで、特定のデータを計画する)が領収書にする(32)の要素参照を含んでいます。 それぞれの支払い体系が補足で参照をつけなければならない要素を定義することに注意してください。
The IOTP Application Core should save all
the components referenced so that the
payment receipt can be reconstructed when
required.
IOTP Application Coreは必要であると支払い領収書を再建できるように参照をつけられるすべてのコンポーネントを保存するはずです。
PayReqNetLocn The Net Location indicating where an
unsecured Payment Request message should be
sent if this protocol choice is used.
このプロトコル選択が使用されているならunsecured Payment Requestメッセージがどこに送られるべきであるかを示すPayReqNetLocnネットLocation。
The content of this attribute must conform
to [URL] and depends on the Transport
Mechanism.
この属性の内容は、[URL]に従わなければならなくて、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.
支払処理の進歩を示す0〜100のPercentComplete(3)A番号。 値は未定の、そして、吊したトランザクションのための0と99の間に及びます。
ProcessState Contains a Process State Code that
indicates the current state of the process
being carried out. Valid values are:
行われるプロセスの現状を示すProcessState Contains a Process州Code。 有効値は以下の通りです。
o NotYetStarted. The Payment Request Block
has been received but processing of the
Payment Request has not yet started
o NotYetStarted。 Payment Request Blockを受け取りましたが、Payment Requestの処理はまだ始まっていません。
o InProgress. The payment transaction is
pending. The processing of the (Payment)
Request Block has started but it is not
yet complete.
o InProgress。 支払処理は未定です。 (支払い)要求Blockの処理は始まりましたが、それはまだ完全ではありません。
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 Application Coreに通過されるなら、このプロセス状態は「InProgress」に写像されます。
Hans, et al. Informational [Page 54] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[54ページ]のRFC3867支払いAPI
o CompletedOk. The processing of the (Payment)
Request Block and any following Payment
Exchange Blocks has completed successfully.
o CompletedOk。 (支払い)要求Blockと次のPayment Exchange Blocksが首尾よく完成したいずれの処理。
o Failed. The payment processing has finally
failed for a Business Error.
o 失敗にされる。 支払処理はBusiness Errorのために最終的に失敗しました。
o ProcessError. This value is only used
when the Status Component is being used in
connection with an Inquiry Request Trading
Block. It indicates there was a Technical
Error in the Request Block which is being
processed or some internal processing
error. Each party's IOTP Payment Bridge
uses this value in order to notify the
IOTP Application Core about the presence
of technical errors.
o ProcessError。 Status ComponentがInquiry Request Trading Blockで使用されているときだけ、この値は使用されます。 それは、処理されているRequest Blockか何らかの内部の整理過程の誤差にはTechnical Errorがあったのを示します。 各当事者のIOTP Payment Bridgeは、技術的な誤りの存在に関してIOTP Application Coreに通知するのにこの値を使用します。
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はそれら自身のをよく定義させます、まだ異なっています、Brand識別子が各プロトコルと共に使用される値。 この属性の有効値は支払いプロトコルがIOTPと共にどう働いているかを説明する"ProtocolId"によって特定された支払いプロトコルのための補足で定義されます。 識別子は高々1つのプロトコルしかBrand Identifierを写像しません。
Hans, et al. Informational [Page 55] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[55ページ]のRFC3867支払いAPI
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"、「eキャッシュ」。」 有効値はIOTP仕様への補足で定義されます、そして、彼らはそれぞれの支払いブランドの中でユニークです。
ProtocolIds A sequence of Protocol Identifiers
プロトコルIdentifiersのProtocolIds A系列
ProtocolName A narrative description of the payment
protocol and its version in the language
identified by "xml:lang". For example
"Secure Electronic Transaction Version 1.0".
Its purpose is to help provide information
on the payment protocol being used if
problems arise.
「xml: lang」によって特定された言語の支払いプロトコルとそのバージョンのProtocolName A物語記述。 例えば、「安全な電子取引バージョン1インチ。」 目的は支払いプロトコルの情報を提供するのを問題が起こるなら使用されることで助けることです。
SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if
this protocol choice is used.
このプロトコル選択が使用されているなら機密保護しているPayment Requestメッセージがどこに送られるべきであるかを示すSecPayReqNetLocnネットLocation。
A secured payment involves the use of a
secure channel such as [TLS] in order
to communicate with the Payment Handler.
機密保護している支払いは、Payment Handlerとコミュニケートするために[TLS]などの安全なチャンネルの使用にかかわります。
The content of this attribute must conform
to [URL].
この属性の内容は[URL]に従わなければなりません。
ReceiverOrgId The Organization Identification which
receives the payment bridge processing
Trading Role Data PackagedContent.
支払いを受け取るReceiverOrgId Organization Identificationは、処理がTrading Role Data PackagedContentであるとブリッジします。
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.
言語における、現在のプロセス状態の任意の原文の記述がConsumerに表示されるべきである「xml: lang」で特定したStatusDesc(256)。 この属性の用法は使用される支払い方法のための支払い補足で定義されます。 特に、それはバンドの外のためのヒント失敗解決を提供します。 長さは256のキャラクタに制限されます。
StyleSheetNetLocn This contains the net location to a style
sheet with visualisation rules for XML
encoded data.
StyleSheetNetLocn ThisはXMLのためのビジュアル化規則がデータを暗号化したことでのスタイルシートにネットの位置を含んでいます。
TimeStamp (30) The date and time in UTC Format when the
payment transaction has been started.
For more information on UTC, see [UTC].
TimeStamp、(30) UTC Formatの支払処理が始められた日時。 UTCの詳しい情報に関しては、[UTC]を見てください。
Hans, et al. Informational [Page 56] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[56ページ]のRFC3867支払いAPI
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)多くの既存の支払いウォレットソフトができる複数の財布です。 Wallet Identifierは実際の財布を選択します。 それが想定される、財布識別子は公共の項目であり、それがIOTP Application Coreによって保存されるかもしれないということです。
xml:lang Defines the language used by the Process
State Description attribute (cf. IOTP
Specification)
xml: 言語がProcess州記述属性で使用したlang Defines(Cf。 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.
アルゴリズムThisはAuthenticationが応答であると生成するのに使用されるかもしれないAlgorithmについて説明する情報を含んでいます。
The algorithm that may be used is
identified by the Name attribute (cf. IOTP
Specification).
使用されるかもしれないアルゴリズムはName属性によって特定されます。(Cf。 IOTP仕様).
AuthReqPackagedContent The Authentication Request Packaged
Content originates from a Authentication
(Data/Response) Component's content
whereby the outermost element tags are
prefixed with "AuthReq". Its declaration
coincides with the Packaged Content's
declaration (cf. IOTP Specification). It
encapsulates the authentication challenge
value. The content of this information is
defined in the supplement for a payment
protocol.
AuthReqPackagedContent Authentication Request Packaged Contentは一番はずれの要素タグが"AuthReq"と共に前に置かれているAuthentication(データ/応答)コンポーネントの内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 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 Authentication Response Packaged Contentは一番はずれの要素タグが「AuthRes」と共に前に置かれているAuthentication Response Componentの内容から発します。
Its declaration coincides with the
Packaged Content's declaration (cf. IOTP
Specification). It encapsulates the
宣言はPackaged Contentの宣言と同時に起こります。(Cf。 IOTP仕様). それは要約されます。
Hans, et al. Informational [Page 57] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[57ページ]のRFC3867支払いAPI
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 Containerは記述に商標を付けます。 内容は一番はずれの要素タグが「ブランド」で前に置かれているBrand Element内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 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 Thisは特定の支払いブランドによって必要とされる追加データを含んでいます。 それはBrand Selection Brand Info Elementの内容を形成します。
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 Thisは形式の特定の支払いブランドによって必要とされる追加データを含んでいます。 それはBrand SelectionプロトコルAmount Info Elementの内容を形成します。
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 Thisは支払いブランドであるどんな追加データと形式で特定の通貨も含んでいます。 それはBrand Selection Currency Amount Info Elementの内容を形成します。
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 Any商人は異なる役割にIOTP Payment Bridgeによって使用されるかもしれないデータについて話しました、例えば、それが暗号化キーではなく、いくつかのショッピングセンターデータにアクセスするIDを含むかもしれません。 Packaged宣言はContentの宣言と同時に起こります。(Cf。 IOTP仕様).
PackagedContent Generic Container for non-IOTP data (cf.
IOTP Specification).
非IOTPデータのためのPackagedContent Generic Container(Cf。 IOTP仕様).
PayProtocolPackagedContent
The Pay Protocol Packaged Content
originates from a Pay Protocol
Element's content whereby the outermost
element tags are prefixed with
一番はずれの要素タグが前に置かれているPayプロトコルElementの内容からプロトコルPackaged Contentと起因するPayProtocolPackagedContent Pay
Hans, et al. Informational [Page 58] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[58ページ]のRFC3867支払いAPI
"PayProtocol". It contains information
about the protocol which is used by
the payment protocol. The content of
this information is defined in the
supplement for a payment protocol. Its
declaration coincides with the Packaged
Content's declaration (cf. IOTP
Specification).
"PayProtocol"。 それは支払いプロトコルによって使用されるプロトコルの情報を含んでいます。 この情報の内容は支払いプロトコルのための補足で定義されます。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 IOTP仕様).
PaySchemePackagedContent
The PayScheme Packaged Content originates
from a Payment Scheme Component's content
whereby the outermost element tags are
prefixed with "PayScheme". Its
declaration coincides with the Packaged
Content's declaration (cf. IOTP
Specification). It carries the payment
specific data. The content of this
information is defined in the supplement
for a payment protocol.
PaySchemePackagedContent PayScheme Packaged Contentは一番はずれの要素タグが"PayScheme"と共に前に置かれているPayment Scheme Componentの内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 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プロトコルAmount Packaged Contentは一番はずれの要素タグが「量」で前に置かれているプロトコルAmount Elementの内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 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プロトコルBrand Packaged Contentは一番はずれの要素タグが"ProtocolBrand"と共に前に置かれているプロトコルBrand Elementの内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 IOTP仕様). それは支払いプロトコルによって使用されるかもしれないブランドの情報を含んでいます。 この情報の内容は支払いプロトコルのための補足で定義されます。
Hans, et al. Informational [Page 59] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[59ページ]のRFC3867支払いAPI
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 Container。 内容は一番はずれの要素タグが「応答」で前に置かれているAuthentication Response ComponentのPackaged Contentから発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 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 Packaged Contentは一番はずれの要素タグが"TradingRoleData"と共に前に置かれているTradingRoleData Componentの内容から発します。 宣言はPackaged Contentの宣言と同時に起こります。(Cf。 IOTP仕様). それは支払いで使用されるプロトコルの周りのConsumerを通してマーチャントからPayment Handlerまでの情報を含んでいます。 この情報の内容は支払いプロトコルのための補足で定義されます。 このパッケージされたコンテンツにおけるName属性が接頭語を含まなければならない、「支払い:」 それを示すために、支払いブリッジはこの、例えば、「支払い: セット過量」を処理します。 詳しい情報に関して[SET/IOTP]を見てください。
The element's declaration coincides with
the Packaged Content's declaration (cf.
IOTP Specification).
要素の宣言はPackaged Contentの宣言と同時に起こります。(Cf。 IOTP仕様).
Table 4: Elements
テーブル4: Elements
XML definition:
XML定義:
<!ENTITY % AuthReqPackagedContent "PackagedContent"> <!ENTITY % AuthResPackagedContent "PackagedContent">
<!実体%AuthReqPackagedContent、「PackagedContent「><!実体%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
Hans, et al. Informational [Page 60] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 60] RFC 3867 Payment API for IOTP November 2004
"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">
3.3. Process States
3.3. Process States
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.
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.
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.
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.3.1. Merchant
3.3.1. Merchant
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.
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.
ProcessState Description ------------ -----------
ProcessState Description ------------ -----------
NotYetStarted The Payment Transaction exists within the
IOTP Application Core, i.e., the
Merchant's shop has already signaled to
the IOTP Application Core that an IOTP
transaction has been initiated by the
Consumer.
NotYetStarted 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.
However, neither any API call has been
issued to the IOTP Payment Bridge nor has
the IOTP Order Request has been created.
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.
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.
Hans, et al. Informational [Page 61] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 61] RFC 3867 Payment API for IOTP November 2004
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).
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.
However, this value does not indicate that any IOTP Order Request has been created and transmitted to the Consumer.
Suspended The IOTP transaction has been suspended
before the order request block has been
transmitted to the Consumer.
Suspended The IOTP transaction has been suspended before the order request block has been transmitted to the Consumer.
Implicitly, the payment is also deferred.
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 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.
But it contains no indication about the
status of the actual payment, which is
accepted by the Payment Handler.
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.
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.
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.
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.
As IOTP provides no communication channel
between the Merchant and Payment Handler,
any change of payment process state will
As IOTP provides no communication channel between the Merchant and Payment Handler, any change of payment process state will
Hans, et al. Informational [Page 62] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 62] RFC 3867 Payment API for IOTP November 2004
be initiated out-of-band to IOTP, e.g., by
electronic statements of account or
payment scheme specific mechanisms.
be initiated out-of-band to IOTP, e.g., by electronic statements of account or payment scheme specific mechanisms.
Failed The IOTP transaction, i.e., order
processing, has failed for some
(business) reason and it is known that no
payment will occur.
Failed The IOTP transaction, i.e., order processing, has failed for some (business) reason and it is known that no payment will occur.
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).
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.
However, the ideal point of view of IOTP suspects that the actual payment transaction has been neither started nor initiated.
ProcessError The IOTP transaction, i.e., order
processing, has failed for some
(technical) reason and it is known that
no payment will occur.
ProcessError The IOTP transaction, i.e., order processing, has failed for some (technical) reason and it is known that no payment will occur.
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).
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.
However, the ideal point of view of IOTP suspects that the actual payment transaction has been neither started nor initiated.
Table 5: Merchant
Table 5: Merchant
3.3.2. Consumer
3.3.2. Consumer
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.
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.
Hans, et al. Informational [Page 63] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 63] RFC 3867 Payment API for IOTP November 2004
ProcessState Description ------------ -----------
ProcessState Description ------------ -----------
NotYetStarted This encodes the initial process state of
any IOTP payment transaction. This value
is set during brand selection but it
normally will not change during the whole brand
selection process.
NotYetStarted 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.
InProgress With the issuance of the Start Payment
Consumer API call, the IOTP Application
Core changes the process state to this
value.
InProgress With the issuance of the Start Payment Consumer API call, the IOTP Application Core changes the process state to this value.
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".
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".
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).
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 The successful payment has been acknowledged by the Payment Handler, i.e., the successful IOTP Payment Response has been received.
Implicitly, this implies successful order
processing.
Implicitly, this implies successful order processing.
Hans, et al. Informational [Page 64] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 64] RFC 3867 Payment API for IOTP November 2004
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.
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.
ProcessError The IOTP transaction, i.e., order or
payment processing, has failed for some
(technical) reason.
ProcessError The IOTP transaction, i.e., order or payment processing, has failed for some (technical) reason.
However, the local process state might be
different from that of Payment Handler.
However, the local process state might be different from that of Payment Handler.
Table 6: Consumer
Table 6: Consumer
3.3.3. Payment Handler
3.3.3. Payment Handler
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.
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.
ProcessState Description ------------ -----------
ProcessState Description ------------ -----------
NotYetStarted This encodes the initial process state of
any payment transaction. Typically, this
value will last for a short amount of
time.
NotYetStarted This encodes the initial process state of any payment transaction. Typically, this value will last for a short amount of time.
InProgress The IOTP Application Core changes the
process state changes to "InProgress"
when the Payment Handler starts with the
actual processing of the IOTP Payment
Request Block.
InProgress 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.
Note that this does not assume that the
"StartPaymentPaymentHandler" API function
has been called.
Note that this does not assume that the "StartPaymentPaymentHandler" API function has been called.
Suspended The payment transaction has been
suspended.
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 The payment has been processed, successfully, i.e., the IOTP Payment Response Block was created and transmitted to the Consumer.
Hans, et al. Informational [Page 65] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 65] RFC 3867 Payment API for IOTP November 2004
Failed The payment transaction, has finally
failed for some (business) reason.
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.
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 The payment transaction, has finally failed for some (technical) reason.
Note that this value encodes the payment
state reported by the IOTP Payment
Bridge. It does not reflect whether some
IOTP Error Block has been created and
submitted to the Consumer.
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
Table 7: Consumer
4. Payment API Calls
4. Payment API Calls
4.1. Brand Compilation Related API Calls
4.1. Brand Compilation Related API Calls
4.1.1. Find Accepted Payment Brand
4.1.1. Find Accepted Payment Brand
This API function determines the payment brands being accepted by the Payment Handler on behalf of the Merchant.
This API function determines the payment brands being accepted by the Payment Handler on behalf of the Merchant.
Input Parameters
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 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.
Hans, et al. Informational [Page 66] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 66] RFC 3867 Payment API for IOTP November 2004
XML definition:
XML definition:
<!ELEMENT FindAcceptedPaymentBrand (MerchantData*) >
<!ATTLIST FindAcceptedPaymentBrand
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentBrand (MerchantData*) > <!ATTLIST FindAcceptedPaymentBrand PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED MerchantPayId CDATA #REQUIRED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED >
Output Parameters
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 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
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.
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 definition:
<!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) >
<!ELEMENT BrandItem (BrandPackagedContent*) >
<!ATTLIST BrandItem
BrandId CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) > <!ELEMENT BrandItem (BrandPackagedContent*) > <!ATTLIST BrandItem BrandId CDATA #REQUIRED xml:lang NMTOKEN #IMPLIED BrandName CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED BrandNarrative CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Hans, et al. Informational [Page 67] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 67] RFC 3867 Payment API for IOTP November 2004
4.1.2. Find Accepted Payment Protocol
4.1.2. Find Accepted Payment Protocol
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:
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:
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 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 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.
Input Parameters
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 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.
XML definition:
XML definition:
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
MerchantData?) >
<!ATTLIST FindAcceptedPaymentProtocol
BrandId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*, MerchantData?) > <!ATTLIST FindAcceptedPaymentProtocol BrandId CDATA #IMPLIED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED MerchantPayId CDATA #REQUIRED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED >
Hans, et al. Informational [Page 68] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 68] RFC 3867 Payment API for IOTP November 2004
Output Parameters
Output Parameters
o Payment Protocol Identifier - for insertion in the Brand List
Component's Pay Protocol Element
o Protocol Brand Identifier - for insertion in the Protocol Brand
Element of the Brand List Component's Brand Element
o Payment Protocol Name and language annotation- for insertion in
the Brand List Component's Pay Protocol Element
o Payment Request Net Location - for insertion in the Brand List
Component's Pay Protocol Element
o Secured Payment Request Net Location - for insertion in the
Brand List Component's Pay Protocol Element
o Brand Item List (cf. Section 4.1.1) - there must be at least
one element if no brand identifier has been provided on the
input parameter list.
o (Protocol Amount) Packaged Content - for insertion in the Brand
List Component's Protocol Amount Element
o (Pay Protocol) Packaged Content - for insertion in the Brand
List Component's Pay Protocol Element
o Currency Amount element - quite similar to the definition in
[IOTP], that contain
- refined Currency Code and Currency - for insertion in the
Brand List Component's Currency Amount Element
- refined Payment Amount - for insertion in the Brand List
Component's Currency Amount Element
o Brand - there must be at least one element in each Protocol
Item if no brand identifier has been provided on the input
parameter list.
o 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.
XML definition:
XML definition:
<!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+,
BrandItem*) >
<!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*
CurrencyAmount+, Brand*,ProtocolBrand*)>
<!ATTLIST ProtocolItem
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
xml:lang NMTOKEN #IMPLIED
ProtocolName CDATA #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED >
<!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+, BrandItem*) > <!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*, PayProtocolPackagedContent* CurrencyAmount+, Brand*,ProtocolBrand*)> <!ATTLIST ProtocolItem ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIED xml:lang NMTOKEN #IMPLIED ProtocolName CDATA #REQUIRED PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED >
<!ELEMENT Brand EMPTY >
<!ATTLIST Brand
BrandId CDATA #REQUIRED >
<!ELEMENT Brand EMPTY > <!ATTLIST Brand BrandId CDATA #REQUIRED >
Hans, et al. Informational [Page 69] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 69] RFC 3867 Payment API for IOTP November 2004
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #IMPLIED
Amount CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY > <!ATTLIST CurrencyAmount CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #IMPLIED Amount CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.1.3. Get Payment Initialization Data
4.1.3. Get Payment Initialization Data
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.
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.
Input Parameters
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 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
Merchant Payment Identifier
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 Merchant Organisation Identifier - used for distinction between multiple merchants that share the some IOTP merchant system o Wallet Identifier and/or Pass Phrase
Protocol Brand Element
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 (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
Hans, et al. Informational [Page 70] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 70] RFC 3867 Payment API for IOTP November 2004
o (Pay Protocol) Packaged Content - further payment protocol
description, from the Brand List Component's Pay Protocol
Element
o (Protocol Brand) Packaged Content - further brand information,
from the Protocol Brand Element of the Brand List Component
which relates to the selected Brand Element, if any
o (Order) Packaged Content - further order description, from the
Order Element
o three Brand Selection Info Packaged Content elements - copied
from the Brand Selection Component on brand dependent purchases
o Brand - additional data about the payment brand
o Protocol Amount - additional data about the payment protocol
o Currency Amount - additional payment brand and currency
specific data
o Merchant Data - specific data used by the IOTP Payment Bridge
which is managed in the IOTP Application Core.
o (Pay Protocol) Packaged Content - further payment protocol description, from the Brand List Component's Pay Protocol Element o (Protocol Brand) Packaged Content - further brand information, from the Protocol Brand Element of the Brand List Component which relates to the selected Brand Element, if any o (Order) Packaged Content - further order description, from the Order Element o three Brand Selection Info Packaged Content elements - copied from the Brand Selection Component on brand dependent purchases o Brand - additional data about the payment brand o Protocol Amount - additional data about the payment protocol o Currency Amount - additional payment brand and currency specific data o Merchant Data - specific data used by the IOTP Payment Bridge which is managed in the IOTP Application Core.
XML definition:
XML definition:
<!ELEMENT GetPaymentInitializationData (ProtocolBrand?
BrandPackagedContent*
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
MerchantData*) >
<!ATTLIST GetPaymentInitializationData
BrandId CDATA #REQUIRED
MerchantPayId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ReceiverOrgId CDATA #IMPLIED
MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT GetPaymentInitializationData (ProtocolBrand? BrandPackagedContent* ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, OrderPackagedContent*, BrandSelBrandInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*, BrandSelCurrencyAmountInfoPackagedContent*, MerchantData*) > <!ATTLIST GetPaymentInitializationData BrandId CDATA #REQUIRED MerchantPayId CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ProtocolId CDATA #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ReceiverOrgId CDATA #IMPLIED MerchantOrgId CDATA #IMPLIED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
Hans, et al. Informational [Page 71] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 71] RFC 3867 Payment API for IOTP November 2004
Output Parameters
Output Parameters
o OkFrom, OkTo - for insertion in the Payment Component
o (TradingRoleData) Packaged Content - further payment protocol
description; the Name Attribute of the packaged Content
element must include "Payment:" as the prefix,
for example "Payment:SET-OD". For more information, see
[SET/IOTP].
o (Order) Packaged Content - defaults to the supplied order
packaged content if omitted.
o OkFrom, OkTo - 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.
XML definition:
XML definition:
<!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.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.1.4. Inquire Authentication Challenge
4.1.4. Inquire Authentication Challenge
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.
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.
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.
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.
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.
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.
The IOTP Payment Bridge responds with the Business Error Code if it does not provide any (more) authentication algorithms and challenges.
The IOTP Payment Bridge responds with the Business Error Code if it does not provide any (more) authentication algorithms and challenges.
Hans, et al. Informational [Page 72] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 72] RFC 3867 Payment API for IOTP November 2004
Input Parameters
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 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
XML definition:
XML definition:
<!ELEMENT InquireAuthChallenge (Algorithm*) >
<!ATTLIST InquireAuthChallenge
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT InquireAuthChallenge (Algorithm*) > <!ATTLIST InquireAuthChallenge AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
Output Parameters
Output Parameters
o list of Authentication Challenge Packaged Contents - for
insertion into the IOTP Authentication Request Component
o Algorithm Element - for insertion into the IOTP Authentication
Request Component
o 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
XML definition:
XML definition:
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
Algorithm) >
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*, Algorithm) >
4.1.5. Authenticate
4.1.5. Authenticate
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.
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.
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.
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.
Failed authentication is reported by the Business Error Code which
might trigger the inquiry of the details ("Inquire Process State").
Final failures might be encoded by the process state "Failed".
Failed 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".
Hans, et al. Informational [Page 73] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 73] RFC 3867 Payment API for IOTP November 2004
Input Parameters
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 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
XML definition:
XML definition:
<!ELEMENT Authenticate (Algorithm, AuthReqPackagedContent*) >
<!ATTLIST Authenticate
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT Authenticate (Algorithm, AuthReqPackagedContent*) > <!ATTLIST Authenticate AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
Output Parameters
Output Parameters
o Authentication Response Packaged Content - for insertion into
the IOTP Authentication Response Component
o Authentication Response Packaged Content - for insertion into the IOTP Authentication Response Component
XML definition:
XML definition:
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.1.6. Check Authentication Response
4.1.6. Check Authentication Response
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.
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.
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".
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".
Hans, et al. Informational [Page 74] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 74] RFC 3867 Payment API for IOTP November 2004
Input Parameters
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 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
XML definition:
XML definition:
<!ELEMENT CheckAuthResponse (Algorithm, AuthReqPackagedContent*,
AuthResPackagedContent*) >
<!ATTLIST CheckAuthResponse
AuthenticationId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT CheckAuthResponse (Algorithm, AuthReqPackagedContent*, AuthResPackagedContent*) > <!ATTLIST CheckAuthResponse AuthenticationId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
Output Parameters
Output Parameters
o Current Process (Authentication) State o Completion Code o Status Description and its language annotation
o Current Process (Authentication) State o Completion Code o Status Description and its language annotation
XML definition:
XML definition:
<!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 | Suspended | CompletedOk | Failed | 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.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Hans, et al. Informational [Page 75] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 75] RFC 3867 Payment API for IOTP November 2004
4.2. Brand Selection Related API Calls
4.2. Brand Selection Related API Calls
4.2.1. Find Payment Instrument
4.2.1. Find Payment Instrument
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.
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.
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.
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.
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.
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.
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.
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.
Input Parameters
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 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
Hans, et al. Informational [Page 76] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 76] RFC 3867 Payment API for IOTP November 2004
o Element (Protocol) Packaged Content - further payment protocol
description, copied from the Brand List Component's Pay
Protocol Element
o Element (Protocol) Packaged Content - further payment protocol description, copied from the Brand List Component's Pay Protocol Element
XML definition:
XML definition:
<!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
ProtocolBrand?,
PayProtocolPackagedContent*,
ProtocolAmountPackagedContent*) >
<!ATTLIST FindPaymentInstrument
BrandId CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED >
<!ELEMENT FindPaymentInstrument (BrandPackagedContent*, ProtocolBrand?, PayProtocolPackagedContent*, ProtocolAmountPackagedContent*) > <!ATTLIST FindPaymentInstrument BrandId CDATA #REQUIRED ProtocolId CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED >
Output Parameters
Output Parameters
o The known Payment Instrument Identifiers, these are internal
values
o The user-defined names of the payment instrument and their
language encoding
o The known Payment Instrument Identifiers, these are internal values o The user-defined names of the payment instrument and their language encoding
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.
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.
XML definition:
XML definition:
<!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.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Hans, et al. Informational [Page 77] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 77] RFC 3867 Payment API for IOTP November 2004
4.2.2. Check Payment Possibility
4.2.2. Check Payment Possibility
This API function checks whether a payment (both debit and credit) can go ahead. It can be used, for example, to check
This API function checks whether a payment (both debit and credit) can go ahead. It can be used, for example, to check
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 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.
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.
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.
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.
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.
Input Parameters
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 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
Hans, et al. Informational [Page 78] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 78] RFC 3867 Payment API for IOTP November 2004
o Protocol Brand Identifier - copied from the selected Protocol
Brand Element of the Brand List Component which relates to the
selected Brand Element, if any
o Consumer Payment Identifier - Consumer's unique reference to the
current payment transaction
o Wallet Identifier and/or Pass Phrase
o (Brand) Packaged Content - copied from the selected Brand Element
o (Protocol Amount) Packaged Content - copied from the selected
Protocol Amount Element
o (Protocol) Packaged Content - copied from the selected Pay
Protocol Element
o (Protocol Brand) Packaged Content - copied from the selected
Protocol Brand Element of the Brand List Component which relates
to the selected Brand Element, if any
o Protocol Brand Identifier - 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
XML definition:
XML definition:
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*>
<!ATTLIST CheckPaymentPossibility
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
ProtocolId CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*, ProtocolBrand? ProtocolAmountPackagedContent*, PayProtocolPackagedContent*> <!ATTLIST CheckPaymentPossibility BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED PayDirection (Debit|Credit) #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED ProtocolId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED >
Output Parameters
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 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
Hans, et al. Informational [Page 79] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 79] RFC 3867 Payment API for IOTP November 2004
XML definition:
XML definition:
<!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.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.3. Payment Transaction Related API calls
4.3. Payment Transaction Related API calls
These Payment API calls may be made either by the Consumer's or Payment Handler's IOTP Application Core.
These Payment API calls may be made either by the Consumer's or Payment Handler's IOTP Application Core.
4.3.1. Start Payment Consumer
4.3.1. Start Payment Consumer
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.
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.
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.
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.
Input Parameters
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 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
Hans, et al. Informational [Page 80] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 80] RFC 3867 Payment API for IOTP November 2004
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 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
XML definition:
XML definition:
<!ELEMENT StartPaymentConsumer (BrandPackagedContent*,
ProtocolBrand?
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
OrderPackagedContent*) >
<!ATTLIST StartPaymentConsumer
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
<!ELEMENT StartPaymentConsumer (BrandPackagedContent*, ProtocolBrand? ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, OrderPackagedContent*) > <!ATTLIST StartPaymentConsumer BrandId CDATA #REQUIRED PaymentInstrumentId CDATA #IMPLIED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #IMPLIED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED WalletID CDATA #IMPLIED Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
Hans, et al. Informational [Page 81] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 81] RFC 3867 Payment API for IOTP November 2004
Output Parameters
Output Parameters
o Continuation Status
o (Payment Scheme) Packaged Content - for insertion into the
Payment Scheme Component of the IOTP Payment Request Block
o Continuation Status o (Payment Scheme) Packaged Content - for insertion into the Payment Scheme Component of the IOTP Payment Request Block
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
The IOTP Application Core is allowed to reissue this request several times on failed analyses of the response.
XML definition:
XML definition:
<!ELEMENT StartPaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT StartPaymentConsumerResponse (PaySchemePackagedContent*) > <!ATTLIST StartPaymentConsumerResponse ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.3.2. Start Payment Payment Handler
4.3.2. Start Payment Payment Handler
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.
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.
Input Parameters
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 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
Hans, et al. Informational [Page 82] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 82] RFC 3867 Payment API for IOTP November 2004
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 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.
XML definition:
XML definition:
<!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*,
BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*,
TradingRoleDataPackagedContent*,
PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandler
BrandId CDATA #REQUIRED
ConsumerPayId CDATA #IMPLIED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED
Amount CDATA #REQUIRED
PayDirection (Debit|Credit) #REQUIRED
ProtocolId CDATA #REQUIRED
<!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*, ProtocolBrand?, ProtocolAmountPackagedContent*, PayProtocolPackagedContent*, BrandSelBrandInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*, BrandSelCurrencyAmountInfoPackagedContent*, TradingRoleDataPackagedContent*, PaySchemePackagedContent*) > <!ATTLIST StartPaymentPaymentHandler BrandId CDATA #REQUIRED ConsumerPayId CDATA #IMPLIED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED Amount CDATA #REQUIRED PayDirection (Debit|Credit) #REQUIRED ProtocolId CDATA #REQUIRED
Hans, et al. Informational [Page 83] RFC 3867 Payment API for IOTP November 2004
Hans, et al. Informational [Page 83] RFC 3867 Payment API for IOTP November 2004
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 Passphrase CDATA #IMPLIED CallBackFunction CDATA #IMPLIED CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters
Output Parameters
o Continuation Status
o (Payment Scheme) Packaged Content - for insertion into the
Payment Scheme Component of the IOTP Payment Exchange Block
o Continuation Status o (Payment Scheme) Packaged Content - for insertion into the Payment Scheme Component of the IOTP Payment Exchange Block
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.
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.
XML definition:
XML definition:
<!ELEMENT StartPaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
<!ELEMENT StartPaymentPaymentHandlerResponse (PaySchemePackagedContent*) > <!ATTLIST StartPaymentPaymentHandlerResponse ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
4.3.3. Resume Payment Consumer
4.3.3. Resume Payment Consumer
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.
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.
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 Payment Request BlockかIOTP Payment Exchange Blockが、生成される必要であるかどうか決めるのは、IOTP Application Core次第です。 1つのインディケータがPayment Handler(例えば、Payment Handler Payment Identifierに関する知識)からの前のIOTP Payment Exchange Blockの領収書であるかもしれません。
Input Parameters
入力パラメタ
o Consumer Payment Identifier o Wallet Identifier and/or Pass Phrase
o 消費者Payment Identifier oのWallet Identifier、そして/または、Pass Phrase
Hans, et al. Informational [Page 84] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[84ページ]のRFC3867支払いAPI
o Call Back Function - used for end user notification/logging
purposes
o 目的をエンドユーザ通知に使用されるか、または登録して、Back Functionに電話をしてください。
XML definition:
XML定義:
<!ELEMENT ResumePaymentConsumer EMPTY >
<!ATTLIST ResumePaymentConsumer
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
空の<!の<!ATTLIST ResumePaymentConsumer ConsumerPayId CDATA#必要なWalletID CDATA要素ResumePaymentConsumer>#、は、パスフレーズCDATA#が、CallBackFunction CDATA#が、CallBackLanguageList NMTOKENS#が>を含意するのを含意するのを含意したのを含意しました。
Output Parameters
出力パラメタ
o Continuation Status
o (Payment Scheme) Packaged Content - for insertion in the
Payment Scheme Component of the next IOTP message (Payment
Exchange or Request Block).
o 継続Status o(支払いScheme)は次のIOTPメッセージ(支払いExchangeかRequest Block)のPayment Scheme Componentへの挿入のためにContentをパッケージしました。
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 Application Coreは応答の失敗した分析のときに何度かこの要求を再発行できます。 しかしながら、IOTP Payment Bridgeは、Consumer Payment Identifier属性を「命名する」"AttNotSupp"Error Codeを使用することによって、再開要求を拒絶するかもしれません。 次に、Consumerが通常のエラー処理を電流に適用しなければならない、(サブ、)、トランザクションとPayment Handlerへの問題のa新しいPayment Request Blockに。
XML definition:
XML定義:
<!ELEMENT ResumePaymentConsumerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED >
<!要素ResumePaymentConsumerResponse(PaySchemePackagedContent*)><!ATTLIST ResumePaymentConsumerResponse ContStatus(終わってください| 続く)#、は>を必要としました。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.3.4. Resume Payment Payment Handler
4.3.4. 支払い支払い操作者を再開してください。
This API function resumes a payment at the Payment Handler side.
このAPI関数はPayment Handler側で支払いを再開します。
Input Parameters
入力パラメタ
o Payment Handler Payment Identifier
o Wallet Identifier - renaming to till identifier neglected - and
Pass Phrase
o 支払いHandler Payment Identifier o Wallet Identifier(無視されるとの識別子まで改名)とPass Phrase
Hans, et al. Informational [Page 85] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[85ページ]のRFC3867支払いAPI
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 Call Back Language Listをエンドユーザ通知に使用されるか、または登録して、Back Functionに電話をしてください。 このリストがCall Back Functionがセットo(支払いScheme)のパッケージされたContentであるなら必要です--受信されたIOTPメッセージ(支払いExchangeかRequest Block)のPayment Scheme Componentから、コピーされます。
XML definition:
XML定義:
<!ELEMENT ResumePaymentPaymentHandler
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandler
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED >
<!要素ResumePaymentPaymentHandler(PaySchemePackagedContent*)><!ATTLIST ResumePaymentPaymentHandler PaymentHandlerPayId CDATAの#必要なWalletID CDATA#、は、パスフレーズCDATA#が、CallBackFunction CDATA#が、CallBackLanguageList NMTOKENS#が>を含意するのを含意するのを含意したのを含意しました。
Output Parameters
出力パラメタ
o Continuation Status
o (Payment Scheme) Packaged Content - for insertion in the
Payment Scheme Component of the next Payment Exchange Block.
o 継続Status o(支払いScheme)は次のPayment Exchange BlockのPayment Scheme Componentへの挿入のためにContentをパッケージしました。
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 Application Coreは応答の失敗した分析のときに何度かこの要求を再発行できます。
XML definition:
XML定義:
<!ELEMENT ResumePaymentPaymentHandlerResponse
(PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED >
<!要素ResumePaymentPaymentHandlerResponse(PaySchemePackagedContent*)><!ATTLIST ResumePaymentPaymentHandlerResponse ContStatus(終わってください| 続く)#、は>を必要としました。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.3.5. Continue Process
4.3.5. プロセスを持続させてください。
This API function passes one specific IOTP Payment Scheme Component, i.e., the encapsulated Packaged Content elements, received from the counter party (e.g., Consumer) to the IOTP Payment Bridge and responds with the next IOTP Payment Scheme Component for submission to the counter party.
このAPI関数は、すなわち、1特定のIOTP Payment Scheme Component、カプセル化されたPackaged Contentに要素を渡して、カウンター・パーティ(例えば、Consumer)からIOTP Payment Bridgeまで受信して、カウンター・パーティへの服従のために次のIOTP Payment Scheme Componentと共に応じます。
Hans, et al. Informational [Page 86] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[86ページ]のRFC3867支払いAPI
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のPayment Identifier o Process(トランザクション)はどれがPaymentsを見分けるか、そして、Inquiriesをタイプします。o Wallet Identifier、そして/または、Pass Phrase o(支払いScheme)はContentをパッケージしました--容認されたPayment Exchange BlockのPayment Scheme ComponentかError Blockからコピーされます。
Each party should set the payment identifier with the local identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment Handler: PaymentHandlerPayId).
各当事者はローカルの識別子(消費者: ConsumerPayId; 商人: MerchantPayId; 支払いHandler: PaymentHandlerPayId)で支払い識別子を設定するべきです。
XML definition:
XML定義:
<!ELEMENT ContinueProcess (PaySchemePackagedContent+) >
<!ATTLIST ContinueProcess
PayId CDATA #REQUIRED
ProcessType (Payment | Inquiry) 'Payment'
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!要素ContinueProcess(PaySchemePackagedContent+)><!ATTLIST ContinueProcess PayId CDATA#必要なProcessType(支払い| 問い合せ)'支払い'WalletID CDATA#は、パスフレーズCDATA#が>を含意したのを含意しました。
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 継続Status o(支払いScheme)は次のPayment Exchange Blockか最終的なPayment Response BlockのPayment Scheme Componentへの挿入のためにContentをパッケージしました。
The response message contains payment schema data if the continuation status signals "Continue". The IOTP Payment Bridge must signal "End", if the payment scheme data was received within an IOTP Error Block containing an Error Component with severity HardError.
継続ステータス信号が「続く」なら、応答メッセージは支払い図式データを含んでいます。 IOTP Payment Bridgeは「終わり」に合図しなければなりません、厳しさHardErrorとError Componentを含んでいて、IOTP Error Blockの中に支払い体系データを受け取ったなら。
XML definition:
XML定義:
<!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) >
<!ATTLIST ContinueProcessResponse
ContStatus (End|Continue) #REQUIRED >
<!要素ContinueProcessResponse(PaySchemePackagedContent*)><!ATTLIST ContinueProcessResponse ContStatus(終わってください| 続く)#、は>を必要としました。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
Hans, et al. Informational [Page 87] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[87ページ]のRFC3867支払いAPI
4.3.6. Change Process State
4.3.6. 変化プロセス状態
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 Application Coreはこの要求で現在の支払い状態を変えます。 IOTP Payment Bridgeはビジネスのレベルの通常の終了、キャンセル、サスペンション、および整理過程の誤差に関して通知されるかもしれません。 通知は、意図しているプロセス状態を要求しながら、偶然通りかかります。
The IOTP Payment Bridge processes the status change and reports the result.
IOTP Payment Bridgeは状態変化を処理して、結果を報告します。
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 Application Coreは、IOTP Payment Bridgeが状態スイッチを同意するか、または傾けたかどうかチェックするためにどんな返されたプロセス状態も分析しなければなりません。 例えば、提出されたProcess州"CompleteOk"は支払処理が既に失敗したなら「失敗された」Payment Statusに通じるかもしれません。
Transaction Suspension is notified by the newly introduced Process State "Suspended". The other attribute values have been taken from the IOTP specification.
トランザクションSuspensionは州が「中断させた」新たに導入されたProcessによって通知されます。 他の属性値は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関数はConsumerによるIOTP Payment Bridgeへの"FindPaymentInstrument"の発行、マーチャントによる"FindAcceptedPaymentBrand"の発行、または"StartPaymentPaymentHandler"の発行の後に各支払処理のためにいつでもPayment HandlerによってConsumer、マーチャント、またはPayment Handlerによって呼ばれるかもしれません。
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.
Process States"CompletedOk"は「失敗しました」、そして、"ProcessError"はその後の呼び出しのときに彼らを変えることができないという意味で最終的です。 しかしながら、そのような両立しない呼び出しが発行されたなら、API関数はエラーコードとともに帰るべきではありません。 代わりに、それは古い変わりのないProcess州を報告するべきです。
Unknown payment transactions are reported by the Error Code "AttValInvalid" pointing to the PayId attribute.
未知の支払処理はPayId属性を示すError Code"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 パーティのPayment Identifier o意図しているPayment Status oはPaymentsとInquiries oのWallet Identifier、そして/または、Pass Phraseを見分けるCompletion Code o Process(トランザクション)タイプを意図しました。
Hans, et al. Informational [Page 88] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[88ページ]のRFC3867支払いAPI
XML definition:
XML定義:
<!ELEMENT ChangeProcessState EMPTY >
<!ATTLIST ChangeProcessState
PayId CDATA #REQUIRED
ProcessState (NotYetStarted |
InProgress |
Suspended |
CompletedOk |
Failed |
ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessType (Payment | Inquiry) 'Payment'
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!の要素のChangeProcessStateの空の><!ATTLIST ChangeProcessState PayId CDATA#がProcessStateを必要とした、(NotYetStarted| InProgress| | CompletedOk| | ProcessError) 吊した失敗した#必要なCompletionCode NMTOKEN#暗示しているProcessType(支払い| 問い合せ)'支払い'WalletID CDATA#は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
o Process State and Percent Complete o Completion Code o Status Description and its language annotation
o 州、Percent Complete o Completion Code o Status記述、およびその言語注釈を処理してください。
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はError Codesを導入します。
4.4. General Inquiry API Calls
4.4. 一般問い合せAPI呼び出し
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.
以下の呼び出しは、必ず支払処理に割り当てられるというわけではなくて、いつでも、発行されるかもしれません。 いかなる他の呼び出しでも依存が全くありません。
Hans, et al. Informational [Page 89] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[89ページ]のRFC3867支払いAPI
4.4.1. Remove Payment Log
4.4.1. 支払いログを取り除いてください。
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 Application Coreは、IOTP Payment Bridgeを通してPayment Logファイルでのどんな記録(記載された支払処理とのその取引)も取り除かれるかもしれないようにIOTP Payment Bridge、そして/または、対応するExisting Payment Softwareに通知します。
Input Parameters
入力パラメタ
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase
o パーティのPayment Identifier oのWallet Identifier、そして/または、Pass Phrase
XML definition:
XML定義:
<!ELEMENT RemovePaymentLog EMPTY >
<!ATTLIST RemovePaymentLog
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
空の<!の<!ATTLIST RemovePaymentLog PayId CDATA#必要なWalletID CDATA要素RemovePaymentLog>#、は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
XML definition:
XML定義:
<!ELEMENT RemovePaymentLogResponse EMPTY > <!ATTLIST RemovePaymentLogResponse >
<!要素RemovePaymentLogResponseは><!ATTLIST RemovePaymentLogResponse>を空にします。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.4.2. Payment Instrument Inquiry
4.4.2. 支払い器具問い合せ
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関数はPayment Instrumentの特性を検索します。 この識別子が他の手段で引き出されるなら、Payment Instrument Identifierは省略されるかもしれません、例えば、現在挿入されたチップカードの分析で。 Payment器具が唯一断固としていた状態でそうすることができないなら、IOTP Payment Bridgeは適当な対話をユーザ入力に提供するかもしれません。
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関数は支払い器具の発行人のCustomer Care Providerとの問題解決の間、使用されるかもしれません、支払いの器具の特定の値について問い合わせるために。
Input parameters
入力パラメタ
o Brand Identifier o Payment Instrument Identifier o Protocol Identifier
o ブランドIdentifier o Payment Instrument Identifier oプロトコルIdentifier
Hans, et al. Informational [Page 90] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[90ページ]のRFC3867支払いAPI
o Wallet Identifier and/or Pass Phrase
o Property Type List - sequence of values whose language is
identified by xml:lang
o (Brand) PackagedContent Content - further payment brand
description
o Protocol Brand Content - further payment brand information
o (Protocol Amount) PackagedContent Content - further payment
protocol description
o (Pay Protocol) PackagedContent Content - further payment
protocol description
o 財布Identifier、そして/または、Pass Phrase o Property Type List--言語がxmlによって特定される値の系列: lang o(ブランド)PackagedContent Content--さらなる支払いブランド記述oプロトコルBrand Content--さらなる支払いブランド情報o(プロトコルAmount)PackagedContent Content--さらなる支払いプロトコル記述o(プロトコルを支払います)PackagedContent Content--さらなる支払いプロトコル記述
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 Payment Brand特定のコードであるかもしれないものをコード化します。
Generic codes for the Property Type List are:
Property Type Listのためのジェネリックコードは以下の通りです。
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
特性のType Meaning Balance CurrentバランスLimit MaximumバランスPaymentLimit Maximum支払処理限界Expiration Expiration日付Identifier Issuerは支払い器具に関する識別子を割り当てました。 通常、それはAPIの支払い器具識別子に合わせません。 保存された支払処理エントリーのLogEntries Number。 エントリーは0(最新の)〜何らかの非負の数まで最も古いエントリーに付番されます。 トランザクション、nがそうするn番目の記録された支払いではn番目の支払いの否定的PayPartyn Remoteパーティーはトランザクションを記録して、nはそうするかもしれません。PayAmountn Payment Amount、n番目の支払いの否定的PayTimen Timeがトランザクションを記録した、nがそうするかもしれない、否定的
XML definition:
XML定義:
<!ELEMENT PaymentInstrumentInquiry (BrandPackagedContent*,
ProtocolBrand?,
ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*) >
<!ATTLIST PaymentInstrumentInquiry
BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED
ProtocolId CDATA #REQUIRED
ATTLIST PaymentInstrumentInquiry BrandId CDATAの必要なPaymentInstrumentId CDATA#暗示しているProtocolId CDATA##、が必要とした<!要素PaymentInstrumentInquiry(BrandPackagedContent*、ProtocolBrand?、ProtocolAmountPackagedContent*、PayProtocolPackagedContent*)><!
Hans, et al. Informational [Page 91] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[91ページ]のRFC3867支払いAPI
PropertyTypeList NMTOKENS #REQUIRED
xml:lang NMTOKEN #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
PropertyTypeList NMTOKENS#REQUIRED xml: lang NMTOKEN#IMPLIED WalletID CDATA#IMPLIED Passphrase CDATA#IMPLIED>。
Output parameters
出力パラメタ
o a list of zero or more unavailable property values whose
language are identified by xml:lang.
o a list of zero or more sets of "Properties Types", "Property
Values" and "Property Descriptions"
o だれの言語がxml: lang○ ゼロのリストによって特定されるか、そして、「特性のタイプ」と、「特性の値」と、より多くの「不動産の表示」というゼロか、より入手できない特性の値のリスト
XML definition:
XML定義:
<!ELEMENT PaymentInstrumentInquiryResponse
(PaymentInstrumentProperty*) >
<!ATTLIST PaymentInstrumentInquiryResponse
xml:lang NMTOKEN #REQUIRED
UnavailablePropertyList NMTOKENS #IMPLIED >
<!ELEMENT PaymentInstrumentProperty EMPTY >
<!ATTLIST PaymentInstrumentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
<!ELEMENT PaymentInstrumentInquiryResponse(PaymentInstrumentProperty*)><!ATTLIST PaymentInstrumentInquiryResponse xml: lang NMTOKEN#REQUIRED UnavailablePropertyList NMTOKENS#IMPLIED><!ELEMENT PaymentInstrumentProperty EMPTY><!ATTLIST PaymentInstrumentProperty PropertyType NMTOKEN#REQUIRED PropertyValue CDATA#REQUIRED PropertyDesc CDATA#REQUIRED>。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.4.3. Inquire Pending Payment
4.4.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 Payment Bridge/既存のPayment Softwareが推薦するどんな未定の支払処理に関する支払い識別子も新しい支払処理の処理の前に完成されるか、または中断すると報告します。 それはさらなるトランザクションの詳細で応じません。 これらは「プロセス状態について問い合わせてください」で要求されていなければなりません。
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 Payment Bridgeがどんなパス句の利益なしでも応じなければならないことに注意してください。 しかし、いくつかの未定の支払処理があれば、IOTP Payment Bridgeは即時型反応を拒否して、代わりにIOTP Application Coreから適切なパスフェーズを要求するかもしれません。
Input Parameters
入力パラメタ
o Wallet Identifier and/or Passphrase
o 財布識別子、そして/または、パスフレーズ
Hans, et al. Informational [Page 92] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[92ページ]のRFC3867支払いAPI
XML definition:
XML定義:
<!ELEMENT InquirePendingPayment EMPTY >
<!ATTLIST InquirePendingPayment
WalletId CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!の要素のInquirePendingPaymentの空の><!ATTLIST InquirePendingPayment WalletId CDATA#は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
o Party's Payment Identifier
o パーティの支払い識別子
XML definition:
XML定義:
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<!要素InquirePendingPaymentResponse(PaymentId*) >。
<!ELEMENT PaymentId EMPTY >
<!ATTLIST PaymentId
PayId CDATA #REQUIRED >
<!の要素のPaymentIdの空の><!ATTLIST PaymentId PayId CDATA#は>を必要としました。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.5. Payment Related Inquiry API Calls
4.5. 支払いは問い合せAPI呼び出しを関係づけました。
4.5.1. Check Payment Receipt
4.5.1. 支払い領収書をチェックしてください。
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
この機能は、Consumerによって使用されて、Packaged Content Elementsから成るかもしれないIOTP支払い領収書の一貫性、正当性、および保全をチェックするのにPayment Handlerによって使用されるかもしれません。
o from the IOTP Payment Receipt Component - provided by the Payment
Handler's "Inquire Process State" API call shortly before payment
completion,
o IOTP Payment Receipt Component--Payment Handlerの「プロセス状態について問い合わせてください」APIで提供するのから、支払い完成のすぐ前に電話をしてください。
o from Payment Scheme Components being exchanged during the actual
payment, or
o または実際の支払いの間に交換されるPayment Scheme Componentsから。
o being returned by the Consumer's "Inquire Process State" API call
shortly before payment completion
o Consumerの「プロセス状態について問い合わせてください」API呼び出しで、支払い完成のすぐ前に返します。
The IOTP Application Core has to check the PayReceiptNameRefs attribute of the IOTP Payment Receipt Component and to supply exactly the Packaged Content Elements being referred to.
IOTP Application CoreはIOTP Payment Receipt ComponentのPayReceiptNameRefs属性をチェックして、ちょうど言及されるPackaged Content Elementsを供給しなければなりません。
Failed verification is returns a business error.
失敗した検証はリターンaビジネスの誤りです。
Hans, et al. Informational [Page 93] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[93ページ]のRFC3867支払いAPI
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.
このPayment APIが、どんな支払い領収書も[IOTP]に関して要素の部分集合を当てにすると仮定することに注意してください。 その上、Packaged Content ElementはそれらのName属性で区別可能でなければなりません。
Input Parameters
入力パラメタ
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase o All Packaged Content Elements in the payment receipt
o 支払い領収書によるパーティのPayment Identifier o Wallet Identifier、そして/または、Pass Phrase o All Packaged Content Elements
XML definition:
XML定義:
<!ELEMENT CheckPaymentReceipt (PackagedContent*) >
<!ATTLIST CheckPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!要素CheckPaymentReceipt(PackagedContent*)><!ATTLIST CheckPaymentReceipt PayId CDATAの#必要なWalletID CDATA#、は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
XML definition:
XML定義:
<!ELEMENT CheckPaymentReceiptResponse EMPTY > <!ATTLIST CheckPaymentReceiptResponse >
<!要素CheckPaymentReceiptResponseは><!ATTLIST CheckPaymentReceiptResponse>を空にします。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.5.2. Expand Payment Receipt
4.5.2. 支払い領収書を広げてください。
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支払い領収書も広くします。 最初に、何か誤りを含む支払い領収書の質問があれば、「チェックPayment Receipt」は使用されるべきです。
The same conventions apply to the input parameter as for "Check Payment Receipt" (cf. Section 4.5.1).
同じコンベンションは「チェック支払い領収書」のように入力パラメタに適用されます。(Cf。 セクション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 支払い領収書を造るパーティのPayment Identifier o Wallet Identifier、そして/または、Pass Phrase o All Packaged Content Elements
Hans, et al. Informational [Page 94] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[94ページ]のRFC3867支払いAPI
XML definition:
XML定義:
<!ELEMENT ExpandPaymentReceipt (PackagedContent*) >
<!ATTLIST ExpandPaymentReceipt
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!要素ExpandPaymentReceipt(PackagedContent*)><!ATTLIST ExpandPaymentReceipt PayId CDATAの#必要なWalletID CDATA#、は、パスフレーズCDATA#が>を含意したのを含意しました。
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 ブランドIdentifier oプロトコル特定のBrand Identifier o Payment Instrument Identifier o Currency CodeとCurrency Code Type o Payment Amount o Payment Direction o Time Stamp--領収書oプロトコルIdentifier oプロトコルの特定のTransaction Identifierの発行--これは支払いo Consumer記述を特定する内部の参照番号、Payment Handler記述であり、言語注釈oスタイルシートネットLocation oはPayment Property Listです。 他の出力パラメタのいずれでもカバーされていない支払いに関する追加情報を含むタイプ/値/記述三重のリスト。 不動産の表示は、言語が注釈であると考えなければなりません。
The Style Sheet Net Location refers to a Style Sheet (e.g., [XSLT]) that contains presentation information about the reported XML encoded data.
スタイルシートネットLocationは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 Amount CDATA#IMPLIED CurrCodeType NMTOKEN#IMPLIED CurrCode CDATA#IMPLIED PayDirection(借り方| クレジット)#IMPLIED TimeStamp CDATA#IMPLIED ProtocolId CDATA#IMPLIED ProtocolBrandId CDATA#IMPLIED ProtocolTransId CDATA#IMPLIED xml: lang NMTOKEN#IMPLIED ConsumerDesc CDATA#IMPLIED
Hans, et al. Informational [Page 95] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[95ページ]のRFC3867支払いAPI
PaymentHandlerDesc CDATA #IMPLIED
StyleSheetNetLocn CDATA #IMPLIED>
PaymentHandlerDesc CDATA#は、StyleSheetNetLocn CDATA#が>を含意したのを含意しました。
<!ELEMENT PaymentProperty EMPTY >
<!ATTLIST PaymentProperty
PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED >
空の<!の必要なPropertyValue CDATA#必要なPropertyDesc CDATA要素PaymentProperty><!ATTLIST PaymentProperty PropertyType NMTOKEN##、は>を必要としました。
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.
Existing Payment Softwareは供給されたIOTP Payment Receiptからできるだけ多くの属性を返すはずです。 支払い補足は支払いの特性のために属性値を定義します。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.5.3. Inquire Process State
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関数は支払い領収書を形成する現在の支払い状態と任意に一層のPackaged Content Elementsを返します。 Payment Handlerによって呼ばれて、データがIOTP Payment Receipt ComponentのPackaged Contentでの包含のために意図していて、IOTP Payment Bridgeは応じるかもしれません。 Consumerが支払い完成のすぐ前にこの機能を呼ぶとき、それは支払い領収書のさらなる項目で応じるかもしれません。 そのような項目はチップカードによって作成されるかもしれません。
Input Parameters
入力パラメタ
o Party's Payment Identifier o Wallet Identifier and/or Pass Phrase
o パーティのPayment Identifier oのWallet Identifier、そして/または、Pass Phrase
XML definition:
XML定義:
<!ELEMENT InquireProcessState EMPTY >
<!ATTLIST InquireProcessState
PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
空の<!の<!ATTLIST InquireProcessState PayId CDATA#必要なWalletID CDATA要素InquireProcessState>#、は、パスフレーズCDATA#が>を含意したのを含意しました。
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 現在のProcess州、Percent Complete o Completion Code o Status記述、およびPackaged Content Elementsへの支払い領収書を造る言語注釈o Payment Receipt Name References(Cf。 セクション4.5 .1), それらが今までのところ作成されていない場合(消費者のシェア)
Hans, et al. Informational [Page 96] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[96ページ]のRFC3867支払いAPI
o Any Packaged Content Element being available that form the
payment receipt
o 支払い領収書を形成するどんな利用可能なPackaged Content Element
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は支払い領収書配送にリンク能力を提供します。 支払い領収書のパッケージされた中身に全体の支払い特定のデータをカプセル化することの代わりに、他のPayment Scheme ComponentsのPackaged Contentは言及されるかもしれません。
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#IMPLIED>に失敗します。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.5.4. Start Payment Inquiry
4.5.4. 支払い問い合せを始めてください。
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関数はどんな追加支払金体系でもConsumerが支払処理問い合せ処理を開始したのでPayment Handlerによって必要とされる特定のデータを反応させます。 たぶん、IOTP Payment Bridge(または、対応するExisting Payment Software)は、支払いが「スタート支払い消費者」APIファンクションコールが提供された項目を関係づけたことを決定しなければなりません。
Input Parameters
入力パラメタ
o Consumer Payment Identifier o Wallet Identifier and/or Pass Phrase
o 消費者Payment Identifier oのWallet Identifier、そして/または、Pass Phrase
Hans, et al. Informational [Page 97] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[97ページ]のRFC3867支払いAPI
XML definition:
XML定義:
<!ELEMENT StartPaymentInquiry EMPTY >
<!ATTLIST StartPaymentInquiry
ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
空の<!の<!ATTLIST StartPaymentInquiry ConsumerPayId CDATA#必要なWalletID CDATA要素StartPaymentInquiry>#、は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
o (Payment Scheme) Packaged Content - intended for insertion in
the Payment Scheme Component of the Inquiry Request Block
o (支払い体系) パッケージされたContent--Inquiry Request BlockのPayment Scheme Componentへの挿入のために、意図します。
XML definition:
XML定義:
<!ELEMENT StartPaymentInquiryResponse
(PaySchemePackagedContent*) >
<!要素StartPaymentInquiryResponse(PaySchemePackagedContent*) >。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
4.5.5. Inquire Payment Status
4.5.5. 支払い状態について問い合わせてください。
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.
Payment Handlerは、ConsumerのためのこのAPI関数を開始している問い合せ処理と呼びます。 それは支払いの体系の特定のデータの任意の包含で「プロセス状態について問い合わせてください」という前のAPI関数と異なっています。 応答は支払処理に関する詳細をカプセル化するかもしれません。
Input Parameters
入力パラメタ
o Payment Handler Payment Identifier
o Wallet Identifier and/or Pass Phrase
o (Payment Scheme) Packaged Content - copied from the Inquiry
Request Block's Payment Scheme Component
o 支払いHandler Payment Identifier o Wallet Identifier、そして/または、Pass Phrase o(支払いScheme)はContentをパッケージしました--Inquiry Request BlockのPayment Scheme Componentから、コピーされます。
XML definition:
XML定義:
<!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) >
<!ATTLIST InquirePaymentStatus
PaymentHandlerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED >
<!要素InquirePaymentStatus(PaySchemePackagedContent*)><!ATTLIST InquirePaymentStatus PaymentHandlerPayId CDATAの#必要なWalletID CDATA#、は、パスフレーズCDATA#が>を含意したのを含意しました。
Output Parameters
出力パラメタ
o Current Process State o Completion Code
o 現在のProcess州o Completion Code
Hans, et al. Informational [Page 98] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[98ページ]のRFC3867支払いAPI
o Status Description and its language annotation
o (Payment Scheme) Packaged Content - intended for insertion in
the Payment Scheme Component of the Inquiry Response Block
o 状態記述とその言語注釈o(支払いScheme)はContentをパッケージしました--Inquiry Response BlockのPayment Scheme Componentへの挿入のために、意図します。
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はError Codesを導入します。
4.6. Other API Calls
4.6. 他のAPIは呼びます。
4.6.1. Manage Payment Software
4.6.1. 支払いソフトウェアを管理してください。
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 Payment Bridgeに通知します。 実際の処理はIOTP Payment Bridge次第です。
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 Payment Bridge(そして、対応するExisting Payment Software)を動かすのに使用されるかもしれません。
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 Identifier oにプロトコルIdentifier o Anyアクション・コードと商標を付けてください: o 新しく、新しい支払い方法/器具o Update(変化支払い方法のもの/器具のデータo Delete)が支払い方法/器具o Wallet Identifierを削除して、Pass Phrase o(ブランド)がContent--さらなる支払いブランド記述o(プロトコルを支払います)のパッケージされたContent--さらなる支払いプロトコル記述をパッケージしたと言い足してください。
Hans, et al. Informational [Page 99] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[99ページ]のRFC3867支払いAPI
o (Protocol Amount) Packaged Content - further payment protocol
description
o (プロトコル量) パッケージされたContent--さらなる支払いプロトコル記述
If the Action attribute is set, the Brand and Protocol Identifier have to also be set. The IOTP Payment Bridge has to provide the required user dialogs and selection mechanisms. E.g., updates and deletions may require the selection of the payment instrument. A new wallet might be silently generated on the supplement of a new Wallet Identifier or after an additional end user acknowledge. The IOTP Application Core should not provide any pass phrases for new wallets. Instead, the IOTP Payment Bridge has to request and verify them, which may return their value to the IOTP Application Core in plain text. In addition, the IOTP Payment Bridge returns the supported authentication algorithms when a new brand and protocol pair has been registered.
また、Action属性が設定されるなら、BrandとプロトコルIdentifierは用意ができなければなりません。 IOTP Payment Bridgeは必要なユーザ対話と選択メカニズムを提供しなければなりません。例えば、アップデートと削除は支払い器具の選択を必要とするかもしれません。 新しい財布は新しいWallet Identifierか追加エンドユーザの後に補足のときに静かに生成されるかもしれません。承認します。 IOTP Application Coreは新しい財布のためのどんなパス句も提供するはずがありません。 代わりに、IOTP Payment Bridgeはそれらを要求して、確かめなければなりません(それらの値をプレーンテキストのIOTP Application Coreに返すかもしれません)。 新しいブランドとプロトコル組を登録してあるとき、さらに、IOTP Payment Bridgeはサポートしている認証アルゴリズムを返します。
If the "Action" attribute is omitted, the IOTP Payment Bridge which is responsible for the Existing Payment Software pops up in a general interactive mode.
「動作」属性が省略されるなら、Existing Payment Softwareに責任があるIOTP Payment Bridgeは一般的な会話型に急に現れます。
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 >
<!要素ManagePaymentSoftware(BrandPackagedContent*、ProtocolAmountPackagedContent*、PayProtocolPackagedContent*)><!ATTLIST ManagePaymentSoftware BrandId CDATA#が、ProtocolId CDATA#が動作を含意したのを含意した、(新しさ、| |アップデートしてください、削除、)、#暗示しているWalletID CDATA#は、パスフレーズCDATA#が>を含意したのを含意しました。
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 Update)変えられた財布の構成o Delete--財布oのWallet Identifier、そして/または、Pass Phraseを取り外します。
The IOTP Payment Bridge does not return any information about the set of registered payment instruments because these data items are dynamically inferred during the brand selection process at the beginning of each IOTP transaction. However, the IOTP Application Core has to be notified about new wallets and should be notified about updated and removed wallets (identifier). Alternatively,
これらのデータ項目がそれぞれのIOTPトランザクションの始めにブランド選択プロセスの間、ダイナミックに推論されるので、IOTP Payment Bridgeは登録された支払い器具のセットの少しの情報も返しません。 しかしながら、IOTP Application Coreは新しい財布に関して通知されなければならなくて、アップデートされて取り外された財布(識別子)に関して通知されるべきです。 代わりに
Hans, et al. Informational [Page 100] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[100ページ]のRFC3867支払いAPI
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 Application Coreの処理をしません。 すぐに複数の追加のIOTP Application Coreに報告を持ちかえることができないので、IOTP Payment Bridgeは高々1個の財布の追加をサポートするだけであるはずです。
XML definition:
XML定義:
<!ELEMENT ManagePaymentSoftwareResponse EMPTY >
<!ATTLIST ManagePaymentSoftwareResponse
Action (New |
Update |
Delete) #IMPLIED
WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED
AuthNames NMTOKENS #REQUIRED >
<!要素ManagePaymentSoftwareResponseが><!ATTLIST ManagePaymentSoftwareResponse動作を空にする、(新しさ、| |アップデートしてください、削除、)、#暗示しているWalletID CDATA#は、パスフレーズCDATA#が、AuthNames NMTOKENS#が>を必要とするのを含意したのを含意しました。
Tables 4 and 5 explain the attributes and elements; Table 3 introduces the Error Codes.
テーブル4と5で、属性と要素がわかります。 テーブル3はError Codesを導入します。
5. Call Back Function
5. 機能に電話し直してください。
This API function, called by the IOTP Payment Bridge, is used to provide information for Consumer or Payment Handler notification about the progress of the payment transaction.
IOTP Payment Bridgeによって呼ばれたこのAPI関数は、支払処理の進歩に関するConsumerのための情報かPayment Handler通知を提供するのに使用されます。
Its use is illustrated in the diagram below.
使用は以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP Application ----calls----
| Core | |
display | | v
to <---------- Call Back <--calls--- Payment
user | | Software
----------------
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*アプリケーション----呼び出し---- | コア| | ディスプレイ| | <へのv---------- 呼び出し後部<--呼び出し--- 支払いユーザ| | ソフトウェア---------------- *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
Call Back機能の参照は入力パラメタとして「スタート支払いX」と「履歴書支払いX」API関数に合格されます。 その後、状態が変化するか、または進歩が、報告される必要があるときはいつも、この機能は呼ばれるかもしれません。
Hans, et al. Informational [Page 101] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[101ページ]のRFC3867支払い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パーティのPayment Identifier o Process州、Percent Complete o Completion Code o Status記述、およびその言語注釈に関するソフトウェア識別子(呼び出しの進歩の情報を提供するテキスト)。 それを表示するか、または例えば、Consumerは入手するはずです。
Examples of Status Description could be:
Status記述に関する例は以下の通りであるかもしれません。
o "Paying 12.30 USD to XYZ Inc" o "Payment completed" o "Payment aborted"
o 「支払いは中止になった」「XYZ Incへの賃金12.30U.S.ドル」○ 「終了する支払い」○
The valid languages are announced in the Call Back Language List attribute in "Start Payment X" and "Resume Payment X" API function calls.
有効な言語は「スタート支払いX」におけるCall Back Language List属性で発表されます、そして、「支払いXを再開してください。」と、API関数は呼びます。
XML definition:
XML定義:
<!ELEMENT CallBack EMPTY >
<!ATTLIST CallBack
ContentSoftwareID CDATA #IMPLIED
PayId CDATA #REQUIRED
ProcessState (NotYetStarted |
InProgress |
Suspended |
CompletedOk |
Failed |
ProcessError) #IMPLIED
PercentComplete CDATA #IMPLIED
CompletionCode NMTOKEN #IMPLIED
xml:lang NMTOKEN #IMPLIED
StatusDesc CDATA #IMPLIED >
<!ELEMENT CallBack EMPTY><!ATTLIST CallBack 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はError Codesを導入します。
Hans, et al. Informational [Page 102] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[102ページ]のRFC3867支払いAPI
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").
いくつかの支払い体系が、Consumerがいつでも支払いを中止できるかもしれないのをサポートするか、または必要とするかもしれません。 次の呼び出しのときに解約請求を返すことによってこれを容易にするのにCall Back機能を使用できます(Business Error CodeとCompletion Code"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.
逆もまた同様に、Payment HandlerのApplication Coreは、IOTP Paymentブリッジスのために速い閉鎖のどんな例外的な必要性にも合図するのに同様のメカニズムを使用するかもしれません。 これらのIOTP Paymentブリッジスはすべての未定の支払処理を終えるか、または中止するための適切なステップに着手するかもしれません。
Note that the "Change Process State" API function provides the second mechanism for such kind of notification. Therefore, the IOTP Payment Bridge or Existing Payment Software may ignore the details of the "Call Back" response.
「変化プロセス状態」API機能が2番目のメカニズムをちょっとそのような通知に提供することに注意してください。 したがって、IOTP Payment BridgeかExisting Payment Softwareが「呼び出し後部」応答の詳細を無視するかもしれません。
6. Security Consideration
6. 警備上の配慮
The IOTP Payment APIs only supports security using pass phrase to access to payment Wallet. These can be protected over TLS, which provides stronger security at the transport layer, but implementations are out the scope of this document.
IOTP Payment APIは、Walletに支払いにアクセスするのにパス句を使用することでセキュリティをサポートするだけです。 TLSの上にこれらを保護できますが、実装がこのドキュメントの範囲にあります。TLSはトランスポート層で、より強いセキュリティを提供します。
See also security consideration section of [IOTP].
また、[IOTP]の警備上の配慮部を見てください。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[IOTP] Burdett, D., "Internet Open Trading Protocol - IOTP
version 1.0", RFC 2801, April 2000.
[IOTP]バーデット、D.、「インターネットオープンTradingプロトコル--、IOTP、バージョン1インチ、RFC2801、2000インチ年4月。
[ISO4217] ISO 4217: Codes for the Representation of Currencies.
Available from ANSI or ISO.
[ISO4217]ISO4217: 通貨の表現のためのコード。 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、「Uniform Resource Locator(URL)」、RFC1738、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]世界標準時は調整されました。 (グリニッジ標準時に)グリニッジ標準時に比例して時間を絶対に定義するメソッド。 通常、フォームについて: + n」はグリニッジ標準時から数時間を定義します。「「CCYY-MM- DDTHH:MM:SS.sssZ+n」、どこ、」 ISO DIS8601を見てくださいか。
Hans, et al. Informational [Page 103] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[103ページ]のRFC3867支払いAPI
[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-ナノ秒] XML推薦における名前空間。 T。 ロバの鳴き声、D.オランダ人、A.俗人。 Janaury1999 http://www.w3.org/TR/REC-xml- 名
[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 を見ます。
7.2. Informative References
7.2. 有益な参照
[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を開きます。 ISBN0-07- 135501-4。
[SET] SET Secure Electronic Transaction(TM) , Version 1.0, May
31, 1997
Book 1: Business Description
Book 2: Programmer's Guide
Book 3: Formal Protocol Definition
[設定します] 安全な電子取引(TM)、バージョン1.0、第1 1997年5月31日巻を設定してください: 第2ビジネス記述巻: 第3プログラマーズガイド巻: 正式なプロトコル定義
[SET/IOTP] Kawatsura, Y., "Secure Electronic Transaction (SET)
Supplement for the v1.0 Internet Open Trading Protocol
(IOTP)", RFC 3538, June 2003.
[SET/IOTP]Kawatsura、Y.、「安全なElectronic Transaction(SET)はv1.0インターネットオープンTradingプロトコル(IOTP)のために補う」RFC3538、2003年6月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Hans, et al. Informational [Page 104] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[104ページ]のRFC3867支払いAPI
Acknowledgement
承認
The contributions of Werner Hans of Atos Origin are gratefully acknowledged.
アトーOriginのヴェルナー・ハンスの貢献は感謝して承諾されます。
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
幸区川崎市神奈川、Yoshiaki Kawatsura日立890日本鹿島田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
Masaaki浩哉TechnoinfoサービスInc.333-2-718Uchikoshi-machi Hachioji市日本東京192-0911
EMail: hiroya@st.rim.or.jp
メール: hiroya@st.rim.or.jp
Hans, et al. Informational [Page 105] RFC 3867 Payment API for IOTP November 2004
ハンス、他 IOTP2004年11月のための情報[105ページ]のRFC3867支払いAPI
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hans, et al. Informational [Page 106]
ハンス、他 情報[106ページ]
一覧
スポンサーリンク
