draft-ietf-trade-iotp-v1.0-papi-00.txt   draft-ietf-trade-iotp-v1.0-papi-01.txt 
TRADE Working Group Werner Hans TRADE Working Group Werner Hans
INTERNET-DRAFT Hans-Bernhard.Beykirch INTERNET-DRAFT Hans-Bernhard.Beykirch
SIZ SIZ
Masaaki Hiroya Masaaki Hiroya
Yoshiaki Kawatsura Yoshiaki Kawatsura
Hitachi Hitachi
Expires: September 2000 March 2000 Expires: March 2001 September 2000
Architecture and Payment API for Internet Open Trading Protocol (IOTP) 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 Status of this Memo
This document is intended to become an Internet-Draft and will be in This document is intended to become an Informational RFC and will be
full conformance with all provisions of Section 10 of RFC2026. in full conformance with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering This document is an Internet-Draft and is in full conformance with
Task Force (IETF), its areas, and its working groups. Note that all provisions of Section 10 of RFC 2026. Internet-Drafts are
other groups may also distribute working documents as Internet- working documents of the Internet Engineering Task Force (IETF), its
Drafts. areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com >, which may the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf- be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>. trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at Discussions of the TRADE working group are archived at
http://www.elistx.com/archives/ietf-trade. http://www.elistx.com/archives/ietf-trade.
Abstract Abstract
The Trading Architecture proposes an abstract layered model of the The Internet Open Trading Protocol provides a data exchange format
IOTP based trading environment. Its description sketches the for trading purposes while integrating existing pure payment
essential functional and data modules and their interfaces at each protocols seamlessly. This motivates the multiple layered system
trading role's installation. This abstract view deals as a guideline architecture which consists of at least some generic IOTP application
for the modules' mapping to actual software modules. core and multiple specific payment modules.
The second part of this document focuses on the Payment API that This document addresses the common interface between the IOTP
improves the essential interface that relates to payment application core and the payment modules, enabling the
transactions. Such interface exists at the Consumers', the Merchants' interoperability between these kinds of modules. Furthermore, such an
and the Payment Handlers' installations connecting the actual payment interface provides the foundations for a plug-in- mechanism in actual
software components/legacy systems and the generic IOTP aware front implementations of IOTP application cores.
end application.
Such interfaces exist at the Consumers', the Merchants' and the
Payment Handlers' installations connecting the IOTP application core
and the payment software components/legacy systems.
Intended Readership
Software and hardware developers, development analysts, and users of
payment protocols.
Copyright Copyright
Copyright (C) The Internet Society 2000. Copyright (C) The Internet Society 2000.
Table of Contents Table of Contents
Status of this Memo........................................1 Status of this Memo........................................1
Abstract...................................................1 Abstract...................................................1
Intended Readership........................................2
Copyright..................................................2 Copyright..................................................2
Table of Contents..........................................3 Table of Contents..........................................3
1. Introduction............................................6 1. Introduction............................................5
1.1 Intended Readership...................................8 1.1 General payment phases................................6
GENERAL TRADING ARCHITECTURE...............................8 1.2 Assumptions...........................................7
2. Trading Architecture....................................8 2. Message Flow..........................................13
2.1 Overview...............................................8 2.1 Authentication Documentation Exchange................16
2.1.1 Layers and Components................................9 2.2 Brand Compilation....................................18
2.1.1.1 Consumer Access - End System Layer................10 2.3 Brand Selection......................................21
2.1.1.2 Network Layer.....................................11 2.4 Successful Payment...................................24
2.1.1.3 Access Layer......................................11 2.5 Payment Inquiry......................................28
2.1.1.4 Refinement Layer - Integration with IOTP..........11 2.6 Abnormal Transaction Processing......................30
2.1.1.5...................................................12 2.6.1 Failures and Cancellations.........................30
2.1.1.6 Data Layer........................................12 2.6.2 Resumption.........................................32
2.1.2 Implementation Variants.............................12 2.7 IOTP Wallet Initialization...........................33
2.1.3 Component Distribution..............................12 2.8 Payment Software Management..........................33
2.2 Requirements and Commitments..........................12 3. Mutuality.............................................34
2.2.1 Basic Requirements..................................13 3.1 Error Codes..........................................37
2.2.1.1 Electronic Commerce Provider (Server).............13 3.2 Attributes and Elements..............................47
2.2.2 Security Requirements and Commitments..............13 3.3 Process States........................................59
2.2.2.1 Overview about the Security Levels...............13 3.3.1 Merchant............................................59
2.2.3 Security Mechanism.................................14 3.3.2 Consumer............................................61
2.2.3.1 Transmission Security............................14 3.3.3 Payment Handler.....................................63
2.2.3.2 Authentication....................................15 4. Payment API Calls.....................................64
2.2.3.3 Document Security.................................15 4.1 Brand Compilation Related API Calls..................64
2.2.3.4 Authorization.....................................16 4.1.1 Find Accepted Payment Brand........................64
2.2.4 Protection against Attacks.........................16 4.1.2 Find Accepted Payment Protocol.....................65
2.2.4.1 Consumer System..................................17 4.1.3 Get Payment Initialization Data....................67
2.2.4.2 Transmission Line................................17 4.1.4 Inquire Authentication Challenge...................69
2.2.4.3 Provider's Computing Center......................18 4.1.5 Authenticate.......................................71
3. Layers and Functional Components......................18 4.1.6 Check Authentication Response......................71
3.1 End System Layer.....................................19 4.2 Brand Selection Related API Calls....................73
3.1.1 Presentation Software...............................20 4.2.1 Find Payment Instrument............................73
3.1.2 Document Formatting................................20 4.2.2 Check Payment Possibility..........................75
3.1.3 Document Security..................................21 4.3 Payment Transaction Related API calls................77
3.1.4 Transport Coupling.................................21 4.3.1 Start Payment Consumer.............................77
3.1.5 Maintenance........................................21 4.3.2 Start Payment Payment Handler......................79
3.2 Network Layer........................................21 4.3.3 Resume Payment Consumer............................81
3.3 Access Layer.........................................22 4.3.4 Resume Payment Payment Handler.....................82
3.3.1 Transport Coupling.................................23 4.3.5 Continue Process ..................................83
3.3.1.1 Network Protocols................................23 4.3.6 Change Process State...............................84
3.3.1.2 Transmission Security............................24 4.4 General Inquiry API Calls............................86
3.3.1.3 Access Protection................................24 4.4.1 Remove Payment Log.................................86
3.3.1.4 Presentation Control Monitor.....................24 4.4.2 Payment Instrument Inquiry.........................87
3.3.1.5 Parameterized Subsystem Distribution.............25 4.4.3 Inquire Pending Payment............................89
3.3.1.6 Frame Dialogs....................................25 4.5 Payment Related Inquiry API Calls....................89
3.3.2 Presentation Services..............................26 4.5.1 Check Payment Receipt..............................90
3.3.2.1 Native presentation (standard)...................27 4.5.2 Expand Payment Receipt.............................91
3.3.2.2 Optimization.....................................27 4.5.3 Inquire Process State..............................92
3.3.2.3 Transport Information............................27 4.5.4 Start Payment Inquiry..............................94
3.3.2.4 Native Programs..................................28 4.5.5 Inquire Payment Status.............................94
3.4 Refinement Layer.....................................28 4.6 Other API Calls......................................95
3.4.1 Format Conversion..................................29 4.6.1 Manage Payment Software............................95
3.4.2 Document Security..................................30 5. Call Back Function.....................................97
3.4.3 Format Optimization................................30 6. Security Consideration.................................99
4. Recapitulation........................................30
4.1 Example Justification................................33 Full Copyright Statement.................................100
5. Progress Example......................................35 References...............................................100
6. TCP/IP - WWW, Java Implementation Variant.............40 Author's Address.........................................101
6.1 Consumer's Sphere....................................42 Expiration and File Name.................................102
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 Authentication Documentation Exchange................54
8.2 Brand Compilation....................................55
8.3 Brand Selection......................................58
8.4 Successful Payment ..................................61
8.5 Payment Inquiry......................................65
8.6 Abnormal Transaction Processing......................67
8.6.1 Failures and Cancellations.........................67
8.6.2 Resumption.........................................69
8.7 IOTP Wallet Initialization...........................69
8.8 Payment Software Management..........................70
9. Mutuality.............................................70
9.1 Error Codes..........................................73
9.2 Attributes and Elements..............................82
10. Payment API Calls....................................94
10.1 Brand Compilation Related API Calls.................94
10.1.1 Find Accepted Payment Brand.......................94
10.1.2 Find Accepted Payment Protocol....................95
10.1.3 Get Payment Initialization Data...................97
10.1.4 Inquire Authentication Challenge..................99
10.1.5 Authenticate.....................................100
10.1.6 Check Authentication Response....................101
10.1.7 Cancel Payment...................................102
10.2 Brand Selection Related API Calls..................103
10.2.1 Find Payment Instrument".........................103
10.2.2 Find Payment Protocol............................105
10.2.3 Check Payment Possibility........................107
10.2.4 Quit Payment Instrument..........................109
10.3 Payment Transaction Related API calls..............110
10.3.1 Start Payment Consumer...........................110
10.3.2 Start Payment Payment Handler....................112
10.3.3 Resume Payment Consumer..........................115
10.3.4 Resume Payment Payment Handler...................116
10.3.5 Continue Process ................................117
10.4 General Inquiry API Calls..........................120
10.4.1 Inquire Payment Log..............................120
10.4.3 Payment Instrument Inquiry.......................124
10.4.4 Inquire Pending Payment..........................126
10.5 Payment Related Inquiry API Calls..................127
10.5.1 Check Payment Receipt............................127
10.5.2 Expand Payment Receipt...........................128
10.5.3 Inquire Process State............................129
10.5.4 Start Payment Inquiry............................131
10.5.5 Inquire Payment Status...........................131
11. Called Functions....................................134
11.1 Call Back Function.................................135
11.2 Work and Payment Log Database Function.............136
12. Security Consideration...............................141
Full Copyright Statement.................................141
References...............................................141
Author's Address.........................................142
Expiration and File Name.................................143
1. Introduction 1. Introduction
Common network technologies base on standardized and established Common network technologies are based on standardized and established
Internet technologies. The Internet technologies provide mechanisms Internet technologies. The Internet technologies provide mechanisms
and tools for presentation, application development, network and tools for presentation, application development, network
infrastructure, security, and basic data exchange. 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 Due to the presence of already installed trading roles' systems with
their own interfaces (Internet shop, order management, payment, their own interfaces (Internet shop, order management, payment,
billing, and delivery management systems, or financial institute's billing, and delivery management systems, or financial institute's
legacy systems), IOTP defines the common external (Internet) legacy systems), IOTP has been limited to the common external
interface between these systems. Initially, this consideration leads interface over the Internet. However, some of these internal
to the two-level layered view of the IOTP software for each role, interfaces might be also standardized for better integration of IOTP
consisting of the generic IOTP frontend part providing IOTP based aware components with of the existing infrastructure and its cost
gateway services and the trading roles' specific backend systems effective reuse.
implementing the actual trading transaction types' functionality.
These software components communicate with each other and might have
been even provided by different software suppliers.
As IOTP extends payment schemes to a trading protocol, the IOTP
application glues different payment software components. However, the
Consumers' requirements can be lowered to the sole support of
multiple payment methods. Therefore, the IOTP application splits into
three main component types:
o the IOTP Application Core processes the generic parts of the IOTP
transaction and connects to the Internet,
o the Existing Legacy System resp. Existing Payment Software
processes the actual transaction type resp. payment transaction,
o the IOTP Middleware resp. IOTP Payment Bridge connects the other
two components. It extends the Existing Legacy System with an
interface compatible with the one offered by the IOTP Application
Core. The latter maps the Payment API calls to the payment software's
specific calls.
Actually, the trading architecture splits into five logical layers
that reflect the aspects of external Internet and user interfaces,
internal generic IOTP message processing, backend preparation of the
transaction's content, their processing at 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 the five layers, and sketches their (internal) interfaces.
Generally, some of these interfaces are specified 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 or near- The typical Payment Handlers, i.e., financial institutes or near-
bank organizations, require an IOTP aware application that easily bank organizations, as well as Merchants require an IOTP aware
fits into their existing financial infrastructure. The Payment application that easily fits into their existing financial
Handler may even insist on the reuse of special in-house solutions infrastructure. The Payment Handler might even insist on the reuse of
for some subtasks of the IOTP aware application, e.g., reflecting special in-house solutions for some subtasks of the IOTP aware
their cryptography modules, gateway interfaces, or physical application, e.g., reflecting their cryptography modules, gateway
environment. Therefore, their IOTP aware application really needs interfaces, or physical environment. Therefore, their IOTP aware
both well defined external and internal interfaces. implementation really requires such clear internal interfaces.
However, the significance of such an architecture depends on the
product's target group. Generally, Payment Handlers have stronger
products requirements with respect to modularization and clear
internal interfaces than Consumers. But even the Consumer's IOTP
application aims at the support of multiple payment methods.
Particularly, Consumers prefer the flexible use of different seamless
integrating payment methods within one trading application with
nearly identical behavior and user interfaces.
The second part of the document (Chapters 7 to 11) refines one
specific internal interface to an actual Application Programming
Interface (API), i.e., Payment API, that bases on the functional
specification of Baseline IOTP [RFC XXXX]. This API aims at the
realization of a plug-in mechanism for payment specific software.
Currently, several payment software components from different
suppliers exist. Due to the payment method independence of IOTP, the
IOTP application must deal with and should provide a mostly common
interface for them. Therefore, this Payment API proposes an interface
between the generic IOTP Application Core and the Existing Payment
Software. Although, the highest significance of this API is
recognized at the Consumer, Payment Handlers offering multiple
transactions will also benefit, because such an API reduces the
overhead of integration, customization etc. of the IOTP aware
application.
1.1 Intended Readership
Software and hardware developers; development analysts, and users of
payment protocols.
GENERAL TRADING ARCHITECTURE
2. Trading Architecture
The general architecture suits for a broad range of applications, and
several abstract interfaces are identified between the architecture
components. Of course, such an architecture defines only the initial
starting point for an incremental process of refinements that ends in
an actual implementation. This incremental process hides superfluous
details very long and clarifies the roles of the components and their
interfaces very early.
2.1 Overview
The Trading Architecture consists of several layers and components
providing specific functionality. There exist well- defined
interfaces between the layers that are introduced in this section.
Implementation variants are derived from this abstract description.
For electronic commerce on the Internet, the implementation obviously
bases on HTML, HTTP, and TCP/IP. However, mobiles and set top boxes
may introduce other techniques.
The components can be distributed over different platforms, e.g.,
main server and server stations. The combination of implementation
variants and component distribution leads to actual scenarios, e.g.,
TCP/IP, WWW, and Java on a server station at the merchant or
financial institute. But these actual scenarios are out of the scope
of this proposal.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
------------------ Trading Architecture ---------
| components that may spread |
| across layers |
V V
Implementation variants <------------> Component Distribution
tcp/ip - www, java main server
other server station
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
The specification of the Trading Architecture starts with the general
logical partition of the layers.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
End system layer
o Web browser or standard software interacting with the user
network layer
o tcp/ip, other
access layer
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
o integrity
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 2: Architecture Layers and Implementation Examples
2.1.1.1 Consumer Access - End System Layer
The end system uses the World Wide Web for presentation purposes
supporting graphical mechanisms for interaction, animated
graphical objects, photos, audio, and video tracks. In this
moment, these technologies are already implemented in highly
available web browsers. These software components are bundled
with newer releases of operating systems for 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 the future, other networks and devices like set-top boxes
for Pay-TV will be the target of IOTP implementations, too.
The Internet features an open network infrastructure between the
consumer and 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 the
transmission security. Currently, this demands can not be
fulfilled by the Web-browser, solely. Instead special helper
applications have to be installed at the consumer's side.
Actually, the client-sided end system layer consists also 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' capabilities spread across the access to the data
layer.
o The functionality of helper applications may spread across
refinement to data layer.
o The IOTP wallet mainly belongs to the refinement layer.
o The actual payment software, e.g. SET wallet, inclusive its
helper applications like chip card reader drivers belongs to
the application/data layer.
However, the following discussion of these layers assumes their
location at the server side.
2.1.1.2 Network Layer
The network layer is operated by network providers 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, and even financial institutes.
This layer aims at the abstraction from particular network
services like TCP/IP, HTTP, or Pay-TV networks. Application data,
i.e., IOTP message content and payment specific data, is
transparently passed 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 - Integration with IOTP
Standardized protocols promise strong flexibility for the choice
of application suppliers, prevent the dependence on a particular
one, and yield compliance and interoperability. Often, the
server-located systems have quite long life cycles, despite the
short development cycles of hardware and software.
These two cycles lead to two concurrent goals. The first goal
intends long-termed stability and security of investments. The
second requires the accurate consideration of new developments.
The IOTP Application Core represents the generic part of an IOTP
aware trading environment that provides IOTP specific document
formatting and security mechanisms. It connects to the
transaction specific backend systems.
2.1.1.5
The processing of the actual transaction data is performed by the
Existing Legacy Systems resp. Existing Payment Software being
reused for IOTP based (Internet) trading. They may even apply
their own document formatting and security mechanisms on the
application data being transparently embedded in IOTP messages.
2.1.1.6 Data Layer
The Existing Legacy Systems provide their specific data
management systems for data storage, security, or backup.
However, the internal structure of the Application and Data Layer
is out of the scope of this document.
2.1.2 Implementation Variants
The implementation variant defines the concrete realization 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 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 the upcoming of intelligent payment
periphery, e.g., intelligent chip card reader. E.g., the
architecture may be implemented at the 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 the server's and from the consumer's point of
view.
2.2 Requirements and Commitments
2.2.1 Basic Requirements
In addition to the aforementioned IOTP objectives, the user's
prospective must be considered.
2.2.1.1 Electronic Commerce Provider (Server)
o The Trading Architecture must be scaleable.
o The implementation must support the 24h/7d service. The online
dialog system should be always available. Precautions are
necessary that support changes, e.g., maintenance, during the
operating hours.
o The architecture must provide functions that can be used by
most of the providers. Therefore, the architecture clearly
describes its core components and the interface to the provider
specific services.
- The architecture addresses all layers inclusive the
refinement layer. The application and data layer may be
realized by the providers. Payment Handlers and big merchants
may implement these capabilities on behalf of their existing
installations.
- For example, the interface to the 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 for the
transmission and requirements for the operating environments at
the consumer's and provider's side reflect distinct security
levels. Baseline IOTP provides integrity protection but future
versions of IOTP will incorporate more sophisticated mechanisms
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 of
(inclusive layer IOTP of specific
authentication e.g. payment methods
chip card <-> provider)
{4} authorization application provider's
layer application
The security levels can be classified as follows:
o The Transmission Security 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 the Java applets belongs to this class. In addition,
products, information announcements, and trading offers that may lead
to an IOTP transaction require transmission security.
o The Application Security {2-4} provides the strongest protection
for 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 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 the provider is a financial institute.
This provider needs a special certificate and has to use particular
HTTP servers. The consumer has to use the newer releases of Web
browsers. Particular European browser add-ons close the security hole
outside the USA and Canada and offer world wide strong security 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 and weak integrity while SSL V3 offers weak
confidentiality but strong integrity. However, the usual RSA key size
is limited to 512 bits, in contrast to the normal key sizes of SET ,
CyberCash , eCash ( 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 the secure transmission of Java applets etc.
and the verification of its origin by the consumer. And it provides
the base for HTTP Basic Authentication or (mutual) authentication at
the application layer.
2.2.3.2 Authentication
ID / pass phrase pairs or certificates can prove 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 of the refinement layer process the IOTP level
document security. This includes:
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 by the use of transmission security mechanisms.
o validity
Counters, nonces, or unique transaction identifiers ensure message
freshness and prevent replay attacks.
o defense 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, this API may offer services for accessing some
central crypto hardware, too. This hardware stores the crypto keys
and performs the cryptographic operations. Such a device is expected
to be implemented by a chip card at the Consumer's side and by tamper
resistant security modules at the Payment Handler's side. The
equipment at the Merchant and Customer Care Providers may depend on
their expected load.
The refinement layer may require additional data for key management
purposes, i.e., certificates or private keys.
The result of this security verification is reported to the
application layer. Security warnings, e.g., replay attacks detected
at the refinement layer, may be forwarded to other application
modules, e.g., card or user management systems.
However, the refinement layer does not manage any security of
transparently embedded data like payment scheme specific data. Its
security needs to be handled by the application layer.
2.2.3.4 Authorization
The application layer implements the authorization procedures and
different procedures may be offered by the providers. The following
information influences the counterparty's verification:
o result of the authentication
derived from the document integrity reported by the refinement layer.
o result of the document integrity
evaluated information reported by the refinement layer.
o authorization
- user, account, or chip card status Verification of user,
account, or chip card presence and status.
- competence verification counterparty's, mainly consumer's,
authorization of the requested transaction type at the application
layer.
2.2.4 Protection against Attacks
In principle, multiple points of attacks exist that need accurate
protection:
o consumer's system,
o providers' systems respective their computing centers, and
o transmission line.
Generally, several providers are involved during each IOTP
transaction - even during the individual steps - while basically only
one consumer participates (consumer to business). This scenario may
be extended for business to business transactions in future versions
of IOTP.
2.2.4.1 Consumer System
The protection of the consumer's system, i.e., vulnerable personal
computer with unsecured applications, is quite difficult. Better
security is obtained by specialized consumer electronic components
that integrate chip cards implementing the important security
procedures in tamper resistant hardware. The following requirements
need to be satisfied by a PC based system.
o On the Internet, the transmission security should be ensured by an
SSL instance. Very sensible transactions should be secured by an SSL
implementation with full cryptographic strength.
o Additionally, the transaction data may be symmetrically or
asymmetrically secured by software or chip cards.
o Best security is obtained by the use of intelligent chip card
readers with an integrated keyboard and display. This allows the
secure input of pass phrases, the safe display of transaction data,
and the signature outside the personal computer. Viruses and Trojan
horses are not able to attack the chip card reader.
o The environment for the input of the transaction data needs to be
secured. Current implementations of Web browsers for personal
computers and workstations have many security holes, e.g., Java
virtual machine, ActiveX.
2.2.4.2 Transmission Line
The network providers control the security of the transmission line.
There is no additional danger, if strong cryptographic mechanisms for
end 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
The providers' end points for the transmission 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 the different quality of both security levels.
Additional protection against illegal access, e.g., a firewall, is
necessary. This does not secure the application data but addresses
system attacks from the public Internet.
3. Layers and Functional Components
A flexible architecture requires its partition into multiple logical
layers. These layers incorporate the functional components. Changes
at one layer may not necessarily imply changes at other layers. And,
the introduction of additional implementation variants does not
necessarily imply changes on all layers. The architecture consists of
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
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 the transaction message
5 application layer electronic commerce functionality 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 specific formats
access layer v
presentation services
presentation control monitor
transport coupling ^
| document format IOTP
refinement layer v
document security
document formatting ^
| 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 the layers inclusive the refinement layer
and their interfaces to the specific implementations of the
provider's applications.
3.1 End System Layer
The end system layer is localized at the consumer's side. The
architecture defines the components for electronic commerce. It
considers the use 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. This application may bolt on
standard software or browser based applications. The implementation
should reflect 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 checks of the IOTP structure (segments,
lengts, elements, attributes etc.)
o logical compression
transport coupling
o network protocols
o transmission security
o access protection
IOTP kernel maintenance
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 4: Components and 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 for the data
presentation, too. This applies both to personal computers and other
consumer electronic end devices.
There are no requirements how to provide this functionality.
Generally, two classes can be distinguished:
o program parts base on intelligent browser extensions like Java
applets, plug-ins or helper applications.
o standard products for electronic commerce.
3.1.2 Document Formatting
This component includes functions for the generation and analysis of
IOTP messages as well as mechanisms for initialization and
termination of IOTP transactions. They correspond to those of 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 the components presentation software, document
security, transport coupling, and IOTP kernel maintenance. It
controls their behavior.
This general concept 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 the very general
refinement layer. The architecture may remain unchanged if another
protocol or some future IOTP version replaces Baseline IOTP. However,
the consumer's system generates complete transaction messages and
transfers them to the provider considering all security aspects.
3.1.3 Document Security
This component provides (chip card based) document security services
that correspond to the respective services of the refinement layer.
3.1.4 Transport Coupling
This component manages communication channels in cooperation with the
respective components 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 as
well as application 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 be reported to
the access layer's component transport coupling together with the
determined characteristics of the end device.
Currently, Baseline IOTP neglects this option due to the lack of any
standardized clarification of the reportable data.
3.3 Access Layer
The access layer defines the entry point to the provider's sphere and
controls the presentation dialogs with the consumer's end device.
This layer does no processing on the transaction 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 be offered by the
merchant trading role.
The presentation controls and their dialog steps are realized in so-
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 the application subsystems, their distribution,
supervision, and statistics.
The access layer consists 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 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 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
the WWW. This coupling of presentation services is called standard
coupling. In the case of WWW, the socket standard defines the
coupling for both transmission channels.
Both the implementation of the access layer and the standard coupling
should 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 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
The socket protection component implements the transmission security
on the public network. On the Internet, SSL may implement this
service at IOTP message level while the Existing Legacy Systems and
Existing Payment Software may secure their specific transaction data
on their own at the application layer in advance to its encapsulation
in IOTP.
3.3.1.3 Access Protection
Components are needed that limit the remote access and protect the
provider's infrastructure against attacks from the public network.
Firewalls and packet filters do this for TCP/IP based network
protocols. However these component prevent illegal access 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 and the presentation systems, and supports the
professional operation.
The presentation control monitor contains the following
subcomponents:
o frame dialogs Each frame dialog relates to and controls the
respective presentation service. The presentation control monitor
manages the connections (channels) to the individual frame dialogs.
The monitor provides the following functionality:
- selection of the frame dialogs components and their presentation
services
- initialization, termination and channel supervision for
transport coupling
- requesting and forwarding of transport profiles for control
purposes of the network layer
o parameterized subsystem distribution provides functionality
complementary to the application monitor:
- mapping of the frame dialog's sessions to the application layer
- supervision and transport parameterization of 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 be able to log
the history of the dialog steps and the progress of IOTP message
exchanges for each session, hereby delivering the raw data for
subsequent analyses. o statistics and reporting functions Online
statistics about the maximal and current number of connections and
the states of the electronic commerce environment are necessary.
They enable the detection of bottle necks and system adjustments.
- error processing
The monitor must be able to report specific error messages to the
consumer's system and to the provider's applications. These
messages can be used by the user help desk for error localization,
too.
- trace function
The monitor's dialog control should be traceable, i.e., the monitor
should provide a logging function for its own actions. This trace
function should be able to trace subsets of connections.
3.3.1.5 Parameterized Subsystem Distribution
This function complements the subsystem distribution of the
application monitor. Based on information of the network layer, the
presentation control monitor initiates the connection 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 the frame dialog's functionality yields:
o presentation services
They implement 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 the Internet are HTML pages;
scripts, applets, and pre-installed applications. The main functions
are:
- management of provider specific data, individual presentation
possibilities
Often, the provider requires a specific look & feel (logos,
colors). 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 be activated after a specific user
input. The frame dialog coincides with a table automaton. These
tables must be customizable and maintainable. The dialog controller
must support tracing in order to prevent 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 the document transport for electronic commerce. The
provider's Web server or the IOTP aware application represents the
corresponding implementation. It is based on standard TCP/IP
protocols with the usage of an intermediate presentation protocol
(HTTP). The socket protection component may be disabled, if 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 More important, Consumers demand modularization and clear internal
server. Its implementation requires the distinction between the interfaces: Their IOTP application aims at the support of multiple
consumer's and the merchant's / deliverer's / Payment Handler's payment methods. Consumers prefer the flexible use of different
sphere. 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.
6.1 Consumer's Sphere Initially, this consideration leads to the two-level layered view of
the IOTP software for each role, consisting of
The following discussion distinguishes between two different types of o some generic IOTP system component, the so-called IOTP application
end systems. core - providing IOTP based gateway services and generic business
logic and
A standard application may implement all services on its own. Solely, o the trading roles' specific backend systems implementing the
it has to fulfill the requirements of the IOTP protocol. specific trading transaction types' functionality.
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 In order to isolate the changes on the infrastructure, the IOTP
order to provide full SSL security outside of USA and Canada. The trading application has been three-layered:
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 o the IOTP Application Core processes the generic parts of the IOTP
discussion and needs to be formalized in an subsequent document. The transaction and holds the connection to the Internet,
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 o the Existing Legacy System or Existing Payment Software which
processes the actual transaction type, and particular payment
transaction, and
A powerful server station with a decentralized operating system like o the IOTP Middleware or IOTP Payment Bridge which glues the other
UNIX may implement the access layer. Such a server station may be two possibly incompatible components. It brokers between the specific
located at a computing center, at the Internet services provider, interface of the Existing Legacy System and the standardized
etc. It runs the following jobs: interfaces of the IOTP Application Core.
- Web server As IOTP extends payment schemes to a trading scheme, primarily, this
- SSL server document focuses on payment modules, i.e. the interface between the
- IOTP Application Core IOTP Payment Bridge and the IOTP Application Core. It provides a
standard method for exchanging payment protocol messages between the
parties involved in a payment. But, it does not specify any interface
for order or delivery processing.
The general cooperation of the IOTP Application Core and the Existing Such a Payment Application Programmers Interface (API) must suit for
Legacy System is outside the scope of this document. However, the a broad range of payment methods: (1) software based like Credit Card
connection to particular Existing Payment Software is discussed in SET or CyberCoin, (2) chip card based like Mondex or GeldKarte, and
the next chapter. The IOTP Application Core may be a slim IOTP (3) mimicries of typical and traditional payment methods like money
monitor (IOTP application level gateway) that forwards the IOTP transfer, direct debit, deposit, withdrawal, money exchange and value
documents to the actual IOTP Application Core located anywhere else points. It should support both payments with explicit consumer
in the demilitarized zone or interior network. acknowledge and automatic repeated payments, which have been consumer
approved in advance.
Additional components may protect the server station against attacks The following discussion focuses on the Consumer's point of view and
from the Internet. Such products as well as the respective uses the associated terminology. When switching to Merchants' or
(consultation) services are highly available. Therefore, this Delivery Handlers' IOTP aware applications, the payment related
document does not address these traditional network security risks. components should be implicitly renamed by Existing Legacy Systems to
the IOTP Middleware.
Any gateway in the interior net may convert the traffic between The next two sub-sections describe the general payment scenario and
TCP/IP and other protocols. Herewith, IOTP documents can be several assumptions about the coarsely sketched software components.
transmitted to arbitrary IOTP systems.
IOTP Payment API Chapter 2 illustrates the payment transaction progress and message
flow of different kinds of transaction behavior. Chapters 3 to 4
provide the details of the API functions and Chapter 5 elaborates the
call back interface.
7. Payment API 1.1 General payment phases
The Internet Open Trading Protocol extends pure payment schemes like The following table sketches the four logical steps of many payment
SET, SSL based payments, or CyberCash to a trading protocol, that schemes. The preceding agreements about the goods, payment method,
deals with purchase orders, payment receipts, and delivery responses purchase amount, or delivery rules are omitted.
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 Payment State Party Example Behavior
The following table sketches the four logical steps of many payment Mutual Payment Handler Generation of identification
transactions. The preceding agreement about the goods, payment method Authentication request, solvency request, or
and purchase amount is omitted. and Init- some nonce
ialization Consumer Responses to the requests and
generation of the own nonce
Payment State Party Behavior Authorization Payment Handler Generation of the authorization
Mutual Payment Handler E.g., generation of request (for consumer)
Authentication identification request, solvency Consumer Agreement to payment (by
request, and some nonce reservation of the Consumer's
Consumer E.g., responses to the requests, e-money)
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 Payment Handler Acceptance or rejection of the
authorization response agreement (consumer's
Capture generation of the capture authorization response),
request generation of the authorization
Consumer Charge request (for issuer/acquirer),
and processing of its response
Capture Generation of the capture
request (for issuer/acquirer)
Consumer Is charged
Payment Handler Acceptance or rejection of the Payment Handler Acceptance or rejection of the
e-money, closing of the payment e-money, close of the payment
transaction transaction
Reversal On rejection: general of the
reversal data Reversal On rejection (online/delayed):
generation of the reversal data
Consumer Receipt of the refund Consumer Receipt of the refund
Some payment methods do not distinguish between authorization and However, some payment schemes
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 o limit themselves to one-sided authentication,
IOTP wallet supports different payment methods and the registration o perform offline authorization without any referral to any
of new payment methods which might be achieved by a common Payment issuer/acquirer,
API. Payment Handlers will also benefit from such a Payment API that o apply capture processing in batch mode, or
standardizes the connection to their legacy systems, if they offer o do not distinguish between authorization and capture,
payment services for multiple payment methods. o lack an inbound mechanism for reversals or implement a limited
variant.
The Payment API provides a standard method for exchanging payment This model applies not only to payments at the typical points of
protocol messages between the parties involved in a payment sales but extends to refunds, deposits, withdrawals, electronic
(resolution). The existence of a well defined Payment API enables cheques, direct debits, and money transfers.
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 1.2 Assumptions
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 In outline, the IOTP Payment Bridge processes some input sequence of
is illustrated in the following figure. The relationship between payment protocol messages being forwarded by the IOTP Application
these components are arbitrary: One IOTP Application Core may manage Core. It (1) disassembles the messages, (2) maps them onto the
multiple IOTP Payment Bridges, which may manage multiple Existing formats of the Existing Payment Software, (3) assembles its
Payment Software components, which may manage multiple payment responses, and (4) returns another sequence of payment protocol
methods. Finally, each payment method may support multiple payment messages that is mostly intended for transparent transmission by the
instruments. Vice versa, several IOTP Payment Bridges may share IOTP Application Core to some IOTP aware remote party. Normally, this
Existing Payment Software and even share payment methods. process continues between the two parties until the Payment Handler's
Payment API signals the payment termination. Exceptionally, each
system component may signal failures.
The relationship between the aforementioned components is illustrated
in the following figure. These components might be related to each
other in a flexible n-to-m-manner:
o One IOTP Application Core may manage multiple IOTP Payment
Bridges and the latter might be shared between multiple IOTP
Application Cores.
o Each Payment Bridge may manage multiple Existing Payment
Software modules and the latter might be shared between multiple
Payment Bridges.
o Each Existing Payment Software may manage multiple payment
schemes (e.g. SET) and the latter might be supported by multiple
Existing Payment Software modules.
o Each payment scheme may support multiple payment instruments
(e.g. particular card) or methods (e.g. Visa via SET) and the
latter might be shared by multiple Existing Payment Software
Components.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant) IOTP client (consumer) <---------------> IOTP server (merchant)
^ Internet ^ ( contains Internet ( containes
IOTP Application Core) IOTP Application Core)
^ ^
| IOTP Payment | IOTP Payment | IOTP Payment | IOTP Payment
| API | API | API | API
v v v v
IOTP/Payment Bridge IOTP/Payment Bridge IOTP Payment Bridge IOTP Payment Bridge
^ ^ ^ ^
| Existing Payment APIs, e.g., | | Existing Payment APIs, e.g., |
| SET, Mondex, etc. | | SET, Mondex, etc. |
v v v v
Existing Payment Software Existing Payment Software Existing Payment Software Existing Payment Software
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 11: Relationship of the Components Figure 1: 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 The Payment API considers the following transaction types of Baseline
IOTP [RFC XXXX]: IOTP [IOTP]:
o Baseline Purchase, o Baseline Purchase,
o Baseline Refund, o Baseline Refund,
o Baseline Value Exchange, o Baseline Value Exchange,
o Baseline Withdrawal, and o Baseline Withdrawal, and
o Baseline (Payment) Inquiry. o Baseline (Payment) Inquiry.
First, the vision of the IOTP aware application's and its main First, the authors' vision of the IOTP aware application's and its
components' capabilities are clarified. On the one hand, the Payment main components' capabilities are clarified: On the one hand, the
API should be powerful and flexible such that the IOTP Application Payment API should be quite powerful and flexible for sufficient
Core really benefits from it. On the other hand, it should not be connection of the generic and specific components. On the other hand,
overloaded with stuff that is not supported by Existing Payment the Payment API should not be overloaded with nice-to-haves being
Software. Furthermore, the requirements of Consumers and Payment unsupported by Existing Payment Software.
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 Despite the strong similarities on the processing of successful
payments, failure resolution and inquiry capabilities differ
extremely among different payment schemes. These aspects may even
vary between different payment instrument using the same payment
schemes. Eventually, the specific requirements of Consumers,
Merchants and Payment Handlers add variance and complexity.
Therefore, it is envisioned that the IOTP Application Core provides
only very basic inquiry mechanisms while complex and payment scheme
specific inquiries, failure analysis, and failure resolution are
fully deferred to the actual Existing Payment Software - including
the user interface.
The IOTP Application Core processes payments transparently, i.e., it
forwards the wrapped payment scheme specific messages to the
associated IOTP Payment Bridge/Existing Payment Software. The
Existing Payment Software might even use these messages for inbound
failure resolution. It reports only the final payment status to the
IOTP Application Core or some intermediate - might be also final -
status on abnormal interruption.
The IOTP Application Core implements the generic and payment scheme
independent part of the IOTP transaction processing and provides the independent part of the IOTP transaction processing and provides the
suitable user interface. Focusing on the payment, it suitable user interface. Focusing on payment related tasks, it
o manages the registered IOTP Payment Bridges, inclusive their o manages the registered IOTP Payment Bridges and provides a
registration process, mechanism for their registration - the latter is omitted by this
document.
o supports the Consumer's payment instrument selection preceding the o assumes that any IOTP Payment Bridge is a passive component, i.e.,
payment request, it strictly awaits input data and generates one response to each
request,
o invokes and requests additional payment specific support from the o supports the payment negotiation (Consumer: selection of the actual
selected and registered Existing Payment Software through the IOTP payment instrument or method; Merchant: selection of the payment
Payment Bridge, methods being offered to the Consumer) preceding the payment request,
o initializes and terminates the Existing Payment Software through o requests additional payment specific support from the Existing
the IOTP Payment Bridge, Payment Software via the selected and registered the IOTP Payment
Bridge,
o requests authentication data from the Consumer, o initializes and terminates the Existing Payment Software via the
IOTP Payment Bridge,
o inquires authentication data (for subsequent request or response)
from the Existing Payment Software, specific authentication component
- omitted in this document - or Consumer (by a suitable user
interface),
o supervises the online transaction process and traces its progress, o supervises the online transaction process and traces its progress,
o implements any payment transaction progress indicator, o stores the transaction data being exchanged over the IOTP wire -
payment scheme specific data is handled transparently,
o offers generic dialogs to the Existing Payment Software, e.g. pass o relates each payment transaction with multiple payment parameters
phrase input, basic transaction inquiry, balance inquiry, brand (IOTP Transaction Identifier, Trading Protocol Options, Payment
selection payment acknowledge, payment instrument insertion, payment Instrument/Method, Offer Response, IOTP Payment Bridge, and Wallet
suspension / cancellation, Identifier, associated remote Parties). The relation might be lowered
to the party's Payment Identifier, IOTP Payment Bridge, Wallet
Identifier, and the remote parties when the actual payment
transaction has been successfully started.
o validates (previously) received payment receipts and the status of o implements a payment transaction progress indicator,
(terminated) payment transactions,
o stores the transaction data and offers basic data base facilities o enables the inquiry of pending and completed payment transactions,
and basic inquiry mechanisms for payment transactions,
o supports the invocation of the existing software modules in an o implements generic dialogs, e.g., brand selection, payment
interactive mode for further payment method specific transaction acknowledge, payment suspension / cancellation, receipt
post-processing, and visualization, basic transaction inquiry, balance inquiry, or receipt
validation,
o exports call back functions for use by the IOTP Payment Bridge or o defers payment specific processing, supervision, validation, and
Existing Payment Software for progress indication or database access. error resolution to the Existing Payment Software. It is expected,
that the Existing Payment Software tries to resolve many errors first
by the extended exchange of Payment Exchange messages. The most
significant and visible failures arise from sudden unavailability or
lapses of the local or opposing payment component.
In addition, the IOTP Application Core o supports the invocation of any Existing Payment Software in an
interactive mode, which might be used (1) for the payment scheme
specific post-processing of a (set of) payment transactions, (2) for
the analysis of a payment instrument, (3) for the registration of a
new payment instrument/scheme, or (4) re-configuration of a payment
instrument/scheme.
o enables the inquiry of pending and completed payment transactions, o exports call back functions for use by the IOTP Payment Bridge or
Existing Payment Software for progress indication.
o manages the IOTP components and IOTP blocks exchanged during the In addition, the IOTP Application Core
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) o manages the IOTP message components and IOTP message blocks
and each payment transaction with multiple payment parameters (IOTP exchanged during the transaction which may be referenced and accessed
Transaction Identifier, Trading Protocol Options, Payment Instrument, during the processing of subsequent messages, e.g., for signature
Offer Response, IOTP Payment Bridge, and Wallet Identifier). The verification. In particular, it stores named Packaged Content
latter association can be lowered to the Consumer Payment Identifier, elements exchanged during payments.
IOTP Payment Bridge, and Wallet Identifier when the payment
transaction has been successfully started.
o manages several kinds of identifiers, i.e., transaction, message, o manages several kinds of identifiers, i.e., transaction, message,
component, and block identifiers, component, and block identifiers,
o provides a message caching mechanism, o implements 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 o detects time-outs at the protocol and API level reflecting the
communication with both the remote party and the local periphery, communication with both the IOTP aware remote party and the Payment
e.g., chip card (reader) may raise time-outs. API aware 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 However, the IOTP Payment Bridge and Existing Payment Software do not
have to rely on the IOTP Application Core's capabilities. E.g., they have to rely on all of these IOTP Application Core's capabilities.
may implement several dialogs on their own or they may refuse the E.g., some Consumer's Existing Payment Software may refuse the
export of specific payment instruments at brand selection time and disclosure of specific payment instruments at brand selection time
may defer this selection to the Check Payment Possibility step using and may delay this selection to the "Check Payment Possibility"
their own user interface. invocation using its own user interface.
The IOTP Payment Bridge's capabilities deal not only with actual The IOTP Payment Bridge's capabilities do not only deal with actual
payments from the Consumer to the Payment Handler but extend to the payments between the Consumer and the Payment Handler but extend to
following: the following:
o translation of messages between the formats of the IOTP o translation and (dis)assemblage of messages between the formats of
Application Core and the Existing Payment Software. If one IOTP the IOTP Payment API and those of the Existing Payment Software.
payment API call splits into multiple Existing Payment Software Payment API requests and response are strictly 1-to-1 related.
calls, it has to assemble their output to one IOTP payment API
response.
o Consumer's payment instrument selection by the means of an o Consumer's payment instrument selection by the means of an
unsecured export of the relationship of payment brands, payment unsecured/public export of the relationship of payment brands,
protocols, and payment instruments (identifiers). Generally, this payment protocols, and payment instruments (identifiers). Generally,
includes not just the brand (Mondex, GeldKarte, etc.) but also which this includes not just the brand (Mondex, GeldKarte, etc.) but also
specific instance of the instrument and currency to use (e.g. which which specific instance of the instrument and currency to use (e.g.
specific Mondex card and which currency of all those available). which specific Mondex card and which currency of all those
However, some payment methods may defer the selection of the payment available).
instrument to the actual payment carrying-out or they may even lack
any management of payment instruments. E.g., chip card based payment However, some Existing Payment Software may defer the selection of
methods may offer - Point of Sale like - implicit selection of the the payment instrument to the actual payment carrying-out or it may
payment instrument through simple insertion of the respective chip even lack any management of payment instruments. E.g., chip card
card into the chip card reader or they interrogate the inserted card based payment methods may offer - Point of Sale like - implicit
and request an acknowledge (or selection) of the detected payment selection of the payment instrument by simple insertion of the chip
card into the chip card reader or it interrogates the inserted card
and requests an acknowledge (or selection) of the detected payment
instrument(s). instrument(s).
o payment progress checks, e.g., is there enough funds available to o payment progress checks, e.g., is there enough funds available to
carry out the purchase, carry out the purchase, or enough funds left for the refund,
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 - o IOTP Payment Receipt checks which might be performed over its
checks. Furthermore, it may support payment method specific Payment Packaged Content or by other means.
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 o recoding of payment scheme specific receipts into a format which
IOTP Payment Receipt or actual payment method specific Payment can be displayed to the user or printed,
Receipt into a format which can be displayed to the user or printed,
o cancellation of payment, even though it is not complete, o cancellation of payment, even though it is not complete,
o suspension and resumption of payment transactions. One source of o suspension and resumption of payment transactions. Two kinds of
failure the Existing Payment Software has to deal with is the time- failures the Existing Payment Software might deal with are (1) the
out of the network connection. For resolution, the IOTP Application time-out of the network connection and (2) lack of funds. For
Core may try the suspension with a view to later possible resumption. resolution, the IOTP Application Core may try the suspension with a
Alternatively, the IOTP Application Core may signal the transaction's view to later possible resumption.
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 o recording the payment progress and status on a database. E.g.,
determine the appropriate next step. information about pending payments might be used to assist their
continuation when the next payment protocol message is received.
o inquiry on payment transactions. Particularly, the inquiry of o payment transaction status inquiry, so that the inquirer - IOTP
transactions with specific transaction states should be supported. Application Core or User - can determine the appropriate next step.
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 o balance inquiry or transaction history, e.g. consumers may
the IOTP Payment Bridge. It may evaluate local databases, log files, interrogate their chip card based payment instrument or remotely
chip cards, or remote account manager. administer some account in advance of a payment transaction
acknowledge,
o recording the payment progress and status on a database. E.g., o inquiry on abnormal interrupted payment transactions, which might
information about pending payments can be used to assist their be used by the IOTP Application Core to resolve these pending
continuation when the next payment protocol message is received. transactions at startup (after power failure).
o payment progress indication. This could be used to inform the end o payment progress indication. This could be used to inform the end
user of details on what is happening with the payment. user of details on what is happening with the payment.
o payment method specific authentication methods. o payment method specific authentication methods.
Existing Payment Software may not provide full support of these Existing Payment Software may not provide full support of these
capabilities. E.g., some payment protocols may not support or even capabilities. E.g., some payment schemes may not support or even
prevent the explicit transaction cancellation at arbitrary phases of prevent the explicit transaction cancellation at arbitrary phases of
the payment process. Therefore, the IOTP Payment Bridge has to the payment process. In this case, the IOTP Payment Bridge has to
implement at least skeletons that signal any lack of support back to implement at least skeletons that signal such lack of support by the
the caller by the use of error codes (see below). The Existing use of specific error codes (see below).
Payment Software's capabilities vary extremely. It
o supports the actual online payment transaction, The Existing Payment Software's capabilities vary extremely. It
o resolves most types of payment specific failures, o supports payment scheme specific processing, supervision,
validation, and error resolution. It is expected, that many errors
are tried to be resolved first by the extended exchange of Payment
Exchange messages.
o provides hints for out-of-band failure resolution on failed o provides hints for out-of-band failure resolution on failed inbound
immediate resolution, resolution - inbound resolution is invisible to the IOTP Application
Core.
o may implement transaction data management and inquiry mechanisms o may implement arbitrary transaction data management and inquiry
ranging from no transaction recording, last transaction recording, mechanisms ranging from no transaction recording, last transaction
chip card deferred transaction recording, simple transaction history recording, chip card deferred transaction recording, simple
to very sophisticated implementations with flexible user inquiry transaction history to sophisticated persistent data management with
capabilities. The latter is required by Payment Handlers for easy and flexible user inquiry capabilities. The latter is required by Payment
cost effective failure resolution. Handlers for easy and cost effective failure resolution.
o may rely on the generic dialogs of the IOTP Application Core. o implements the payment scheme specific dialog boxes.
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- Even the generic dialog boxes of the IOTP Application Core might be
out failure, each party requires a reliable analysis of the current unsuitable: Particular (business or scheme) rules may require some
payment transaction status and hints about the possible resolution dedicated appearance / structure / content or the dialog boxes, may
alternatives. Common payment revocation by (e)mail, fax, or voice prohibit the unsecured export of payment instruments, or may
telephone becomes useless if the content of any chip card needs to be prescribe the pass phrase input under its own control.
modified.
8. Message Flows 2. Message Flow
The Payment API calls are distinguished between general and payment The following lists all functions of the IOTP Payment API:
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 o Brand Compilation Related API Functions
"Find Accepted Payment Brand" identifies the accepted payment brands "Find Accepted Payment Brand" identifies the accepted payment brands
for the indicated currency amount. for any indicated currency amount.
"Find Accepted Payment Protocol" identifies the accepted payment "Find Accepted Payment Protocol" identifies the accepted payment
protocols and returns payment scheme specific packaged content for protocols for any indicated currency amount (and brand) and returns
brand selection purposes. payment scheme specific packaged content for brand selection
purposes.
This function might be used in conjunction with the aforementioned
function or called without any brand identifier.
"Get Payment Initialization Data" returns additional payment scheme "Get Payment Initialization Data" returns additional payment scheme
specific packaged content for payment processing by the payment specific packaged content for payment processing by the payment
handler. handler.
"Inquire Authentication Challenge" returns the payment scheme "Inquire Authentication Challenge" returns the payment scheme
specific authentication challenge value. 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 "Check Authentication Response" verifies the returned payment scheme
specific authentication response value. specific authentication response value.
"Cancel Payment" terminates the payment transaction immediately. This "Change Process State" is used (here only) for abnormal termination.
API function is a short cut to some specific "Change Process State" (cf. Payment Processing Related API Functions).
call.
o Brand Selection Related API Calls o Brand Selection Related API Functions
"Find Payment Instrument" identifies which instances of a payment "Find Payment Instrument" identifies which instances of a payment
instrument of a particular payment brand are available for use in a instrument of a particular payment brand are available for use in a
payment. payment.
"Find Payment Protocol" identifies which payment protocols are "Find Payment Protocol" identifies which payment protocols are
supported by a specific payment instrument, resp. payment brand. supported by a specific payment instrument, resp. payment brand.
"Check Payment Possibility" checks whether a payment instrument is This function might be used in conjunction with the aforementioned
able to perform a payment. function or called without any brand identifier.
"Quit Payment Instrument" terminates a payment transaction, even "Check Payment Possibility" checks whether a specific payment
before the transaction has been initiated towards the Payment Handler instrument is able to perform a payment.
(short cut for "Change Process State").
"Authenticate" (cf. Brand Compilation Related API Calls) "Authenticate" forwards any payment scheme specific authentication
data to the IOTP Payment Bridge for processing.
o Payment Transaction Related API Calls "Change Process State" is used (here only) for abnormal termination.
(cf. Payment Processing Related API Functions).
o Payment Processing Related API Functions
"Start or Resume Payment Consumer/Payment Handler" initiate or resume "Start or Resume Payment Consumer/Payment Handler" initiate or resume
a payment transaction. There exist specific API calls for the two a payment transaction. There exist specific API functions for the two
trading roles Consumer and Payment Handler. trading roles Consumer and Payment Handler.
"Continue Process" forwards payment scheme data to the Existing "Continue Process" forwards payment scheme specific data to the
Payment Software and returns more payment scheme data for Existing Payment Software and returns more payment scheme specific
transmission to the counterparty. data for transmission to the counter party.
"Change Process State" changes the current status of payment "Change Process State" changes the current status of payment
transactions. Typically, this call is used for successful/less transactions. Typically, this call is used for successful/- less
termination of suspension. termination or suspension.
oGeneral Inquiry API Calls
"Inquire Payment Log" interrogates the payment log for different o General Inquiry API Functions
kinds of payments. The interrogation is adjustable by multiple
parameters.
"Remove Payment Log" removes one specific entry from the Payment Log. "Remove Payment Log" notifies the IOTP Payment Bridge that a
particular entry has been removed from the Payment Log of the IOTP
Application Core.
"Payment Instrument Inquiry" retrieves the properties of Payment "Payment Instrument Inquiry" retrieves the properties of Payment
Instruments. Instruments.
"Inquire Pending Payment" reports whether the IOTP Payment Bridge has "Inquire Pending Payment" reports any abnormal interrupted payment
pending transactions. transaction known by the IOTP Payment Bridge.
o Payment Transaction Related Inquiry API Calls Payment Processing Related Inquiry API Functions
"Check Payment Receipt" checks the validity of IOTP Payment Receipts, "Check Payment Receipt" checks the consistency and validity of IOTP
returned by an "Inquire Process State" API call. It is used to check Payment Receipts, received from the Payment Handler or returned by
that the payment receipt is consistent and/or matches the respective "Inquire Process State" API calls. Typically, this function is called
payment transaction. Typically, it is used by the Consumer during the by the Consumer during the final processing of payment transactions.
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 Nevertheless, this check might be advantageous both for Consumers and
Contents and payment specific payment receipts into a form which can Payment Handlers on failure resolution.
be used for display or printing purposes.
"Inquire Process State" responds with the payment status and the IOTP "Expand Payment Receipt" expands the Packaged Content of IOTP Payment
Payment Receipt Component. Normally, it is called by the Payment Receipts as well as payment scheme specific payment receipts into a
Handler for final processing of the payment transaction. form which can be used for display or printing purposes.
"Inquire Process State" responds with the payment state and the IOTP
Payment Receipt Component. Normally, this function is called by the
Payment Handler for final processing of the payment transaction.
"Start Payment Inquiry" prepares the remote inquiry of the payment "Start Payment Inquiry" prepares the remote inquiry of the payment
transaction status and responds with payment scheme specific data transaction status and responds with payment scheme specific data
that might be needed by the Payment Handler for the Consumer that might be needed by the Payment Handler for the Consumer
initiated inquiry processing. initiated inquiry processing.
"Inquire Payment Status" is called on Consumer initiated inquiry "Inquire Payment Status" is called by the Payment Handler on Consumer
requests by the Payment Handler. It provides the payment scheme initiated inquiry requests. This function returns the payment scheme
specific content of the Inquiry Response Block. specific content of the Inquiry Response Block.
"Continue Process" and Change Process State" (cf. Payment Transaction "Continue Process" and "Change Process State" (cf. Payment Processing
Related API Calls) Related API Calls)
o Other API Calls o Other API Functions
"Manage Payment Software" enables the immediate activation of the "Manage Payment Software" enables the immediate activation of the
Existing Payment Software. Further user input is under control of the Existing Payment Software. Further user input is under control of the
Existing Payment Software. Existing Payment Software.
"Access Data Base" provide a general data base interface to the IOTP "Call Back" provides a general interface for the visualization of
Payment Bridge. They can rely on the IOTP Application Core transaction progress by 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 (#), The following table shows which API functions must (+), should (#),
or might (?) be implemented by which Trading Roles. or might (?) be implemented by which Trading Roles.
API function Consumer Payment Handler Merchant API function Consumer Payment Handler Merchant
Find Accepted Payment Brand + Find Accepted Payment Brand +
Find Accepted Payment Protocol + Find Accepted Payment Protocol #
Find Payment Instrument + Find Payment Instrument +
Find Payment Protocol +
Get Payment Initialization Data + Get Payment Initialization Data +
Cancel Payment #
Check Payment Possibility + Check Payment Possibility +
Quit Payment Instrument #
Start Payment Consumer + Start Payment Consumer +
Start Payment Payment Handler + Start Payment Payment Handler +
Resume Payment Consumer #
Resume Payment Payment Handler #
Continue Process + + Continue Process + +
Inquire Process State + + Inquire Process State + + ?
Change Process State + + ? Change Process State + + ?
Check Payment Receipt + ? Check Payment Receipt + ?
Inquire Authentication Challenge #
Remove Payment Log # # #
Authenticate +
Check Authentication Response #
Resume Payment Consumer +
Resume Payment Payment Handler +
Expand Payment Receipt # ? Expand Payment Receipt # ?
Inquire Payment Log # #
Remove Payment Log ? ? ?
Inquire Authentication Challenge ?
Authenticate +
Check Authentication Response ?
Payment Instrument Inquiry ? Payment Instrument Inquiry ?
Inquire Pending Payment # # Inquire Pending Payment # #
Start Payment Inquiry ? Start Payment Inquiry ?
Inquire Payment Status ? 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 Manage Payment Software # ? ?
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 Call Back #
Table 1: Requirements on API Functions by the Trading Roles
The next sections sketch the relationships and the dependencies
between the API functions. They provide the informal description of
the progress alternatives and depict the communication and
synchronization between the general IOTP Application Core and the
payment scheme specific modules.
2.1 Authentication Documentation Exchange
This section describes how the functions in this document are used This section describes how the functions in this document are used
together to process authentication. together to process authentication.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Authenticator Inquire Authentication Challenge(Alg1*) -> IPB Authenticator Inquire Authentication Challenge(Alg1*) -> IPB
Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB
. . . . . .
Inquire Authentication Challenge(Algn*) -> IPB Inquire Authentication Challenge(Algn*) -> IPB
Inq. Auth. Challenge Response(Algn,Chn) <- IPB Inq. Auth. Challenge Response(Algn,Chn) <- IPB
skipping to change at page 54, line 29 skipping to change at page 17, line 7
. . . . . .
Authenticate(Algm, Chm) -> IPB Authenticate(Algm, Chm) -> IPB
AuthenticateResponse(Res) <- IPB AuthenticateResponse(Res) <- IPB
Create and transmit Authentication Response Block Create and transmit Authentication Response Block
Authenticator Check Authentication Response(Algm,Chm,Res)->IPB Authenticator Check Authentication Response(Algm,Chm,Res)->IPB
Check Auth. Resp. Response() <-IPB Check Auth. Resp. Response() <-IPB
Create and transmit Authentication Status Block Create and transmit Authentication Status Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 12 Authentication Message Flows Figure 12 Authentication Message Flows
1. (Authenticator Process) The IOTP Payment Bridge (IPB) is asked 1. (Authenticator Process) None, one or multiple IOTP Payment Bridges
for one or multiple authentication challenge values ("Inquire (IPB) are requested for one or multiple authentication challenge
Authentication Challenge"). Each value is encapsulated in an values ("Inquire Authentication Challenge"). Each value is
Authentication Request Component which forms the final Authentication encapsulated in an IOTP Authentication Request Component. In
Request Block. If the authenticator intends to submit a choice of addition, the IOTP Application Core may add payment scheme
authentication algorithms to the authenticatee, it has to issue independent authentication methods. All of them form the final IOTP
several API call to the IOTP Payment Bridge. Authentication Request Block, which describes the set of
authentication methods being supported by the authenticator and from
which the authenticatee has to choose one method.
Note that the interface is limited to the response of one algorithm Note that the interface of the API function is limited to the
per call. If the IOTP Application Core provides a choice algorithm, response of exactly one algorithm per call. If the IOTP Application
this choice should be reduced successively by the returned algorithm. Core provides a choice of algorithms for input, this choice should be
The IOTP Payment Bridge notifies the IOTP Application Core with each reduced successively by the returned algorithm ({Alg(i+1)*} is subset
newly registered Payment Instrument about the supported of {Algi*}).
authentication algorithms by their names.
2. The Authenticatee's IOTP Application Core checks whether the IOTP During the registration of new Payment Instruments, the IOTP Payment
transaction type actually supports the authentication process. If Bridge notifies the IOTP Application Core about the supported
Authentication Request Components have been provided, they are authentication algorithms.
checked in some order. The IOTP Application Core analyzes the
algorithms' names, the transaction context, and optionally user 2. On presence of an IOTP Authentication Block within the received
preferences in order to determine the system components which are IOTP message, the Authenticatee's IOTP Application Core checks
capable to process the authentication request items. Such system whether the IOTP transaction type in the current phase actually
components might be the IOTP Application itself or some of the supports the authentication process.
registered IOTP Payment Bridges. These system components might be
requested for the responses to the supplied challenges, sequentially. For each provided Authentication Request Component, the IOTP
The search stops with the first successful response. Application Core analyzes the algorithms' names, the transaction
context, and optionally user preferences in order to determine the
system components which are capable to process the authentication
request items. Such system components might be the IOTP Application
Core itself or any of the registered IOTP Payment Bridges.
Subsequently, the IOTP Application Core requests the responses to
the supplied challenges from the determined system components in any
order. The authentication trials stop with the first successful
response, which is included in the IOTP Authentication Response
Block.
Alternatively, the IOTP Application might ask for a user selection. Alternatively, the IOTP Application might ask for a user selection.
This might be appropriate, if two or more authentication algorithms This might be appropriate, if two or more authentication algorithms
are received that require explicit user interaction, like PIN or chip are received that require explicit user interaction, like PIN or chip
card insertion. card insertion.
The Authenticatee's organizational data is requested by The Authenticatee's organizational data is requested by an IOTP
Authentication Request Blocks without any content element. On Authentication Request Block without any content element. On failure,
failure, the authentication request may be retried, or the whole the authentication (sequence) might be retried, or the whole
transaction might be suspended or cancelled. transaction might be suspended or cancelled.
3. (Authenticator Process) The IOTP Application Core checks the 3. (Authenticator Process) The IOTP Application Core checks the
presence of the Authentication Response Component in the presence of the IOTP Authentication Response Component in the
Authentication Response Block and forwards its content to the Authentication Response Block and forwards its content to the
"selected" IOTP Payment Bridge for verification ("Check generator of the associated authentication challenge for verification
Authentication Response"). Otherwise, the presence of the ("Check Authentication Response").
Authenticatee's organisational data is checked. Any verification must
succeed in order to continue the transaction.
8.2 Brand Compilation On sole organizational data request, its presence is checked.
An example of how the functions in this document are used together so Any verification must succeed in order to proceed with the
that the Merchant can compile the Brand List Component, generate the transaction.
Payment Component, and adjust the Order Component with payment scheme
specific packaged content. 2.2 Brand Compilation
The following shows how the API functions are used together so that
the Merchant can (1) compile the Brand List Component, (2) generate
the Payment Component, and (3) adjust the Order Component with
payment scheme specific packaged content.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant For each registered IOTP Payment Bridge Merchant For each registered IOTP Payment Bridge
| Find Accepted Payment Brand() -> IPB | Find Accepted Payment Brand() -> IPB
| Find Accepted Payment Brand Response (B*) <- IPB | Find Accepted Payment Brand Response (B*) <- IPB
| Find Accepted Payment Protocol(B1) -> IPB | Find Accepted Payment Protocol(B1) -> IPB
| Find Accepted Payment Protocol Res.(P1*) <- IPB | Find Accepted Payment Protocol Res.(P1*) <- IPB
| . . . | . . .
| Find Accepted Payment Protocol(Bn) -> IPB | Find Accepted Payment Protocol(Bn) -> IPB
| Find Accepted Payment Protocol Res.(Pn*) <- IPB | Find Accepted Payment Protocol Res.(Pn*) <- IPB
Create one Brand List Component, ideally sharing Create one Brand List Component, ideally sharing
common Brand, Protocol Amount, Currency Amount, common Brand, Protocol Amount, Currency Amount,
and Pay Protocol Elements and Pay Protocol Elements
Create Trading Protocol Options Block Create Trading Protocol Options Block
On brand independent transactions On brand independent transactions
| Create Brand Selection Component, implicitly | Create Brand Selection Component, implicitly
| Get Payment Initialization Data() -> IPB | Get Payment Initialization Data(B1,P1) -> IPB
| Get Payment Initialization Data Res.() <- IPB | Get Payment Initialization Data Res.() <- IPB
| Optionally | Optionally
| | Inquire Process State() -> IPB | | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB | | Inquire Process State Response(State) <- IPB
| Create Offer Response Block | Create Offer Response Block
Transmit newly created Block(s) Transmit newly created Block(s)
Consumer Consumer selects Brand/Currency from those Consumer Consumer selects Brand (Bi)/Currency/Protocol (Pj)
that will work and generates Brand Selection from those that will work and generates Brand
Component - at least implicitly Selection Component - at least logically
On brand dependent transaction On brand dependent transaction
| Transmit Brand Selection Component | Transmit Brand Selection Component
Merchant On brand dependent transaction Merchant On brand dependent transaction
| Get Payment Initialization Data() -> IPB | Get Payment Initialization Data(Bi,Pj) -> IPB
| Get Payment Initialization Data Res.() <- IPB | Get Payment Initialization Data Res.() <- IPB
| Optionally | Optionally
| | Inquire Process State() -> IPB | | Inquire Process State() -> IPB
| | Inquire Process State Response(State) <- IPB | | Inquire Process State Response(State) <- IPB
| Create Offer Response Block | Create Offer Response Block
| Transmit newly created Block | Transmit newly created Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 13 Brand Compilation Message Flows Figure 3 Brand Compilation Message Flows
1. The Merchant's commerce server controls the shopping dialog with 1. The Merchant's commerce server controls the shopping dialog with
its own mechanisms until the Consumer checks out the shopping cart its own mechanisms until the Consumer checks out the shopping cart
and indicates the payment intention. The notion shopping subsumes any and indicates the payment intention. The notion shopping subsumes any
non-IOTP based visit of the Merchant Trading Role's (which subsumes non-IOTP based visit of the Merchant Trading Role's (which subsumes
Financial Institutes) web site in order to negotiate the content of Financial Institutes) web site in order to negotiate the content of
the IOTP Order Component. The subsequent processing switches to the the IOTP Order Component. The subsequent processing switches to the
IOTP based form by the activation of the Merchant's IOTP aware IOTP based form by the activation of the Merchant's IOTP aware
application. application.
skipping to change at page 57, line 10 skipping to change at page 19, line 53
4. The IOTP Application Core interrogates the IOTP Payment Bridges 4. The IOTP Application Core interrogates the IOTP Payment Bridges
for each accepted payment brand about the supported payment protocols for each accepted payment brand about the supported payment protocols
("Find Accepted Payment Protocol"). These responses provide the ("Find Accepted Payment Protocol"). These responses provide the
remaining attribute values of the Brand Elements as well as all remaining attribute values of the Brand Elements as well as all
attribute values for the compilation of the Brand List Component's attribute values for the compilation of the Brand List Component's
Protocol Amount and Pay Protocol Elements. Furthermore, the Protocol Amount and Pay Protocol Elements. Furthermore, the
organisational data about the Payment Handler is returned. The IOTP organisational data about the Payment Handler is returned. The IOTP
Application Core might optionally match the returned payment brands Application Core might optionally match the returned payment brands
with Merchant's general preferences. with Merchant's general preferences.
Note that this complex process might be optimized by any pre- Alternatively, the IOTP Application Core might skip the calls of
compilation of Brand Lists. At startup the IOTP Application Core "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
might Accepted Payment Protocol" call without any Brand given on the input
parameter list. In this case, the IOTP Payment Bridge responds on the
o perform multiple dummy inquiries on the registered IOTP latter call with the whole set of payment schemes supported w.r.t.
Payment Bridges, the other input parameters.
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 5. The steps 3 and 4 are repeated during IOTP Value Exchange
transactions - these steps are omitted in the previous figure. transactions - these steps are omitted in the previous figure.
6. The IOTP Application Core compiles the Brand List Component(s) 6. The IOTP Application Core compiles the Brand List Component(s) and
and the IOTP Trading Protocol Options Block. It is recommended that the IOTP Trading Protocol Options Block. It is recommended that
"equal" items returned by IOTP Payment Bridge function calls are "equal" items returned by IOTP Payment Bridge function calls are
shared due to the extensive linking capabilities within the Brand shared due to the extensive linking capabilities within the Brand
List Component. However, the compilation must consider several List Component. However, the compilation must consider several
aspects in order to prevent conflicts - sharing detection might be aspects in order to prevent conflicts - sharing detection might be
textual matching: textual matching (after normalization):
o Packaged Content Elements contained in the Brand List Component o Packaged Content Elements contained in the Brand List Component
(and subsequently generated Payment and Order Components) might be (and subsequently generated Payment and Order Components) might be
payment scheme specific and might depend on each other. payment scheme specific and might depend on each other.
o Transaction/Brand/Protocol/Currency Amount (in)dependent data o Currently, IOTP lacks precise rules for the content of the
might share the same Packaged Content. Packaged Content Element. Therefore, transaction / brand /
protocol / currency amount (in)dependent data might share the same
Packaged Content Element or might spread across multiple Packaged
Content Elements.
o The Consumer's IOTP Application Core transparently passes the o The Consumer's IOTP Application Core transparently passes the
packaged contents to the IOTP Payment Bridges which might not be Packaged Content Elements to the IOTP Payment Bridges which might
able to handle payment scheme data of other payment schemes not be able to handle payment scheme data of other payment
accurately. schemes, accurately.
The details about the rules and mechanisms, how this could be The rules and mechanisms of how this could be accomplished are out
accomplished is out of the scope of this document. With other words, of the scope of this document. Furthermore, this document does not
this document does not define further restrictions to the IOTP define any further restriction to the IOTP specification.
specification.
7. The IOTP Application Core determines whether the IOTP message can 7. The IOTP Application Core determines whether the IOTP message can
be enriched with an Offer Response Block. This is valid under the be enriched with an Offer Response Block. This is valid under the
following conditions: following conditions:
o All payment alternatives share the attribute values and o All payment alternatives share the attribute values and Packaged
contents of the subsequently generated Payment and Order Content Elements of the subsequently generated IOTP Payment and
Component. Order Components.
o The subsequently generated data does not depend on any o The subsequently generated data does not depend on any IOTP
BrandSelXInfo Elements that might be reported by the consumer BrandSelInfo Elements that might be reported by the consumer
within the TPO Selection Block in the brand dependent variant. within the TPO Selection Block in the brand dependent variant.
If both conditions are fulfilled, the IOTP Application Core might If both conditions are fulfilled, the IOTP Application Core might
request the remaining payment scheme specific payment initialization request the remaining payment scheme specific payment initialization
data from the IOTP Payment Bridge ("Get Payment Initialization Data") data from the IOTP Payment Bridge ("Get Payment Initialization Data")
and compile the Offer Response Block. Optionally, the IOTP and compile the IOTP Offer Response Block.
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 Optionally, the IOTP Application Core might request the current
could be accomplished is out of the scope of this document. process state from the IOTP Payment Bridge and add the inferred order
status to the IOTP Offer Response Block. Alternatively, IOTP
Application might determine the order status on its own.
8. The IOTP Application Core compiles the IOTP TPO message adding As in step 6, the rules and mechanisms of how this could be
all compiled blocks and transmits the message to the Consumer. The accomplished are out of the scope of this document.
IOTP Application Core terminates if an Offer Response Block has been
created.
9. The Consumer performs the Brand Selection Steps (see below) and 8. The IOTP Application Core compiles the IOTP TPO Message including
responds with a TPO Selection Block if no Offer Response Block has all compiled IOTP Blocks and transmits the message to the Consumer.
been received. Otherwise, the following step is skipped. The IOTP Application Core terminates if an IOTP Offer Response Block
has been created.
9. The Consumer performs the Brand Selection Steps (cf. Section 2.3)
and responds with a TPO Selection Block if no IOTP Offer Response
Block has been received. Otherwise, the following step is skipped.
10. On brand dependent transactions, the IOTP Application Core 10. On brand dependent transactions, the IOTP Application Core
requests the remaining payment scheme specific payment initialization requests the remaining payment scheme specific payment initialization
data from the IOTP Payment Bridge ("Get Payment Initialization data from the IOTP Payment Bridge ("Get Payment Initialization
Data"), compiles the Offer Response Block, transmits it to the Data"), compiles the IOTP Offer Response Block, transmits it to the
Consumer, and terminates. Like Step 7, the IOTP Application Core Consumer, and terminates. Like Step 7, the IOTP Application Core
might access the current process state of the IOTP Payment Bridge for might access the current process state of the IOTP Payment Bridge for
the compilation of the order status. the compilation of the order status.
Any error during this process raises an IOTP Error Block. Any error during this process raises an IOTP Error Block.
8.3 Brand Selection 2.3 Brand Selection
This section describes the steps that happen mainly after the This section describes the steps that happen mainly after the
Merchant's Brand Compilation (in a brand independent transaction). Merchant's Brand Compilation (in a brand independent transaction).
However, these steps might partially interlace the previous process However, these steps might partially interlace the previous process
(in a brand dependent transaction). An example of how the functions (in a brand dependent transaction).
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 Merchant Merchant generates Brand List(s) containing
Brands, Payment Protocols and Currency Amounts Brands, Payment Protocols and Currency Amounts
On brand independent transactions On brand independent transactions
| Merchant generates Offer Response Block | Merchant generates Offer Response Block
Consumer For each accepted Payment Brand Consumer Compile set(s) of Brands B/Protocols P
| Find Payment Instrument(B,C) -> IPB for each set
| Find Payment Instrument(B, P, C) -> IPB
| Find Payment Instrument Response (PI*) <- 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 Consumer selects Brand/Currency/Payment Instrument
from those that will work and generates Brand from those that will work and generates Brand
Selection Component Selection Component
For the Selection For the Selection
| Get Payment Initialization Data(B,C,PI,P) -> IPB | Get Payment Initialization Data(B,C,PI,P) -> IPB
| Get Payment Initialization Data Response()<- IPB | Get Payment Initialization Data Response()<- IPB
On brand dependent transaction On brand dependent transaction
| Generate and transmit TPO Selection Block | Generate and transmit TPO Selection Block
Merchant On brand dependent transaction Merchant On brand dependent transaction
| Merchant checks Brand Selection and generates | Merchant checks Brand Selection and generates
| and transmits Offer Response Block | and transmits Offer Response Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 14 Brand Selection Message Flows Figure 4 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 1. The Merchant's commerce server controls the shopping dialog with
its own mechanisms until the Consumer checks out the shopping cart its own mechanisms until the Consumer checks out the shopping cart
and indicates the payment intention. The subsequent processing and indicates his payment intention. The subsequent processing
switches to the IOTP based form by the activation of the Merchant's switches to the IOTP based form by the activation of the Merchant's
IOTP aware application. IOTP aware application.
2. The IOTP Application Core compiles the Trading Protocol Options 2. The IOTP Application Core compiles the IOTP Trading Protocol
Block which contains the Brand List Component(s) enumerating Options Block which contains the IOTP Brand List Component(s)
Merchant's accepted payment brands and payment protocols and enumerating Merchant's accepted payment brands and payment protocols
initiates the Brand Selection process. and initiates the Brand Selection process.
3. This first IOTP message activates the Consumer's IOTP aware 3. This first IOTP message activates the Consumer's IOTP aware
application, e.g., the Web browser invokes a helper application application, e.g., the Web browser invokes a helper application
(e.g., Java applet or external application). The Consumer's IOTP (e.g., Java applet or external application). Its IOTP Application
Application Core Core
o infers the accepted payment brands, payment protocols, payment o infers the accepted payment brands, payment protocols, payment
direction, currencies, payment amounts, any descriptions etc., and direction, currencies, payment amounts, any descriptions etc., and
their relationships from the IOTP message, their relationships from the IOTP message,
o determines the registered IOTP Payment Bridges, o determines the registered IOTP Payment Bridges,
o inquires general payment brand support and the known payment
o compiles one or multiple set of brand and protocol such that the
join of all set describes exactly the set of payment alternatives
being offered by the Merchant.
o inquires payment (protocol) support and the known payment
instruments from each registered IOTP Payment Bridge for each instruments from each registered IOTP Payment Bridge for each
accepted payment brand and currency ("Find Payment Instrument"). compiled set ("Find Payment Instrument"). However, some IOTP Payment
However, some IOTP Payment Bridges may refuse payment instrument Bridges may refuse payment instrument distinction.
distinction.
o inquires payment protocol support from each registered IOTP The payment protocol support may differ between payment instruments
Payment Bridge that has acknowledged any of the accepted payment if the IOTP Payment Bridge supports payment instrument distinction.
brands ("Find Payment Protocol"). The payment protocol support may
differ between payment instruments if the IOTP Payment Bridge These API calls are used to infer the payment alternatives at the
supports payment instrument distinction. startup of any payment transaction (without user unfriendly explicit
user interaction).
The IOTP Application Core must provide wallet identifiers, if they The IOTP Application Core must provide wallet identifiers, if they
are required by the IOTP Payment Bridges which signal their need by are requested by the IOTP Payment Bridges which signal their need by
specific error codes (see below). These API calls are used to infer specific error codes (see below).
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 It is recommended that the IOTP Application Core manages wallet
identifiers. But for security reasons, it should manage pass phrases identifiers. But for security reasons, it should store pass phrases
in plain text only in runtime memory. Developers of IOTP Payment in plain text only in runtime memory. Developers of IOTP Payment
Bridges and payment software modules should provide a thin and fast Bridges and payment software modules should provide a thin and fast
implementation - without lengthy initialization processes- for this implementation - without lengthy initialization processes- for this
initial inquiry step. initial inquiry step.
4. The IOTP Application Core 4. The IOTP Application Core
o intersects the Consumer's payment capabilities with the verifies the Consumer's payment capabilities with the Merchant's
Merchant's accepted payment brands and currencies, accepted payment brands and currencies,
o displays the valid payment instruments and payment instrument o displays the valid payment instruments and payment instrument
independent payment brands (brand and protocol) together with independent payment brands (brand and protocol) together with their
their purchase parameters (payment direction, currency, amount), purchase parameters (payment direction, currency, amount), and
and
o requests the Consumer's choice or derives it automatically from
the configured preferences.
The management / resolution of unavailable IOTP Payment Bridges o requests the Consumer's choice or derives it automatically from any
during the previous inquiry process is up to the IOTP Application configured preferences. Any selection ties one IOTP Payment Bridge
Core. It may skip these IOTP Payment Bridges or may allow user with the following payment transaction.
supported resolution. It may also offer the registration of new
payment instruments.
5. The Consumer's payment instrument / brand selection ties one IOTP The handling and resolution of unavailable IOTP Payment Bridges
Payment Bridge with the subsequent payment transaction. The IOTP during the inquiry in Step 3 is up to the IOTP Application Core. It
Application Core interrogates this IOTP Payment Bridge, whether the may skip these IOTP Payment Bridges or may allow user supported
payment can proceed with success ("Check Payment Possibility"). At resolution.
this step, the IOTP Payment Bridge may issue several signals, e.g.,
Furthermore, it may offer the registration of new payment
instruments when the Consumer is requested for payment instrument
selection.
5. The IOTP Application Core interrogates the fixed IOTP Payment
Bridge whether the payment might complete with success ("Check
Payment Possibility"). At this step, the IOTP Payment Bridge may
issue several signals, e.g.,
o payment can proceed immediately, o payment can proceed immediately,
o required peripheral inclusive some required physical payment o required peripheral inclusive some required physical payment
instrument (chip card) is unavailable, instrument (chip card) is unavailable,
o remote party is not available, o (non-IOTP) remote party (e.g. issuer, server wallet) is not
available,
o wallet identifier or pass phrase is required, o wallet identifier or pass phrase is required,
o expired payment instrument (or certificate), insufficient o expired payment instrument (or certificate), insufficient funds,
funds, and or
o physical payment instrument unreadable. o physical payment instrument unreadable.
In any case except the first one, the user should be notified and In any erroneous case, the user should be notified and offered
offered accurate alternatives. Most probably, the user might be accurate alternatives. Most probably, the user might be recommended
requested o to resolve the problem, e.g. to insert another payment
instrument or to verify the periphery,
o to resolve the problem, e.g. insertion of another payment o to proceed (assuming its success),
instrument, verification of periphery,
o to skip this check and to proceed (assuming its success),
o to cancel the whole transaction, or o to cancel the whole transaction, or
o to suspend the transaction, e.g., initiating a nested o to suspend the transaction, e.g., initiating a nested
transaction. transaction for uploading an electronic purse.
If the payment software implements payment instrument selection on If the payment software implements payment instrument selection on
its own, it may request the Consumer's choice at this step. its own, it may request the Consumer's choice at this step.
If the check succeeds, it returns several Brand Selection Info If the check succeeds, it returns several IOTP Brand Selection Info
Elements. Elements.
6. The steps 2 to 5 are repeated and possibly interlaced for the 6. The Steps 2 to 5 are repeated and possibly interlaced for the
selection of the second payment instrument during IOTP Value Exchange selection of the second payment instrument during IOTP Value Exchange
transactions - this is neglected in the figure above. transactions - this is omitted in the figure above.
7. The IOTP Brand Selection Component is generated and enriched with 7. The IOTP Brand Selection Component is generated and enriched with
the Brand Selection Info elements. This component is transmitted to the Brand Selection Info elements. This component is transmitted to
the Merchant inside a TPO Selection Block if the received IOTP the Merchant inside a TPO Selection Block if the received IOTP
message lacks the Offer Response Block. The Merchant will then message lacks the IOTP Offer Response Block. The Merchant will then
respond with an Offer Response Block (following the aforementioned respond with an IOTP Offer Response Block (following the
compilation rules). aforementioned compilation rules).
8.4 Successful Payment 2.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 5.
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 Technically, two payments happen during IOTP Value Exchange
transactions. transactions.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB
Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB
Create and transmit Payment Request Block Create and transmit Payment Request Block
Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB
Start Payment PH Response(PS2, CS=Cont.) <- IPB Start Payment PH Response(PS2, CS=Cont.) <- IPB
Create and transmit Payment Exchange Block Create and transmit Payment Exchange Block
skipping to change at page 62, line 15 skipping to change at page 24, line 45
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB
Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB
Create and transmit Payment Request Block Create and transmit Payment Request Block
Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB
Start Payment PH Response(PS2, CS=Cont.) <- IPB Start Payment PH Response(PS2, CS=Cont.) <- IPB
Create and transmit Payment Exchange Block Create and transmit Payment Exchange Block
Consumer Continue Process(PS2) -> IPB Consumer Continue Process(PS2) -> IPB
Continue Process Response(PS3, CS=Cont.) <- IPB Continue Process Response(PS3, CS=Cont.) <- IPB
... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ... ... CONTINUE SWAPPING PAYMENT EXCHANGES UNTIL ...
Payment Handler Continue Process Response([PSn], CS=End) <- IPB Payment Handler Continue Process Response([PSn], CS=End) <- IPB
Inquire Process State() -> IPB Request any local payment receipt
Inquire Proc. State Resp.(State, Receipt) <- IPB | Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Create and transmit Payment Response Block Create and transmit Payment Response Block
Terminate transaction, actively Terminate transaction, actively
| Change Process State(State) -> IPB | Change Process State(State) -> IPB
| Change PS Response(State=CompletedOK) <- IPB | Change PS Response(State=CompletedOK) <- IPB
Consumer On receipt of final payment scheme data Consumer On receipt of final payment scheme data
| Continue Process(PSn) -> IPB | Continue Process(PSn) -> IPB
| Continue Process Response(CS=End) <- IPB | Continue Process Response(CS=End) <- IPB
Check Payment Receipt(Receipt) -> IPB Check Payment Receipt(Receipt) -> IPB
Check Payment Receipt Response() <- IPB Check Payment Receipt Response() <- IPB
Change Process State(State) -> IPB Request any local payment receipt
Change PS Response(State=CompletedOk) <- IPB | Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB
Terminate transaction, actively
| Change Process State(State) -> IPB
| Change PS Response(State=CompletedOk) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 15 Example Payment Message Flows Figure 5 Example Payment Message Flows
1. After Brand Selection and receipt of the IOTP Offer Response 1. After Brand Selection and receipt of the IOTP Offer Response
Block, the Consumer has to agree to the payment transaction's Block, the Consumer switches from communicating with the Merchant to
continuation. The agreement may be explicit per transaction or may communicating with the Payment Handler.
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 This might be a milestone requiring the renewed Consumer's agreement
continues with minimal user (Consumer and Payment Handler) about the payment transaction's continuation. Particularly, this is a
interaction and that it is controlled by the IOTP Application Core good moment for payment suspension (and even cancellation), which
and IOTP Payment Bridge. will be most probably supported by all payment schemes. Simply,
because the genuine payment legacy systems have not been involved in
the 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 transaction proceeds with minimal user
(Consumer and Payment Handler) interaction and that its progess is
controlled by the IOTP Application Core and IOTP Payment Bridge.
2. In order to open the actual payment transaction, the IOTP 2. In order to open the actual payment transaction, the IOTP
Application Core issues the "Start Payment Consumer" request towards Application Core issues the "Start Payment Consumer" request towards
the IOTP Payment Bridge. This request carries the whole the IOTP Payment Bridge. This request carries the whole
initialization data of the payment transaction being referred to by initialization data of the payment transaction being referred to by
the IOTP Payment Bridge for subsequent consistency the IOTP Payment Bridge for subsequent consistency checks:
checks:
o payment brand and its description from the selected Brand o payment brand and its description from the selected Brand
Element of the Brand List Component, Element of the IOTP Brand List Component,
o payment instrument from preceding inquiry step, o payment instrument from preceding inquiry step,
o further payment parameters (currency, amount, direction, o further payment parameters (currency, amount, direction,
expiration) from the selected Currency Amount element, Brand List expiration) from the selected Currency Amount element, Brand List
Component, and Payment Component of the IOTP Offer Response Block, Component, and Payment Component of the IOTP Offer Response Block,
o payment protocol from the selected Pay Protocol Element, o payment protocol from the selected IOTP Pay Protocol Element,
o order details contained in the Order Component which might be o order details contained in the IOTP Order Component which might
payment scheme specific, be payment scheme specific,
o payment scheme specific data inclusive payment protocol o payment scheme specific data inclusive payment protocol
descriptions from the Protocol Amount Element, and Pay Protocol descriptions from the IOTP Protocol Amount Element, and IOTP Pay
Element, and Protocol Element, and
o payment scheme specific data inclusive payment protocol o payment scheme specific data inclusive payment protocol
descriptions, in which the name attribute includes the prefix as descriptions, in which the name attribute includes the prefix as
"Payment:" from the Trading Role Data Component. "Payment:" from the Trading Role Data Component.
Generally, this request repeats most checks of the "Check Payment Generally, the called API function redoes most checks of the "Check
Possibility" request due to lack of dependencies between both Payment Possibility" call due to lack of strong dependencies between
requests, e.g. availability check of periphery, pass phrase both requests: There might be a significant delay between both API
supplement. There might be a significant delay between both API requests.
requests. The function may return further payment scheme specific
The called API function may return further payment scheme specific
data being considered as payment specific initialization data for the data being considered as payment specific initialization data for the
Payment Handler's IOTP Payment Bridge. If the payment software Payment Handler's IOTP Payment Bridge.
implements payment instrument selection on its own, it may request
the Consumer's choice at this step. If the fixed Existing Payment Software implements payment instrument
selection on its own, it may request the Consumer's choice at this
step.
The IOTP Payment Bridge reports lack of capability quite similar to The IOTP Payment Bridge reports lack of capability quite similar to
the "Check Payment Possibility" request to the IOTP Application Core. the "Check Payment Possibility" request to the IOTP Application Core.
The Consumer may decide to resolve the problem, to suspend, or to The Consumer may decide to resolve the problem, to suspend, or to
cancel the transaction, but he must not skip this API request. The cancel the transaction, but this function call must succeed in order
IOTP Application Core might reissue the API request on user to proceed with the transaction.
indication.
Developers of payment modules may decide to omit payment instrument Developers of payment modules may decide to omit payment instrument
related checks like expiration date or refunds sufficiency, if they related checks like expiration date or refunds sufficiency, if they
are part of the specific payment protocol. are part of the specific payment protocol.
If the IOTP Payment Bridge requests wallet identifiers or pass If the IOTP Payment Bridge requests wallet identifiers or pass
phrases anywhere during the payment process, they should be requested phrases anywhere during the payment process, they should be requested
by this API call, too. The IOTP Application Core should store these by this API function, too. It is recommended that the IOTP
values. The IOTP Payment Bridge may also store these values and Application Core stores plain text pass phrases only in runtime
dispense with their supplement on subsequent payment related API memory.
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, Finally, the IOTP Application Core generates the IOTP Payment
inserts any returned payment scheme data, and submits it to the Request Block, inserts any returned payment scheme data, and submits
Payment Handler's system. it to the Payment Handler's system.
3. The Payment Handler's IOTP Application Core opens the payment 3. The Payment Handler's IOTP Application Core opens the payment
transaction using the "Start Payment Payment Handler" API call. The transaction calling the "Start Payment Payment Handler" API function.
payment brand, its description, payment protocol, payment specific The payment brand, its description, payment protocol, payment
data, payment direction, currency and payment amount are determined specific data, payment direction, currency and payment amount are
quite similar to the Consumer's IOTP Application Core. Furthermore, determined quite similar to the Consumer's IOTP Application Core.
the content of the Payment Scheme Data component and the Brand Furthermore, the content of the IOTP Payment Scheme Component and the
Selection Info Elements are passed to the API function. IOTP Brand Selection Info Elements are passed to this function.
On success, the Payment Handler's IOTP Payment Bridge responds with On success, the Payment Handler's IOTP Payment Bridge responds with
payment scheme data. On failures, it has to resolve any problems on payment scheme specific data. On failures, this non- interactive
its own or to give up aborting the payment transaction because the server application has to resolve any problems on its own or to give
Payment Handler operates a non- interactive server application. up aborting the payment transaction. However, the Consumer may
However, the Consumer may restart the whole payment transaction. But restart the whole payment transaction. Anyway, the payment log file
the payment log file should reflect any trials of a payments. should reflect any trials of payments.
In any case, the Payment Handler informs the Consumer about the Eventually, the Payment Handler informs the Consumer about the
current Process State using the IOTP Payment Response or IOTP Error current IOTP Process State using the IOTP Payment Response or IOTP
Block. Error Block.
The "Start Payment Payment Handler" call might return the Note that the "Start Payment Payment Handler" call might return the
Continuation Status "End" which leads to the continuation with Step Continuation Status "End" such that payment processing proceeds with
7. Step 7.
4. The IOTP Application Core verifies the presence of the Payment 4. The IOTP Application Core verifies the presence of the Payment
Exchange Block in the IOTP message and passes the contained payment Exchange Block in the IOTP message and passes the contained payment
scheme specific data to the active IOTP Payment Bridge ("Continue scheme specific data to the fixed IOTP Payment Bridge ("Continue
Process") which returns the next Payment Scheme Component. Process") which returns the next IOTP Payment Scheme Component.
The Payment Scheme Component is encapsulated in a Payment Exchange This Payment Scheme Component is encapsulated in an IOTP Payment
Block and transmitted to the Payment Handler. Exchange Block and transmitted to the Payment Handler.
5. The Payment Handler's IOTP Application Core verifies the presence 5. The Payment Handler's IOTP Application Core verifies the presence
of the Payment Exchange Block and passes the contained payment scheme of the Payment Exchange Block and passes the contained payment scheme
specific data to the active IOTP Payment Bridge ("Continue Process") specific data to the fixed IOTP Payment Bridge ("Continue Process")
which returns the next Payment Scheme Component for encapsulation and which returns the next IOTP Payment Scheme Component for
transmission to the Consumer. encapsulation and transmission to the Consumer.
6. The payment process continues with IOTP Payment Exchange Block 6. The payment process continues with IOTP Payment Exchange Block
exchanges, carrying the specific payment scheme data. Each party exchanges, carrying the payment scheme specific data. Each party (1)
submits the embedded payment scheme data transparently to the active submits the embedded payment scheme specific data transparently to
IOTP Payment Bridge by the Continue Process API call, wraps the the appropriate IOTP Payment Bridge calling the "Continue Process"
returned payment scheme data into an IOTP Payment Exchange Block, and API function, (2) wraps the returned payment scheme specific data
transmits it to the counterparty. into an IOTP Payment Exchange Block, and (3) transmits this block to
the counter party.
However, the processing of the payment scheme data may fail for However, the processing of the payment scheme specific data may fail
several reasons signaled by specific error codes which are for several reasons signaled by specific error codes which are
transformed to IOTP Payment Response Blocks (generated by Payment transformed to IOTP Payment Response Blocks (generated by Payment
Handler) or IOTP Error Blocks (both parties may generate them) and Handler) or IOTP Error Blocks (both parties may generate them) and
transmitted to the counterparty. transmitted to the counterparty.
7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes 7. Eventually, the Payment Handler's IOTP Payment Bridge recognizes
the termination of the payment transaction and reports this by the the termination of the payment transaction and reports this by the
continuation status "End". Then the IOTP Application Core issues the continuation status "End" on the output parameter of "Continue
"Inquire Process State" API call and verifies whether an IOTP Payment Process" (or "Start Payment Payment Handler"). Then, the IOTP
Receipt Component has been returned. The IOTP Application Core wraps Application Core issues the "Inquire Process State" API call and
the payment receipt, the status response, and the optional payment verifies whether an IOTP Payment Receipt Component has been returned.
scheme data in an IOTP Payment Response Block and transmits this The IOTP Application Core wraps the payment receipt, the status
block to the Consumer. response, and the optional payment scheme specific 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 However, any of these API calls may fail or any response might be
incomplete (lack of payment receipt). Then the Consumer has to be incomplete (e.g., lack of payment receipt). Then, the Consumer has to
notified about the failed processing by an IOTP Error Block. be notified about the failed processing by an IOTP Error Block.
Finally, the Payment Handler terminates the payment transaction Finally, the Payment Handler terminates the payment transaction with
with the "Change Process State" API call without awaiting any the "Change Process State" API call without awaiting any further
response from the Consumer. Further failures are not reported to the response from the Consumer. Further failures are not reported to the
Consumer. Consumer.
It might be possible that the Consumer's IOTP Payment Bridge has Note that it might be possible that the Consumer's IOTP Payment
returned the previous payment scheme data with the continuation Bridge has returned the previous payment scheme specific data with
status "End". In this case, the Payment Handler must not supply any the continuation status "End". Even in the absence of this knowledge
further payment scheme data, because it will be rejected by the - this status is not exchanged between the Consumer and the Payment
Consumer's IOTP Payment Bridge. Note that the genuine continuation Handler - the Payment Handler must not supply any further payment
status is not exchanged between the Consumer and the Payment Handler. scheme specific data. Such data will be rejected by the Consumer's
IOTP Payment Bridge.
8. The Consumer passes the optional payment scheme data and the 8. The Consumer passes the optional payment scheme specific data and
payment receipt to the appropriate IOTP Payment Bridge by "Continue the payment receipt to the fixed IOTP Payment Bridge by "Continue
Process" and "Check Payment Receipt" API calls. Finally, the Process" and "Check Payment Receipt" API calls.
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 Payment Afterwards, the IOTP Application Core issues the "Inquire Process
Handler. Therefore, failures have to be resolved locally or outside State" API call and verifies whether extensions to the payment
the payment transaction. receipt have been returned.
8.5 Payment Inquiry Finally, the transaction is terminated by calling the "Change
Process State" API function which verifies and synchronizes the
reported payment status with the local one and signals any
inconsistencies. Any Inconsistency and returned status text should be
displayed to the Consumer.
At this point, the payment transaction has already been closed by
the Payment Handler. Therefore, any failure has to be resolved
locally or out-of-band.
2.5 Payment Inquiry
In Baseline IOTP, Payment inquiries are initiated by the Consumer in In Baseline IOTP, Payment inquiries are initiated by the Consumer in
order to verify the current payment progress and process state at the order to verify the current payment progress and process state at the
remote Payment Handler. The next figure shows the message flow of a remote Payment Handler.
Consumer initiated payment inquiry.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Inquiry() -> IPB Consumer Start Payment Inquiry() -> IPB
Start Payment Inquiry Response([PS1]) <- IPB Start Payment Inquiry Response([PS1]) <- IPB
Create and transmit Inquiry Request Trading Block Create and transmit Inquiry Request Trading Block
Payment Handler Inquire Payment Status([PS1]) -> IPB Payment Handler Inquire Payment Status([PS1]) -> IPB
Inquire Payment Status Res.(State, [PS2]) -> IPB Inquire Payment Status Res.(State, [PS2]) -> IPB
Create and transmit Inquiry Response Trading Create and transmit Inquiry Response Trading
Block Block
Consumer If Payment Scheme Data present Consumer If Payment Scheme Data present
| Continue Process(PS2) -> IPB | Continue Process(PS2) -> IPB
| Continue Process Response(CS=End) <- IPB | Continue Process Response(CS=End) <- IPB
Change Process State(State) -> IPB Change Process State(State) -> IPB
Change Process State Response(State') <- IPB Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 16 Remote Process State Inquiry Figure 6 Remote Process State Inquiry
1. The Consumer might initiate a payment inquiry once the payment 1. The Consumer might initiate a payment inquiry once the payment
transaction has been opened by the IOTP Application Core, i.e., any transaction has been opened by the IOTP Application Core, i.e., at
time after the initial submission of the IOTP Payment Request Block. any time after the initial submission of the IOTP Payment Request
The IOTP Application Core requests any additional specific payment Block. The IOTP Application Core requests any additional specific
scheme data from the respective IOTP Payment Bridge using the "Start payment scheme data from the IOTP Payment Bridge which has been fixed
Payment Inquiry" API request. Erroneous API responses should be during brand selection (cf. Section 2.3) using the "Start Payment
reported to the Consumer and valid alternatives (typically retry and Inquiry" API request.
cancellation) should be presented by the IOTP Application Core.
Generally, this request performs the complete initialization, e.g. Erroneous API responses should be reported to the Consumer and valid
availability check of periphery or pass phrase supplement. The IOTP alternatives (typically retry and cancellation) should be presented
Payment Bridge reports lack of capability quite similar to the "Check by the IOTP Application Core.
Payment Possibility" request to the IOTP Application Core.
This request might perform the complete initialization, e.g.
availability check of periphery or pass phrase supplement, and the
IOTP Payment Bridge reports lack of capability quite similar to the
"Check Payment Possibility" request to the IOTP Application Core.
If the IOTP Payment Bridge requests wallet identifiers or pass If the IOTP Payment Bridge requests wallet identifiers or pass
phrases anywhere during the inquiry process, they should be requested phrases anywhere during the payment process, they should be requested
by this API call, too. The IOTP Application Core should store these by this API function, too. It is recommended that the IOTP
values. The IOTP Payment Bridge may also store these values and Application Core stores plain text pass phrases only in runtime
dispense with their supplement on subsequent inquiry related API memory.
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. For security reasons, the
IOTP Application Core should store plain text pass phrases only in
runtime memory and the IOTP Payment Bridges should renew their
requests for pass phrases after any "Change Process State" API call.
The IOTP Application Core encapsulates any Payment Scheme Component The IOTP Application Core encapsulates any Payment Scheme Component
in an IOTP Inquiry Request Block and submits it to the Payment in an IOTP Inquiry Request Block and submits the block to the Payment
Handler. Handler.
2. The Payment Handler analyses the Inquire Request Block, maps the 2. The Payment Handler analyses the IOTP Inquire Request Block, maps
Transaction Identifier to payment related attributes (Brand, Consumer the Transaction Identifier to payment related attributes (brand,
and Payment Handler Payment Identifiers), and forwards the request to consumer and payment identifiers), determines the appropriate IOTP
the appropriate IOTP Payment Bridge ("Inquire Payment Status"). The Payment Bridge, and forwards the request to the this IOTP Payment
IOTP Application Core transforms the response to an Inquiry Response Bridge ("Inquire Payment Status"). The IOTP Application Core
Block and transmits it to the Consumer. transforms the response to an IOTP Inquiry Response Block and
transmits it to the Consumer.
3. On receipt of the respective IOTP Inquiry Response Block the 3. On receipt of the respective IOTP Inquiry Response Block the
Consumer's IOTP Application Core submits any encapsulated payment Consumer's IOTP Application Core submits any encapsulated payment
scheme specific data to the IOTP Payment Bridge for verification scheme specific data to the IOTP Payment Bridge for verification
("Continue Process"). ("Continue Process").
4. The IOTP Application Core passes the reported payment status 4. The IOTP Application Core passes the reported payment status
(except textual descriptions) to the IOTP Payment Bridge ("Change (except textual descriptions) to the IOTP Payment Bridge ("Change
Process State") for verification purposes and payment status change. Process State") for verification purposes and payment status change.
The IOTP Payment Bridge reports any inconsistencies as well as the The IOTP Payment Bridge reports any inconsistencies as well as the
final payment status to the IOTP Application Core. Any additional final payment status to the IOTP Application Core.
information that may be of interest for the Consumer has to be
displayed by the IOTP Payment Bridge or Existing Payment Software on
their own.
8.6 Abnormal Transaction Processing Any additional information that might be of interest for the
Consumer has to be displayed by the IOTP Payment Bridge or Existing
Payment Software on their own.
8.6.1 Failures and Cancellations 2.6 Abnormal Transaction Processing
2.6.1 Failures and Cancellations
The IOTP specification distinguishes between several classes of The IOTP specification distinguishes between several classes of
failures: failures:
o Business and technical errors o Business and technical errors
o Error depth on transport, message and block level o Error depth on transport, message and block level
o Transient errors, warnings, and hard errors. o Transient errors, warnings, and hard errors.
Any (Payment) API has to deal with the receipt of failure Any IOTP Payment API has to deal with the receipt of failure
notifications from and failure responses to the IOTP Application notifications by and failure responses. This proposal has borrowed
Core. The interface between the IOTP Application Core and the IOTP the basic mechanisms for error reporting between the IOTP Application
Payment Bridge is mostly inherited from the genuine protocol. I.e., Core and the IOTP Payment Bridge from the genuine protocol: Business
business errors are reported by status components in normal response errors are reported by Status Components within IOTP Response Blocks
blocks while technical errors are signaled by error components in while technical errors are signaled by Error Components within IOTP
dedicated error blocks. Error Blocks.
Cancellations are specific business errors might be initiated by each Cancellations are mimicked as specific business errors which might
trading party. be initiated by each trading party.
In preference to slim interfaces, the payment API introduces one Preferring slim interfaces, this IOTP Payment API introduces one
additional error flag for business error indication - errors can be additional Error Code value for business error indication - errors
returned by every API function. On receipt of this flag, the IOTP can be raised on every API call. On receipt of this value, the IOTP
Application Core has to infer the details of the business error using Application Core has to infer further details by the issuance of the
the API function "Inquire Process State". API function call "Inquire Process State".
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Issue some API request -> IPB Any Party Issue some API request -> IPB
Error Response(Error Code) <- IPB Error Response(Error Code) <- IPB
On "Business Error" response On "Business Error" response
| Inquire Process State() -> IPB | Inquire Process State() -> IPB
| Inquire P.S. Resp.(State, Receipt) <- IPB | Inquire P.S. Resp.(State, Receipt) <- IPB
Determine Local Behavior Analyze local process state and try to resolve
If Status Change needed with optional user interaction
If Process State Change needed
| Change Process State (State) -> IPB | Change Process State (State) -> IPB
| Change Process State Response(State') <- IPB | Change Process State Response(State) <- IPB
If Counterparty notification required If counter party's notification required
| Create Error or Cancel Block (, add to next | Create Error or Cancel Block (, add to next
message, ) and transmit it to counterparty | message, ) and transmit it to counter party
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 17 Error Response from IPB Figure 7 Error Response from IPB
The specific Completion Codes "ConsCancelled", "MerchCancelled", and The specific Completion Codes "ConsCancelled", "MerchCancelled", and
"PaymCancelled" - returned by "Inquire Process State" - determine "PaymCancelled" - returned by "Inquire Process State" - determine
that the Cancel Block has to be created instead of an Error Block. that the IOTP Cancel Block has to be created instead of an IOTP Error
The rules for the determination of the behavior of the IOTP Block.
Application Core, particularly the response to the counterparty is
given in the IOTP specification.
Vice versa, failures, cancellations, and even success's are always The rules for determining the required behavior of the IOTP
reported to the IOTP Payment Bridge by the API function "Change Application Core are given in the IOTP specification.
Process State". This API function is used both for status change and
consistency checking. Any suspicion of inconsistency should be Note that any payment (intermediate) termination, i.e., failures,
reported by the IOTP Payment Bridge for display by the IOTP cancellations, and even success's is always reported to the IOTP
Application Core. Payment Bridge by the API function "Change Process State". This API
function does both status changes and consistency checking /
synchronization. Any suspicion of inconsistency should be reported by
the IOTP Payment Bridge for display by the IOTP Application Core.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Error Block or Cancel Block Received Any Party Error Block or Cancel Block Received
If Status Change required If Change Process State required
| Change Process State (State) -> IPB | Change Process State (State) -> IPB
| Change Process State Response(State') <- IPB | Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 18 Error Notification to IPB Figure 8 Error Notification from counter party
The processing of payment transactions might temporarily be hampered Not every failure might be visible at the IOTP layer, e.g., the
by intermediate failures without significant influence to the IOTP processing of payment transactions might temporarily be hampered by
layer. Internal failures might be resolved within the genuine payment intermediate failures at the payment scheme or protocol transport
scheme. However, final failures or cancellations have to be reported layer which might be resolved by the genuine components.
at the IOTP layer.
Finally, communication time-out and heavily faulty communication However, final failures or cancellations have to be reported at the
channels may disable the transaction. Any components may implement IOTP layer. E.g., communication time-outs and heavily faulty
time-out recognition and use the aforementioned API mechanisms for communication channels may disable the transaction.
the notification 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 IOTP Payment Bridges, may raise time-outs
that need to be resolved. The Consumer's IOTP Application Core should
notify the Consumer about the resolution alternatives, i.e., retry,
suspension, and cancellation.
8.6.2 Resumption Any system component may implement time-out recognition and use the
aforementioned API mechanisms for the notification of process state
changes. But, time-outs may happens while communicating with both the
counter party and local system components, like chip card readers or
IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core
should notify the Consumer about the resolution alternatives, i.e.,
retry, suspension, and cancellation.
2.6.2 Resumption
Payment transaction resumption may apply at different steps of a Payment transaction resumption may apply at different steps of a
payment transaction: payment transaction:
o Due to different time-out values the payment transaction may not o The Consumer's and Payment Handler's view of the transaction
have been suspended by the counterparty. Therefore, the API callee might not be synchronized: Due to different time-out values the
has to deal with pending and suspended payment transactions. payment transaction may not have been suspended by the counter
party.
o IOTP Payment Exchange and IOTP Payment Request Blocks may be Any "Resume Payment ..." API function responds with an Error Code
received by the Payment Handler on resumption. Additionally, the on non suspended payment transaction that signals a business
payment transaction may not have been created at the Payment Handler. error. Afterwards the IOTP Application Core has to issue the
In that case, the "Resume Payment Payment Handler" API function "Inquire Process State" API call for further analysis of the
responds with a hard error indicating the required "Start Payment process state.
Payment Handler" API call.
o The IOTP Application Core may defer any payment tracing o One IOTP message sent by one party might not be processed
responsibilities to the IOTP Payment Bridge and may not be able to successfully or even received by the counter party.
distinguish between the continuation and resumption of payment
transactions. Either, the IOTP Payment Bridge API functions "Start This needs to be handled by the genuine payment scheme. It is
Payment Payment Handler" and "Continue Process" implement both cases expected that the IOTP Application Core will not recognize
or they signal the required explicit payment resumption by error code anything.
responses ("Business Error"). Further analysis of the current payment
state ("Inquire Process State") should return the value Suspended. o IOTP does not provide any specific signal for payment
resumption. On receipt of every IOTP Payment Exchange Block, the
IOTP Application Core has to decide whether this Block belongs to
a pending transaction or to a suspended transaction that should be
resumed. The IOTP Application Core might call the "Inquire Process
State" API function to update any lack of knowledge.
Any "Resume Payment" API function responds with an Error Code on
non suspended payment transaction that signals a business error.
Similar, the "Continue Process" API function should report
business errors on non pending payment transactions.
o The payment transaction may not have been created at the Payment
Handler (early suspension and failed data transmission). In that
case, the IOTP Application Core should respond with a business
error that signals the repetition of the payment transaction (by
the Consumer).
Any "Resume Payment", "Continue Process" or "Inquire Process
State" API function should return with an Error Code
"AttValIllegal" on non existent payment transaction whereby the
further Error Attribute "Names" denote the payment identifier.
o The IOTP Application Core should always request fresh payment
scheme specific data on resumption - for synchronization purposes
with the Existing Payment Software. Old data in the cache that has
not been send to the counter party should not be accessed.
If the Consumer does not reconnect within an acceptable amount of If the Consumer does not reconnect within an acceptable amount of
time, the Payment Handler's system may perform local failure time, the Payment Handler's system may perform local failure
resolution in order to close the transaction and to retain resources resolution in order to close the transaction and to retain resources
for other transactions ("Change Process State"). If the Consumer for other transactions ("Change Process State"). If the Consumer
reconnect afterwards, a Payment Response or Error Block could be reconnect afterwards, an IOTP Payment Response or IOTP Error Block
generated. could be generated.
It is expected, that Payment Handlers implement the main control of
the payment transaction. Therefore, the Payment Handler's
responsibility for driving the payment transaction to a consistent
status is very high.
8.7 IOTP Wallet Initialization 2.7 IOTP Wallet Initialization
At startup or on explicit user request the IOTP Application Core At startup or on explicit user request the IOTP Application Core
should check its IOTP Payment Bridges' internal status by searching should check its IOTP Payment Bridges' internal status by searching
for pending payment transactions. for pending payment transactions.
1. The IOTP Application Core interrogates the registered IOTP 1. The IOTP Application Core interrogates the registered IOTP
Payment Bridges about pending payment transactions. The IOTP Payment Bridges about pending payment transactions. The IOTP
Application Core may store indicators for pending transactions and Application Core may store indicators for pending transactions and
use them for driving any subsequent inquiry ("Inquire Pending use them for driving any subsequent inquiry ("Inquire Pending
Payment"). Payment").
2. If one IOTP Payment Bridge reports the presence of pending 2. If one or more IOTP Payment Bridges report the presence of pending
transactions, the IOTP Application Core has to inquire more transactions, the IOTP Application Core may try to suspend ("Change
information about each pending transaction ("Inquire Payment Log"). Process State") or resume (only Consumer: "Resume Payment Consumer")
This inquiry API call may be pass phrase protected which has to be the pending transactions (on user request).
requested from the Consumer.
3. The IOTP Application Core may try to suspend ("Change Process The IOTP Payment Bridge may deny the processing of any new payment
State") or resume ("Resume Payment Consumer") the pending transaction transactions until the pending transactions have been processed. Such
(on user request). The IOTP Payment Bridge may deny any processing of denials are signaled by the error code "Business Error".
new payment transactions until the pending transactions have been
processed. These denials are signaled by the error code "Business
Error".
8.8 Payment Software Management 2.8 Payment Software Management
The IOTP Application Core provides only a simple and generic The IOTP Application Core provides only a simple and generic
interface for the registration of new payment methods / instruments interface for the registration of new payment methods / instruments
("Manage Payment Software"). It receives the initial user request and ("Manage Payment Software"). It receives the initial user request and
defers the actual registration to the corresponding IOTP Payment defers the actual registration to the corresponding IOTP Payment
Bridge. Other IOTP Application Core specific registration procedures Bridge.
deal with the registration of new IOTP Payment Bridges and payment
brands. The registration of a new payment instrument may even be
useful in the initial step of a payment transaction, when the
Merchant transmits new brand identifiers to the Consumer. The IOTP
Application Core has to renew any inquiry of payment instruments - at
least partially, if registration happens afterwards. The IOTP
Application Core may also activate the Existing Payment Software for
further payment instrument and wallet administration.
9. Mutuality The IOTP Application Core may also activate the Existing Payment
Software for further payment instrument and wallet administration.
3. Mutuality
The Payment API is formalized using the Extensible Markup Language
(XML). It defines wrapper elements for both the input parameters and
the API function's response. In particular, the response wrapper
provides common locations for Error Codes and Error Descriptions.
The input and output arguments are annotated using the Extensible
Markup Language (XML) notation. The called API function responds with
a generic wrapper, that provides error codes and error descriptions.
It is anticipated that this description reflects the logical It is anticipated that this description reflects the logical
structure of the API parameter. It may be used to derive structure of the API parameter and might be used to derive
implementation language specific API definitions. implementation language specific API definitions.
XML definition: 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?, ( <!ELEMENT IotpPaymentApiResponse (ErrorResponse?, (
FindAcceptedPaymentBrandResponse | FindAcceptedPaymentBrandResponse |
FindAcceptedPaymentProtocolResponse | FindAcceptedPaymentProtocolResponse |
GetPaymentInitializationDataResponse | GetPaymentInitializationDataResponse |
CancelPaymentResponse |
FindPaymentInstrumentResponse | FindPaymentInstrumentResponse |
FindPaymentProtocolResponse |
CheckPaymentPossiblityResponse | CheckPaymentPossiblityResponse |
QuitPaymentInstrumentResponse |
StartPaymentConsumerResponse | StartPaymentConsumerResponse |
StartPaymentPaymentHandlerResponse | StartPaymentPaymentHandlerResponse |
ResumePaymentConsumerResponse | ResumePaymentConsumerResponse |
ResumePaymentPaymentHandlerResponse | ResumePaymentPaymentHandlerResponse |
ContinueProcessResponse | ContinueProcessResponse |
InquireProcessStateResponse | InquireProcessStateResponse |
ChangeProcessStateResponse | ChangeProcessStateResponse |
PassErrorCodeResponse |
InquireAuthChallengeResponse | InquireAuthChallengeResponse |
AuthenticateResponse | AuthenticateResponse |
CheckAuthResponsenResponse | CheckAuthResponseResponse |
CheckPaymentReceiptResponse | CheckPaymentReceiptResponse |
ExpandPaymentReceiptResponse | ExpandPaymentReceiptResponse |
InquirePaymentLogResponse |
RemovePaymentLogResponse | RemovePaymentLogResponse |
PaymentInstrumentInquiryResponse | PaymentInstrumentInquiryResponse |
InquirePendingPaymentResponse | InquirePendingPaymentResponse |
ManagePaymentSoftwareResponse | ManagePaymentSoftwareResponse |
StartPaymentInquiryResponse | StartPaymentInquiryResponse |
InquirePaymentStatusResponse | InquirePaymentStatusResponse |
CallBackResponse | CallBackResponse )?)>
AccessDatabaseResponse )?)>
<!ATTLIST IotpPaymentApiResponse <!ATTLIST IotpPaymentApiResponse
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #IMPLIED
ContentSoftwareID CDATA #IMPLIED > ContentSoftwareID CDATA #IMPLIED
xmlns CDATA #FIXED
"http://www.iotp.org/2000/08/PaymentAPI" >
<!ELEMENT ErrorResponse (PaySchemePackagedContent*) > <!ELEMENT ErrorResponse (ErrorLocation+,PaySchemePackagedContent*) >
<!ATTLIST ErrorResponse <!ATTLIST ErrorResponse
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
ErrorCode NMTOKEN #REQUIRED ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED ErrorDesc CDATA #REQUIRED
Severity (Warning | Severity (Warning |
TransientError | TransientError |
HardError) #REQUIRED HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED MinRetrySecs CDATA #IMPLIED
Names NMTOKENS #IMPLIED > SwVendorErrorRef CDATA #IMPLIED >
Most of the attribute items are intended for immediate insertion in Most of the attribute items are intended for immediate insertion in
the IOTP Error Block. The values of the Name attribute have to the IOTP Error Block. The attribute values of the Error Location
transformed into Error Location Elements of the Error Component (cf. elements attribute have to enriched and transformed into Error
IOTP Specification). Location Elements of the Error Component (cf. IOTP Specification).
Attributes: Attributes (cf. IOTP Specification):
xml:lang Defines the language used by the Error xml:lang Defines the language used by attributes or
Description attribute (cf. IOTP child elements within this component, unless
Specification). overridden by an xml:lang attribute on a child
element.
ContentSoftwareId This contains information which identifies the ContentSoftwareId Contains information which identifies the
software which generated the IOTP Message. Its ssoftware that generated the content of the
purpose is to help resolve interoperability element. Its purpose is to help resolve
interoperability problems that might occur as
a result of incompatibilities between messages
produced by different software. It is a single
text string in the language defined by
"xml:lang". It must contain, as a minimum
problems that might occur as a result of problems that might occur as a result of
incompatibilities between messages produced by
different software. It is a single text string
in the language defined by "xml:lang". It must
contain, as a minimum
o the name of the software manufacturer, o the name of the software manufacturer,
o the name of the software, o the name of the software,
o the version of the software, and o the version of the software, and
o the build of the software. o the build of the software.
ErrorCode Contains an error code which indicates the ErrorCode Contains an error code which indicates the
nature of the error in the message in error. nature of the error in the message in error.
Valid values for the Error Code are given in Valid values for the Error Code are given in
the following section. This mnemonic enables the following section. This mnemonic enables
the automatic failure resolution of the IOTP the automatic failure resolution of the IOTP
Application Core which analyzes the error code Application Core which analyzes the error code
value in order to determine the continuation value in order to determine the continuation
alternatives. alternatives.
ErrorDesc An optional textual description of the current ErrorDesc Contains a description of the error in the
error in the language identified by language defined by xml:lang. The content of
"xml:lang". It is intended for user display this attribute is defined by the
and provides detailed explanations about the vendor/developer of the software that
failure and its (out-of-band) resolution generated the Error Response Element.
alternatives. It is 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 Severity Indicates the severity of the error. Valid
values are: values are:
o Warning. This indicates that although there o Warning. This indicates that although there
is a message in error the IOTP Transaction is a message in error the IOTP Transaction
can still continue. can still continue.
o TransientError. This indicates that the o TransientError. This indicates that the
error in the message in error may be error in the message in error may be
recovered if the message in error that is recovered if the message in error that is
referred to by the "Names" attribute is referred to by the "Names" attribute is
resent. resent.
o HardError. This indicates that there is an o HardError. This indicates that there is an
unrecoverable error in the message in error unrecoverable error in the message in error
and the IOTP Transaction must stop. and the IOTP Transaction must stop.
MinRetrySecs This attribute should be present if Severity MinRetrySecs This attribute should be present if "Severity"
is set to "TransientError". It is the minimum is set to "TransientError". It is the minimum
number of whole seconds which the IOTP aware number of whole seconds which the IOTP aware
application which received the message application which received the message
reporting the error should wait before re- reporting the error should wait before re-
sending the message in error identified by the sending the message in error identified by the
"Names" attribute. "ErrorLocation" attribute.
If Severity is not set to If Severity is not set to
"TransientError" then the value of this "TransientError" then the value of this
attribute is ignored. attribute is ignored.
Names This attribute indicates the name(s) of the SwVendorErrorRef This attribute is a reference whose value is
attribute or element to which the error code set by the vendor/developer of the software
refers. that generated the Error Element. It should
contain data that enables the vendor to
identify the precise location in their
software and the set of circumstances that
caused the software to generate a message
reporting the error.
Content: Content:
ErrorLocation This identifies, where possible, the
element and attribute in the message
in error that caused the Error
Element to be generated. If the
"Severity" of the error is not
"TransientError", more that one
"ErrorLocation" may be specified as
appropriate depending on the nature
of the error and at the discretion of
the vendor/developer of the IOTP
Payment Bridge.
Its definition coincides with the
IOTP specification whereby the
attributes "IotpMsgRef", "BlkRef" and
"CompRef" are left blank,
intentionally.
PaySchemePackagedContent cf. Table 5 PaySchemePackagedContent cf. Table 5
9.1 Error Codes 3.1 Error Codes
The following table contains the valid values for the ErrorCode The following table lists the valid values for the ErrorCode
attribute of the Error Response. The first sentence of the attribute of the Error Response Element. The first sentence of the
description contains the default text that can be used to describe error description contains the default text that can be used to
the error when displayed or otherwise reported. Individual describe the error when displayed or otherwise reported. Individual
implementations may translate this into alternative languages at implementations may translate this into alternative languages at
their discretion. However, not every error code may apply to every 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 API call. An Error Code must not be more than 14 characters long.
Error Codes have been taken from the IOTP Specification and extended
by some additional codes which are highlighted by a preceding The Error Codes have been taken from the IOTP Specification and
asterisk. extended by some additional codes which are highlighted by a
preceding asterisk.
Generally, if the corrupt values have been user supplied, the IOTP Generally, if the corrupt values have been user supplied, the IOTP
Application Core might prompt for their correction. If the renewal Application Core might prompt for their correction. If the renewal
fails or if the IOTP Application Core skips any renewals and some fails or if the IOTP Application Core skips any renewals and some
notification has to be send to the counter-party, the error code is notification has to be send to the counter-party, the error code is
encapsulated within an IOTP Error Block. However, the IOTP server encapsulated within an IOTP Error Block.
application reports business errors by the Status Component of the
respective Response Block.
References which are enumerated in the Names attribute have to be However, the IOTP server application reports business errors -
transformed to Error Location Elements. The IOTP Application Core visible at the IOTP layer - in the Status Component of the respective
must consider the elements' origin in the received IOTP message. Response Block.
Particularly, references to packaged content elements have to be
transformed to references of the surrounding XML element. The same The IOTP Application Core may add the attributes (and values) within
rule applies to any reported attribute. Then, the AttName attribute the ErrorLocation elements being omitted by the IOTP Payment Bridge.
has to be set in the Error Location element, too.
The following table mentions any modification from this general The following table mentions any modification from this general
processing for particular error values. Furthermore, it contains processing for particular error values. Furthermore, it contains
hints for developers of IOTP Application Core software components hints for developers of IOTP Application Core software components
about the processing of error codes. Conversely, developers of IOTP about the processing of error codes. Conversely, developers of IOTP
Payment Bridges get impressions about the expected behavior of the Payment Bridges get impressions about the expected behavior of the
IOTP Application Core. The IOTP Payment API assumes that the IOTP IOTP Application Core.
Application Core implements the dialog boxes needed for error
resolution. But it does not assume, that the IOTP Payment Bridge The IOTP Payment API assumes that the IOTP Application Core
actually relies on them. Instead, the IOTP Payment Bridge may try implements the dialog boxes needed for error resolution. But it does
resolution on its own, implement specific dialog boxes, and signal not assume, that the IOTP Payment Bridge actually relies on them.
only final failures. Instead, the IOTP Payment Bridge may try resolution on its own, may
implement specific dialog boxes, and may signal only final failures.
Note: This abstract document assumes that the API parameters are Note: This abstract document assumes that the API parameters are
exchanged in XML encoding. Therefore, several error values might exchanged XML encoded. Therefore, several error values might
disappear in lower level language specific derivations. disappear in lower level language specific derivations.
Error Value Error Description Error Value Error Description
Reserved Reserved. This error is reserved by the Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact vendor/developer of the software. Contact
the vendor/developer of the software for the vendor/developer of the software for
more information (see the SoftwareId more information (see the SoftwareId
attribute of the Message Id element in the attribute of the Message Id element in the
Transaction Reference Block [RFC XXXX]). Transaction Reference Block [IOTP]).
The Names attribute might refer some
attributes or elements of the input
parameter list.
XmlNotWellFrmd XML not well formed. The XML document is not XmlNotWellFrmd XML not well formed. The XML document is not
well formed. See [XML] for the meaning of well formed. See [XML] for the meaning of
"well formed". "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 XmlNotValid XML not valid. The XML document is well
formed but the document is not valid. See formed but the document is not valid. See
[XML] for the meaning of "valid". [XML] for the meaning of "valid".
Specifically: Specifically:
o the XML document does not comply with the o the XML document does not comply with the
constraints defined in the IOTP document constraints defined in the IOTP document
type declaration, and type declaration, and
o the XML document does not comply with the o the XML document does not comply with the
constraints defined in the document type constraints defined in the document type
declaration of any additional [XML declaration of any additional [XML-NS]
Namespace] that are declared. that are declared.
The Names attribute might refer some The Names attribute might refer some
attributes and elements of the input attributes and elements of the input
parameter list. parameter list.
(*)ElNotValid Element not valid. Invalid element in terms (*)ElNotValid Element not valid. Invalid element in terms
of prescribed syntactical characteristics. of prescribed syntactical characteristics.
The Names attribute refers to the
corresponding element tags. The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
elements (if they have ID attributes).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" before error code with "XmlNotValid" before
transmission to the counterparty. transmission to the counterparty.
ElUnexpected Unexpected element. Although the XML ElUnexpected Unexpected element. Although the XML
document is well formed and valid, an document is well formed and valid, an
element is present that is not expected in element is present that is not expected in
the particular context according to the the particular context according to the
rules and constraints contained in this rules and constraints contained in this
specification. specification.
The Names attribute refers to the The ElementRef attributes of ErrorLocation
corresponding element tags. The IOTP elements might refer to the corresponding
Application Core has to replace the error elements (if they have ID attributes).
code with "EncapProtErr" or
"ElContIllegal" before transmission to the
counterparty, if the Names attribute refers
to inner elements without a Block or
Component Identifier.
ElNotSupp Element not supported. Although the document ElNotSupp Element not supported. Although the document
is well formed and valid, an element is is well formed and valid, an element is
present that present that
o is consistent with the rules and o is consistent with the rules and
constraints contained in this constraints contained in this
specification, but specification, but
o is not supported by the IOTP Aware o is not supported by the IOTP Aware
Application which is processing the IOTP Application which is processing the IOTP
Message. Message.
The Names attribute refers to the The ElementRef attributes of ErrorLocation
corresponding element tags. The IOTP elements might refer to the corresponding
Application Core has to replace the error elements (if they have ID attributes).
code with "EncapProtErr" or
"ElContIllegal" before transmission to the
counterparty, if the Names attribute refers
to inner elements without a Block or
Component Identifier.
ElMissing Element missing. Although the document is ElMissing Element missing. Although the document is
well formed and valid, an element is missing well formed and valid, an element is missing
that should have been present if the rules that should have been present if the rules
and constraints contained in this and constraints contained in this
specification are followed. specification are followed.
The Names attribute refers to the The ElementRef attributes of ErrorLocation
corresponding element tags. The IOTP elements might refer to the corresponding
Application Core has to replace the error elements (if they have ID attributes).
code 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 the ElContIllegal Element content illegal. Although the
document is well formed and valid, the document is well formed and valid, the
element contains values which do not conform element contains values which do not conform
the rules and constraints contained in this the rules and constraints contained in this
specification. The Names attribute refers to specification.
the corresponding element tags.
The ElementRef attributes of ErrorLocation
elements might refer to the corresponding
element (if they have ID attributes).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "EncapProtErr" or Error Code with "ElNotSupp" before
"ElContIllegal" before transmission to the transmission to the counter party, if the
counterparty, if the Names attribute refers ErrorLocation elements refer to non
to inner elements without a Block or PackagedContent element.
Component Identifier.
EncapProtErr Encapsulated protocol error. Although the EncapProtErr Encapsulated protocol error. Although the
document is well formed and valid, the document is well formed and valid, the
Packaged Content of an element contains data Packaged Content of an element contains data
from an encapsulated protocol which contains from an encapsulated protocol which contains
errors. errors.
The Names attribute refers to the The ElementRef attributes of ErrorLocation
corresponding element tags. elements might refer to the corresponding
element (if they have ID attributes).
AttUnexpected Unexpected attribute. Although the XML AttUnexpected Unexpected attribute. Although the XML
document is well formed and valid, the document is well formed and valid, the
presence of the attribute is not expected in presence of the attribute is not expected in
the particular context according to the the particular context according to the
rules and constraints contained in this rules and constraints contained in this
specification. specification.
The Names attribute refers to the The AttName attributes of ErrorLocation
corresponding attribute tags. elements might refer to the corresponding
attribute tags.
(*)AttNotValid Attribute not valid. Invalid attribute value (*)AttNotValid Attribute not valid. Invalid attribute value
in terms of prescribed syntactical in terms of prescribed syntactical
characteristics. The Names attribute refers characteristics.
to the corresponding attribute tags.
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags.
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" before error code with "XmlNotValid" before
transmission to the counterparty. transmission to the counterparty.
AttNotSupp Attribute not supported. Although the XML AttNotSupp Attribute not supported. Although the XML
document is well formed and valid, and the document is well formed and valid, and the
presence of the attribute in an element is presence of the attribute in an element is
consistent with the rules and constraints consistent with the rules and constraints
contained in this specification, it is not contained in this specification, it is not
supported by the IOTP Aware Application supported by the IOTP Aware Application
which is processing the IOTP Message. which is processing the IOTP Message.
The Names attribute refers to the
corresponding attribute tags.
Furthermore, the inquiry API function
("Inquire Payment Log") might report lack of
selection criteria. If a selector has been
user supplied, the IOTP Application Core may
offer a dialog for its adjustment. However,
errors generated in this case, are never
passed to the counterparty's IOTP
Application Core.
AttMissing Attribute missing. Although the document is AttMissing Attribute missing. Although the document is
well formed and valid, an attribute is well formed and valid, an attribute is
missing that should have been present if the missing that should have been present if the
rules and constraints contained in this rules and constraints contained in this
specification are followed. The Names specification are followed.
attribute refers to the corresponding
The AttName attributes of ErrorLocation
elements might refer to the corresponding
attribute tags. attribute tags.
If the attribute is required by the IOTP If the attribute is required by the IOTP
Document Type Declaration (#REQUIRED) the Document Type Declaration (#REQUIRED) the
hints for non valid attributes should be hints for non valid attributes should be
adopted, otherwise these for illegal adopted, otherwise these for illegal
attribute values. attribute values.
AttValIllegal Attribute value illegal. The attribute AttValIllegal Attribute value illegal. The attribute
contains a value which does not conform to contains a value which does not conform to
the rules and constraints contained in this the rules and constraints contained in this
specification. specification.
The Names attribute refers to the The AttName attributes of ErrorLocation
corresponding attribute tags - valid values elements might refer to the corresponding
are: attribute tags - valid values are:
BrandId: illegal/unknown Brand Identifier - BrandId: illegal/unknown Brand Identifier -
If the brand is not recognized/known by any If the brand is not recognized/known by any
IOTP Payment Bridge, the IOTP Application IOTP Payment Bridge, the IOTP Application
Core may offer the registration of a new Core may offer the registration of a new
Payment Instrument. Payment Instrument.
PaymentInstrumentId: illegal/unknown PaymentInstrumentId: illegal/unknown
Payment Instrument Identifier - This Payment Instrument Identifier - This
indicates a serious communication problem if indicates a serious communication problem if
the attribute value has been reported by the the attribute value has been reported by the
same "wallet" on a previous inquiry same "wallet" on a previous inquiry
requests. The IOTP Application Core has to requests. The IOTP Application Core has to
replace the error code with replace the error code with
"TransportError" before transmission to the "UnknownError" before transmission to the
counterparty. counterparty.
WalletId: illegal/unknown Wallet Identifier WalletId: illegal/unknown Wallet Identifier
- It is assumed that the wallet identifier - It is assumed that the wallet identifier
is checked before the pass phrase. On is checked before the pass phrase. On
invalid wallet identifiers, the IOTP invalid wallet identifiers, the IOTP
Application Core may open the dialog in Application Core may open the dialog in
order to request the correct wallet order to request the correct wallet
identifier. In addition, any pass phrase may identifier. In addition, any pass phrase may
be supplied by the user. The dialog should be supplied by the user. The dialog should
indicate the respective payment brand(s). indicate the respective payment brand(s).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "TransportError" before error code with "UnknownError" before
transmission to the counterparty. transmission to the counterparty.
Passphrase: illegal/unknown Pass Phrase - Passphrase: illegal/unknown Pass Phrase -
The IOTP Application Core may open the The IOTP Application Core may open the
dialog in order to request the correct pass dialog in order to request the correct pass
phrase. If the pass phrase is wallet phrase. If the pass phrase is wallet
identifier specific the dialog should identifier specific the dialog should
display the wallet identifier. The IOTP display the wallet identifier. The IOTP
Application Core has to replace the error Application Core has to replace the error
code with "TransportError" before code with "TransportError" before
skipping to change at page 79, line 32 skipping to change at page 43, line 27
OkTo: illegal/unknown/unsupported OkTo OkTo: illegal/unknown/unsupported OkTo
Timestamp Timestamp
ConsumerPayId: illegal/unknown Consumer ConsumerPayId: illegal/unknown Consumer
Payment Identifier Payment Identifier
PaymentHandlerPayId: illegal/unknown Payment PaymentHandlerPayId: illegal/unknown Payment
Handler Payment Identifier Handler Payment Identifier
PayId: illegal/unknown Payment Identifier
AttValNotRecog Attribute Value Not Recognized. The AttValNotRecog Attribute Value Not Recognized. The
attribute contains a value which the IOTP attribute contains a value which the IOTP
Aware Application generating the message Aware Application generating the message
reporting the error could not recognize. reporting the error could not recognize.
The Names attribute refers to the The AttName attributes of ErrorLocation
corresponding attribute tags. elements might refer to the corresponding
attribute tags
MsgTooLarge Message too large. The message is too large MsgTooLarge Message too large. The message is too large
to be processed by the IOTP Payment Bridge to be processed by the IOTP Payment Bridge
(resp. IOTP Application Core). (resp. IOTP Application Core).
ElTooLarge Element too large. The element is too large ElTooLarge Element too large. The element is too large
to be processed by the IOTP Payment Bridge to be processed by the IOTP Payment Bridge
(resp. IOTP Application Core). (resp. IOTP Application Core).
The Names attribute refers to the The ElementRef attributes of ErrorLocation
corresponding attribute tags. elements might might refer to the
corresponding elements.
ValueTooSmall Value too small or early. The value of all ValueTooSmall Value too small or early. The value of all
or part of an element content or an or part of an element content or an
attribute, although valid, is too small. attribute, although valid, is too small.
The Name attribute refers to the The ErrorLocation elements might refer to
corresponding attribute or element name. the corresponding attribute tags or
elements.
ValueTooLarge Value too large or in the future. The value ValueTooLarge Value too large or in the future. The value
of all or part of an element content or an of all or part of an element content or an
attribute, although valid, is too large. attribute, although valid, is too large.
The Name attribute refers to the The ErrorLocation elements might refer to
corresponding attribute or element name. the corresponding attribute tags or
elements.
ElInconsistent Element Inconsistent. Although the document ElInconsistent Element Inconsistent. Although the document
is well formed and valid, according to the is well formed and valid, according to the
rules and constraints contained in this rules and constraints contained in this
specification: specification:
o the content of an element is inconsistent o the content of an element is inconsistent
with the content of other elements or with the content of other elements or
their attributes, or their attributes, or
o the value of an attribute is inconsistent o the value of an attribute is inconsistent
with the value of one or more other with the value of one or more other
attributes. attributes.
The error description may contain further The Error Description may contain further
explanations. explanations.
The Names attribute refers to the The ErrorLocation elements might refer to
inconsistent attribute or element tags. the corresponding attribute tags or elements
that are inconsistent.
TransportError Transport Error. The connection to some TransportError Transport Error. This error code is used to
indicate that there is a problem with the
transport mechanism that is preventing the
message from being received. It is typically
associated with a "Transient Error".
The connection to some
periphery or the counterparty could not be periphery or the counterparty could not be
established, is erroneous, or has been lost. established, is erroneous, or has been lost.
The error description may contain further The Error Description may contain further
narrative explanations, e.g., "chip card narrative explanations, e.g., "chip card
does not respond", "remote account manager does not respond", "remote account manager
unreachable", "Internet connection to xyz unreachable", "Internet connection to xyz
lost", "no Internet connection available", lost", "no Internet connection available",
"no modem connected", or "serial port to "no modem connected", or "serial port to
modem used by another application". This modem used by another application". This
text should be shown to the end user. If text should be shown to the end user. If
timeout has occurred at the Consumer this timeout has occurred at the Consumer this
text should be shown and the Consumer may text should be shown and the Consumer may
decide how to proceed - alternatives are decide how to proceed - alternatives are
retry, payment transaction suspension, and retry, payment transaction suspension, and
cancellation. cancellation.
MsgBeingProc Message Being Processed. This error code is MsgBeingProc Message Being Processed. This error code is
only used with a Severity of Transient only used with a Severity of Transient
Error. It indicates that the previous Error. It indicates that the previous
message, which may be an exchange message or message, which may be an exchange message or
a request message, is being processed. a request message, is being processed and,
if no response is received by the time
indicated by the "MinRetrySecs" attribute,
then the original message should be resent.
SystemBusy System Busy. This error code is only used SystemBusy System Busy. This error code is only used
with a Severity of Transient Error. It with a Severity of Transient Error. It
indicates that the IOTP Payment Bridge or indicates that the IOTP Payment Bridge or
Existing Payment Software that received the Existing Payment Software that received the
API request is currently too busy to handle API request is currently too busy to handle
it. it. If no response is received by the time
indicated by the "MinRetrySecs" attribute,
then the original message should be resent.
The Error Description may provide further
explanations, e.g., "wallet / chip card
reader is unavailable or locked by another
payment transaction", "payment gateway is
overloaded", "unknown chip card reader", or
"unrecognized chip card inserted, change
chip card".
The Consumer's IOTP Application Core may
visualize the error description and ask the
Consumer about the continuation -
alternatives are retry, payment transaction
suspension, and cancellation.
UnknownError Unknown Error. Indicates that the UnknownError Unknown Error. Indicates that the
transaction cannot complete for some reason transaction cannot complete for some reason
that is not covered explicitly by any of the that is not covered explicitly by any of the
other errors. The Error description other errors. The Error description
attribute should be used to indicate the attribute should be used to indicate the
nature of the problem. nature of the problem.
The Names attribute might refer to some The ErrorLocation elements might refer to
attribute or element tags. the corresponding attribute tags or elements
that are inconsistent.
(*)SyntaxError Syntax Error. An (unknown) syntax error has (*)SyntaxError Syntax Error. An (unknown) syntax error has
occurred. occurred.
The Names attribute might refer to some The ErrorLocation elements might refer to
attribute or element tags. the corresponding attribute tags or elements
that are inconsistent.
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" or error code with "XmlNotValid" or
"UnknownError" before transmission to the "UnknownError" before transmission to the
counterparty. counterparty.
(*)ReqRefused Request refused. The API request is (*)ReqRefused Request refused. The API request is
(currently) refused by the IOTP Payment (currently) refused by the IOTP Payment
Bridge. The error description may provide Bridge. The error description may provide
further explanations, e.g., "wallet / chip further explanations, e.g., "wallet / chip
skipping to change at page 82, line 17 skipping to change at page 46, line 46
function(ality) has not been implemented in function(ality) has not been implemented in
the IOTP Payment Bridge. Typically, this the IOTP Payment Bridge. Typically, this
kind of error is not passed to the kind of error is not passed to the
counterparty's IOTP Application Core. counterparty's IOTP Application Core.
Otherwise, it maps to "TransportError" or Otherwise, it maps to "TransportError" or
"UnknownError". "UnknownError".
(*)BusError Business Error. The API request has been (*)BusError Business Error. The API request has been
rejected because some payment transaction rejected because some payment transaction
has an illegal payment status. has an illegal payment status.
Particularly, this error code is used to
signal any raise of payment business layered
failures.
The Names attribute may contain references The ErrorLocation elements may refer to
to payment transactions using the party's payment transactions using the party's
Payment Identifier - it defaults to the Payment Identifier - it defaults to the
current transaction or might contain the current transaction or might contain the
current payment transaction party's Payment current payment transaction party's Payment
Identifier. Particularly, this error code is Identifier - identified by the ElementRef
used to signal any raise of payment business attribute while the AttName attribute is
layer failures. fixed with "PayId".
The IOTP Application Core must inquire the The IOTP Application Core must inquire the
IOTP Payment Bridge about the actual Process IOTP Payment Bridge about the actual Process
State which actually encodes the business State which actually encodes the business
error ("Inquire Process State" or "Inquire error ("Inquire Process State").
Payment Log"). This error code is never This error code must not be
passed to the counterparty's IOTP passed to the counterparty's IOTP
Application Core. Application Core.
Table 3: Common Error Codes Table 2: Common Error Codes
The IOTP Payment Bridge may also use the error description in order The IOTP Payment Bridge may also use the error description in order
to notify the Consumer about further necessary steps for failure to notify the Consumer about further necessary steps for failure
resolution, e.g., "sorry, your payment transaction failed. resolution, e.g., "sorry, your payment transaction failed.
Unfortunately, you have been charged, please contact your issuer." Unfortunately, you have been charged, please contact your issuer."
9.2 Attributes and Elements 3.2 Attributes and Elements
The following table explains the XML attributes in alphabetical order The following table explains the XML attributes in alphabetical order
- any parenthesized number behind the attribute tag recommends the - any parenthesized number behind the attribute tag recommends the
maximal length of the attribute value in characters: maximal length of the attribute value in characters:
Attribute Description Attribute Description
Amount (11) Indicates the payment amount to be paid in Amount (11) Indicates the payment amount to be paid in
AmountFrom(11) whole and fractional units of the currency. AmountFrom(11) whole and fractional units of the currency.
AmountTo (11) For example $245.35 would be expressed AmountTo (11) For example $245.35 would be expressed
"245.35". Note that values smaller than the "245.35". Note that values smaller than the
smallest denomination are allowed. For smallest denomination are allowed. For
example one tenth of a cent would be example one tenth of a cent would be
"0.001". "0.001".
AuthenticationId An identifier specified by the AuthenticationId An identifier specified by the
authenticator which, if returned by the authenticator which, if returned by the
organization that receives the organization that receives the
authentication request, will enable the authentication request, will enable the
skipping to change at page 83, line 34 skipping to change at page 48, line 14
Values of BrandId are managed under Values of BrandId are managed under
procedure being described in the IOTP procedure being described in the IOTP
protocol specification. protocol specification.
BrandLogoNetLocn The net location which can be used to BrandLogoNetLocn The net location which can be used to
download the logo for the organization (cf. download the logo for the organization (cf.
IOTP Specification). IOTP Specification).
The content of this attribute must conform The content of this attribute must conform
to [RFC1738]. to [URL].
BrandName This contains the name of the brand, for BrandName This contains the name of the brand, for
example "MasterCard Credit". This is the example "MasterCard Credit". This is the
description of the Brand which is displayed description of the Brand which is displayed
to the consumer in the Consumer's language to the consumer in the Consumer's language
defined by "xml:lang". For example it might defined by "xml:lang". For example it might
be "American Airlines Advantage Visa". Note be "American Airlines Advantage Visa". Note
that this attribute is not used for matching that this attribute is not used for matching
against the payment instruments held by the against the payment instruments held by the
Consumer. Consumer.
BrandNarrative This optional attribute is designed to be BrandNarrative This optional attribute is
used by the Merchant to indicate some used by the Merchant to indicate some
special conditions or benefit which would special co