draft-ietf-trade-iotp-v1.0-papi-02.txt   draft-ietf-trade-iotp-v1.0-papi-03.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: March 2001 September 2000 Expires: May 2001 November 2000
Payment API for v1.0 Internet Open Trading Protocol (IOTP) Payment API for v1.0 Internet Open Trading Protocol (IOTP)
------- --- --- ---- -------- ---- ------- -------- ------ ------- --- --- ---- -------- ---- ------- -------- ------
<draft-ietf-trade-iotp-v1.0-papi-02.txt> <draft-ietf-trade-iotp-v1.0-papi-03.txt>
Status of this Memo Status of this Memo
This document is intended to become an Informational RFC and will be This document is intended to become an Informational RFC.
in full conformance with all provisions of Section 10 of RFC2026. Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>. Discussions of the TRADE working
group are archived at http://www.elistx.com/archives/ietf-trade.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. 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
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to Copyright
the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>.
Discussions of the TRADE working group are archived at Copyright (C) The Internet Society 2000.
http://www.elistx.com/archives/ietf-trade.
Abstract Abstract
The Internet Open Trading Protocol provides a data exchange format The Internet Open Trading Protocol provides a data exchange format
for trading purposes while integrating existing pure payment for trading purposes while integrating existing pure payment
protocols seamlessly. This motivates the multiple layered system protocols seamlessly. This motivates the multiple layered system
architecture which consists of at least some generic IOTP application architecture which consists of at least some generic IOTP application
core and multiple specific payment modules. core and multiple specific payment modules.
This document addresses the common interface between the IOTP This document addresses the common interface between the IOTP
skipping to change at page 2, line 22 skipping to change at page 3, line 5
Such interfaces exist at the Consumers', the Merchants' and the Such interfaces exist at the Consumers', the Merchants' and the
Payment Handlers' installations connecting the IOTP application core Payment Handlers' installations connecting the IOTP application core
and the payment software components/legacy systems. and the payment software components/legacy systems.
Intended Readership Intended Readership
Software and hardware developers, development analysts, and users of Software and hardware developers, development analysts, and users of
payment protocols. payment protocols.
Copyright
Copyright (C) The Internet Society 2000.
Table of Contents Table of Contents
Status of this Memo........................................1 Status of this Memo........................................1
Abstract...................................................1 Copyright..................................................1
Abstract...................................................2
Intended Readership........................................2 Intended Readership........................................2
Copyright..................................................2
Table of Contents..........................................3 Table of Contents..........................................3
1. Introduction............................................5 1. Introduction............................................5
1.1 General payment phases................................6 1.1 General payment phases................................6
1.2 Assumptions...........................................7 1.2 Assumptions...........................................8
2. Message Flow..........................................13 2. Message Flow..........................................13
2.1 Authentication Documentation Exchange................16 2.1 Authentication Documentation Exchange................16
2.2 Brand Compilation....................................18 2.2 Brand Compilation....................................18
2.3 Brand Selection......................................21 2.3 Brand Selection......................................22
2.4 Successful Payment...................................24 2.4 Successful Payment...................................25
2.5 Payment Inquiry......................................28 2.5 Payment Inquiry......................................29
2.6 Abnormal Transaction Processing......................30 2.6 Abnormal Transaction Processing......................30
2.6.1 Failures and Cancellations.........................30 2.6.1 Failures and Cancellations.........................31
2.6.2 Resumption.........................................32 2.6.2 Resumption.........................................32
2.7 IOTP Wallet Initialization...........................33 2.7 IOTP Wallet Initialization...........................33
2.8 Payment Software Management..........................33 2.8 Payment Software Management..........................34
3. Mutuality.............................................34 3. Mutuality.............................................34
3.1 Error Codes..........................................37 3.1 Error Codes..........................................38
3.2 Attributes and Elements..............................47 3.2 Attributes and Elements..............................48
3.3 Process States........................................59 3.3 Process States........................................60
3.3.1 Merchant............................................59 3.3.1 Merchant............................................60
3.3.2 Consumer............................................61 3.3.2 Consumer............................................62
3.3.3 Payment Handler.....................................63 3.3.3 Payment Handler.....................................64
4. Payment API Calls.....................................64 4. Payment API Calls.....................................65
4.1 Brand Compilation Related API Calls..................64 4.1 Brand Compilation Related API Calls..................65
4.1.1 Find Accepted Payment Brand........................64 4.1.1 Find Accepted Payment Brand........................65
4.1.2 Find Accepted Payment Protocol.....................65 4.1.2 Find Accepted Payment Protocol.....................66
4.1.3 Get Payment Initialization Data....................67 4.1.3 Get Payment Initialization Data....................68
4.1.4 Inquire Authentication Challenge...................69 4.1.4 Inquire Authentication Challenge...................71
4.1.5 Authenticate.......................................71 4.1.5 Authenticate.......................................72
4.1.6 Check Authentication Response......................71 4.1.6 Check Authentication Response......................73
4.2 Brand Selection Related API Calls....................73 4.2 Brand Selection Related API Calls....................74
4.2.1 Find Payment Instrument............................73 4.2.1 Find Payment Instrument............................74
4.2.2 Check Payment Possibility..........................75 4.2.2 Check Payment Possibility..........................76
4.3 Payment Transaction Related API calls................77 4.3 Payment Transaction Related API calls................78
4.3.1 Start Payment Consumer.............................77 4.3.1 Start Payment Consumer.............................78
4.3.2 Start Payment Payment Handler......................79 4.3.2 Start Payment Payment Handler......................80
4.3.3 Resume Payment Consumer............................81 4.3.3 Resume Payment Consumer............................82
4.3.4 Resume Payment Payment Handler.....................82 4.3.4 Resume Payment Payment Handler.....................83
4.3.5 Continue Process ..................................83 4.3.5 Continue Process ..................................84
4.3.6 Change Process State...............................84 4.3.6 Change Process State...............................85
4.4 General Inquiry API Calls............................86 4.4 General Inquiry API Calls............................87
4.4.1 Remove Payment Log.................................86 4.4.1 Remove Payment Log.................................87
4.4.2 Payment Instrument Inquiry.........................87 4.4.2 Payment Instrument Inquiry.........................88
4.4.3 Inquire Pending Payment............................89 4.4.3 Inquire Pending Payment............................90
4.5 Payment Related Inquiry API Calls....................89 4.5 Payment Related Inquiry API Calls....................91
4.5.1 Check Payment Receipt..............................90 4.5.1 Check Payment Receipt..............................91
4.5.2 Expand Payment Receipt.............................91 4.5.2 Expand Payment Receipt.............................92
4.5.3 Inquire Process State..............................92 4.5.3 Inquire Process State..............................93
4.5.4 Start Payment Inquiry..............................94 4.5.4 Start Payment Inquiry..............................95
4.5.5 Inquire Payment Status.............................94 4.5.5 Inquire Payment Status.............................95
4.6 Other API Calls......................................95 4.6 Other API Calls......................................96
4.6.1 Manage Payment Software............................95 4.6.1 Manage Payment Software............................97
5. Call Back Function.....................................97 5. Call Back Function.....................................98
6. Security Consideration.................................99 6. Security Consideration................................100
Full Copyright Statement.................................100 Full Copyright Statement.................................101
References...............................................100 References...............................................101
Author's Address.........................................101 Author's Addresses.......................................102
Expiration and File Name.................................102 Expiration and File Name.................................103
1. Introduction 1. Introduction
Common network technologies are based 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.
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 has been limited to the common external legacy systems), IOTP has been limited to the common external
interface over the Internet. However, some of these internal interface over the Internet. However, some of these internal
interfaces might be also standardized for better integration of IOTP interfaces might be also standardized for better integration of IOTP
aware components with of the existing infrastructure and its cost aware components with of the existing infrastructure and its cost
effective reuse. effective reuse.
The typical Payment Handlers, i.e., financial institutes or near- The typical Payment Handlers (i.e., financial institutes or near-
bank organizations, as well as Merchants require an IOTP aware bank organizations) as well as Merchants require an IOTP aware
application that easily fits into their existing financial application that easily fits into their existing financial
infrastructure. The Payment Handler might even insist on the reuse of infrastructure. The Payment Handler might even insist on the reuse of
special in-house solutions for some subtasks of the IOTP aware special in-house solutions for some subtasks of the IOTP aware
application, e.g., reflecting their cryptography modules, gateway application, e.g., reflecting their cryptography modules, gateway
interfaces, or physical environment. Therefore, their IOTP aware interfaces, or physical environment. Therefore, their IOTP aware
implementation really requires such clear internal interfaces. implementation really requires such clear internal interfaces.
More important, Consumers demand modularization and clear internal More important, Consumers demand modularization and clear internal
interfaces: Their IOTP application aims at the support of multiple interfaces: Their IOTP application aims at the support of multiple
payment methods. Consumers prefer the flexible use of different payment methods. Consumers prefer the flexible use of different
skipping to change at page 5, line 45 skipping to change at page 5, line 45
well-defined interface enables payment software developers to bolt on well-defined interface enables payment software developers to bolt on
their components to other developer's general IOTP Application Core. their components to other developer's general IOTP Application Core.
Initially, this consideration leads to the two-level layered view of Initially, this consideration leads to the two-level layered view of
the IOTP software for each role, consisting of the IOTP software for each role, consisting of
o some generic IOTP system component, the so-called IOTP application o some generic IOTP system component, the so-called IOTP application
core - providing IOTP based gateway services and generic business core - providing IOTP based gateway services and generic business
logic and logic and
o the trading roles' specific backend systems implementing the o the trading roles' specific back-end systems implementing the
specific trading transaction types' functionality. specific trading transaction types' functionality.
In order to isolate the changes on the infrastructure, the IOTP In order to isolate the changes on the infrastructure, the IOTP
trading application has been three-layered: trading application has been three-layered:
o the IOTP Application Core processes the generic parts of the IOTP o the IOTP Application Core processes the generic parts of the IOTP
transaction and holds the connection to the Internet, transaction and holds the connection to the Internet,
o the Existing Legacy System or Existing Payment Software which o the Existing Legacy System or Existing Payment Software which
processes the actual transaction type, and particular payment processes the actual transaction type, and particular payment
transaction, and transaction, and
o the IOTP Middleware or IOTP Payment Bridge which glues the other o the IOTP Middle-ware or IOTP Payment Bridge which glues the other
two possibly incompatible components. It brokers between the specific two possibly incompatible components. It brokers between the
interface of the Existing Legacy System and the standardized specific interface of the Existing Legacy System and the
interfaces of the IOTP Application Core. standardized interfaces of the IOTP Application Core.
As IOTP extends payment schemes to a trading scheme, primarily, this As IOTP extends payment schemes to a trading scheme, primarily, this
document focuses on payment modules, i.e. the interface between the document focuses on payment modules, i.e. the interface between the
IOTP Payment Bridge and the IOTP Application Core. It provides a IOTP Payment Bridge and the IOTP Application Core. It provides a
standard method for exchanging payment protocol messages between the standard method for exchanging payment protocol messages between the
parties involved in a payment. But, it does not specify any interface parties involved in a payment. But, it does not specify any interface
for order or delivery processing. for order or delivery processing.
Such a Payment Application Programmers Interface (API) must suit for Such a Payment Application Programmers Interface (API) must suit for
a broad range of payment methods: (1) software based like Credit Card a broad range of payment methods: (1) software based like Credit Card
skipping to change at page 6, line 32 skipping to change at page 6, line 32
(3) mimicries of typical and traditional payment methods like money (3) mimicries of typical and traditional payment methods like money
transfer, direct debit, deposit, withdrawal, money exchange and value transfer, direct debit, deposit, withdrawal, money exchange and value
points. It should support both payments with explicit consumer points. It should support both payments with explicit consumer
acknowledge and automatic repeated payments, which have been consumer acknowledge and automatic repeated payments, which have been consumer
approved in advance. approved in advance.
The following discussion focuses on the Consumer's point of view and The following discussion focuses on the Consumer's point of view and
uses the associated terminology. When switching to Merchants' or uses the associated terminology. When switching to Merchants' or
Delivery Handlers' IOTP aware applications, the payment related Delivery Handlers' IOTP aware applications, the payment related
components should be implicitly renamed by Existing Legacy Systems to components should be implicitly renamed by Existing Legacy Systems to
the IOTP Middleware. the IOTP Middle-ware.
The next two sub-sections describe the general payment scenario and The next two sub-sections describe the general payment scenario and
several assumptions about the coarsely sketched software components. several assumptions about the coarsely sketched software components.
Chapter 2 illustrates the payment transaction progress and message Chapter 2 illustrates the payment transaction progress and message
flow of different kinds of transaction behavior. Chapters 3 to 4 flow of different kinds of transaction behavior. Chapters 3 to 4
provide the details of the API functions and Chapter 5 elaborates the provide the details of the API functions and Chapter 5 elaborates the
call back interface. call back interface.
1.1 General payment phases 1.1 General payment phases
The following table sketches the four logical steps of many payment The following table sketches the four logical steps of many payment
schemes. The preceding agreements about the goods, payment method, schemes. The preceding agreements about the goods, payment method,
purchase amount, or delivery rules are omitted. purchase amount, or delivery rules are omitted.
Payment State Party Example Behavior Payment State Party Example Behavior
------------- ----- ----------------
Mutual Payment Handler Generation of identification Mutual Payment Handler Generation of identification
Authentication request, solvency request, or Authentication request, solvency request, or
and Init- some nonce and Init- some nonce
ialization Consumer Responses to the requests and ialization Consumer Responses to the requests and
generation of the own nonce generation of the own nonce
Authorization Payment Handler Generation of the authorization Authorization Payment Handler Generation of the authorization
request (for consumer) request (for consumer)
Consumer Agreement to payment (by Consumer Agreement to payment (by
skipping to change at page 7, line 34 skipping to change at page 7, line 40
e-money, close of the payment e-money, close of the payment
transaction transaction
Reversal On rejection (online/delayed): Reversal On rejection (online/delayed):
generation of the reversal data generation of the reversal data
Consumer Receipt of the refund Consumer Receipt of the refund
However, some payment schemes However, some payment schemes
o limit themselves to one-sided authentication, o limit themselves to one-sided authentication,
o perform offline authorization without any referral to any o perform off-line authorization without any referral to any
issuer/acquirer, issuer/acquirer,
o apply capture processing in batch mode, or o apply capture processing in batch mode, or
o do not distinguish between authorization and capture, o do not distinguish between authorization and capture,
o lack an inbound mechanism for reversals or implement a limited o lack an inbound mechanism for reversals or implement a limited
variant. variant.
This model applies not only to payments at the typical points of This model applies not only to payments at the typical points of
sales but extends to refunds, deposits, withdrawals, electronic sales but extends to refunds, deposits, withdrawals, electronic
cheques, direct debits, and money transfers. cheques, direct debits, and money transfers.
skipping to change at page 8, line 30 skipping to change at page 8, line 38
o Each Existing Payment Software may manage multiple payment o Each Existing Payment Software may manage multiple payment
schemes (e.g. SET) and the latter might be supported by multiple schemes (e.g. SET) and the latter might be supported by multiple
Existing Payment Software modules. Existing Payment Software modules.
o Each payment scheme may support multiple payment instruments o Each payment scheme may support multiple payment instruments
(e.g. particular card) or methods (e.g. Visa via SET) and the (e.g. particular card) or methods (e.g. Visa via SET) and the
latter might be shared by multiple Existing Payment Software latter might be shared by multiple Existing Payment Software
Components. Components.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant) IOTP client (consumer) <---------------> IOTP server (merchant)
( contains Internet ( containes ( contains Internet ( contains
IOTP Application Core) IOTP Application Core) 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 1: Relationship of the Components
Figure 1: Relationship of the Components
The Payment API considers the following transaction types of Baseline The Payment API considers the following transaction types of Baseline
IOTP [IOTP]: 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 authors' vision of the IOTP aware application's and its First, the authors' vision of the IOTP aware application's and its
skipping to change at page 9, line 46 skipping to change at page 10, line 4
o manages the registered IOTP Payment Bridges and provides a o manages the registered IOTP Payment Bridges and provides a
mechanism for their registration - the latter is omitted by this mechanism for their registration - the latter is omitted by this
document. document.
o assumes that any IOTP Payment Bridge is a passive component, i.e., o assumes that any IOTP Payment Bridge is a passive component, i.e.,
it strictly awaits input data and generates one response to each it strictly awaits input data and generates one response to each
request, request,
o supports the payment negotiation (Consumer: selection of the actual o supports the payment negotiation (Consumer: selection of the actual
payment instrument or method; Merchant: selection of the payment payment instrument or method; Merchant: selection of the payment
methods being offered to the Consumer) preceding the payment request, methods being offered to the Consumer) preceding the payment
request,
o requests additional payment specific support from the Existing o requests additional payment specific support from the Existing
Payment Software via the selected and registered the IOTP Payment Payment Software via the selected and registered the IOTP Payment
Bridge, Bridge,
o initializes and terminates the Existing Payment Software via the o initializes and terminates the Existing Payment Software via the
IOTP Payment Bridge, IOTP Payment Bridge,
o inquires authentication data (for subsequent request or response) o inquires authentication data (for subsequent request or response)
from the Existing Payment Software, specific authentication component from the Existing Payment Software, specific authentication
- omitted in this document - or Consumer (by a suitable user component - omitted in this document - or Consumer (by a suitable
interface), user interface),
o supervises the online transaction process and traces its progress, o supervises the online transaction process and traces its progress,
o stores the transaction data being exchanged over the IOTP wire - o stores the transaction data being exchanged over the IOTP wire -
payment scheme specific data is handled transparently, payment scheme specific data is handled transparently,
o relates each payment transaction with multiple payment parameters o relates each payment transaction with multiple payment parameters
(IOTP Transaction Identifier, Trading Protocol Options, Payment (IOTP Transaction Identifier, Trading Protocol Options, Payment
Instrument/Method, Offer Response, IOTP Payment Bridge, and Wallet Instrument/Method, Offer Response, IOTP Payment Bridge, and Wallet
Identifier, associated remote Parties). The relation might be lowered Identifier, associated remote Parties). The relation might be
to the party's Payment Identifier, IOTP Payment Bridge, Wallet lowered to the party's Payment Identifier, IOTP Payment Bridge,
Identifier, and the remote parties when the actual payment Wallet Identifier, and the remote parties when the actual payment
transaction has been successfully started. transaction has been successfully started.
o implements a payment transaction progress indicator, o implements a payment transaction progress indicator,
o enables the inquiry of pending and completed payment transactions, o enables the inquiry of pending and completed payment transactions,
o implements generic dialogs, e.g., brand selection, payment o implements generic dialogs, e.g., brand selection, payment
acknowledge, payment suspension / cancellation, receipt acknowledge, payment suspension / cancellation, receipt
visualization, basic transaction inquiry, balance inquiry, or receipt visualization, basic transaction inquiry, balance inquiry, or
validation, receipt validation,
o defers payment specific processing, supervision, validation, and o defers payment specific processing, supervision, validation, and
error resolution to the Existing Payment Software. It is expected, error resolution to the Existing Payment Software. It is expected,
that the Existing Payment Software tries to resolve many errors first that the Existing Payment Software tries to resolve many errors
by the extended exchange of Payment Exchange messages. The most first by the extended exchange of Payment Exchange messages. The
significant and visible failures arise from sudden unavailability or most significant and visible failures arise from sudden
lapses of the local or opposing payment component. unavailability or lapses of the local or opposing payment
component.
o supports the invocation of any Existing Payment Software in an o supports the invocation of any Existing Payment Software in an
interactive mode, which might be used (1) for the payment scheme interactive mode, which might be used (1) for the payment scheme
specific post-processing of a (set of) payment transactions, (2) for specific post-processing of a (set of) payment transactions, (2)
the analysis of a payment instrument, (3) for the registration of a for the analysis of a payment instrument, (3) for the registration
new payment instrument/scheme, or (4) re-configuration of a payment of a new payment instrument/scheme, or (4) re-configuration of a
instrument/scheme. payment instrument/scheme.
o exports call back functions for use by the IOTP Payment Bridge or o exports call back functions for use by the IOTP Payment Bridge or
Existing Payment Software for progress indication. Existing Payment Software for progress indication.
In addition, the IOTP Application Core In addition, the IOTP Application Core
o manages the IOTP message components and IOTP message blocks o manages the IOTP message components and IOTP message blocks
exchanged during the transaction which may be referenced and accessed exchanged during the transaction which may be referenced and
during the processing of subsequent messages, e.g., for signature accessed during the processing of subsequent messages, e.g., for
verification. In particular, it stores named Packaged Content signature verification. In particular, it stores named Packaged
elements exchanged during payments. Content elements exchanged during payments.
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 implements a message caching mechanism, o implements a message caching mechanism,
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 IOTP aware remote party and the Payment communication with both the IOTP aware remote party and the Payment
API aware local periphery, e.g., chip card (reader) may raise time- API aware local periphery, e.g., chip card (reader) may raise
outs. time-outs.
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 all of these IOTP Application Core's capabilities. have to rely on all of these IOTP Application Core's capabilities.
E.g., some Consumer's Existing Payment Software may refuse the E.g., some Consumer's Existing Payment Software may refuse the
disclosure of specific payment instruments at brand selection time disclosure of specific payment instruments at brand selection time
and may delay this selection to the "Check Payment Possibility" and may delay this selection to the "Check Payment Possibility"
invocation using its own user interface. invocation using its own user interface.
The IOTP Payment Bridge's capabilities do not only deal with actual The IOTP Payment Bridge's capabilities do not only deal with actual
payments between the Consumer and the Payment Handler but extend to payments between the Consumer and the Payment Handler but extend to
the following: the following:
o translation and (dis)assemblage of messages between the formats of o translation and (dis)assemblage of messages between the formats of
the IOTP Payment API and those of the Existing Payment Software. the IOTP Payment API and those of the Existing Payment Software.
Payment API requests and response are strictly 1-to-1 related. Payment API requests and response are strictly 1-to-1 related.
o Consumer's payment instrument selection by the means of an o Consumer's payment instrument selection by the means of an
unsecured/public export of the relationship of payment brands, unsecured/public export of the relationship of payment brands,
payment protocols, and payment instruments (identifiers). Generally, payment protocols, and payment instruments (identifiers).
this includes not just the brand (Mondex, GeldKarte, etc.) but also Generally, this includes not just the brand (Mondex, GeldKarte,
which specific instance of the instrument and currency to use (e.g. etc.) but also which specific instance of the instrument and
which specific Mondex card and which currency of all those currency to use (e.g. which specific Mondex card and which currency
available). of all those available).
However, some Existing Payment Software may defer the selection of However, some Existing Payment Software may defer the selection of
the payment instrument to the actual payment carrying-out or it may the payment instrument to the actual payment carrying-out or it may
even lack any management of payment instruments. E.g., chip card even lack any management of payment instruments. E.g., chip card
based payment methods may offer - Point of Sale like - implicit based payment methods may offer - Point of Sale like - implicit
selection of the payment instrument by simple insertion of the chip selection of the payment instrument by simple insertion of the chip
card into the chip card reader or it interrogates the inserted card card into the chip card reader or it interrogates the inserted card
and requests an acknowledge (or selection) of the detected payment and requests an acknowledge (or selection) of the detected payment
instrument(s). instrument(s).
skipping to change at page 12, line 52 skipping to change at page 13, line 13
use of specific error codes (see below). use of specific error codes (see below).
The Existing Payment Software's capabilities vary extremely. It The Existing Payment Software's capabilities vary extremely. It
o supports payment scheme specific processing, supervision, o supports payment scheme specific processing, supervision,
validation, and error resolution. It is expected, that many errors validation, and error resolution. It is expected, that many errors
are tried to be resolved first by the extended exchange of Payment are tried to be resolved first by the extended exchange of Payment
Exchange messages. Exchange messages.
o provides hints for out-of-band failure resolution on failed inbound o provides hints for out-of-band failure resolution on failed inbound
resolution - inbound resolution is invisible to the IOTP Application resolution - inbound resolution is invisible to the IOTP
Core. Application Core.
o may implement arbitrary transaction data management and inquiry o may implement arbitrary transaction data management and inquiry
mechanisms ranging from no transaction recording, last transaction mechanisms ranging from no transaction recording, last transaction
recording, chip card deferred transaction recording, simple recording, chip card deferred transaction recording, simple
transaction history to sophisticated persistent data management with transaction history to sophisticated persistent data management
flexible user inquiry capabilities. The latter is required by Payment with flexible user inquiry capabilities. The latter is required by
Handlers for easy and cost effective failure resolution. Payment Handlers for easy and cost effective failure resolution.
o implements the payment scheme specific dialog boxes. o implements the payment scheme specific dialog boxes.
Even the generic dialog boxes of the IOTP Application Core might be Even the generic dialog boxes of the IOTP Application Core might be
unsuitable: Particular (business or scheme) rules may require some unsuitable: Particular (business or scheme) rules may require some
dedicated appearance / structure / content or the dialog boxes, may dedicated appearance / structure / content or the dialog boxes, may
prohibit the unsecured export of payment instruments, or may prohibit the unsecured export of payment instruments, or may
prescribe the pass phrase input under its own control. prescribe the pass phrase input under its own control.
2. Message Flow 2. Message Flow
skipping to change at page 15, line 34 skipping to change at page 15, line 44
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.
"Call Back" provides a general interface for the visualization of "Call Back" provides a general interface for the visualization of
transaction progress by the IOTP Application Core. 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 +
Get Payment Initialization Data + Get Payment Initialization Data +
Check Payment Possibility + Check Payment Possibility +
Start Payment Consumer + Start Payment Consumer +
Start Payment Payment Handler + Start Payment Payment Handler +
skipping to change at page 16, line 46 skipping to change at page 17, line 22
Authenticatee Authenticate(Alg1, Ch1) -> IPB Authenticatee Authenticate(Alg1, Ch1) -> IPB
AuthenticateResponse(...) <- IPB AuthenticateResponse(...) <- IPB
. . . . . .
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. Response() <-IPB Check Auth. Response() <-IPB
Create and transmit Authentication Status Block Create and transmit Authentication Status Block
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 12 Authentication Message Flows
Figure 2. Authentication Message Flows
1. (Authenticator Process) None, one or multiple IOTP Payment Bridges 1. (Authenticator Process) None, one or multiple IOTP Payment Bridges
(IPB) are requested for one or multiple authentication challenge (IPB) are requested for one or multiple authentication challenge
values ("Inquire Authentication Challenge"). Each value is values ("Inquire Authentication Challenge"). Each value is
encapsulated in an IOTP Authentication Request Component. In encapsulated in an IOTP Authentication Request Component. In
addition, the IOTP Application Core may add payment scheme addition, the IOTP Application Core may add payment scheme
independent authentication methods. All of them form the final IOTP independent authentication methods. All of them form the final
Authentication Request Block, which describes the set of IOTP Authentication Request Block, which describes the set of
authentication methods being supported by the authenticator and from authentication methods being supported by the authenticator and
which the authenticatee has to choose one method. from which the Authenticatee has to choose one method.
Note that the interface of the API function is limited to the Note that the interface of the API function is limited to the
response of exactly one algorithm per call. If the IOTP Application response of exactly one algorithm per call. If the IOTP
Core provides a choice of algorithms for input, this choice should be Application Core provides a choice of algorithms for input, this
reduced successively by the returned algorithm ({Alg(i+1)*} is subset choice should be reduced successively by the returned algorithm
of {Algi*}). ({Alg(i+1)*} is subset of {Algi*}).
During the registration of new Payment Instruments, the IOTP Payment During the registration of new Payment Instruments, the IOTP
Bridge notifies the IOTP Application Core about the supported Payment Bridge notifies the IOTP Application Core about the
authentication algorithms. supported authentication algorithms.
2. On presence of an IOTP Authentication Block within the received 2. On presence of an IOTP Authentication Block within the received
IOTP message, the Authenticatee's IOTP Application Core checks IOTP message, the Authenticatee's IOTP Application Core checks
whether the IOTP transaction type in the current phase actually whether the IOTP transaction type in the current phase actually
supports the authentication process. supports the authentication process.
For each provided Authentication Request Component, the IOTP For each provided Authentication Request Component, the IOTP
Application Core analyzes the algorithms' names, the transaction Application Core analyzes the algorithms' names, the transaction
context, and optionally user preferences in order to determine the context, and optionally user preferences in order to determine the
system components which are capable to process the authentication system components which are capable to process the authentication
request items. Such system components might be the IOTP Application request items. Such system components might be the IOTP
Core itself or any of the registered IOTP Payment Bridges. Application Core itself or any of the registered IOTP Payment
Bridges.
Subsequently, the IOTP Application Core requests the responses to Subsequently, the IOTP Application Core requests the responses to
the supplied challenges from the determined system components in any the supplied challenges from the determined system components in
order. The authentication trials stop with the first successful any order. The authentication trials stop with the first
response, which is included in the IOTP Authentication Response successful response, which is included in the IOTP Authentication
Block. Response Block.
Alternatively, the IOTP Application might ask for a user selection. Alternatively, the IOTP Application might ask for a user
This might be appropriate, if two or more authentication algorithms selection. This might be appropriate, if two or more
are received that require explicit user interaction, like PIN or chip authentication algorithms are received that require explicit user
card insertion. interaction, like PIN or chip card insertion.
The Authenticatee's organizational data is requested by an IOTP The Authenticatee's organizational data is requested by an IOTP
Authentication Request Block without any content element. On failure, Authentication Request Block without any content element. On
the authentication (sequence) might be retried, or the whole failure, the authentication (sequence) might be retried, or the
transaction might be suspended or cancelled. whole 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 IOTP 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
generator of the associated authentication challenge for verification generator of the associated authentication challenge for
("Check Authentication Response"). verification ("Check Authentication Response").
On sole organizational data request, its presence is checked. On sole organizational data request, its presence is checked.
Any verification must succeed in order to proceed with the Any verification must succeed in order to proceed with the
transaction. transaction.
2.2 Brand Compilation 2.2 Brand Compilation
The following shows how the API functions are used together so that The following shows how the API functions are used together so that
the Merchant can (1) compile the Brand List Component, (2) generate the Merchant can (1) compile the Brand List Component, (2) generate
skipping to change at page 19, line 4 skipping to change at page 19, line 29
| Transmit Brand Selection Component | Transmit Brand Selection Component
Merchant On brand dependent transaction Merchant On brand dependent transaction
| Get Payment Initialization Data(Bi,Pj) -> 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 3 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
non-IOTP based visit of the Merchant Trading Role's (which subsumes any non-IOTP based visit of the Merchant Trading Role's (which
Financial Institutes) web site in order to negotiate the content of subsumes Financial Institutes) web site in order to negotiate the
the IOTP Order Component. The subsequent processing switches to the content of the IOTP Order Component. The subsequent processing
IOTP based form by the activation of the Merchant's IOTP aware switches to the IOTP based form by the activation of the
application. Merchant's IOTP aware application.
2. The IOTP Application Core inquires the IOTP level trading 2. The IOTP Application Core inquires the IOTP level trading
parameters (Consumer's shopping identifier, payment direction, parameters (Consumer's shopping identifier, payment direction,
initial currency amounts, discount rates, Merchant's and Delivery initial currency amounts, discount rates, Merchant's and Delivery
Handler's Net Locations, Non-Payment Handler's Organisational Data, Handler's Net Locations, Non-Payment Handler's Organizational
initial order information, ....). Data, initial order information, ....).
3. The registered IOTP Payment Bridges are inquired by the IOTP 3. The registered IOTP Payment Bridges are inquired by the IOTP
Application Core about the accepted payment brands ("Find Accepted Application Core about the accepted payment brands ("Find Accepted
Payment Brand"). Their responses provide most of the attribute values Payment Brand"). Their responses provide most of the attribute
for the compilation of the Brand List Component's Brand Elements. The values for the compilation of the Brand List Component's Brand
IOTP Application Core might optionally match the returned payment Elements. The IOTP Application Core might optionally match the
brands with Merchant's general preferences. returned payment brands with Merchant's general preferences.
The IOTP Application Core must provide any wallet identifiers, if The IOTP Application Core must provide any wallet identifiers, if
they are required by the IOTP Payment Bridges which signal their need they are required by the IOTP Payment Bridges which signal their
by specific error codes (see below). Any signaled error that could need by specific error codes (see below). Any signaled error that
not immediately solved by the IOTP Application Core should be logged could not immediately solved by the IOTP Application Core should
- this applies also to the subsequent API calls of this section. In be logged - this applies also to the subsequent API calls of this
this case, the IOTP Application Core creates an IOTP Error Block section. In this case, the IOTP Application Core creates an IOTP
(hard error), transmits it to the Consumer, and terminates the Error Block (hard error), transmits it to the Consumer, and
current transaction. terminates the current transaction.
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
("Find Accepted Payment Protocol"). These responses provide the protocols ("Find Accepted Payment Protocol"). These responses
remaining attribute values of the Brand Elements as well as all provide the remaining attribute values of the Brand Elements as
attribute values for the compilation of the Brand List Component's well as all attribute values for the compilation of the Brand List
Protocol Amount and Pay Protocol Elements. Furthermore, the Component's Protocol Amount and Pay Protocol Elements.
organisational data about the Payment Handler is returned. The IOTP Furthermore, the organisational data about the Payment Handler is
Application Core might optionally match the returned payment brands returned. The IOTP Application Core might optionally match the
with Merchant's general preferences. returned payment brands with Merchant's general preferences.
Alternatively, the IOTP Application Core might skip the calls of Alternatively, the IOTP Application Core might skip the calls of
"Find Accepted Payment Brands" (cf. Step 3) and issue the "Find "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
Accepted Payment Protocol" call without any Brand given on the input Accepted Payment Protocol" call without any Brand given on the
parameter list. In this case, the IOTP Payment Bridge responds on the input parameter list. In this case, the IOTP Payment Bridge
latter call with the whole set of payment schemes supported w.r.t. responds on the latter call with the whole set of payment schemes
the other input parameters. supported w.r.t. the other input parameters.
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) and 6. The IOTP Application Core compiles the Brand List Component(s) 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 (after normalization): textual matching (after normalization):
o Packaged Content Elements contained in the Brand List Component o Packaged Content Elements contained in the Brand List
(and subsequently generated Payment and Order Components) might be Component (and subsequently generated Payment and Order
payment scheme specific and might depend on each other. Components) might be payment scheme specific and might depend
on each other.
o Currently, IOTP lacks precise rules for the content of the o Currently, IOTP lacks precise rules for the content of the
Packaged Content Element. Therefore, transaction / brand / Packaged Content Element. Therefore, transaction / brand /
protocol / currency amount (in)dependent data might share the same protocol / currency amount (in)dependent data might share the
Packaged Content Element or might spread across multiple Packaged same Packaged Content Element or might spread across multiple
Content Elements. Packaged Content Elements.
o The Consumer's IOTP Application Core transparently passes the o The Consumer's IOTP Application Core transparently passes the
Packaged Content Elements to the IOTP Payment Bridges which might Packaged Content Elements to the IOTP Payment Bridges which
not be able to handle payment scheme data of other payment might not be able to handle payment scheme data of other
schemes, accurately. payment schemes, accurately.
The rules and mechanisms of how this could be accomplished are out The rules and mechanisms of how this could be accomplished are out
of the scope of this document. Furthermore, this document does not of the scope of this document. Furthermore, this document does not
define any further restriction to the IOTP specification. define any further restriction to the IOTP 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 Packaged o All payment alternatives share the attribute values and
Content Elements of the subsequently generated IOTP Payment and Packaged Content Elements of the subsequently generated IOTP
Order Components. Payment and Order Components.
o The subsequently generated data does not depend on any IOTP o The subsequently generated data does not depend on any IOTP
BrandSelInfo 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
data from the IOTP Payment Bridge ("Get Payment Initialization Data") initialization data from the IOTP Payment Bridge ("Get Payment
and compile the IOTP Offer Response Block. Initialization Data") and compile the IOTP Offer Response Block.
Optionally, the IOTP Application Core might request the current Optionally, the IOTP Application Core might request the current
process state from the IOTP Payment Bridge and add the inferred order process state from the IOTP Payment Bridge and add the inferred
status to the IOTP Offer Response Block. Alternatively, IOTP order status to the IOTP Offer Response Block. Alternatively, IOTP
Application might determine the order status on its own. Application might determine the order status on its own.
As in step 6, the rules and mechanisms of how this could be As in step 6, the rules and mechanisms of how this could be
accomplished are out of the scope of this document. accomplished are out of the scope of this document.
8. The IOTP Application Core compiles the IOTP TPO Message including 8. The IOTP Application Core compiles the IOTP TPO Message including
all compiled IOTP Blocks and transmits the message to the Consumer. all compiled IOTP Blocks and transmits the message to the
The IOTP Application Core terminates if an IOTP Offer Response Block Consumer. The IOTP Application Core terminates if an IOTP Offer
has been created. Response Block has been created.
9. The Consumer performs the Brand Selection Steps (cf. Section 2.3) 9. The Consumer performs the Brand Selection Steps (cf. Section 2.3)
and responds with a TPO Selection Block if no IOTP Offer Response and responds with a TPO Selection Block if no IOTP Offer Response
Block has been received. Otherwise, the following step is skipped. 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
data from the IOTP Payment Bridge ("Get Payment Initialization initialization data from the IOTP Payment Bridge ("Get Payment
Data"), compiles the IOTP Offer Response Block, transmits it to the Initialization Data"), compiles the IOTP Offer Response Block,
Consumer, and terminates. Like Step 7, the IOTP Application Core transmits it to the Consumer, and terminates. Like Step 7, the
might access the current process state of the IOTP Payment Bridge for IOTP Application Core might access the current process state of
the compilation of the order status. the IOTP Payment Bridge for 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.
2.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). (in a brand dependent transaction).
skipping to change at page 22, line 8 skipping to change at page 22, line 35
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 4 Brand Selection Message Flows
Figure 4. Brand Selection 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 his 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
IOTP aware application. Merchant's IOTP aware application.
2. The IOTP Application Core compiles the IOTP Trading Protocol 2. The IOTP Application Core compiles the IOTP Trading Protocol
Options Block which contains the IOTP Brand List Component(s) Options Block which contains the IOTP Brand List Component(s)
enumerating Merchant's accepted payment brands and payment protocols enumerating Merchant's accepted payment brands and payment
and initiates the Brand Selection process. protocols 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). Its IOTP Application (e.g., Java applet or external application). Its IOTP Application
Core Core
o infers the accepted payment brands, payment protocols,
o infers the accepted payment brands, payment protocols, payment payment direction, currencies, payment amounts, any
direction, currencies, payment amounts, any descriptions etc., and descriptions etc., and their relationships from the IOTP
their relationships from the IOTP message, message,
o determines the registered IOTP Payment Bridges, o determines the registered IOTP Payment Bridges,
o compiles one or multiple set of brand and protocol such that the o compiles one or multiple set of brand and protocol such that
join of all set describes exactly the set of payment alternatives the join of all set describes exactly the set of payment
being offered by the Merchant. alternatives being offered by the Merchant.
o inquires payment (protocol) support and the known payment 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
compiled set ("Find Payment Instrument"). However, some IOTP Payment compiled set ("Find Payment Instrument"). However, some IOTP
Bridges may refuse payment instrument distinction. Payment Bridges may refuse payment instrument distinction.
The payment protocol support may differ between payment instruments The payment protocol support may differ between payment
if the IOTP Payment Bridge supports payment instrument distinction. instruments if the IOTP Payment Bridge supports payment instrument
distinction.
These API calls are used to infer the payment alternatives at the These API calls are used to infer the payment alternatives at the
startup of any payment transaction (without user unfriendly explicit startup of any payment transaction (without user unfriendly
user interaction). explicit user interaction).
The IOTP Application Core must provide wallet identifiers, if they The IOTP Application Core must provide wallet identifiers, if they
are requested by the IOTP Payment Bridges which signal their need by are requested by the IOTP Payment Bridges which signal their need
specific error codes (see below). by specific error codes (see below).
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 store pass phrases identifiers. But for security reasons, it should store pass
in plain text only in runtime memory. Developers of IOTP Payment phrases in plain text only in runtime memory. Developers of IOTP
Bridges and payment software modules should provide a thin and fast Payment Bridges and payment software modules should provide a thin
implementation - without lengthy initialization processes- for this and fast implementation - without lengthy initialization
initial inquiry step. processes- for this initial inquiry step.
4. The IOTP Application Core
verifies the Consumer's payment capabilities with the Merchant's 4. The IOTP Application Core verifies the Consumer's payment
accepted payment brands and currencies, capabilities with the Merchant's 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 their independent payment brands (brand and protocol) together with
purchase parameters (payment direction, currency, amount), and their purchase parameters (payment direction, currency,
amount), and
o requests the Consumer's choice or derives it automatically from any o requests the Consumer's choice or derives it automatically
configured preferences. Any selection ties one IOTP Payment Bridge from any configured preferences. Any selection ties one IOTP
with the following payment transaction. Payment Bridge with the following payment transaction.
The handling and resolution of unavailable IOTP Payment Bridges The handling and resolution of unavailable IOTP Payment Bridges
during the inquiry in Step 3 is up to the IOTP Application Core. It during the inquiry in Step 3 is up to the IOTP Application Core.
may skip these IOTP Payment Bridges or may allow user supported
It may skip these IOTP Payment Bridges or may allow user supported
resolution. resolution.
Furthermore, it may offer the registration of new payment Furthermore, it may offer the registration of new payment
instruments when the Consumer is requested for payment instrument instruments when the Consumer is requested for payment instrument
selection. selection.
5. The IOTP Application Core interrogates the fixed IOTP Payment 5. The IOTP Application Core interrogates the fixed IOTP Payment
Bridge whether the payment might complete with success ("Check Bridge whether the payment might complete with success ("Check
Payment Possibility"). At this step, the IOTP Payment Bridge may Payment Possibility"). At this step, the IOTP Payment Bridge may
issue several signals, e.g., issue several signals, e.g.,
skipping to change at page 23, line 35 skipping to change at page 24, line 16
resolution. resolution.
Furthermore, it may offer the registration of new payment Furthermore, it may offer the registration of new payment
instruments when the Consumer is requested for payment instrument instruments when the Consumer is requested for payment instrument
selection. selection.
5. The IOTP Application Core interrogates the fixed IOTP Payment 5. The IOTP Application Core interrogates the fixed IOTP Payment
Bridge whether the payment might complete with success ("Check Bridge whether the payment might complete with success ("Check
Payment Possibility"). At this step, the IOTP Payment Bridge may Payment Possibility"). At this step, the IOTP Payment Bridge may
issue several signals, e.g., 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 (non-IOTP) remote party (e.g. issuer, server wallet) is not o (non-IOTP) remote party (e.g. issuer, server wallet) is not
available, available,
o wallet identifier or pass phrase is required, o wallet identifier or pass phrase is required,
o expired payment instrument (or certificate), insufficient funds, o expired payment instrument (or certificate), insufficient
or funds, or
o physical payment instrument unreadable. o physical payment instrument unreadable.
In any erroneous case, the user should be notified and offered In any erroneous case, the user should be notified and offered
accurate alternatives. Most probably, the user might be recommended accurate alternatives. Most probably, the user might be
recommended
o to resolve the problem, e.g. to insert another payment o to resolve the problem, e.g. to insert another payment
instrument or to verify the periphery, instrument or to verify the periphery,
o to proceed (assuming its success), o 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 for uploading an electronic purse. 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 IOTP Brand Selection Info If the check succeeds, it returns several IOTP Brand Selection
Elements. Info 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
transactions - this is omitted in the figure above. Exchange 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
the Merchant inside a TPO Selection Block if the received IOTP to the Merchant inside a TPO Selection Block if the received IOTP
message lacks the IOTP Offer Response Block. The Merchant will then message lacks the IOTP Offer Response Block. The Merchant will
respond with an IOTP Offer Response Block (following the then respond with an IOTP Offer Response Block (following the
aforementioned compilation rules). aforementioned compilation rules).
2.4 Successful Payment 2.4 Successful Payment
An example of how the functions in this document are used together An example of how the functions in this document are used together to
to effect a successful payment is illustrated in the Figure 5. effect a successful payment is illustrated in the Figure 5.
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
skipping to change at page 25, line 16 skipping to change at page 25, line 45
| 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
Request any local payment receipt Request any local payment receipt
| Inquire Process State() -> IPB | Inquire Process State() -> IPB
| Inquire Proc. State Resp.(State, [Rcp.])<- IPB | Inquire Proc. State Resp.(State, [Rcp.])<- IPB
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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 5 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 switches from communicating with the Merchant to Block, the Consumer switches from communicating with the Merchant
communicating with the Payment Handler. to communicating with the Payment Handler.
This might be a milestone requiring the renewed Consumer's agreement This might be a milestone requiring the renewed Consumer's
about the payment transaction's continuation. Particularly, this is a agreement about the payment transaction's continuation.
good moment for payment suspension (and even cancellation), which Particularly, this is a good moment for payment suspension (and
will be most probably supported by all payment schemes. Simply, even cancellation), which will be most probably supported by all
because the genuine payment legacy systems have not been involved in payment schemes. Simply, because the genuine payment legacy
the current transaction. systems have not been involved in the current transaction.
Such an agreement might be explicit per transaction or automatic Such an agreement might be explicit per transaction or automatic
based on configured preferences, e.g., early acknowledgements for based on configured preferences, e.g., early acknowledgments for
specific payment limits. specific payment limits.
It is assumed, that the transaction proceeds with minimal user It is assumed, that the transaction proceeds with minimal user
(Consumer and Payment Handler) interaction and that its progess is (Consumer and Payment Handler) interaction and that its progress
controlled by the IOTP Application Core and IOTP Payment Bridge. 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
the IOTP Payment Bridge. This request carries the whole towards 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
the IOTP Payment Bridge for subsequent consistency checks: by the IOTP Payment Bridge for subsequent consistency checks:
o payment brand and its description from the selected Brand o payment brand and its description from the selected Brand
Element of the IOTP 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
Component, and Payment Component of the IOTP Offer Response Block, List Component, and Payment Component of the IOTP Offer
Response Block,
o payment protocol from the selected IOTP Pay Protocol Element, o payment protocol from the selected IOTP Pay Protocol Element,
o order details contained in the IOTP Order Component which might o order details contained in the IOTP Order Component which
be payment scheme specific, might be payment scheme specific,
o payment scheme specific data inclusive payment protocol o payment scheme specific data inclusive payment protocol
descriptions from the IOTP Protocol Amount Element, and IOTP Pay descriptions from the IOTP Protocol Amount Element, and IOTP
Protocol Element, and Pay 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
"Payment:" from the Trading Role Data Component. as "Payment:" from the Trading Role Data Component.
Generally, the called API function redoes most checks of the "Check Generally, the called API function re-does most checks of the
Payment Possibility" call due to lack of strong dependencies between "Check Payment Possibility" call due to lack of strong
both requests: There might be a significant delay between both API dependencies between both requests: There might be a significant
requests. delay between both API requests.
The called API 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
Payment Handler's IOTP Payment Bridge. the Payment Handler's IOTP Payment Bridge.
If the fixed Existing Payment Software implements payment instrument If the fixed Existing Payment Software implements payment
selection on its own, it may request the Consumer's choice at this instrument selection on its own, it may request the Consumer's
step. 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
the "Check Payment Possibility" request to the IOTP Application Core. to the "Check Payment Possibility" request to the IOTP Application
The Consumer may decide to resolve the problem, to suspend, or to Core. The Consumer may decide to resolve the problem, to suspend,
cancel the transaction, but this function call must succeed in order or to cancel the transaction, but this function call must succeed
to proceed with the transaction. in order to proceed with the transaction.
Developers of payment modules may decide to omit payment instrument Developers of payment modules may decide to omit payment
related checks like expiration date or refunds sufficiency, if they instrument related checks like expiration date or refunds
are part of the specific payment protocol. sufficiency, if they 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
by this API function, too. It is recommended that the IOTP requested by this API function, too. It is recommended that the
Application Core stores plain text pass phrases only in runtime IOTP Application Core stores plain text pass phrases only in
memory. runtime memory.
Finally, the IOTP Application Core generates the IOTP Payment Finally, the IOTP Application Core generates the IOTP Payment
Request Block, inserts any returned payment scheme data, and submits Request Block, inserts any returned payment scheme data, and
it to the Payment Handler's system. submits 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 calling the "Start Payment Payment Handler" API function. transaction calling the "Start Payment Payment Handler" API
The payment brand, its description, payment protocol, payment function. The payment brand, its description, payment protocol,
specific data, payment direction, currency and payment amount are payment specific data, payment direction, currency and payment
determined quite similar to the Consumer's IOTP Application Core. amount are determined quite similar to the Consumer's IOTP
Furthermore, the content of the IOTP Payment Scheme Component and the Application Core. Furthermore, the content of the IOTP Payment
IOTP Brand Selection Info Elements are passed to this function. Scheme Component and the 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
payment scheme specific data. On failures, this non- interactive with payment scheme specific data. On failures, this non-
server application has to resolve any problems on its own or to give interactive server application has to resolve any problems on its
up aborting the payment transaction. However, the Consumer may own or to give up aborting the payment transaction. However, the
restart the whole payment transaction. Anyway, the payment log file Consumer may restart the whole payment transaction. Anyway, the
should reflect any trials of payments. payment log file should reflect any trials of payments.
Eventually, the Payment Handler informs the Consumer about the Eventually, the Payment Handler informs the Consumer about the
current IOTP Process State using the IOTP Payment Response or IOTP current IOTP Process State using the IOTP Payment Response or IOTP
Error Block. Error Block.
Note that the "Start Payment Payment Handler" call might return the Note that the "Start Payment Payment Handler" call might return
Continuation Status "End" such that payment processing proceeds with the Continuation Status "End" such that payment processing
Step 7. proceeds with 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
scheme specific data to the fixed IOTP Payment Bridge ("Continue payment scheme specific data to the fixed IOTP Payment Bridge
Process") which returns the next IOTP Payment Scheme Component. ("Continue Process") which returns the next IOTP Payment Scheme
Component.
This Payment Scheme Component is encapsulated in an IOTP Payment This Payment Scheme Component is encapsulated in an IOTP Payment
Exchange 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
specific data to the fixed IOTP Payment Bridge ("Continue Process") scheme specific data to the fixed IOTP Payment Bridge ("Continue
which returns the next IOTP Payment Scheme Component for Process") which returns the next IOTP Payment Scheme Component for
encapsulation and 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 payment scheme specific data. Each party (1) exchanges, carrying the payment scheme specific data. Each party
submits the embedded payment scheme specific data transparently to (1) submits the embedded payment scheme specific data
the appropriate IOTP Payment Bridge calling the "Continue Process" transparently to the appropriate IOTP Payment Bridge calling the
API function, (2) wraps the returned payment scheme specific data "Continue Process" API function, (2) wraps the returned payment
into an IOTP Payment Exchange Block, and (3) transmits this block to scheme specific data into an IOTP Payment Exchange Block, and (3)
the counter party. transmits this block to the counter party.
However, the processing of the payment scheme specific data may fail However, the processing of the payment scheme specific data may
for several reasons signaled by specific error codes which are fail for several reasons signaled by specific error codes which
transformed to IOTP Payment Response Blocks (generated by Payment are transformed to IOTP Payment Response Blocks (generated by
Handler) or IOTP Error Blocks (both parties may generate them) and Payment Handler) or IOTP Error Blocks (both parties may generate
transmitted to the counter party. them) and transmitted to the counter party.
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" on the output parameter of "Continue continuation status "End" on the output parameter of "Continue
Process" (or "Start Payment Payment Handler"). Then, the IOTP Process" (or "Start Payment Payment Handler"). Then, the IOTP
Application Core issues the "Inquire Process State" API call and Application Core issues the "Inquire Process State" API call and
verifies whether an IOTP Payment Receipt Component has been returned. verifies whether an IOTP Payment Receipt Component has been
The IOTP Application Core wraps the payment receipt, the status returned. The IOTP Application Core wraps the payment receipt, the
response, and the optional payment scheme specific data in an IOTP status response, and the optional payment scheme specific data in
Payment Response Block and transmits this block to the Consumer. an IOTP Payment Response Block and transmits this block to the
Consumer.
However, any of these API calls may fail or any response might be However, any of these API calls may fail or any response might be
incomplete (e.g., lack of payment receipt). Then, the Consumer has to incomplete (e.g., lack of payment receipt). Then, the Consumer has
be notified about the failed processing by an IOTP Error Block. to be notified about the failed processing by an IOTP Error Block.
Finally, the Payment Handler terminates the payment transaction with Finally, the Payment Handler terminates the payment transaction
the "Change Process State" API call without awaiting any further with the "Change Process State" API call without awaiting any
response from the Consumer. Further failures are not reported to the further response from the Consumer. Further failures are not
Consumer. reported to the Consumer.
Note that it might be possible that the Consumer's IOTP Payment Note that it might be possible that the Consumer's IOTP Payment
Bridge has returned the previous payment scheme specific data with Bridge has returned the previous payment scheme specific data with
the continuation status "End". Even in the absence of this knowledge the continuation status "End". Even in the absence of this
- this status is not exchanged between the Consumer and the Payment knowledge - this status is not exchanged between the Consumer and
Handler - the Payment Handler must not supply any further payment the Payment Handler - the Payment Handler must not supply any
scheme specific data. Such data will be rejected by the Consumer's further payment scheme specific data. Such data will be rejected
IOTP Payment Bridge. by the Consumer's IOTP Payment Bridge.
8. The Consumer passes the optional payment scheme specific data and 8. The Consumer passes the optional payment scheme specific data and
the payment receipt to the fixed IOTP Payment Bridge by "Continue the payment receipt to the fixed IOTP Payment Bridge by "Continue
Process" and "Check Payment Receipt" API calls. Process" and "Check Payment Receipt" API calls.
Afterwards, the IOTP Application Core issues the "Inquire Process Afterwards, the IOTP Application Core issues the "Inquire Process
State" API call and verifies whether extensions to the payment State" API call and verifies whether extensions to the payment
receipt have been returned. receipt have been returned.
Finally, the transaction is terminated by calling the "Change Finally, the transaction is terminated by calling the "Change
Process State" API function which verifies and synchronizes the Process State" API function which verifies and synchronizes the
reported payment status with the local one and signals any reported payment status with the local one and signals any
inconsistencies. Any Inconsistency and returned status text should be inconsistencies. Any Inconsistency and returned status text should
displayed to the Consumer. be displayed to the Consumer.
At this point, the payment transaction has already been closed by At this point, the payment transaction has already been closed by
the Payment Handler. Therefore, any failure has to be resolved the Payment Handler. Therefore, any failure has to be resolved
locally or out-of-band. locally or out-of-band.
2.5 Payment Inquiry 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. remote Payment Handler.
skipping to change at page 29, line 11 skipping to change at page 29, line 43
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 6 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., at transaction has been opened by the IOTP Application Core, i.e., at
any time after the initial submission of the IOTP Payment Request any time after the initial submission of the IOTP Payment Request
Block. The IOTP Application Core requests any additional specific Block. The IOTP Application Core requests any additional specific
payment scheme data from the IOTP Payment Bridge which has been fixed payment scheme data from the IOTP Payment Bridge which has been
during brand selection (cf. Section 2.3) using the "Start Payment fixed during brand selection (cf. Section 2.3) using the "Start
Inquiry" API request. Payment Inquiry" API request.
Erroneous API responses should be reported to the Consumer and valid Erroneous API responses should be reported to the Consumer and
alternatives (typically retry and cancellation) should be presented valid alternatives (typically retry and cancellation) should be
by the IOTP Application Core. presented by the IOTP Application Core.
This request might perform the complete initialization, e.g. This request might perform the complete initialization, e.g.
availability check of periphery or pass phrase supplement, and the availability check of periphery or pass phrase supplement, and the
IOTP Payment Bridge reports lack of capability quite similar to the IOTP Payment Bridge reports lack of capability quite similar to
"Check Payment Possibility" request to the IOTP Application Core. 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 payment process, they should be requested phrases anywhere during the payment process, they should be
by this API function, too. It is recommended that the IOTP requested by this API function, too. It is recommended that the
Application Core stores plain text pass phrases only in runtime IOTP Application Core stores plain text pass phrases only in
memory. runtime memory.
The IOTP Application Core encapsulates any Payment Scheme Component The IOTP Application Core encapsulates any Payment Scheme
in an IOTP Inquiry Request Block and submits the block to the Payment Component in an IOTP Inquiry Request Block and submits the block
Handler. to the Payment Handler.
2. The Payment Handler analyses the IOTP Inquire Request Block, maps 2. The Payment Handler analyses the IOTP Inquire Request Block, maps
the Transaction Identifier to payment related attributes (brand, the Transaction Identifier to payment related attributes (brand,
consumer and payment identifiers), determines the appropriate IOTP consumer and payment identifiers), determines the appropriate IOTP
Payment Bridge, and forwards the request to the this IOTP Payment Payment Bridge, and forwards the request to the this IOTP Payment
Bridge ("Inquire Payment Status"). The IOTP Application Core Bridge ("Inquire Payment Status"). The IOTP Application Core
transforms the response to an IOTP Inquiry Response Block and transforms the response to an IOTP Inquiry Response Block and
transmits it to the Consumer. 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
The IOTP Payment Bridge reports any inconsistencies as well as the change. The IOTP Payment Bridge reports any inconsistencies as
final payment status to the IOTP Application Core. well as the final payment status to the IOTP Application Core.
Any additional information that might be of interest for the Any additional information that might be of interest for the
Consumer has to be displayed by the IOTP Payment Bridge or Existing Consumer has to be displayed by the IOTP Payment Bridge or
Payment Software on their own. Existing Payment Software on their own.
2.6 Abnormal Transaction Processing 2.6 Abnormal Transaction Processing
2.6.1 Failures and Cancellations 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 IOTP Payment API has to deal with the receipt of failure Any IOTP Payment API has to deal with the receipt of failure
notifications by and failure responses. This proposal has borrowed notifications by and failure responses. This proposal has borrowed
the basic mechanisms for error reporting between the IOTP Application the basic mechanisms for error reporting between the IOTP Application
Core and the IOTP Payment Bridge from the genuine protocol: Business Core and the IOTP Payment Bridge from the genuine protocol: Business
errors are reported by Status Components within IOTP Response Blocks errors are reported by Status Components within IOTP Response Blocks
while technical errors are signaled by Error Components within IOTP while technical errors are signaled by Error Components within IOTP
Error Blocks. Error Blocks.
Cancellations are mimicked as specific business errors which might Cancellations are mimicked as specific business errors which might be
be initiated by each trading party. initiated by each trading party.
Preferring slim interfaces, this IOTP Payment API introduces one Preferring slim interfaces, this IOTP Payment API introduces one
additional Error Code value for business error indication - errors additional Error Code value for business error indication - errors
can be raised on every API call. On receipt of this value, the IOTP can be raised on every API call. On receipt of this value, the IOTP
Application Core has to infer further details by the issuance of the Application Core has to infer further details by the issuance of the
API function call "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
skipping to change at page 31, line 10 skipping to change at page 31, line 46
| Inquire P.S. Resp.(State, Receipt) <- IPB | Inquire P.S. Resp.(State, Receipt) <- IPB
Analyze local process state and try to resolve Analyze local process state and try to resolve
with optional user interaction with optional user interaction
If Process State Change needed 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 counter party's 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 counter party | message, ) and transmit it to counter party
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 7 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 IOTP Cancel Block has to be created instead of an IOTP Error that the IOTP Cancel Block has to be created instead of an IOTP Error
Block. Block.
The rules for determining the required behavior of the IOTP The rules for determining the required behavior of the IOTP
Application Core are given in the IOTP specification. Application Core are given in the IOTP specification.
Note that any payment (intermediate) termination, i.e., failures, Note that any payment (intermediate) termination, i.e., failures,
skipping to change at page 31, line 33 skipping to change at page 32, line 19
function does both status changes and consistency checking / function does both status changes and consistency checking /
synchronization. Any suspicion of inconsistency should be reported by synchronization. Any suspicion of inconsistency should be reported by
the IOTP Payment Bridge for display by the IOTP Application Core. 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 Change Process State 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 8 Error Notification from counter party
Figure 8. Error Notification from counter party
Not every failure might be visible at the IOTP layer, e.g., the Not every failure might be visible at the IOTP layer, e.g., the
processing of payment transactions might temporarily be hampered by processing of payment transactions might temporarily be hampered by
intermediate failures at the payment scheme or protocol transport intermediate failures at the payment scheme or protocol transport
layer which might be resolved by the genuine components. layer which might be resolved by the genuine components.
However, final failures or cancellations have to be reported at the However, final failures or cancellations have to be reported at the
IOTP layer. E.g., communication time-outs and heavily faulty IOTP layer. E.g., communication time-outs and heavily faulty
communication channels may disable the transaction. communication channels may disable the transaction.
skipping to change at page 32, line 10 skipping to change at page 32, line 44
counter party and local system components, like chip card readers or counter party and local system components, like chip card readers or
IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core
should notify the Consumer about the resolution alternatives, i.e., should notify the Consumer about the resolution alternatives, i.e.,
retry, suspension, and cancellation. retry, suspension, and cancellation.
2.6.2 Resumption 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 The Consumer's and Payment Handler's view of the transaction o The Consumer's and Payment Handler's view of the transaction might
might not be synchronized: Due to different time-out values the not be synchronized: Due to different time-out values the payment
payment transaction may not have been suspended by the counter transaction may not have been suspended by the counter party.
party.
Any "Resume Payment ..." API function responds with an Error Code Any "Resume Payment ..." API function responds with an Error Code
on non suspended payment transaction that signals a business on non suspended payment transaction that signals a business error.
error. Afterwards the IOTP Application Core has to issue the Afterwards the IOTP Application Core has to issue the "Inquire
"Inquire Process State" API call for further analysis of the Process State" API call for further analysis of the process state.
process state.
o One IOTP message sent by one party might not be processed o One IOTP message sent by one party might not be processed
successfully or even received by the counter party. successfully or even received by the counter party.
This needs to be handled by the genuine payment scheme. It is This needs to be handled by the genuine payment scheme. It is
expected that the IOTP Application Core will not recognize expected that the IOTP Application Core will not recognize
anything. anything.
o IOTP does not provide any specific signal for payment o IOTP does not provide any specific signal for payment resumption.
resumption. On receipt of every IOTP Payment Exchange Block, the On receipt of every IOTP Payment Exchange Block, the IOTP
IOTP Application Core has to decide whether this Block belongs to Application Core has to decide whether this Block belongs to a
a pending transaction or to a suspended transaction that should be pending transaction or to a suspended transaction that should be
resumed. The IOTP Application Core might call the "Inquire Process resumed. The IOTP Application Core might call the "Inquire Process
State" API function to update any lack of knowledge. State" API function to update any lack of knowledge.
Any "Resume Payment" API function responds with an Error Code on Any "Resume Payment" API function responds with an Error Code on
non suspended payment transaction that signals a business error. non suspended payment transaction that signals a business error.
Similar, the "Continue Process" API function should report Similar, the "Continue Process" API function should report business
business errors on non pending payment transactions. errors on non pending payment transactions.
o The payment transaction may not have been created at the Payment o The payment transaction may not have been created at the Payment
Handler (early suspension and failed data transmission). In that Handler (early suspension and failed data transmission). In that
case, the IOTP Application Core should respond with a business case, the IOTP Application Core should respond with a business
error that signals the repetition of the payment transaction (by error that signals the repetition of the payment transaction (by
the Consumer). the Consumer).
Any "Resume Payment", "Continue Process" or "Inquire Process Any "Resume Payment", "Continue Process" or "Inquire Process State"
State" API function should return with an Error Code API function should return with an Error Code "AttValIllegal" on
"AttValIllegal" on non existent payment transaction whereby the non existent payment transaction whereby the further Error
further Error Attribute "Names" denote the payment identifier. Attribute "Names" denote the payment identifier.
o The IOTP Application Core should always request fresh payment o The IOTP Application Core should always request fresh payment
scheme specific data on resumption - for synchronization purposes scheme specific data on resumption - for synchronization purposes
with the Existing Payment Software. Old data in the cache that has with the Existing Payment Software. Old data in the cache that has
not been send to the counter party should not be accessed. 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
skipping to change at page 33, line 26 skipping to change at page 34, line 12
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 or more IOTP Payment Bridges report the presence of pending 2. If one or more IOTP Payment Bridges report the presence of pending
transactions, the IOTP Application Core may try to suspend ("Change transactions, the IOTP Application Core may try to suspend
Process State") or resume (only Consumer: "Resume Payment Consumer") ("Change Process State") or resume (only Consumer: "Resume Payment
the pending transactions (on user request). Consumer") the pending transactions (on user request).
The IOTP Payment Bridge may deny the processing of any new payment The IOTP Payment Bridge may deny the processing of any new payment
transactions until the pending transactions have been processed. Such transactions until the pending transactions have been processed. Such
denials are signaled by the error code "Business Error". denials are signaled by the error code "Business Error".
2.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
skipping to change at page 36, line 6 skipping to change at page 36, line 34
Location Elements of the Error Component (cf. IOTP Specification). Location Elements of the Error Component (cf. IOTP Specification).
Attributes (cf. IOTP Specification): Attributes (cf. IOTP Specification):
xml:lang Defines the language used by attributes or xml:lang Defines the language used by attributes or
child elements within this component, unless child elements within this component, unless
overridden by an xml:lang attribute on a child overridden by an xml:lang attribute on a child
element. element.
ContentSoftwareId Contains information which identifies the ContentSoftwareId Contains information which identifies the
ssoftware that generated the content of the software that generated the content of the
element. Its purpose is to help resolve element. Its purpose is to help resolve
interoperability problems that might occur as interoperability problems that might occur as
a result of incompatibilities between messages a result of incompatibilities between messages
produced by different software. It is a single produced by different software. It is a single
text string in the language defined by text string in the language defined by
"xml:lang". It must contain, as a minimum "xml:lang". It must contain, as a minimum
problems that might occur as a result of problems that might occur as a result of
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,
skipping to change at page 38, line 44 skipping to change at page 39, line 23
implements the dialog boxes needed for error resolution. But it does implements the dialog boxes needed for error resolution. But it does
not assume, that the IOTP Payment Bridge actually relies on them. not assume, that the IOTP Payment Bridge actually relies on them.
Instead, the IOTP Payment Bridge may try resolution on its own, may Instead, the IOTP Payment Bridge may try resolution on its own, may
implement specific dialog boxes, and may signal only final failures. 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 XML encoded. 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 [IOTP]). Transaction Reference Block [IOTP]).
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
skipping to change at page 47, line 30 skipping to change at page 48, line 12
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."
3.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
skipping to change at page 55, line 41 skipping to change at page 56, line 23
xml:lang Defines the language used by the Process xml:lang Defines the language used by the Process
State Description attribute (cf. IOTP State Description attribute (cf. IOTP
Specification) Specification)
Table 3: Attributes Table 3: Attributes
The following table explains the XML elements in alphabetical The following table explains the XML elements in alphabetical
order: order:
Element Description Element Description
------- -----------
Algorithm This contains information which describes Algorithm This contains information which describes
an Algorithm that may be used to generate an Algorithm that may be used to generate
the Authentication response. the Authentication response.
The algorithm that may be used is The algorithm that may be used is
identified by the Name attribute (cf. IOTP identified by the Name attribute (cf. IOTP
Specification). Specification).
AuthReqPackagedContent The Authentication Request Packaged AuthReqPackagedContent The Authentication Request Packaged
skipping to change at page 56, line 34 skipping to change at page 57, line 17
the supplement for a payment protocol. the supplement for a payment protocol.
BrandPackagedContent Container for further payment brand BrandPackagedContent Container for further payment brand
description. Its content originates from description. Its content originates from
a Brand Element content whose outermost a Brand Element content whose outermost
element tags are prefixed with "Brand". element tags are prefixed with "Brand".
Its declaration coincides with the Its declaration coincides with the
Packaged Content's declaration (cf. IOTP Packaged Content's declaration (cf. IOTP
Specification). Specification).
BrandSelBrandInfoPacka This contains any additional data that BrandSelBrandInfoPackagedContent
gedContent may be required by a particular payment This contains any additional data that
may be required by a particular payment
brand. It forms the content of the Brand brand. It forms the content of the Brand
Selection Brand Info Element. Selection Brand Info Element.
BrandSelProtocolAmount This contains any additional data that BrandSelProtocolAmountInfoPackagedContent
InfoPackagedContent may be required by a particular payment This contains any additional data that
may be required by a particular payment
brand in the format. It forms the content brand in the format. It forms the content
of the Brand Selection Protocol Amount of the Brand Selection Protocol Amount
Info Element. Info Element.
BrandSelCurrencyAmount This contains any additional data that BrandSelCurrencyAmountInfoPackagedContent
InfoPackagedContent payment brand and currency specific in This contains any additional data that
payment brand and currency specific in
the format. It forms the content of the the format. It forms the content of the
Brand Selection Currency Amount Info Brand Selection Currency Amount Info
Element. Element.
MerchantData Any merchant related data that might be MerchantData Any merchant related data that might be
used by the IOTP Payment Bridge for used by the IOTP Payment Bridge for
different purposes, e.g., it might different purposes, e.g., it might
contain access keys to some mall keys. contain access keys to some mall keys.
Its declaration coincides with the Its declaration coincides with the
Packaged Content's declaration (cf. IOTP Packaged Content's declaration (cf. IOTP
Specification). Specification).
PackagedContent Generic Container for non-IOTP data (cf. PackagedContent Generic Container for non-IOTP data (cf.
IOTP Specification). IOTP Specification).
PayProtocolPackaged The Pay Protocol Packaged Content PayProtocolPackagedContent
Content originates from a Pay Protocol The Pay Protocol Packaged Content
originates from a Pay Protocol
Element's content whereby the outermost Element's content whereby the outermost
element tags are prefixed with element tags are prefixed with
"PayProtocol". It contains information "PayProtocol". It contains information
about the protocol which is used by about the protocol which is used by
the payment protocol. The content of the payment protocol. The content of
this information is defined in the this information is defined in the
supplement for a payment protocol.Its supplement for a payment protocol.Its
declaration coincides with the Packaged declaration coincides with the Packaged
Content's declaration (cf. IOTP Content's declaration (cf. IOTP
Specification). Specification).
PaySchemePackagedConte The PayScheme Packaged Content originates PaySchemePackagedContent
nt from a Payment Scheme Component's content The PayScheme Packaged Content originates
from a Payment Scheme Component's content
whereby the outermost element tags are whereby the outermost element tags are
prefixed with "PayScheme". Its prefixed with "PayScheme". Its
declaration coincides with the Packaged declaration coincides with the Packaged
Content's declaration (cf. IOTP Content's declaration (cf. IOTP
Specification). It carries the payment Specification). It carries the payment
specific data. The content of this specific data. The content of this
information is defined in the supplement information is defined in the supplement
for a payment protocol. for a payment protocol.
ProtocolAmountPackaged The Protocol Amount Packaged Content ProtocolAmountPackagedContent
Content originates from a Protocol Amount The Protocol Amount Packaged Content
originates from a Protocol Amount
Element's content whereby the outermost Element's content whereby the outermost
element tags are prefixed with "Amount". element tags are prefixed with "Amount".
Its declaration coincides with the Its declaration coincides with the
Packaged Content's declaration (cf. IOTP Packaged Content's declaration (cf. IOTP
Specification). It contains information Specification). It contains information
about the protocol which is used by the about the protocol which is used by the
payment protocol. The content of this payment protocol. The content of this
information is defined in the supplement information is defined in the supplement
for a payment protocol. for a payment protocol.
ProtocolBrandPackagedC The Protocol Brand Packaged Content ProtocolBrandPackagedContent
ontent originates from a Protocol Brand The Protocol Brand Packaged Content
originates from a Protocol Brand
Element's content whereby the outermost Element's content whereby the outermost
element tags are prefixed with element tags are prefixed with
"ProtocolBrand". Its declaration "ProtocolBrand". Its declaration
coincides with the Packaged Content's coincides with the Packaged Content's
declaration (cf. IOTP Specification). It declaration (cf. IOTP Specification). It
contains information about the brand contains information about the brand
which might be used by the payment which might be used by the payment
protocol. The content of this information protocol. The content of this information
is defined in the supplement for a is defined in the supplement for a
payment protocol. payment protocol.
ResponsePackagedConten Container for authentication response ResponsePackagedContent
t data. Its content originates from a Container for authentication response
data. Its content originates from a
Authentication Response Component's Authentication Response Component's
Packaged Content whose outermost element Packaged Content whose outermost element
tags are prefixed with "Response". Its tags are prefixed with "Response". Its
declaration coincides with the Packaged declaration coincides with the Packaged
Content's declaration (cf. IOTP Content's declaration (cf. IOTP
Specification). Specification).
TradingRoleDataPackage The TradingRoleData Packaged Content TradingRoleDataPackagedContent
dContent originates from a TradingRoleData The TradingRoleData Packaged Content
originates from a TradingRoleData
Component's content whereby the outermost Component's content whereby the outermost
element tags are prefixed with element tags are prefixed with
"TradingRoleData". Its declaration "TradingRoleData". Its declaration
coincides with the Packaged Content's coincides with the Packaged Content's
declaration (cf. IOTP Specification). It declaration (cf. IOTP Specification). It
contains information from Merchant to contains information from Merchant to
Payment Handler via Consumer about the Payment Handler via Consumer about the
protocol which is used by the payment. protocol which is used by the payment.
The content of this information is The content of this information is
defined in the supplement for a payment defined in the supplement for a payment
skipping to change at page 58, line 43 skipping to change at page 59, line 35
packaged contents must include prefix as packaged contents must include prefix as
"Payment:" to indicate that the payment "Payment:" to indicate that the payment
bridge processes this, for example bridge processes this, for example
"Payment:SET-OD" "Payment:SET-OD"
The element's declaration coincides with The element's declaration coincides with
the Packaged Content's declaration (cf. the Packaged Content's declaration (cf.
IOTP Specification). IOTP Specification).
Table 4: Elements Table 4: Elements
XML definition: <!ENTITY % AuthReqPackagedContent XML definition:
"PackagedContent"> <!ENTITY % AuthResPackagedContent
"PackagedContent"> <!ENTITY % AuthReqPackagedContent "PackagedContent"> <!ENTITY %
AuthResPackagedContent "PackagedContent">
<!ENTITY % BrandPackagedContent "PackagedContent"> <!ENTITY % <!ENTITY % BrandPackagedContent "PackagedContent"> <!ENTITY %
BrandSelInfoPackagedContent "PackagedContent"> <!ENTITY % BrandSelInfoPackagedContent "PackagedContent"> <!ENTITY %
BrandSelProtocolAmountPackagedContent BrandSelProtocolAmountPackagedContent
"PackagedContent"> <!ENTITY % "PackagedContent"> <!ENTITY %
BrandSelCurrencyAmountPackagedContent BrandSelCurrencyAmountPackagedContent
"PackagedContent"> "PackagedContent">
<!ENTITY % ProtocolAmountPackagedContent <!ENTITY % ProtocolAmountPackagedContent
"PackagedContent"> <!ENTITY % "PackagedContent"> <!ENTITY %
PayProtocolPackagedContent "PackagedContent"> PayProtocolPackagedContent "PackagedContent">
<!ENTITY % TradingRoleDataPackagedContent "PackagedContent"> <!ENTITY % TradingRoleDataPackagedContent "PackagedContent">
<!ENTITY % MerchantData "PackagedContent"> <!ENTITY % MerchantData "PackagedContent">
<!ENTITY % PaySchemePackagedContent "PackagedContent"> <!ENTITY % PaySchemePackagedContent "PackagedContent">
3.3 Process States 3.3 Process States
The IOTP Payment API supports six different attribute values that The IOTP Payment API supports six different attribute values that
encode the transaction status from the IOTP's point of view, i.e. the encode the transaction status from the IOTP's point of view, i.e. the
appropriate point of view at the interface between the IOTP appropriate point of view at the interface between the IOTP
Application Core and IOTP Payment Bridge. This point of view does not Application Core and IOTP Payment Bridge. This point of view does not
completely mimic the more detailed view on the actual payment by the completely mimic the more detailed view on the actual payment by the
genuine Existing Payment Software or IOTP Payment Bridge. genuine Existing Payment Software or IOTP Payment Bridge.
The following three tables distinguish between the Merchant's, The following three tables distinguish between the Merchant's,
Consumer's, and Payment Handlers' environment. They extend the Consumer's, and Payment Handlers' environment. They extend the
aforementioned explanations towards the mapping between IOTP process aforementioned explanations towards the mapping between IOTP process
skipping to change at page 59, line 35 skipping to change at page 60, line 28
states and the internal payment scheme related states of the Existing states and the internal payment scheme related states of the Existing
Payment Software/IOTP Payment Bridge. Payment Software/IOTP Payment Bridge.
3.3.1 Merchant 3.3.1 Merchant
The Merchant's point of view of payment is limited to the local The Merchant's point of view of payment is limited to the local
payment initiation being interlaced with order processing because payment initiation being interlaced with order processing because
IOTP assigns the actual payment processing to the Payment Handler. IOTP assigns the actual payment processing to the Payment Handler.
ProcessState Description ProcessState Description
------------ -----------
NotYetStarted The Payment Transaction exists within the NotYetStarted The Payment Transaction exists within the
IOTP Application Core, i.e., the IOTP Application Core, i.e., the
Merchant's shop has already signaled to Merchant's shop has already signaled to
the IOTP Application Core that an IOTP the IOTP Application Core that an IOTP
transaction has been initiated by the transaction has been initiated by the
Consumer. Consumer.
However, neither any API call has been However, neither any API call has been
issued to the IOTP Payment Bridge nor the issued to the IOTP Payment Bridge nor the
IOTP Order Request has been created. IOTP Order Request has been created.
skipping to change at page 61, line 49 skipping to change at page 62, line 43
transaction has been neither started nor transaction has been neither started nor
initiated. initiated.
Table 5: Merchant Table 5: Merchant
3.3.2 Consumer 3.3.2 Consumer
The Consumer's IOTP Application Core restricts its point of view to The Consumer's IOTP Application Core restricts its point of view to
the payment transaction. It is assumed that the IOTP Payment Bridge the payment transaction. It is assumed that the IOTP Payment Bridge
handles the preceding brand selection process in a stateless manner. handles the preceding brand selection process in a stateless manner.
ProcessState Description
------------ -----------
NotYetStarted This encodes the initial process state of NotYetStarted This encodes the initial process state of
any IOTP payment transaction. This value any IOTP payment transaction. This value
is set during brand selection but it will is set during brand selection but it will
not change during the whole brand not change during the whole brand
selection process, normally. selection process, normally.
InProgress With the issuance of the Start Payment InProgress With the issuance of the Start Payment
Consumer API call, the IOTP Application Consumer API call, the IOTP Application
Core changes the process state to this Core changes the process state to this
value. value.
skipping to change at page 63, line 15 skipping to change at page 64, line 13
Table 6: Consumer Table 6: Consumer
3.3.3 Payment Handler 3.3.3 Payment Handler
The Payment Handler is responsible for the actual payment processing. The Payment Handler is responsible for the actual payment processing.
New payment transactions are reported by the Consumer with the New payment transactions are reported by the Consumer with the
transmission of new IOTP Payment Request Blocks. IOTP Payment transmission of new IOTP Payment Request Blocks. IOTP Payment
Exchange Block are send by the Consumer for payment transaction Exchange Block are send by the Consumer for payment transaction
continuation and resumption. continuation and resumption.
ProcessState Description
------------ -----------
NotYetStarted This encodes the initial process state of NotYetStarted This encodes the initial process state of
any payment transaction. Typically, this any payment transaction. Typically, this
value will last for a short amount of value will last for a short amount of
time. time.
InProgress The IOTP Application Core changes the InProgress The IOTP Application Core changes the
process state changes to "InProgress" process state changes to "InProgress"
when the Payment Handler starts with the when the Payment Handler starts with the
actual processing of the IOTP Payment actual processing of the IOTP Payment
Request Block. Request Block.
skipping to change at page 64, line 8 skipping to change at page 65, line 7
and submitted to the Consumer. and submitted to the Consumer.
ProcessError The payment transaction, has finally ProcessError The payment transaction, has finally
failed for some (technical) reason. failed for some (technical) reason.
Note that this value encodes the payment Note that this value encodes the payment
state reported by the IOTP Payment state reported by the IOTP Payment
Bridge. It does not reflect whether some Bridge. It does not reflect whether some
IOTP Error Block has been created and IOTP Error Block has been created and
submitted to the Consumer. submitted to the Consumer.
Table 7: Consumer Table 7: Consumer
4. Payment API Calls 4. Payment API Calls
4.1 Brand Compilation Related API Calls 4.1 Brand Compilation Related API Calls
4.1.1 Find Accepted Payment Brand 4.1.1 Find Accepted Payment Brand
This API finction determines the payment brands being accepted by the This API function determines the payment brands being accepted by the
Payment Handler on behalf of the Merchant. Payment Handler on behalf of the Merchant.
Input Parameters Input Parameters
o Payment Direction - provided by the IOTP Application Core o Payment Direction - provided by the IOTP Application Core
o Currency Code and Currency - provided by the IOTP Application o Currency Code and Currency - provided by the IOTP Application
Core Core
o Payment Amount - provided by the IOTP Application Core o Payment Amount - provided by the IOTP Application Core
o Merchant Payment Identifier - Merchant's unique private o Merchant Payment Identifier - Merchant's unique private
reference to the payment transaction reference to the payment transaction
skipping to change at page 65, line 45 skipping to change at page 66, line 48
optionally the payment brands) being accepted by the Payment Handler optionally the payment brands) being accepted by the Payment Handler
on behalf of the Merchant. The function might be called in two on behalf of the Merchant. The function might be called in two
variants: variants:
o With the Brand Identifier set on the input parameter list: The o With the Brand Identifier set on the input parameter list: The
function responds with the payment protocols that fits to the function responds with the payment protocols that fits to the
submitted brand. submitted brand.
o Without any Brand Identifier - that allows the omission of the o Without any Brand Identifier - that allows the omission of the
"Find Accepted Payment Brand" API call (cf. Section 4.1.1): This "Find Accepted Payment Brand" API call (cf. Section 4.1.1): This
function responds with both the supported brand identifiers and function responds with both the supported brand identifiers and the
the payment protocols being related by the Brand Elements. payment protocols being related by the Brand Elements.
Input Parameters Input Parameters
o Brand Identifier - returned by "Find Accepted Payment Brand" o Brand Identifier - returned by "Find Accepted Payment Brand"
o Payment Direction o Payment Direction
o Currency Code and Currency o Currency Code and Currency
o Payment Amount o Payment Amount
o Merchant Payment Identifier - Merchant's unique private o Merchant Payment Identifier - Merchant's unique private
reference to the payment transaction reference to the payment transaction
o Merchant Organisation Identifier - used for distinction between o Merchant Organisation Identifier - used for distinction between
skipping to change at page 81, line 24 skipping to change at page 82, line 34
4.3.3 Resume Payment Consumer 4.3.3 Resume Payment Consumer
This API function resumes a previously suspended payment at the This API function resumes a previously suspended payment at the
Consumer side. Resumption includes the internal inquiry of the Consumer side. Resumption includes the internal inquiry of the
payment transaction data, e.g., payment amount, protocol identifier, payment transaction data, e.g., payment amount, protocol identifier,
and the whole initialization as it has been applied on the "Start and the whole initialization as it has been applied on the "Start
Payment Consumer" API request. Payment Consumer" API request.
It is up to the IOTP Application Core to decide whether an IOTP It is up to the IOTP Application Core to decide whether an IOTP
Payment equest Block or a IOTP Payment Exchange Block needs to be Payment Request Block or a IOTP Payment Exchange Block needs to be
generated. One indicator might be the receipt of a previous IOTP generated. One indicator might be the receipt of a previous IOTP
Payment Exchange Block from the Payment Handler, e.g., the knowledge Payment Exchange Block from the Payment Handler, e.g., the knowledge
of the Payment Handler Payment Identifier. of the Payment Handler Payment Identifier.
Input Parameters Input Parameters
o Consumer Payment Identifier o Consumer Payment Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o Call Back Function - used for end user notification/logging o Call Back Function - used for end user notification/logging
purposes purposes
skipping to change at page 83, line 33 skipping to change at page 84, line 47
4.3.5 Continue Process 4.3.5 Continue Process
This API function passes one specific IOTP Payment Scheme Component, This API function passes one specific IOTP Payment Scheme Component,
i.e., the encapsulated Packaged Content elements, received from the i.e., the encapsulated Packaged Content elements, received from the
counter party (e.g. Consumer) to the IOTP Payment Bridge and responds counter party (e.g. Consumer) to the IOTP Payment Bridge and responds
with the next IOTP Payment Scheme Component for submission to the with the next IOTP Payment Scheme Component for submission to the
counter party. counter party.
Input Parameters Input Parameters
o Payty's Payment Idetifier o Payty's Payment Identifier
o Process (Transaction) Type which distinguishes between Payments o Process (Transaction) Type which distinguishes between Payments
and Inquiries. and Inquiries.
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o (Payment Scheme) Packaged Content - copied from the Payment o (Payment Scheme) Packaged Content - copied from the Payment
Scheme Component of the received Payment Exchange Block or from Scheme Component of the received Payment Exchange Block or from
the Error Block. the Error Block.
Each party should set the payment identifier with the local Each party should set the payment identifier with the local
identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment identifier (Consumer: ConsumerPayId; Merchant: MerchantPayId; Payment
Handler: PaymentHandlerPayId). Handler: PaymentHandlerPayId).
skipping to change at page 89, line 22 skipping to change at page 90, line 30
State". State".
Note that the IOTP Payment Bridge has to respond without the Note that the IOTP Payment Bridge has to respond without the
supplement of any pass phrase if there exist no pending payment supplement of any pass phrase if there exist no pending payment
transaction. But if there are some pending payment transactions, the transaction. But if there are some pending payment transactions, the
IOTP Payment Bridge may refuse the immediate response and may instead IOTP Payment Bridge may refuse the immediate response and may instead
request the appropriate pass phase from the IOTP Application Core. request the appropriate pass phase from the IOTP Application Core.
Input Parameters Input Parameters
o Wallet Identifier and/or PassPhrase o Wallet Identifier and/or Passphrase
XML definition: XML definition:
<!ELEMENT InquirePendingPayment EMPTY > <!ELEMENT InquirePendingPayment EMPTY >
<!ATTLIST InquirePendingPayment <!ATTLIST InquirePendingPayment
WalletId CDATA #IMPLIED WalletId CDATA #IMPLIED
PassPhrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
o Party's Payment Identifier o Party's Payment Identifier
XML definition: XML definition:
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) > <!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<!ELEMENT PaymentId EMPTY > <!ELEMENT PaymentId EMPTY >
skipping to change at page 98, line 4 skipping to change at page 99, line 13
Its use is illustrated in the diagram below. Its use is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP Application ----calls---- IOTP Application ----calls----
| Core | | | Core | |
display | | v display | | v
to <---------- Call Back <--calls--- Payment to <---------- Call Back <--calls--- Payment
user | | Software user | | Software
---------------- ----------------
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 9 Call Back Function
Figure 9. Call Back Function
Whenever this function is called, the content of the status Whenever this function is called, the content of the status
description should be made available to the user. For example on a description should be made available to the user. For example on a
status bar, a pop up window, etc. status bar, a pop up window, etc.
A reference to the Call Back function is passed as an input parameter A reference to the Call Back function is passed as an input parameter
to the "Start Payment X" and "Resume Payment X" API function. to the "Start Payment X" and "Resume Payment X" API function.
Afterwards, this function might be called whenever the status changes Afterwards, this function might be called whenever the status changes
or progress needs to be reported. or progress needs to be reported.
skipping to change at page 99, line 34 skipping to change at page 100, line 43
appropriate steps for terminating/canceling all pending payment appropriate steps for terminating/canceling all pending payment
transactions. transactions.
Note that the "Change Process State" API function provides the second Note that the "Change Process State" API function provides the second
mechanism for such kind of notification. Therefore, the IOTP Payment mechanism for such kind of notification. Therefore, the IOTP Payment
Bridge or Existing Payment Software may ignore the details of the Bridge or Existing Payment Software may ignore the details of the
"Call Back" response. "Call Back" response.
6. Security Consideration 6. Security Consideration
[T.B.D.] The IOTP Payment APIs only supports security using pass phrase to
access to payment Wallet. These can be protected over TLS, which
provides stronger security at the transport layer, but
implementations are out the scope of this document.
See also security consideration section of [IOTP]. See also security consideration section of [IOTP].
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2000. Copyright (C) The Internet Society 2000.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
skipping to change at page 100, line 39 skipping to change at page 101, line 39
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References References
[IOTP] - Internet Open Trading Protocol Specification, Version 1.0, [IOTP] - Internet Open Trading Protocol Specification, Version 1.0,
April 2000, See RFC2801. April 2000, See RFC2801.
[IOTPBOOK] - D. Burdett, D.E. Eastlake III, and M. Goncalves, [IOTPBOOK] - D. Burdett, D.E. Eastlake III, and M. Goncalves,
Internet Open Trading Protocol, McGraw-Hill, 2000 Internet Open Trading Protocol, McGraw-Hill, 2000. ISBN 0-07-135501-
4.
[HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language [HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language
(HTML) is a simple markup language used to create hypertext documents (HTML) is a simple markup language used to create hypertext documents
that are platform independent. See RFC 1866 and the World Wide Web that are platform independent. See RFC 1866 and the World Wide Web
(W3C) consortium web site at: http://www.w3.org/MarkUp/ (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC [HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC
1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R. 1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R.
Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer
Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
skipping to change at page 101, line 21 skipping to change at page 102, line 22
Resource Locators (URL)", RFC 1738, December 1994. Resource Locators (URL)", RFC 1738, December 1994.
[SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31, [SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31,
1997 1997
Book 1: Business Description Book 1: Business Description
Book 2: Programmer's Guide Book 2: Programmer's Guide
Book 3: Formal Protocol Definition Book 3: Formal Protocol Definition
Download from: <http://www.setco.org>. Download from: <http://www.setco.org>.
[SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently [SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently
draft-ietf-trade-iotp-v1.0-set-01.txt) draft-ietf-trade-iotp-v1.0-set-02.txt)
[UTC] - Universal Time Coordinated. A method of defining time [UTC] - Universal Time Coordinated. A method of defining time
absolutely relative to Greenwich Mean Time (GMT). Typically of the absolutely relative to Greenwich Mean Time (GMT). Typically of the
form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number
of hours from GMT. See ISO DIS8601. of hours from GMT. See ISO DIS8601.
[XML] - Extensible Mark Up Language. A W3C recommendation. See [XML] - Extensible Mark Up Language (XML) 1.0 (Second Edition). A
http://www.w3.org/TR/1998/REC-xml-19980210 W3C recommendation. See http://www.w3.org/TR/1998/REC-xml
[XSLT] - Extensible Style Language Transformations 1.0, November [XSLT] - Extensible Style Language Transformations 1.0, November
1999, See http://www.w3.org/TR/xslt 1999, See http://www.w3.org/TR/xslt
[XML-NS] - Namespaces in XML Recommendation. T. Bray, D. Hollander, [XML-NS] - Namespaces in XML Recommendation. T. Bray, D. Hollander,
A. Layman. Janaury 1999. http://www.w3.org/TR/1999/REC-xml-names- A. Layman. Janaury 1999. http://www.w3.org/TR/1999/REC-xml-names
19990114
Author's Address Author's Addresses
Hans-Bernhard Beykirch and Werner Hans Hans-Bernhard Beykirch and Werner Hans
IT Development & Coordination Center for the German Savings Banks IT Development & Coordination Center for the German Savings Banks
Organization (SIZ) Organization (SIZ)
Konigswinterer Strase 553 Konigswinterer Strase 553
53227 Bonn 53227 Bonn
Germany Germany
E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de
Masaaki Hiroya and Yoshiaki Kawatsura Masaaki Hiroya and Yoshiaki Kawatsura
Hitachi, Ltd. Hitachi, Ltd.
890 Kashimada Saiwai-ku Kawasaki-shi 890 Kashimada Saiwai-ku Kawasaki-shi
Kanagawa, Japan 212-8567 Kanagawa, Japan 212-8567
E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp
Expiration and File Name Expiration and File Name
This draft expires March 2001. This draft expires May 2001.
Its file name is draft-ietf-trade-iotp-v1.0-papi-02.txt. Its file name is draft-ietf-trade-iotp-v1.0-papi-03.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/