TRADE Working Group                                          Werner Hans
INTERNET-DRAFT                                    Hans-Bernhard.Beykirch
                                                                     SIZ
                                                          Masaaki Hiroya
                                                      Yoshiaki Kawatsura
                                                                 Hitachi
Expires: September 2000 March 2001                                       September 2000

 Architecture and

       Payment API for v1.0 Internet Open Trading Protocol (IOTP)
 ------------ ---
        ------- --- --- ---- -------- ---- ------- -------- ------
                <draft-ietf-trade-iotp-v1.0-papi-00.txt>
                draft-ietf-trade-iotp-v1.0-papi-01.txt

Status of this Memo

   This document is intended to become an Internet-Draft Informational RFC and will be
   in full conformance with all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-
   Drafts. Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited. Please send comments to
   the TRADE  working group at <ietf-trade@lists.elistx.com >, which may
   be joined by sending a message with subject "subscribe" to <ietf-
   trade-request@lists.elistx.com>.

   Discussions of the TRADE working group are archived at
   http://www.elistx.com/archives/ietf-trade.

Abstract

   The Internet Open Trading Architecture proposes an abstract layered model of the
   IOTP based trading environment. Its description sketches the
   essential functional and Protocol provides a data modules and their interfaces at each exchange format
   for trading role's installation. purposes while integrating existing pure payment
   protocols seamlessly. This abstract view deals as a guideline
   for motivates the modules' mapping to actual software modules.

   The second part multiple layered system
   architecture which consists of this at least some generic IOTP application
   core and multiple specific payment modules.

   This document focuses on the Payment API that
   improves addresses the essential common interface that relates to between the IOTP
   application core and the payment
   transactions. Such modules, enabling the
   interoperability between these kinds of modules. Furthermore, such an
   interface exists provides the foundations for a plug-in- mechanism in actual
   implementations of IOTP application cores.

   Such interfaces exist at the Consumers', the Merchants' and the
   Payment Handlers' installations connecting the actual IOTP application core
   and the payment software components/legacy systems systems.

Intended Readership

   Software and the generic IOTP aware front
   end application. hardware developers, development analysts, and users of
   payment protocols.

Copyright

   Copyright (C) The Internet Society 2000.

Table of Contents

      Status of this Memo........................................1
      Abstract...................................................1
      Intended Readership........................................2
      Copyright..................................................2

      Table of Contents..........................................3
      1. Introduction............................................6 Introduction............................................5
      1.1  Intended Readership...................................8
      GENERAL TRADING ARCHITECTURE...............................8  General payment phases................................6
      1.2  Assumptions...........................................7
      2. Trading Architecture....................................8
      2.1 Overview...............................................8
      2.1.1 Layers and Components................................9
      2.1.1.1 Consumer Access - End System Layer................10
      2.1.1.2 Network Layer.....................................11
      2.1.1.3 Access Layer......................................11
      2.1.1.4 Refinement Layer - Integration with IOTP..........11
      2.1.1.5...................................................12
      2.1.1.6 Data Layer........................................12
      2.1.2 Implementation Variants.............................12
      2.1.3 Component Distribution..............................12
      2.2 Requirements and Commitments..........................12
      2.2.1 Basic Requirements..................................13
      2.2.1.1 Electronic Commerce Provider (Server).............13
      2.2.2  Security Requirements and Commitments..............13
      2.2.2.1  Overview about the Security Levels...............13
      2.2.3  Security Mechanism.................................14
      2.2.3.1  Transmission Security............................14
      2.2.3.2 Authentication....................................15
      2.2.3.3 Document Security.................................15
      2.2.3.4 Authorization.....................................16
      2.2.4  Protection against Attacks.........................16
      2.2.4.1  Consumer System..................................17
      2.2.4.2  Transmission Line................................17
      2.2.4.3  Provider's Computing Center......................18
      3.  Layers and Functional Components......................18
      3.1  End System Layer.....................................19
      3.1.1 Presentation Software...............................20
      3.1.2  Document Formatting................................20
      3.1.3  Document Security..................................21
      3.1.4  Transport Coupling.................................21
      3.1.5  Maintenance........................................21
      3.2  Network Layer........................................21
      3.3  Access Layer.........................................22
      3.3.1  Transport Coupling.................................23
      3.3.1.1  Network Protocols................................23
      3.3.1.2  Transmission Security............................24
      3.3.1.3  Access Protection................................24
      3.3.1.4  Presentation Control Monitor.....................24
      3.3.1.5  Parameterized Subsystem Distribution.............25
      3.3.1.6  Frame Dialogs....................................25
      3.3.2  Presentation Services..............................26
      3.3.2.1  Native presentation (standard)...................27
      3.3.2.2  Optimization.....................................27
      3.3.2.3  Transport Information............................27
      3.3.2.4  Native Programs..................................28
      3.4  Refinement Layer.....................................28
      3.4.1  Format Conversion..................................29
      3.4.2  Document Security..................................30
      3.4.3  Format Optimization................................30
      4.  Recapitulation........................................30
      4.1  Example Justification................................33
      5.  Progress Example......................................35
      6.  TCP/IP - WWW, Java Implementation Variant.............40
      6.1  Consumer's Sphere....................................42
      6.2  Provider's sphere....................................43
      IOTP Payment API..........................................43
      7.  Payment API...........................................43
      7.1  Introduction.........................................44
      7.2  Assumptions..........................................45
      8.  Message Flows.........................................50
      8.1 Flow..........................................13
      2.1  Authentication Documentation Exchange................54
      8.2 Exchange................16
      2.2  Brand Compilation....................................55
      8.3 Compilation....................................18
      2.3  Brand Selection......................................58
      8.4 Selection......................................21
      2.4  Successful Payment...................................24
      2.5  Payment ..................................61
      8.5  Payment Inquiry......................................65
      8.6 Inquiry......................................28
      2.6  Abnormal Transaction Processing......................67
      8.6.1 Processing......................30
      2.6.1  Failures and Cancellations.........................67
      8.6.2  Resumption.........................................69
      8.7 Cancellations.........................30
      2.6.2  Resumption.........................................32
      2.7  IOTP Wallet Initialization...........................69
      8.8 Initialization...........................33
      2.8  Payment Software Management..........................70
      9.  Mutuality.............................................70
      9.1 Management..........................33
      3.  Mutuality.............................................34
      3.1  Error Codes..........................................73
      9.2 Codes..........................................37
      3.2  Attributes and Elements..............................82
      10. Elements..............................47
      3.3 Process States........................................59
      3.3.1 Merchant............................................59
      3.3.2 Consumer............................................61
      3.3.3 Payment Handler.....................................63
      4.  Payment API Calls....................................94
      10.1 Calls.....................................64
      4.1  Brand Compilation Related API Calls.................94
      10.1.1 Calls..................64
      4.1.1  Find Accepted Payment Brand.......................94
      10.1.2 Brand........................64
      4.1.2  Find Accepted Payment Protocol....................95
      10.1.3 Protocol.....................65
      4.1.3  Get Payment Initialization Data...................97
      10.1.4 Data....................67
      4.1.4  Inquire Authentication Challenge..................99
      10.1.5  Authenticate.....................................100
      10.1.6 Challenge...................69
      4.1.5  Authenticate.......................................71
      4.1.6  Check Authentication Response....................101
      10.1.7  Cancel Payment...................................102
      10.2 Response......................71
      4.2  Brand Selection Related API Calls..................103
      10.2.1 Calls....................73
      4.2.1  Find Payment Instrument".........................103
      10.2.2  Find Payment Protocol............................105
      10.2.3 Instrument............................73
      4.2.2  Check Payment Possibility........................107
      10.2.4  Quit Payment Instrument..........................109
      10.3 Possibility..........................75
      4.3  Payment Transaction Related API calls..............110
      10.3.1 calls................77
      4.3.1  Start Payment Consumer...........................110
      10.3.2 Consumer.............................77
      4.3.2  Start Payment Payment Handler....................112
      10.3.3 Handler......................79
      4.3.3  Resume Payment Consumer..........................115
      10.3.4 Consumer............................81
      4.3.4  Resume Payment Payment Handler...................116
      10.3.5 Handler.....................82
      4.3.5  Continue Process ................................117
      10.4 ..................................83
      4.3.6  Change Process State...............................84
      4.4  General Inquiry API Calls..........................120
      10.4.1  Inquire Calls............................86
      4.4.1  Remove Payment Log..............................120
      10.4.3 Log.................................86
      4.4.2  Payment Instrument Inquiry.......................124
      10.4.4 Inquiry.........................87
      4.4.3  Inquire Pending Payment..........................126
      10.5 Payment............................89
      4.5  Payment Related Inquiry API Calls..................127
      10.5.1 Calls....................89
      4.5.1  Check Payment Receipt............................127
      10.5.2 Receipt..............................90
      4.5.2  Expand Payment Receipt...........................128
      10.5.3 Receipt.............................91
      4.5.3  Inquire Process State............................129
      10.5.4 State..............................92
      4.5.4  Start Payment Inquiry............................131
      10.5.5 Inquiry..............................94
      4.5.5  Inquire Payment Status...........................131
      11.  Called Functions....................................134
      11.1 Status.............................94
      4.6  Other API Calls......................................95
      4.6.1  Manage Payment Software............................95
      5. Call Back Function.................................135
      11.2  Work and Payment Log Database Function.............136
      12. Function.....................................97
      6. Security Consideration...............................141 Consideration.................................99

      Full Copyright Statement.................................141
      References...............................................141 Statement.................................100
      References...............................................100
      Author's Address.........................................142 Address.........................................101
      Expiration and File Name.................................143 Name.................................102

1. Introduction

   Common network technologies base 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.

   The Internet Open Trading Protocol (IOTP) [RFC XXXX] is such an
   Internet technology that specifies a generic protocol for Internet
   trading. IOTP founds upon a client server model. It defines six
   different trading roles (Consumer, Merchant, Payment Handler,
   Delivery Handler, Merchant Customer Care Provider, and Payment
   Instrument Customer Care Provider) and nine trading transaction types
   (Deposit, Purchase, Refund, Withdrawal, Value Exchange, Inquiry,
   Payment Instrument Customer Care, Authentication, and Ping). But it
   does not depend on any payment method, e.g., SET, CyberCash/Coin,
   Mondex, or GeldKarte.

   The general IOTP objectives are to o  provide the basic trading
   transactions, o  be an interoperable solution, o  be payment system
   independent, o  be extensible and flexible, o  meet immediate
   business needs, o  be an application level protocol, o  be transport
   level independent, and o  be client / server architecture
   independent.

   Each trading role uses an IOTP aware application. The client, i.e.,
   Consumer, initiates each type of transaction request while the
   server, i.e., other trading roles, responds to the Consumers'
   requests.

   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 defines has been limited to the common external (Internet)
   interface between these systems. Initially, this consideration leads
   to over the two-level layered view Internet. However, some of the IOTP software these internal
   interfaces might be also standardized for each role,
   consisting better integration of the generic IOTP frontend part providing IOTP based
   gateway services and the trading roles' specific backend systems
   implementing the actual trading transaction types' functionality.
   These software
   aware components communicate with each other of the existing infrastructure and its cost
   effective reuse.

   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 have
   been even provided by different software suppliers.

   As IOTP extends payment schemes to a trading protocol, insist on the IOTP
   application glues different payment software components. However, reuse of
   special in-house solutions for some subtasks of the
   Consumers' requirements can be lowered to 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.

   More important, Consumers demand modularization and clear internal
   interfaces: Their IOTP application aims at the sole support of multiple
   payment methods. Therefore, 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.

   Initially, this consideration leads to the two-level layered view of
   the IOTP software for each role, consisting of

   o some generic IOTP system component, the so-called IOTP application splits into
   three main component types:
   core - providing IOTP based gateway services and generic business
   logic and

   o the trading roles' specific backend systems implementing the
   specific trading transaction types' functionality.

   In order to isolate the changes on the infrastructure, the IOTP
   trading application has been three-layered:

   o the IOTP Application Core processes the generic parts of the IOTP
   transaction and connects holds the connection to the Internet,

   o the Existing Legacy System resp. or Existing Payment Software which
   processes the actual transaction type resp. type, and particular payment
   transaction, and

   o the IOTP Middleware resp. or IOTP Payment Bridge connects which glues the other
   two possibly incompatible components. It extends brokers between the specific
   interface of the Existing Legacy System with an
   interface compatible with and the one offered by standardized
   interfaces of the IOTP Application Core. The latter maps the Payment API calls

   As IOTP extends payment schemes to the a trading scheme, primarily, this
   document focuses on payment software's
   specific calls.

   Actually, modules, i.e. the trading architecture splits into five logical layers
   that reflect interface between the aspects of external Internet and user interfaces,
   internal generic
   IOTP message processing, backend preparation of the
   transaction's content, their processing at Payment Bridge and the actual application
   layer, and the transaction data management.

   The trading architecture being motivated and introduced in Chapters 2
   to 6 elaborates the essential functional and data modules, maps them
   to IOTP Application Core. It provides a
   standard method for exchanging payment protocol messages between the five layers, and sketches their (internal) interfaces.
   Generally, some of these interfaces are specified
   parties involved in public (product)
   documents while others are confidential developer's only interfaces.
   However, the Trading Architecture defines the first step towards an
   actual implementation of an IOTP aware application.

   The typical Payment Handlers, i.e., financial institutes a payment. But, it does not specify any interface
   for order or near-
   bank organizations, require an IOTP aware application that easily
   fits into their existing financial infrastructure. The delivery processing.

   Such a Payment
   Handler may even insist on the reuse of special in-house solutions Application Programmers Interface (API) must suit for some subtasks
   a broad range of the IOTP aware application, e.g., reflecting
   their cryptography modules, gateway interfaces, payment methods: (1) software based like Credit Card
   SET or physical
   environment. Therefore, their IOTP aware application really needs
   both well defined external CyberCoin, (2) chip card based like Mondex or GeldKarte, and internal interfaces.

   However, the significance
   (3) mimicries of such an architecture depends on the
   product's target group. Generally, Payment Handlers have stronger
   products requirements typical and traditional payment methods like money
   transfer, direct debit, deposit, withdrawal, money exchange and value
   points. It should support both payments with respect to modularization explicit consumer
   acknowledge and clear
   internal interfaces than Consumers. But even automatic repeated payments, which have been consumer
   approved in advance.

   The following discussion focuses on the Consumer's point of view and
   uses the associated terminology. When switching to Merchants' or
   Delivery Handlers' IOTP
   application aims at aware applications, the support of multiple payment methods.
   Particularly, Consumers prefer related
   components should be implicitly renamed by Existing Legacy Systems to
   the flexible use of different seamless
   integrating IOTP Middleware.

   The next two sub-sections describe the general payment methods within one trading application with
   nearly identical behavior scenario and user interfaces.

   The second part of
   several assumptions about the document (Chapters 7 to 11) refines one
   specific internal interface coarsely sketched software components.

   Chapter 2 illustrates the payment transaction progress and message
   flow of different kinds of transaction behavior. Chapters 3 to an actual Application Programming
   Interface (API), i.e., Payment API, that bases on 4
   provide the functional
   specification details of Baseline IOTP [RFC XXXX]. This the API aims at functions and Chapter 5 elaborates the
   realization of a plug-in mechanism for
   call back interface.

1.1  General payment specific software.
   Currently, several phases

   The following table sketches the four logical steps of many payment software components from different
   suppliers exist. Due to
   schemes. The preceding agreements about the goods, payment method independence method,
   purchase amount, or delivery rules are omitted.

   Payment State  Party             Example Behavior

   Mutual         Payment Handler   Generation of IOTP, the
   IOTP application must deal with identification
   Authentication                   request, solvency request, or
   and should provide a mostly common
   interface for them. Therefore, this Payment API proposes an interface
   between Init-                        some nonce
   ialization     Consumer          Responses to the generic IOTP Application Core requests and
                                    generation of the Existing own nonce

   Authorization  Payment
   Software. Although, Handler   Generation of the highest significance authorization
                                    request (for consumer)
                  Consumer          Agreement to payment (by
                                    reservation of this API is
   recognized at the Consumer, Consumer's
                                    e-money)
                  Payment Handlers offering multiple
   transactions will also benefit, because such an API reduces the
   overhead Handler   Acceptance or rejection of integration, customization etc. the
                                    agreement (consumer's
                                    authorization response),
                                    generation of the IOTP aware
   application.

1.1  Intended Readership

   Software and hardware developers; development analysts, authorization
                                    request (for issuer/acquirer),
                                    and users of
   payment protocols.

GENERAL TRADING ARCHITECTURE

2. Trading Architecture

   The general architecture suits for a broad range processing of its response

   Capture                          Generation of applications, and
   several abstract interfaces are identified between the architecture
   components. Of course, such an architecture defines only capture
                                    request (for issuer/acquirer)
                  Consumer          Is charged
                  Payment Handler   Acceptance or rejection of the initial
   starting point for an incremental process
                                    e-money, close of refinements that ends the payment
                                    transaction

   Reversal                         On rejection (online/delayed):
                                    generation of the reversal data
                  Consumer          Receipt of the refund

   However, some payment schemes

   o limit themselves to one-sided authentication,
   o perform offline 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 actual implementation. inbound mechanism for reversals or implement a limited
   variant.

   This incremental process hides superfluous
   details very long model applies not only to payments at the typical points of
   sales but extends to refunds, deposits, withdrawals, electronic
   cheques, direct debits, and clarifies money transfers.

1.2  Assumptions

   In outline, the roles 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 components Existing Payment Software, (3) assembles its
   responses, and their
   interfaces very early.

2.1 Overview

   The Trading Architecture consists (4) returns another sequence of several layers and components
   providing specific functionality. There exist well- defined
   interfaces between the layers payment protocol
   messages that are introduced in this section.

   Implementation variants are derived from is mostly intended for transparent transmission by the
   IOTP Application Core to some IOTP aware remote party. Normally, this abstract description.
   For electronic commerce on
   process continues between the Internet, two parties until the implementation obviously
   bases on HTML, HTTP, and TCP/IP. However, mobiles and set top boxes Payment Handler's
   Payment API signals the payment termination. Exceptionally, each
   system component may introduce other techniques. signal failures.

   The relationship between the aforementioned components can is illustrated
   in the following figure. These components might be distributed over different platforms, e.g.,
   main server related to each
   other in a flexible n-to-m-manner:

   o One IOTP Application Core may manage multiple IOTP Payment
   Bridges and server stations. The combination of implementation
   variants the latter might be shared between multiple IOTP
   Application Cores.
   o Each Payment Bridge may manage multiple Existing Payment
   Software modules and component distribution leads to actual scenarios, e.g.,
   TCP/IP, WWW, the latter might be shared between multiple
   Payment Bridges.
   o Each Existing Payment Software may manage multiple payment
   schemes (e.g. SET) and Java on a server station at the merchant latter might be supported by multiple
   Existing Payment Software modules.
   o Each payment scheme may support multiple payment instruments
   (e.g. particular card) or
   financial institute. But these actual scenarios are out of methods (e.g. Visa via SET) and the scope
   of this proposal.
   latter might be shared by multiple Existing Payment Software
   Components.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
        ------------------  Trading Architecture  ---------
   IOTP client (consumer)  <--------------->  IOTP server (merchant)
   (      contains             Internet       (      containes
   IOTP Application Core)                     IOTP Application Core)
         ^                                          ^
         |                   components that may spread IOTP Payment                             | IOTP Payment
         |                   across layers    API                                   |
        V                                                 V
   Implementation variants  <------------>  Component Distribution
   tcp/ip - www, java                                  main server
   other                                            server station    API
         v                                          v
   IOTP Payment Bridge                        IOTP Payment Bridge
        ^                                           ^
        | Existing Payment APIs, e.g.,              |
        | SET, Mondex, etc.                         |
        v                                           v
   Existing Payment Software               Existing Payment Software
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 1: Relationship between Architecture, Implementation
                    Variant, and Component Distribution

2.1.1 Layers and Components

   An electronic commerce application should support different
   implementation variants. Although WWW obtains the main focus, the
   technologies may change in the future. A separation of the
   application according to current and upcoming technologies must be
   prevented. Components

   The specification of the Trading Architecture starts with Payment API considers the general
   logical partition following transaction types of the layers.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer Baseline
   IOTP [IOTP]:

   o  Web browser or standard software interacting with the user

   network layer  Baseline Purchase,
   o  tcp/ip, other

   access layer  Baseline Refund,
   o  Internet IOTP demon
   o  Internet transport information
   o  frame dialog, presentation services
   o  subsystem distribution
   o  monitor for presentation control

   refinement layer
   o  document security
   o  format conversion

   application layer
   o  electronic commerce application
   o  application monitor
   o  middleware

   data layer
   o  data access  Baseline Value Exchange,
   o  integrity
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
         Figure 2: Architecture Layers  Baseline Withdrawal, and Implementation Examples

2.1.1.1 Consumer Access - End System Layer

   The end system uses
   o  Baseline (Payment) Inquiry.

   First, the World Wide Web for presentation purposes
   supporting graphical mechanisms for interaction, animated
   graphical objects, photos, audio, authors' vision of the IOTP aware application's and video tracks. In this
   moment, these technologies are already implemented in highly
   available web browsers. These software components its
   main components' capabilities are bundled
   with newer releases of operating systems for clarified: On the consumers'
   personal computers, e.g., Microsoft Internet Explorer with
   Microsoft Windows 95/NT, they come for free (Netscape
   Navigator/Communicator), or can be licensed for a nominal license
   fee. In one hand, the future, other networks
   Payment API should be quite powerful and devices like set-top boxes flexible for Pay-TV will be the target sufficient
   connection of IOTP implementations, too.

   The Internet features an open network infrastructure between the
   consumer generic and specific components. On the service provider for electronic commerce. An
   electronic commerce application must be able to generate the
   complete transaction data, to sign it, and to ensure other hand,
   the
   transmission security. Currently, this demands can Payment API should not be
   fulfilled overloaded with nice-to-haves being
   unsupported by Existing Payment Software.

   Despite the Web-browser, solely. Instead special helper
   applications have to be installed at the consumer's side.

   Actually, strong similarities on the client-sided end system layer consists also processing of the
   last three server-sided layers (see below) but they have been
   collapsed for simplicity. For short:

   o  Operating system offered network services belong to the access
   layer.
   o  Web browsers' successful
   payments, failure resolution and inquiry capabilities spread across the access to the data
   layer.
   o  The functionality of helper applications differ
   extremely among different payment schemes. These aspects may spread across
   refinement to data layer.
   o  The IOTP wallet mainly belongs to even
   vary between different payment instrument using the refinement layer.
   o  The actual same payment software, e.g. SET wallet, inclusive its
   helper applications like chip card reader drivers belongs to
   the application/data layer.

   However,
   schemes. Eventually, the following discussion specific requirements of these layers assumes their
   location at the server side.

2.1.1.2 Network Layer

   The network layer is operated by network providers Consumers,
   Merchants and online
   service providers. Not only the network provider may offer these
   services, they can also be offered by merchants, mall providers,
   financial service providers, Payment Handlers add variance and even financial institutes.

   This layer aims at complexity.
   Therefore, it is envisioned that the abstraction from particular network
   services like TCP/IP, HTTP, or Pay-TV networks. Application data,
   i.e., IOTP message content Application Core provides
   only very basic inquiry mechanisms while complex and payment scheme
   specific data, is
   transparently passed inquiries, failure analysis, and failure resolution are
   fully deferred to the refinement layer.

2.1.1.3 Access Layer

   This layer subsumes the standard mechanisms for (Inter)net(work)
   access, i.e.,

   o  operating system offered network access services,
   o  peripherals like modem, packet filter, or firewall,
   o  partial capabilities of Web browsers and HTTP servers, e.g.,
   transmission security, visualisation, logging.

   This layer does not offer any trading services and transparently
   carries IOTP formatted data.

2.1.1.4 Refinement Layer actual Existing Payment Software - Integration with IOTP

   Standardized protocols promise strong flexibility for including
   the choice
   of application suppliers, prevent user interface.

   The IOTP Application Core processes payments transparently, i.e., it
   forwards the dependence on a particular
   one, and yield compliance and interoperability. Often, wrapped payment scheme specific messages to the
   server-located systems have quite long life cycles, despite
   associated IOTP Payment Bridge/Existing Payment Software. The
   Existing Payment Software might even use these messages for inbound
   failure resolution. It reports only the
   short development cycles of hardware and software.

   These two cycles lead final payment status to two concurrent goals. The first goal
   intends long-termed stability and security of investments. The
   second requires the accurate consideration of new developments.
   IOTP Application Core or some intermediate - might be also final -
   status on abnormal interruption.

   The IOTP Application Core represents implements the generic and payment scheme
   independent part of an IOTP
   aware trading environment that provides the IOTP specific document
   formatting transaction processing and security mechanisms. It connects to the
   transaction specific backend systems.

2.1.1.5

   The processing of provides the actual transaction data is performed by
   suitable user interface. Focusing on payment related tasks, it

   o manages the
   Existing Legacy Systems resp. Existing registered IOTP Payment Software being
   reused Bridges and provides a
   mechanism for IOTP based (Internet) trading. They may even apply their own document formatting and security mechanisms on registration - the
   application data being transparently embedded in latter is omitted by this
   document.

   o assumes that any IOTP messages.

2.1.1.6 Data Layer

   The Existing Legacy Systems provide their specific data
   management systems for Payment Bridge is a passive component, i.e.,
   it strictly awaits input data storage, security, or backup.
   However, the internal structure of the Application and Data Layer
   is out of generates one response to each
   request,

   o supports the scope payment negotiation (Consumer: selection of this document.

2.1.2 Implementation Variants

   The implementation variant defines the concrete realization actual
   payment instrument or method; Merchant: selection of
   these layers. Although this proposal focuses on the WWW
   environment, any concrete realization is omitted.

2.1.3 Component Distribution

   Component distribution means that the architecture needs payment
   methods being offered to be
   mapped onto different infrastructures and that different
   realizations become necessary. While this mapping is quite
   trivial on current consumers' personal computers, it is more
   complicated on the server's side. Complexity may even increase on the consumer's side with Consumer) preceding the upcoming of intelligent payment
   periphery, e.g., intelligent chip card reader. E.g., the
   architecture may be implemented at request,

   o requests additional payment specific support from the Existing
   Payment Handler on a
   single main server or may be distributed between multiple server
   stations.

   The architecture should be considered from two different points
   of view, i.e., from Software via the server's selected and from registered the consumer's point of
   view.

2.2 Requirements IOTP Payment
   Bridge,

   o initializes and Commitments

2.2.1 Basic Requirements

   In addition to terminates the aforementioned IOTP objectives, Existing Payment Software via the user's
   prospective must be considered.

2.2.1.1 Electronic Commerce Provider (Server)

   o  The Trading Architecture must be scaleable.
   IOTP Payment Bridge,
   o  The implementation must support 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 supervises the 24h/7d service. The online
   dialog system should be always available. Precautions are
   necessary that support changes, e.g., maintenance, during transaction process and traces its progress,

   o stores the transaction data being exchanged over the
   operating hours. IOTP wire -
   payment scheme specific data is handled transparently,

   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 architecture must provide functions that can relation might be used by
   most of the providers. Therefore, lowered
   to the architecture clearly
   describes its core components party's Payment Identifier, IOTP Payment Bridge, Wallet
   Identifier, and the interface to remote parties when the provider
   specific services.

      -  The architecture addresses all layers inclusive actual payment
   transaction has been successfully started.

   o implements a payment transaction progress indicator,

   o enables the
      refinement layer. The application inquiry of pending and data layer may be
      realized completed payment transactions,

   o implements generic dialogs, e.g., brand selection, payment
   acknowledge, payment suspension / cancellation, receipt
   visualization, basic transaction inquiry, balance inquiry, or receipt
   validation,

   o defers payment specific processing, supervision, validation, and
   error resolution to the Existing Payment Software. It is expected,
   that the Existing Payment Software tries to resolve many errors first
   by the providers. extended exchange of Payment Handlers Exchange messages. The most
   significant and big merchants
      may implement these capabilities on behalf visible failures arise from sudden unavailability or
   lapses of their existing
      installations.

      -  For example, the interface to local or opposing payment component.

   o supports the invocation of any Existing Payment Software
      located at the application layer bases on the XML format.

2.2.2  Security Requirements and Commitments

   Security Requirements have strong influences on the design of the
   architecture. I.e., several concrete security mechanisms in an
   interactive mode, which might be used (1) for the
   transmission and requirements payment scheme
   specific post-processing of a (set of) payment transactions, (2) for
   the operating environments at
   the consumer's and provider's side reflect distinct security
   levels. Baseline IOTP provides integrity protection but future
   versions analysis of IOTP will incorporate more sophisticated mechanisms a payment instrument, (3) for confidentiality, authenticity, and integrity.

2.2.2.1  Overview about the Security Levels

   Several security levels protect the application data.

        Security Level            Architecture  Method
                                  Layer
   {1}  transmission              access layer  e.g. SSL
        (inclusive
         authentication
         provider -> consumer)
   {2}  authentication            end system    local pass phrase
        (consumer -> certificate, layer         verification through
         chip card)                             software or the
                                                consumer's chip card
   {3}  document                  refinement    future versions registration of
        (inclusive                layer         IOTP a
   new payment instrument/scheme, or (4) re-configuration of specific
         authentication e.g. a payment methods
         chip card <-> provider)
   {4}  authorization             application   provider's
                                  layer         application

   The security levels can be classified as follows:
   instrument/scheme.

   o  The Transmission Security exports call back functions for Transport Purposes {1} implements
   the secure transmission between two parties (HTTP server and Web
   browser) without any interpretation of the content. E.g., the
   transmission of use by the Java applets belongs to this class. IOTP Payment Bridge or
   Existing Payment Software for progress indication.

   In addition,
   products, information announcements, and trading offers that may lead
   to an the IOTP transaction require transmission security.

   o  The Application Security {2-4} provides the strongest protection
   for Core

   o manages the financial and trading transactions. The remaining security
   levels fall into this category.

2.2.3  Security Mechanism

2.2.3.1  Transmission Security

   Socket security IOTP message components like SSL implement the transmission
   security. Both instances of the access layer at the consumer's and
   provider's side may exchange their data SSL secured. This implies
   that the international versions of the common Web browsers deliver
   only weak security, except IOTP message blocks
   exchanged during the provider is a financial institute.
   This provider needs a special certificate transaction which may be referenced and has to use particular
   HTTP servers. The consumer has to use accessed
   during the newer releases processing of Web
   browsers. Particular European browser add-ons close the security hole
   outside the USA subsequent messages, e.g., for signature
   verification. In particular, it stores named Packaged Content
   elements exchanged during payments.

   o manages several kinds of identifiers, i.e., transaction, message,
   component, and Canada block identifiers,

   o implements a message caching mechanism,

   o detects time-outs at the protocol and offer world wide strong security API level reflecting the
   communication with
   full sized symmetric session keys.

   SSL supports both server and consumer authentication. From the
   worldwide prospective, US browser integrated SSL V2 offers both weak
   confidentiality IOTP aware remote party and weak integrity while SSL V3 offers weak
   confidentiality but strong integrity. the Payment
   API aware local periphery, e.g., chip card (reader) may raise time-
   outs.

   However, the usual RSA key size
   is limited to 512 bits, in contrast IOTP Payment Bridge and Existing Payment Software do not
   have to the normal key sizes of SET ,
   CyberCash , eCash ( rely on all 1024), and HBCI (768).

   The server's private authentication key may be stored in a special
   hardware device.

   Server authentication offered by both versions of SSL suffices in
   most cases. It supports these IOTP Application Core's capabilities.
   E.g., some Consumer's Existing Payment Software may refuse the secure transmission
   disclosure of Java applets etc. specific payment instruments at brand selection time
   and may delay this selection to the verification of "Check Payment Possibility"
   invocation using its origin by the consumer. And it provides own user interface.

   The IOTP Payment Bridge's capabilities do not only deal with actual
   payments between the base for HTTP Basic Authentication or (mutual) authentication at Consumer and the application layer.

2.2.3.2 Authentication

   ID / pass phrase pairs or certificates can prove Payment Handler but extend to
   the claimed
   consumer's identity. When using chip cards, these cards should enable
   their transaction sensitive mechanisms only after successful local
   authentication.

2.2.3.3 Document Security

   The security services following:

   o translation and (dis)assemblage of messages between the refinement layer process formats of
   the IOTP level
   document security. This includes: Payment API and those of the Existing Payment Software.
   Payment API requests and response are strictly 1-to-1 related.

   o  document integrity
   Digital signatures or message authentication codes permit this.

   o  authentication
   Mutual authentication may happen at startup each time a new
   communication channel is established between two trading roles, i.e.,
   Consumer - Merchant / Payment Handler / Delivery Handler.

   o  confidentiality
   The data stream may be optionally encrypted in addition to the
   transmission protocol. However, Baseline IOTP provides
   confidentiality only Consumer's payment instrument selection by the use means of transmission security mechanisms.

   o  validity
   Counters, nonces, or unique transaction identifiers ensure message
   freshness and prevent replay attacks.

   o  defense an
   unsecured/public export of attacks
   Failed signatures may be controlled and defended (brute force
   attacks).

   A unique crypto application programming interface offers the services
   for document security processing. Beneath the software based
   implementation, relationship of payment brands,
   payment protocols, and payment instruments (identifiers). Generally,
   this API may offer services for accessing some
   central crypto hardware, too. This hardware stores includes not just the crypto keys
   and performs brand (Mondex, GeldKarte, etc.) but also
   which specific instance of the cryptographic operations. Such a device is expected instrument and currency to be implemented by a chip use (e.g.
   which specific Mondex card at the Consumer's side and by tamper
   resistant security modules at the which currency of all those
   available).

   However, some Existing Payment Handler's side. The
   equipment at the Merchant and Customer Care Providers may depend on
   their expected load.

   The refinement layer Software may require additional data for key management
   purposes, i.e., certificates or private keys.

   The result of this security verification is reported to defer the
   application layer. Security warnings, e.g., replay attacks detected
   at selection of
   the refinement layer, may be forwarded payment instrument to other application
   modules, e.g., card or user management systems.

   However, the refinement layer does not manage actual payment carrying-out or it may
   even lack any security management of
   transparently embedded data payment instruments. E.g., chip card
   based payment methods may offer - Point of Sale like - implicit
   selection of the payment scheme specific data. Its
   security needs to be handled instrument by simple insertion of the application layer.

2.2.3.4 Authorization

   The application layer implements chip
   card into the authorization procedures and
   different procedures may be offered by chip card reader or it interrogates the providers. The following
   information influences inserted card
   and requests an acknowledge (or selection) of the counterparty's verification: detected payment
   instrument(s).

   o  result of payment progress checks, e.g., is there enough funds available to
   carry out the authentication
   derived from purchase, or enough funds left for the document integrity reported refund,

   o IOTP Payment Receipt checks which might be performed over its
   Packaged Content or by the refinement layer. other means.

   o  result recoding of payment scheme specific receipts into a format which
   can be displayed to the document integrity
   evaluated information reported by the refinement layer.

   o  authorization
      -  user, account, user or chip card status Verification printed,

   o cancellation of user,
      account, or chip card presence payment, even though it is not complete,

   o suspension and status.

      -  competence verification counterparty's, mainly consumer's,
      authorization resumption of payment transactions. Two kinds of
   failures the requested transaction type at Existing Payment Software might deal with are (1) the application
      layer.

2.2.4  Protection against Attacks

   In principle, multiple points
   time-out of attacks exist that need accurate
   protection:

   o  consumer's system,
   o  providers' systems respective their computing centers, the network connection and
   o  transmission line.

   Generally, several providers are involved during each (2) lack of funds. For
   resolution, the IOTP
   transaction - even during Application Core may try the individual steps - while basically only
   one consumer participates (consumer suspension with a
   view to business). This scenario may later possible resumption.

   o recording the payment progress and status on a database. E.g.,
   information about pending payments might be extended for business used to business transactions in future versions
   of IOTP.

2.2.4.1  Consumer System

   The protection of assist their
   continuation when the consumer's system, i.e., vulnerable personal
   computer with unsecured applications, is quite difficult. Better
   security next payment protocol message is obtained by specialized consumer electronic components received.

   o payment transaction status inquiry, so that integrate chip cards implementing the important security
   procedures 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 tamper resistant hardware. The following requirements
   need to be satisfied by advance of a PC based system. payment transaction
   acknowledge,

   o  On the Internet, the transmission security should inquiry on abnormal interrupted payment transactions, which might
   be ensured used by an
   SSL instance. Very sensible the IOTP Application Core to resolve these pending
   transactions should be secured by an SSL
   implementation with full cryptographic strength. at startup (after power failure).

   o  Additionally, the transaction data may payment progress indication. This could be symmetrically or
   asymmetrically secured by software or chip cards.

   o  Best security is obtained by used to inform the use end
   user of intelligent chip card
   readers details on what is happening with an integrated keyboard and display. This allows the
   secure input payment.

   o payment method specific authentication methods.

   Existing Payment Software may not provide full support of pass phrases, these
   capabilities. E.g., some payment schemes may not support or even
   prevent the safe display of explicit transaction data,
   and cancellation at arbitrary phases of
   the signature outside payment process. In this case, the personal computer. Viruses and Trojan
   horses are not able IOTP Payment Bridge has to attack the chip card reader.

   o  The environment for the input
   implement at least skeletons that signal such lack of support by the transaction data needs to be
   secured. Current implementations
   use of Web browsers for personal
   computers specific error codes (see below).

   The Existing Payment Software's capabilities vary extremely. It

   o supports payment scheme specific processing, supervision,
   validation, and workstations have error resolution. It is expected, that many security holes, e.g., Java
   virtual machine, ActiveX.

2.2.4.2  Transmission Line

   The network providers control errors
   are tried to be resolved first by the security extended exchange of the transmission line.
   There is no additional danger, if strong cryptographic mechanisms Payment
   Exchange messages.

   o provides hints for
   end out-of-band failure resolution on failed inbound
   resolution - inbound resolution is invisible to end security are used. All end points are located at the
   consumer's respective provider's sphere.

2.2.4.3  Provider's Computing Center 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 providers' end points latter is required by Payment
   Handlers for the transmission easy and document security
   are located at their computing centers. Important secret/private keys
   may be stored in hardware. Separate hardware components should be
   used according to cost effective failure resolution.

   o implements the different quality of both security levels.

   Additional protection against illegal access, e.g., a firewall, is
   necessary. This does not secure payment scheme specific dialog boxes.

   Even the application data but addresses
   system attacks from generic dialog boxes of the public Internet.

3.  Layers and Functional Components

   A flexible architecture requires its partition into multiple logical
   layers. These layers incorporate IOTP Application Core might be
   unsuitable: Particular (business or scheme) rules may require some
   dedicated appearance / structure / content or the functional components. Changes
   at one layer dialog boxes, may not necessarily imply changes at other layers. And,
   prohibit the introduction of additional implementation variants does not
   necessarily imply changes on all layers. The architecture consists unsecured export of payment instruments, or may
   prescribe the pass phrase input under its own control.

2.  Message Flow

   The following layers whereby the communication between the access and
   the refinement layer bases on IOTP:

        Notation           Duties
   1    end system layer   user interface and off-line functionality lists all functions of the consumer's system (personal
                           computer or other intelligent end device
   2    network layer      communication between consumer and
                           provider
   3    access layer       transport coupling and presentation
                           control
   4    refinement layer   processing of IOTP Payment API:

   o Brand Compilation Related API Functions

   "Find Accepted Payment Brand" identifies the transaction message

   5    application layer  electronic commerce functionality 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
                           control
   6    data layer         data management

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer
      presentation software
      document formatting, document security, transport coupling
                                |service specific formats
   network layer                v
      network access procedure
      network participant management
      network services          ^
                                | service returns
   payment scheme specific formats
   access layer                 v
      presentation services
      presentation control monitor
      transport coupling        ^
                                | document format IOTP
   refinement layer             v
      document security
      document formatting       ^
                                | packaged content data format
   application layer            v
      electronic commerce application
      application monitor (authorization)
                                | provider specific format
   data layer                   v
      data access
      integrity
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
              Figure 3: Layer Components of the Architecture

   The architecture describes for brand selection
   purposes.

   This function might be used in conjunction with the layers inclusive aforementioned
   function or called without any brand identifier.

   "Get Payment Initialization Data" returns additional payment scheme
   specific packaged content for payment processing by the refinement layer
   and their interfaces to payment
   handler.

   "Inquire Authentication Challenge" returns the payment scheme
   specific implementations of authentication challenge value.

   "Check Authentication Response" verifies the
   provider's applications.

3.1  End System Layer

   The end system layer returned payment scheme
   specific authentication response value.

   "Change Process State" is localized at the consumer's side. The
   architecture defines the components used (here only) for electronic commerce. It
   considers the use abnormal termination.
   (cf. Payment Processing Related API Functions).

   o Brand Selection Related API Functions

   "Find Payment Instrument" identifies which instances of standard software and browser based applications
   as well as client based and server based implementation alternatives.

   An (optionally certified) IOTP aware application implements the data
   format parser and the security services. a payment
   instrument of a particular payment brand are available for use in a
   payment.

   "Find Payment Protocol" identifies which payment protocols are
   supported by a specific payment instrument, resp. payment brand.

   This application may bolt on
   standard software or browser based applications. The implementation
   should reflect function might be used in conjunction with the depicted architecture:

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End system layer
     presentation software
       o  standard software
       o  web browser based
     document security
       o  document authenticity
       o  document encryption
       o  validity
     document formatting
       o  conversion between IOTP and application formats
       o  format syntax aforementioned
   function or called without any brand identifier.

   "Check Payment Possibility" checks of whether a specific payment
   instrument is able to perform a payment.

   "Authenticate" forwards any payment scheme specific authentication
   data to the IOTP structure (segments,
     lengts, elements, attributes etc.)
       o  logical compression
     transport coupling
       o  network protocols
       o  transmission security Payment Bridge for processing.

   "Change Process State" is used (here only) for abnormal termination.
   (cf. Payment Processing Related API Functions).

   o  access protection
     IOTP kernel maintenance
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
        Figure 4: Components and Payment Processing Related API Functions of the End System Layer

3.1.1 Presentation Software

   The presentation software performs the actual electronic commerce
   processing at the consumer's side. It is responsible

   "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
   presentation, too. This applies both to personal computers the
   Existing Payment Software and other
   consumer electronic end devices.

   There are no requirements how returns more payment scheme specific
   data for transmission to provide the counter party.

   "Change Process State" changes the current status of payment
   transactions. Typically, this functionality.
   Generally, two classes can be distinguished:

   o  program parts base on intelligent browser extensions like Java
   applets, plug-ins call is used for successful/- less
   termination or helper applications. suspension.

   o  standard products for electronic commerce.

3.1.2  Document Formatting

   This component includes functions for General Inquiry API Functions

   "Remove Payment Log" notifies the generation and analysis of IOTP messages as well as mechanisms for initialization and
   termination Payment Bridge that a
   particular entry has been removed from the Payment Log of the IOTP transactions. They correspond to those
   Application Core.

   "Payment Instrument Inquiry" retrieves the properties of Payment
   Instruments.

   "Inquire Pending Payment" reports any abnormal interrupted payment
   transaction known by the
   provider's refinement layer.

   The IOTP aware application implements these functions in browser
   based applications and standard products. This application has
   further interfaces to Payment Bridge.

   Payment Processing Related Inquiry API Functions

   "Check Payment Receipt" checks the components presentation software, document
   security, transport coupling, consistency and IOTP kernel maintenance. It
   controls their behavior.

   This general concept validity of the IOTP aware application for browser based
   electronic commerce supports its usage in PC based kiosk system in
   public self service areas, too.

   Note that IOTP defines only one instance of
   Payment Receipts, received from the very general
   refinement layer. The architecture may remain unchanged if another
   protocol Payment Handler or some future IOTP version replaces Baseline IOTP. However,
   the consumer's system generates complete transaction messages and
   transfers them to returned by
   "Inquire Process State" API calls. Typically, this function is called
   by the provider considering all security aspects.

3.1.3  Document Security

   This component provides (chip card based) document security services
   that correspond to Consumer during the respective services 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 refinement layer.

3.1.4  Transport Coupling

   This component manages communication channels in cooperation with the
   respective components Packaged Content of the access layer at the counterparty. It
   supports socket security mechanisms like SSL and XML message
   processing.

3.1.5  Maintenance

   The end system layer should provide functions for maintenance of the IOTP aware application. This may be ordinary software maintenance Payment
   Receipts as well as application payment scheme specific extensions. Also an organizational
   concept including access protection to the application components is
   needed.

3.2  Network Layer

   The network layer of the architecture connects the consumer's system
   with the provider's system. The network provider implements this
   layer and promises its reliability. The offered services base on
   standardized communication protocols.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Network layer
     network access procedure
       o  access procedure and identification
       o  end device characteristics
     network participant management
     network services
       o  Internet
       o  other
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
          Figure 5: Components and Functions of the Network Layer

   The network provider realizes the network access procedure and
   implements the participant management with respect to the consumer's
   identification. The result of this verification may payment receipts into a
   form which can be reported to
   the access layer's component transport coupling together used for display or printing purposes.

   "Inquire Process State" responds with the
   determined characteristics of payment state and the end device.

   Currently, Baseline IOTP neglects
   Payment Receipt Component. Normally, this option due to function is called by the lack of any
   standardized clarification
   Payment Handler for final processing of the reportable data.

3.3  Access Layer

   The access layer defines payment transaction.

   "Start Payment Inquiry" prepares the entry point to remote inquiry of the provider's sphere payment
   transaction status and
   controls the presentation dialogs responds with the consumer's end device.
   This layer does no processing on the transaction payment scheme specific data exchanged
   between the provider and the consumer. All documents are processed
   transparently.

   Particular applications, so-called native programs, may serve as
   consumer attractors. Consumer attractors are games, advertisements,
   information, and calculation examples and they may
   that might be offered needed by the
   merchant trading role.

   The presentation controls and their dialog steps are realized in so- Payment Handler for the Consumer
   initiated inquiry processing.

   "Inquire Payment Status" is called frame dialogs. The capabilities are defined by concrete
   presentation services, e.g., WWW. Herewith, frame dialogs are
   adjusted to the specific presentation service. In addition to the
   control of the presentation service, the frame dialog controls the
   document transport.

   The presentation control monitor realizes the superior control, i.e.,
   initialization and termination of the channels to the frame dialogs,
   connections to Payment Handler on Consumer
   initiated inquiry requests. This function returns the application subsystems, their distribution,
   supervision, and statistics.

   The access layer consists payment scheme
   specific content of the following components and
   subcomponents:

   o  transport coupling
     -  network protocols
     -  transmission security
     -  access protection

   o  presentation control monitor
     -  frame dialogs
     -  presentation services
     -  subsystem distribution

   o  frame dialogs

   o  native programs

3.3.1  Transport Coupling

   The transport coupling provides an interface to the network layer Inquiry Response Block.

   "Continue Process" and
   contains the following subcomponents:

   o  network protocols o  tcp/ip, pay tv, mobile

   o  transmission security o  socket protection component

   o  access management o  packet filter "Change Process State" (cf. Payment Processing
   Related API Calls)

   o  firewall

3.3.1.1  Network Protocols

   The transport access depends on the actual presentation services and
   their standard mechanisms. Currently, this access is determined by Other API Functions

   "Manage Payment Software" enables the WWW. This coupling immediate activation of presentation services is called standard
   coupling. In the case
   Existing Payment Software. Further user input is under control of WWW, the socket standard defines the
   coupling
   Existing Payment Software.

   "Call Back" provides a general interface for both transmission channels.

   Both the implementation visualization of
   transaction progress by the access layer and the standard coupling IOTP Application Core.

   The following table shows which API functions must (+), should (#),
   or might (?) be transparent to the provider's and the consumer's sphere
   because the presentation service, being selected for a particular
   consumer connection, must implement the standard coupling internally.

   The next figure presents an example for standard coupling at the
   access layer:

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer's sphere              WWW/Java resp. IOTP
                                        ^
         Access layer                   |sockets
                                        |
                                      tcp/ip
         (network protocols)            |
                                        |sockets
                                        v
   Provider's sphere              WWW/Java resp. IOTP
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                Figure 6: Access Layer's Standard Coupling

   Note that the access layer usually lacks any conversion services,
   i.e., the selected consumer connection requires implemented by which Trading Roles.

   API function                  Consumer  Payment Handler  Merchant

   Find Accepted Payment Brand                                 +
   Find Accepted Payment Protocol                              #
   Find Payment Instrument          +

   Get Payment Initialization Data                             +
   Check Payment Possibility        +

   Start Payment Consumer           +
   Start Payment Payment Handler                  +
   Resume Payment Consumer          #
   Resume Payment Payment Handler                 #

   Continue Process                 +             +
   Inquire Process State            +             +            ?
   Change Process State             +             +            ?
   Check Payment Receipt            +             ?
   Expand Payment Receipt           #             ?

   Remove Payment Log               ?             ?            ?

   Inquire Authentication Challenge                            ?
   Authenticate                     +
   Check Authentication Response                               ?

   Payment Instrument Inquiry       ?
   Inquire Pending Payment          #             #
   Start Payment Inquiry            ?
   Inquire Payment Status                         ?

   Manage Payment Software          #             ?            ?

   Call Back                        #
        Table 1: Requirements on API Functions by the same standard
   coupling at both parties.

   Maybe, some provider operated IOTP aware application may accept
   document formats without an intermediate presentation service. But
   this is not expected for Baseline IOTP over HTTP or native TCP/IP.

3.3.1.2  Transmission Security Trading Roles

   The socket protection component implements next sections sketch the transmission security
   on relationships and the public network. On dependencies
   between the Internet, SSL may implement this
   service at IOTP message level while API functions. They provide the Existing Legacy Systems informal description of
   the progress alternatives and
   Existing Payment Software may secure their specific transaction data
   on their own at depict the application layer in advance to its encapsulation
   in IOTP.

3.3.1.3  Access Protection

   Components are needed that limit communication and
   synchronization between the remote access general IOTP Application Core and protect the
   provider's infrastructure against attacks from
   payment scheme specific modules.

2.1  Authentication Documentation Exchange

   This section describes how the public network.
   Firewalls and packet filters do functions in this for TCP/IP based network
   protocols. However these component prevent illegal access document are used
   together to the
   providers' system but they can not protect the data that they
   transparently process.

3.3.1.4  Presentation Control Monitor

   The presentation control monitor provides basic features being
   independent from the underlying system architecture, loosely couples
   the application 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 the presentation systems, transmit Authentication Request Block
   Authenticatee   Authenticate(Alg1, Ch1)                   -> IPB
                   AuthenticateResponse(...)                 <- IPB
                   . . .
                   Authenticate(Algm, Chm)                   -> IPB
                   AuthenticateResponse(Res)                 <- IPB
                   Create and supports the
   professional operation.

   The presentation control monitor contains the following
   subcomponents:

   o  frame dialogs Each frame dialog relates to transmit Authentication Response Block
   Authenticator   Check Authentication Response(Algm,Chm,Res)->IPB
                   Check Auth. Resp. Response()               <-IPB
                   Create and controls the
   respective presentation service. The presentation control monitor
   manages transmit Authentication Status Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 12 Authentication Message Flows

   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 connections (channels) to IOTP Application Core may add payment scheme
   independent authentication methods. All of them form the individual frame dialogs.

   The monitor provides final IOTP
   Authentication Request Block, which describes the following functionality:

     -  selection set of
   authentication methods being supported by the frame dialogs components and their presentation
     services
     -  initialization, termination and channel supervision for
     transport coupling
     -  requesting authenticator and forwarding of transport profiles for control
     purposes of from
   which the network layer

   o  parameterized subsystem distribution provides functionality
   complementary authenticatee has to choose one method.

    Note that the application monitor:
     -  mapping interface of the frame dialog's sessions API function is limited to the application layer
     -  supervision and transport parameterization
   response of exactly one algorithm per call. If the subsystems
   Further functions are:

   o  load supervision

   o  statistic and diagnosis functions

   These functions subsume
     -  logging
     System processes must remain transparent to the support personal in
     order to provide consumer support. The monitor must IOTP Application
   Core provides a choice of algorithms for input, this choice should be able to log
   reduced successively by the history returned algorithm ({Alg(i+1)*} is subset
   of {Algi*}).

    During the dialog steps and the progress registration of new Payment Instruments, the IOTP message
     exchanges for each session, hereby delivering Payment
   Bridge notifies the raw data for
     subsequent analyses.  o  statistics and reporting functions Online
     statistics IOTP Application Core about the maximal and current number supported
   authentication algorithms.

   2. On presence of connections and an IOTP Authentication Block within the states of received
   IOTP message, the electronic commerce environment are necessary.
     They enable Authenticatee's IOTP Application Core checks
   whether the detection of bottle necks and system adjustments.
     -  error processing
     The monitor must be able to report specific error messages to IOTP transaction type in the
     consumer's system and to current phase actually
   supports the provider's applications. These
     messages can be used by authentication process.

    For each provided Authentication Request Component, the IOTP
   Application Core analyzes the algorithms' names, the transaction
   context, and optionally user help desk for error localization,
     too.
     -  trace function
     The monitor's dialog control should be traceable, i.e., preferences in order to determine the monitor
     should provide a logging function for its own actions. This trace
     function should be able
   system components which are capable to trace subsets of connections.

3.3.1.5  Parameterized Subsystem Distribution

   This function complements process the subsystem distribution of authentication
   request items. Such system components might be the
   application monitor. Based on information IOTP Application
   Core itself or any of the network layer, registered IOTP Payment Bridges.

    Subsequently, the
   presentation control monitor initiates IOTP Application Core requests the connection responses to
   the
   requested application monitor or application subsystem and supervises
   these connections. Both single and multiplexed connections may be
   supported.

3.3.1.6  Frame Dialogs

   The further partition of supplied challenges from the frame dialog's functionality yields:

   o  presentation services
   They implement determined system components in any
   order. The authentication trials stop with the actual online dialog with the consumer. Native
   presentation methods are used to implement the transaction dependent
   parts of the electronic commerce offer, e.g., determination of
   acceptable payment methods, offer generation, payment, digital data
   delivery. Native presentation methods of first successful
   response, which is included in the Internet are HTML pages;
   scripts, applets, and pre-installed applications. The main functions
   are:

     -  management of provider specific data, individual presentation
     possibilities
     Often, IOTP Authentication Response
   Block.

    Alternatively, the provider requires IOTP Application might ask for a specific look & feel (logos,
     colors). user selection.
   This should be controlled by tables whereby each service
     uses its own table.

     -  dialog control
     The fundamental connection control should base on tables. They
     specify which dialogs need to might be activated after a specific appropriate, if two or more authentication algorithms
   are received that require explicit user
     input. interaction, like PIN or chip
   card insertion.

    The frame dialog coincides with a table automaton. These
     tables must Authenticatee's organizational data is requested by an IOTP
   Authentication Request Block without any content element. On failure,
   the authentication (sequence) might be customizable and maintainable. retried, or the whole
   transaction might be suspended or cancelled.

   3. (Authenticator Process) The dialog controller
     must support tracing in order to prevent IOTP Application Core checks the
   presence of a removed
     objects in the table. This log documents the dialog process and can
     be used for review purposes.

   o  document transport IOTP realizes Authentication Response Component in the document transport for electronic commerce. The
   provider's Web server or
   Authentication Response Block and forwards its content to the IOTP aware application represents
   generator of the
   corresponding implementation. It associated authentication challenge for verification
   ("Check Authentication Response").

   On sole organizational data request, its presence is based on standard TCP/IP
   protocols checked.

   Any verification must succeed in order to proceed with the usage of an intermediate presentation protocol
   (HTTP).
   transaction.

2.2  Brand Compilation

   The socket protection component may be disabled, if following shows how the IOTP
   protocol provides its own document security - this does not apply to
   Baseline IOTP. The frame dialog uses the protocols of the
   presentation service and controls herewith this application. The
   application requests data from the presentation service or responds
   data to it until an IOTP message has been generated or processed.

   Baseline IOTP over the Internet assumes pre-installed consumer
   applications. Although the IOTP application manages the visualization
   and dialog appearance, the provider generates and formats the
   visualized transaction specific data, e.g., payment brand, logo,
   purchase amount, (organizational) descriptions. Furthermore, he has
   to trace the message exchanges in order to synchronize his own
   transaction progress with the consumer's transaction progress.

3.3.2  Presentation Services

   The presentation services base on established, standardized, and
   extensible description services. Therefore, only fundamental
   requirements are noted that need to be fulfilled by these services.

   The established implementations of presentation services of the
   Internet are Web servers.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Presentation Services
     o  native presentation
       -  basic presentation protocols (HTML, ...)
       -  graphical user interface (style guides)
       -  character set conversion (ASCII <-> EBCDIC)
     o  optimization
       -  compression
       -  local object cashing
       -  refresh
     o  transport information
       -  inquiry and parameterization services of the transport
          coupling (security, configuration, performance, quality)
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
      Figure 7: Components and Functions of the presentation services

3.3.2.1  Native presentation (standard)

   The standard presentation protocols apply to the presentation modus,
   i.e., HTML is used on the Internet optionally enriched with Java or
   ActiveX applets, JavaScript or VisualBasic scripts. The IOTP protocol
   contains also some data being visualized during the transaction.
   Considering Baseline IOTP, the preceding browsing and shopping steps
   base on the standard presentation protocol. Afterwards the
   transaction switches to IOTP. The implementation of the user
   interface considers the requirements of the provider.

3.3.2.2  Optimization

   The transmission of the presentation data using the Internet is
   recommended and advantageous due to performance considerations and
   costs. Nevertheless, optimization should be independent from the
   network. Example operations are logical compression, local object
   caching, and slim data transmission.

   The HTTP cache management and the packaging of several Java classes
   in one archive are two Internet specific optimizations.

   Logical compression deals with the omission of empty or superfluous
   data elements.

3.3.2.3  Transport Information

   Presentation services are network independent. But it is pithy and
   necessary to receive information from the network layer or to control
   this layer through parameters. The presentation service may provide
   the mechanisms for accessing and forwarding such information.

   The network provider may provide the following information:

   o  network type (TCP/IP, ...)
   o  participant identification
   o  end device identification

   This information could be used for security purposes, statistics,
   configuration, performance and quality of service.

3.3.2.4  Native Programs

   Optionally, the access layer may contain application services. It may
   be more advantageous to implement simple calculations, e.g., ATM
   locators or zip code determinations, immediate in the access layer,
   without the usage of any subsystem, relieving the application
   systems.

   Particularly, scripts and applets offer new perspectives because they
   transmit program parts to the consumer's system and execute them on
   the remote system. This allows the server side supplement of raw data
   and their consumer sided refinement, i.e., processing and
   visualization. This relieves the central systems because the
   consumers' systems perform the main part of the computation. More
   complex applications are possible with remote data base access (JDBC,
   RMI). The potential increases further if complete applications are
   distributed on CDROMs etc. instead of dynamic transmissions of
   network accurate (down-)scaled scripts and applets.

3.4  Refinement Layer

   Ideally, the refinement layer separates the application layer from
   the actual access layer. Mainly, it establishes a stable interface.
   The refinement layer communicates with IOTP formatted messages
   towards the access layer and with application specific formatted
   messages towards the application layer, e.g., providers' existing
   legacy systems. It converts the messages between the respective
   formats.

   The IOTP aware application, i.e., IOTP Application Core, belongs to
   this layer.

   The refinement layer supplies services that can be accessed by the
   application layer:

   o  format conversion: task of the IOTP services
   o  security (document): task of the security and stock data
      services
   o  format optimization: task of the security services

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Refinement layer
     o  document security
       -  document authenticity (authentication, signing, etc.)
       -  stock data management (RSA key management, wrong
          signatures)
     o  document formatting
       -  conversion between IOTP and application format
       -  formal syntax checks
       -  character set conversion (ASCII <-> EBCDIC)
       -  logical compression and decompression
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
           Figure 8: Refinement Layer's Components and Functions

3.4.1  Format Conversion

   The format conversion guarantees the access layer's independence from
   the application and provider specific data formats and yields the
   portability of the presentation control monitor between different
   installations. This is of particular importance for bank or near-bank
   Payment Handlers with their broad range of proprietary existing
   installations.

   The IOTP service performs the following tasks

   o  formal syntax check and semantic analysis of the IOTP message
      (correct protocol building blocks, elements, lengths,
      attributes, matches of descriptive header attributes and
      elements, and dangling cross references)

   o  verification of the document security referencing the security
      services

   o  generation and supervision of IOTP dialog sequences

   >From the provider's prospective it should be considered that the
   received messages may be generated both by the consumers' home
   electronic commerce applications and public self service terminals.

   Furthermore, the format conversion handles character set conversions.
   This conversion depends on the installation platforms.

3.4.2  Document Security

   The secure (confidential, authentic, integer) data exchange between
   the consumer and the provider is one important requirement for
   electronic commerce. The consumer leaves the sphere of the provider
   (merchant, financial institute etc.), in contrast to the traditional
   face-to-face business. Instead, the data is generated in the
   consumers' private environment, by trusted servers, or at public
   terminals and transmitted over the public network. Therefore, the
   document security seems to be worthwhile despite Baseline IOTP's
   focus on message integrity.

   The verification of the document authenticity requires either a stock
   data management for the key and signature management without any
   contribution of the data layer. Alternatively, a certification
   hierarchy may be established. Stock data may be Certificate
   Authority, provider (, and consumer) certificates as well as
   otherwise encoded cryptographic keys. It may include further
   information about the consumer. This data is intended only for key
   management. Any authorization of a transaction is deferred to the
   application layer.

   The refinement layer should support the anonymous access - at least
   for registration purposes - if the provider offers the actual service
   to registered consumers, only.

3.4.3  Format Optimization

   The security services optimize the data format by compression and
   decompression operations.

4.  Recapitulation

   The following discussion focuses on the Consumer and Payment Handler
   and simplifies the provider's IOTP Middleware / Existing Legacy
   System to the IOTP Payment Bridge / Existing Payment Software.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   End System Layer

   Network Layer

   Access Layer
     o  Transport Coupling
       -  access protection: packet filter, firewall
       -  transmission security: SSL, TLS
       -  network protocol: TCP/IP, HTTP, XML
     o  Presentation Service
       -  graphical user interface
       -  HTML
       -  character set conversion

   Refinement Layer                                         IOTP
     o  Document Formatting                              APPLICATION
       -  IOTP level semantical analysis                    CORE
       -  transaction reference analysis
       -  cross reference management
       -  character set conversion
     o  Document security
       -  Hash
       -  canonical form transformation
       -  signature capabilities
     o  Cache Management
       -  idempotency checks
       -  logging capabilities
     o  Transaction Database
       -  storage of IOTP messages, blocks, and elements indexed by
          transids or blockids
       -  transaction status memory
     o  Dispatcher
       -  routing
       -  session management
     o  Transaction Type Processors
       -  IOTP transaction types
       -  user inquiries
       -  policy, configuration data base

   Application Layer                                            IOTP
     o  Device Driver                                   MIDDLEWARE /
       -  chip card, PIN PAD                         PAYMENT BRIDGE
       -  tamper resistent security module      -------------------
     o  Payment Protocol Driver             EXISTING LEGACY SYSTEM /
       -  Secure Electronic Transaction   EXISTING PAYMENT SOFTWARE
       -  Secure Channel Credit and Debit
       -  ...

   Data Layer
     o  Transaction Database
       -  storage of transaction data
       -  transaction status memory
       -  stock data
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                   Figure 9: Architecture Recapitulation

   Figure 14 entails a more compact view of the Trading Architecture.
   Implementations may consider additional middleware or the more
   detailed view on the IOTP / Payment Bridge being omitted from the
   following description. This figure names the important functional
   modules of an IOTP application and maps them to the identified
   architecture layers. Example modules are:

   o  TCP/IP stacks,
   o  SSL security packages,
   o  HTTP wrapper,
   o  XML parser / validator and generator,
   o  IOTP semantic analyzer,
   o  security modules for document security,
   o  cache manager,
   o  internal database system,
   o  format converter,
   o  display and dialog management,
   o  session management: Transaction, Message, Element Identifier
      Management,
   o  dispatcher,
   o  transaction specific processing modules,
   o  . . .

   IOTP defines the interface between the access and the refinement
   layer. The HTTP and the XML processors, which parse and validate IOTP
   messages, are assigned to the access layer.

   The transaction database is the central component of the IOTP
   application. It stores the transaction data (IOTP messages,
   components, and blocks) and realizes the persistent memory of the
   internal transaction state automaton. The specific transaction type
   processors interrogate the database for internal state update /
   verification and transaction data. Nevertheless, the IOTP Payment
   Bridge and Existing Payment Software may use their own databases or
   they may refer to this database through call back functions.

   The figure indicates further interfaces between the other layers and
   their internal modules. They have not been fixed yet due to their
   variance between the different roles, systems, vendors, ...
   Furthermore, the figure describes the transaction type processors
   very coarsely. Obviously, the Payment Handler's Payment Bridge
   cooperates with the Existing Legacy Systems. Therefore the
   transaction type processors may indirectly request further
   installation specific communication and application specific
   services, e.g., some CORBA middleware, SNA transport protocol, or
   external transaction approval.

4.1  Example Justification

   TCP/Internet Protocol (TCP/IP):
     TCP/IP is the basic network protocol used for information exchange
     on the Internet with increasing success even in business
     environments. It provides sole transport services and does not
     depend on any application data. The TCP/IP module is assigned to
     the Transport Coupling module of the access layer.

   Secure Socket Layer (SSL), Transport Layer Security (TLS):
     SSL and TLS add sole channel security services to the basically
     open unsecured TCP/IP. Consequently, they encrypt transparently
     application data before transmission and remove the security
     envelope after receipt. Although SSL and TLS build upon TCP/IP they
     offer sole access services.

   Hypertext Transfer Protocol (HTTP) Wrapper:
     >From the application's or IOTP's point of view, HTTP is a generic
     wrapper used for pre-transmission conversion, such that
     transmission could be easily realized by the reuse of current
     software components (Web browsers and HTTP servers). Furthermore,
     HTTP wrapped messages pass firewalls with the highest probability -
     HTTP provides only access services.

   Extensible Markup Language (XML):
     The actual IOTP message content is encoded in XML and the Document
     Type Declaration (DTD) defines the syntax of IOTP messages. The XML
     parser checks received XML messages on syntactical well-formedness
     and IOTP-DTD validity. Even the powerful XML parser remains an
     access utility from the application's point of view.

   The transmission of data uses specific formats and conversions of low
   level data entities. E.g., byte order of characters, character sets.
   Some of these presentations services may be optionally handled by the
   HTTP parser or the XML parser. However, the abstract view assigns
   their subservices to the presentation services.

   Graphical User Interface (GUI):
     Furthermore, these services subsume the dialog service with the
     consumer, e.g., pop-up of notification/alert windows or input forms
     and low level input processing.

   Hypertext Markup Language (HTML):
     The presentation service includes any HTML processor - the HTML
     engine of the Web browser - that visualizes any HTML encoded data.
     It includes also style sheet processors and visualization engines
     for XML. The operating system (MS Windows, ...), the window system
     (X11, ...), or the reused tools prescribe the interface. Any
     further refinement of this interface or the introduction of a
     portable intermediate layer is out of the scope of this document.

     All of the aforementioned capabilities belong to the access layer.
     The next items describe the refinement layer.

   Document Formatting:
     The incoming IOTP messages - nevertheless encoded in XML but now
     verified w.r.t. well-formedness and validity- reach the refinement
     layer. This layer provides modules from IOTP level document
     verification (use of unique transaction id, use of other ids, valid
     cross references, analysis of interior structures, e.g., syntax of
     net locations, descriptions, embedded data). It transforms XML
     encoded IOTP messages to an internal structured representation.
     These functions belong to the architecture component "document
     formatting" because they deal with the internal application
     specific structure of IOTP messages. Vice versa, the document
     formatter enriches the internal representation of IOTP messages and
     encodes them to IOTP specific XML before transmission.

   Document Security:
     Baseline IOTP provides some security mechanisms that build an extra
     architecture component. This increases the flexibility of the
     architecture. E.g., vendors could plug in several security modules
     without affecting the remaining application. Furthermore, Payment
     Handlers may prescribe high security requirements that affect only
     an isolated topic of the architecture and therefore an isolated
     module of the application.

   Cache Management:
     The cache manager implements a hardly application dependent
     mechanism for idempotency checks of  messages. The cache manager
     does not belong to the access layer because IOTP defines the rules
     for idempotency checking.

   Dispatcher:
     The dispatcher is the master module of the IOTP Application Core.
     It receives all events - both from the user and the remote party -
     and determines the respective slaves, i.e., transaction type
     processors. The dispatcher manages session related requests and
     responses. The dispatcher and the transaction type processors
     depend on the IOTP application.

   Transaction Database:
     The transaction database stores both the message content and the
     internal state information.

   Existing Payment Software:
     The Existing Payment Software together with the suitable IOTP
     Payment Bridge define the Application Layer. Their internal
     structure is not described. However, a more elaborated discussion
     would result in a structure comparable with the IOTP Application
     Core.

5.  Progress Example

   This section describes the progress of an IOTP transaction within the
   Trading Architecture step by step and uses an example consumer dialog
   for the brand independent payment with a provider combining the
   Merchant and Payment Handler trading roles. The implementation
   variant "TCP/IP - WWW, Java, SSL" with an online distributed Java
   applet is assumed that implements the IOTP aware application. Secure
   Channel Credit and Debit (SCCD) based payments may be implemented by
   Java applets. SSL implements the secure data transmission. The
   description focuses on the participation of the individual layers and
   clarifies their roles.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Client (Consumer)      IOTP request 1         Server
                     ------------------------->
                         IOTP response 2
                     <-------------------------

                          IOTP request n
                     ------------------------->
                         IOTP response n
                     <-------------------------
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

   End System Layer

      Pre IOTP progress:
      1.  The consumer dials into the Internet using his (arbitrary)
      network provider and establishes the physical Internet connection.
      2.  The consumer uses the pre-installed Web browser for the
      visualization of HTML pages that have been fetched from the
      Internet.
      The consumer interacts only with the component presentation
      software, i.e., the Web browser. The other components of the end
      system layer cooperate with the browser transparently.

   Network Layer
      3.  The network provider identifies the participants and supplies
      the service access points for WWW and Email.
      4.  The network provider may offer his own WWW content. Usually,
      the HTTP protocol is offered on port 80.

   End System Layer
      5.  The consumer connects to some merchant site, browses through
      the merchant's offer, and fills his shopping cart. The initial URL
      may be accessed by user input or links from other pages (home
      page, result page of a Web search engine. Then the consumer
      decides to check out the shopping cart and agrees to the
      subsequent payment.

   Access Layer
      7.  By assumption, the requested page is SSL secured, indicated by
      the protocol HTTPS in its URL. This page is used to initiate the
      secure download of the Java applet.
      8.  The socket protection entity of the transport coupling
      component responds with the encrypted session key material.

   End System Layer
      Remark:
      The browser has been configured with the public key needed for the
      authentication of the page's origin. The key may be configured by
      the consumer, manually (neither safe nor recommended). The key can
      be sent to the consumer by standard mail or it can be downloaded
      from another site. The latter requires another browser built-in
      public certification key.

      8.  The consumer's (and provider's) socket protection components
      exchange the encrypted session key material (certificates and
      encrypted pre-master keys). The browser (or SSL helper
      application) verifies the key material using the configured public
      keys, derives the actual session keys, and accepts or rejects the
      upcoming transmission of the requested page.
      9.  The consumer gets an indication - e.g. icon change - about the
      successful SSL connection. Manually, he may pop up the received
      certificate and verify the authenticity of the server.
      10.  Now the browser initiates the actual request of the page. The
      transport coupling receives the encrypted page. The browser
      decrypts this page using the session key and forwards the
      decrypted page to its visualization engine. The Java applet is
      securely downloaded and activated as part of the page processing.
      Alternatively, a local pre-installed Java applet may be referenced
      and activated. In addition, either the downloaded page contains
      the IOTP based initialization data for the Java applet or the Java
      applet requests this from a special URL.
      11.  The consumer provides some input data, e.g., for payment
      instrument selection, which is driven by the Java applet.
      12.  Finally the consumer agrees to the payment of the selected
      goods with the chosen payment instrument and clicks on the pay now
      button. At this point all user input needs to be verified, e.g.,
      supplement of all required payment data.
      13.  On successful verification, the Java applet forwards the user
      data to its IOTP dialog services.
      14.  The IOTP dialog services generate the IOTP (Payment) request
      message using the IOTP message services.
      15.  The IOTP message is forwarded to the transport coupling,
      which may establish a new SSL secured connection with the Payment
      Handler (cf. 8 & 9) and sends the message to his IOTP aware
      application, using the current network connection and the socket
      API. Note that the Merchant and Payment Handler collapse by
      assumption.

   Access Layer
      16.  The network layer transmits the (encrypted) data.
      17.  The frame dialog ensures the complete and consistent
      transmission between the consumer's end system and the provider's
      computing center. The message may be used to set up some control
      mechanisms.

   Refinement Layer
      18.  The refinement layer performs formal verification. It
      transforms the IOTP formatted message into the application
      specific format, verifies the document formatting, validity, and
      security, and extends the application data with the results.
      19.  The application data is forwarded to the application
      services.

   The following insertion gives an example description of the
   application and data layers. They vary between the trading roles and
   even between providers of the same type. The description does not
   belong to the architecture.

   Application Layer

   The application layer implements the functionality of the actual
   electronic commerce applications which vary between the providers. In
   addition, a parameterized application monitor may be contained in the
   application.

   The application layer contains the following components:

   o  application monitor
   o  electronic commerce application

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Application Layer
     o  application monitor
       -  security (verification, authorization)
         -  verification result of document authenticity
         -  customer authorization
         -  anonymous access
       -  subsystem distribution (parameterized)
     o  electronic commerce applications
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 10: Application Layer's Components

   o  Application Monitor
      One component of the application monitor routes the initiated
      application connections to the application subsystems, supervises
      them, and deals with the application specific security and
      authorization. The presentation control monitor of the access
      layer triggers the application monitor.

   o  Subsystem Distribution
      This control function initiates and supervises the application
      connection to the application system (consumer account manager,
      order, payment, or billing system, etc.). It contains the
      following functionality:

      -  parameterized session memory
         stores the current (shopping/payment
         negotiation/payment/delivery) context, e.g., the relationship
         between goods, payments and consumers.

      -  routing of application connections and their supervision
         Partial functions may be realized by different application
         subsystems or they may run on different servers at different
         locations. The component manages the controlled initialization,
         termination, and supervision of application connections derived
         from the information of the initial IOTP request and final IOTP
         response.

      -  statistics and diagnosis
         The tasks are described in the previous section about the
         presentation control monitor. The respective components log the
         actions of the application monitor (logging of application
         progress and application errors)

   o  Application Specific Security

   This function includes the routing of successful authorized dialogs.
   Security modes are:

      -  authorized
         The application services can reference the verification result
         of the document security (signature, authentication). But they
         handle the application specific consumer authorization by
         themselves. This may involve the validity check of the
         consumer's account or of a payment chip card.
      -  without authorization
         There is no user information necessary because the service
         requires no security attribute (guest account). But the
         component may perform some checks on user supplied data, e.g.,
         syntax of email address and validity of the given domain name.

   o  Electronic Commerce Applications

   They comprise the provider specific functionality. The Existing
   Legacy System resp. Existing Payment Software and IOTP Middleware
   resp. IOTP Payment Bridge belong to this class.

   Data Layer

   The data layer consists of the following components:

   o  data access
      Routines for database access and data manipulation.

   o  data integrity
      The data integrity contains a transaction monitor and integrity
      verifications.

   o  data administration
      The functions storage, balance, update, and distribution belong to
      the administration class.

   The above progress example is continued:

   Refinement Layer
      20.  The refinement layer reports technical errors to the
      presentation control monitor, e.g., time-outs.
      21.  The refinement layer generates an IOTP response if it has
      received the correct response from the application services. Its
      security services sign (and encrypt) the IOTP response.

   End System Layer
      22.  The applet's IOTP message services request the data
      encryption and signature verification for the response from its
      security services.
      23.  The applet's IOTP dialog services enable IOTP dialogs and
      verify any optional authentication and initialization data.
      24.  The IOTP message services generate the next request (IOTP
      Payment Exchange).

   Access Layer
      25.  The frame dialog receives the message, verifies its relation
      with the current dialog, and forwards the data.

   Refinement Layer, Application Layer, Data Layer
      26.  The process coincides with the processing of the first IOTP
      message.

   Access Layer
      27.  The IOTP aware application sends the response and closes the
      IOTP dialog on payment completion or failure. The physical
      connection remains open.

   End System Layer
      28.  The Java applet processes the transaction response.

      29.  It takes the control and display the final payment status.
      30.  It passes the control back to the browser, redirects it to
      the respective net location, and terminates.

6.  TCP/IP - WWW, Java Implementation Variant

   The WWW variant of the Trading Architecture has specific requirements
   for the implementation that are implied by the open structure and
   established standards and tools of the Internet. The following table
   depicts the non-trivial relationship of these structures with the
   Trading Architecture. The table describes the components, standards,
   and products of the implementation variant.

   Layer        Component        Standard    Product
   End System  Presentation      IOTP        IOTP Wallet, Payment
   Layer       Software                      Extension
                                 XML         IOTP Wallet, e.g., Web
                                             browser extension
                                             (e.g. Java applet)
                                 Java        IOTP Wallet, e.g., Web
                                             browser extension
                                             (e.g. Java applet)
               Document Format   IOTP        IOTP Wallet, Payment
                                             Extension (and
                                             smartcard)
               Document          IOTP        IOTP Wallet, security
               Security          (smartcard) services (of financial
                                             service providers)
                                             inclusive chip card
                                             support
               Transport
               Services
                  Network        TCP/IP      TCP/IP socket support
                  Protocol       Socket      for the Windows & OS/2
                                             family, Macintosh
                                             system, and UNIX
                                             derivatives, e.g.,
                                             Windows WINSOCK.DLL
                                 HTTP        Web browser, IOTP
                                             Wallet
                                 HTML, XML   Web browser, IOTP
                                             Wallet
                                 IOTP        IOTP Wallet
                 Transmission    SSL         browser implemented SSL
                 Security                    functionality, SSL
                                             client solution for
                                             world wide full
                                             strength cryptography
   Network       Network         Internet    Internet/Online
   Layer         Services                    service provider
                 Network Access  Requirement Internet/Online
                 Procedure and   of the      service provider
                 User Management Internet
                                 Service
                                 Provider
   Access Layer  Transport
                 Services
                    Network      TCP/IP      TCP/IP support by
                    Protocol                 - packet filter
                                             - web server
                                             - ...
                    Transmission SSL         web server integrated
                    Security                 SSL functionality,
                                             specific SSL server
                                             solutions
                    Access       Firewall
                    Security
                                 Packet      router of firewall
                                 Filter
                                 (exterior)
                                 Application firewall
                                 Level
                                 Gateway
                                 Packet      router of firewall
                                 Filter
                                 (interior)
                 Presentation
                 Control Monitor             web server
                    Subsystem
                    Distribution
                    Frame        HTML, Java  web server
                    Dialog       ActiveX,
                                 JavaScript,
                                 Visual Basic
                    Presentation HTML, XML    web server
                    Native       HTML, XML    web server
                    Presentation
                    Optimization HTTP Cache   web server, http proxy
                    Transport    System       requirements for the
                    Information  Information  web server
                 Native Programs Java         self developed /
                                 JavaScript,  customized programs /
                                 ActiveX,     applets
                                 Visual Basic
   Refinement    Document Format IOTP         IOTP aware application
   Layer
                 Document        IOTP         IOTP aware application
                 Security                     security services:
                                              - digital signature
                                              - crypto API for RSA,
                                              - (certification /
                                                 registration
                                                 authority)
       Table 1: Implementation Variant  TCP/IP - WWW, Java, Server
   Station Solution

   The IOTP implementation variant does not recommend any specific Web
   server. Its implementation requires the distinction between the
   consumer's and the merchant's / deliverer's / Payment Handler's
   sphere.

6.1  Consumer's Sphere

   The following discussion distinguishes between two different types of
   end systems.

   A standard application may implement all services on its own. Solely,
   it has to fulfill the requirements of the IOTP protocol.
   Alternatively, it may use the functionality of a so-called IOTP
   kernel, in order to relieve the actual front-end application from the
   complex process of the parsing, analysis, verification, generation,
   and protection of IOTP messages. Parameters supplied by (preceding)
   IOTP messages influence the consumer's system behavior and
   appearance.

   A Web browser extension may also require an IOTP kernel, e.g., in
   order to provide full SSL security outside of USA and Canada. The
   usage of a local IOTP kernel is recommended even if an online loaded
   component - e.g., Java applet - may encode this extension. This
   decreases the size of the application dependent Java applet.
   Parameters supplied by (preceding) IOTP messages may customize such
   an applet, too. Alternatively, a fully customized applet may be
   supplied to the consumer.

   The detailed description of the IOTP kernel is outside of this
   discussion and needs to be formalized in an subsequent document.  The
   specification of the IOTP kernel aims at the subsequent
   implementation. Such an implementation may be distributed as an IOTP
   development kit using the Internet service providers in order to
   enable the rapid development of consumer products. Furthermore, the
   IOTP kernel may incorporate a Crypto API encapsulating the security
   services.

6.2  Provider's sphere

   A powerful server station with a decentralized operating system like
   UNIX may implement the access layer. Such a server station may be
   located at a computing center, at the Internet services provider,
   etc. It runs the following jobs:

   -  Web server
   -  SSL server
   -  IOTP Application Core

   The general cooperation of the IOTP Application Core and the Existing
   Legacy System is outside the scope of this document. However, the
   connection to particular Existing Payment Software is discussed in
   the next chapter. The IOTP Application Core may be a slim IOTP
   monitor (IOTP application level gateway) that forwards the IOTP
   documents to the actual IOTP Application Core located anywhere else
   in the demilitarized zone or interior network.

   Additional components may protect the server station against attacks
   from the Internet. Such products as well as the respective
   (consultation) services are highly available. Therefore, this
   document does not address these traditional network security risks.

   Any gateway in the interior net may convert the traffic between
   TCP/IP and other protocols. Herewith, IOTP documents can be
   transmitted to arbitrary IOTP systems.

IOTP Payment API

7.  Payment API

   The Internet Open Trading Protocol extends pure payment schemes like
   SET, SSL based payments, or CyberCash to a trading protocol, that
   deals with purchase orders, payment receipts, and delivery responses
   but does not replace of any payment method. Instead, it provides a
   wrapper for these payment specific protocols. Consequently, the IOTP
   aware application may reuse Existing Payment Software or may minimize
   the changes to these components. Therefore, the IOTP Application Core
   implements the IOTP transaction platform, IOTP transaction data
   management system, and user interface. But it defers the actual
   payment processing to the Existing Payment Software.

7.1  Introduction

   The following table sketches the four logical steps of many payment
   transactions. The preceding agreement about the goods, payment method
   and purchase amount is omitted.

   Payment State  Party             Behavior
   Mutual         Payment Handler   E.g., generation of
   Authentication                   identification request, solvency
                                    request, and some nonce
                  Consumer          E.g., responses to the requests,
                                    and generation of the own nonce
   Authorization  Payment Handler   Opening of the transaction,
                                    generation of the authorization
                                    request
                  Consumer          Reservation of the Consumer's
                                    e-money
                  Payment Handler   Acceptance or rejection of the
                                    authorization response
   Capture                          generation of the capture
                                    request
                  Consumer          Charge
                  Payment Handler   Acceptance or rejection of the
                                    e-money, closing of the payment
                                    transaction
   Reversal                         On rejection: general of the
                                    reversal data
                  Consumer          Receipt of the refund

   Some payment methods do not distinguish between authorization and
   capture. The optional transaction reversal applies on payment
   rejection / revocation. This model applies also to refunds, deposits,
   withdrawals, electronic cheque, direct debit, and money transfer.

   It seems to be important for the consumers' acceptance, that the same
   IOTP wallet supports different payment methods and the registration
   of new payment methods which might be achieved by a common Payment
   API. Payment Handlers will also benefit from such a Payment API that
   standardizes the connection to their legacy systems, if they offer
   payment services for multiple payment methods.

   The Payment API provides a standard method for exchanging payment
   protocol messages between the parties involved in a payment
   (resolution). The existence of a well defined Payment API enables
   payment software developers to bolt on their components to other
   developer's general IOTP Application Core. The former have to
   implement the IOTP Payment Bridge, too.

   In outline, the Payment API accepts as an input parameter the
   transformed payment protocol message received from the remote party
   and returns another payment protocol message to be sent back to the
   remote party. This continues between the two parties until the
   Payment Handler's Payment API signals the payment termination.

   The relationship between the API and a typical software architecture
   is illustrated in the following figure. The relationship between
   these components are arbitrary: One IOTP Application Core may manage
   multiple IOTP Payment Bridges, which may manage multiple Existing
   Payment Software components, which may manage multiple payment
   methods. Finally, each payment method may support multiple payment
   instruments. Vice versa, several IOTP Payment Bridges may share
   Existing Payment Software and even share payment methods.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   IOTP client (consumer)  <--------------->  IOTP server (merchant)
         ^                     Internet             ^
         | IOTP Payment                             | IOTP Payment
         |    API                                   |    API
         v                                          v
   IOTP/Payment Bridge                        IOTP/Payment Bridge
        ^                                           ^
        | Existing Payment APIs, e.g.,              |
        | SET, Mondex, etc.                         |
        v                                           v
   Existing Payment Software               Existing Payment Software
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 11: Relationship of the Components

   The next section lists several assumptions about the different
   software components. The next chapter illustrates the payment
   transaction progress and message flow for different kinds of
   transaction behavior. Chapters 9 to 11 contain the detailed
   description of the API calls and Chapter 12 elaborates the call back
   interface.

   When dealing with Merchants' or Delivery Handlers' IOTP aware
   applications, the payment related components are replaced by their
   Existing Legacy Systems and the IOTP Middleware. However, the
   discussion of non-payment interfaces (order management etc.) is
   deferred to future versions of this document.

7.2  Assumptions

   Any Payment API has to suit for a broad range of payment methods both
   software based like Credit Card SET or CyberCoin and chip card based
   like Mondex or GeldKarte. Furthermore, it should suit for mimicries
   of typical and traditional payment methods like money transfer,
   direct debit, deposit, withdrawal, and money exchange, however they
   are realized. It should support both payments with explicit consumer
   acknowledge and automatic (micro)payments, which have been consumer
   approved in advance.

   The Payment API considers the following transaction types of Baseline
   IOTP [RFC XXXX]:

   o  Baseline Purchase,
   o  Baseline Refund,
   o  Baseline Value Exchange,
   o  Baseline Withdrawal, and
   o  Baseline (Payment) Inquiry.

   First, the vision of the IOTP aware application's and its main
   components' capabilities are clarified. On the one hand, the Payment
   API should be powerful and flexible such that the IOTP Application
   Core really benefits from it. On the other hand, it should not be
   overloaded with stuff that is not supported by Existing Payment
   Software. Furthermore, the requirements of Consumers and Payment
   Handlers differ extremely on failure resolution and inquiry
   capabilities. Therefore, it is envisioned that the IOTP Application
   Core supports only basic inquiry mechanism while complex and payment
   method specific inquiries are deferred to the actual Existing Payment
   Software. Finally, the complete payment processing inclusive failure
   resolution support is deferred to the Existing Payment Software.

   The IOTP Application Core implements the generic and payment method
   independent part of the IOTP transaction processing and provides the
   suitable user interface. Focusing on the payment, it

   o  manages the registered IOTP Payment Bridges, inclusive their
   registration process,

   o  supports the Consumer's payment instrument selection preceding the
   payment request,

   o  invokes and requests additional payment specific support from the
   selected and registered Existing Payment Software through the IOTP
   Payment Bridge,

   o  initializes and terminates the Existing Payment Software through
   the IOTP Payment Bridge,

   o  requests authentication data from the Consumer,

   o  supervises the online transaction process and traces its progress,

   o  implements any payment transaction progress indicator,

   o  offers generic dialogs to the Existing Payment Software, e.g. pass
   phrase input, basic transaction inquiry, balance inquiry, brand
   selection payment acknowledge, payment instrument insertion, payment
   suspension / cancellation,

   o  validates (previously) received payment receipts and the status of
   (terminated) payment transactions,

   o  stores the transaction data and offers basic data base facilities
   and basic inquiry mechanisms for payment transactions,

   o  supports the invocation of the existing software modules in an
   interactive mode for further payment method specific transaction
   post-processing, and

   o  exports call back functions for use by the IOTP Payment Bridge or
   Existing Payment Software for progress indication or database access.

   In addition, the IOTP Application Core

   o  enables the inquiry of pending and completed payment transactions,

   o  manages the IOTP components and IOTP blocks exchanged during the
   transaction which may be referenced and accessed for the processing
   of subsequent messages, e.g., for signature verification. In
   particular, it stores named Packaged Content elements exchanged
   during payments.

   o  associates each IOTP transaction type with payment transaction(s)
   and each payment transaction with multiple payment parameters (IOTP
   Transaction Identifier, Trading Protocol Options, Payment Instrument,
   Offer Response, IOTP Payment Bridge, and Wallet Identifier). The
   latter association can be lowered to the Consumer Payment Identifier,
   IOTP Payment Bridge, and Wallet Identifier when the payment
   transaction has been successfully started.

   o  manages several kinds of identifiers, i.e., transaction, message,
   component, and block identifiers,

   o  provides a message caching mechanism,

   o  neglects failures at lower protocol layers except time-outs
   because they are handled by the appropriate protocol mechanisms,
   e.g., TCP/IP handles transmission errors.

   o  detects time-outs at the protocol and API level reflecting the
   communication with both the remote party and the local periphery,
   e.g., chip card (reader) may raise time-outs.

   o  defers payment specific error resolution to the Existing Payment
   Software. Mostly, they are solved from the IOTP Application Core's
   prospective by the extended exchange of Payment Exchange messages.
   The most significant failures arise from sudden unavailability or
   lapses of the local or opposing payment component.

   o  assumes that the IOTP Payment Bridge is a passive component of the
   payment system, i.e., it awaits any input data and generates one
   response to each request. In particular, it does neither recognize
   nor notify time-outs, necessarily.

   However, the IOTP Payment Bridge and Existing Payment Software do not
   have to rely on the IOTP Application Core's capabilities. E.g., they
   may implement several dialogs on their own or they may refuse the
   export of specific payment instruments at brand selection time and
   may defer this selection to the Check Payment Possibility step using
   their own user interface.

   The IOTP Payment Bridge's capabilities deal not only with actual
   payments from the Consumer to the Payment Handler but extend to the
   following:

   o  translation of messages between the formats of the IOTP
   Application Core and the Existing Payment Software. If one IOTP
   payment API call splits into multiple Existing Payment Software
   calls, it has to assemble their output to one IOTP payment API
   response.

   o  Consumer's payment instrument selection by the means of an
   unsecured 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).
   However, some payment methods may defer the selection of the payment
   instrument to the actual payment carrying-out or they 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 through simple insertion of the respective chip
   card into the chip card reader or they interrogate the inserted card
   and request an acknowledge (or selection) of the detected payment
   instrument(s).

   o  payment progress checks, e.g., is there enough funds available to
   carry out the purchase,

   o  balance inquiry, e.g. consumers may interrogate their chip card
   based payment instrument or remotely administered account in advance
   of a payment transaction acknowledge,

   o  IOTP Payment Receipt - more precisely its Packaged Content  -
   checks. Furthermore, it may support payment method specific Payment
   Receipt checks that are typically exchanged in IOTP Payment Scheme
   Components rather than in IOTP Payment Response Blocks or generated
   by chip cards.

   o  decoding of data contained within a brand or protocol specific
   IOTP Payment Receipt or actual payment method specific Payment
   Receipt into a format which can be displayed to the user or printed,

   o  cancellation of payment, even though it is not complete,

   o  suspension and resumption of payment transactions. One source of
   failure the Existing Payment Software has to deal with is the time-
   out of the network connection. For resolution, the IOTP Application
   Core may try the suspension with a view to later possible resumption.
   Alternatively, the IOTP Application Core may signal the transaction's
   cancellation. However, the existing software can not rely on correct
   suspensions / cancellations, e.g., when it shuts down, it has to
   consider any exceptions and to resolve inconsistencies.

     Another source of failure is lack of funds in which case the IOTP
   Application Core may signal the suspension of the current payment
   transaction. The consumer may download money and may resume the
   previous transaction.

   o  payment transaction status inquiry, so that the inquirer can
   determine the appropriate next step.

   o  inquiry on payment transactions. Particularly, the inquiry of
   transactions with specific transaction states should be supported.
   The IOTP Application Core may inquire and resolve pending
   transactions at startup. E.g., the computer system may crash due to
   power failure.

     The determination details of the inquired transaction data is up to
   the IOTP Payment Bridge. It may evaluate local databases, log files,
   chip cards, or remote account manager.

   o  recording the payment progress and status on a database. E.g.,
   information about pending payments can be used to assist their
   continuation when the next payment protocol message is received.

   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.

   Existing Payment Software may not provide full support of these
   capabilities. E.g., some payment protocols may not support or even
   prevent the explicit transaction cancellation at arbitrary phases of
   the payment process. Therefore, the IOTP Payment Bridge has to
   implement at least skeletons that signal any lack of support back to
   the caller by the use of error codes (see below).  The Existing
   Payment Software's capabilities vary extremely. It

   o  supports the actual online payment transaction,

   o  resolves most types of payment specific failures,

   o  provides hints for out-of-band failure resolution on failed
   immediate resolution,

   o  may implement transaction data management and inquiry mechanisms
   ranging from no transaction recording, last transaction recording,
   chip card deferred transaction recording, simple transaction history
   to very sophisticated implementations with flexible user inquiry
   capabilities. The latter is required by Payment Handlers for easy and
   cost effective failure resolution.

   o  may rely on the generic dialogs of the IOTP Application Core.
   However, particular (business) rules or payment aspects may require
   additional dialog boxes or their dedicated appearance / structure /
   content, may prohibit the unsecured export of payment instruments, or
   may prescribe the pass phrase input under its own control.

   The API must consider both successful and failed payments. On time-
   out failure, each party requires a reliable analysis of the current
   payment transaction status and hints about the possible resolution
   alternatives. Common payment revocation by (e)mail, fax, or voice
   telephone becomes useless if the content of any chip card needs to be
   modified.

8.  Message Flows

   The Payment API calls are distinguished between general and payment
   transaction related inquiry calls, brand selection and payment
   transaction related calls, payment instrument customer care related
   and other calls.

   o Brand Compilation Related API Calls

   "Find Accepted Payment Brand" identifies the accepted payment brands
   for the indicated currency amount.

   "Find Accepted Payment Protocol" identifies the accepted payment
   protocols and returns payment scheme specific packaged content for
   brand selection purposes.

   "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.

   "Authenticate" forwards any payment scheme specific authentication
   data to the IOTP Payment Bridge for processing.

   "Check Authentication Response" verifies the returned payment scheme
   specific authentication response value.

   "Cancel Payment" terminates the payment transaction immediately. This
   API function is a short cut to some specific "Change Process State"
   call.

   o Brand Selection Related API Calls

   "Find Payment Instrument" identifies which instances of a payment
   instrument of a particular payment brand are available for use in a
   payment.

   "Find Payment Protocol" identifies which payment protocols are
   supported by a specific payment instrument, resp. payment brand.

   "Check Payment Possibility" checks whether a payment instrument is
   able to perform a payment.

   "Quit Payment Instrument" terminates a payment transaction, even
   before the transaction has been initiated towards the Payment Handler
   (short cut for "Change Process State").

   "Authenticate" (cf. Brand Compilation Related API Calls)

   o Payment Transaction Related API Calls

   "Start or Resume Payment Consumer/Payment Handler" initiate or resume
   a payment transaction. There exist specific API calls for the two
   trading roles Consumer and Payment Handler.

   "Continue Process" forwards payment scheme data to the Existing
   Payment Software and returns more payment scheme data for
   transmission to the counterparty.

   "Change Process State" changes the current status of payment
   transactions. Typically, this call is used for successful/less
   termination of suspension.

   oGeneral Inquiry API Calls

   "Inquire Payment Log" interrogates the payment log for different
   kinds of payments. The interrogation is adjustable by multiple
   parameters.

   "Remove Payment Log" removes one specific entry from the Payment Log.

   "Payment Instrument Inquiry" retrieves the properties of Payment
   Instruments.

   "Inquire Pending Payment" reports whether the IOTP Payment Bridge has
   pending transactions.

   o Payment Transaction Related Inquiry API Calls

   "Check Payment Receipt" checks the validity of IOTP Payment Receipts,
   returned by an "Inquire Process State" API call. It is used to check
   that the payment receipt is consistent and/or matches the respective
   payment transaction. Typically, it is used by the Consumer during the
   final processing of payment transactions. However, this check might
   be advantageous both for Consumers and Payment Handlers on failure
   resolution.

   "Expand Payment Receipt" expands IOTP Payment Receipt Packaged
   Contents and payment specific payment receipts into a form which can
   be used for display or printing purposes.

   "Inquire Process State" responds with the payment status and the IOTP
   Payment Receipt Component. Normally, it is called by the Payment
   Handler for final processing of the payment transaction.

   "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 on Consumer initiated inquiry
   requests by the Payment Handler. It provides the payment scheme
   specific content of the Inquiry Response Block.

   "Continue Process" and Change Process State" (cf. Payment Transaction
   Related API Calls)

   o Other API Calls

   "Manage Payment Software" enables the immediate activation of the
   Existing Payment Software. Further user input is under control of the
   Existing Payment Software.

   "Access Data Base" provide a general data base interface to the IOTP
   Payment Bridge. They can rely on the IOTP Application Core
   capabilities for reliable data management.

   "Call Back" Function provides a general interface for 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.

   API function                  Consumer  Payment Handler  Merchant
   Find Accepted Payment Brand                                 +
   Find Accepted Payment Protocol                              +
   Find Payment Instrument          +
   Find Payment Protocol            +
   Get Payment Initialization Data                             +
   Cancel Payment                                              #
   Check Payment Possibility        +
   Quit Payment Instrument          #
   Start Payment Consumer           +
   Start Payment Payment Handler                  +
   Continue Process                 +             +
   Inquire Process State            +             +
   Change Process State             +             +            ?
   Check Payment Receipt            +             ?
   Inquire Authentication Challenge                            #
   Remove Payment Log               #             #            #
   Authenticate                     +
   Check Authentication Response                               #
   Resume Payment Consumer          +
   Resume Payment Payment Handler                 +
   Expand Payment Receipt           #             ?
   Inquire Payment Log              #             #
   Payment Instrument Inquiry       ?
   Inquire Pending Payment          #             #
   Start Payment Inquiry            ?
   Inquire Payment Status                         ?
   Manage Payment Software          #             o            ?
   Access Database                  #             #            #
         Table 2: Mapping between API Functions and Trading Roles

   The next sections sketch the relationships and the dependencies of
   the API calls. They provide the informal description of the progress
   alternatives and describe the communication and synchronization
   between the general IOTP Application Core and the payment scheme
   specific modules.

8.1  Authentication Documentation Exchange

   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. Resp. Response()               <-IPB
                   Create and transmit Authentication Status Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 12 Authentication Message Flows

   1.  (Authenticator Process) The IOTP Payment Bridge (IPB) is asked
   for one or multiple authentication challenge values ("Inquire
   Authentication Challenge"). Each value is encapsulated in an
   Authentication Request Component which forms the final Authentication
   Request Block. If the authenticator intends to submit a choice of
   authentication algorithms to the authenticatee, it has to issue
   several API call to the IOTP Payment Bridge.

     Note that the interface is limited to the response of one algorithm
   per call. If the IOTP Application Core provides a choice algorithm,
   this choice should be reduced successively by the returned algorithm.
   The IOTP Payment Bridge notifies the IOTP Application Core with each
   newly registered Payment Instrument about the supported
   authentication algorithms by their names.

   2.  The Authenticatee's IOTP Application Core checks whether the IOTP
   transaction type actually supports the authentication process. If
   Authentication Request Components have been provided, they are
   checked in some order. 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 itself or some of the
   registered IOTP Payment Bridges. These system components might be
   requested for the responses to the supplied challenges, sequentially.
   The search stops with the first successful response.

     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
   Authentication Request Blocks without any content element. On
   failure, the authentication request may be retried, or the whole
   transaction might be suspended or cancelled.

   3.  (Authenticator Process) The IOTP Application Core checks the
   presence of the Authentication Response Component in the
   Authentication Response Block and forwards its content to the
   "selected" IOTP Payment Bridge for verification ("Check
   Authentication Response"). Otherwise, the presence of the
   Authenticatee's organisational data is checked. Any verification must
   succeed in order to continue the transaction.

8.2  Brand Compilation

   An example of how the functions in this document are used together so
   that the Merchant can compile the Brand List Component, generate the
   Payment Component, and adjust the Order Component with payment scheme
   specific packaged content.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   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()        -> 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/Currency from those
                   that will work and generates Brand Selection
                   Component - at least implicitly
                 On brand dependent transaction
                 |  Transmit Brand Selection Component
   Merchant      On brand dependent transaction
                 |  Get Payment Initialization Data()        -> 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 13 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.

   2.  The IOTP Application Core inquires 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 Organisational 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.

     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 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. 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.

     Note that this complex process might be optimized by any pre-
   compilation of Brand Lists. At startup the IOTP Application Core
   might

      o  perform multiple dummy inquiries on the registered IOTP
         Payment Bridges,

      o  exclude some IOTP Payment Bridges from subsequent inquiries,

      o  analyze the relationships between the items, and

      o  create patterns of the Brand Lists.

     For this purpose it is assumed that the items either vary on each
   inquiry or are static.

   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
   "equal" items returned by IOTP Payment Bridge function calls are
   shared due to the extensive linking capabilities within the Brand
   List Component. However, the compilation must consider several
   aspects in order to prevent conflicts - sharing detection might be
   textual matching:

      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  Transaction/Brand/Protocol/Currency Amount (in)dependent data
      might share the same Packaged Content.

      o  The Consumer's IOTP Application Core transparently passes the
      packaged contents to the IOTP Payment Bridges which might not be
      able to handle payment scheme data of other payment schemes
      accurately.

     The details about the rules and mechanisms, how this could be
   accomplished is out of the scope of this document. With other words,
   this document does not define further restrictions 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:

      o  All payment alternatives share the attribute values and
      contents of the subsequently generated Payment and Order
      Component.

      o  The subsequently generated data does not depend on any
      BrandSelXInfo 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 Offer Response Block. Optionally, the IOTP
   Application Core might request the current process state of the IOTP
   Payment Bridge and use the returned status to infer the order status
   which is added to the Offer Response Block. Alternatively, IOTP
   Application should determine the order status on its own.

     As in step 6, the details about the rules and mechanisms, how this
   could be accomplished is out of the scope of this document.

   8.  The IOTP Application Core compiles the IOTP TPO message adding
   all compiled blocks and transmits the message to the Consumer. The
   IOTP Application Core terminates if an Offer Response Block has been
   created.

   9.  The Consumer performs the Brand Selection Steps (see below) and
   responds with a TPO Selection Block if no 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 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.

   Any error during this process raises an IOTP Error Block.

8.3  Brand Selection

   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). An example of how the functions
   in this document are used together so that the Consumer can determine
   which Brand/Currency to use is illustrated in the figure below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      Merchant generates Brand List(s) containing
                   Brands, Payment Protocols and Currency Amounts
                 On brand independent transactions
                 |  Merchant generates Offer Response Block
   Consumer      For each accepted Payment Brand
                 |  Find Payment Instrument(B,C)              -> IPB
                 |  Find Payment Instrument Response (PI*)    <- IPB
                 For each returned Payment Instrument/Brand
                 |  Find Payment Protocol(B,PI,C)             -> IPB
                 |  Find Payment Protocol Response(P*)        <- IPB
                 Consumer selects Brand/Currency/Payment Instrument
                   from those that will work and generates Brand
                   Selection Component
                 For the Selection
                 |  Get Payment Initialization Data(B,C,PI,P) -> IPB
                 |  Get Payment Initialization Data Response()<- IPB
                 On brand dependent transaction
                 |  Generate and transmit TPO Selection Block
   Merchant      On brand dependent transaction
                 |  Merchant checks Brand Selection and generates
                 |  and transmits Offer Response Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 14 Brand Selection Message Flows

   Note that the figure and the following description show one of two
   variants of the inquiry of valid payment instruments. Alternatively,
   the IOTP Application Core might enrich the "Find Payment Instrument"
   input parameter list with the payment protocols that are accepted by
   the Merchant. In this case all calls to "Find Payment Protocol"
   become superfluous and might be skipped. However, the IOTP
   Application Core must call "Find Payment Instrument" for every valid
   combination of payment brands, payment protocols, and IOTP Payment
   Bridges.

   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 subsequent processing
   switches to the IOTP based form by the activation of the Merchant's
   IOTP aware application.

   2.  The IOTP Application Core compiles the Trading Protocol Options
   Block which contains the Brand List Component(s) enumerating
   Merchant's accepted payment brands and payment protocols and
   initiates the Brand Selection process.

   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). The Consumer's IOTP
   Application Core

   o  infers the accepted payment brands, payment protocols, payment
   direction, currencies, payment amounts, any descriptions etc., and
   their relationships from the IOTP message,

      o  determines the registered IOTP Payment Bridges,
      o  inquires general payment brand support and the known payment
      instruments from each registered IOTP Payment Bridge for each
      accepted payment brand and currency ("Find Payment Instrument").
      However, some IOTP Payment Bridges may refuse payment instrument
      distinction.
      o  inquires payment protocol support from each registered IOTP
      Payment Bridge that has acknowledged any of the accepted payment
      brands ("Find Payment Protocol"). The payment protocol support may
      differ between payment instruments if the IOTP Payment Bridge
      supports payment instrument distinction.

     The IOTP Application Core must provide wallet identifiers, if they
   are required by the IOTP Payment Bridges which signal their need by
   specific error codes (see below). These API calls are used to infer
   the payment alternatives at the startup of any payment transaction
   (without user unfriendly explicit user interaction).

     It is recommended that the IOTP Application Core manages wallet
   identifiers. But for security reasons, it should manage pass phrases
   in plain text only in runtime memory. Developers of IOTP Payment
   Bridges and payment software modules should provide a thin and fast
   implementation - without lengthy initialization processes- for this
   initial inquiry step.

   4.  The IOTP Application Core

      o  intersects the Consumer's payment capabilities with the
      Merchant's accepted payment brands and currencies,
      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  requests the Consumer's choice or derives it automatically from
      the configured preferences.

     The management / resolution of unavailable IOTP Payment Bridges
   during the previous inquiry process is up to the IOTP Application
   Core. It may skip these IOTP Payment Bridges or may allow user
   supported resolution. It may also offer the registration of new
   payment instruments.

   5.  The Consumer's payment instrument / brand selection ties one IOTP
   Payment Bridge with the subsequent payment transaction. The IOTP
   Application Core interrogates this IOTP Payment Bridge, whether the
   payment can proceed with success ("Check Payment Possibility"). At
   this step, the IOTP Payment Bridge may issue several signals, e.g.,

      o  payment can proceed immediately,
      o  required peripheral inclusive some required physical payment
      instrument (chip card) is unavailable,
      o  remote party is not available,
      o  wallet identifier or pass phrase is required,
      o  expired payment instrument (or certificate), insufficient
      funds, and
      o  physical payment instrument unreadable.

     In any case except the first one, the user should be notified and
   offered accurate alternatives. Most probably, the user might be
   requested

      o  to resolve the problem, e.g. insertion of another payment
      instrument, verification of periphery,
      o  to skip this check and to proceed (assuming its success),
      o  to cancel the whole transaction, or
      o  to suspend the transaction, e.g., initiating a nested
      transaction.

     If the payment software implements payment instrument selection on
   its own, it may request the Consumer's choice at this step.

     If the check succeeds, it returns several 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 neglected in the figure above.

   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 Offer Response Block. The Merchant will then
   respond with an Offer Response Block (following the aforementioned
   compilation rules).

8.4  Successful Payment

   An example of how the functions in this document are used together to
   effect a successful payment is illustrated in the figure below.
   Technically, two payments happen during IOTP Value Exchange
   transactions.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Consumer(Amount,[PS0]...)    -> IPB
                   Start Payment Cons. Res.([PS1], CS=Cont.)  <- IPB
                   Create and transmit Payment Request Block
   Payment Handler Start Payment Pay. Handler(Amount, [PS1])  -> IPB
                   Start Payment PH Response(PS2, CS=Cont.)   <- IPB
                   Create and transmit Payment Exchange Block
   Consumer        Continue Process(PS2)                      -> IPB
                   Continue Process Response(PS3, CS=Cont.)   <- IPB
            ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
   Payment Handler Continue Process Response([PSn], CS=End)   <- IPB
                   Inquire Process State()                    -> IPB
                   Inquire Proc. State Resp.(State, Receipt)  <- IPB
                   Create and transmit Payment Response Block
                   Terminate transaction, actively
                   |  Change Process State(State)             -> IPB
                   |  Change PS Response(State=CompletedOK)   <- IPB
   Consumer        On receipt of final payment scheme data
                   |  Continue Process(PSn)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Check Payment Receipt(Receipt)             -> IPB
                   Check Payment Receipt Response()           <- IPB
                   Change Process State(State)                -> IPB
                   Change PS Response(State=CompletedOk)      <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 15 Example Payment Message Flows

   1.  After Brand Selection and receipt of the IOTP Offer Response
   Block, the Consumer has to agree to the payment transaction's
   continuation. The agreement may be explicit per transaction or may
   base on configured preferences or pre-authorizations for specific
   payment limits. The Consumer may also decide to suspend or cancel the
   continuation of the IOTP transaction. However, this suspension has to
   be managed by the IOTP Application Core on its own because no payment
   transaction has been actually opened. No IOTP messages are sent to
   the counterparty if the payment stops.

     It is assumed, that generally the following payment process
   continues with minimal user (Consumer and Payment Handler)
   interaction and that it is controlled by the IOTP Application Core
   and 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:

      o  payment brand and its description from the selected Brand
      Element of the Brand List Component,
      o  payment instrument from preceding inquiry step,
      o  further payment parameters (currency, amount, direction,
      expiration) from the selected Currency Amount element, Brand List
      Component, and Payment Component of the IOTP Offer Response Block,
      o  payment protocol from the selected Pay Protocol Element,
      o  order details contained in the Order Component which might be
      payment scheme specific,
      o  payment scheme specific data inclusive payment protocol
      descriptions from the Protocol Amount Element, and Pay Protocol
      Element, and
      o  payment scheme specific data inclusive payment protocol
      descriptions, in which the name attribute includes the prefix as
      "Payment:" from the Trading Role Data Component.

     Generally, this request repeats most checks of the "Check Payment
   Possibility" request due to lack of dependencies between both
   requests, e.g. availability check of periphery, pass phrase
   supplement. There might be a significant delay between both API
   requests. The function may return further payment scheme specific
   data being considered as payment specific initialization data for the
   Payment Handler's IOTP Payment Bridge. If the payment software
   implements payment instrument selection on its own, it may request
   the Consumer's choice at this step.

     The IOTP Payment Bridge reports lack of capability quite similar 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 he must not skip this API request. The
   IOTP Application Core might reissue the API request on user
   indication.

     Developers of payment modules may decide to omit payment instrument
   related checks like expiration date or refunds sufficiency, if they
   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 call, too. The IOTP Application Core should store these
   values. The IOTP Payment Bridge may also store these values and
   dispense with their supplement on subsequent payment related API
   calls. The IOTP Application Core may issue the following API calls
   without these values, but it has to supply them on IOTP Payment
   Bridge request and to reissue the API call. It is recommended that
   the IOTP Application Core stores plain text pass phrases only in
   runtime memory and that IOTP Payment Bridges renew their requests for
   pass phrases after "Change Process State" API calls.

     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.

   3.  The Payment Handler's IOTP Application Core opens the payment
   transaction using the "Start Payment Payment Handler" API call. 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 Payment Scheme Data component and the Brand
   Selection Info Elements are passed to the API function.

     On success, the Payment Handler's IOTP Payment Bridge responds with
   payment scheme data. On failures, it has to resolve any problems on
   its own or to give up aborting the payment transaction because the
   Payment Handler operates a non- interactive server application.
   However, the Consumer may restart the whole payment transaction. But
   the payment log file should reflect any trials of a payments.

     In any case, the Payment Handler informs the Consumer about the
   current Process State using the IOTP Payment Response or IOTP Error
   Block.

     The "Start Payment Payment Handler" call might return the
   Continuation Status "End" which leads to the continuation with Step
   7.

   4.  The IOTP Application Core verifies the presence of the Payment
   Exchange Block in the IOTP message and passes the contained payment
   scheme specific data to the active IOTP Payment Bridge ("Continue
   Process") which returns the next Payment Scheme Component.

     The Payment Scheme Component is encapsulated in a Payment Exchange
   Block and transmitted to the 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 active IOTP Payment Bridge ("Continue Process")
   which returns the next Payment Scheme Component for encapsulation and
   transmission to the Consumer.

   6.  The payment process continues with IOTP Payment Exchange Block
   exchanges, carrying the specific payment scheme data. Each party
   submits the embedded payment scheme data transparently to the active
   IOTP Payment Bridge by the Continue Process API call, wraps the
   returned payment scheme data into an IOTP Payment Exchange Block, and
   transmits it to the counterparty.

     However, the processing of the payment scheme data may fail for
   several reasons 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 counterparty.

   7.  Eventually, the Payment Handler's IOTP Payment Bridge recognizes
   the termination of the payment transaction and reports this by the
   continuation status "End". 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 data in an IOTP Payment Response Block and transmits this
   block to the Consumer.

     However, these API calls may fail or any API response might be
   incomplete (lack of payment receipt). Then the Consumer has to be
   notified about the failed processing by an IOTP Error Block.

     Finally, the Payment Handler terminates the payment transaction
   with the "Change Process State" API call without awaiting any
   response from the Consumer. Further failures functions are not reported to the
   Consumer.

     It might be possible used together so that
   the Consumer's IOTP Payment Bridge has
   returned the previous payment scheme data with the continuation
   status "End". In this case, Merchant can (1) compile the Payment Handler must not supply any
   further payment scheme data, because it will be rejected by Brand List Component, (2) generate
   the
   Consumer's IOTP Payment Bridge. Note that the genuine continuation
   status is not exchanged between the Consumer Component, and (3) adjust the Payment Handler.

   8.  The Consumer passes the optional Order Component with
   payment scheme data and the
   payment receipt to the appropriate specific packaged content.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      For each registered IOTP Payment Bridge by "Continue
   Process" and "Check Payment Receipt" API calls. Finally, the
   transaction is terminated with the "Change Process State" API call
   which verifies the reported payment status with the local one and
   signals any inconsistencies. Inconsistencies and the status text
   should be displayed to the Consumer.

     At this point, payment transactions have been closed by the
                 |  Find Accepted Payment
   Handler. Therefore, failures have to be resolved locally or outside
   the payment transaction.

8.5 Brand()             -> IPB
                 |  Find Accepted Payment Inquiry

   In Baseline IOTP, Brand Response (B*) <- IPB
                 |  Find Accepted Payment inquiries are initiated by the Consumer in
   order to verify the current payment progress and process state at the
   remote Protocol(B1)        -> IPB
                 |  Find Accepted Payment Handler. The next figure shows the message flow of a
   Consumer initiated payment inquiry.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Protocol Res.(P1*)  <- IPB
                 |  . . .
                 |  Find Accepted Payment Inquiry() Protocol(Bn)        -> IPB
                   Start
                 |  Find Accepted Payment Inquiry Response([PS1]) Protocol Res.(Pn*)  <- IPB
                 Create one Brand List Component, ideally sharing
                   common Brand, Protocol Amount, Currency Amount,
                   and transmit Inquiry Request Pay Protocol Elements
                 Create Trading Protocol Options Block
                 On brand independent transactions
                 |  Create Brand Selection Component, implicitly
                 |  Get Payment Handler Inquire Payment Status([PS1]) Initialization Data(B1,P1)   -> IPB
                   Inquire
                 |  Get Payment Status Res.(State, [PS2]) Initialization Data Res.()   <- IPB
                 |  Optionally
                 |  |  Inquire Process State()               -> IPB
                 |  |  Inquire Process State Response(State) <- IPB
                 |  Create and transmit Inquiry Offer Response Trading Block
                 Transmit newly created Block(s)
   Consumer        If Payment Scheme Data present      Consumer selects Brand (Bi)/Currency/Protocol (Pj)
                   from those that will work and generates Brand
                   Selection Component - at least logically
                 On brand dependent transaction
                 |  Continue Process(PS2)  Transmit Brand Selection Component
   Merchant      On brand dependent transaction
                 |  Get Payment Initialization Data(Bi,Pj)   -> IPB
                 |  Continue Process Response(CS=End)  Get Payment Initialization Data Res.()   <- IPB
                   Change
                 |  Optionally
                 |  |  Inquire Process State(State) State()               -> IPB
                   Change
                 |  |  Inquire Process State Response(State') Response(State) <- IPB
                 |  Create Offer Response Block
                 |  Transmit newly created Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                 Figure 16 Remote Process State Inquiry 3 Brand Compilation Message Flows

   1. The Consumer might initiate a payment inquiry once the payment
   transaction has been opened by the IOTP Application Core, i.e., 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 respective IOTP Payment Bridge using Merchant's commerce server controls the "Start
   Payment Inquiry" API request. Erroneous API responses should be
   reported to shopping dialog with
   its own mechanisms until the Consumer and valid alternatives (typically retry and
   cancellation) should be presented by the IOTP Application Core.

     Generally, this request performs checks out the complete initialization, e.g.
   availability check of periphery or pass phrase supplement. shopping cart
   and indicates the payment intention. The IOTP
   Payment Bridge reports lack notion shopping subsumes any
   non-IOTP based visit of capability quite similar to the "Check
   Payment Possibility" request Merchant Trading Role's (which subsumes
   Financial Institutes) web site in order to negotiate the IOTP Application Core.

     If content of
   the IOTP Payment Bridge requests wallet identifiers or pass
   phrases anywhere during Order Component. The subsequent processing switches to the inquiry process, they should be requested
   IOTP based form by this API call, too. the activation of the Merchant's IOTP aware
   application.

   2. The IOTP Application Core should store these
   values. The inquires the IOTP Payment Bridge may also store these values level trading
   parameters (Consumer's shopping identifier, payment direction,
   initial currency amounts, discount rates, Merchant's and
   dispense with their supplement on subsequent inquiry related API
   calls. Delivery
   Handler's Net Locations, Non-Payment Handler's Organisational Data,
   initial order information, ....).

   3. The registered IOTP Payment Bridges are inquired by the IOTP
   Application Core may issue about the following API calls
   without these values, but it has to supply them on IOTP accepted payment brands ("Find Accepted
   Payment
   Bridge request and to reissue Brand"). Their responses provide most of the API call. For security reasons, attribute values
   for the compilation of the Brand List Component's Brand Elements. The
   IOTP Application Core should store plain text pass phrases only in
   runtime memory and 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 immediately solved by the IOTP Application Core should renew their
   requests for pass phrases after any "Change Process State" be logged
   - this applies also to the subsequent API call.

     The calls of this section. In
   this case, the IOTP Application Core encapsulates any Payment Scheme Component
   in creates an IOTP Inquiry Request Error Block and submits
   (hard error), transmits it to the Payment
   Handler.

   2. Consumer, and terminates the
   current transaction.

   4. The Payment Handler analyses IOTP Application Core interrogates the Inquire Request Block, maps IOTP Payment Bridges
   for each accepted payment brand about the
   Transaction Identifier to supported payment related attributes (Brand, Consumer
   and Payment Handler protocols
   ("Find Accepted Payment Identifiers), 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 forwards Pay Protocol Elements. Furthermore, the request to
   organisational data about the appropriate IOTP Payment Bridge ("Inquire Payment Status"). Handler is returned. The IOTP
   Application Core transforms the response to an Inquiry Response
   Block and transmits it to the Consumer.

   3.  On receipt of might optionally match the respective IOTP Inquiry Response Block returned payment brands
   with Merchant's general preferences.

    Alternatively, the
   Consumer's IOTP Application Core submits might skip the calls of
   "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
   Accepted Payment Protocol" call without any encapsulated payment
   scheme specific data to Brand given on the input
   parameter list. In this case, the IOTP Payment Bridge for verification
   ("Continue Process").

   4. responds on 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.

   6. The IOTP Application Core passes compiles the reported payment status
   (except textual descriptions) to Brand List Component(s) and
   the IOTP Payment Bridge ("Change
   Process State") for verification purposes and payment status change.
   The Trading Protocol Options Block. It is recommended that
   "equal" items returned by IOTP Payment Bridge reports any inconsistencies as well as the
   final payment status function calls are
   shared due to the IOTP Application Core. Any additional
   information that may be of interest for extensive linking capabilities within the Consumer has Brand
   List Component. However, the compilation must consider several
   aspects in order to prevent conflicts - sharing detection might be
   displayed by
   textual matching (after normalization):

      o  Packaged Content Elements contained in the IOTP Payment Bridge or Existing Brand List Component
      (and subsequently generated Payment Software on
   their own.

8.6  Abnormal Transaction Processing

8.6.1  Failures and Cancellations

   The IOTP specification distinguishes between several classes of
   failures:

   o  Business Order Components) might be
      payment scheme specific and technical errors
   o  Error depth might depend on transport, message and block level each other.

      o  Transient errors, warnings, and hard errors.

   Any (Payment) API has to deal with Currently, IOTP lacks precise rules for the receipt content of failure
   notifications from and failure responses to the IOTP Application
   Core. The interface between
      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 and transparently passes the
      Packaged Content Elements to the IOTP Payment Bridge is mostly inherited from the genuine protocol. I.e.,
   business errors are reported by status components in normal response
   blocks while technical errors are signaled by error components in
   dedicated error blocks.

   Cancellations are specific business errors Bridges which might
      not be initiated by each
   trading party.

   In preference able to slim interfaces, the handle payment API introduces one
   additional error flag for business error indication - errors can scheme data of other payment
      schemes, accurately.

    The rules and mechanisms of how this could be
   returned by every API function. On receipt accomplished are out
   of the scope of this flag, document. Furthermore, this document does not
   define any further restriction to the IOTP specification.

   7. The IOTP Application Core has to infer determines whether the details of IOTP message can
   be enriched with an Offer Response Block. This is valid under the business error using
   following conditions:

      o All payment alternatives share the API function "Inquire Process State".

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Issue some API request                     -> IPB
                   Error Response(Error Code)                 <- IPB
                   On "Business Error" response
                   |  Inquire Process State()                 -> IPB
                   |  Inquire P.S. Resp.(State, Receipt)      <- IPB
                   Determine Local Behavior
                   If Status Change needed
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State')   <- IPB
                   If Counterparty notification required
                   |  Create Error or Cancel Block (, add to next
                      message, ) attribute values and transmit it to counterparty
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                     Figure 17 Error Response from IPB

   The specific Completion Codes "ConsCancelled", "MerchCancelled", Packaged
      Content Elements of the subsequently generated IOTP Payment and
   "PaymCancelled" - returned by "Inquire Process State" - determine
      Order Components.

      o The subsequently generated data does not depend on any IOTP
      BrandSelInfo Elements that might be reported by the Cancel consumer
      within the TPO Selection Block has to be created instead of an Error Block.
   The rules for 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 determination of IOTP Payment Bridge ("Get Payment Initialization Data")
   and compile the behavior of IOTP Offer Response Block.

    Optionally, the IOTP Application Core, particularly the response to Core might request the counterparty is
   given in current
   process state from the IOTP specification.

   Vice versa, failures, cancellations, Payment Bridge and even success's are always
   reported add the inferred order
   status to the IOTP Payment Bridge by Offer Response Block. Alternatively, IOTP
   Application might determine the API function "Change
   Process State". This API function is used both for order status change on its own.

    As in step 6, the rules and
   consistency checking. Any suspicion mechanisms of inconsistency should how this could be
   reported by
   accomplished are out of the scope of this document.

   8. The IOTP Payment Bridge for display by Application Core compiles the IOTP TPO Message including
   all compiled IOTP Blocks and transmits the message to the Consumer.
   The IOTP Application Core.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Error Block or Cancel Core terminates if an IOTP Offer Response Block Received
                   If Status Change required
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State')   <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                    Figure 18 Error Notification to IPB
   has been created.

   9. The processing of 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 transactions might temporarily be hampered
   by intermediate failures without significant influence 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
   layer. Internal failures Application Core
   might be resolved within access the genuine payment
   scheme. However, final failures or cancellations have to be reported
   at current process state of the IOTP layer.

   Finally, communication time-out and heavily faulty communication
   channels may disable the transaction. Any components may implement
   time-out recognition and use the aforementioned API mechanisms Payment Bridge for
   the notification compilation of any status change. However, time-outs do not only
   appear on communication with the remote party. Even local components,
   like chip card readers or order status.

   Any error during this process raises an IOTP Payment Bridges, may raise time-outs Error Block.

2.3  Brand Selection

    This section describes the steps that need to be resolved. The Consumer's IOTP Application Core should
   notify happen mainly after the Consumer about
   Merchant's Brand Compilation (in a brand independent transaction).
   However, these steps might partially interlace the resolution alternatives, i.e., retry,
   suspension, previous process
   (in a brand dependent transaction).

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Merchant      Merchant generates Brand List(s) containing
                   Brands, Payment Protocols and cancellation.

8.6.2  Resumption 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 resumption may apply at different steps of a
   payment transaction:

   o  Due to different time-out values
                 |  Generate and transmit TPO Selection Block
   Merchant      On brand dependent transaction
                 |  Merchant checks Brand Selection and generates
                 |  and transmits Offer Response Block
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 4 Brand Selection Message Flows

   1. The Merchant's commerce server controls the payment transaction may not
   have been suspended by shopping dialog with
   its own mechanisms until the counterparty. Therefore, Consumer checks out the API callee
   has to deal with pending shopping cart
   and suspended indicates his payment transactions.

   o  IOTP Payment Exchange and intention. The subsequent processing
   switches to the IOTP Payment Request Blocks may be
   received based form by the Payment Handler on resumption. Additionally, the
   payment transaction may not have been created at the Payment Handler.
   In that case, the "Resume Payment Payment Handler" API function
   responds with a hard error indicating activation of the required "Start Payment
   Payment Handler" API call.

   o Merchant's
   IOTP aware application.

   2. The IOTP Application Core may defer any payment tracing
   responsibilities to compiles the IOTP Payment Bridge and may not be able to
   distinguish between Trading Protocol
   Options Block which contains the continuation IOTP Brand List Component(s)
   enumerating Merchant's accepted payment brands and resumption of payment
   transactions. Either, protocols
   and initiates the Brand Selection process.

   3. This first IOTP Payment Bridge API functions "Start
   Payment Payment Handler" and "Continue Process" implement both cases message activates the Consumer's IOTP aware
   application, e.g., the Web browser invokes a helper application
   (e.g., Java applet or they signal external application). Its IOTP Application
   Core

   o infers the required explicit accepted payment resumption by error code
   responses ("Business Error"). Further analysis of the current brands, payment
   state ("Inquire Process State") should return the value Suspended.

   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 protocols, payment
   direction, currencies, payment amounts, any descriptions etc., and to retain resources
   for other transactions ("Change Process State"). If
   their relationships from the Consumer
   reconnect afterwards, a IOTP message,

   o determines the registered IOTP Payment Response Bridges,

   o compiles one or Error Block could be
   generated.

   It is expected, multiple set of brand and protocol such that Payment Handlers implement the main control
   join of all set describes exactly the set of payment transaction. Therefore, alternatives
   being offered by the Merchant.

   o inquires payment (protocol) support and the known payment
   instruments from each registered IOTP Payment Handler's
   responsibility Bridge for driving each
   compiled set ("Find Payment Instrument"). However, some IOTP Payment
   Bridges may refuse payment instrument distinction.

    The payment protocol support may differ between payment instruments
   if the IOTP Payment Bridge supports payment transaction instrument distinction.

    These API calls are used to a consistent
   status is very high.

8.7  IOTP Wallet Initialization

   At infer the payment alternatives at the
   startup or on of any payment transaction (without user unfriendly explicit
   user request the interaction).

    The IOTP Application Core
   should check its must provide wallet identifiers, if they
   are requested by the IOTP Payment Bridges' internal status Bridges which signal their need by searching
   for pending payment transactions.

   1.  The
   specific error codes (see below).

    It is recommended that the IOTP Application Core interrogates the registered manages wallet
   identifiers. But for security reasons, it should store pass phrases
   in plain text only in runtime memory. Developers of IOTP Payment
   Bridges about pending and payment transactions. software modules should provide a thin and fast
   implementation - without lengthy initialization processes- for this
   initial inquiry step.

   4. The IOTP Application Core may store indicators for pending transactions

   verifies the Consumer's payment capabilities with the Merchant's
   accepted payment brands and currencies,

   o displays the valid payment instruments and
   use them for driving payment instrument
   independent payment brands (brand and protocol) together with their
   purchase parameters (payment direction, currency, amount), and

   o requests the Consumer's choice or derives it automatically from any subsequent inquiry ("Inquire Pending
   Payment").

   2.  If
   configured preferences. Any selection ties one IOTP Payment Bridge reports
   with the presence following payment transaction.

    The handling and resolution of pending
   transactions, the unavailable IOTP Application Core has to inquire more
   information about each pending transaction ("Inquire Payment Log").
   This Bridges
   during the inquiry API call may be pass phrase protected which has in Step 3 is up to be
   requested from the Consumer.

   3.  The IOTP Application Core Core. It
   may try to suspend ("Change Process
   State") or resume ("Resume Payment Consumer") the pending transaction
   (on user request). The skip these IOTP Payment Bridge Bridges or may deny any processing allow user supported
   resolution.

    Furthermore, it may offer the registration of new payment transactions until the pending transactions have been
   processed. These denials are signaled by
   instruments when the error code "Business
   Error".

8.8  Payment Software Management Consumer is requested for payment instrument
   selection.

   5. The IOTP Application Core provides only a simple and generic
   interface for interrogates the fixed IOTP Payment
   Bridge whether the registration of new payment methods / instruments
   ("Manage might complete with success ("Check
   Payment Software"). It receives Possibility"). At this step, the IOTP Payment Bridge may
   issue several signals, e.g.,
      o payment can proceed immediately,
      o required peripheral inclusive 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.

    In any erroneous case, the initial user request should be notified and
   defers offered
   accurate alternatives. Most probably, the actual registration user might be recommended
      o to resolve the corresponding IOTP Payment
   Bridge. Other IOTP Application Core specific registration procedures
   deal with the registration of new IOTP Payment Bridges and payment
   brands.  The registration of a new problem, e.g. to insert another payment
      instrument may even be
   useful in or to verify the initial step of periphery,
      o to proceed (assuming its success),
      o to cancel the whole transaction, or
      o to suspend the transaction, e.g., initiating a nested
      transaction for uploading an electronic purse.

    If the payment transaction, when software implements payment instrument selection on
   its own, it may request the
   Merchant transmits new brand identifiers to Consumer's choice at this step.

    If the Consumer. The check succeeds, it returns several IOTP
   Application Core has Brand Selection Info
   Elements.

   6. The Steps 2 to renew any inquiry 5 are repeated and possibly interlaced for the
   selection of payment instruments - at
   least partially, if registration happens afterwards.  The IOTP
   Application Core may also activate the Existing Payment Software for
   further second payment instrument and wallet administration.

9.  Mutuality during IOTP Value Exchange
   transactions - this is omitted in the figure above.

   7. The input IOTP Brand Selection Component is generated and output arguments are annotated using enriched with
   the Extensible
   Markup Language (XML) notation. 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 called API function responds Merchant will then
   respond with
   a generic wrapper, that provides error codes and error descriptions.
   It is anticipated that this description reflects an IOTP Offer Response Block (following the logical
   structure
   aforementioned compilation rules).

2.4  Successful Payment

    An example of how the API parameter. It may be functions in this document are used together
   to derive
   implementation language specific API definitions.

   XML definition:

   <!ELEMENT IotpPaymentApiResponse (ErrorResponse?, (
     FindAcceptedPaymentBrandResponse |
     FindAcceptedPaymentProtocolResponse |
     GetPaymentInitializationDataResponse |
     CancelPaymentResponse |
     FindPaymentInstrumentResponse |
     FindPaymentProtocolResponse |
     CheckPaymentPossiblityResponse |
     QuitPaymentInstrumentResponse |
     StartPaymentConsumerResponse |
     StartPaymentPaymentHandlerResponse |
     ResumePaymentConsumerResponse |
     ResumePaymentPaymentHandlerResponse |
     ContinueProcessResponse |
     InquireProcessStateResponse |
     ChangeProcessStateResponse |
     PassErrorCodeResponse |
     InquireAuthChallengeResponse |
     AuthenticateResponse |
     CheckAuthResponsenResponse |
     CheckPaymentReceiptResponse |
     ExpandPaymentReceiptResponse |
     InquirePaymentLogResponse |
     RemovePaymentLogResponse effect a successful payment is illustrated in the Figure 5.

    Technically, two payments happen during IOTP Value Exchange
   transactions.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Consumer(Amount,[PS0]...)    -> IPB
                   Start Payment Cons. Res.([PS1], CS=Cont.)  <- IPB
                   Create and transmit Payment Request Block
   Payment Handler Start Payment Pay. Handler(Amount, [PS1])  -> IPB
                   Start Payment PH Response(PS2, CS=Cont.)   <- IPB
                   Create and transmit Payment Exchange Block
   Consumer        Continue Process(PS2)                      -> IPB
                   Continue Process Response(PS3, CS=Cont.)   <- IPB

            ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...

   Payment Handler Continue Process Response([PSn], CS=End)   <- IPB
                   Request any local payment receipt
                   |
     PaymentInstrumentInquiryResponse  Inquire Process State()                 -> IPB
                   |
     InquirePendingPaymentResponse  Inquire Proc. State Resp.(State, [Rcp.])<- IPB
                   Create and transmit Payment Response Block
                   Terminate transaction, actively
                   |
     ManagePaymentSoftwareResponse  Change Process State(State)             -> IPB
                   |
     StartPaymentInquiryResponse  Change PS Response(State=CompletedOK)   <- IPB
   Consumer        On receipt of final payment scheme data
                   |
     InquirePaymentStatusResponse  Continue Process(PSn)                   -> IPB
                   |
     CallBackResponse  Continue Process Response(CS=End)       <- IPB
                   Check Payment Receipt(Receipt)             -> IPB
                   Check Payment Receipt Response()           <- IPB
                   Request any local payment receipt
                   |
     AccessDatabaseResponse )?)>
   <!ATTLIST IotpPaymentApiResponse
     xml:lang  NMTOKEN  #REQUIRED
     ContentSoftwareID  CDATA  #IMPLIED >

   <!ELEMENT ErrorResponse (PaySchemePackagedContent*) >
   <!ATTLIST ErrorResponse
     xml:lang  NMTOKEN  #IMPLIED
     ErrorCode  NMTOKEN  #REQUIRED
     ErrorDesc  CDATA  #REQUIRED
     Severity  (Warning  Inquire Process State()                 -> IPB
                   |
      TransientError  Inquire Proc. State Resp.(State, [Rcp.])<- IPB
                   Terminate transaction, actively
                   |
      HardError)  #REQUIRED
     MinRetrySecs  CDATA  #IMPLIED
     Names  NMTOKENS  #IMPLIED >

   Most  Change Process State(State)             -> IPB
                   |  Change PS Response(State=CompletedOk)   <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                  Figure 5 Example Payment Message Flows

   1. After Brand Selection and receipt of the attribute items are intended for immediate insertion in
   the IOTP Error Block. The values of the Name attribute have to
   transformed into Error Location Elements of Offer Response
   Block, the Error Component (cf.
   IOTP Specification).

   Attributes:

   xml:lang           Defines Consumer switches from communicating with the language used by Merchant to
   communicating with the Error
                      Description attribute (cf. IOTP
                      Specification).

   ContentSoftwareId Payment Handler.

    This contains information which identifies the
                      software which generated the IOTP Message. 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 be a minimum

                      o  the name of the software manufacturer,
                      o  the name of the software,
                      o  the version of milestone requiring the software, and
                      o  the build of renewed Consumer's agreement
   about the software.

   ErrorCode          Contains an error code payment transaction's continuation. Particularly, this is a
   good moment for payment suspension (and even cancellation), which indicates the
                      nature of
   will be most probably supported by all payment schemes. Simply,
   because the error genuine payment legacy systems have not been involved in
   the message in error.
                      Valid values current transaction.

    Such an agreement might be explicit per transaction or automatic
   based on configured preferences, e.g., early acknowledgements for
   specific payment limits.

    It is assumed, that the Error Code are given in transaction proceeds with minimal user
   (Consumer and Payment Handler) interaction and that its progess is
   controlled by the following section. This mnemonic enables IOTP Application Core and IOTP Payment Bridge.

   2. In order to open the automatic failure resolution of actual payment transaction, the IOTP
   Application Core which analyzes issues the error code
                      value in order to determine "Start Payment Consumer" request towards
   the continuation
                      alternatives.

   ErrorDesc          An optional textual description of IOTP Payment Bridge. This request carries the current
                      error in whole
   initialization data of the language identified payment transaction being referred to by
                      "xml:lang". It is intended for user display
                      and provides detailed explanations about
   the
                      failure IOTP Payment Bridge for subsequent consistency checks:

      o payment brand and its (out-of-band) resolution
                      alternatives.

   Severity           Indicates description from the severity selected Brand
      Element of the error. Valid
                      values are:

                      o  Warning. This indicates that although there
                      is a message in error the IOTP Transaction
                      can still continue. Brand List Component,
      o  TransientError. This indicates that the
                      error in the message in error may be
                      recovered if payment instrument from preceding inquiry step,
      o further payment parameters (currency, amount, direction,
      expiration) from the message in error  that is
                      referred to by selected Currency Amount element, Brand List
      Component, and Payment Component of the "Names" attribute is
                      resent. IOTP Offer Response Block,
      o  HardError. This indicates that there is an
                      unrecoverable error in payment protocol from the message selected IOTP Pay Protocol Element,
      o order details contained in error
                      and the IOTP Transaction must stop.

   MinRetrySecs       This attribute should be present if Severity
                      is set to "TransientError". It is the minimum
                      number of whole seconds Order Component which might
      be payment scheme specific,
      o payment scheme specific data inclusive payment protocol
      descriptions from the IOTP aware
                      application Protocol Amount Element, and IOTP Pay
      Protocol Element, and
      o payment scheme specific data inclusive payment protocol
      descriptions, in which received the message
                      reporting the error should wait before re-
                      sending the message in error identified by name attribute includes the
                      "Names" attribute.

                      If Severity is not set to
                      "TransientError" then prefix as
      "Payment:" from the value of this
                      attribute is ignored.

   Names              This attribute indicates Trading Role Data Component.

    Generally, the name(s) called API function redoes most checks of the
                      attribute or element "Check
   Payment Possibility" call due to which the error code
                      refers.

   Content:

   PaySchemePackagedContent  cf. Table 5

9.1  Error Codes

   The following table contains the valid values for the ErrorCode
   attribute lack of the Error Response. strong dependencies between
   both requests: There might be a significant delay between both API
   requests.

    The first sentence of the
   description contains called API function may return further payment scheme specific
   data being considered as payment specific initialization data for the default text that can be used to describe
   Payment Handler's IOTP Payment Bridge.

    If the error when displayed or otherwise reported. Individual
   implementations fixed Existing Payment Software implements payment instrument
   selection on its own, it may translate this into alternative languages request the Consumer's choice 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. this
   step.

    The
   Error Codes have been taken from the IOTP Specification and extended
   by some additional codes which are highlighted by a preceding
   asterisk.

   Generally, if Payment Bridge reports lack of capability quite similar to
   the corrupt values have been user supplied, "Check Payment Possibility" request to the IOTP Application Core might prompt for their correction. If Core.
   The Consumer may decide to resolve the renewal
   fails problem, to suspend, or if to
   cancel the IOTP Application Core skips any renewals and some
   notification has transaction, but this function call must succeed in order
   to be send proceed with the transaction.

    Developers of payment modules may decide to omit payment instrument
   related checks like expiration date or refunds sufficiency, if they
   are part of the counter-party, specific payment protocol.

    If the error code is
   encapsulated within an IOTP Error Block. However, Payment Bridge requests wallet identifiers or pass
   phrases anywhere during the IOTP server
   application reports business errors payment process, they should be requested
   by this API function, too. It is recommended that the Status Component of the
   respective Response Block.

   References which are enumerated in the Names attribute have to be
   transformed to Error Location Elements. The IOTP
   Application Core
   must consider the elements' origin stores plain text pass phrases only in runtime
   memory.

    Finally, the received IOTP message.
   Particularly, references to packaged content elements have to be
   transformed to references of Application Core generates the surrounding XML element. The same
   rule applies to IOTP Payment
   Request Block, inserts any reported attribute. Then, the AttName attribute
   has returned payment scheme data, and submits
   it to be set in the Error Location element, too. Payment Handler's system.

   3. The following table mentions any modification from this general
   processing for particular error values. Furthermore, it contains
   hints for developers of Payment Handler's IOTP Application Core software components
   about opens the processing of error codes. Conversely, developers of IOTP
   Payment Bridges get impressions about payment
   transaction calling the expected behavior of "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. The
   Furthermore, the content of the IOTP Payment API assumes that Scheme Component and the
   IOTP
   Application Core implements the dialog boxes needed for error
   resolution. But it does not assume, that Brand Selection Info Elements are passed to this function.

    On success, the IOTP Payment Bridge
   actually relies on them. Instead, the Handler's IOTP Payment Bridge may try
   resolution responds with
   payment scheme specific data. On failures, this non- interactive
   server application has to resolve any problems on its own, implement specific dialog boxes, and signal
   only final failures.

   Note: This abstract document assumes that own or to give
   up aborting the API parameters are
   exchanged in XML encoding. Therefore, several error values might
   disappear in lower level language specific derivations.

   Error Value        Error Description

   Reserved           Reserved. This error is reserved by payment transaction. However, the
                      vendor/developer of Consumer may
   restart the software. Contact whole payment transaction. Anyway, the vendor/developer payment log file
   should reflect any trials of payments.

    Eventually, the software for
                      more information (see Payment Handler informs the SoftwareId
                      attribute of Consumer about the Message Id element in
   current IOTP Process State using the
                      Transaction Reference Block [RFC XXXX]).

                      The Names attribute might refer some
                      attributes IOTP Payment Response or elements of the input
                      parameter list.

   XmlNotWellFrmd     XML not well formed. The XML document is not
                      well formed. See [XML] for the meaning of
                      "well formed".

                      The Names attribute might refer to some
                      attributes and elements of the input
                      parameter list.

   XmlNotValid        XML not valid. The XML document is well
                      formed but the document is not valid. See
                      [XML] for IOTP
   Error Block.

    Note that the meaning of "valid".
                      Specifically:

                      o "Start Payment Payment Handler" call might return the XML document does not comply
   Continuation Status "End" such that payment processing proceeds with
   Step 7.

   4. The IOTP Application Core verifies the
                      constraints defined presence of the Payment
   Exchange Block in the IOTP document
                      type declaration, message and
                      o  the XML document does not comply with passes the
                      constraints defined in contained payment
   scheme specific data to the document type
                      declaration of any additional [XML
                      Namespace] that are declared.

                      The Names attribute might refer some
                      attributes and elements of fixed IOTP Payment Bridge ("Continue
   Process") which returns the input
                      parameter list.

   (*)ElNotValid      Element not valid. Invalid element next IOTP Payment Scheme Component.

    This Payment Scheme Component is encapsulated in terms
                      of prescribed syntactical characteristics.
                      The Names attribute refers an IOTP Payment
   Exchange Block and transmitted to the
                      corresponding element tags. Payment Handler.

   5. The Payment Handler's IOTP Application Core has to replace the
                      error code with "XmlNotValid" before
                      transmission to verifies the counterparty.

   ElUnexpected       Unexpected element. Although presence
   of the XML
                      document is well formed Payment Exchange Block and valid, an
                      element is present that is not expected in passes the particular context according contained payment scheme
   specific data to the
                      rules fixed IOTP Payment Bridge ("Continue Process")
   which returns the next IOTP Payment Scheme Component for
   encapsulation and constraints contained in this
                      specification.

                      The Names attribute refers transmission to the
                      corresponding element tags. Consumer.

   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
                      Application Core has Payment Exchange Block, and (3) transmits this block to replace
   the counter party.

    However, the processing of the payment scheme specific data may fail
   for several reasons signaled by specific error
                      code with "EncapProtErr" codes which are
   transformed to IOTP Payment Response Blocks (generated by Payment
   Handler) or
                      "ElContIllegal" before transmission IOTP Error Blocks (both parties may generate them) and
   transmitted to the
                      counterparty, if counter party.

   7. Eventually, the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   ElNotSupp          Element not supported. Although Payment Handler's IOTP Payment Bridge recognizes
   the document
                      is well formed and valid, an element is
                      present that

                      o  is consistent with termination of the rules payment transaction and
                      constraints contained in reports this
                      specification, but
                      o  is not supported by the
   continuation status "End" on the output parameter of "Continue
   Process" (or "Start Payment Payment Handler"). Then, the IOTP Aware
   Application which is processing Core issues the "Inquire Process State" API call and
   verifies whether an IOTP
                      Message.

                      The Names attribute refers to the
                      corresponding element tags. Payment Receipt Component has been returned.
   The IOTP Application Core has to replace wraps the error
                      code with "EncapProtErr" or
                      "ElContIllegal" before transmission to payment receipt, the
                      counterparty, if status
   response, and the Names attribute refers
                      to inner elements without a optional payment scheme specific data in an IOTP
   Payment Response Block and transmits this block to the Consumer.

    However, any of these API calls may fail or
                      Component Identifier.

   ElMissing          Element missing. Although any response might be
   incomplete (e.g., lack of payment receipt). Then, the document is
                      well formed and valid, Consumer has to
   be notified about the failed processing by an element is missing
                      that should have been present if IOTP Error Block.

    Finally, the rules
                      and constraints contained in this
                      specification Payment Handler terminates the payment transaction with
   the "Change Process State" API call without awaiting any further
   response from the Consumer. Further failures are followed.

                      The Names attribute refers not reported to the
                      corresponding element tags. The
   Consumer.

    Note that it might be possible that the Consumer's IOTP
                      Application Core Payment
   Bridge has to replace returned the error
                      code previous payment scheme specific data with "EncapProtErr" or
                      "ElContIllegal" before transmission to the
                      counterparty, if
   the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   ElContIllegal      Element content illegal. Although continuation status "End". Even in the
                      document absence of this knowledge
   - this status is well formed not exchanged between the Consumer and valid, the
                      element contains values which do Payment
   Handler - the Payment Handler must not conform supply any further payment
   scheme specific data. Such data will be rejected by the rules and constraints contained in this
                      specification. Consumer's
   IOTP Payment Bridge.

   8. The Names attribute refers Consumer passes the optional payment scheme specific data and
   the payment receipt to the corresponding element tags.

                      The fixed IOTP Payment Bridge by "Continue
   Process" and "Check Payment Receipt" API calls.

    Afterwards, the IOTP Application Core has to replace issues the
                      error code with "EncapProtErr" or
                      "ElContIllegal" before transmission "Inquire Process
   State" API call and verifies whether extensions to the
                      counterparty, if the Names attribute refers
                      to inner elements without a Block or
                      Component Identifier.

   EncapProtErr       Encapsulated protocol error. Although payment
   receipt have been returned.

    Finally, the
                      document transaction is well formed and valid, terminated by calling the
                      Packaged Content of an element contains data
                      from an encapsulated protocol "Change
   Process State" API function which contains
                      errors.

                      The Names attribute refers 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
                      corresponding element tags.

   AttUnexpected      Unexpected attribute. Although Consumer.

    At this point, the XML
                      document is well formed and valid, payment transaction has already been closed by
   the
                      presence of Payment Handler. Therefore, any failure has to be resolved
   locally or out-of-band.

2.5  Payment Inquiry

    In Baseline IOTP, Payment inquiries are initiated by the attribute is not expected Consumer in
                      the particular context according
   order to verify the
                      rules current payment progress and constraints contained in this
                      specification. process state at the
   remote Payment Handler.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer        Start Payment Inquiry()                    -> IPB
                   Start Payment Inquiry Response([PS1])      <- IPB
                   Create and transmit Inquiry Request Trading Block
   Payment Handler Inquire Payment Status([PS1])              -> IPB
                   Inquire Payment Status Res.(State, [PS2])  -> IPB
                   Create and transmit Inquiry Response Trading
                     Block
   Consumer        If Payment Scheme Data present
                   |  Continue Process(PS2)                   -> IPB
                   |  Continue Process Response(CS=End)       <- IPB
                   Change Process State(State)                -> IPB
                   Change Process State Response(State)      <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                   Figure 6 Remote Process State Inquiry

   1. The Names attribute refers to Consumer might initiate a payment inquiry once the
                      corresponding attribute tags.

   (*)AttNotValid     Attribute not valid. Invalid attribute value
                      in terms payment
   transaction has been opened by the IOTP Application Core, i.e., at
   any time after the initial submission of prescribed syntactical
                      characteristics. The Names attribute refers
                      to the corresponding attribute tags. IOTP Payment Request
   Block. The IOTP Application Core requests any additional specific
   payment scheme data from the IOTP Payment Bridge which has to replace been fixed
   during brand selection (cf. Section 2.3) using the
                      error code with "XmlNotValid" before
                      transmission "Start Payment
   Inquiry" API request.

    Erroneous API responses should be reported to the counterparty.

   AttNotSupp         Attribute not supported. Although the XML
                      document is well formed Consumer and valid, valid
   alternatives (typically retry and cancellation) should be presented
   by the
                      presence IOTP Application Core.

    This request might perform the complete initialization, e.g.
   availability check of periphery or pass phrase supplement, and the attribute in an element is
                      consistent with
   IOTP Payment Bridge reports lack of capability quite similar to the rules and constraints
                      contained in this specification, it is not
                      supported by
   "Check Payment Possibility" request to the IOTP Aware Application
                      which is processing Core.

    If the IOTP Message.

                      The Names attribute refers to the
                      corresponding attribute tags.

                      Furthermore, Payment Bridge requests wallet identifiers or pass
   phrases anywhere during the inquiry payment process, they should be requested
   by this API function
                      ("Inquire Payment Log") might report lack of
                      selection criteria. If a selector has been
                      user supplied, function, too. It is recommended that the IOTP
   Application Core may
                      offer a dialog for its adjustment. However,
                      errors generated stores plain text pass phrases only in this case, are never
                      passed runtime
   memory.

    The IOTP Application Core encapsulates any Payment Scheme Component
   in an IOTP Inquiry Request Block and submits the block to the counterparty's Payment
   Handler.

   2. The Payment Handler analyses the IOTP
                      Application Core.

   AttMissing         Attribute missing. Although Inquire Request Block, maps
   the document is
                      well formed Transaction Identifier to payment related attributes (brand,
   consumer and valid, an attribute is
                      missing that should have been present if payment identifiers), determines the
                      rules appropriate IOTP
   Payment Bridge, and constraints contained in forwards the request to the this
                      specification are followed. IOTP Payment
   Bridge ("Inquire Payment Status"). The Names
                      attribute refers IOTP Application Core
   transforms the response to an IOTP Inquiry Response Block and
   transmits it to the corresponding
                      attribute tags.

                      If Consumer.

   3. On receipt of the attribute is required by respective IOTP Inquiry Response Block the
   Consumer's IOTP
                      Document Type Declaration (#REQUIRED) Application Core submits any encapsulated payment
   scheme specific data to the
                      hints for non valid attributes should be
                      adopted, otherwise these IOTP Payment Bridge for illegal
                      attribute values.

   AttValIllegal      Attribute value illegal. verification
   ("Continue Process").

   4. The attribute
                      contains a value which does not conform IOTP Application Core passes the reported payment status
   (except textual descriptions) to the rules IOTP Payment Bridge ("Change
   Process State") for verification purposes and constraints contained in this
                      specification. payment status change.
   The Names attribute refers to the
                      corresponding attribute tags - valid values
                      are:

                      BrandId: illegal/unknown Brand Identifier -
                      If the brand is not recognized/known by any IOTP Payment Bridge, Bridge reports any inconsistencies as well as the
   final payment status to the IOTP Application
                      Core may offer the registration Core.

    Any additional information that might be of a new
                      Payment Instrument.

                      PaymentInstrumentId:   illegal/unknown
                      Payment Instrument Identifier - This
                      indicates a serious communication problem if interest for the attribute value
   Consumer has been reported to be displayed by the
                      same "wallet" IOTP Payment Bridge or Existing
   Payment Software on a previous inquiry
                      requests. their own.

2.6  Abnormal Transaction Processing

2.6.1  Failures and Cancellations

    The IOTP Application Core has to
                      replace the error code with
                      "TransportError" before transmission to the
                      counterparty.

                      WalletId: illegal/unknown Wallet Identifier
                      - It is assumed that specification distinguishes between several classes of
   failures:

   o  Business and technical errors
   o  Error depth on transport, message and block level
   o  Transient errors, warnings, and hard errors.

    Any IOTP Payment API has to deal with the wallet identifier
                      is checked before receipt of failure
   notifications by and failure responses. This proposal has borrowed
   the pass phrase. On
                      invalid wallet identifiers, basic mechanisms for error reporting between the IOTP Application
   Core may open and the dialog in
                      order to request IOTP Payment Bridge from the correct wallet
                      identifier. In addition, any pass phrase may genuine protocol: Business
   errors are reported by Status Components within IOTP Response Blocks
   while technical errors are signaled by Error Components within IOTP
   Error Blocks.

    Cancellations are mimicked as specific business errors which might
   be supplied 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 user. The dialog should
                      indicate the respective payment brand(s).
                      The IOTP
   Application Core has to replace the
                      error code with "TransportError" before
                      transmission to infer further details by the counterparty.

                      Passphrase:   illegal/unknown Pass Phrase -
                      The IOTP Application Core may open issuance of the
                      dialog in order to
   API function call "Inquire Process State".

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Issue some API request the correct pass
                      phrase.                     -> 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 the pass phrase is wallet
                      identifier Process State Change needed
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State)   <- IPB
                   If counter party's notification required
                   |  Create Error or Cancel Block (, add to next
                   |  message, ) and transmit it to counter party
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                     Figure 7 Error Response from IPB

    The specific Completion Codes "ConsCancelled", "MerchCancelled", and
   "PaymCancelled" - returned by "Inquire Process State" - determine
   that the dialog should
                      display the wallet identifier. The IOTP
                      Application Core Cancel Block has to replace be created instead of an IOTP Error
   Block.

    The rules for determining the error
                      code with "TransportError" before
                      transmission to required behavior of the counterparty.

                      Action:  illegal / unknown / unsupported
                      Action

                      PropertyTypeList:  lists contains illegal /
                      unknown / unsupported Property Types - The IOTP
   Application Core tries only are given in the local
                      resolution but does never transmit any IOTP
                      Error Block specification.

    Note that any payment (intermediate) termination, i.e., failures,
   cancellations, and even success's is always reported to the counterparty.

                      CurrCode: illegal/unknown/unsupported
                      Currency Code

                      CurrCodeType: illegal/unknown/unsupported
                      Currency Code Type

                      Amount: illegal/unknown/unsupported Payment
                      Amount

                      PayDirection: illegal/unknown/unsupported
                      Payment Direction

                      ProtocolId:   illegal/unknown/unsupported
                      Protocol Identifier

                      OkFrom: illegal/unknown/unsupported OkFrom
                      Timestamp

                      OkTo:   illegal/unknown/unsupported OkTo
                      Timestamp

                      ConsumerPayId: illegal/unknown Consumer
                      Payment Identifier

                      PaymentHandlerPayId: illegal/unknown IOTP
   Payment
                      Handler 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 Identifier

   AttValNotRecog     Attribute Value Not Recognized. The
                      attribute contains a value which Bridge for display by the IOTP
                      Aware Application generating Core.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Any Party       Error Block or Cancel Block Received
                   If Change Process State required
                   |  Change Process State (State)            -> IPB
                   |  Change Process State Response(State)   <- IPB
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
              Figure 8 Error Notification from counter party

    Not every failure might be visible at the message
                      reporting IOTP layer, e.g., the error could not recognize.

                      The Names attribute refers to
   processing of payment transactions might temporarily be hampered by
   intermediate failures at the
                      corresponding attribute tags.

   MsgTooLarge        Message too large. The message is too large
                      to payment scheme or protocol transport
   layer which might be processed resolved by the IOTP Payment Bridge
                      (resp. IOTP Application Core).

   ElTooLarge         Element too large. The element is too large genuine components.

    However, final failures or cancellations have to be processed by reported at the
   IOTP layer. E.g., communication time-outs and heavily faulty
   communication channels may disable the transaction.

    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 Bridge
                      (resp. Bridges. Anyway, the Consumer's IOTP Application Core).

                      The Names attribute refers to Core
   should notify the
                      corresponding attribute tags.

   ValueTooSmall      Value too small or early. The value of all
                      or part Consumer about the resolution alternatives, i.e.,
   retry, suspension, and cancellation.

2.6.2  Resumption

   Payment transaction resumption may apply at different steps of an element content or an
                      attribute, although valid, is too small. a
   payment transaction:

      o The Name attribute refers Consumer's and Payment Handler's view of the transaction
      might not be synchronized: Due to different time-out values the
                      corresponding attribute or element name.

   ValueTooLarge      Value too large or in
      payment transaction may not have been suspended by the future. The value
                      of all or part of an element content or counter
      party.

      Any "Resume Payment ..." API function responds with an
                      attribute, although valid, is too large.

                      The Name attribute refers to the
                      corresponding attribute or element name.

   ElInconsistent     Element Inconsistent. Although Error Code
      on non suspended payment transaction that signals a business
      error. Afterwards the document
                      is well formed and valid, according IOTP Application Core has to issue the
                      rules and constraints contained in this
                      specification:

                      o  the content
      "Inquire Process State" API call for further analysis of an element is inconsistent
                      with the content of other elements or
                      their attributes, or
      process state.

      o  the value of an attribute is inconsistent
                      with the value of One IOTP message sent by one party might not be processed
      successfully or more other
                      attributes.

                      The error description may contain further
                      explanations.

                      The Names attribute refers to even received by the
                      inconsistent attribute or element tags.

   TransportError     Transport Error. The connection counter party.

      This needs to some
                      periphery or the counterparty could not be
                      established, handled by the genuine payment scheme. It is erroneous, or has been lost.

                      The error description may contain further
                      narrative explanations, e.g., "chip card
      expected that the IOTP Application Core will not recognize
      anything.

      o IOTP does not respond", "remote account manager
                      unreachable", "Internet connection provide any specific signal for payment
      resumption. On receipt of every IOTP Payment Exchange Block, the
      IOTP Application Core has to xyz
                      lost", "no Internet connection available",
                      "no modem connected", decide whether this Block belongs to
      a pending transaction or "serial port to
                      modem used by another application". This
                      text a suspended transaction that should be shown
      resumed. The IOTP Application Core might call the "Inquire Process
      State" API function to update any lack of knowledge.

      Any "Resume Payment" API function responds with an Error Code on
      non suspended payment transaction that signals a business error.
      Similar, the end user. If
                      timeout has occurred "Continue Process" API function should report
      business errors on non pending payment transactions.

      o The payment transaction may not have been created at the Consumer this
                      text should be shown Payment
      Handler (early suspension and failed data transmission). In that
      case, the Consumer may
                      decide how to proceed - alternatives are
                      retry, payment transaction suspension, and
                      cancellation.

   MsgBeingProc       Message Being Processed. This error code is
                      only used IOTP Application Core should respond with a Severity of Transient
                      Error. It indicates business
      error that signals the previous
                      message, which may be an exchange message repetition of the payment transaction (by
      the Consumer).

      Any "Resume Payment", "Continue Process" or
                      a request message, is being processed.

   SystemBusy         System Busy. This error code is only used "Inquire Process
      State" API function should return with a Severity of Transient Error. It
                      indicates that an Error Code
      "AttValIllegal" on non existent payment transaction whereby the
      further Error Attribute "Names" denote the payment identifier.

      o The IOTP Payment Bridge or Application Core should always request fresh payment
      scheme specific data on resumption - for synchronization purposes
      with the Existing Payment Software that received the
                      API request is currently too busy to handle
                      it.

   UnknownError       Unknown Error. Indicates that Software. Old data in the
                      transaction cannot complete for some reason cache that is has
      not covered explicitly by any of been send to the
                      other errors. The Error description
                      attribute counter party should not be used to indicate accessed.

    If the
                      nature Consumer does not reconnect within an acceptable amount of
   time, the problem.

                      The Names attribute might refer to some
                      attribute or element tags.

   (*)SyntaxError     Syntax Error. An (unknown) syntax error has
                      occurred.

                      The Names attribute might refer Payment Handler's system may perform local failure
   resolution in order to some
                      attribute or element tags.

                      The IOTP Application Core has close the transaction and to replace retain resources
   for other transactions ("Change Process State"). If the
                      error code with "XmlNotValid" Consumer
   reconnect afterwards, an IOTP Payment Response or
                      "UnknownError" before transmission to the
                      counterparty.

   (*)ReqRefused      Request refused. The API IOTP Error Block
   could be generated.

2.7  IOTP Wallet Initialization

   At startup or on explicit user request is
                      (currently) refused by the IOTP Application Core
   should check its IOTP Payment
                      Bridge. The error description may provide
                      further explanations, e.g., "wallet / chip
                      card reader is unavailable or locked Bridges' internal status by
                      another searching
   for pending payment transaction", "payment
                      gateway is overloaded", "unknown chip card
                      reader", or "unrecognized chip card
                      inserted, change chip card". transactions.

   1.  The Consumer's IOTP Application Core may
                      visualize the error description and ask interrogates the
                      Consumer registered IOTP
   Payment Bridges about the continuation -
                      alternatives are retry, pending 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 counterparty's transactions. The IOTP
   Application Core. Otherwise, it maps to
                      "TransportError" Core may store indicators for pending transactions and
   use them for driving any subsequent inquiry ("Inquire Pending
   Payment").

   2. If one or "UnknownError".

   (*)ReqNotSupp      Request not supported. The API
                      function(ality) has not been implemented in
                      the more IOTP Payment Bridge. Typically, this
                      kind Bridges report the presence of error is not passed to pending
   transactions, the
                      counterparty's IOTP Application Core.
                      Otherwise, it maps Core may try to "TransportError" suspend ("Change
   Process State") or
                      "UnknownError".

   (*)BusError        Business Error. The API request has been
                      rejected because some payment transaction
                      has an illegal payment status. resume (only Consumer: "Resume Payment Consumer")
   the pending transactions (on user request).

    The Names attribute may contain references
                      to IOTP Payment Bridge may deny the processing of any new payment
   transactions using the party's
                      Payment Identifier - it defaults to until the
                      current transaction or might contain pending transactions have been processed. Such
   denials are signaled by the
                      current payment transaction party's Payment
                      Identifier. Particularly, this error code is
                      used to signal any raise of payment business
                      layer failures. "Business Error".

2.8  Payment Software Management

   The IOTP Application Core must inquire provides only a simple and generic
   interface for the
                      IOTP registration of new payment methods / instruments
   ("Manage Payment Bridge about Software"). It receives the actual Process
                      State which actually encodes initial user request and
   defers the business
                      error ("Inquire Process State" or "Inquire
                      Payment Log"). This  error code is never
                      passed actual registration to the counterparty's corresponding IOTP
                      Application Core.

                        Table 3: Common Error Codes Payment
   Bridge.

   The IOTP Payment Bridge Application Core may also use the error description in order
   to notify activate the Consumer about further necessary steps Existing Payment
   Software for failure
   resolution, e.g., "sorry, your further payment transaction failed.
   Unfortunately, you have been charged, please contact your issuer."

9.2  Attributes instrument and Elements wallet administration.

3.  Mutuality

    The following table explains the XML attributes in alphabetical order
   - any parenthesized number behind the attribute tag recommends the
   maximal length of the attribute value in characters:

   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".

   AuthenticationId    An identifier specified by Payment API is formalized using the
                       authenticator which, if returned by Extensible Markup Language
   (XML). It defines wrapper elements for both the
                       organization that receives input parameters and
   the
                       authentication request, will enable API function's response. In particular, the
                       authenticator to identify which
                       authentication is being referred to.

   BrandId  (128)      This contains a unique identifier response wrapper
   provides common locations for the
                       brand (or promotional brand). Error Codes and Error Descriptions.

    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 anticipated that this description reflects the
                       Brand.

                       Values logical
   structure of BrandId are managed under
                       procedure being described in the IOTP
                       protocol specification.

   BrandLogoNetLocn    The net location which can API parameter and might be used to
                       download derive
   implementation language specific API definitions.

   XML definition:

   <!ELEMENT IotpPaymentApiRequest (
     FindAcceptedPaymentBrand |
     FindAcceptedPaymentProtocol |
     GetPaymentInitializationData |
     FindPaymentInstrument |
     CheckPaymentPossiblity |
     StartPaymentConsumer |
     StartPaymentPaymentHandler |
     ResumePaymentConsumer |
     ResumePaymentPaymentHandler |
     ContinueProcess |
     InquireProcessState |
     ChangeProcessState |
     InquireAuthChallenge |
     Authenticate |
     CheckAuthResponse |
     CheckPaymentReceipt |
     ExpandPaymentReceipt |
     RemovePaymentLog |
     PaymentInstrumentInquiry |
     InquirePendingPayment |
     ManagePaymentSoftware |
     StartPaymentInquiry |
     InquirePaymentStatus |
     CallBack )>

   <!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 )?)>

   <!ATTLIST IotpPaymentApiResponse
     xml:lang          NMTOKEN #IMPLIED
     ContentSoftwareID CDATA   #IMPLIED
     xmlns             CDATA   #FIXED
                "http://www.iotp.org/2000/08/PaymentAPI" >

   <!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) >
   <!ATTLIST ErrorResponse
     xml:lang      NMTOKEN   #IMPLIED
     ErrorCode     NMTOKEN   #REQUIRED
     ErrorDesc     CDATA     #REQUIRED
     Severity(Warning |
       TransientError |
              HardError)     #REQUIRED
     MinRetrySecs  CDATA     #IMPLIED
     SwVendorErrorRef CDATA  #IMPLIED >

   Most of the logo attribute items are intended for immediate insertion in
   the organization (cf. IOTP Specification). Error Block. The content attribute values of this the Error Location
   elements attribute must conform have to [RFC1738].

   BrandName           This contains the name enriched and transformed into Error
   Location Elements of the brand, for
                       example "MasterCard Credit". This is Error Component (cf. IOTP Specification).

   Attributes (cf. IOTP Specification):

   xml:lang           Defines the
                       description language used by attributes or
                      child elements within this component, unless
                      overridden by an xml:lang attribute on a child
                      element.

   ContentSoftwareId  Contains information which identifies the
                      ssoftware that generated the content of the Brand which
                      element. Its purpose is displayed to the consumer 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 Consumer's language defined by
                      "xml:lang". For example it might
                       be "American Airlines Advantage Visa". Note It must contain, as a minimum
                      problems that this attribute is not used for matching
                       against might occur as a result of

                      o  the payment instruments held by name of the
                       Consumer.

   BrandNarrative      This optional attribute is designed to be
                       used by software manufacturer,
                      o  the Merchant to indicate some
                       special conditions or benefit which would
                       apply if name of the Consumer selected that brand.
                       For example "5% discount", "free shipping software,
                      o  the version of the software, and handling", "free breakage insurance for
                       1 year", "double air miles apply", etc.

   CallBackFunction    A function
                      o  the build of the software.

   ErrorCode          Contains an error code which is called whenever there is
                       a change 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 Process State or payment
                       progress, e.g. for display updates. However, the IOTP Payment Bridge may use its own
                       mechanisms and dialog boxes.

   CallBackLanguageLis A list of language codes
                      Application Core which contain, analyzes the error code
                      value in
   t order to determine the continuation
                      alternatives.

   ErrorDesc          Contains a description of preference, the languages error in which
                       the text passed to the Call Back function
                       will be encoded.

   CompletionCode (14) Indicates
                      language defined by xml:lang. The content of
                      this attribute is defined by the nature
                      vendor/developer of the payment failure. software that
                      generated the Error Response Element.
                      It is required if ProcessState is set to
                       "Failed" otherwise it is ignored. intended for user display and provides
                      detailed explanations about the failure and
                      its (out-of-band) resolution alternatives.

   Severity           Indicates the severity of the error. Valid
                      values as well as recovery options are given are:

                      o  Warning. This indicates that although there
                      is a message in error the IOTP specification.

                       The IOTP Payment Bridge may also use Transaction
                      can still continue.

                      o  TransientError. This indicates that the
                       Status Description to notify
                      error in the Consumer
                       about further necessary steps message in order error may be
                      recovered if the message in error  that is
                      referred to
                       resolve some kind of business failures,
                       e.g.,

                       o  "sorry, your payment transaction failed.
                       Unfortunately, you have been charged,
                       please contact your issuer."
                       o  "insufficient capacity left (on your card)
                       for refund", by the "Names" attribute is
                      resent.

                      o  "payment failed/chip card error/internal
                       error, please contact your payment
                       instrument's issuer"

   ConsumerDesc        A narrative description  HardError. This indicates that there is an
                      unrecoverable error in the message in error
                      and the IOTP Transaction must stop.

   MinRetrySecs       This attribute should be present if "Severity"
                      is set to "TransientError". It is the minimum
                      number of whole seconds which the Consumer.

   ConsumerPayId (14)  An identifier specified by IOTP aware
                      application which received the Consumer
                       which, if returned by message
                      reporting the Payment Handler error should wait before re-
                      sending the message in
                       another Payment Scheme Component or error identified by other
                       means, will enable the Consumer
                      "ErrorLocation" attribute.

                      If Severity is not set to identify
                       which payment
                      "TransientError" then the value of this
                      attribute is being referred to. Its ignored.

   SwVendorErrorRef   This attribute is a reference whose value uniquely identifies the payment
                       transaction on the Consumer's system. It is
                       provided
                      set by the IOTP Payment Bridge on
                       initialization vendor/developer of the payment transaction.
                       It may equal to software
                      that generated the Payment Handler Payment
                       Identifiers but need not necessarily be so. Error Element. It is recommended should
                      contain data that uniqueness extends enables the vendor to
                       multiple payment instruments, payment
                       brands, payment protocols, wallet
                       identifiers,
                      identify the precise location in their
                      software and even multiple IOTP Payment
                       Bridges, if they (might) share the support set of specific payment brands.

   ContStatus          During payment progress, this status value
                       indicates whether circumstances that
                      caused the payment needs software to be
                       continued with further IOTP Payment Scheme
                       Component exchanges with generate a message
                      reporting the remote party.
                       "End" indicates that error.

   Content:

   ErrorLocation      This identifies, where possible, the reported payment
                       scheme data is
                      element and attribute in the last data message
                      in error that caused the Error
                      Element to be exchanged
                       with the counterparty.

   ContentSoftwareId   This contains information which identifies generated. If the software which generated
                      "Severity" of the element.
                       Its purpose error is to help resolve
                       interoperability problems that might occur
                       as a result of incompatibilities between
                       messages produced by different software. It
                       must contain, not
                      "TransientError", more that one
                      "ErrorLocation" may be specified as a minimum:

                       o
                      appropriate depending on  the name nature
                      of the software manufacturer,
                       o error and at the name discretion of
                      the software,
                       o  the version vendor/developer of the software, IOTP
                      Payment Bridge.

                      Its definition coincides with the
                      IOTP specification whereby the
                      attributes "IotpMsgRef", "BlkRef" and
                       o
                      "CompRef" are left blank,
                      intentionally.

   PaySchemePackagedContent  cf. Table 5

3.1  Error Codes

   The following table lists the build of valid values for the software.

   CurrCodeType  (14)  Indicates ErrorCode
   attribute of the domain Error Response Element. The first sentence of the CurrCode. Its
                       value defaults
   error description contains the default text that can be used to ISO4217-A.

   CurrCode  (14)      A
   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 identifies are highlighted by a
   preceding asterisk.

   Generally, if the currency 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
                       used send to the counter-party, the error code is
   encapsulated within an IOTP Error Block.

   However, the IOTP server application reports business errors -
   visible at the IOTP layer - in the payment. Status Component of the respective
   Response Block.

   The domain IOTP Application Core may add the attributes (and values) within
   the ErrorLocation elements being omitted by the IOTP Payment Bridge.

   The following table mentions any modification from this general
   processing for particular error values. Furthermore, it contains
   hints for developers of valid
                       currency codes is defined by "CurrCodeType"

   DataBaseFunction    This callback functions may be called by IOTP Application Core software components
   about the processing of error codes. Conversely, developers of IOTP
   Payment Bridge resp. Existing Payment
                       Software whenever data Bridges get impressions about transactions
                       needs to be stored or retrieved. However, the expected behavior of the
   IOTP Application Core.

   The IOTP Payment Bridge may use its own
                       mechanisms.

   MerchantPayId  (14) An private identifier specified by API assumes that the
                       Merchant which will enable IOTP Application Core
   implements 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 dialog boxes needed for error resolution. But it does
   not assume, that the IOTP Payment Bridge actually relies on payment preparation
                       during brand compilation.

                       Cf. To "ConsumerPayId" for note about
                       uniqueness.

   MerchantOrgId  (64) A private item that might refer to some them.
   Instead, the IOTP Payment Bridge may try resolution on its own, may
   implement specific shop in a multi shop environment.
                       This item is optional dialog boxes, and might enrich the
                       Wallet Identifier which itself can be used
                       for the same purpose.

   Name                Distinguishes between multiple occurrences
                       of Packaged Content Elements at the same
                       point in IOTP. For example:

                       <ABCD>
                         <PackagedContent Name='FirstPiece'>
                           snroasdfnas934k
                         </PackagedContent>
                         <PackagedContent Name='SecondPiece'>
                           dvdsjnl5poidsdsflkjnw45
                         </PackagedContent>
                       </ABCD>

                       The "Name" attribute may be omitted, for
                       example if there is signal only one Packaged
                       Content element.

   NumberofPayments    The numerical attribute is used to limit final failures.

   Note: This abstract document assumes that the
                       items in inquiry responses.

   OkFrom  (30)        The date and time API parameters are
   exchanged XML encoded. Therefore, several error values might
   disappear in UTC Format range
   OkTo  (30)          indicated lower level language specific derivations.

   Error Value        Error Description

   Reserved           Reserved. This error is reserved by the merchant in which
                      vendor/developer of the
                       Payment Handler may accept software. Contact
                      the payment.

   Passphrase  (32)    Payment wallets may use pass phrase
                       protection vendor/developer of the software 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 inquired by
                      more information (see the IOTP
                       application without any pass phrase
                       knowledge.

   PayDirection        Indicates SoftwareId
                      attribute of the direction Message Id element in which the
                       payment
                      Transaction Reference Block [IOTP]).

   XmlNotWellFrmd     XML not well formed. The XML document is not
                      well formed. See [XML] for which a Brand the meaning of
                      "well formed".

   XmlNotValid        XML not valid. The XML document is being selected well
                      formed but the document is to be made. Its values may be:

                       o  Debit: The sender of not valid. See
                      [XML] for the Payment Request
                       Block (e.g. meaning of "valid".
                      Specifically:

                      o  the Consumer) to which this
                       Brand List relates will make XML document does not comply with the payment
                       to
                      constraints defined in the Payment Handler, or IOTP document
                      type declaration, and
                      o  Credit: The sender of the Payment Request
                       Block to which this Brand List relates
                       will receive a payment from the Payment
                       Handler.

   PayInstName         This contains  the user-defined name of XML document does not comply with the
                       payment instrument. There exist no
                       (technical)
                      constraints like uniqueness. defined in the document type
                      declaration of any additional [XML-NS]
                      that are declared.

                      The
                       "xml:lang" Names attribute denotes might refer some
                      attributes and elements of the language
                       encoding input
                      parameter list.

   (*)ElNotValid      Element not valid. Invalid element in terms
                      of its value.

   PaymentHandlerDesc  A narrative description prescribed syntactical characteristics.

                      The ElementRef attributes of ErrorLocation
                      elements might refer to the Payment
                       Handler.

   PaymentHandlerPayId An identifier specified by corresponding
                      elements (if they have ID attributes).

                      The IOTP Application Core has to replace the Payment
     (14)              Handler which, if returned by
                      error code with "XmlNotValid" before
                      transmission to the Consumer counterparty.

   ElUnexpected       Unexpected element. Although the XML
                      document is well formed and valid, an
                      element is present that is not expected in another Payment Scheme Component, or by
                       other means, will enable
                      the Payment Handler particular context according to identify which payment the
                      rules and constraints contained in this
                      specification.

                      The ElementRef attributes of ErrorLocation
                      elements might refer to the corresponding
                      elements (if they have ID attributes).

   ElNotSupp          Element not supported. Although the document
                      is being referred
                       to. It well formed and valid, an element is required whenever it
                      present that

                      o  is known. Its
                       value uniquely identifies the payment
                       transaction on consistent with the Payment Handler's system.
                       It rules and
                      constraints contained in this
                      specification, but
                      o  is provided not supported by the IOTP Payment Bridge on
                       initialization of Aware
                      Application which is processing the payment transaction.
                       It may equal IOTP
                      Message.

                      The ElementRef attributes of ErrorLocation
                      elements might refer to the Consumer Payment
                       Identifiers but need not necessarily be so.

                       Cf. To "ConsumerPayId" for note about
                       uniqueness.

   PaymentInstrumentId An identifier for a specific payment
     (32)              instrument, e.g. "credit card", "Mondex card
                       for English Pounds". This identifier corresponding
                      elements (if they have ID attributes).

   ElMissing          Element missing. Although the document is
                       fully customizable. It
                      well formed and valid, an element is assumed, missing
                      that it
                       does not contain confidential information or
                       even an indication to it. should have been present if the rules
                      and constraints contained in this
                      specification are followed.

                      The payment
                       instrument identifier is unique within each
                       payment brand. It is displayed ElementRef attributes of ErrorLocation
                      elements might refer to the
                       Consumer during brand selection.

   PayReceiptNameRefs  Optionally contains a list of corresponding
                      elements (if they have ID attributes).

   ElContIllegal      Element content illegal. Although the
                      document is well formed and valid, the
                      element contains values of which do not conform
                      the Name rules and constraints contained in this
                      specification.

                      The ElementRef attributes of Packaged Content ErrorLocation
                      elements that together make up might refer to the receipt. corresponding
                      element (if they have ID attributes).

                      The IOTP Application Core has to replace the
                      Error Code with "ElNotSupp" before
                      transmission to the counter party, if the
                      ErrorLocation elements refer to non
                      PackagedContent element.

   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.

                      The ElementRef attributes of ErrorLocation
                      elements are container
                       either within:

                       o  Payment Scheme Data components exchanged
                       between might refer to the Payment Handler and corresponding
                      element (if they have ID attributes).

   AttUnexpected      Unexpected attribute. Although the
                       Consumer roles during XML
                      document is well formed and valid, the Payment, and/or
                       o
                      presence of the Payment Receipt component itself.

                       Each payment scheme defines attribute is not expected in its
                       supplement
                      the Names of particular context according to the Packaged Content
                       elements that must be listed
                      rules and constraints contained in this
                       attribute.

   PayReqNetLocn
                      specification.

                      The Net Location indicating where an
                       unsecured Payment Request message should be
                       sent if this protocol choice is used. AttName attributes of ErrorLocation
                      elements might refer to the corresponding
                      attribute tags.

   (*)AttNotValid     Attribute not valid. Invalid attribute value
                      in terms of prescribed syntactical
                      characteristics.

                      The content AttName attributes of this ErrorLocation
                      elements might refer to the corresponding
                      attribute depends on tags.

                      The IOTP Application Core has to replace the
                       Transport Mechanism (such must conform
                      error code with "XmlNotValid" before
                      transmission to
                       [RFC1738].

   PercentComplete (3) A number between 0 and 100 which indicates the progress of counter party.

   AttNotSupp         Attribute not supported. Although the payment transaction. The
                       values range between 0 XML
                      document is well formed and 99 for pending valid, and suspended transactions.

   ProcessState        Contains a Process State Code which
                       indicates the current state
                      presence of the business
                       success or failure of attribute in an element is
                      consistent with the processing of rules and constraints
                      contained in this specification, it is not
                      supported by the
                       payment transactions. Valid values are:

                       o  NotYetStarted. The Payment Request Block
                       has been received but IOTP Aware Application
                      which is processing of the
                       Payment Request has not yet started

                       o  InProgress. The payment transaction IOTP Message.

   AttMissing         Attribute missing. Although the document is
                       pending.
                      well formed and valid, an attribute is
                      missing that should have been present if the
                      rules and constraints contained in this
                      specification are followed.

                      The processing AttName attributes of ErrorLocation
                      elements might refer to the Payment
                       Request Block and any subsequent Payment
                       Exchange Blocks has started but it corresponding
                      attribute tags.

                      If the attribute is not
                       yet complete.

                       o  Suspended: required by the IOTP
                      Document Type Declaration (#REQUIRED) the
                      hints for non valid attributes should be
                      adopted, otherwise these for illegal
                      attribute values.

   AttValIllegal      Attribute value illegal. The payment transaction has
                       been suspended attribute
                      contains a value which does not conform to
                      the rules and can be resumed.

                         This process state is mapped constraints contained in this
                      specification.

                      The AttName attributes of ErrorLocation
                      elements might refer to
                       "InProgress", if it the corresponding
                      attribute tags - valid values are:

                      BrandId: illegal/unknown Brand Identifier -
                      If the brand is passed to not recognized/known by any
                      IOTP Payment Bridge, the
                       counterparty's IOTP Application Core.

                       o  CompletedOk. Processing of
                      Core may offer the registration of a new
                      Payment
                       Request Block and any following Instrument.

                      PaymentInstrumentId:   illegal/unknown
                      Payment
                       Exchange Blocks Instrument Identifier - This
                      indicates a serious communication problem if
                      the attribute value has completed
                       successfully.

                       o  Failed. been reported by the
                      same "wallet" on a previous inquiry
                      requests. The payment IOTP Application Core has finally failed for
                       some reason.

                       o  ProcessError. This value is only exchanged
                       when to
                      replace the Status Component is being used in
                       connection error code with an Inquiry Request Trading
                       Block.
                      "UnknownError" before transmission to the
                      counter party.

                      WalletId: illegal/unknown Wallet Identifier
                      - It indicates there was a Technical
                       Error in is assumed that the Request Block which wallet identifier
                      is being
                       processed or some internal processing
                       error. Each party's IOTP Payment Bridge
                       uses this value in order to notify checked before the pass phrase. On
                      invalid wallet identifiers, the IOTP
                      Application Core about may open the presence
                       of technical errors.

   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 dialog in
                      order to request the correct wallet
                      identifier. In addition, any pass phrase may apply to
                       payment brand specific transactions or out-
                       of-band failure resolution.

   PropertyDesc
                      be supplied by the user. The property description carries dialog should
                      indicate the respective human readable property (value)'s
                       description.

   PropertyValue payment brand(s).
                      The actual property value intends automatic
                       post processing.

   ProtocolBrandId (64)This is an identifier IOTP Application Core has to be used with a
                       particular payment protocol. For example,
                       SET and EMV have their own well defined, yet
                       different, values for replace the Brand identifier
                       to be used
                      error code with each protocol. One Brand
                       Identifier maps "UnknownError" before
                      transmission to at most one Protocol
                       Brand Identifier.

   ProtocolId  (64)    An the counter party.

                      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 for a specific payment
                       protocol and version, e.g. "SETv1.0",
                       "ecash". Valid values are defined by
                       supplements 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.

                      Action:  illegal / unknown / unsupported
                      Action

                      PropertyTypeList:  lists contains illegal /
                      unknown / unsupported Property Types - The
                      IOTP specification and
                       they are unique within each payment brand.

   ProtocolIds         A sequence of Application Core tries only the local
                      resolution but does never transmit any IOTP
                      Error Block to the counter party.

                      CurrCode: illegal/unknown/unsupported
                      Currency Code

                      CurrCodeType: illegal/unknown/unsupported
                      Currency Code Type

                      Amount: illegal/unknown/unsupported Payment
                      Amount

                      PayDirection: illegal/unknown/unsupported
                      Payment Direction

                      ProtocolId:   illegal/unknown/unsupported
                      Protocol Identifiers

   ProtocolName        A narrative description of Identifier

                      OkFrom: illegal/unknown/unsupported OkFrom
                      Timestamp

                      OkTo:   illegal/unknown/unsupported OkTo
                      Timestamp

                      ConsumerPayId: illegal/unknown Consumer
                      Payment Identifier

                      PaymentHandlerPayId: illegal/unknown Payment
                      Handler Payment Identifier

                      PayId: illegal/unknown Payment Identifier

   AttValNotRecog     Attribute Value Not Recognized. The
                      attribute contains a value which the payment
                       protocol and its version in IOTP
                      Aware Application generating the language
                       identified by "xml:lang". For example
                       "Secure Electronic Transaction Version 1.0".
                       Its purpose is message
                      reporting the error could not recognize.

                      The AttName attributes of ErrorLocation
                      elements might refer to help provide information
                       on the payment protocol being used if
                       problems arise.

   ResponseCode        This corresponding
                      attribute encodes a binary flag with
                       the value "Yes" and "No".

   SecPayReqNetLocn tags

   MsgTooLarge        Message too large. The Net Location indicating where a secured
                       Payment Request message should be sent if
                       this protocol choice is used.

                       A secured payment involves too large
                      to be processed by the use of a
                       secure channel such as [SSL] in order IOTP Payment Bridge
                      (resp. IOTP Application Core).

   ElTooLarge         Element too large. The element is too large
                      to
                       communicate with be processed by the IOTP Payment Handler. Bridge
                      (resp. IOTP Application Core).

                      The content ElementRef attributes of this attribute must conform ErrorLocation
                      elements might might refer to [RFC1738].

   ReceiverOrgId       The Organization Identification which
                       receives the payment bridge processing
                       Trading Role Data PackagedContent.

   StatusDesc  (256)   An optional textual description
                      corresponding elements.

   ValueTooSmall      Value too small or early. The value of all
                      or part of an element content or an
                      attribute, although valid, is too small.

                      The ErrorLocation elements might refer to
                      the
                       current process state corresponding attribute tags or
                      elements.

   ValueTooLarge      Value too large or in the language
                       identified by "xml:lang" that should be
                       displayed future. The value
                      of all or part of an element content or an
                      attribute, although valid, is too large.

                      The ErrorLocation elements might refer to
                      the corresponding attribute tags or
                      elements.

   ElInconsistent     Element Inconsistent. Although the document
                      is well formed and valid, according to the Consumer. The usage of
                      rules and constraints contained in this
                       attribute
                      specification:

                      o  the content of an element is defined in inconsistent
                      with the payment
                       supplement for content of other elements or
                      their attributes, or
                      o  the payment method being
                       used. Particularly, it provides hints for
                       out-of-band failure resolution. Its length value of an attribute is limited inconsistent
                      with the value of one or more other
                      attributes.

                      The Error Description may contain further
                      explanations.

                      The ErrorLocation elements might refer to 256 characters.

   StyleSheetNetLocn   This contains
                      the net location corresponding attribute tags or elements
                      that are inconsistent.

   TransportError     Transport Error. This error code is used to
                      indicate that there is a style
                       sheet problem with visualisation rules for XML
                       encoded data.

   TimeStamp  (30) the
                      transport mechanism that is preventing the
                      message from being received. It is typically
                      associated with a "Transient Error".

                      The date and time in UTC Format when connection to some
                      periphery or the
   TimeStampFrom (30)  payment transaction counter party could not be
                      established, is erroneous, or has been started.
   TimeStampTo (30)

   WalletId  (32)      Many existing payment wallet software are
                       multiple wallet capable. lost.

                      The Wallet
                       Identifier selects 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 actual wallet. It is
                       assumed, that end user. If
                      timeout has occurred at the wallet identifier Consumer this
                      text should be shown and the Consumer may
                      decide how to proceed - alternatives are
                      retry, payment transaction suspension, and
                      cancellation.

   MsgBeingProc       Message Being Processed. This error code is
                      only used with a
                       public item, Severity of Transient
                      Error. It indicates that might the previous
                      message, which may be stored an exchange message or
                      a request message, is being processed and,
                      if no response is received by the
                       IOTP Application Core.

   xml:lang            Defines the language used time
                      indicated by the Process
                       State Description attribute (cf. IOTP
                       Specification)

                            Table 4: Attributes

   The following table explains "MinRetrySecs" attribute,
                      then the XML elements in alphabetical
   order:

   Element             Description

   Algorithm           This contains information which describes
                       an Algorithm that may original message should be resent.

   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 generate handle
                      it. If no response is received by the Authentication response. time
                      indicated by the "MinRetrySecs" attribute,
                      then the original message should be resent.

                      The
                       algorithm that Error Description may be used provide further
                      explanations, e.g., "wallet / chip card
                      reader is identified unavailable or locked by the Name attribute (cf. IOTP
                       Specification).

   AuthReqPackagedContent another
                      payment transaction", "payment gateway is
                      overloaded", "unknown chip card reader", or
                      "unrecognized chip card inserted, change
                      chip card".

                      The Authentication Request Packaged
                       Content originates from a Authentication
                       (Data/Response) Component's content
                       whereby Consumer's IOTP Application Core may
                      visualize the outermost element tags error description and ask the
                      Consumer about the continuation -
                      alternatives are
                       prefixed with "AuthReq". Its declaration
                       coincides with retry, payment transaction
                      suspension, and cancellation.

   UnknownError       Unknown Error. Indicates that the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       encapsulates
                      transaction cannot complete for some reason
                      that is not covered explicitly by any of the authentication challenge
                       value.
                      other errors. The content Error description
                      attribute should be used to indicate the
                      nature of this information is
                       defined in the supplement for a payment
                       protocol.

   AuthResPackagedContent problem.

                      The Authentication Response Packaged
                       Content originates from a Authentication
                       (Data/Response) Component's content
                       whereby ErrorLocation elements might refer to
                      the outermost element corresponding attribute tags or elements
                      that are
                       prefixed with "AuthRes". Its declaration
                       coincides with the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       encapsulates the authentication response
                       value. inconsistent.

   (*)SyntaxError     Syntax Error. An (unknown) syntax error has
                      occurred.

                      The content of this information is
                       defined in ErrorLocation elements might refer to
                      the supplement for a payment
                       protocol.

   BrandPackagedContent     Container for further payment brand
                       description. Its content originates from
                       a Brand Element content whose outermost
                       element corresponding attribute tags or elements
                      that are prefixed with "Brand".
                       Its declaration coincides inconsistent.

                      The IOTP Application Core has to replace the
                      error code with "XmlNotValid" or
                      "UnknownError" before transmission to the
                      counter party.

   (*)ReqRefused      Request refused. The API request is
                      (currently) refused by the
                       Packaged Content's declaration (cf. IOTP
                       Specification).

   BrandSelBrandInfoPacka This contains any additional data that
   gedContent Payment
                      Bridge. The error description may be required provide
                      further explanations, e.g., "wallet / chip
                      card reader is unavailable or locked by a particular
                      another payment
                       brand. It forms transaction", "payment
                      gateway is overloaded", "unknown chip card
                      reader", or "unrecognized chip card
                      inserted, change chip card".

                      The Consumer's IOTP Application Core may
                      visualize the content of error description and ask the Brand
                       Selection Brand Info Element.

   BrandSelProtocolAmount This contains any additional data that
   InfoPackagedContent may
                      Consumer about the continuation -
                      alternatives are retry, payment transaction
                      suspension, and cancellation. Denials due to
                      invalid Process States should be required signaled by a particular payment
                       brand in the format. It forms the content
                      "BusinessError". Typically, this kind of
                      error is not passed to the Brand Selection Protocol Amount
                       Info Element.

   BrandSelCurrencyAmount This contains any additional data that
   InfoPackagedContent payment brand and currency specific counter party's
                      IOTP Application Core. Otherwise, it maps to
                      "TransportError" or "UnknownError".

   (*)ReqNotSupp      Request not supported. The API
                      function(ality) has not been implemented in
                      the format. It forms the content IOTP Payment Bridge. Typically, this
                      kind of error is not passed to the
                       Brand Selection Currency Amount Info
                       Element.

   ChallengePackagedConte Container for authentication challenge
   nt                  data. Its content originates from a
                       Authentication Data Component's Packaged
                       Content element whose outermost element
                       tags are prefixed with "Challenge". Its
                       declaration coincides with the Packaged
                       Content's declaration (cf.
                      counter party's IOTP
                       Specification).

   MerchantData        Any merchant related data that might be Application Core.
                      Otherwise, it maps to "TransportError" or
                      "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 by to
                      signal any raise of payment business layered
                      failures.

                      The ErrorLocation elements may refer to
                      payment transactions using the IOTP party's
                      Payment Bridge for
                       different purposes, e.g., Identifier - it defaults to the
                      current transaction or might contain access keys to some mall keys.
                       Its declaration coincides with the
                       Packaged Content's declaration (cf. IOTP
                       Specification).

   PackagedContent     Generic Container for non-IOTP data (cf.
                       IOTP Specification).

   PayReceiptPackagedCont   Its content originates from a
                      current payment transaction party's Payment
   ent                 Receipt Component's Packaged Content
                       whose outermost element tags are prefixed
                       with "PayReceipt". Its declaration
                       coincides
                      Identifier - identified by the ElementRef
                      attribute while the AttName attribute is
                      fixed with "PayId".

                      The IOTP Application Core must inquire the Packaged Content's
                       declaration (cf.
                      IOTP Specification).

   PaySchemePackagedConte The PayScheme Packaged Content originates
   nt                  from a Payment Scheme Component's content
                       whereby Bridge about the outermost element tags are
                       prefixed with "PayScheme". Its
                       declaration coincides with actual Process
                      State which actually encodes the Packaged
                       Content's declaration (cf. IOTP
                       Specification). It carries business
                      error ("Inquire Process State").
                      This error code must not be
                      passed to the payment
                       specific data. counter party's IOTP
                      Application Core.

                        Table 2: Common Error Codes

   The content of this
                       information is defined IOTP Payment Bridge may also use the error description in order
   to notify the supplement Consumer about further necessary steps for a failure
   resolution, e.g., "sorry, your payment protocol.

   ProtocolAmountPackaged transaction failed.
   Unfortunately, you have been charged, please contact your issuer."

3.2  Attributes and Elements

   The Protocol Amount Packaged Content
   Content             originates from a Protocol Amount
                       Element's content whereby the outermost
                       element tags are prefixed with "Amount".
                       Its declaration coincides with following table explains the
                       Packaged Content's declaration (cf. IOTP
                       Specification). It contains information
                       about XML attributes in alphabetical order
   - any parenthesized number behind the protocol which is used by attribute tag recommends the
                       payment protocol. The content
   maximal length of this
                       information is defined the attribute value in characters:

   Attribute           Description

   Amount    (11)      Indicates the supplement
                       for a payment protocol.

   ProtocolBrandPackagedC   The Protocol Brand Packaged Content
   ontent              originates from a Protocol Brand
                       Element's content whereby the outermost
                       element tags are prefixed with
                       "ProtocolBrand". Its declaration
                       coincides with amount to be paid in
   AmountFrom(11)      whole and fractional units of the Packaged Content's
                       declaration (cf. IOTP Specification). It
                       contains information about currency.
   AmountTo  (11)      For example $245.35 would be expressed
                       "245.35". Note that values smaller than the brand
                       which might
                       smallest denomination are allowed. For
                       example one tenth of a cent would be used
                       "0.001".

   AuthenticationId    An identifier specified by the payment
                       protocol. The content of this information
                       is defined in
                       authenticator which, if returned by the
                       organization that receives the supplement for a
                       payment protocol.

   ResponsePackagedConten   Container for
                       authentication response
   t                   data. Its content originates from a
                       Authentication Response Component's
                       Packaged Content whose outermost element
                       tags are prefixed with "Response". Its
                       declaration coincides with request, will enable the Packaged
                       Content's declaration (cf. IOTP
                       Specification).

   TradingRoleDataPackage   The TradingRoleData Packaged Content
   dContent            originates from
                       authenticator to identify which
                       authentication is being referred to.

   BrandId  (128)      This contains a TradingRoleData
                       Component's content whereby the outermost
                       element tags are prefixed with
                       "TradingRoleData". Its declaration
                       coincides with unique identifier for the Packaged Content's
                       declaration (cf. IOTP Specification).
                       brand (or promotional brand). It
                       contains information from Merchant is used to
                       match against a list of Payment Handler via Instruments
                       which the Consumer about holds to determine
                       whether or not the
                       protocol which is used by Consumer can pay with the payment.
                       The content
                       Brand.

                       Values of this information is
                       defined BrandId are managed under
                       procedure being described in the supplement for a payment
                       protocol. IOTP
                       protocol specification.

   BrandLogoNetLocn    The Name attribute in this
                       packaged contents  must include prefix as
                       "Payment:" net location which can be used to indicate that
                       download the payment
                       bridge processes this, logo for example
                       "Payment:SET-OD"
                             Table 5: Elements

10.  Payment API Calls

10.1  Brand Compilation Related API Calls

10.1.1  Find Accepted Payment Brand

   This function determines which payment brands could be accepted by the Payment Handler on behalf organization (cf.
                       IOTP Specification).

                       The content of this attribute must conform
                       to [URL].

   BrandName           This contains the Merchant.

   Input Parameters

   o  Payment Direction - provided by name of the IOTP Application Core
   o  Currency Code and Currency - provided by brand, for
                       example "MasterCard Credit". This is the IOTP Application
      Core
   o  Payment Amount - provided by
                       description of the IOTP Application Core
   o  Merchant Payment Identifier - Merchant's unique private
      reference Brand which is displayed
                       to the payment transaction
   o  Merchant Organisation Identifier - 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 distinction between
      multiple merchants that share matching
                       against the some IOTP merchant system
   o  Wallet Identifier - managed payment instruments held by the IOTP Application Core
   o  Merchant Data - specific data
                       Consumer.

   BrandNarrative      This optional attribute is
                       used by the IOTP Payment Bridge Merchant to indicate some
                       special conditions or benefit which is managed in would
                       apply if the IOTP Application Core.

   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 >

   Output Parameters

   o  Payment Brand Identifier - Consumer selected that brand.
                       For example "5% discount", "free shipping
                       and handling", "free breakage insurance for insertion in
                       1 year", "double air miles apply", etc.

   CallBackFunction    A function which is called whenever there is
                       a change of Process State or payment
                       progress, e.g. for display updates. However,
                       the Brand List
      Component's Brand Element
   o IOTP Payment Brand Name Bridge may use its own
                       mechanisms and dialog boxes.

   CallBackLanguageLis A list of language annotation - for insertion codes which contain, in
   t                   order of preference, the Brand List Component's Brand Element
   o  Payment Brand Logo Net Location - for insertion languages in which
                       the Brand
      List Component's Brand Element
   o  Payment Brand Narrative Description - for insertion in text passed to the
      Brand List Component's Brand Element
   o  (Brand) Packaged Content - further payment brand description
      for insertion Call Back function
                       will be encoded.

   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 Brand List Component's Brand Element IOTP specification.

                       The Existing IOTP Payment Software returns an empty list Bridge may also use the
                       Status Description to notify the Consumer
                       about further necessary steps in order to
                       resolve some kind of brand items,
   if it does not support any business failures,
                       e.g.,

                       o  "sorry, your payment brand/payment protocol combination transaction failed.
                       Unfortunately, you have been charged,
                       please contact your issuer."
                       o  "insufficient capacity left (on your card)
                       for the given refund",
                       o  "payment failed/chip card error/internal
                       error, please contact your payment parameters.

   XML definition:

   <!ELEMENT FindAcceptedPaymentBrandResponse (BrandItem*) >
   <!ATTLIST FindAcceptedPaymentBrandResponse >
   <!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
                       instrument's issuer"

   ConsumerDesc        A narrative description of the attributes and elements; Table 3
   introduces Consumer.

   ConsumerPayId (14)  An unique identifier specified by the
                       Consumer that, if returned by the Error Codes.

10.1.2  Find Accepted Payment Protocol

   Determines
                       Handler in another Payment Scheme Component
                       or by other means, enables the Consumer to
                       identify which instances of payment protocols are accepted is being referred to.

                       This unique identifier is generated by the
                       IOTP Application Core and submitted to the
                       IOTP Payment Handler Bridge on behalf of every API call. It
                       may equal to the Merchant.

   Input Parameters

   o  Brand Identifier - returned by "Find Accepted Payment Brand"
   o  Payment Direction
   o  Currency Code and Currency
   o  Payment Amount
   o  Merchant Handler Payment Identifier - Merchant's unique private
      reference
                       Identifiers but need not necessarily be so.

                       The uniqueness extends to the multiple payment transaction
   o  Merchant Organisation Identifier - used for distinction between
                       instruments, payment brands, payment
                       protocols, wallet identifiers, and even
                       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"
   o  Merchant Data - specific data used by Bridges.

   ContStatus          During payment progress, this status value
                       indicates whether the payment needs to be
                       continued with further IOTP Payment Bridge
      which Scheme
                       Component exchanges with the remote party.
                       "End" indicates that the reported payment
                       scheme data is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
   MerchantData*) >
   <!ATTLIST FindAcceptedPaymentProtocol
     BrandId  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     MerchantPayId  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants last data to be exchanged
                       with the counter party.

   ContentSoftwareId   This contains information that identifies
                       the software that generated the content of
                       the element. Its purpose is to help resolve
                       interoperability problems that share might occur
                       as a result of incompatibilities between
                       messages produced by different software. It
                       is a single text string in the some IOTP merchant system language
                       defined by xml:lang. It must contain, as a
                       minimum:

                       o  Refined Currency Code and Currency - for insertion in  the Brand
      List Component's Currency Amount Element name of the software manufacturer,
                       o  Refined Payment Amount - for insertion in  the Brand List
      Component's Currency Amount Element name of the software,
                       o  Payment Protocol Identifier - for insertion in  the Brand List
      Component's Pay Protocol Element version of the software, and
                       o  Protocol Brand Identifier - for insertion in  the Protocol Brand
      Element build of the Brand List Component's Brand Element software.

   CurrCodeType (14)   Indicates the domain of the CurrCode. This
                       attribute is included so that the currency
                       code may support nonstandard currencies
                       such as frequent flyer point, trading
                       stamps, etc. Its values may be

                       o  Payment Protocol Name and language annotation- for insertion in  ISO-4217-A, the Brand List Component's Pay Protocol Element default, indicates the
                          currency code is the three-letter
                          alphabetic code that conform to ISO 4217

                       o  Payment Request Net Location - for insertion  IOTP indicates that the values of
                          CurrCode are managed under the procedure
                          described in [IOTP].

   CurrCode  (14)      A code which identifies the Brand List
      Component's Pay Protocol Element
   o  Secured Payment Request Net Location - currency to be
                       used in the payment. The domain of valid
                       currency codes is defined by "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.

                       Cf. To "ConsumerPayId" for insertion note about
                       uniqueness.

   MerchantOrgId  (64) A local item that might refer to some
                       specific shop in a multi shop environment.
                       This item is optional and might enrich the
      Brand List Component's Pay Protocol Element
   o  (Protocol Brand) Packaged Content -
                       Wallet Identifier which itself can be used
                       for insertion in the
      Protocol Brand Element same purpose.

   Name                Distinguishes between multiple occurrences
                       of the Brand List Component's Brand
      Element
   o  (Protocol Amount) Packaged Content - for insertion in Elements at the Brand
      List Component's Protocol Amount Element
   o  (Protocol) same
                       point in IOTP. For example:

                       <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 - for insertion element.

   OkFrom  (30)        The date and time in UTC Format range
   OkTo  (30)          indicated by the Brand List
      Component's Pay Protocol Element

   XML definition:

   <!ELEMENT FindAcceptedPaymentProtocolResponse (ProtocolItem+) >
   <!ATTLIST FindAcceptedPaymentProtocolResponse >
   <!ELEMENT ProtocolItem (ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST ProtocolItem
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     ProtocolName  CDATA  #REQUIRED
     PayReqNetLocn  CDATA  #IMPLIED
     SecPayReqNetLocn  CDATA  #IMPLIED >

   Tables 4 merchant in which the
                       Payment Handler may accept the payment.

   Passphrase  (32)    Payment wallets may use pass phrase
                       protection for transaction data and 5 explain 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 inquired by the IOTP
                       application without any pass phrase
                       knowledge.

   PayDirection        Indicates the attributes and elements; Table 3
   introduces direction in which the
                       payment for which a Brand is being selected
                       is to be made. Its values may be:

                       o  Debit: The sender of the Error Codes.

10.1.3  Get Payment Initialization Data

   This API function provides Request
                       Block (e.g. the remaining initialization data being
   required by Consumer) to which this
                       Brand List relates will make the Consumer's payment
                       to the Payment Handler, or
                       o  Credit: The sender of the Payment Handler's Existing Request
                       Block to which this Brand List relates
                       will receive a payment from the Payment
   Software.
                       Handler.

   PayId (14)          This function might be called both attribute is introduced for "brand dependent"
   and "brand independent" transaction types.

   Input Parameters API
                       simplification:

                       o  Brand Identifier - returned by "Find Accepted Payment Brand"  The Consumer has to identify PayId and
                          ConsumerPayId.

                       o  The Merchant Payment Identifier - Merchant's unique private
      reference has to the payment transaction identify PayId and
                          MerchantPayId.

                       o  The Payment Direction
   o  Currency Code Handler has to identify PayId
                          and Currency - from Payment Handler Pay Id.

   PayInstId           This contains the Brand List Component's
      Currency Amount Element
   o unique identifier used
                       internally by the IOTP Payment Amount - from
                       Bridge/Existing 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.

   PaymentHandlerDesc  A narrative description of the Brand List Component's Currency
      Amount Element
   o Payment Protocol Identifier - from
                       Handler.

   PaymentHandlerPayId An unique identifier specified by the Brand List Component's
      Pay Protocol Element
   o  Protocol Brand Identifier - from
     (14)              Payment Handler that, if returned by the
                       Consumer in another Payment Scheme Component
                       or by other means, enables the Protocol Brand Element Payment
                       Handler to identify which relates payment is being
                       referred to. It is required whenever it is
                       known.

                       Cf. To "ConsumerPayId" for note about
                       uniqueness.

   PaymentInstrumentId An identifier for a specific payment
     (32)              instrument, e.g. "credit card", "Mondex card
                       for English Pounds". This identifier is
                       fully customizable. It is assumed, that it
                       does not contain confidential information or
                       even an indication to the selected Brand Element, if any
   o  (TradingRoleData) Receiver Organization Identifier
   o  OkFrom, OkTo - identical it. The payment
                       instrument identifier is unique within each
                       payment brand. It is displayed to the entries of
                       Consumer during brand selection.

   PayReceiptNameRefs  Optionally contains element references to
     (32)              other elements (containing payment scheme
                       specific data) that together make up the Order Component
   o  Merchant Organisation Identifier - used for distinction between
      multiple merchants
                       receipt. Note that share each payment scheme
                       defines in its supplement the some elements that
                       must be referenced

                       The IOTP merchant system
   o  Wallet Identifier and/or Pass Phrase
   o  (Brand) Packaged Content - further payment brand description,
      from Application Core should save all
                       the Brand List Component's Brand Element
   o  (Protocol Amount) Packaged Content - further payment protocol
      description, from components referenced so that the Brand List Component's Protocol Amount
      Element
   o  (Protocol) Packaged Content - further
                       payment receipt can be reconstructed when
                       required.

   PayReqNetLocn       The Net Location indicating where an
                       unsecured Payment Request message should be
                       sent if this protocol
      description, from the Brand List Component's Pay Protocol
      Element
   o  (Protocol Brand) Packaged Content - further brand information,
      from the Protocol Brand Element choice is used.

                       The content of this attribute must conform
                       to [URL] and depends on the Brand List Component Transport
                       Mechanism.

   PercentComplete (3) A number between 0 and 100 which relates to indicates
                       the selected Brand Element, if any
   o  (Order) Packaged Content - further order description, from progress of the
      Order Element
   o  three Brand Selection Info Packaged Content elements - copied
      from payment transaction. The
                       values range between 0 and 99 for pending
                       and suspended transactions.

   ProcessState        Contains a Process State Code that
                       indicates the Brand Selection Component on brand dependent purchases
   o  Brand - additional data about current state of the payment brand process
                       being carried out. Valid values are:

                       o  Protocol Amount - additional data about  NotYetStarted. The Payment Request Block
                       has been received but processing of the payment protocol
                       Payment Request has not yet started

                       o  Currency Amount - additional  InProgress. The payment brand and currency
      specific data
   o  Merchant Data - specific data used by the IOTP Payment Bridge
      which transaction is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT GetPaymentInitializationData (BrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   ProtocolBrandPackagedContent*,
   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
     ProtocolBrandId  CDATA  #IMPLIED
     ReceiverOrgId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  OkFrom, OkTo - for insertion in
                       pending. The processing of the Payment Component (Payment)
                       Request Block has started but it is not
                       yet complete.

                       o  (TradingRoleData) Packaged Content - further  (*)Suspended: The payment protocol
      description; transaction has
                       been suspended and can be resumed.

                         This process state is mapped to
                       "InProgress", if it is passed to the Name Attribute
                       counter party's IOTP Application Core.

                       o  CompletedOk. The processing of the packaged contents must
      include "Payment:" as the prefix, for example "Payment:SET-OD". (Payment)
                       Request Block and any following Payment
                       Exchange Blocks has completed successfully.

                       o  (Order) Packaged Content - defaults to the supplied order
      packaged data on omission  Failed. The Merchant might payment processing has finally
                       failed for a Business Error.

                       o  overwrite  ProcessError. This value is only used
                       when the previously returned Merchant Payment Identifier Status Component is being used in
                       connection with an Inquiry Request Trading
                       Block. It indicates there was a new value,
   o  return just now the Merchant Payment Identifier, or
   o  may skip the generation of any Merchant Payment Identifier.

   XML definition:

   <!ELEMENT GetPaymentInitializationDataResponse
   (OrderPackagedContent*,
   TradingRoleDataPackagedContent*) >
   <!ATTLIST GetPaymentInitializationDataResponse
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED>

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Technical
                       Error Codes.

10.1.4  Inquire Authentication Challenge

   This API function inquires any payment protocol specific
   authentication challenge value from in the Request Block which is being
                       processed or some internal processing
                       error. Each party's IOTP Payment Bridge. In
   Baseline IOTP Bridge
                       uses this API function is called by value in order to notify the Merchant or
   Financial Institution, typically. The
                       IOTP Application Core may
   propose a choice of algorithms to about the IOTP Payment Bridge. presence
                       of technical errors.

   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,
   the IOTP Payment Bridge these
                       property types are not used during normal
                       payment processing. E.g., they may ignore apply to
                       payment brand specific transactions or out-
                       of-band failure resolution.

   PropertyDesc        The property description carries the proposal and select some other
   algorithm.
                       respective human readable property (value)'s
                       description.

   PropertyValue       The inquiry actual property value intends automatic
                       post processing.

   ProtocolBrandId (64)This is assumed an identifier to be stateless. E.g., the IOTP
   Application Core may check the returned algorithm used with a
                       particular payment protocol. For example,
                       SET and stop
   transaction processing without notifying EMV have their own well defined, yet
                       different, values for the IOTP Payment Bridge.

   The IOTP Application Core may submit several API calls Brand identifier
                       to be used with each protocol. The valid values
                       of this attribute are defined in the IOTP
   Payment Bridge to build up
                       supplement for the Authentication Request Block. Any
   choice of algorithms should be reduced payment protocol
                       identified by "ProtocolId" that describes
                       how the accepted algorithms
   from earlier API responses.

   Input Parameters

   o  Authentication payment protocol works with IOTP.
                       Identifier - maps to at most one Protocol
                       Brand Identifier.

   ProtocolId  (64)    An identifier for a specific payment
                       protocol and version, e.g. "SETv1.0",
                       "ecash". Valid values are defined by
                       supplements to the authenticator may provide its IOTP specification and
                       they are unique within each payment identifier, i.e., Payment Handler or Merchant Payment
      Identifier.
   o  Wallet Identifier and/or Pass Phrase
   o  set brand.

   ProtocolIds         A sequence of pre-selected algorithms for authentication

   XML definition:

   <!ELEMENT InquireAuthChallenge (Algorithm*) >
   <!ATTLIST InquireAuthChallenge
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters
   o  list Protocol Identifiers

   ProtocolName        A narrative description of Authentication Challenge Packaged Contents - for
      insertion into the IOTP Authentication Request Component
   o  Algorithm Element - for insertion into 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 IOTP Authentication payment protocol being used if
                       problems arise.

   SecPayReqNetLocn    The Net Location indicating where a secured
                       Payment Request Component

   XML definition:

   <!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
   Algorithm) >
   <!ATTLIST InquireAuthChallengeResponse >

   Tables 4 and 5 explain message should be sent if
                       this protocol choice is used.

                       A secured payment involves the attributes and elements; Table 3
   introduces use of a
                       secure channel such as [SSL]/[TLS] in order
                       to communicate with the Error Codes.

10.1.5  Authenticate Payment Handler.

                       The Consumer's IOTP Application Core defers content of this attribute must conform
                       to [URL].

   ReceiverOrgId       The Organization Identification which
                       receives the payment protocol specific
   authentication bridge processing and
                       Trading Role Data PackagedContent.

   StatusDesc  (256)   An optional textual description of the
                       current challenge value to process state in the
   active IOTP Payment Bridge. Alternative authentication algorithms
   might language
                       identified by "xml:lang" that should be tried sequentially or offered
                       displayed to the user Consumer. The usage of this
                       attribute is defined in the payment
                       supplement for selection.

   Note that the IOTP Application Core has payment method being
                       used. Particularly, it provides hints for
                       out-of-band failure resolution. Its length
                       is limited to consider both 256 characters.

   StyleSheetNetLocn   This contains the current
   context net location to a style
                       sheet with visualisation rules for XML
                       encoded data.

   TimeStamp  (30)     The date and the algorithm time in order to determine UTC Format when the responsible IOTP
   Payment Bridge.

   Failed authentication
                       payment transaction has been started.

   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 reported a
                       public item, that might be stored by the Business Error Code which
   might trigger
                       IOTP Application Core.

   xml:lang            Defines the inquiry of language used by the details ("Inquire Process State").

   Input Parameters

   o  Authentication Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Authentication Challenge Packaged Content - copied from the
                       State Description attribute (cf. IOTP Authentication Request Component
   o  Algorithm
                       Specification)

                            Table 3: Attributes

   The following table explains the XML elements in alphabetical
   order:

   Element - copied from             Description

   Algorithm           This contains information which describes
                       an Algorithm that may be used to generate
                       the Authentication response.

                       The algorithm that may be used is
                       identified by the Name attribute (cf. IOTP
                       Specification).

   AuthReqPackagedContent   The Authentication Request
      Component

   XML definition:

   <!ELEMENT Authenticate (AuthReqPackagedContent*, Algorithm) >
   <!ATTLIST Authenticate
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Authentication Response Packaged
                       Content - for insertion into
      the IOTP originates from a Authentication Response Component

   XML definition:

   <!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
   <!ATTLIST AuthenticateResponse >

   Tables 4 and 5 explain
                       (Data/Response) Component's content
                       whereby the attributes and elements; Table 3
   introduces outermost element tags are
                       prefixed with "AuthReq". Its declaration
                       coincides with the Error Codes.

10.1.6  Check Authentication Response

   This API function verifies Packaged Content's
                       declaration (cf. IOTP Specification). It
                       encapsulates the Consumer's payment protocol specific authentication response. In Baseline IOTP challenge
                       value. The content of this API function information is called
   by the Merchant or the Financial Institution. This API call happens
   only if
                       defined in the counterparty has responded with an supplement for a payment
                       protocol.

   AuthResPackagedContent   The Authentication Response Component within the Packaged
                       Content originates from a Authentication
                       Response Block.

   Due to Component's content whereby the authentication's statelessness, all parameters
                       outermost element tags are
   returned to prefixed with
                       "AuthRes".

                       Its declaration coincides with the
                       Packaged Content's declaration (cf. IOTP Payment Bridge. Authentication failure
                       Specification). It encapsulates the
                       authentication response value. The
                       content of this information is
   reported by defined in
                       the supplement for a Process State different payment protocol.

   BrandPackagedContent     Container for further payment brand
                       description. Its content originates from "CompletedOK".

   Input Parameters

   o  Authentication Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Authentication Challenge
                       a Brand Element content whose outermost
                       element tags are prefixed with "Brand".
                       Its declaration coincides with the
                       Packaged Content - generated Content's declaration (cf. IOTP
                       Specification).

   BrandSelBrandInfoPacka This contains any additional data that
   gedContent          may be required by a particular payment
                       brand. It forms the
      Inquire Authentication Challenge (1st content element)
   o  Algorithm Element
   o  Authentication Response Packaged Content - copied from of the Brand
                       Selection Brand Info Element.

   BrandSelProtocolAmount This contains any additional data that
   InfoPackagedContent may be required by a particular payment
                       brand in the format. It forms the
      Authentication Response Component (2nd content element)

   XML definition:

   <!ELEMENT CheckAuthResponse (AuthReqPackagedContent*, Algorithm,
   AuthResPackagedContent*) >
   <!ATTLIST CheckAuthResponse
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process (Authentication) State
   o  Completion Code
   o  Status Description and its language annotation

   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 >

   Tables 4 and 5 explain
                       of the attributes Brand Selection Protocol Amount
                       Info Element.

   BrandSelCurrencyAmount This contains any additional data that
   InfoPackagedContent payment brand and elements; Table 3
   introduces currency specific in
                       the format. It forms the content of the Error Codes.

10.1.7  Cancel Payment

   This API function is
                       Brand Selection Currency Amount Info
                       Element.

   MerchantData        Any merchant related data that might be
                       used by the merchant to notify the local IOTP Payment Bridge resp. for
                       different purposes, e.g., it might
                       contain access keys to some mall keys.
                       Its declaration coincides with the payment modules
                       Packaged Content's declaration (cf. IOTP
                       Specification).

   PackagedContent     Generic Container for non-IOTP data (cf.
                       IOTP Specification).

   PayProtocolPackaged The Pay Protocol Packaged Content
   Content             originates from a Pay Protocol
                       Element's content whereby the outermost
                       element tags are prefixed with
                       "PayProtocol". It contains information
                       about the immediate
   termination protocol which is used by
                       the payment protocol. The content of
                       this information is defined in the
                       supplement for a payment transaction during protocol.Its
                       declaration coincides with the compilation of Packaged
                       Content's declaration (cf. IOTP
                       Specification).

   PaySchemePackagedConte The PayScheme Packaged Content originates
   nt                  from a
   brand list.

   All the involved components may execute shut down operations on
   internal components and data structures.

   This call might happen anytime during the Brand List Compilation
   process, i.e., before the Offer Response Block has been send to the
   Consumer. Normally, no response code is returned.

   Input Parameters

   o  Merchant Payment Identifier - Merchant's unique reference to Scheme Component's content
                       whereby the current payment transaction
   o  intended Payment Status
   o  intended Completion Code
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT CancelPayment EMPTY >
   <!ATTLIST CancelPayment
     MerchantPayId  CDATA  #REQUIRED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CancelPaymentResponse EMPTY >
   <!ATTLIST CancelPaymentResponse >

   Tables 4 and 5 explain outermost element tags are
                       prefixed with "PayScheme". Its
                       declaration coincides with the attributes and elements; Table 3
   introduces Packaged
                       Content's declaration (cf. IOTP
                       Specification). It carries the Error Codes.

   Essentially, payment
                       specific data. The content of this API function implements
                       information is defined in the supplement
                       for a short cut to payment protocol.

   ProtocolAmountPackaged  The Protocol Amount Packaged Content
   Content             originates from a Protocol Amount
                       Element's content whereby the API
   function "Change Process State" (see below) outermost
                       element tags are prefixed with "Amount".
                       Its declaration coincides with specific input
   parameters and skips the returned attribute values, i.e. any call
                       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 form

   <CancelPayment
     MerchantPayId=mmm
     ProcessState=sss
     CompletionCode=ccc
     WalletID=www
     Passphrase=ppp>

   mimics supplement
                       for a payment protocol.

   ProtocolBrandPackagedC   The Protocol Brand Packaged Content
   ontent              originates from a Protocol Brand
                       Element's content whereby the call

   <ChangeProcessState
     PaymentHandlerPayId=mmm
     ProcessState=sss
     CompletionCode=ccc
     ProcessType=Payment
     Wallet=www
     Passphrase=ppp>.

   Note that outermost
                       element tags are prefixed with
                       "ProtocolBrand". Its declaration
                       coincides with the Merchant Payment Identifier is mapped to Packaged Content's
                       declaration (cf. IOTP Specification). It
                       contains information about the Payment
   Handler Payment Identifier. This brand
                       which might be used by the payment
                       protocol. The content of this information
                       is valid because defined in the supplement for a
                       payment protocol.

   ResponsePackagedConten   Container for authentication response
   t                   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).

   TradingRoleDataPackage   The TradingRoleData Packaged Content
   dContent            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
   has not been involved, so far.

10.2  Brand Selection Related API Calls

10.2.1  Find Payment Instrument"

   This API function determines via Consumer about the
                       protocol which instances is used by the payment.
                       The content of this information is
                       defined in the supplement for a Payment Brand,
   e.g., two Mondex cards, are present. payment
                       protocol. The same physical card may even
   represent multiple Name attribute in this
                       packaged contents  must include prefix as
                       "Payment:" to indicate that the payment instruments.

   Essentially,
                       bridge processes this, for example
                       "Payment:SET-OD"

                       The element's declaration coincides with
                       the function Packaged Content's declaration (cf.
                       IOTP Specification).
                             Table 4: Elements

   XML definition: <!ENTITY % AuthReqPackagedContent
   "PackagedContent"> <!ENTITY % AuthResPackagedContent
   "PackagedContent">

   <!ENTITY % BrandPackagedContent         "PackagedContent"> <!ENTITY %
   BrandSelInfoPackagedContent  "PackagedContent"> <!ENTITY %
   BrandSelProtocolAmountPackagedContent
                                           "PackagedContent"> <!ENTITY %
   BrandSelCurrencyAmountPackagedContent
                                           "PackagedContent">
   <!ENTITY % ProtocolAmountPackagedContent
                                           "PackagedContent"> <!ENTITY %
   PayProtocolPackagedContent   "PackagedContent">

   <!ENTITY % TradingRoleDataPackagedContent "PackagedContent">

   <!ENTITY % MerchantData "PackagedContent">

   <!ENTITY % PaySchemePackagedContent     "PackagedContent">

3.3 Process States
   The IOTP Payment API supports two kinds of payment instrument
   inquiries. Either, six different attribute values that
   encode the Protocol Identifier and transaction status from the optional Brand
   Protocol Identifier might be specified on IOTP's point of view, i.e. the input parameter list,
   or they might be unspecified. In
   appropriate point of view at the former case, interface between the IOTP
   Application Core should also provide any necessary Protocol (Amount)
   Packaged Contents. By this the and IOTP Application Core might check for
   valid Payment Instruments for each Bridge. This point of view does not
   completely mimic the alternatives that have been
   offered by the Merchant.

   In the latter case, the API function returns more detailed view on the superset of
   potentially supported actual payment instruments (for some Payment
   Protocol). For each of this Payment Instrument, the valid Payment
   Protocols have to be inquired by the API function "Find
   genuine Existing Payment
   Protocol" and matched by the Software or IOTP Application Core against the Payment Protocols that has been reported by the Merchant.

   Input Parameters

   o  Brand Identifier - copied from Bridge.

   The following three tables distinguish between the Brand List Component's Brand
      Element
   o  payment Protocol Identifier Merchant's,
   Consumer's, and associated Protocol Brand
      Identifier
   o Payment Direction - copied from Handlers' environment. They extend the Brand List Component
   o  Currency Code
   aforementioned explanations towards the mapping between IOTP process
   states and Currency - copied from the Currency Amount
      Element
   o  Payment Amount - copied from internal payment scheme related states of the Currency Amount Element
   o  Consumer Existing
   Payment Identifier - Consumer's unique reference Software/IOTP Payment Bridge.

3.3.1 Merchant

   The Merchant's point of view of payment is limited to the current local
   payment transaction
   o  Wallet Identifier - managed by the initiation being interlaced with order processing because
   IOTP Application Core
   o  (Brand) Packaged Content - further assigns the actual payment brand description;
      copied from processing to the Brand List Component's Brand Element
   o  (Protocol Brand) Packaged Content - further brand information,
      from Payment Handler.

   ProcessState        Description
   NotYetStarted       The Payment Transaction exists within the Protocol Brand Element of
                       IOTP Application Core, i.e., the Brand List Component
      which relates
                       Merchant's shop has already signaled to
                       the 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  Element (Protocol) Packaged Content - further payment protocol
      description, copied from IOTP Application Core that an IOTP
                       transaction has been initiated by the Brand List Component's Pay
      Protocol Element

   XML definition:

   <!ELEMENT FindPaymentInstrument (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolPackagedContent*,
   ProtocolAmountPackagedContent*) >
   <!ATTLIST FindPaymentInstrument
     BrandId  CDATA  #REQUIRED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  The known
                       Consumer.

                       However, neither any API call has been
                       issued to the IOTP Payment Instrument Identifiers, these are internal
      values
   o  The user-defined names of Bridge nor the payment instrument and their
      language encoding
                       IOTP Order Request has been created.

   InProgress          The Existing Payment Software responds with an empty list of
   identifiers, either if IOTP Application changes the process
                       state to this value when 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 issues the latter case,
                       first API call to the Payment Bridge
                       during Brand List compilation.

                       This value indicates that the IOTP 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 some 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 registration of a suitable payment instrument at a
   subsequent step of Consumer.

                       Implicitly, the payment process.

   XML definition:

   <!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) >
   <!ATTLIST FindPaymentInstrumentResponse >
   <!ELEMENT PayInstrument EMPTY >
   <!ATTLIST PayInstrument
     Id  CDATA  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     PayInstName  CDATA  #REQUIRED >

   Tables 4 is also deferred.

   CompletedOk         The IOTP Order Request has been
                       successfully created and 5 explain transmitted to
                       the attributes and elements; Table 3
   introduces Consumer. Actually, this process
                       state indicates only that the Error Codes.

10.2.2  Find Payment Protocol

   Determines which instances order
                       processing has been finished.

                       But it contains no indication about the
                       status of payment protocols are supported the genuine payment, which is
                       accepted by the Payment Handler.

                       However, successful order processing
                       signals the IOTP Application Core that a
   particular
                       payment instrument. On omission 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 instrument,
                       system.

                       Particularly, it is expected that the IOTP
                       Existing Payment Bridge responds with 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 superset Merchant and Payment Handler,
                       any change of payment
   protocols, supported process state will
                       be initiated out-of-band to IOTP, e.g. by all
                       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 instruments.

   Input Parameters

   o  Brand Identifier - copied from will occur.

                       This indication might be used to clear
                       all data about this transaction within
                       the Brand List Component's Brand
      Element
   o Existing Payment Instrument Identifier - derived from Bridge (by
                       "RemovePaymentLog" or
                       "ChangeProcessState") or to reverse any
                       preparation (with the Find Payment
      Instrument responses
   o Payment Direction - copied from Handler
                       out-of-band to IOTP).

                       However, the Brand List Component
   o  Currency Code ideal point of view of IOTP
                       suspects that the genuine payment
                       transaction has been neither started nor
                       initiated.

   ProcessError        The IOTP transaction, i.e. order
                       processing, has failed for some
                       (technical) reason and Currency - copied from it is known that
                       no payment will occur.

                       This indication might be used to clear
                       all data about this transaction within
                       the Currency Amount
      Element
   o Existing Payment Amount - copied from the Currency Amount Element
   o  Consumer Bridge (by
                       "RemovePaymentLog" or
                       "ChangeProcessState") or to reverse any
                       preparation (with the Payment Identifier - Consumer's unique reference Handler
                       out-of-band to IOTP).

                       However, the current ideal point of view of IOTP
                       suspects that the genuine payment
                       transaction
   o  Wallet Identifier - managed by the has been neither started nor
                       initiated.
                             Table 5: Merchant

3.3.2 Consumer

   The Consumer's IOTP Application Core
   o  (Brand) Packaged Content - further restricts its point of view to
   the payment brand description;
      copied from transaction. It is assumed that the Brand List Component's Brand Element
   o  (Protocol Brand) Packaged Content - further IOTP Payment Bridge
   handles the preceding brand information,
      from selection process in a stateless manner.

   NotYetStarted       This encodes the Protocol Brand Element initial process state of the Brand List Component
      which relates to the selected Brand Element, if
                       any
   o  (Protocol Amount) Packaged Content - further IOTP payment protocol
      description, copied from transaction. This value
                       is set during brand selection but it will
                       not change during the Brand List Component's Protocol
      Amount Element
   o  (Protocol) Packaged Content - further payment protocol
      description, copied from whole brand
                       selection process, normally.

   InProgress          With the Brand List Component's Pay
      Protocol Element

   XML definition:

   <!ELEMENT FindPaymentProtocol (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) >
   <!ATTLIST FindPaymentProtocol
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o issuance of the Start Payment
                       Consumer API call, the IOTP Application
                       Core changes the process state to this
                       value.

   Suspended           The supported payment protocol identifiers and associated
      protocol transaction has been
                       suspended. Suspension may occur anywhere
                       during brand identifiers

   XML definition:

   <!ELEMENT FindPaymentProtocolResponse (ProtocolIds*) >
   <!ATTLIST FindPaymentProtocolResponse >
   <!ELEMENT ProtocolIds EMPTY>
   <!ATTLIST ProtocolIds
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED >

   Tables 4 and 5 explain selection (with the
                       Merchant) or payment processing (with the
                       Payment Handler). On resumption, the attributes IOTP
                       Application Core and elements; Table 3
   introduces the Error Codes.

10.2.3  Check IOTP Payment Possibility

   This API function checks
                       Bridge have to use other internal data to
                       decide whether a brand selection or actual
                       payment (both debit and credit)
   can go ahead. It can processing needs to be used, for example, continued,
                       i.e., whether the process state needs to check

   o  if there are sufficient funds available
                       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 to
                       consider any already negotiated
                       conditions in a particular
      currency for an electronic cash brand depended purchase
                       (brand, protocol).

   CompletedOk         The successful payment brand,
   o  whether there is sufficient value space left on has been
                       acknowledged by the Payment Handler, i.e.
                       the successful IOTP Payment Response has
                       been received.

                       Implicitly, this implies successful order
                       processing.

   Failed              The IOTP transaction, i.e. order or
                       payment
      instrument processing, has failed 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. some
                       (business) reason. In addition, either case it may be used to remind is
                       known that the payment will not succeed.

   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.

                             Table 6: Consumer to register a
   suitable

3.3.3 Payment Handler

   The Payment Handler is responsible for the actual payment instrument if an processing.
   New payment transactions are reported by the Consumer with the
   transmission of new IOTP Payment Bridge has been
   selected that contains no valid payment instrument.

   If Request Blocks. IOTP Payment
   Exchange Block are send by the Consumer for payment method bases on external components, e.g., magnetic
   stripe or chip cards, transaction
   continuation and resumption.

   NotYetStarted       This encodes the check accesses 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 medium,
                       process state changes to "InProgress"
                       when 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 Handler starts with the same card reader. If
                       actual processing of the IOTP Payment
                       Request Block.

                       Note that this happens for API internal
   request processing, does not assume that the
                       "StartPaymentPaymentHandler" API function
                       has to unlock these components on
   return. Otherwise, the been called.

   Suspended           The payment may not proceed if transaction has been
                       suspended.

   CompletedOk         The payment has been processed,
                       successfully, i.e. the Consumer
   cancels immediately IOTP Payment
                       Response Block was created and decides
                       transmitted to use another the Consumer.

   Failed              The payment instrument. In transaction, has finally
                       failed for some (business) reason.

                       Note that this event value encodes the payment
                       state reported by the previous IOTP Payment Bridge is not notified about the
   change.

   This call happens immediately after the Consumer's payment instrument
   selection. For example, if
                       on "InquireProcessState". It does neither
                       reflect whether 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, receipt has
                       been inquired nor whether the Consumer should be able IOTP
                       Payment Response Block has been created
                       and submitted to
   hit some 'skip' button, if the Consumer.

   ProcessError        The payment check is part of transaction, has finally
                       failed for some (technical) reason.

                       Note that this value encodes the actual payment protocol, too. Finally,
                       state reported by the IOTP Payment Bridge may provide
   only a subset of these capabilities or may even directly generate a
   successful response without any checks. Alternatively,
                       Bridge. It does not reflect whether some
                       IOTP Error Block has been created and
                       submitted to the callee
   might respond with Consumer.
                             Table 7: Consumer

4.  Payment API Calls

4.1  Brand Compilation Related API Calls

4.1.1  Find Accepted Payment Brand

   This API finction determines the ReqNotSupport error code. payment brands being accepted by the
   Payment Handler on behalf of the Merchant.

   Input Parameters

   o  Brand Identifier - user selection
   o  Payment Instrument Identifier Direction - user selection provided by the IOTP Application Core
   o  Currency Code and Currency Code Type - copied from provided by the selected
      Currency Amount Element IOTP Application
      Core
   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  Protocol Brand Identifier - copied from the selected Protocol
      Brand Element of the Brand List Component which relates to provided by the
      selected Brand Element, if any IOTP Application Core
   o  Consumer  Merchant Payment Identifier - Consumer's Merchant's unique private
      reference to the current payment transaction
   o  Wallet  Merchant Organisation 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 used for distinction between
      multiple merchants that share the selected Pay
      Protocol Element some IOTP merchant system
   o  (Protocol Brand) Packaged Content  Wallet Identifier - copied from managed by the selected
      Protocol Brand Element of IOTP Application Core
   o  Merchant Data - specific data used by the Brand List Component IOTP Payment Bridge
      which
      relates to is managed in the selected Brand Element, if any IOTP Application Core.

   XML definition:

   <!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*> FindAcceptedPaymentBrand (MerchantData*) >
   <!ATTLIST CheckPaymentPossibility
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED FindAcceptedPaymentBrand
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #REQUIRED
     ConsumerPayId
     MerchantPayId  CDATA  #REQUIRED
     WalletID
     MerchantOrgId  CDATA  #IMPLIED
     Passphrase
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  three  Payment Brand Selection Info Packaged Content elements Identifier - for insertion into in the Brand Selection component List
      Component's Brand Element
   o  Payment Brand Name and language annotation - additional data about for insertion in
      the payment brand Brand List Component's Brand Element
   o  Protocol Amount  Payment Brand Logo Net Location - additional data about for insertion in the payment protocol Brand
      List Component's Brand Element
   o  Currency Amount - additional payment brand and currency
      specific data

   XML definition:

   <!ELEMENT CheckPaymentPossibilityResponse
   (BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*) >
   <!ATTLIST CheckPaymentPossibilityResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.2.4  Quit Payment Instrument

   This API function is used by the card holder to notify the local IOTP
   Payment Bridge resp. the payment modules about the immediate
   termination of a payment transaction during the selection of a
   Payment Instrument.

   All the involved components may execute shut down operations on
   internal components and data structures.

   This call might happen anytime during the  Payment Instrument
   Selection process, i.e., before Brand Narrative Description - for insertion in the "Start Payment Consumer" call has
   been issued. Normally, no response code is returned.

   Input Parameters
      Brand List Component's Brand Element
   o  Consumer  (Brand) Packaged Content - further payment brand description
      for insertion in the Brand List Component's Brand Element

   The Existing Payment Identifier - Consumer's unique reference to Software returns an empty list of brand items,
   if it does not support any payment brand/payment protocol combination
   for the current given payment transaction
   o  Wallet Identifier and/or Pass Phrase parameters.

   XML definition:

   <!ELEMENT QuitPaymentInstrument EMPTY FindAcceptedPaymentBrandResponse (BrandItem*) >
   <!ELEMENT BrandItem (BrandPackagedContent*) >
   <!ATTLIST QuitPaymentInstrument
     ConsumerPayId BrandItem
     BrandId  CDATA  #REQUIRED
     WalletID  CDATA
     xml:lang  NMTOKEN  #IMPLIED
     Passphrase
     BrandName  CDATA  #REQUIRED
     BrandLogoNetLocn  CDATA  #REQUIRED
     BrandNarrative  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT QuitPaymentInstrumentResponse EMPTY >
   <!ATTLIST QuitPaymentInstrumentResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   Essentially, this API function implements a short cut to the

4.1.2  Find Accepted Payment Protocol

   This API function "Change Process State" (see below) with specific input
   parameters and skips determines the returned attribute values, i.e. any call instances of
   the form

   <QuitPaymentInstrument
     ConsumerPayId=ccc
     WalletID=www
     Passphrase=ppp>

   mimics the call

   <ChangeProcessState
     ConsumerPayId=ccc
     ProcessState=ProcessError
     ProcessType=Payment
     Wallet=www
     Passphrase=ppp>.

10.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.

10.3.1  Start Payment Consumer

   Initiates a payment at the Consumer side. The IOTP Payment Bridge and protocols (and
   optionally the Existing Payment Software perform all necessary initialization
   and preparation for payment transaction processing. This includes the
   reservation of external periphery. E.g., the Consumer's chip card
   reader needs to be protected against access from other software
   components, the insertion of the chip card may be requested, the
   Internet connection may be re-established, or brands) being accepted by the Payment Handler may
   open a mutual exclusive session to the security hardware.

   The IOTP Payment Bridge monitors the payment progress and stores
   on behalf of the
   current payment states such that resumption - even after power
   failures - remains possible. Merchant. The resumption API call provides only a
   subset of function might be called in two
   variants:

      o With the Brand Identifier set on the input parameters of parameter list: The
      function responds with the start payment call and refers protocols that fits to the payment transaction through the individual party's payment
   identifier.

   The IOTP Payment Bridge may remain accessible for payment processing
   without
      submitted brand.

      o Without any further supplement of wallet identifiers and pass phrases
   until Brand Identifier - that allows the transaction's payment status changes to some status
   different from 'InProgress'. Nevertheless, omission of the IOTP Application Core
   has to remember both attribute values for further
      "Find Accepted Payment Brand" API call issuance (cf. Section 4.1.1): This
      function responds with both the supported brand identifiers and might be requested to supply this information on subsequent API
   calls. But it is recommended that
      the IOTP Application Core forgets
   these values after any payment transaction status change (Change
   Process State) and removes at least their plain text representations. protocols being related by the Brand Elements.

   Input Parameters

   o  Brand Identifier - copied from the selected Brand Element returned by "Find Accepted Payment Brand"
   o  Payment Instrument Identifier - the user selection Direction
   o  Currency Code and Currency
   o  Payment Amount
   o  Merchant Payment Identifier - copied from Merchant's unique private
      reference to the selected Currency
      Amount Element 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 Amount Brand"; this elements are
      only provided iff the Brand Identifier is set
   o  Merchant Data - copied from specific data used by the selected Currency IOTP Payment Bridge
      which is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
   MerchantData?) >
   <!ATTLIST FindAcceptedPaymentProtocol
     BrandId  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount
      Element  CDATA  #REQUIRED
     MerchantPayId  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  Payment Direction - copied from the Brand List Component
   o Protocol Identifier - copied from for insertion in the selected Payment Brand List
      Component's Pay Protocol Element
   o  Protocol Brand Identifier - copied from for insertion in the Brand Protocol Brand
      Element of the Brand List Component which relates to the
      selected Component's Brand Element, if any Element
   o  OkFrom, OkTo - copied from the  Payment Component Protocol Name and language annotation- for insertion in
      the Brand List Component's Pay Protocol Element
   o  Consumer  Payment Identifier Request Net Location - Consumer's unique reference to for insertion in the current payment transaction
   o  Wallet Identifier and/or Pass Phrase Brand List
      Component's Pay Protocol Element
   o  Call Back Function  Secured Payment Request Net Location - used for end user notification/logging
      purposes
   o  Call Back Language List. This list is required if insertion in the Call Back
      Function is set
      Brand List Component's Pay Protocol Element
   o  Database Function  Brand Item List (cf. Section 4.1.1) - there must be at least
      one element if no brand identifier has been provided on the IOTP Payment bridge may refer to this
      API function for data management purposes
      input parameter list.
   o  (Brand)  (Protocol Amount) Packaged Content - further payment brand description;
      copied from for insertion in the selected Brand Element's content
      List Component's Protocol Amount Element
   o  (Protocol Brand)  (Pay Protocol) Packaged Content - further information; copied
      from the Protocol Brand Element of for insertion in the Brand
      List Component
      which relates Component's Pay Protocol Element
   o  Currency Amount element - quite similar to the selected Brand Element, if any
   o  (Protocol Amount) Packaged Content definition in
      [IOTP], that contain
      - further payment protocol
      description; copied from refined Currency Code and Currency - for insertion in the selected Protocol
        Brand List Component's Currency Amount Element's
      content
   o  (Protocol) Packaged Content Element
      - further payment protocol
      description; copied from refined Payment Amount - for insertion in the selected Pay Protocol Element's
      ncontent Brand List
      Component's Currency Amount Element
   o  (Order) Packaged Content  Brand - further order description, copied
      from there must be at least one element in each Protocol
      Item if no brand identifier has been provided on the Order Component input
      parameter list.

   XML definition:

   <!ELEMENT StartPaymentConsumer (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   OrderPackagedContent*) FindAcceptedPaymentProtocolResponse (ProtocolItem+,
   BrandItem*) >
   <!ELEMENT ProtocolItem (ProtocolAmountPackagedContent*,
   PayProtocolPackagedContent*
   CurrencyAmount+, Brand*,ProtocolBrand*)>
   <!ATTLIST StartPaymentConsumer
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED ProtocolItem
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     ConsumerPayId
     xml:lang  NMTOKEN  #IMPLIED
     ProtocolName  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase
     PayReqNetLocn  CDATA  #IMPLIED
     CallBackFunction
     SecPayReqNetLocn  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction >

   <!ELEMENT Brand EMPTY >
   <!ATTLIST Brand
     BrandId  CDATA  #IMPLIED  #REQUIRED >

   Output Parameters

   o  Time Stamp
   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.

   XML definition:

   <!ELEMENT StartPaymentConsumerResponse
   (PaySchemePackagedContent*) CurrencyAmount EMPTY >
   <!ATTLIST StartPaymentConsumerResponse
     TimeStamp CurrencyAmount
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #IMPLIED
     Amount  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.3.2  Start Payment Payment Handler

   Initiates a payment 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.

   The IOTP

4.1.3  Get Payment Bridge may remain accessible for payment processing
   without any further supplement of wallet/till identifiers and pass
   phrases until Initialization Data

   This API function provides the transaction's payment status changes to some status
   different from 'InProgress'. Nevertheless, remaining initialization data being
   required by the IOTP Application Core
   has to remember Consumer's or Payment Handler's Existing Payment
   Software. This function might be called both attribute values for further API call issuances "brand dependent"
   and might be requested to supply "brand independent" transaction types. In ether case, this information on subsequent API
   calls. But it
   function is recommended, that the IOTP Application Core forgets
   these values after any payment transaction status change (Change
   Process State) and removes at least their plain text representations. called with one particular brand.

   Input Parameters

   o  Brand Identifier - copied from the Consumer selected Brand
      Element returned by "Find Accepted Payment Brand"
   o  Consumer  Merchant Payment Identifier - copied from Merchant's unique private
      reference to the payment transaction
   o  Payment Scheme
      Component Direction
   o  Currency Code and Currency - copied from the Consumer selected Brand List Component's
      Currency Amount Element
   o  Payment Amount - copied from the Consumer selected Brand List Component's Currency
      Amount Element
   o  Payment Direction - copied from the Brand List Component
   o Protocol Identifier - copied from the Consumer selected
      Payment Brand List Component's
      Pay Protocol Element
   o  Protocol Brand Identifier - copied from the Brand Protocol
      Element of the Brand List Component Element
      which relates to the
      Consumer selected Brand Element, if any

   o  (TradingRoleData) Receiver Organization Identifier

   o  OkFrom, OkTo - copied from identical to the Payment entries of the Order Component
   o  Payment Handler

   Merchant Payment Identifier - Payment Handler's unique
      reference to the current payment transaction

   o  Merchant Organisation Identifier -  copied from used for distinction between
      multiple merchants that share the Merchant's
      Organisation Element some IOTP merchant system
   o  Wallet Identifier - renaming to till identifier neglected - and/or Pass Phrase

   Protocol Brand Element

   o  Call Back Function  (Brand) Packaged Content - used for end user notification/logging
      purposes
   o  Call Back Language List. This list is required if further payment brand description,
      from the call back
      function is set Brand List Component's Brand Element
   o  Database Function  (Protocol Amount) Packaged Content - the IOTP Payment bridge may refer to this
      API function for data management purposes further payment protocol
      description, from the Brand List Component's Protocol Amount
      Element
   o  (Brand)  (Pay Protocol) Packaged Content - further payment brand description;
      copied protocol
      description, from the Consumer selected Brand Element's content List Component's Pay Protocol
      Element

   o  (Protocol Brand) Packaged Content - further information; copied brand information,
      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 any

   o  (Protocol)  (Order) Packaged Content - further payment protocol
      description; copied order description, 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".
      Order Element
   o  Three  three Brand Selection Info Packaged Content Elements 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  (Payment Scheme) Packaged Content.  Merchant Data - specific data used by the IOTP Payment Bridge
      which is managed in the IOTP Application Core.

   XML definition:

   <!ELEMENT StartPaymentPaymentHandler (BrandPackagedContent*,
   ProtocolBrandPackagedContent*, GetPaymentInitializationData (ProtocolBrand?
   BrandPackagedContent*
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*,
   PayProtocolPackagedContent*,
   OrderPackagedContent*,
   BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*,
   TradingRoleDataPackagedContent*,
   PaySchemePackagedContent*)
   MerchantData*) >
   <!ATTLIST StartPaymentPaymentHandler GetPaymentInitializationData
     BrandId  CDATA  #REQUIRED
     ConsumerPayId
     MerchantPayId  CDATA  #IMPLIED  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     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
     PaymentHandlerPayId  CDATA  #REQUIRED
     MerchantOrdId  CDATA  #REQUIRED
     WalletID
     ReceiverOrgId  CDATA  #IMPLIED
     Passphrase
     MerchantOrgId  CDATA  #IMPLIED
     CallBackFunction
     WalletID  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Time Stamp
   o  Continuation Status
   o  (Payment Scheme) Packaged Content  OkFrom, OkTo - for insertion into in the Payment Scheme Component
   o  (TradingRoleData) Packaged Content - further payment protocol
      description; the Name Attribute of the IOTP Payment Exchange Block
   The response message packaged Content
      element must contain payment schema data if include "Payment:" as the
   continuation status signals "Continue". The IOTP Application Core is
   allowed prefix,
      for example "Payment:SET-OD".
   o  (Order) Packaged Content - defaults to reissue this request several times on failed analyses of the response. supplied order
      packaged content if omitted.

   XML definition:

   <!ELEMENT StartPaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) GetPaymentInitializationDataResponse
   (OrderPackagedContent*,
   TradingRoleDataPackagedContent*) >
   <!ATTLIST StartPaymentPaymentHandlerResponse
     TimeStamp GetPaymentInitializationDataResponse
     OkFrom  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED >
     OkTo  CDATA  #IMPLIED>

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.3.3  Resume Payment Consumer

4.1.4  Inquire Authentication Challenge

   This API function resumes a previously suspended payment at the
   Consumer side. Resumption includes the internal inquiry of the
   payment transaction data, e.g., inquires any payment amount, protocol identifier,
   and the whole initialization as it has been applied on specific
   authentication challenge value from the Start IOTP Payment Consumer Bridge. In
   Baseline IOTP this API request. 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 remain accessible for payment processing
   without any further supplement of wallet identifiers and pass phrases
   until ignore the transaction's payment status changes to proposal and select some status
   different from 'InProgress'.

   It other
   algorithm.

   The inquiry is up assumed to be stateless. E.g., the IOTP Application
   Core to decide whether a may check the returned algorithm and stop transaction processing
   without notifying the IOTP Payment
   Request Block or a Bridge.

   The IOTP Application Core may issue several API calls to the IOTP
   Payment Exchange Block needs Bridge to be generated. One
   indicator might be build up the receipt IOTP Authentication Request Block. Any
   subsequently submitted choice of a previous Payment Exchange Block
   from algorithms should be reduced by the
   accepted algorithms from earlier API responses.

   The IOTP Payment Handler, e.g., Bridge responds with the knowledge of Business Error Code if it
   does not provide any (more) authentication algorithms and challenges.

   Input Parameters

   o  Authentication Identifier - the authenticator may provide its
      payment identifier, i.e., Payment Handler or Merchant Payment
      Identifier.

   Input Parameters

   o  Consumer Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Database Function - the IOTP Payment bridge may refer to this
      API function for data management purposes, particularly, to
      inquire the remaining payment parameters and the current
      payment state Phrase
   o  set of pre-selected algorithms for authentication

   XML definition:

   <!ELEMENT ResumePaymentConsumer EMPTY InquireAuthChallenge (Algorithm*) >
   <!ATTLIST ResumePaymentConsumer
     ConsumerPayId InquireAuthChallenge
     AuthenticationId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme)  list of Authentication Challenge Packaged Content Contents - for
      insertion in the
      Payment Scheme Component of into the next IOTP message (Payment
      Exchange or Authentication Request Block).

   The IOTP Application Core is allowed to reissue this request several
   times on failed analyses of the response. However, Component
   o  Algorithm Element - for insertion into 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 Authentication
      Request Block to the
   Payment Handler. Component

   XML definition:

   <!ELEMENT ResumePaymentConsumerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST ResumePaymentConsumerResponse
     PaymentHandlerPayId  CDATA  #IMPLIED
     ContStatus  (End|Continue)  #REQUIRED InquireAuthChallengeResponse (AuthReqPackagedContent*,
   Algorithm) >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.3.4  Resume Payment Payment Handler

   This API function resumes a payment at the Payment Handler side.

4.1.5  Authenticate

   The Consumer's IOTP Payment Bridge may remain accessible for Application Core defers payment protocol specific
   authentication processing
   without any further supplement of wallet/till identifiers and pass
   phrases until the transaction's payment status changes to some status
   different from 'InProgress'.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
   o  Wallet Identifier - renaming current challenge value to till identifier neglected - and
      Pass Phrase
   o  Database Function - the
   active IOTP Payment bridge may refer Bridge. Alternative authentication algorithms
   might be tried sequentially or offered to this
      API function the user for data management purposes, particularly, selection.

   Note that the IOTP Application Core has to
      inquire 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 remaining payment parameters and inquiry of the current
      payment details ("Inquire Process State").
   Final failures might be encoded by the process state "Failed".

   Input Parameters

   o  (Payment Scheme)  Authentication Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Authentication Challenge Packaged Content - copied from the Payment
      Scheme
      IOTP Authentication Request Component of
   o  Algorithm Element - copied from the received IOTP message (Payment Exchange
      or Authentication Request Block).
      Component

   XML definition:

   <!ELEMENT ResumePaymentPaymentHandler
   (PaySchemePackagedContent*) Authenticate (Algorithm, AuthReqPackagedContent*) >
   <!ATTLIST ResumePaymentPaymentHandler
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId Authenticate
     AuthenticationId  CDATA  #IMPLIED  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme)  Authentication Response Packaged Content - for insertion in the
      Payment Scheme Component of the next Payment Exchange Block.

   The response message contains 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. However, into
      the IOTP Payment Bridge might reject the
   resumption request by using the "AttNotSupp" Error Code "naming" the
   Consumer Payment Identifier attribute. Then the Payment Handler has
   to apply normal error processing to the transaction. Authentication Response Component

   XML definition:

   <!ELEMENT ResumePaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST ResumePaymentPaymentHandlerResponse
     PaymentHandlerPayId  CDATA  #REQUIRED
     ContStatus  (End|Continue)  #REQUIRED AuthenticateResponse (AuthResPackagedContent*) >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.3.5  Continue Process

4.1.6  Check Authentication Response

   This API function passes one verifies the Consumer's payment protocol specific
   authentication response. In Baseline IOTP Payment Scheme Component,
   i.e., this API function is called
   by the encapsulated Packaged Content elements, received from Merchant (or the
   counterparty (e.g. Consumer) to Financial Institution). It is called only if
   the counter party has responded with an IOTP Payment Bridge 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 responds
   with response) are submitted to the next IOTP Payment Scheme Component for submission to the
   counterparty. Bridge.
   Authentication failure is reported by a Process State different from
   "CompletedOK".

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment  Authentication Identifier
   o  Process (Transaction) Type which distinguishes between Payments
      and Inquiries.
   o  Wallet Identifier and/or Pass Phrase
   o  (Payment Scheme)  Authentication Challenge Packaged Content - generated by
      previous "Inquire Authentication Challenge" API call
   o  Algorithm Element
   o  Authentication Response Packaged Content - copied from the Payment
      Scheme
      Authentication Response Component of the received Payment Exchange Block or from
      the Error Block.

   Each party should set all know Payment Identifiers. At least, each
   party must set the own Payment Identifier.

   XML definition:

   <!ELEMENT ContinueProcess (PaySchemePackagedContent+) CheckAuthResponse (Algorithm, AuthReqPackagedContent*,
   AuthResPackagedContent*) >
   <!ATTLIST ContinueProcess
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId CheckAuthResponse
     AuthenticationId  CDATA  #IMPLIED
     ProcessType  (Payment | Inquiry) 'Payment'  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Continuation Status  Current Process (Authentication) State
   o  (Payment Scheme) Packaged Content - for insertion in the
      Payment Scheme Component of the next Payment Exchange Block or
      final Payment Response Block

   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.  Completion Code
   o  Status Description and its language annotation

   XML definition:

   <!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) CheckAuthResponseResponse EMPTY >
   <!ATTLIST ContinueProcessResponse
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.3.6  Change Process State

   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, CheckAuthResponseResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)#REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Tables 4 and processing errors.
   Notification happens by requesting the intended process state. The
   IOTP Payment Bridge processes 5 explain the status change attributes and reports elements; Table 3
   introduces the
   result. Error Codes.

4.2  Brand Selection Related API Calls

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.

   The IOTP Application Core has to analyze any returned process
   status in order supplies possible payment brand and payment
   protocol to check whether the IOTP Payment Bridge that has agreed
   or declined the status switch. E.g., the Process State "CompleteOk"
   may lead to be considered when
   the IOTP Payment Status "Failed" if the Bridge searches for appropriate payment transaction
   has already failed. Alternatively, the function may issue an Error
   Response ("BusinessError") if instruments.
   This set represents the intended and current (sub)set of payment status
   are incompatible.

   Transaction Suspension is notified alternatives being
   supported by the newly introduced Process
   State "Suspended". The other attribute values have been borrowed from Merchant. If the IOTP specification.

   This API Application Cote has multiple
   possible payment brand/protocol, it can call this function might be called by the Consumer, Merchant, or in turn.

   The Existing Payment Handler for each Software responds with PayInstrument Elements
   with empty PayInstId attributes if it does not distinguish between
   different payment transaction anytime after instruments for the
   issuance of "CheckPaymentPossibility" to particular payment
   alternatives.

   Note that the IOTP Payment Bridge by
   the Consumer, the issuance of "GetPaymentInitializationData" by the
   Merchant, or API assumes that the issuance values of "StartPaymentPaymentHandler" by the
   Payment Handler.

   The Process States "Failed" attributes
   BrandId, ProtocolId, ProtocolBrandId and "ProcessError" are final in the sense
   that they can not be changed on subsequent calls. However, currency amount suffice
   for the determination of the API
   function should not return with an error code if such an incompatible
   call has been issued. Instead it should report appropriate Packaged Content Element
   that will be transmitted to the old unchanged
   Process State. Payment Handler later on.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment  Brand Identifier - any known identifier should be supplied. Merchant should map
      their payment identifier to Payment Handler copied from the Brand List Component's Brand
      Element
   o  Payment Protocol Identifier and associated Protocol Brand
      Identifier
   o  intended  Payment Status Direction - copied from the Brand List Component
   o  intended Completion  Currency Code
   o  Process (Transaction) Type which distinguishes between Payments and Inquiries. 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 and/or Pass Phrase - 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  Element (Protocol) Packaged Content - further payment protocol
      description, copied from the Brand List Component's Pay
      Protocol Element

   XML definition:

   <!ELEMENT ChangeProcessState EMPTY FindPaymentInstrument (BrandPackagedContent*,
     ProtocolBrand?,
     PayProtocolPackagedContent*,
     ProtocolAmountPackagedContent*) >
   <!ATTLIST ChangeProcessState
     ConsumerPayId FindPaymentInstrument
     BrandId  CDATA  #IMPLIED
     PaymentHandlerPayId  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     CompletionCode  NMTOKEN  #IMPLIED
     ProcessType  (Payment | Inquiry) 'Payment'
     WalletID
     ConsumerPayId  CDATA  #IMPLIED
     Passphrase  #REQUIRED
     WalletID  CDATA  #IMPLIED >

   Output Parameters

   o  Process State and Percent Complete
   o  Completion Code  The known Payment Instrument Identifiers, these are internal
      values
   o  Status Description  The user-defined names of the payment instrument and its their
      language annotation 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.

   XML definition:

   <!ELEMENT ChangeProcessStateResponse FindPaymentInstrumentResponse (PayInstrument*) >

   <!ELEMENT PayInstrument EMPTY >
   <!ATTLIST ChangeProcessStateResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     PercentComplete PayInstrument
     Id  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc
     PayInstName  CDATA  #IMPLIED  #REQUIRED >

   Tables 4 and 5 explain 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

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

   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 bases on external components, e.g., magnetic
   stripe or chip cards, and the attributes and elements; Table 3
   introduces check accesses the Error Codes.

10.4  General Inquiry API Calls

   The following calls are not necessarily assigned to a medium, the existing
   payment
   transaction and method should not mutually exclusive lock system resources,
   e.g., serial port or modem, that may also be issued at any time. There are no dependencies
   on any required by other calls.

10.4.1  Inquire
   Existing Payment Log

   This API call Software, e.g., multiple payment software components
   may be used share the same card reader. If this happens for API internal
   request processing, the function has to unlock these components prior
   to browse return. Otherwise, the completed payment transaction
   as well as to determine may not proceed if the set of pending or suspended transactions
   that are awaiting their completion or resumption.

   It is up Consumer
   cancels immediately and decides to use another payment instrument. In
   this event the previous IOTP Payment Bridge and is not notified about the Existing Payment Software
   whether they support such inquiries. Therefore, it
   change.

   This function call happens immediately after the Consumer's payment
   instrument selection. For example, if the payment instrument is recommended a
   chip card, that is not inserted in the IOTP Application Core implements the required data base
   capabilities and provides chip card reader, the inquiry mechanisms on Consumer
   may be prompted for its own. insertion. However, the IOTP Application Core might use this API function Consumer should be
   able to extend its
   own knowledge base about hit some 'skip' button, if the transactions. 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

   o  Brand Identifier - omission defaults to any user selection
   o  Payment Instrument Identifier - omission defaults to any
   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - omission defaults to any
   o  Process State - omission defaults to any user selection
   o  Completion  Currency Code - omission defaults to any
   o  Payment Direction - omission defaults to any
   o  Time Stamp From - omission defaults to 1900-01-
      01T00:00:00.000Z+0
   o  Time Stamp To - omission defaults to 9999-12-31T23:59:59.999Z+0
   o and Currency Code Type - omission defaults to any
   o copied from the selected
      Currency Code - omission defaults to any
   o Amount From - omission defaults to 0 Element
   o  Payment Amount To - omission defaults to unlimited copied from the selected Currency Amount
      Element
   o  Ok From  Payment Direction - omission defaults to 1900-01-01T00:00:00.000Z+0 copied from the selected Trading Protocol
      Option Block
   o  Ok To  Protocol Identifier - omission defaults to 9999-12-31T23:59:59.999Z+0 copied from the selected Pay Protocol
      Element
   o  Protocol Brand Identifier - omission defaults copied from the selected Protocol
      Brand Element of the Brand List Component which relates to the
      selected Brand Element, if any
   o  Maximal Number of transaction to report  Consumer Payment Identifier - omission defaults Consumer's unique reference to
      unlimited
      the current payment transaction
   o  Wallet Identifier and/or Pass Phrase

   All input arguments are used to define restrictions for the inquiry
   of
   o  (Brand) Packaged Content - copied from the payment log. The OkFrom and OkTo attributes are used to
   inquire payment transactions with a non-empty intersection with selected Brand
      Element
   o  (Protocol Amount) Packaged Content - copied from the
   payment's validity time range which was supplied by selected
      Protocol Amount Element
   o  (Protocol) Packaged Content - copied from the IOTP Payment
   Component.

   However, there exists some risk of user unfriendliness: The user
   initiates selected Pay
      Protocol Element
   o  (Protocol Brand) Packaged Content - copied from the inquiries by selected
      Protocol Brand Element of the IOTP Application Core Brand List Component which defers the
   inquiries
      relates to the IOTP Payment Bridges. Then the IOTP Application Core
   might be requested for appropriate wallet identifiers and pass
   phrases. selected Brand Element, if any

   XML definition:

   <!ELEMENT InquirePaymentLog EMPTY > CheckPaymentPossibility (BrandPackagedContent*,
   ProtocolBrand?
   ProtocolAmountPackagedContent*,
   PayProtocolPackagedContent*>
   <!ATTLIST InquirePaymentLog CheckPaymentPossibility
     BrandId  CDATA  #IMPLIED  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #IMPLIED
     AmountFrom  CDATA  #IMPLIED
     AmountTo  #REQUIRED
     Amount  CDATA  #IMPLIED  #REQUIRED
     ProtocolId  CDATA  #IMPLIED
     OkFrom  CDATA  #IMPLIED
     OkTo  CDATA  #IMPLIED
     TimeStampFrom  CDATA  #IMPLIED
     TimeStampTo  CDATA  #IMPLIED
     NumberofPayments  #REQUIRED
     ConsumerPayId  CDATA  #IMPLIED  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  List  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

   XML definition:

   <!ELEMENT CheckPaymentPossibilityResponse
   (BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*) >
   <!ATTLIST CheckPaymentPossibilityResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

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.

4.3.1  Start Payment Consumer

   This API function initiates the genuine 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 inquired payments. Information for each the following input parameter to the
   associated resumption API function and refers to the payment
   transaction is provided on: through the party's payment identifier.

   Input Parameters

   o  Brand Identifier - copied from the selected Brand Element
   o  Payment Instrument Identifier
   o  Consumer Payment Identifier, Payment Handler Payment
      Identifier - the 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
   o  Time Stamp
   o  Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation - copied from the Brand List Component
   o  Protocol Identifier - copied from the selected Payment Protocol
      Element
   o  Protocol Brand Identifier 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 expiration dates 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 Content - further payment brand
      description description;
      copied from the selected Brand Element's content
   o  (Protocol Brand) Amount) Packaged Content Content - further payment
      brand description protocol
      description; copied from the selected Protocol Amount Element's
      content
   o  (Protocol Amount)  (Payment Protocol) Packaged Content Content - further payment protocol description
      description; copied from the selected Pay Protocol Element's
      content
   o  (Pay Protocol)  (Order) Packaged Content Content - further payment
      protocol description order description, copied
      from the Order Component

   XML definition:

   <!ELEMENT InquirePaymentLogResponse(PaymentItem*) >
   <!ATTLIST InquirePaymentLogResponse >
   <!ELEMENT PaymentItem StartPaymentConsumer (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolBrand?
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*)
   PayProtocolPackagedContent*,
   OrderPackagedContent*) >
   <!ATTLIST PaymentItem StartPaymentConsumer
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #REQUIRED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     TimeStamp
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED >

   Generally, the IOTP Payment Bridge should respond as many attributes
   as possible.

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.4.2  Remove Payment Log

   This API function is used by the individual parties to remove
   specific entries from the Payment Log file. The IOTP application core
   notifies the IOTP Payment Bridge resp. the payment modules that a
   particular transaction record is not needed any more and should be
   removed.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known identifier should be provided
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT RemovePaymentLog EMPTY >
   <!ATTLIST RemovePaymentLog
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED >

   Output Parameters

   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion into the
      Payment Scheme Component of the IOTP Payment Request Block

   The IOTP Application Core is allowed to reissue this request several
   times on failed analyses of the response.

   XML definition:

   <!ELEMENT RemovePaymentLogResponse EMPTY StartPaymentConsumerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST RemovePaymentLogResponse StartPaymentConsumerResponse
     ContStatus  (End|Continue)  #REQUIRED >
   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   Note that the Merchant Payment Identifier is mapped to the Payment
   Handler Payment Identifier. This is valid because the Payment Handler
   has not been involved, so far.

10.4.3 Error Codes.

4.3.2  Start Payment Instrument Inquiry

   The Payment Instrument Inquiry Handler

   This API function retrieves initializes the properties
   of Consumer initiated payment
   transaction at 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 Handler's side. Similar to the Payment
   instrument could not uniquely determined, Consumer's
   system, the IOTP Payment Bridge may
   provide suitable dialogs for user input.

   This API function might be used during problem resolution with the
   Customer Care Provider of the issuer of and the Existing Payment Software
   perform all necessary initialization and preparation for payment instrument, in
   order to inquire payment instrument specific values.
   transaction processing.

   Input parameters Parameters

   o  Brand Identifier  - copied from the Consumer selected Brand
      Element
   o  Consumer Payment Instrument 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  Wallet Identifier - renaming to till identifier neglected -
      and/or Pass Phrase
   o  Property Type List  Call Back Function - sequence of values whose language used for end user notification/logging
      purposes
   o  Call Back Language List. This list is
      identified by xml:lang required if the call back
      function is set
   o  (Brand) PackagedContent Packaged Content - further payment brand
      description description;
      copied from the Consumer selected Brand Element's content
   o  (Protocol Brand) PackagedContent Packaged Content - further payment
      brand information 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) PackagedContent Packaged Content - further payment protocol description
      description; copied from the Consumer selected Protocol Amount
      Element's content
   o  (Pay Protocol) PackagedContent  (Protocol) Packaged Content - further payment protocol description

   The codes in
      description; copied from the property type list are of two types: Consumer selected Pay Protocol
      Element's content
   o  generic codes which apply to all  (TradingRoleData) Packaged Content - further payment methods but might be
      unavailable
   o  Payment Brand specific codes.

   Generic codes for protocol
      description; the Property Type List are:

   Property Type         Meaning
   Balance               Current balance
   Limit                 Maximum balance
   PaymentLimit          Maximum payment transaction limit
   Expiration            Expiration date
   Identifier            Issuer assigned identifier Name Attribute of the payment
                         instrument. Usually, it does not match with packaged contents must
      include "Payment:" as 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 prefix, for example "Payment:SET-OD".
   o  Three Brand Selection Info Packaged Content Elements - copied
      from the oldest entry.
   PayAmountn            Payment Amount of Brand Selection Component
   o  Brand - additional data about the n-th recorded payment
                         transaction, n may negative
   PayPartyn             Remote party of brand
   o  Protocol Amount - additional data about the n-th payment recorded
                         transaction, n may negative
   PayTimen              Time of the n-th protocol
   o  Currency Amount - additional payment recorded
                         transaction, n may negative brand and currency
      specific data
   o  (Payment Scheme) Packaged Content.

   XML definition:

   <!ELEMENT PaymentInstrumentInquiry StartPaymentPaymentHandler (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolBrand?,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*)
   PayProtocolPackagedContent*,
   BrandSelBrandInfoPackagedContent*,
   BrandSelProtocolAmountInfoPackagedContent*,
   BrandSelCurrencyAmountInfoPackagedContent*,
   TradingRoleDataPackagedContent*,
   PaySchemePackagedContent*) >
   <!ATTLIST PaymentInstrumentInquiry StartPaymentPaymentHandler
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId
     ConsumerPayId  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #REQUIRED
     Amount  CDATA  #REQUIRED
     PayDirection  (Debit|Credit)  #REQUIRED
     ProtocolId  CDATA  #REQUIRED
     ProtocolBrandId
     OkFrom  CDATA  #REQUIRED
     OkTo  CDATA  #REQUIRED
     PaymentHandlerPayId  CDATA  #REQUIRED
     MerchantOrgId  CDATA  #IMPLIED
     PropertyTypeList  NMTOKENS  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED >

   Output parameters Parameters

   o  a list of zero or more unavailable property values whose
      language are identified by xml:lang.  Continuation Status
   o  a list  (Payment Scheme) Packaged Content - for insertion into the
      Payment Scheme Component of zero or more sets 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 "Properties Types", "Property
      Values" and "Property Descriptions"
   the response.

   XML definition:

   <!ELEMENT PaymentInstrumentInquiryResponse
   (PaymentInstrumentProperty*) >
   <!ATTLIST PaymentInstrumentInquiryResponse
     xml:lang  NMTOKEN  #REQUIRED
     UnavailablePropertyList NMTOKENS  #IMPLIED >

   <!ELEMENT PaymentInstrumentProperty EMPTY StartPaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST PaymentInstrumentProperty
     PropertyType  NMTOKEN  #REQUIRED
     PropertyValue  CDATA  #REQUIRED
     PropertyDesc  CDATA StartPaymentPaymentHandlerResponse
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.4.4  Inquire Pending

4.3.3  Resume Payment Consumer

   This API call reports function resumes a previously suspended payment at the presence
   Consumer side. Resumption includes the internal inquiry of pending the
   payment transactions.
   It does not respond further transaction details. Note that 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 Bridge has equest Block or a IOTP Payment Exchange Block needs to respond without be
   generated. One indicator might be the supplement receipt of a previous IOTP
   Payment Exchange Block from the Payment Handler, e.g., the knowledge
   of any pass
   phrase. the Payment Handler Payment Identifier.

   Input Parameters

   o  Consumer Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Call Back Function - used for end user notification/logging
      purposes

   XML definition:

   <!ELEMENT InquirePendingPayment ResumePaymentConsumer EMPTY >
   <!ATTLIST InquirePendingPayment
     WalletId ResumePaymentConsumer
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED >

   Output Parameters

   o  Response Code encodes  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion in the presence
      Payment Scheme Component of pending payment
      transactions. the next IOTP message (Payment
      Exchange or Request Block).

   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.

   XML definition:

   <!ELEMENT InquirePendingPaymentResponse EMPTY ResumePaymentConsumerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST InquirePendingPaymentResponse
     ResponseCode  (Yes|No) ResumePaymentConsumerResponse
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.5

4.3.4  Resume Payment Related Inquiry API Calls

10.5.1  Check Payment Receipt Handler

   This API function is used by the Consumer and might be used by the
   Payment Handler to check the consistency, validity, and integrity of
   an IOTP Payment Receipt whereby the receipt might consists of
   attributes of the Payment Receipt Components and additional Packaged
   Content elements of the same component or of previous Payment Scheme
   Components. The IOTP Application Core has to check the
   PayReceiptNameRefs attribute of the Payment Receipt Component and to
   supply ALL Packaged Content Elements which are referred to.

   Such resumes a verification might include internal consistency check of the
   receipt as well as consistency checks with payment at the whole transaction. Payment Handler side.

   Input Parameters

   o  Consumer Payment Identifier,  Payment Handler Payment Identifier
   o  Wallet Identifier and/or - renaming to till identifier neglected - and
      Pass Phrase
   o  Payment Receipt Name References  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 Receipt and Payment Scheme) Packaged Content -
      originates copied from the Payment Receipt
      Scheme Component and previous
      Payment Request/Exchange/Response Components of the received IOTP message (Payment Exchange
      or Request Block).

   XML definition:

   <!ELEMENT CheckPaymentReceipt (PackagedContent*) ResumePaymentPaymentHandler
   (PaySchemePackagedContent*) >
   <!ATTLIST CheckPaymentReceipt
     ConsumerPayId  CDATA  #IMPLIED ResumePaymentPaymentHandler
     PaymentHandlerPayId  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED >

   Output Parameters
   o  Continuation Status
   o  (Payment Scheme) Packaged Content - for insertion in the
      Payment Scheme Component of the next Payment Exchange Block.

   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.

   XML definition:

   <!ELEMENT CheckPaymentReceiptResponse EMPTY ResumePaymentPaymentHandlerResponse
   (PaySchemePackagedContent*) >
   <!ATTLIST CheckPaymentReceiptResponse ResumePaymentPaymentHandlerResponse
     ContStatus  (End|Continue)  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.5.2  Expand Payment Receipt

4.3.5  Continue Process

   This expands API function passes one specific IOTP Payment Receipt Components 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 Scheme Component,
   i.e., the payment receipt
   containing errors. This function may also access encapsulated Packaged Content elements, received from the payment specific
   payment receipt and expand its content. The IOTP Application Core has
   counter party (e.g. Consumer) to check the PayReceiptNameRefs attribute of IOTP Payment Bridge and responds
   with the next IOTP Payment Receipt Scheme Component and for submission to supply ALL Packaged Content Elements which are
   referred to. the
   counter party.

   Input Parameters

   o  Consumer  Payty's Payment Identifier, Payment Handler Payment Identifier Idetifier
   o  Process (Transaction) Type which distinguishes between Payments
      and Inquiries.
   o  Wallet Identifier and/or Pass Phrase
   o  Payment Receipt Name References
   o  (Payment Receipt and Payment Scheme) Packaged Content -
      originates copied from the Payment Receipt
      Scheme Component and previous of the received Payment Request/Exchange/Response Components Exchange Block or from
      the Error Block.

   Each party should set the payment identifier with the local
   identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment
   Handler: PaymentHandlerPayId).

   XML definition:

   <!ELEMENT ExpandPaymentReceipt (PackagedContent*) ContinueProcess (PaySchemePackagedContent+) >
   <!ATTLIST ExpandPaymentReceipt
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId ContinueProcess
     PayId  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED  #REQUIRED
     ProcessType  (Payment | Inquiry) 'Payment'
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Brand Identifier
   o  Protocol specific Brand Identifier
   o  Payment Instrument Identifier
   o  Currency Code and Currency Code Type
   o  Payment Amount
   o  Payment Direction
   o  Time Stamp - issuance of the receipt
   o  Protocol Identifier  Continuation Status
   o  Protocol specific Transaction Identifier  (Payment Scheme) Packaged Content - this is an internal
      reference number which identifies for insertion in 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 Scheme Component of the other output parameters; property
      descriptions have to consider the language annotation.

   The Style Sheet Net Location refers to a Style Sheet (e.g. [XSL])
   that contains visualization information about the reported XML
   encoded data. However, the IOTP Application Core may ignore this
   attribute.

   XML definition:

   <!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) >
   <!ATTLIST ExpandPaymentReceiptResponse
     BrandId  CDATA  #IMPLIED
     PaymentInstrumentId  CDATA  #IMPLIED
     Amount  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  #IMPLIED
     CurrCode  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     ProtocolTransId  CDATA  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     ConsumerDesc  CDATA  #IMPLIED
     PaymentHandlerDesc  CDATA  #IMPLIED
     StyleSheetNetLocn  CDATA  #IMPLIED> next Payment Exchange Block or
      final Payment Response Block

   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.

   XML definition:

   <!ELEMENT PaymentProperty EMPTY ContinueProcessResponse (PaySchemePackagedContent*) >
   <!ATTLIST PaymentProperty
     PropertyType  NMTOKEN  #REQUIRED
     PropertyValue  CDATA  #REQUIRED
     PropertyDesc  CDATA ContinueProcessResponse
     ContStatus  (End|Continue)  #REQUIRED >

   The Existing Payment Software should return as many attributes as
   possible from the supplied IOTP Payment Receipt.

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.5.3  Inquire

4.3.6  Change Process State

   This API function returns

   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 optionally processing errors.
   Notification happens by requesting the intended process state.

   The IOTP Payment Receipt Component's Packaged Content. Bridge processes the status change and reports the
   result.

   The IOTP Application Core has to analyze any returned process status
   in order to check whether the IOTP Payment
   Handler's 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.

   Transaction Suspension is notified by the newly introduced Process
   State "Suspended". The other attribute values have been taken from
   the IOTP specification.

   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 must by the
   Consumer, the issuance of "FindAcceptedPaymentBrand" by the Merchant,
   or the issuance of "StartPaymentPaymentHandler" by the 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 this Packaged Content with an error code if it
   such an incompatible call has been created. The Consumer's IOTP Payment Bridge may return it if issued. Instead it has been received and accepted should report
   the old unchanged Process State.

   Unknown payment transactions are reported by "Check Payment Receipt". the Error Code
   "AttValInvalid" pointing to the PayId attribute.

   Input Parameters

   o  Consumer Payment Identifier, Payment Handler  Party's Payment Identifier
      - known payment identifiers should be provided.
   o  intended Payment Status
   o  intended Completion Code
   o  Process (Transaction) Type which distinguishes between Payments
      and Inquiries.
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT InquireProcessState ChangeProcessState EMPTY >
   <!ATTLIST InquireProcessState
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId 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 >

   Output Parameters

   o  Current  Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation
   o  Payment Receipt References
   o  Payment Receipt Packaged Content Data, if available

   The Internet Open Trading Protocol 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.

   XML definition:

   <!ELEMENT InquireProcessStateResponse
   (PayReceiptPackagedContent*) ChangeProcessStateResponse EMPTY >
   <!ATTLIST InquireProcessStateResponse ChangeProcessStateResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      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.

10.5.4  Start Payment

4.4  General Inquiry

   This API function responds any additional payment scheme specific
   data which is needed by the Payment Handler for Consumer initiated Calls

   The following calls are not necessarily assigned to a payment
   transaction inquiry processing. and may be issued at any time. There are no dependencies
   on any other calls.

4.4.1  Remove Payment Log

   The IOTP Application Core notifies the IOTP Payment Bridge resp. the
   Existing Payment Software has to determine the payment related items
   inclusive that any call back functions record in the Payment Log file,
   that were provided deals with the "Start
   Payment Consumer" API function call. listed payment transaction, might be removed.

   Input Parameters

   o  Consumer  Party's Payment Identifier
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT StartPaymentInquiry RemovePaymentLog EMPTY >
   <!ATTLIST StartPaymentInquiry
     ConsumerPayId RemovePaymentLog
     PayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  (Payment Scheme) Packaged Content - intended for insertion in
      the Payment Scheme Component of  the Inquiry Request Block

   XML definition:

   <!ELEMENT StartPaymentInquiryResponse
   (PaySchemePackagedContent*) RemovePaymentLogResponse EMPTY >
   <!ATTLIST StartPaymentInquiryResponse RemovePaymentLogResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

10.5.5  Inquire

4.4.2  Payment Status Instrument Inquiry

   This API function retrieves the properties of the Payment Instrument.
   The Payment Handler uses 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.

   E.g., this API request 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.

   Input parameters

   o  Brand Identifier
   o  Payment Instrument Identifier
   o  Protocol Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  Property Type List - sequence of values whose language is
      identified by xml:lang
   o  (Brand) PackagedContent Content - further payment brand
      description
   o  Protocol Brand Content - further payment brand information
   o  (Protocol Amount) PackagedContent Content - further payment
      protocol description
   o  (Pay Protocol) PackagedContent Content - further payment
      protocol description

   The codes in the property type list are of two types:

   o  generic codes which apply to all payment methods but might be
      unavailable
   o  Payment Brand specific codes.

   Generic codes for Consumer initiated
   inquiry processing. It differs from the previous "Inquire Process
   State" API function by Property Type List are:

   Property Type         Meaning
   Balance               Current balance
   Limit                 Maximum balance
   PaymentLimit          Maximum payment transaction limit
   Expiration            Expiration date
   Identifier            Issuer assigned identifier of the payment
                         instrument. Usually, it does not match with
                         the optional supplement API's payment instrument identifier.
   LogEntries            Number of stored payment scheme
   specific data. transaction
                         entries. The response may encapsulate further details about 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. However, payment schemes
                         transaction, n may omit any supplement negative
   PayPartyn             Remote party of additional data and may mimic the "Inquire Process State" API
   function by neglecting any returned n-th payment receipt.

   Input Parameters
   o  Consumer Payment Identifier, Payment Handler Payment Identifier
      - known identifier should be provided
   o  Wallet Identifier and/or Pass Phrase
   o  (Payment Scheme) Packaged Content - copied from recorded
                         transaction, n may negative
   PayTimen              Time of the Inquiry
      Request Block's Payment Scheme Component n-th payment recorded
                         transaction, n may negative

   XML definition:

   <!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) PaymentInstrumentInquiry (BrandPackagedContent*,
   ProtocolBrand?,
   ProtocolAmountPackagedContent*,
   PayProtocolPackagedContent*) >
   <!ATTLIST InquirePaymentStatus
     ConsumerPayId PaymentInstrumentInquiry
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     PaymentHandlerPayId
     ProtocolId  CDATA  #REQUIRED
     PropertyTypeList  NMTOKENS  #REQUIRED
     xml:lang  NMTOKEN  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process State
   o  Completion Code parameters

   o  Status Description and its  a list of zero or more unavailable property values whose
      language annotation are identified by xml:lang.
   o  (Payment Scheme) Packaged Content - intended for insertion in
      the Payment Scheme Component  a list of the Inquiry Response Block zero or more sets of "Properties Types", "Property
      Values" and "Property Descriptions"

   XML definition:

   <!ELEMENT InquirePaymentStatusResponse
   (PaySchemePackagedContent*) PaymentInstrumentInquiryResponse
   (PaymentInstrumentProperty*) >
   <!ATTLIST InquirePaymentStatusResponse
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #REQUIRED
     CompletionCode PaymentInstrumentInquiryResponse
     xml:lang  NMTOKEN  #REQUIRED
     UnavailablePropertyList NMTOKENS  #IMPLIED
     xml:lang >

   <!ELEMENT PaymentInstrumentProperty EMPTY >
   <!ATTLIST PaymentInstrumentProperty
     PropertyType  NMTOKEN  #IMPLIED
     StatusDesc  #REQUIRED
     PropertyValue  CDATA  #IMPLIED  #REQUIRED
     PropertyDesc  CDATA  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

   10.6  Other API Calls

   10.6.1  Manage

4.4.3  Inquire Pending Payment Software

   The following

   This API function notifies reports the party's payment identifiers of any
   pending payment transactions that the IOTP Payment Bridge about the
   intended registration, modification, Bridge/Existing
   Payment Software recommends to complete or deletion suspend prior to the
   processing of a new payment
   instrument. The actual processing is up transactions. It does not respond further
   transaction details. These have to be inquired by "Inquire Process
   State".

   Note that the IOTP Payment Bridge.

   This API request may also be used Bridge has to activate respond without the
   supplement of any pass phrase if there exist no pending payment
   transaction. But if there are some pending payment transactions, the
   IOTP Payment Bridge
   resp. Existing Payment Software for general administration purposes. may refuse the immediate response and may instead
   request the appropriate pass phase from the IOTP Application Core.

   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 PassPhrase

   XML definition:

   <!ELEMENT InquirePendingPayment EMPTY >
   <!ATTLIST InquirePendingPayment
     WalletId  CDATA  #IMPLIED
     PassPhrase  CDATA  #IMPLIED >

   Output Parameters

   o  (Protocol Amount) Packaged Content - further payment protocol
      description

   If  Party's Payment Identifier

   XML definition:

   <!ELEMENT InquirePendingPaymentResponse (PaymentId*) >

   <!ELEMENT PaymentId EMPTY >
   <!ATTLIST PaymentId
     PayId  CDATA  #REQUIRED >

   Tables 4 and 5 explain the Action attribute attributes and elements; Table 3
   introduces the Error Codes.

4.5  Payment Related Inquiry API Calls

4.5.1  Check Payment Receipt

   This function is set, used by the Brand Consumer and Protocol Identifier
   have to might be set, too. The IOTP used by the
   Payment Bridge has Handler to provide check the
   required user dialogs and selection mechanisms. E.g., updates consistency, validity, and
   deletions may require the selection integrity of the
   IOTP payment instrument. A new
   wallet receipts whereby any receipt might be silently generated on the supplement consist of a new Wallet
   Identifier Packaged
   Content Elements

   o  from the IOTP Payment Receipt Component - provided by the
      Payment Handler's "Inquire Process State" API call shortly
      before payment completion,

   o  from Payment Scheme Components being exchanged during the
      actual payment, or after an additional end user acknowledge.

   o  being returned by the Consumer's "Inquire Process State" API
      call shortly before payment completion

   The IOTP Application Core should not provide any pass phrases for new wallets.
   Instead, has to check the PayReceiptNameRefs
   attribute of the IOTP Payment Bridge has to request Receipt Component and verify them which
   may return their value to supply exactly
   the IOTP Application Core in plain text. In
   addition, Packaged Content Elements being referred to.

   Failed verification is returned with a business error.

   Note that this Payment API assumes that any payment receipt builds
   upon a subset of elements w.r.t. [IOTP]. Furthermore, the Packaged
   Content Element have to be distinguishable by their Name attribute.

   Input Parameters

   o  Party's Payment Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  All Packaged Content Elements that build the payment receipt

   XML definition:

   <!ELEMENT CheckPaymentReceipt (PackagedContent*) >
   <!ATTLIST CheckPaymentReceipt
     PayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CheckPaymentReceiptResponse EMPTY >
   <!ATTLIST CheckPaymentReceiptResponse >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

4.5.2  Expand Payment Receipt

   This API function expands any IOTP payment receipt into a form which
   may be used for display or printing purposes. "Check Payment Bridge returns Receipt"
   should be used first if there is any question of the supported
   authentication algorithms when a new brand and protocol pair has been
   registered.

   If payment receipt
   containing errors.

   There apply the "Action" attribute is omitted, same conventions to the IOTP input parameter as for "Check
   Payment Bridge resp.
   Existing Receipt" (cf. Section 4.5.1).

   Input Parameters

   o  Party's Payment Software pops up in a general interactive mode. Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  All Packaged Content Elements that build the payment receipt

   XML definition:

   <!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*) ExpandPaymentReceipt (PackagedContent*) >
   <!ATTLIST ManagePaymentSoftware
     BrandId  CDATA  #IMPLIED
     ProtocolId ExpandPaymentReceipt
     PayId  CDATA  #IMPLIED
     Action  (New |
      Update |
      Delete)  #IMPLIED  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  An action code:  Brand Identifier
   o  New - added new wallet  Protocol specific Brand Identifier
   o  Update - changed wallet's configuration  Payment Instrument Identifier
   o  Delete - removed a wallet  Currency Code and Currency Code Type
   o  Wallet Identifier and/or 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 Amount
   o  Payment Direction
   o  Time Stamp - issuance of each IOTP transaction. However, the IOTP Application
   Core has to be notified about new wallets and should be notified
   about updated and removed wallet (identifier)s". Alternatively,
   removed wallets can be implicitly detected during the next brand
   selection phase. Updated wallets do no affect the processing of receipt
   o  Protocol Identifier
   o  Protocol specific Transaction Identifier - this is an internal
      reference number which identifies the
   IOTP Application Core. The IOTP payment
   o  Consumer Description, Payment Software resp. Existing Handler Description, and a
      language annotation
   o  Style Sheet Net Location
   o  Payment Software should only support the addition Property List. A list of at most one
   wallet because it type/value/description triples
      which contains additional information about the payment which
      is not able covered by any of the other output parameters; property
      descriptions have to report multiple additions at once
   back consider the language annotation.

   The Style Sheet Net Location refers to a Style Sheet (e.g. [XSLT])
   that contains visualization information about the IOTP Application Core. reported XML
   encoded data.

   XML definition:

   <!ELEMENT ManagePaymentSoftwareResponse EMPTY ExpandPaymentReceiptResponse (PaymentProperty*) >
   <!ATTLIST ManagePaymentSoftwareResponse
     Action  (New |
      Update |
      Delete) ExpandPaymentReceiptResponse
     BrandId  CDATA  #IMPLIED
     WalletID
     PaymentInstrumentId  CDATA  #IMPLIED
     Passphrase
     Amount  CDATA  #IMPLIED
     AuthNames  NMTOKENS
     CurrCodeType  NMTOKEN  #IMPLIED
     CurrCode  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     ProtocolTransId  CDATA  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     ConsumerDesc  CDATA  #IMPLIED
     PaymentHandlerDesc  CDATA  #IMPLIED
     StyleSheetNetLocn  CDATA  #IMPLIED>

   <!ELEMENT PaymentProperty EMPTY >
   <!ATTLIST PaymentProperty
     PropertyType  NMTOKEN  #REQUIRED
     PropertyValue  CDATA  #REQUIRED
     PropertyDesc  CDATA  #REQUIRED >

   The Existing Payment Software should return as many attributes as
   possible from the supplied IOTP Payment Receipt. The payment
   supplement define that attribute value for the payment properties.

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

11.  Called Functions

   There are two functions which can be called by the payment software:

   o  The Call Back Function, which is used to provide information for
   Consumer or Payment Handler notification about the progress of

4.5.3  Inquire Process State

   This API function returns the current payment transaction.  o  The Database Function which is used to
   store, modify, and retrieve both temporary data during state and optionally
   further Packaged Content Elements that form the payment
   transaction and receipt.
   Called by the Payment Handler, the IOTP Payment Bridge might respond
   with data about suspended or completed payment
   transactions.

   Their use is illustrated intended for inclusion in the diagram below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* IOTP Application   ----calls----
                         |     Core     |               |
          display        |              |               v
            to  <----------  Call Back <--calls--- Payment
           user          |              |           Software
                         |   Data Base  |
                         |   |       |  |               |
                         |   |  Work | <--calls---------|
                         |   |  and  |  |               |
                         |   |Logging| <--calls----------
                         |   ---------  |
                         |              |
                         ----------------
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                        Figure 19 Called Functions

11.1  Call Back Function

   The "Call Back" function provides Receipt
   Component's Packaged Content. When the Consumer or Payment Handler
   with information about the payment's progress. Whenever calls this function
   is called, the content
   shortly before payment completion, it may respond with further items
   of the status description should payment receipt. Such items might 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 created by a parameter to the
   Start Payment X API input message. The Call Back function is then
   called whenever the status changes or progress needs to be reported. chip card.

   Input Parameters

   o  the software identifier of the caller
   o  Consumer Payment Identifier, Payment Handler  Party's Payment Identifier
      - known identifier should be supplied
   o  Wallet Identifier and/or Pass Phrase
   XML definition:

   <!ELEMENT InquireProcessState EMPTY >
   <!ATTLIST InquireProcessState
     PayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process State and Percent Complete
   o  Completion Code
   o  Status Description and its language annotation, text which  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  Any Packaged Content Element being available that form the
      payment receipt

   The IOTP provides information about a linking capability to the progress payment receipt
   delivery. Instead of encapsulating the call. It should
      be displayed or made available to, for example, whole payment specific data
   into the Consumer.

   Examples packaged content of Status Description could be:

   o  "Paying 12.30 USD to XYZ Inc"
   o  "Payment completed"
   o  "Payment aborted"

   The valid languages are announced in the Call Back Language List
   attribute in "Start payment receipt, other Payment X" API function calls.
   Scheme Components' Packaged Content might be referred to.

   XML definition:

   <!ELEMENT CallBack EMPTY InquireProcessStateResponse
   (PackagedContent*) >
   <!ATTLIST CallBack
     ContentSoftwareID  CDATA  #IMPLIED
     ConsumerPayId  CDATA  #IMPLIED
     PaymentHandlerPayId  CDATA  #IMPLIED InquireProcessStateResponse
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED >

   Output Parameters

   XML definition:

   <!ELEMENT CallBackResponse EMPTY >
   <!ATTLIST CallBackResponse
     PayReceiptNameRefs  NMTOKENS  #IMPLIED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes. Basically, the call back

4.5.4  Start Payment Inquiry

   This API function accepts
   all input arguments or rejects the whole request. It may even accept
   malformed requests.

   Some responds any additional payment schemes may require scheme specific
   data that is needed by the Payment Handler for Consumer may be able to
   cancel the initiated
   payment at any time. The Call Back function can be used transaction inquiry processing. Probably, the IOTP Payment
   Bridge resp. Existing Payment Software has to
   facilitate this by returning determine the cancellation request on payment
   related items that were provided with the next "Start Payment Consumer"
   API function call. Note that there exist two mechanisms to notify

   Input Parameters

   o  Consumer Payment Identifier
   o  Wallet Identifier and/or Pass Phrase

   XML definition:

   <!ELEMENT StartPaymentInquiry EMPTY >
   <!ATTLIST StartPaymentInquiry
     ConsumerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  (Payment Scheme) Packaged Content - intended for insertion in
      the IOTP Payment
   Bridge about Cancellations or Suspensions. Either Scheme Component of  the "Call Back"
   function might use Inquiry Request Block

   XML definition:

   <!ELEMENT StartPaymentInquiryResponse
   (PaySchemePackagedContent*) >

   Tables 4 and 5 explain the response attributes and elements; Table 3
   introduces the next time it is called or Error Codes.

4.5.5  Inquire Payment Status

   The Payment Handler calls this API function for Consumer initiated
   inquiry processing. It differs from the
   IOTP Application Core might issue a "Change previous "Inquire Process
   State" request to API function by the IOTP Application Core. Due to optional supplement of payment scheme
   specific data. The response may encapsulate further details about the latter case, IOTP
   payment transaction.

   Input Parameters

   o  Payment
   Bridge or Existing Handler Payment Software, may ignore the details of Identifier
   o  Wallet Identifier and/or Pass Phrase
   o  (Payment Scheme) Packaged Content - copied from the
   "Call Back" response.

11.2  Work and Inquiry
      Request Block's Payment Log Database Function

   The Work Database Function stores, modifies, Scheme Component

   XML definition:

   <!ELEMENT InquirePaymentStatus (PaySchemePackagedContent*) >
   <!ATTLIST InquirePaymentStatus
     PaymentHandlerPayId  CDATA  #REQUIRED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  Current Process State
   o  Completion Code
   o  Status Description and retrieves temporary
   data. It is used, its language annotation
   o  (Payment Scheme) Packaged Content - intended for example, to store data about pending payments,
   so that even if the payment software fails, it may be possible to
   restart payments by retrieving the data held insertion in this database. When a
   payment completes,
      the data about Payment Scheme Component of the Inquiry Response Block

   XML definition:

   <!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 >

   Tables 4 and 5 explain the payment held in attributes and elements; Table 3
   introduces the Work
   Database is deleted. Error Codes.

4.6  Other API Calls

4.6.1  Manage Payment Software

   The following API function notifies the IOTP Payment Log Database Function stores receipt data about a
   payment. It is used to store information Bridge about payments with a
   suspended the
   intended registration, modification, or final payment status. This data should be held on
   permanent storage. It may even, for example, be held remotely in
   order to support keeping deletion of a payment records where there is no local
   permanent storage device.
   instrument. The API for both databases have been merged for homogeneous database
   access. It actual processing is assumed, that up to the IOTP Application Core defers most of
   the business related database care Payment Bridge.

   This API request may also be used to activate the IOTP Payment Bridge and
   resp. Existing Payment Software. Nevertheless, their data management may
   rely on the generic database capabilities of the IOTP Application
   Core.

   Deferring the actual data housekeeping to the IOTP Application Core
   is the proposed implementation because it offers IOTP Application
   Core the opportunities Software for further features. general administration purposes.

   Input Parameters

   o  the software identifier of the caller
   o  Database Type which distinguishes between the Work and the
      PaymentLog Databases
   o  Database Action:
   o  New - which stores a new record
   o  Update - which updates an already stored data record
      identified by the Database Entry Identifier
   o  Get - which retrieves the record identified by the Database
      Entry Identifier
   o  Delete - which deletes the record identified by the Database
      Entry  Brand Identifier
   o  First - which positions a record pointer to the "first"
      record in the database and returns the Database Entry  Protocol Identifier
   o  Next - which positions the record pointer to the next record
      and returns the new Database Entry Identifier  Any action code:
   o  Database Entry Identifier  New - which needs to be supplied on all
      actions except special "New" cases (see below). add new payment method / instrument
   o  Further attributes rephrase those from  Update - change the "Start Payment
      X" and "Inquire Payment Log" Response message. They are set on
      action "New" and "Update" and omitted otherwise. payment method's / instrument's data
   o  Database Data  Delete - additional delete a payment software specific data,
      encoding IOTP Payment Bridge's and Existing Payment Software's
      internal states and data method / instrument
   o  (Brand and Protocol Brand)  Wallet Identifier and/or Pass Phrase
   o  (Brand) Packaged Content - further payment brand description
   o  (Protocol Amount)  (Pay Protocol) Packaged Content - further payment protocol
      description
   o  (Protocol)  (Protocol Amount) Packaged Content - further payment protocol
      description

   If the Action attribute is set, the Brand and Protocol Identifier
   have to be set, too. 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.

   If the "Action" attribute is omitted, the IOTP Payment Bridge resp.
   Existing Payment Software pops up in a general interactive mode.

   XML definition:

   <!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   PayProtocolPackagedContent*) >
   <!ATTLIST ManagePaymentSoftware
     BrandId  CDATA  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     Action  (New |
      Update |
      Delete)  #IMPLIED
     WalletID  CDATA  #IMPLIED
     Passphrase  CDATA  #IMPLIED >

   Output Parameters

   o  (Payment Receipt and Payment Scheme) Packaged Content - only
      the Packaged Content Elements that form the payment receipt are
      expected to be stored in the data base. However, it is up to
      the IOTP Payment Bridge to decide which elements it stores  An action code:

   o  (Protocol) Packaged Content  New - further payment protocol
      description added new wallet
   o  (Trading Role) Packaged Content  Update - further payment protocol
      description
   o  (Authentication Request and Authentication Response) Packaged
      Content changed wallet's configuration
   o  (Algorithm) element  Delete - details about the authentication method;
      its ID attribute is neglected

   Typically, the entries of each wallet" define removed a collection of data
   items whereby the "First" and "Next" actions are used for sequential
   database scans. The wallet
   o  Wallet Identifier identifies the associated
   collection in and/or Pass Phrase

   The IOTP Payment Bridge does not return any information about the data base. In this way records set
   of the work database
   which relate to payments which registered payment instruments because these data items are not complete and need to be
   canceled after a period of time, may be removed.

   The definition of which record represents
   dynamically inferred during the "First" and how brand selection process at the
   "Next" record is identified, is implementation dependent. The is no
   predefined order
   beginning of the elements within each collection. However the
   use of "First" and "Next" must allow every record on IOTP transaction. However, the database IOTP Application
   Core has to be referenced with exactly one report of each entry.

   The "New" action is used to extend a possibly empty collection.
   Omitted attribute values notified about new wallets and elements' contents remain undefined.
   However, all REQUIRED attributes from the output parameter list -
   except the Data Entry Identifier - must should be set.  The "Update" action
   replaces only the attribute notified
   about updated and content values of removed wallet (identifier)s". Alternatively,
   removed wallets can be implicitly detected during the referred
   database entry which are mentioned in next brand
   selection phase. Updated wallets do no affect the database request. The other
   values processing of the omitted attribute and elements are not affected.
   IOTP Application Core. The "Delete" action returns IOTP Payment Software resp. Existing
   Payment Software should only support the data base identifier or addition of at most one
   wallet because it is not able to report multiple additions at once
   back to the next
   entry. IOTP Application Core.

   XML definition:

   <!ELEMENT AccessDataBase (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*, PackagedContent*,
   TradingRolePackagedContent*,
   AuthReqPackagedContent*,
   AuthResPackagedContent*, Algorithm*) ManagePaymentSoftwareResponse EMPTY >
   <!ATTLIST AccessDataBase
     ContentSoftwareID  CDATA  #IMPLIED
     DatabaseType  (Work|PaymentLog) #REQUIRED ManagePaymentSoftwareResponse
     Action  (New |
      Update |
      Get |
      Delete |
      First |
      Next)  #REQUIRED
     DataEntryId  NMTOKEN  #IMPLIED
     BrandId  CDATA  #IMPLIED
     PaymentInstrumentId  CDATA
      Delete)  #IMPLIED
     ConsumerPayId
     WalletID  CDATA  #IMPLIED
     PaymentHandlerPayId
     Passphrase  CDATA  #IMPLIED
     ProcessState  (NotYetStarted
     AuthNames  NMTOKENS  #REQUIRED >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes.

5. Call Back Function

   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.

   Its use is illustrated in the diagram below.

   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                         IOTP Application   ----calls----
                         |
      InProgress     Core     |
      Suspended               |
      CompletedOk
          display        |
      Failed              |
      ProcessError)  #IMPLIED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     TimeStamp  CDATA  #IMPLIED
     CurrCodeType  NMTOKEN  'ISO4217-A'
     CurrCode  CDATA  #IMPLIED
     Amount  CDATA  #IMPLIED
     PayDirection  (Debit|Credit)  #IMPLIED
     ProtocolId  CDATA  #IMPLIED
     ProtocolBrandId  CDATA  #IMPLIED
     OkFrom  CDATA  #IMPLIED
     OkTo  CDATA  #IMPLIED
     WalletID  CDATA  #IMPLIED
     CallBackFunction  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS  #IMPLIED
     DatabaseFunction  CDATA  #IMPLIED
     Data  CDATA  #IMPLIED >

   Output Parameters

   o  Database Entry Identifier which uniquely identifies               v
            to  <----------  Call Back <--calls---  Payment
           user          |              |           Software
                         ----------------
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
                        Figure 9 Call Back Function

   Whenever this function is called, the record
      within content of the database
   o  Further attributes and elements rephrase those from 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 "Inquire "Resume Payment Log" Response message (or the
      input parameter list). They are copied from X" API function.
   Afterwards, this function might be called whenever the input message
      on actions "New" status changes
   or "Update" and filled with the actual values
      otherwise progress needs to be reported.

   Input Parameters

   o  Database Data - additional payment  the software specific data 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 retrieved record

   Generally, progress of the response call. It should contain all the
      be displayed or made available attribute
   values. to, for example, the Consumer.

   Examples of Status Description could be:

   o  "Paying 12.30 USD to XYZ Inc"
   o  "Payment completed"
   o  "Payment aborted"

   The behavior on undefined values is undefined. valid languages are announced in the Call Back Language List
   attribute in "Start Payment X" and "Resume Payment X" API function
   calls.

   XML definition:

   <!ELEMENT AccessDataBaseResponse (BrandPackagedContent*,
   ProtocolBrandPackagedContent*,
   ProtocolAmountPackagedContent*,
   ProtocolPackagedContent*, PackagedContent*,
   TradingRolePackagedContent*,
   AuthReqPackagedContent*,
   AuthResPackagedContent*, Algorithm*) CallBack EMPTY >
   <!ATTLIST AccessDataBaseResponse
     DataEntryId NMTOKEN  #IMPLIED
     BrandId  CDATA  #REQUIRED
     PaymentInstrumentId  CDATA  #IMPLIED
     ConsumerPayId CallBack
     ContentSoftwareID  CDATA  #IMPLIED
     PaymentHandlerPayId
     PayId CDATA  #IMPLIED #REQUIRED
     ProcessState  (NotYetStarted |
      InProgress |
      Suspended |
            CompletedOk |
            Failed |
            ProcessError)  #REQUIRED
     PercentComplete  CDATA  #IMPLIED
     CompletionCode  NMTOKEN  #IMPLIED
     xml:lang  NMTOKEN  #IMPLIED
     StatusDesc  CDATA  #IMPLIED
     PayReceiptNameRefs  NMTOKENS  #IMPLIED
     TimeStamp  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
     WalletID  CDATA |
      CompletedOk |
      Failed |
      ProcessError)  #IMPLIED
     CallBackFunction
     PercentComplete  CDATA  #IMPLIED
     CallBackLanguageList  NMTOKENS
     CompletionCode  NMTOKEN  #IMPLIED
     DatabaseFunction  CDATA
     xml:lang  NMTOKEN  #IMPLIED
     Data
     StatusDesc  CDATA  #IMPLIED >

   Output Parameters
   XML definition:

   <!ELEMENT CallBackResponse EMPTY >
   <!ATTLIST CallBackResponse <!-- see below --> >

   Tables 4 and 5 explain the attributes and elements; Table 3
   introduces the Error Codes. However, it is assumed that

   Basically, the typical
   caller, i.e.,  IOTP Payment Bridge call back function accepts all input arguments or Existing Payment Software,
   implements very basic resolution strategies. The caller may retry
   rejects the
   API requests on error and give up after several retries. But whole request. It may even accept malformed requests.

   Some payment schemes may support or require that the end
   user should Consumer might
   be provided with able to cancel the error description because it might
   contain further explanations. payment at any time. The error code "ReqRefused" may Call Back function can
   be used to signal facilitate this by returning the following example errors:

   o  database entry not found
   o  database full, no space left
   o  database entry exceeds length limitation

   The cancellation request on
   the next call (using the Business Error Code "ReqRefused" is used and 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/canceling all pending payment
   transactions.

   Note that the end "Change Process State" API function provides the second
   mechanism for such kind of notification. Therefore, the
   database has been reached on IOTP Payment
   Bridge or Existing Payment Software may ignore the details of the "Next" Action.

12.
   "Call Back" response.

6. Security Consideration

   [T.B.D.]

   See also security consideration section of [IOTP].

Full Copyright Statement

   Copyright (C) The Internet Society 2000.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

References

   [RFC XXXX]

   [IOTP] - D. Burdett, "Interenet Internet Open Trading Protocol - IOTP, Specification, Version 1.0", September 1999. (currently draft-ietf-trade-iotp-v1.0-
   protcool-07.txt) 1.0,
   April 2000, See RFC2801.

   [IOTPBOOK] - D. Burdett, D.E. Eastlake III, and M. Goncalves,
   Internet Open Trading Protocol, McGraw-Hill, 2000

   [HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language
   (HTML) is a simple markup language used to create hypertext documents
   that are platform independent. See RFC 1866 and the World Wide Web
   (W3C) consortium web site at: http://www.w3.org/MarkUp/

   [HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC
   1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R.
   Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer
   Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
   Berners-Lee. January 1997.

   [ISO4217] - ISO 4217: Codes for the Representation of Currencies.

   Available from ANSI or ISO.

   [MIME] - Multipurpose Internet Mail Extensions. See RFC822, RFC2045,
   RFC2046, RFC2047, RFC2048 and RFC2049.

   [URL] -  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
   Resource Locators (URL)", RFC 1738, December 1994.

   [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
   Download from: <http://www.setco.org>.

   [SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently
   draft-ietf-trade-iotp-v1.0-set-00.txt)
   draft-ietf-trade-iotp-v1.0-set-01.txt)

   [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.

   [XML] - Extensible Mark Up Language. A W3C recommendation. See
   http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998
   version [XSL]

   [XSLT] - Extensible Style Language. Language Transformations 1.0, November
   1999, See http://www.w3.org/TR http://www.w3.org/TR/xslt

   [XML-NS] - Namespaces in XML Recommendation. T. Bray, D. Hollander,
   A.  Layman. Janaury 1999.  http://www.w3.org/TR/1999/REC-xml-names-
   19990114

Author's Address

        Hans-Bernhard Beykirch and Werner Hans
        IT Development & Coordination Center for the German Savings Banks
        Organization (SIZ)
        Konigswinterer Strase 553
        53227 Bonn
        Germany
        E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de

        Masaaki Hiroya and Yoshiaki Kawatsura
        Hitachi, Ltd.
        890 Kashimada Saiwai-ku Kawasaki-shi
        Kanagawa, Japan 212-8567
        E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp

Expiration and File Name

   This draft expires September 2000. March 2001.

   Its file name is draft-ietf-trade-iotp-v1.0-papi-00.txt. draft-ietf-trade-iotp-v1.0-papi-01.txt.