draft-ietf-trade-iotp-v1.0-papi-06.txt   rfc3867.txt 
TRADE Working Group Werner Hans Network Working Group Y. Kawatsura
INTERNET-DRAFT Hans-Bernhard.Beykirch Request for Comments: 3867 Hitachi
SIZ Category: Informational M. Hiroya
Yoshiaki Kawatsura
Hitachi
Masaaki Hiroya
Technoinfo Service Technoinfo Service
Expires: September 2004 March 2004 H. Beykirch
Atos Origin
November 2004
Payment API for v1.0 Internet Open Trading Protocol (IOTP) Payment Application Programmers Interface (API) for v1.0
------- --- --- ---- -------- ---- ------- -------- ------ Internet Open Trading Protocol (IOTP)
<draft-ietf-trade-iotp-v1.0-papi-06.txt>
Status of this Memo Status of this Memo
This document is intended to become an Informational RFC. This memo provides information for the Internet community. It does
Distribution of this document is unlimited. Please send comments to not specify an Internet standard of any kind. Distribution of this
the TRADE working group at <ietf-trade@lists.elistx.com >, which may memo is unlimited.
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://lists.elistx.com/archives/ietf-trade.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Copyright Notice
Copyright (C) The Internet Society 2001. Copyright (C) The Internet Society (2004).
Abstract Abstract
The Internet Open Trading Protocol provides a data exchange format The Internet Open Trading Protocol (IOTP) provides a data exchange
for trading purposes while integrating existing pure payment format 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 a common interface between the IOTP This document addresses a common interface between the IOTP
application core and the payment modules, enabling the application core and the payment modules, enabling the
interoperability between these kinds of modules. Furthermore, such an interoperability between these kinds of modules. Furthermore, such
interface provides the foundations for a plug-in- mechanism in actual an interface provides the foundations for a plug-in-mechanism in
implementations of IOTP application cores. actual implementations of IOTP application cores.
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
Software and hardware developers, development analysts, and users of
payment protocols.
Table of Contents Table of Contents
Status of this Memo........................................1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
Copyright..................................................1 1.1. General payment phases . . . . . . . . . . . . . . . . . 5
1.2. Assumptions. . . . . . . . . . . . . . . . . . . . . . . 6
Abstract...................................................2 2. Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intended Readership........................................2 2.1. Authentication Documentation Exchange. . . . . . . . . . 15
2.2. Brand Compilation. . . . . . . . . . . . . . . . . . . . 17
Table of Contents..........................................3 2.3. Brand Selection. . . . . . . . . . . . . . . . . . . . . 21
1. Introduction............................................5 2.4. Successful Payment . . . . . . . . . . . . . . . . . . . 24
1.1 General payment phases................................6 2.5. Payment Inquiry. . . . . . . . . . . . . . . . . . . . . 29
1.2 Assumptions...........................................8 2.6. Abnormal Transaction Processing. . . . . . . . . . . . . 30
2. Message Flow..........................................13 2.6.1. Failures and Cancellations . . . . . . . . . . . 30
2.1 Authentication Documentation Exchange................16 2.6.2. Resumption . . . . . . . . . . . . . . . . . . . 32
2.2 Brand Compilation....................................18 2.7. IOTP Wallet Initialization . . . . . . . . . . . . . . . 33
2.3 Brand Selection......................................22 2.8. Payment Software Management. . . . . . . . . . . . . . . 34
2.4 Successful Payment...................................25 3. Mutuality. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Payment Inquiry......................................29 3.1. Error Codes. . . . . . . . . . . . . . . . . . . . . . . 38
2.6 Abnormal Transaction Processing......................30 3.2. Attributes and Elements. . . . . . . . . . . . . . . . . 48
2.6.1 Failures and Cancellations.........................31 3.3. Process States . . . . . . . . . . . . . . . . . . . . . 61
2.6.2 Resumption.........................................32 3.3.1. Merchant . . . . . . . . . . . . . . . . . . . . 61
2.7 IOTP Wallet Initialization...........................33 3.3.2. Consumer . . . . . . . . . . . . . . . . . . . . 63
2.8 Payment Software Management..........................34 3.3.3. Payment Handler. . . . . . . . . . . . . . . . . 65
3. Mutuality.............................................34 4. Payment API Calls. . . . . . . . . . . . . . . . . . . . . . . 66
3.1 Error Codes..........................................38 4.1. Brand Compilation Related API Calls. . . . . . . . . . . 66
3.2 Attributes and Elements..............................48 4.1.1. Find Accepted Payment Brand. . . . . . . . . . . 66
3.3 Process States........................................60 4.1.2. Find Accepted Payment Protocol . . . . . . . . . 68
3.3.1 Merchant............................................60 4.1.3. Get Payment Initialization Data. . . . . . . . . 70
3.3.2 Consumer............................................62 4.1.4. Inquire Authentication Challenge . . . . . . . . 72
3.3.3 Payment Handler.....................................64 4.1.5. Authenticate . . . . . . . . . . . . . . . . . . 73
4. Payment API Calls.....................................65 4.1.6. Check Authentication Response. . . . . . . . . . 74
4.1 Brand Compilation Related API Calls..................65 4.2. Brand Selection Related API Calls. . . . . . . . . . . . 76
4.1.1 Find Accepted Payment Brand........................65 4.2.1. Find Payment Instrument. . . . . . . . . . . . . 76
4.1.2 Find Accepted Payment Protocol.....................66 4.2.2. Check Payment Possibility. . . . . . . . . . . . 78
4.1.3 Get Payment Initialization Data....................68 4.3. Payment Transaction Related API calls. . . . . . . . . . 80
4.1.4 Inquire Authentication Challenge...................71 4.3.1. Start Payment Consumer . . . . . . . . . . . . . 80
4.1.5 Authenticate.......................................72 4.3.2. Start Payment Payment Handler. . . . . . . . . . 82
4.1.6 Check Authentication Response......................73 4.3.3. Resume Payment Consumer. . . . . . . . . . . . . 84
4.2 Brand Selection Related API Calls....................74 4.3.4. Resume Payment Payment Handler . . . . . . . . . 85
4.2.1 Find Payment Instrument............................74 4.3.5. Continue Process . . . . . . . . . . . . . . . . 86
4.2.2 Check Payment Possibility..........................76 4.3.6. Change Process State . . . . . . . . . . . . . . 88
4.3 Payment Transaction Related API calls................78 4.4. General Inquiry API Calls. . . . . . . . . . . . . . . . 89
4.3.1 Start Payment Consumer.............................78 4.4.1. Remove Payment Log . . . . . . . . . . . . . . . 90
4.3.2 Start Payment Payment Handler......................80 4.4.2. Payment Instrument Inquiry . . . . . . . . . . . 90
4.3.3 Resume Payment Consumer............................82 4.4.3. Inquire Pending Payment. . . . . . . . . . . . . 92
4.3.4 Resume Payment Payment Handler.....................83 4.5. Payment Related Inquiry API Calls. . . . . . . . . . . . 93
4.3.5 Continue Process...................................84 4.5.1. Check Payment Receipt. . . . . . . . . . . . . . 93
4.3.6 Change Process State...............................85 4.5.2. Expand Payment Receipt . . . . . . . . . . . . . 94
4.4 General Inquiry API Calls............................87 4.5.3. Inquire Process State. . . . . . . . . . . . . . 96
4.4.1 Remove Payment Log.................................87 4.5.4. Start Payment Inquiry. . . . . . . . . . . . . . 97
4.4.2 Payment Instrument Inquiry.........................88 4.5.5. Inquire Payment Status . . . . . . . . . . . . . 98
4.4.3 Inquire Pending Payment............................90 4.6. Other API Calls. . . . . . . . . . . . . . . . . . . . . 99
4.5 Payment Related Inquiry API Calls....................91 4.6.1. Manage Payment Software. . . . . . . . . . . . . 99
4.5.1 Check Payment Receipt..............................91 5. Call Back Function . . . . . . . . . . . . . . . . . . . . . .101
4.5.2 Expand Payment Receipt.............................92 6. Security Considerations. . . . . . . . . . . . . . . . . . . .103
4.5.3 Inquire Process State..............................93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . .103
4.5.4 Start Payment Inquiry..............................95 7.1. Normative References . . . . . . . . . . . . . . . . . .103
4.5.5 Inquire Payment Status.............................95 7.2. Informative References . . . . . . . . . . . . . . . . .104
4.6 Other API Calls......................................96 Acknowledgement. . . . . . . . . . . . . . . . . . . . . . . . . .105
4.6.1 Manage Payment Software............................97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .105
5. Call Back Function.....................................98 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .106
6. Security Consideration................................100
Full Copyright Statement.................................101
References...............................................101
Author's Addresses.......................................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. For more information on IOTP, see [IOTP] and
[IOTPBOOK].
The typical Payment Handlers (i.e., financial institutes or near- The typical Payment Handlers (i.e., financial institutes or near-bank
bank organizations) as well as Merchants require an IOTP aware organizations) as well as Merchants require an IOTP aware application
application that easily fits into their existing financial that easily fits into their existing financial infrastructure. The
infrastructure. The Payment Handler might even insist on the reuse of Payment Handler might even insist on the reuse of special in-house
special in-house solutions for some subtasks of the IOTP aware solutions for some subtasks of the IOTP aware application, e.g.,
application, e.g., reflecting their cryptography modules, gateway reflecting their cryptography modules, gateway interfaces, or
interfaces, or physical environment. Therefore, their IOTP aware physical environment. Therefore, their IOTP aware implementation
implementation really requires such clear internal interfaces. 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
seamless integrating payment methods within one trading application seamless integrating payment methods within one trading application
with nearly identical behavior and user interface. The existence of a with nearly identical behavior and user interface. The existence of
well-defined interface enables payment software developers to bolt on a well-defined interface enables payment software developers to bolt
their components to other developer's general IOTP Application Core. on 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 back-end 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 Middle-ware 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 two possibly incompatible components. It brokers between the
specific interface of the Existing Legacy System and the specific interface of the Existing Legacy System and the
standardized 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
for order or delivery processing. interface 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
SET or CyberCoin, (2) chip card based like Mondex or GeldKarte, and SET or CyberCoin, (2) chip card based like Mondex or GeldKarte, and
(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. For more information on SET, see [SET].
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 Middle-ware. 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 Section 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. Sections 3 to 4
provide the details of the API functions and Chapter 5 elaborates the provide the details of the API functions and Section 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 some nonce
ialization Consumer Responses to the requests and Initialization Consumer Responses to the requests and
generation of own nonce generation of 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
reservation of the Consumer's reservation of the Consumer's
e-money) e-money)
Payment Handler Acceptance or rejection of the Payment Handler Acceptance or rejection of the
agreement (consumer's agreement (consumer's
authorization response), authorization response),
skipping to change at page 7, line 37 skipping to change at page 6, line 5
request (for issuer/acquirer) request (for issuer/acquirer)
Consumer Is charged Consumer Is charged
Payment Handler Acceptance or rejection of the Payment Handler Acceptance or rejection of the
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 off-line 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.
1.2 Assumptions 1.2. Assumptions
In outline, the IOTP Payment Bridge processes some input sequence of In outline, the IOTP Payment Bridge processes some input sequence of
payment protocol messages being forwarded by the IOTP Application payment protocol messages being forwarded by the IOTP Application
Core. It (1) disassembles the messages, (2) maps them onto the Core. It (1) disassembles the messages, (2) maps them onto the
formats of the Existing Payment Software, (3) assembles its formats of the Existing Payment Software, (3) assembles its
responses, and (4) returns another sequence of payment protocol responses, and (4) returns another sequence of payment protocol
messages that is mostly intended for transparent transmission by the messages that is mostly intended for transparent transmission by the
IOTP Application Core to some IOTP aware remote party. Normally, this IOTP Application Core to some IOTP aware remote party. Normally,
process continues between the two parties until the Payment Handler's this process continues between the two parties until the Payment
Payment API signals the payment termination. Exceptionally, each Handler's Payment API signals the payment termination.
system component may signal failures. Exceptionally, each system component may signal failures.
The relationship between the aforementioned components is illustrated The relationship between the aforementioned components is illustrated
in the following figure. These components might be related to each in the following figure. These components might be related to each
other in a flexible n-to-m-manner: other in a flexible n-to-m-manner:
o One IOTP Application Core may manage multiple IOTP Payment o One IOTP Application Core may manage multiple IOTP Payment Bridges
Bridges and the latter might be shared between multiple IOTP and the latter might be shared between multiple IOTP Application
Application Cores. Cores.
o Each Payment Bridge may manage multiple Existing Payment o Each Payment Bridge may manage multiple Existing Payment Software
Software modules and the latter might be shared between multiple modules and the latter might be shared between multiple Payment
Payment Bridges. Bridges.
o Each Existing Payment Software may manage multiple payment o Each Existing Payment Software may manage multiple payment schemes
schemes (e.g. SET) and the latter might be supported by multiple (e.g., SET) and the latter might be supported by multiple Existing
Existing Payment Software modules. Payment Software modules. For more information on SET see [SET].
o Each payment scheme may support multiple payment instruments
(e.g. particular card) or methods (e.g. Visa via SET) and the o Each payment scheme may support multiple payment instruments
latter might be shared by multiple Existing Payment Software (e.g., particular card) or methods (e.g., Visa via SET) and the
Components. latter might be shared by multiple Existing Payment Software
Components.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP client (consumer) <---------------> IOTP server (merchant) IOTP client (consumer) <---------------> IOTP server (merchant)
( contains Internet ( contains ( 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:
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.
For more information on Baseline IOTP, see [IOTP] and [IOTPBOOK].
First, the authors' vision of the IOTP aware application's and its First, the authors' vision of the IOTP aware application's and its
main components' capabilities are clarified: On the one hand, the main components' capabilities are clarified: On the one hand, the
Payment API should be quite powerful and flexible for sufficient Payment API should be quite powerful and flexible for sufficient
connection of the generic and specific components. On the other hand, connection of the generic and specific components. On the other
the Payment API should not be overloaded with nice-to-haves being hand, the Payment API should not be overloaded with nice-to-haves
unsupported by Existing Payment Software. being unsupported by Existing Payment Software.
Despite the strong similarities on the processing of successful Despite the strong similarities on the processing of successful
payments, failure resolution and inquiry capabilities differ payments, failure resolution and inquiry capabilities differ
extremely among different payment schemes. These aspects may even extremely among different payment schemes. These aspects may even
vary between different payment instrument using the same payment vary between different payment instrument using the same payment
schemes. Additionally, the specific requirements of Consumers, schemes. Additionally, the specific requirements of Consumers,
Merchants and Payment Handlers add variance and complexity. Merchants and Payment Handlers add variance and complexity.
Therefore, it is envisioned that the IOTP Application Core provides Therefore, it is envisioned that the IOTP Application Core provides
only very basic inquiry mechanisms while complex and payment scheme only very basic inquiry mechanisms while complex and payment scheme
specific inquiries, failure analysis, and failure resolution are specific inquiries, failure analysis, and failure resolution are
fully deferred to the actual Existing Payment Software - including fully deferred to the actual Existing Payment Software - including
the user interface. the user interface.
The IOTP Application Core processes payments transparently, i.e., it The IOTP Application Core processes payments transparently, i.e., it
forwards the wrapped payment scheme specific messages to the forwards the wrapped payment scheme specific messages to the
associated IOTP Payment Bridge/Existing Payment Software. The associated IOTP Payment Bridge/Existing Payment Software. The
Existing Payment Software might even use these messages for inbound Existing Payment Software might even use these messages for inbound
failure resolution. It reports only the final payment status to the failure resolution. It reports only the final payment status to the
IOTP Application Core or some intermediate - might be also final - IOTP Application Core or some intermediate - might be also final -
status on abnormal interruption. status on abnormal interruption.
The IOTP Application Core implements the generic and payment scheme The IOTP Application Core implements the generic and payment scheme
independent part of the IOTP transaction processing and provides the independent part of the IOTP transaction processing and provides the
suitable user interface. Focusing on payment related tasks, it suitable user interface. Focusing on payment related tasks, it
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
payment instrument or method; Merchant: selection of the payment actual payment instrument or method; Merchant: selection of the
methods being offered to the Consumer) preceding the payment payment methods being offered to the Consumer) preceding the
request, 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 from the Existing Payment Software, specific authentication
component - omitted in this document - or Consumer (by a suitable component - omitted in this document - or Consumer (by a suitable
user 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 Identifier, associated remote Parties). The relation might be
lowered to the party's Payment Identifier, IOTP Payment Bridge, lowered to the party's Payment Identifier, IOTP Payment Bridge,
Wallet 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 visualization, basic transaction inquiry, balance inquiry, or
receipt 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
that the Existing Payment Software will try to resolve many errors expected, that the Existing Payment Software will try to resolve
first by the extended exchange of Payment Exchange messages. The many errors first by the extended exchange of Payment Exchange
most significant and visible failures arise from sudden messages. The most significant and visible failures arise from
unavailability or lapses of the local or opposing payment sudden unavailability or lapses of the local or opposing payment
component. 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) specific post-processing of a (set of) payment transactions, (2)
for the analysis of a payment instrument, (3) for the registration for the analysis of a payment instrument, (3) for the registration
of a new payment instrument/scheme, or (4) re-configuration of a of a new payment instrument/scheme, or (4) re-configuration of a
payment 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 exchanged during the transaction which may be referenced and
accessed during the processing of subsequent messages, e.g., for accessed during the processing of subsequent messages, e.g., for
signature verification. In particular, it stores named Packaged signature verification. In particular, it stores named Packaged
Content 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
API aware local periphery, e.g., chip card (reader) may raise Payment API aware local periphery, e.g., chip card (reader) may
time-outs. raise 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). payment protocols, and payment instruments (identifiers).
Generally, this includes not just the brand (Mondex, GeldKarte, Generally, this includes not just the brand (Mondex, GeldKarte,
etc.) but also which specific instance of the instrument and etc.) but also which specific instance of the instrument and
currency to use (e.g. which specific Mondex card and which currency currency to use (e.g., which specific Mondex card and which
of all those available). currency 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).
o payment progress checks, e.g., is there enough funds available to o payment progress checks, e.g., is there enough funds available to
carry out the purchase, or enough funds left for the refund, carry out the purchase, or enough funds left for the refund,
o IOTP Payment Receipt checks which might be performed over its o IOTP Payment Receipt checks which might be performed over its
Packaged Content or by other means. Packaged Content or by other means.
o recoding of payment scheme specific receipts into a format which o recoding of payment scheme specific receipts into a format which
can be displayed to the user or printed, can be displayed to the user or printed,
o cancellation of payment, even though it is not complete, o cancellation of payment, even though it is not complete,
o suspension and resumption of payment transactions. Two kinds of o suspension and resumption of payment transactions. Two kinds of
failures the Existing Payment Software might deal with are (1) the failures the Existing Payment Software might deal with are (1) the
time-out of the network connection and (2) lack of funds. For time-out of the network connection and (2) lack of funds. For
resolution, the IOTP Application Core may try the suspension with a resolution, the IOTP Application Core may try the suspension with
view to later possible resumption. a view to later possible resumption.
o recording the payment progress and status on a database. E.g., o recording the payment progress and status on a database. E.g.,
information about pending payments might be used to assist their information about pending payments might be used to assist their
continuation when the next payment protocol message is received. continuation when the next payment protocol message is received.
o payment transaction status inquiry, so that the inquirer - IOTP o payment transaction status inquiry, so that the inquirer - IOTP
Application Core or User - can determine the appropriate next step. Application Core or User - can determine the appropriate next
step.
o balance inquiry or transaction history, e.g. consumers may o balance inquiry or transaction history, e.g., consumers may
interrogate their chip card based payment instrument or remotely interrogate their chip card based payment instrument or remotely
administer some account in advance of a payment transaction administer some account in advance of a payment transaction
acknowledge, acknowledge,
o inquiry on abnormal interrupted payment transactions, which might o inquiry on abnormal interrupted payment transactions, which might
be used by the IOTP Application Core to resolve these pending be used by the IOTP Application Core to resolve these pending
transactions at startup (after power failure). transactions at startup (after power failure).
o payment progress indication. This could be used to inform the end o payment progress indication. This could be used to inform the end
user of details on what is happening with the payment. user of details on what is happening with the payment.
o payment method specific authentication methods. o payment method specific authentication methods.
Existing Payment Software may not provide full support of these Existing Payment Software may not provide full support of these
capabilities. E.g., some payment schemes may not support or may even capabilities. E.g., some payment schemes may not support or may even
prevent the explicit transaction cancellation at arbitrary phases of prevent the explicit transaction cancellation at arbitrary phases of
the payment process. In this case, the IOTP Payment Bridge has to the payment process. In this case, the IOTP Payment Bridge has to
implement at least skeletons that signal such lack of support by the implement at least skeletons that signal such lack of support by the
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
are tried to be resolved first by the extended exchange of Payment errors are tried to be resolved first by the extended exchange of
Exchange messages. Payment 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
resolution - inbound resolution is invisible to the IOTP inbound resolution - inbound resolution is invisible to the IOTP
Application 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 transaction history to sophisticated persistent data management
with flexible user inquiry capabilities. The latter is required by with flexible user inquiry capabilities. The latter is required
Payment Handlers for easy and cost effective failure resolution. by 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
The following lists all functions of the IOTP Payment API: The following lists all functions of the IOTP Payment API:
o Brand Compilation Related API Functions o Brand Compilation Related API Functions
"Find Accepted Payment Brand" identifies the accepted payment brands "Find Accepted Payment Brand" identifies the accepted payment brands
for any indicated currency amount. for any indicated currency amount.
"Find Accepted Payment Protocol" identifies the accepted payment "Find Accepted Payment Protocol" identifies the accepted payment
protocols for any indicated currency amount (and brand) and returns protocols for any indicated currency amount (and brand) and returns
payment scheme specific packaged content for brand selection payment scheme specific packaged content for brand selection
purposes. purposes.
This function might be used in conjunction with the aforementioned This function might be used in conjunction with the aforementioned
skipping to change at page 14, line 12 skipping to change at page 12, line 43
"Inquire Authentication Challenge" returns the payment scheme "Inquire Authentication Challenge" returns the payment scheme
specific authentication challenge value. specific authentication challenge value.
"Check Authentication Response" verifies the returned payment scheme "Check Authentication Response" verifies the returned payment scheme
specific authentication response value. specific authentication response value.
"Change Process State" is used (here only) for abnormal termination. "Change Process State" is used (here only) for abnormal termination.
(cf. Payment Processing Related API Functions). (cf. Payment Processing Related API Functions).
o Brand Selection Related API Functions o Brand Selection Related API Functions
"Find Payment Instrument" identifies which instances of a payment "Find Payment Instrument" identifies which instances of a payment
instrument of a particular payment brand are available for use in a instrument of a particular payment brand are available for use in a
payment. payment.
"Check Payment Possibility" checks whether a specific payment "Check Payment Possibility" checks whether a specific payment
instrument is able to perform a payment. instrument is able to perform a payment.
"Authenticate" forwards any payment scheme specific authentication "Authenticate" forwards any payment scheme specific authentication
data to the IOTP Payment Bridge for processing. data to the IOTP Payment Bridge for processing.
"Change Process State" is used (here only) for abnormal termination. "Change Process State" is used (here only) for abnormal termination.
(cf. Payment Processing Related API Functions). (cf. Payment Processing Related API Functions).
o Payment Processing Related API Functions o Payment Processing Related API Functions
"Start or Resume Payment Consumer/Payment Handler" initiate or resume "Start or Resume Payment Consumer/Payment Handler" initiate or resume
a payment transaction. There exist specific API functions for the two a payment transaction. There exist specific API functions for the
trading roles Consumer and Payment Handler. two trading roles Consumer and Payment Handler.
"Continue Process" forwards payment scheme specific data to the "Continue Process" forwards payment scheme specific data to the
Existing Payment Software and returns more payment scheme specific Existing Payment Software and returns more payment scheme specific
data for transmission to the counter party. data for transmission to the counter party.
"Change Process State" changes the current status of payment "Change Process State" changes the current status of payment
transactions. Typically, this call is used for termination or transactions. Typically, this call is used for termination or
suspension without success. suspension without success.
o General Inquiry API Functions o General Inquiry API Functions
"Remove Payment Log" notifies the IOTP Payment Bridge that a "Remove Payment Log" notifies the IOTP Payment Bridge that a
particular entry has been removed from the Payment Log of the IOTP particular entry has been removed from the Payment Log of the IOTP
Application Core. Application Core.
"Payment Instrument Inquiry" retrieves the properties of Payment "Payment Instrument Inquiry" retrieves the properties of Payment
Instruments. Instruments.
"Inquire Pending Payment" reports any abnormal interrupted payment "Inquire Pending Payment" reports any abnormal interrupted payment
transaction known by the IOTP Payment Bridge. transaction known by the IOTP Payment Bridge.
skipping to change at page 15, line 4 skipping to change at page 13, line 38
particular entry has been removed from the Payment Log of the IOTP particular entry has been removed from the Payment Log of the IOTP
Application Core. Application Core.
"Payment Instrument Inquiry" retrieves the properties of Payment "Payment Instrument Inquiry" retrieves the properties of Payment
Instruments. Instruments.
"Inquire Pending Payment" reports any abnormal interrupted payment "Inquire Pending Payment" reports any abnormal interrupted payment
transaction known by the IOTP Payment Bridge. transaction known by the IOTP Payment Bridge.
Payment Processing Related Inquiry API Functions Payment Processing Related Inquiry API Functions
"Check Payment Receipt" checks the consistency and validity of IOTP "Check Payment Receipt" checks the consistency and validity of IOTP
Payment Receipts, received from the Payment Handler or returned by Payment Receipts, received from the Payment Handler or returned by
"Inquire Process State" API calls. Typically, this function is called "Inquire Process State" API calls. Typically, this function is
by the Consumer during the final processing of payment transactions. called by the Consumer during the final processing of payment
Nevertheless, this check might be advantageous both for Consumers and transactions. Nevertheless, this check might be advantageous both
Payment Handlers on failure resolution. for Consumers and Payment Handlers on failure resolution.
"Expand Payment Receipt" expands the Packaged Content of IOTP Payment "Expand Payment Receipt" expands the Packaged Content of IOTP Payment
Receipts as well as payment scheme specific payment receipts into a Receipts as well as payment scheme specific payment receipts into a
form which can be used for display or printing purposes. form which can be used for display or printing purposes.
"Inquire Process State" responds with the payment state and the IOTP "Inquire Process State" responds with the payment state and the IOTP
Payment Receipt Component. Normally, this function is called by the Payment Receipt Component. Normally, this function is called by the
Payment Handler for final processing of the payment transaction. Payment Handler for final processing of the payment transaction.
"Start Payment Inquiry" prepares the remote inquiry of the payment "Start Payment Inquiry" prepares the remote inquiry of the payment
transaction status and responds with payment scheme specific data transaction status and responds with payment scheme specific data
that might be needed by the Payment Handler for the Consumer that might be needed by the Payment Handler for the Consumer
initiated inquiry processing. initiated inquiry processing.
"Inquire Payment Status" is called by the Payment Handler on Consumer "Inquire Payment Status" is called by the Payment Handler on Consumer
initiated inquiry requests. This function returns the payment scheme initiated inquiry requests. This function returns the payment scheme
specific content of the Inquiry Response Block. specific content of the Inquiry Response Block.
"Continue Process" and "Change Process State" (cf. Payment Processing "Continue Process" and "Change Process State" (cf. Payment Processing
Related API Calls) Related API Calls)
o Other API Functions o Other API Functions
"Manage Payment Software" enables the immediate activation of the "Manage Payment Software" enables the immediate activation of the
Existing Payment Software. Further user input is under control of the Existing Payment Software. Further user input is under control of
Existing Payment Software. the 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
------------ -------- --------------- -------- ------------ -------- --------------- --------
skipping to change at page 16, line 28 skipping to change at page 15, line 15
Check Authentication Response ? Check Authentication Response ?
Payment Instrument Inquiry ? Payment Instrument Inquiry ?
Inquire Pending Payment # # Inquire Pending Payment # #
Start Payment Inquiry ? Start Payment Inquiry ?
Inquire Payment Status ? Inquire Payment Status ?
Manage Payment Software # ? ? Manage Payment Software # ? ?
Call Back # Call Back #
Table 1: Requirements on API Functions by the Trading Roles Table 1: Requirements on API Functions by the Trading Roles
The next sections sketch the relationships and the dependencies The next sections sketch the relationships and the dependencies
between the API functions. They provide the informal description of between the API functions. They provide the informal description of
the progress alternatives and depict the communication and the progress alternatives and depict the communication and
synchronization between the general IOTP Application Core and the synchronization between the general IOTP Application Core and the
payment scheme specific modules. payment scheme specific modules.
2.1 Authentication Documentation Exchange 2.1. Authentication Documentation Exchange
This section describes how the functions in this document are used This section describes how the functions in this document are used
together to process authentication. together to process authentication.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Authenticator Inquire Authentication Challenge(Alg1*) -> IPB Authenticator Inquire Authentication Challenge(Alg1*) -> IPB
Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB Inq. Auth. Challenge Response(Alg1,Ch1) <- IPB
. . . . . .
Inquire Authentication Challenge(Algn*) -> IPB Inquire Authentication Challenge(Algn*) -> IPB
Inq. Auth. Challenge Response(Algn,Chn) <- IPB Inq. Auth. Challenge Response(Algn,Chn) <- IPB
skipping to change at page 17, line 27 skipping to change at page 16, line 7
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 2. 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 independent authentication methods. All of them form the final
IOTP 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 authentication methods being supported by the authenticator and
from 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 response of exactly one algorithm per call. If the IOTP
Application Core provides a choice of algorithms for input, this Application Core provides a choice of algorithms for input, this
choice should be reduced successively by the returned algorithm choice should be reduced successively by the returned algorithm
({Alg(i+1)*} is subset of {Algi*}). ({Alg(i+1)*} is subset of {Algi*}).
During the registration of new Payment Instruments, the IOTP During the registration of new Payment Instruments, the IOTP
Payment Bridge notifies the IOTP Application Core about the Payment Bridge notifies the IOTP Application Core about the
supported authentication algorithms. supported authentication algorithms.
2. On the presence of an IOTP Authentication Block within the 2. On the presence of an IOTP Authentication Block within the
received IOTP message, the Authenticatee's IOTP Application Core received IOTP message, the Authenticatee's IOTP Application Core
checks whether the IOTP transaction type in the current phase checks whether the IOTP transaction type in the current phase
actually supports the authentication process. actually 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 request items. Such system components might be the IOTP
Application Core itself or any of the registered IOTP Payment Application Core itself or any of the registered IOTP Payment
Bridges. 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 the supplied challenges from the determined system components in
any order. The authentication trials stop with the first any order. The authentication trials stop with the first
successful response, which is included in the IOTP Authentication successful response, which is included in the IOTP Authentication
Response Block. Response Block.
Alternatively, the IOTP Application might ask for a user Alternatively, the IOTP Application might ask for a user
selection. This might be appropriate, if two or more selection. This might be appropriate, if two or more
authentication algorithms are received that require explicit user authentication algorithms are received that require explicit user
interaction, like PIN or chip 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 Authentication Request Block without any content element. On
failure, the authentication (sequence) might be retried, or the failure, the authentication (sequence) might be retried, or the
whole 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 generator of the associated authentication challenge for
verification ("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
the Payment Component, and (3) adjust the Order Component with the Payment Component, and (3) adjust the Order Component with
payment scheme specific packaged content. payment scheme specific packaged content.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant For each registered IOTP Payment Bridge Merchant For each registered IOTP Payment Bridge
| Find Accepted Payment Brand() -> IPB | Find Accepted Payment Brand() -> IPB
| Find Accepted Payment Brand Response (B*) <- IPB | Find Accepted Payment Brand Response (B*) <- IPB
skipping to change at page 19, line 32 skipping to change at page 18, line 44
| 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
and indicates the payment intention. The notion shopping subsumes cart and indicates the payment intention. The notion shopping
any non-IOTP based visit of the Merchant Trading Role's (which subsumes any non-IOTP based visit of the Merchant Trading Role's
subsumes Financial Institutes) web site in order to negotiate the (which subsumes Financial Institutes) web site in order to
content of the IOTP Order Component. The subsequent processing negotiate the content of the IOTP Order Component. The
switches to the IOTP based form by the activation of the subsequent processing switches to the IOTP based form by the
Merchant's IOTP aware application. activation of the Merchant's IOTP aware application.
2. The IOTP Application Core inquires for the IOTP level trading 2. The IOTP Application Core inquires for 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 Organizational Handler's Net Locations, Non-Payment Handler's Organizational
Data, 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
Payment Brand"). Their responses provide most of the attribute Accepted Payment Brand"). Their responses provide most of the
values for the compilation of the Brand List Component's Brand attribute values for the compilation of the Brand List
Elements. The IOTP Application Core might optionally match the Component's Brand Elements. The IOTP Application Core might
returned payment brands with Merchant's general preferences. optionally match the 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 they are required by the IOTP Payment Bridges which signal their
need by specific error codes (see below). Any signaled error that need by specific error codes (see below). Any signaled error
could not be immediately solved by the IOTP Application Core that could not be immediately solved by the IOTP Application Core
should be logged - this applies also to the subsequent API calls should be logged - this applies also to the subsequent API calls
of this section. In this case, the IOTP Application Core creates of this section. In this case, the IOTP Application Core creates
an IOTP Error Block (hard error), transmits it to the Consumer, an IOTP Error Block (hard error), transmits it to the Consumer,
and terminates the current transaction. and 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 for each accepted payment brand about the supported payment
protocols ("Find Accepted Payment Protocol"). These responses protocols ("Find Accepted Payment Protocol"). These responses
provide the remaining attribute values of the Brand Elements as provide the remaining attribute values of the Brand Elements as
well as all attribute values for the compilation of the Brand List well as all attribute values for the compilation of the Brand
Component's Protocol Amount and Pay Protocol Elements. List Component's Protocol Amount and Pay Protocol Elements.
Furthermore, the organisational data about the Payment Handler is
returned. The IOTP Application Core might optionally match the
returned payment brands with Merchant's general preferences.
Alternatively, the IOTP Application Core might skip the calls of Furthermore, the organisational data about the Payment Handler is
"Find Accepted Payment Brands" (cf. Step 3) and issue the "Find returned. The IOTP Application Core might optionally match the
Accepted Payment Protocol" call without any Brand given on the returned payment brands with Merchant's general preferences.
input parameter list. In this case, the IOTP Payment Bridge
responds to the latter call with the whole set of payment schemes
supported w.r.t. the other input parameters.
5. The steps 3 and 4 are repeated during IOTP Value Exchange Alternatively, the IOTP Application Core might skip the calls of
transactions - these steps are omitted in the previous figure. "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
Accepted Payment Protocol" call without any Brand given on the
input parameter list. In this case, the IOTP Payment Bridge
responds to the latter call with the whole set of payment schemes
supported w.r.t. the other input parameters.
6. The IOTP Application Core compiles the Brand List Component(s) and 5. The steps 3 and 4 are repeated during IOTP Value Exchange
the IOTP Trading Protocol Options Block. It is recommended that transactions - these steps are omitted in the previous figure.
the "equal" items returned by IOTP Payment Bridge function calls
are shared due to the extensive linking capabilities within the
Brand List Component. However, the compilation must consider
several aspects in order to prevent conflicts - sharing detection
might be textual matching (after normalization):
o Packaged Content Elements contained in the Brand List 6. The IOTP Application Core compiles the Brand List Component(s)
Component (and subsequently generated Payment and Order and the IOTP Trading Protocol Options Block. It is recommended
Components) might be payment scheme specific and might depend that the "equal" items returned by IOTP Payment Bridge function
on each other. calls are shared due to the extensive linking capabilities within
the Brand List Component. However, the compilation must consider
several aspects in order to prevent conflicts - sharing detection
might be textual matching (after normalization):
o Currently, IOTP lacks precise rules for the content of the o Packaged Content Elements contained in the Brand List Component
Packaged Content Element. Therefore, transaction / brand / (and subsequently generated Payment and Order Components) might
protocol / currency amount (in)dependent data might share the be payment scheme specific and might depend on each other.
same Packaged Content Element or might spread across multiple
Packaged Content Elements.
o The Consumer's IOTP Application Core transparently passes the o Currently, IOTP lacks precise rules for the content of the
Packaged Content Elements to the IOTP Payment Bridges which Packaged Content Element. Therefore, transaction / brand /
might not be able to handle payment scheme data of other protocol / currency amount (in)dependent data might share the
payment schemes, accurately. same Packaged Content Element or might spread across multiple
Packaged Content Elements.
The rules and mechanisms of how this could be accomplished are out o The Consumer's IOTP Application Core transparently passes the
of the scope of this document. Furthermore, this document does not Packaged Content Elements to the IOTP Payment Bridges which
define any further restriction to the IOTP specification. might not be able to handle payment scheme data of other
payment schemes, accurately.
7. The IOTP Application Core determines whether the IOTP message can The rules and mechanisms of how this could be accomplished are
be enriched with an Offer Response Block. This is valid under the out of the scope of this document. Furthermore, this document
following conditions: does not define any further restriction to the IOTP
specification.
o All payment alternatives share the attribute values and 7. The IOTP Application Core determines whether the IOTP message can
Packaged Content Elements of the subsequently generated IOTP be enriched with an Offer Response Block. This is valid under
Payment and Order Components. the following conditions:
o The subsequently generated data does not depend on any IOTP o All payment alternatives share the attribute values and
BrandSelInfo Elements that might be reported by the consumer Packaged Content Elements of the subsequently generated IOTP
within the TPO Selection Block in the brand dependent Payment and Order Components.
variant.
If both conditions are fulfilled, the IOTP Application Core might o The subsequently generated data does not depend on any IOTP
request the remaining payment scheme specific payment BrandSelInfo Elements that might be reported by the consumer
initialization data from the IOTP Payment Bridge ("Get Payment within the TPO Selection Block in the brand dependent variant.
Initialization Data") and compile the IOTP Offer Response Block.
Optionally, the IOTP Application Core might request the current If both conditions are fulfilled, the IOTP Application Core might
process state from the IOTP Payment Bridge and add the inferred request the remaining payment scheme specific payment
order status to the IOTP Offer Response Block. Alternatively, IOTP initialization data from the IOTP Payment Bridge ("Get Payment
Application might determine the order status on its own. Initialization Data") and compile the IOTP Offer Response Block.
As in step 6, the rules and mechanisms of how this could be Optionally, the IOTP Application Core might request the current
accomplished are out of the scope of this document. process state from the IOTP Payment Bridge and add the inferred
order status to the IOTP Offer Response Block. Alternatively,
IOTP Application might determine the order status on its own.
8. The IOTP Application Core compiles the IOTP TPO Message including As in step 6, the rules and mechanisms of how this could be
all compiled IOTP Blocks and transmits the message to the accomplished are out of the scope of this document.
Consumer. The IOTP Application Core terminates if an IOTP Offer
Response Block has been created.
9. The Consumer performs the Brand Selection Steps (cf. Section 2.3) 8. The IOTP Application Core compiles the IOTP TPO Message including
and responds with a TPO Selection Block if no IOTP Offer Response all compiled IOTP Blocks and transmits the message to the
Block has been received. Otherwise, the following step is skipped. Consumer. The IOTP Application Core terminates if an IOTP Offer
Response Block has been created.
9. The Consumer performs the Brand Selection Steps (cf. Section 2.3)
and responds with a TPO Selection Block if no IOTP Offer Response
Block has been received. Otherwise, the following step is
skipped.
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 requests the remaining payment scheme specific payment
initialization data from the IOTP Payment Bridge ("Get Payment initialization data from the IOTP Payment Bridge ("Get Payment
Initialization Data"), compiles the IOTP Offer Response Block, Initialization Data"), compiles the IOTP Offer Response Block,
transmits it to the Consumer, and terminates. Like Step 7, the transmits it to the Consumer, and terminates. Like Step 7, the
IOTP Application Core might access the current process state of IOTP Application Core might access the current process state of
the IOTP Payment Bridge for 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).
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Merchant generates Brand List(s) containing Merchant Merchant generates Brand List(s) containing
Brands, Payment Protocols and Currency Amounts Brands, Payment Protocols and Currency Amounts
On brand independent transactions On brand independent transactions
skipping to change at page 22, line 35 skipping to change at page 22, line 4
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 switches to the IOTP based form by the activation of the
Merchant's 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 enumerating Merchant's accepted payment brands and payment
protocols 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,
payment direction, currencies, payment amounts, any
descriptions etc., and their relationships from the IOTP
message,
o determines the registered IOTP Payment Bridges, o infers the accepted payment brands, payment protocols, payment
direction, currencies, payment amounts, any descriptions etc.,
and their relationships from the IOTP message,
o compiles one or multiple sets of brand and protocol such that o determines the registered IOTP Payment Bridges,
the join of all sets describes exactly the payment
alternatives being offered by the Merchant.
o inquires payment (protocol) support and the known payment o compiles one or multiple sets of brand and protocol such that
instruments from each registered IOTP Payment Bridge for each the join of all sets describes exactly the payment alternatives
compiled set ("Find Payment Instrument"). However, some IOTP being offered by the Merchant.
Payment Bridges may refuse payment instrument distinction.
o inquires payment (protocol) support and the known payment
instruments from each registered IOTP Payment Bridge for each
compiled set ("Find Payment Instrument"). However, some IOTP
Payment Bridges may refuse payment instrument distinction.
The payment protocol support may differ between payment The payment protocol support may differ between payment
instruments if the IOTP Payment Bridge supports payment instrument instruments if the IOTP Payment Bridge supports payment instrument
distinction. 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 startup of any payment transaction (without user unfriendly
explicit 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 are requested by the IOTP Payment Bridges which signal their need
by 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 identifiers. But for security reasons, it should store pass
phrases in plain text only in runtime memory. Developers of IOTP phrases in plain text only in runtime memory. Developers of IOTP
Payment Bridges and payment software modules should provide a thin Payment Bridges and payment software modules should provide a thin
and fast implementation - without lengthy initialization and fast implementation - without lengthy initialization processes
processes- for this initial inquiry step. - for this initial inquiry step.
4. The IOTP Application Core verifies the Consumer's payment 4. The IOTP Application Core verifies the Consumer's payment
capabilities with the Merchant's accepted payment brands and capabilities with the Merchant's accepted payment brands and
currencies, currencies,
o displays the valid payment instruments and payment instrument o displays the valid payment instruments and payment instrument
independent payment brands (brand and protocol) together with independent payment brands (brand and protocol) together with
their purchase parameters (payment direction, currency, their purchase parameters (payment direction, currency,
amount), and amount), and
o requests the Consumer's choice or derives it automatically o requests the Consumer's choice or derives it automatically from
from any configured preferences. Any selection ties one IOTP any configured preferences. Any selection ties one IOTP
Payment Bridge 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. during the inquiry in Step 3 is up to the IOTP Application Core.
It may skip these IOTP Payment Bridges or may allow user supported 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 asked for payment instrument instruments when the Consumer is asked 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 of some required physical o required peripheral inclusive of some required physical payment
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 o expired payment instrument (or certificate), insufficient
funds, 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 offered accurate alternatives. Most probably, the user might be offered
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 If the check succeeds, it returns several IOTP Brand Selection
Info 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 selection of the second payment instrument during IOTP Value
Exchange 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 the Brand Selection Info elements. This component is transmitted
to 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 message lacks the IOTP Offer Response Block. The Merchant will
then 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 to An example of how the functions in this document are used together to
effect a successful payment is illustrated in the Figure 5. effect a successful payment is illustrated in the Figure 5. In the
figure 5, PS0, PS1, ..., and PSn indicate the nth PayScheme Packaged
Content data, and [ ] indicates optional.
(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 48 skipping to change at page 25, line 21
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 Block, the Consumer switches from communicating with the Merchant
to communicating with the Payment Handler. to communicating with the Payment Handler.
This might be a milestone requiring the renewed Consumer's This might be a milestone requiring the renewed Consumer's
agreement about the payment transaction's continuation. agreement about the payment transaction's continuation.
Particularly, this is a good moment for payment suspension (and Particularly, this is a good moment for payment suspension (and
even cancellation), which will be most probably supported by all even cancellation), which will be most probably supported by all
payment schemes. Simply, because the actual payment legacy systems payment schemes. Simply, because the actual payment legacy
have not yet been involved in the current transaction. systems have not yet 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 acknowledgments 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 progress (Consumer and Payment Handler) interaction and that its progress
is controlled by the IOTP Application Core and IOTP Payment is controlled by the IOTP Application Core and IOTP Payment
Bridge. 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 Application Core issues the "Start Payment Consumer" request
towards 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 initialization data of the payment transaction being referred to
by 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 expiration) from the selected Currency Amount element, Brand
List Component, and Payment Component of the IOTP Offer List Component, and Payment Component of the IOTP Offer
Response Block, 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 o order details contained in the IOTP Order Component which might
might be payment scheme specific, be payment scheme specific,
o payment scheme specific data inclusive of the payment o payment scheme specific data inclusive of the payment protocol
protocol descriptions from the IOTP Protocol Amount Element, descriptions from the IOTP Protocol Amount Element, and IOTP
and IOTP Pay Protocol Element, and Pay Protocol Element, and
o payment scheme specific data inclusive of the payment o payment scheme specific data inclusive of the payment protocol
protocol descriptions, in which the name attribute includes descriptions, in which the name attribute includes the prefix
the prefix as "Payment:" from the Trading Role Data as "Payment:" from the Trading Role Data Component.
Component.
Generally, the called API function re-does most checks of the Generally, the called API function re-does most checks of the
"Check Payment Possibility" call due to lack of strong "Check Payment Possibility" call due to lack of strong
dependencies between both requests: There might be a significant dependencies between both requests: There might be a significant
delay between both API 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 data being considered as payment specific initialization data for
the Payment Handler's IOTP Payment Bridge. the Payment Handler's IOTP Payment Bridge.
If the fixed Existing Payment Software implements payment If the fixed Existing Payment Software implements payment
instrument selection on its own, it may request the Consumer's instrument selection on its own, it may request the Consumer's
choice at this step. choice at this step.
The IOTP Payment Bridge reports lack of capability quite similarly The IOTP Payment Bridge reports lack of capability quite similarly
to the "Check Payment Possibility" request to the IOTP Application to the "Check Payment Possibility" request to the IOTP Application
Core. The Consumer may decide to resolve the problem, to suspend, Core. The Consumer may decide to resolve the problem, to suspend,
or to cancel the transaction, but this function call must succeed or to cancel the transaction, but this function call must succeed
in order to proceed with the transaction. in order to proceed with the transaction.
Developers of payment modules may decide to omit payment Developers of payment modules may decide to omit payment
instrument related checks like expiration date or refunds instrument related checks like expiration date or refunds
sufficiency, if such checks are part of the specific payment sufficiency, if such checks are part of the specific payment
protocol. 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 phrases anywhere during the payment process, they should be
requested by this API function, too. It is recommended that the requested by this API function, too. It is recommended that the
IOTP Application Core stores plain text pass phrases only in IOTP Application Core stores plain text pass phrases only in
runtime 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 Request Block, inserts any returned payment scheme data, and
submits 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 transaction calling the "Start Payment Payment Handler" API
function. The payment brand, its description, payment protocol, function. The payment brand, its description, payment protocol,
payment specific data, payment direction, currency and payment payment specific data, payment direction, currency and payment
amount are determined quite similar to the Consumer's IOTP amount are determined quite similar to the Consumer's IOTP
Application Core. Furthermore, the content of the IOTP Payment Application Core. Furthermore, the content of the IOTP Payment
Scheme Component and the IOTP Brand Selection Info Elements are Scheme Component and the IOTP Brand Selection Info Elements are
passed to this function. passed to this function.
On success, the Payment Handler's IOTP Payment Bridge responds On success, the Payment Handler's IOTP Payment Bridge responds
with payment scheme specific data. On failures, this non- with payment scheme specific data. On failures, this non-
interactive server application has to resolve any problems on its interactive server application has to resolve any problems on its
own or to give up aborting the payment transaction. However, the own or to give up aborting the payment transaction. However, the
Consumer may restart the whole payment transaction. Anyway, the Consumer may restart the whole payment transaction. Anyway, the
payment log file 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 Note that the "Start Payment Payment Handler" call might return
the Continuation Status "End" such that payment processing the Continuation Status "End" such that payment processing
proceeds with Step 7. proceeds with Step 7.
skipping to change at page 28, line 15 skipping to change at page 27, line 45
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 of the Payment Exchange Block and passes the contained payment
scheme specific data to the fixed IOTP Payment Bridge ("Continue scheme specific data to the fixed IOTP Payment Bridge ("Continue
Process") 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 exchanges, carrying the payment scheme specific data. Each party
(1) submits the embedded payment scheme specific data (1) submits the embedded payment scheme specific data
transparently to the appropriate IOTP Payment Bridge calling the transparently to the appropriate IOTP Payment Bridge calling the
"Continue Process" API function, (2) wraps the returned payment "Continue Process" API function, (2) wraps the returned payment
scheme specific data into an IOTP Payment Exchange Block, and (3) scheme specific data into an IOTP Payment Exchange Block, and (3)
transmits this block to the counter party. transmits this block to the counter party.
However, the processing of the payment scheme specific data may However, the processing of the payment scheme specific data may
fail for several reasons. These are signaled by specific error fail for several reasons. These are signaled by specific error
codes which are transformed to IOTP Payment Response Blocks codes which are transformed to IOTP Payment Response Blocks
(generated by Payment Handler) or IOTP Error Blocks (both parties (generated by Payment Handler) or IOTP Error Blocks (both parties
may generate them) and transmitted to the counter party. may generate 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 verifies whether an IOTP Payment Receipt Component has been
returned. The IOTP Application Core wraps the payment receipt, the returned. The IOTP Application Core wraps the payment receipt,
status response, and the optional payment scheme specific data in the status response, and the optional payment scheme specific data
an IOTP Payment Response Block and transmits this block to the in an IOTP Payment Response Block and transmits this block to the
Consumer. 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 incomplete (e.g., lack of payment receipt). Then, the Consumer
to be notified about the failed processing by an IOTP Error Block. has to be notified about the failed processing by an IOTP Error
Block.
Finally, the Payment Handler terminates the payment transaction Finally, the Payment Handler terminates the payment transaction
with the "Change Process State" API call without awaiting any with the "Change Process State" API call without awaiting any
further response from the Consumer. Further failures are not further response from the Consumer. Further failures are not
reported to the 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 the continuation status "End". Even in the absence of this
knowledge - this status is not exchanged between the Consumer and knowledge - this status is not exchanged between the Consumer and
the Payment Handler - the Payment Handler must not supply any the Payment Handler - the Payment Handler must not supply any
further payment scheme specific data. Such data will be rejected further payment scheme specific data. Such data will be rejected
by the Consumer's 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 inconsistencies. Any Inconsistency and returned status text
be displayed to the Consumer. should 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. In the figure 6, PS1 and PS2 indicate the
first and second PayScheme Packaged Content data, and [ ] indicates
optional.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Inquiry() -> IPB Consumer Start Payment Inquiry() -> IPB
Start Payment Inquiry Response([PS1]) <- IPB Start Payment Inquiry Response([PS1]) <- IPB
Create and transmit Inquiry Request Trading Block Create and transmit Inquiry Request Trading Block
Payment Handler Inquire Payment Status([PS1]) -> IPB Payment Handler Inquire Payment Status([PS1]) -> IPB
Inquire Payment Status Res.(State, [PS2]) -> IPB Inquire Payment Status Res.(State, [PS2]) -> IPB
Create and transmit Inquiry Response Trading Create and transmit Inquiry Response Trading
Block Block
Consumer If Payment Scheme Data present Consumer If Payment Scheme Data present
skipping to change at page 29, line 49 skipping to change at page 29, line 37
| 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 payment scheme data from the IOTP Payment Bridge which has been
fixed during brand selection (cf. Section 2.3) using the "Start fixed during brand selection (cf. Section 2.3) using the "Start
Payment Inquiry" API request. Payment Inquiry" API request.
Erroneous API responses should be reported to the Consumer and Erroneous API responses should be reported to the Consumer and
valid alternatives (typically retry and cancellation) should be valid alternatives (typically retry and cancellation) should be
presented 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 similarly to IOTP Payment Bridge reports lack of capability quite similarly to
the "Check Payment Possibility" request to the IOTP Application the "Check Payment Possibility" request to the IOTP Application
Core. 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 phrases anywhere during the payment process, they should be
requested by this API function, too. It is recommended that the requested by this API function, too. It is recommended that the
IOTP Application Core store plain text pass phrases only in IOTP Application Core store plain text pass phrases only in
runtime memory. runtime memory.
The IOTP Application Core encapsulates any Payment Scheme The IOTP Application Core encapsulates any Payment Scheme
Component in an IOTP Inquiry Request Block and submits the block Component in an IOTP Inquiry Request Block and submits the block
to the Payment 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 Process State") for verification purposes and payment status
change. The IOTP Payment Bridge reports any inconsistencies as change. The IOTP Payment Bridge reports any inconsistencies as
well as the 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 to the Any additional information that might be of interest to the
Consumer has to be displayed by the IOTP Payment Bridge or Consumer has to be displayed by the IOTP Payment Bridge or
Existing 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 depths of transport, message and block level o Error depths of 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 actual protocol: Business Core and the IOTP Payment Bridge from the actual 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 be Cancellations are mimicked as specific business errors which might 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
On "Business Error" response On "Business Error" response
| Inquire Process State() -> IPB | Inquire Process State() -> IPB
| Inquire P.S. Resp.(State, Receipt) <- IPB | Inquire P.S. Resp.(State, Receipt) <- IPB
Analyze local process state and try to resolve Analyze local process state and try to resolve
skipping to change at page 32, line 8 skipping to change at page 31, line 45
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,
cancellations, and even successes are always reported to the IOTP cancellations, and even successes are always reported to the IOTP
Payment Bridge by the API function "Change Process State". This API Payment Bridge by the API function "Change Process State". This API
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
the IOTP Payment Bridge for display by the IOTP Application Core. by the IOTP Payment Bridge for display by the IOTP Application Core.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Error Block or Cancel Block Received Any Party Error Block or Cancel Block Received
If 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 actual components. layer which might be resolved by the actual 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.
Any system component may implement time-out recognition and use the Any system component may implement time-out recognition and use the
aforementioned API mechanisms for the notification of process state aforementioned API mechanisms for the notification of process state
changes. But, time-outs may happens while communicating with both the changes. But, time-outs may happens while communicating with both
counter party and local system components, like chip card readers or the counter party and local system components, like chip card readers
IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core or IOTP Payment Bridges. Anyway, the Consumer's IOTP Application
should notify the Consumer about the resolution alternatives, i.e., Core should notify the Consumer about the resolution alternatives,
retry, suspension, and cancellation. i.e., 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 might o The Consumer's and Payment Handler's view of the transaction might
not be synchronized: Due to different time-out values the payment not be synchronized: Due to different time-out values the payment
transaction may not have been suspended by the counter party. transaction may not have been suspended by the counter party.
Any "Resume Payment ..." API function responds with an Error Code
on non-suspended payment transaction that signals a business error.
Afterwards the IOTP Application Core has to issue the "Inquire
Process State" API call for further analysis of the process state.
o One IOTP message sent by one party might not be processed Any "Resume Payment ..." API function responds with an Error Code
successfully or even received by the counter party. on non-suspended payment transaction that signals a business
error. Afterwards the IOTP Application Core has to issue the
"Inquire Process State" API call for further analysis of the
process state.
This needs to be handled by the actual payment scheme. It is o One IOTP message sent by one party might not be processed
expected that the IOTP Application Core will not recognize successfully or even received by the counter party. This needs to
anything. be handled by the actual payment scheme. It is expected that the
IOTP Application Core will not recognize anything.
o IOTP does not provide any specific signal for payment resumption. o IOTP does not provide any specific signal for payment resumption.
On receipt of every IOTP Payment Exchange Block, the IOTP On receipt of every IOTP Payment Exchange Block, the IOTP
Application Core has to decide whether this Block belongs to a Application Core has to decide whether this Block belongs to 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
State" API function to update any lack of knowledge. Process 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 business Similar, the "Continue Process" API function should report
errors on non-pending payment transactions. business 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 State" Any "Resume Payment", "Continue Process" or "Inquire Process
API function should return with an Error Code "AttValIllegal" on State" API function should return with an Error Code
non-existent payment transaction whereby the further Error "AttValIllegal" on non-existent payment transaction whereby the
Attribute "Names" denote the payment identifier. further Error 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
not been send to the counter party should not be accessed. has not been sent to the counter party should not be accessed.
If the Consumer does not reconnect within an acceptable amount of If the Consumer does not reconnect within an acceptable amount of
time, the Payment Handler's system may perform local failure time, the Payment Handler's system may perform local failure
resolution in order to close the transaction and to retain resources resolution in order to close the transaction and to retain resources
for other transactions ("Change Process State"). If the Consumer for other transactions ("Change Process State"). If the Consumer
reconnect afterwards, an IOTP Payment Response or IOTP Error Block reconnect afterwards, an IOTP Payment Response or IOTP Error Block
could be generated. could be generated.
2.7 IOTP Wallet Initialization 2.7. IOTP Wallet Initialization
At startup or on explicit user request the IOTP Application Core At startup or on explicit user request the IOTP Application Core
should check its IOTP Payment Bridges' internal status by searching should check its IOTP Payment Bridges' internal status by searching
for pending payment transactions. for pending payment transactions.
1. The IOTP Application Core interrogates the registered IOTP 1. The IOTP Application Core interrogates the registered IOTP Payment
Payment Bridges about pending payment transactions. The IOTP Bridges about pending payment transactions. The IOTP Application
Application Core may store indicators for pending transactions and Core may store indicators for pending transactions and use them
use them for driving any subsequent inquiry ("Inquire Pending 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 transactions, the IOTP Application Core may try to suspend
("Change Process State") or resume (only Consumer: "Resume Payment ("Change Process State") or resume (only Consumer: "Resume Payment
Consumer") 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.
denials are signaled by the error code "Business Error". Such 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
defers the actual registration to the corresponding IOTP Payment and defers the actual registration to the corresponding IOTP Payment
Bridge. Bridge.
The IOTP Application Core may also activate the Existing Payment The IOTP Application Core may also activate the Existing Payment
Software for further payment instrument and wallet administration. Software for further payment instrument and wallet administration.
3. Mutuality 3. Mutuality
The Payment API is formalized using the eXtensible Markup Language The Payment API is formalized using the eXtensible Markup Language
(XML). It defines wrapper elements for both the input parameters and (XML). It defines wrapper elements for both the input parameters and
the API function's response. In particular, the response wrapper the API function's response. In particular, the response wrapper
provides common locations for Error Codes and Error Descriptions. provides common locations for Error Codes and Error Descriptions.
It is anticipated that this description reflects the logical It is anticipated that this description reflects the logical
structure of the API parameter and might be used to derive structure of the API parameter and might be used to derive
implementation language specific API definitions. implementation language specific API definitions.
XML definition: XML definition:
<!ELEMENT IotpPaymentApiRequest ( <!ELEMENT IotpPaymentApiRequest (
FindAcceptedPaymentBrand | FindAcceptedPaymentBrand |
skipping to change at page 36, line 23 skipping to change at page 36, line 17
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
ErrorCode NMTOKEN #REQUIRED ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED ErrorDesc CDATA #REQUIRED
Severity(Warning | Severity(Warning |
TransientError | TransientError |
HardError) #REQUIRED HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED > SwVendorErrorRef CDATA #IMPLIED >
Most of the attribute items are intended for immediate insertion in Most of the attribute items are intended for immediate insertion in
the IOTP Error Block. The attribute values of the Error Location the IOTP Error Block. The attribute values of the Error Location
elements attribute have to enriched and transformed into Error elements attribute have to enriched and transformed into Error
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
software 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,
o the version of the software, and o the version of the software, and
o the build of the software. o the build of the software.
ErrorCode Contains an error code which indicates the ErrorCode Contains an error code which indicates the
nature of the error in the message in error. nature of the error in the message in error.
Valid values for the Error Code are given in Valid values for the Error Code are given in
the following section. This mnemonic enables the following section. This mnemonic enables
the automatic failure resolution of the IOTP the automatic failure resolution of the IOTP
Application Core which analyzes the error code Application Core which analyzes the error code
value in order to determine the continuation value in order to determine the continuation
alternatives. alternatives.
ErrorDesc Contains a description of the error in the ErrorDesc Contains a description of the error in the
language defined by xml:lang. The content of language defined by xml:lang. The content of
this attribute is defined by the this attribute is defined by the
vendor/developer of the software that vendor/developer of the software that
generated the Error Response Element. generated the Error Response Element.
It is intended for user display and provides It is intended for user display and provides
detailed explanations about the failure and detailed explanations about the failure and
its (out-of-band) resolution alternatives. its (out-of-band) resolution alternatives.
Severity Indicates the severity of the error. Valid Severity Indicates the severity of the error. Valid
values are: values are:
o Warning. This indicates that although there o Warning. This indicates that although there
is a message in error the IOTP Transaction is a message in error the IOTP Transaction
can still continue. can still continue.
o TransientError. This indicates that the o TransientError. This indicates that the
error in the message in error may be error in the message in error may be
recovered if the message in error that is recovered if the message in error that is
referred to by the "Names" attribute is referred to by the "Names" attribute is
resent. resent.
o HardError. This indicates that there is an o HardError. This indicates that there is an
unrecoverable error in the message in error unrecoverable error in the message in error
and the IOTP Transaction must stop. and the IOTP Transaction must stop.
MinRetrySecs This attribute should be present if "Severity" MinRetrySecs This attribute should be present if "Severity"
is set to "TransientError". It is the minimum is set to "TransientError". It is the minimum
number of whole seconds which the IOTP aware number of whole seconds which the IOTP aware
application which received the message application which received the message
reporting the error should wait before re- reporting the error should wait before
sending the message in error identified by the resending the message in error identified by
"ErrorLocation" attribute. the "ErrorLocation" attribute.
If Severity is not set to If Severity is not set to
"TransientError" then the value of this "TransientError" then the value of this
attribute is ignored. attribute is ignored.
SwVendorErrorRef This attribute is a reference whose value is SwVendorErrorRef This attribute is a reference whose value is
set by the vendor/developer of the software set by the vendor/developer of the software
that generated the Error Element. It should that generated the Error Element. It should
contain data that enables the vendor to contain data that enables the vendor to
identify the precise location in their identify the precise location in their
software and the set of circumstances that software and the set of circumstances that
caused the software to generate a message caused the software to generate a message
reporting the error. reporting the error.
Content: Content:
ErrorLocation This identifies, where possible, the ErrorLocation This identifies, where possible, the
element and attribute in the message element and attribute in the message
in error that caused the Error in error that caused the Error
Element to be generated. If the Element to be generated. If the
"Severity" of the error is not "Severity" of the error is not
"TransientError", more that one "TransientError", more that one
"ErrorLocation" may be specified as "ErrorLocation" may be specified as
appropriate depending on the nature appropriate depending on the nature
of the error and at the discretion of of the error and at the discretion of
the vendor/developer of the IOTP the vendor/developer of the IOTP
Payment Bridge. Payment Bridge.
Its definition coincides with the Its definition coincides with the
IOTP specification whereby the IOTP specification whereby the
attributes "IotpMsgRef", "BlkRef" and attributes "IotpMsgRef", "BlkRef" and
"CompRef" are left blank, "CompRef" are left blank,
intentionally. intentionally.
PaySchemePackagedContent cf. Table 5 PaySchemePackagedContent cf. Table 5
3.1 Error Codes 3.1. Error Codes
The following table lists the valid values for the ErrorCode The following table lists the valid values for the ErrorCode
attribute of the Error Response Element. The first sentence of the attribute of the Error Response Element. The first sentence of the
error description contains the default text that can be used to error description contains the default text that can be used to
describe the error when displayed or otherwise reported. Individual describe the error when displayed or otherwise reported. Individual
implementations may translate this into alternative languages at implementations may translate this into alternative languages at
their discretion. However, not every error code may apply to every their discretion. However, not every error code may apply to every
API call. An Error Code must not be more than 14 characters long. API call. An Error Code must not be more than 14 characters long.
The Error Codes have been taken from the IOTP Specification and The Error Codes have been taken from the IOTP Specification and
extended by some additional codes which are highlighted by a extended by some additional codes which are highlighted by a
preceding asterisk. preceding asterisk.
Generally, if the corrupt values have been user supplied, the IOTP Generally, if the corrupt values have been user supplied, the IOTP
Application Core might prompt for their correction. If the renewal Application Core might prompt for their correction. If the renewal
fails or if the IOTP Application Core skips any renewals and some fails or if the IOTP Application Core skips any renewals and some
notification has to be send to the counter-party, the error code is notification has to be send to the counter-party, the error code is
encapsulated within an IOTP Error Block. encapsulated within an IOTP Error Block.
However, the IOTP server application reports business errors - However, the IOTP server application reports business errors -
visible at the IOTP layer - in the Status Component of the respective visible at the IOTP layer - in the Status Component of the respective
Response Block. Response Block.
The IOTP Application Core may add the attributes (and values) within The IOTP Application Core may add the attributes (and values) within
the ErrorLocation elements that are omitted by the IOTP Payment the ErrorLocation elements that are omitted by the IOTP Payment
Bridge. Bridge.
The following table mentions any modification from this general The following table mentions any modification from this general
processing for particular error values. Furthermore, it contains processing for particular error values. Furthermore, it contains
hints for developers of IOTP Application Core software components hints for developers of IOTP Application Core software components
about the processing of error codes. Conversely, developers of IOTP about the processing of error codes. Conversely, developers of IOTP
Payment Bridges get impressions about the expected behavior of the Payment Bridges get impressions about the expected behavior of the
IOTP Application Core. IOTP Application Core.
The IOTP Payment API assumes that the IOTP Application Core The IOTP Payment API assumes that the IOTP Application Core
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
"well formed". "well formed".
XmlNotValid XML not valid. The XML document is well XmlNotValid XML not valid. The XML document is well
formed but the document is not valid. See formed but the document is not valid. See
[XML] for the meaning of "valid". [XML] for the meaning of "valid".
Specifically: Specifically:
o the XML document does not comply with the o the XML document does not comply with the
constraints defined in the IOTP document constraints defined in the IOTP document
type declaration, and type declaration, and
o the XML document does not comply with the o the XML document does not comply with the
constraints defined in the document type constraints defined in the document type
declaration of any additional [XML-NS] declaration of any additional [XML-NS]
that are declared. that are declared.
The Names attribute might refer some The Names attribute might refer some
attributes and elements of the input attributes and elements of the input
parameter list. parameter list.
(*)ElNotValid Element not valid. Invalid element in terms (*)ElNotValid Element not valid. Invalid element in terms
of prescribed syntactical characteristics. of prescribed syntactical characteristics.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
elements (if they have ID attributes). elements (if they have ID attributes).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" before error code with "XmlNotValid" before
transmission to the counterparty. transmission to the counterparty.
ElUnexpected Unexpected element. Although the XML ElUnexpected Unexpected element. Although the XML
document is well formed and valid, an document is well formed and valid, an
element is present that is not expected in element is present that is not expected in
the particular context according to the the particular context according to the
rules and constraints contained in this rules and constraints contained in this
specification. specification.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
elements (if they have ID attributes). elements (if they have ID attributes).
ElNotSupp Element not supported. Although the document ElNotSupp Element not supported. Although the document
is well formed and valid, an element is is well formed and valid, an element is
present that present that
o is consistent with the rules and o is consistent with the rules and
constraints contained in this constraints contained in this
specification, but specification, but
o is not supported by the IOTP Aware o is not supported by the IOTP Aware
Application which is processing the IOTP Application which is processing the IOTP
Message. Message.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
elements (if they have ID attributes). elements (if they have ID attributes).
ElMissing Element missing. Although the document is ElMissing Element missing. Although the document is
well formed and valid, an element is missing well formed and valid, an element is missing
that should have been present if the rules that should have been present if the rules
and constraints contained in this and constraints contained in this
specification are followed. specification are followed.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
elements (if they have ID attributes). elements (if they have ID attributes).
ElContIllegal Element content illegal. Although the ElContIllegal Element content illegal. Although the
document is well formed and valid, the document is well formed and valid, the
element contains values which do not conform element contains values which do not conform
the rules and constraints contained in this the rules and constraints contained in this
specification. specification.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
element (if they have ID attributes). element (if they have ID attributes).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
Error Code with "ElNotSupp" before Error Code with "ElNotSupp" before
transmission to the counter party, if the transmission to the counter party, if the
ErrorLocation elements refer to non- ErrorLocation elements refer to
PackagedContent element. non-PackagedContent element.
EncapProtErr Encapsulated protocol error. Although the EncapProtErr Encapsulated protocol error. Although the
document is well formed and valid, the document is well formed and valid, the
Packaged Content of an element contains data Packaged Content of an element contains data
from an encapsulated protocol which contains from an encapsulated protocol which contains
errors. errors.
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
element (if they have ID attributes). element (if they have ID attributes).
AttUnexpected Unexpected attribute. Although the XML AttUnexpected Unexpected attribute. Although the XML
document is well formed and valid, the document is well formed and valid, the
presence of the attribute is not expected in presence of the attribute is not expected in
the particular context according to the the particular context according to the
rules and constraints contained in this rules and constraints contained in this
specification. specification.
The AttName attributes of ErrorLocation The AttName attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
attribute tags. attribute tags.
(*)AttNotValid Attribute not valid. Invalid attribute value (*)AttNotValid Attribute not valid. Invalid attribute value
in terms of prescribed syntactical in terms of prescribed syntactical
characteristics. characteristics.
The AttName attributes of ErrorLocation The AttName attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
attribute tags. attribute tags.
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" before error code with "XmlNotValid" before
transmission to the counter party. transmission to the counter party.
AttNotSupp Attribute not supported. Although the XML AttNotSupp Attribute not supported. Although the XML
document is well formed and valid, and the document is well formed and valid, and the
presence of the attribute in an element is presence of the attribute in an element is
consistent with the rules and constraints consistent with the rules and constraints
contained in this specification, it is not contained in this specification, it is not
supported by the IOTP Aware Application supported by the IOTP Aware Application
which is processing the IOTP Message. which is processing the IOTP Message.
AttMissing Attribute missing. Although the document is AttMissing Attribute missing. Although the document is
well formed and valid, an attribute is well formed and valid, an attribute is
missing that should have been present if the missing that should have been present if the
rules and constraints contained in this rules and constraints contained in this
specification are followed. specification are followed.
The AttName attributes of ErrorLocation The AttName attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
attribute tags. attribute tags.
If the attribute is required by the IOTP If the attribute is required by the IOTP
Document Type Declaration (#REQUIRED) the Document Type Declaration (#REQUIRED) the
hints for non-valid attributes should be hints for non-valid attributes should be
adopted, otherwise these for illegal adopted, otherwise these for illegal
attribute values. attribute values.
AttValIllegal Attribute value illegal. The attribute AttValIllegal Attribute value illegal. The attribute
contains a value which does not conform to contains a value which does not conform to
the rules and constraints contained in this the rules and constraints contained in this
specification. specification.
The AttName attributes of ErrorLocation The AttName attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
attribute tags - valid values are: attribute tags - valid values are:
BrandId: illegal/unknown Brand Identifier - BrandId: illegal/unknown Brand Identifier -
If the brand is not recognized/known by any If the brand is not recognized/known by any
IOTP Payment Bridge, the IOTP Application IOTP Payment Bridge, the IOTP Application
Core may offer the registration of a new Core may offer the registration of a new
Payment Instrument. Payment Instrument.
PaymentInstrumentId: illegal/unknown PaymentInstrumentId: illegal/unknown
Payment Instrument Identifier - This Payment Instrument Identifier - This
indicates a serious communication problem if indicates a serious communication problem if
the attribute value has been reported by the the attribute value has been reported by the
same "wallet" on a previous inquiry same "wallet" on a previous inquiry
requests. The IOTP Application Core has to requests. The IOTP Application Core has to
replace the error code with replace the error code with
"UnknownError" before transmission to the "UnknownError" before transmission to the
counter party. counter party.
WalletId: illegal/unknown Wallet Identifier WalletId: illegal/unknown Wallet Identifier
- It is assumed that the wallet identifier - It is assumed that the wallet identifier
is checked before the pass phrase. On is checked before the pass phrase. On
invalid wallet identifiers, the IOTP invalid wallet identifiers, the IOTP
Application Core may open the dialog in Application Core may open the dialog in
order to request the correct wallet order to request the correct wallet
identifier. In addition, any pass phrase may identifier. In addition, any pass phrase may
be supplied by the user. The dialog should be supplied by the user. The dialog should
indicate the respective payment brand(s). indicate the respective payment brand(s).
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "UnknownError" before error code with "UnknownError" before
transmission to the counter party. transmission to the counter party.
Passphrase: illegal/unknown Pass Phrase - Passphrase: illegal/unknown Pass Phrase -
The IOTP Application Core may open the The IOTP Application Core may open the
dialog in order to request the correct pass dialog in order to request the correct pass
phrase. If the pass phrase is wallet phrase. If the pass phrase is wallet
identifier specific the dialog should identifier specific the dialog should
display the wallet identifier. The IOTP display the wallet identifier. The IOTP
Application Core has to replace the error Application Core has to replace the error
code with "TransportError" before code with "TransportError" before
transmission to the counter party. transmission to the counter party.
Action: illegal / unknown / unsupported Action: illegal / unknown / unsupported
Action Action
PropertyTypeList: lists contains illegal / PropertyTypeList: lists contains illegal /
unknown / unsupported Property Types - The unknown / unsupported Property Types - The
IOTP Application Core tries only the local IOTP Application Core tries only the local
skipping to change at page 43, line 45 skipping to change at page 44, line 4
Currency Code Type Currency Code Type
Amount: illegal/unknown/unsupported Payment Amount: illegal/unknown/unsupported Payment
Amount Amount
PayDirection: illegal/unknown/unsupported PayDirection: illegal/unknown/unsupported
Payment Direction Payment Direction
ProtocolId: illegal/unknown/unsupported ProtocolId: illegal/unknown/unsupported
Protocol Identifier Protocol Identifier
OkFrom: illegal/unknown/unsupported OkFrom OkFrom: illegal/unknown/unsupported OkFrom
Timestamp Timestamp
OkTo: illegal/unknown/unsupported OkTo OkTo: illegal/unknown/unsupported OkTo
Timestamp Timestamp
ConsumerPayId: illegal/unknown Consumer ConsumerPayId: illegal/unknown Consumer
Payment Identifier Payment Identifier
PaymentHandlerPayId: illegal/unknown Payment PaymentHandlerPayId: illegal/unknown Payment
Handler Payment Identifier Handler Payment Identifier
PayId: illegal/unknown Payment Identifier PayId: illegal/unknown Payment Identifier
AttValNotRecog Attribute Value Not Recognized. The AttValNotRecog Attribute Value Not Recognized. The
attribute contains a value which the IOTP attribute contains a value which the IOTP
Aware Application generating the message Aware Application generating the message
reporting the error could not recognize. reporting the error could not recognize.
The AttName attributes of ErrorLocation The AttName attributes of ErrorLocation
elements might refer to the corresponding elements might refer to the corresponding
attribute tags attribute tags.
MsgTooLarge Message too large. The message is too large MsgTooLarge Message too large. The message is too large
to be processed by the IOTP Payment Bridge to be processed by the IOTP Payment Bridge
(or IOTP Application Core). (or IOTP Application Core).
ElTooLarge Element too large. The element is too large ElTooLarge Element too large. The element is too large
to be processed by the IOTP Payment Bridge to be processed by the IOTP Payment Bridge
(or IOTP Application Core). (or IOTP Application Core).
The ElementRef attributes of ErrorLocation The ElementRef attributes of ErrorLocation
elements might might refer to the elements might refer to the corresponding
corresponding elements. elements.
ValueTooSmall Value too small or early. The value of all ValueTooSmall Value too small or early. The value of all
or part of an element content or an or part of an element content or an
attribute, although valid, is too small. attribute, although valid, is too small.
The ErrorLocation elements might refer to The ErrorLocation elements might refer to
the corresponding attribute tags or the corresponding attribute tags or
elements. elements.
ValueTooLarge Value too large or in the future. The value ValueTooLarge Value too large or in the future. The value
of all or part of an element content or an of all or part of an element content or an
attribute, although valid, is too large. attribute, although valid, is too large.
The ErrorLocation elements might refer to The ErrorLocation elements might refer to
the corresponding attribute tags or the corresponding attribute tags or
elements. elements.
ElInconsistent Element Inconsistent. Although the document ElInconsistent Element Inconsistent. Although the document
is well formed and valid, according to the is well formed and valid, according to the
rules and constraints contained in this rules and constraints contained in this
specification: specification:
o the content of an element is inconsistent o the content of an element is inconsistent
with the content of other elements or with the content of other elements or
their attributes, or their attributes, or
o the value of an attribute is inconsistent o the value of an attribute is inconsistent
with the value of one or more other with the value of one or more other
attributes. attributes.
The Error Description may contain further The Error Description may contain further
explanations. explanations.
The ErrorLocation elements might refer to The ErrorLocation elements might refer to
the corresponding attribute tags or elements the corresponding attribute tags or elements
that are inconsistent. that are inconsistent.
TransportError Transport Error. This error code is used to TransportError Transport Error. This error code is used to
indicate that there is a problem with the indicate that there is a problem with the
transport mechanism that is preventing the transport mechanism that is preventing the
message from being received. It is typically message from being received. It is typically
associated with a "Transient Error". associated with a "Transient Error".
The connection to some periphery or the The connection to some periphery or the
counter party could not be established, counter party could not be established,
is erroneous, or has been lost. is erroneous, or has been lost.
The Error Description may contain further The Error Description may contain further
narrative explanations, e.g., "chip card narrative explanations, e.g., "chip card
does not respond", "remote account manager does not respond", "remote account manager
unreachable", "Internet connection to xyz unreachable", "Internet connection to xyz
lost", "no Internet connection available", lost", "no Internet connection available",
"no modem connected", or "serial port to "no modem connected", or "serial port to
modem used by another application". This modem used by another application". This
text should be shown to the end user. If text should be shown to the end user. If
timeout has occurred at the Consumer this timeout has occurred at the Consumer this
text should be shown and the Consumer may text should be shown and the Consumer may
decide how to proceed - alternatives are decide how to proceed - alternatives are
retry, payment transaction suspension, and retry, payment transaction suspension, and
cancellation. cancellation.
MsgBeingProc Message Being Processed. This error code is MsgBeingProc Message Being Processed. This error code is
only used with a Severity of Transient only used with a Severity of Transient
Error. It indicates that the previous Error. It indicates that the previous
message, which may be an exchange message or message, which may be an exchange message or
a request message, is being processed and, a request message, is being processed and,
if no response is received by the time if no response is received by the time
indicated by the "MinRetrySecs" attribute, indicated by the "MinRetrySecs" attribute,
then the original message should be resent. then the original message should be resent.
SystemBusy System Busy. This error code is only used SystemBusy System Busy. This error code is only used
with a Severity of Transient Error. It with a Severity of Transient Error. It
indicates that the IOTP Payment Bridge or indicates that the IOTP Payment Bridge or
Existing Payment Software that received the Existing Payment Software that received the
API request is currently too busy to handle API request is currently too busy to handle
it. If no response is received by the time it. If no response is received by the time
indicated by the "MinRetrySecs" attribute, indicated by the "MinRetrySecs" attribute,
then the original message should be resent. then the original message should be resent.
The Error Description may provide further The Error Description may provide further
explanations, e.g., "wallet / chip card explanations, e.g., "wallet / chip card
reader is unavailable or locked by another reader is unavailable or locked by another
payment transaction", "payment gateway is payment transaction", "payment gateway is
overloaded", "unknown chip card reader", or overloaded", "unknown chip card reader", or
"unrecognized chip card inserted, change "unrecognized chip card inserted, change
chip card". chip card".
The Consumer's IOTP Application Core may The Consumer's IOTP Application Core may
display the error description and ask the display the error description and ask the
Consumer about the continuation - Consumer about the continuation -
alternatives are retry, payment transaction alternatives are retry, payment transaction
suspension, and cancellation. suspension, and cancellation.
UnknownError Unknown Error. Indicates that the UnknownError Unknown Error. Indicates that the
transaction cannot complete for some reason transaction cannot complete for some reason
that is not covered explicitly by any of the that is not covered explicitly by any of the
other errors. The Error description other errors. The Error description
attribute should be used to indicate the attribute should be used to indicate the
nature of the problem. nature of the problem.
The ErrorLocation elements might refer to The ErrorLocation elements might refer to
the corresponding attribute tags or elements the corresponding attribute tags or elements
that are inconsistent. that are inconsistent.
(*)SyntaxError Syntax Error. An (unknown) syntax error has (*)SyntaxError Syntax Error. An (unknown) syntax error has
occurred. occurred.
The ErrorLocation elements might refer to The ErrorLocation elements might refer to
the corresponding attribute tags or elements the corresponding attribute tags or elements
that are inconsistent. that are inconsistent.
The IOTP Application Core has to replace the The IOTP Application Core has to replace the
error code with "XmlNotValid" or error code with "XmlNotValid" or
"UnknownError" before transmission to the "UnknownError" before transmission to the
counter party. counter party.
(*)ReqRefused Request refused. The API request is (*)ReqRefused Request refused. The API request is
(currently) refused by the IOTP Payment (currently) refused by the IOTP Payment
Bridge. The error description may provide Bridge. The error description may provide
further explanations, e.g., "wallet / chip further explanations, e.g., "wallet / chip
card reader is unavailable or locked by card reader is unavailable or locked by
another payment transaction", "payment another payment transaction", "payment
gateway is overloaded", "unknown chip card gateway is overloaded", "unknown chip card
reader", or "unrecognized chip card reader", or "unrecognized chip card
inserted, change chip card". inserted, change chip card".
The Consumer's IOTP Application Core may The Consumer's IOTP Application Core may
display the error description and ask the display the error description and ask the
Consumer about the continuation - Consumer about the continuation -
alternatives are retry, payment transaction alternatives are retry, payment transaction
suspension, and cancellation. Denials due to suspension, and cancellation. Denials due to
invalid Process States should be signaled by invalid Process States should be signaled by
"BusinessError". Typically, this kind of "BusinessError". Typically, this kind of
error is not passed to the counter party's error is not passed to the counter party's
IOTP Application Core. Otherwise, it maps to IOTP Application Core. Otherwise, it maps to
"TransportError" or "UnknownError". "TransportError" or "UnknownError".
(*)ReqNotSupp Request not supported. The API (*)ReqNotSupp Request not supported. The API
function(ality) has not been implemented in function(ality) has not been implemented in
the IOTP Payment Bridge. Typically, this the IOTP Payment Bridge. Typically, this
kind of error is not passed to the kind of error is not passed to the
counter party's IOTP Application Core. counter party's IOTP Application Core.
Otherwise, it maps to "TransportError" or Otherwise, it maps to "TransportError" or
"UnknownError". "UnknownError".
(*)BusError Business Error. The API request has been (*)BusError Business Error. The API request has been
rejected because some payment transaction rejected because some payment transaction
has an illegal payment status. has an illegal payment status.
Particularly, this error code is used to Particularly, this error code is used to
signal any raise of payment business layered signal any raise of payment business layered
failures. failures.
The ErrorLocation elements may refer to The ErrorLocation elements may refer to
payment transactions using the party's payment transactions using the party's
Payment Identifier - it defaults to the Payment Identifier - it defaults to the
current transaction or might contain the current transaction or might contain the
skipping to change at page 47, line 52 skipping to change at page 48, line 22
State which actually encodes the business State which actually encodes the business
error ("Inquire Process State"). error ("Inquire Process State").
This error code must not be This error code must not be
passed to the counter party's IOTP passed to the counter party's IOTP
Application Core. Application Core.
Table 2: Common Error Codes Table 2: Common Error Codes
The IOTP Payment Bridge may also use the error description in order The IOTP Payment Bridge may also use the error description in order
to notify the Consumer about further necessary steps for failure to notify the Consumer about further necessary steps for failure
resolution, e.g., "sorry, your payment transaction failed. resolution, e.g., "Sorry, your payment transaction failed.
Unfortunately, you have been charged, please contact your issuer." Unfortunately, you have been charged, please contact your issuer."
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 after the attribute tag is a recommended - any parenthesized number after the attribute tag is a recommended
maximal length of the attribute value in characters: maximal length of the attribute value in characters:
Attribute Description Attribute Description
--------- ----------- --------- -----------
Amount (11) Indicates the payment amount to be paid in Amount (11) Indicates the payment amount to be paid in
AmountFrom(11) whole and fractional units of the currency. AmountFrom(11) whole and fractional units of the currency.
AmountTo (11) For example $245.35 would be expressed AmountTo (11) For example $245.35 would be expressed
"245.35". Note that values smaller than the "245.35". Note that values smaller than the
smallest denomination are allowed. For smallest denomination are allowed. For
example one tenth of a cent would be example one tenth of a cent would be
"0.001". "0.001".
AuthenticationId An identifier specified by the AuthenticationId An identifier specified by the
authenticator which, if returned by the authenticator which, if returned by the
organization that receives the organization that receives the
authentication request, will enable the authentication request, will enable the
authenticator to identify which authenticator to identify which
authentication is being referred to. authentication is being referred to.
BrandId (128) This contains a unique identifier for the BrandId (128) This contains a unique identifier for the
brand (or promotional brand). It is used to brand (or promotional brand). It is used to
match against a list of Payment Instruments match against a list of Payment Instruments
which the Consumer holds to determine which the Consumer holds to determine
whether or not the Consumer can pay with the whether or not the Consumer can pay with the
Brand. Brand.
Values of BrandId are managed under Values of BrandId are managed under
procedure being described in the IOTP procedure being described in the IOTP
protocol specification. protocol specification.
BrandLogoNetLocn The net location which can be used to BrandLogoNetLocn The net location which can be used to
download the logo for the organization (cf. download the logo for the organization (cf.
IOTP Specification). IOTP Specification).
The content of this attribute must conform The content of this attribute must conform
to [URL]. to [URL].
BrandName This contains the name of the brand, for BrandName This contains the name of the brand, for
example "MasterCard Credit". This is the example "MasterCard Credit". This is the
description of the Brand which is displayed description of the Brand which is displayed
to the consumer in the Consumer's language to the consumer in the Consumer's language
defined by "xml:lang". For example it might defined by "xml:lang". For example it might
be "American Airlines Advantage Visa". Note be "American Airlines Advantage Visa". Note
that this attribute is not used for matching that this attribute is not used for matching
against the payment instruments held by the against the payment instruments held by the
Consumer. Consumer.
BrandNarrative This optional attribute is BrandNarrative This optional attribute is
used by the Merchant to indicate some used by the Merchant to indicate some
special conditions or benefit which would special conditions or benefit which would
apply if the Consumer selected that brand. apply if the Consumer selected that brand.
For example "5% discount", "free shipping For example "5% discount", "free shipping
and handling", "free breakage insurance for and handling", "free breakage insurance for
1 year", "double air miles apply", etc. 1 year", "double air miles apply", etc.
CallBackFunction A function which is called whenever there is CallBackFunction A function which is called whenever there is
a change of Process State or payment a change of Process State or payment
progress, e.g. for display updates. However, progress, e.g., for display updates. However,
the IOTP Payment Bridge may use its own the IOTP Payment Bridge may use its own
mechanisms and dialog boxes. mechanisms and dialog boxes.
CallBackLanguageLis A list of language codes which contain, in CallBackLanguageList
t order of preference, the languages in which A list of language codes which contain, in
order of preference, the languages in which
the text passed to the Call Back function the text passed to the Call Back function
will be encoded. will be encoded.
CompletionCode (14) Indicates how the process completed. CompletionCode (14) Indicates how the process completed.
It is required if ProcessState is set to It is required if ProcessState is set to
"Failed" otherwise it is ignored. Valid "Failed" otherwise it is ignored. Valid
values as well as recovery options are given values as well as recovery options are given
in the IOTP specification. in the IOTP specification.
The IOTP Payment Bridge may also use the The IOTP Payment Bridge may also use the
Status Description to notify the Consumer Status Description to notify the Consumer
about further necessary steps in order to about further necessary steps in order to
resolve some kind of business failures, resolve some kind of business failures,
e.g., e.g.,
o "sorry, your payment transaction failed. o "sorry, your payment transaction failed.
Unfortunately, you have been charged, Unfortunately, you have been charged,
please contact your issuer." please contact your issuer."
o "insufficient capacity left (on your stored o "insufficient capacity left (on your
value card) for refund", stored value card) for refund",
o "payment failed/chip card error/internal o "payment failed/chip card error/internal
error, please contact your payment error, please contact your payment
instrument's issuer" instrument's issuer"
ConsumerDesc A narrative description of the Consumer. ConsumerDesc A narrative description of the Consumer.
ConsumerPayId (14) An unique identifier specified by the ConsumerPayId (14) An unique identifier specified by the
Consumer that, if returned by the Payment Consumer that, if returned by the Payment
Handler in another Payment Scheme Component Handler in another Payment Scheme Component
or by other means, enables the Consumer to or by other means, enables the Consumer to
identify which payment is being referred to. identify which payment is being referred to.
This unique identifier is generated by the This unique identifier is generated by the
IOTP Application Core and submitted to the IOTP Application Core and submitted to the
IOTP Payment Bridge on every API call. It IOTP Payment Bridge on every API call. It
may equal the Payment Handler Payment may equal the Payment Handler Payment
Identifiers but need not necessarily be so. Identifiers but need not necessarily be so.
The uniqueness extends to multiple payment The uniqueness extends to multiple payment
instruments, payment brands, payment instruments, payment brands, payment
protocols, wallet identifiers, and even protocols, wallet identifiers, and even
multiple IOTP Payment Bridges. multiple IOTP Payment Bridges.
ContStatus During payment progress, this status value ContStatus During payment progress, this status value
indicates whether the payment needs to be indicates whether the payment needs to be
continued with further IOTP Payment Scheme continued with further IOTP Payment Scheme
Component exchanges with the remote party. Component exchanges with the remote party.
"End" indicates that the reported payment "End" indicates that the reported payment
scheme data is the last data to be exchanged scheme data is the last data to be exchanged
with the counter party. with the counter party.
ContentSoftwareId This contains information that identifies ContentSoftwareId This contains information that identifies
the software that generated the content of the software that generated the content of
the element. Its purpose is to help resolve the element. Its purpose is to help resolve
interoperability problems that might occur interoperability problems that might occur
as a result of incompatibilities between as a result of incompatibilities between
messages produced by different software. It messages produced by different software. It
is a single text string in the language is a single text string in the language
defined by xml:lang. It must contain, as a defined by xml:lang. It must contain, as a
minimum: minimum:
o the name of the software manufacturer, o the name of the software manufacturer,
o the name of the software, o the name of the software,
o the version of the software, and o the version of the software, and
o the build of the software. o the build of the software.
CurrCodeType (14) Indicates the domain of the CurrCode. This CurrCodeType (14) Indicates the domain of the CurrCode. This
attribute is included so that the currency attribute is included so that the currency
code may support nonstandard currencies code may support nonstandard currencies
such as frequent flyer point, trading such as frequent flyer point, trading
stamps, etc. Its values may be stamps, etc. Its values may be
o ISO-4217-A, the default, indicates the o ISO-4217-A, the default, indicates the
currency code is the three-letter currency code is the three-letter
alphabetic code that conform to ISO 4217 alphabetic code that conform to ISO-4217
[ISO4217].
o IOTP indicates that the values of o IOTP indicates that the values of
CurrCode are managed under the procedure CurrCode are managed under the procedure
described in [IOTP]. described in [IOTP].
CurrCode (14) A code which identifies the currency to be CurrCode (14) A code which identifies the currency to be
used in the payment. The domain of valid used in the payment. The domain of valid
currency codes is defined by "CurrCodeType" currency codes is defined by "CurrCodeType"
MerchantPayId (14) An private identifier specified by the MerchantPayId (14) An private identifier specified by the
Merchant which will enable the Merchant to Merchant which will enable the Merchant to
identify which payment is being referred to. identify which payment is being referred to.
It is a pure private item and is never sent It is a pure private item and is never sent
to any other party. It is provided by the to any other party. It is provided by the
IOTP Payment Bridge on payment preparation IOTP Payment Bridge on payment preparation
during brand compilation. during brand compilation.
Cf. To "ConsumerPayId" for note about Cf. To "ConsumerPayId" for note about
uniqueness. uniqueness.
MerchantOrgId (64) A local item that might refer to some MerchantOrgId (64) A local item that might refer to some
specific shop in a multi shop environment. specific shop in a multi shop environment.
This item is optional and might enrich the This item is optional and might enrich the
Wallet Identifier which itself can be used Wallet Identifier which itself can be used
for the same purpose. for the same purpose.
Name Distinguishes between multiple occurrences Name Distinguishes between multiple occurrences
of Packaged Content Elements at the same of Packaged Content Elements at the same
point in IOTP. For example: point in IOTP. For example:
<ABCD> <ABCD>
<PackagedContent Name='FirstPiece'> <PackagedContent Name='FirstPiece'>
snroasdfnas934k snroasdfnas934k
</PackagedContent> </PackagedContent>
<PackagedContent Name='SecondPiece'> <PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45 dvdsjnl5poidsdsflkjnw45
</PackagedContent> </PackagedContent>
</ABCD> </ABCD>
The "Name" attribute may be omitted, for The "Name" attribute may be omitted, for
example if there is only one Packaged example if there is only one Packaged
Content element. Content element.
OkFrom (30) The date and time in UTC Format range OkFrom (30) The date and time in UTC Format range
OkTo (30) indicated by the merchant in which the OkTo (30) indicated by the merchant in which the
Payment Handler may accept the payment. Payment Handler may accept the payment.
For more information, see [UTC].
Passphrase (32) Payment wallets may use pass phrase Passphrase (32) Payment wallets may use pass phrase
protection for transaction data and payment protection for transaction data and payment
instruments' data. However, it is assumed instruments' data. However, it is assumed
that there exists a public and customizable that there exists a public and customizable
payment instrument identifier such that payment instrument identifier such that
these identifiers together with their these identifiers together with their
relationship to payment brands, payment relationship to payment brands, payment
protocols, payment directions, and currency protocols, payment directions, and currency
amounts can be queried by the IOTP amounts can be queried by the IOTP
application without any pass phrase application without any pass phrase
knowledge. knowledge.
PayDirection Indicates the direction in which the PayDirection Indicates the direction in which the
payment for which a Brand is being selected payment for which a Brand is being selected
is to be made. Its values may be: is to be made. Its values may be:
o Debit: The sender of the Payment Request o Debit: The sender of the Payment Request
Block (e.g. the Consumer) to which this Block (e.g., the Consumer) to which this
Brand List relates will make the payment Brand List relates will make the payment
to the Payment Handler, or to the Payment Handler, or
o Credit: The sender of the Payment Request o Credit: The sender of the Payment Request
Block to which this Brand List relates Block to which this Brand List relates
will receive a payment from the Payment will receive a payment from the Payment
Handler. Handler.
PayId (14) This attribute is introduced for API PayId (14) This attribute is introduced for API
simplification: simplification:
o The Consumer has to identify PayId and o The Consumer has to identify PayId and
ConsumerPayId. ConsumerPayId.
o The Merchant has to identify PayId and o The Merchant has to identify PayId and
MerchantPayId. MerchantPayId.
o The Payment Handler has to identify PayId o The Payment Handler has to identify PayId
and Payment Handler Pay Id. and Payment Handler Pay Id.
PayInstId This contains the unique identifier used PayInstId This contains the unique identifier used
internally by the IOTP Payment internally by the IOTP Payment
Bridge/Existing Payment Software. Bridge/Existing Payment Software.
PayInstName This contains the user-defined name of the PayInstName This contains the user-defined name of the
payment instrument. There exist no payment instrument. There exist no
(technical) constraints like uniqueness. The (technical) constraints like uniqueness. The
"xml:lang" attribute denotes the language "xml:lang" attribute denotes the language
encoding of its value. encoding of its value.
PaymentHandlerDesc A narrative description of the Payment PaymentHandlerDesc A narrative description of the Payment
Handler. Handler.
PaymentHandlerPayId An unique identifier specified by the PaymentHandlerPayId An unique identifier specified by the
(14) Payment Handler that, if returned by the (14) Payment Handler that, if returned by the
Consumer in another Payment Scheme Component Consumer in another Payment Scheme Component
or by other means, enables the Payment or by other means, enables the Payment
Handler to identify which payment is being Handler to identify which payment is being
referred to. It is required whenever it is referred to. It is required whenever it is
known. known.
Cf. To "ConsumerPayId" for note about Cf. To "ConsumerPayId" for note about
uniqueness. uniqueness.
PaymentInstrumentId An identifier for a specific payment PaymentInstrumentId An identifier for a specific payment
(32) instrument, e.g. "credit card", "Mondex card (32) instrument, e.g., "credit card", "Mondex card
for English Pounds". This identifier is for English Pounds". This identifier is
fully customizable. It is assumed, that it fully customizable. It is assumed, that it
does not contain confidential information or does not contain confidential information or
even an indication of it. The payment even an indication of it. The payment
instrument identifier is unique within each instrument identifier is unique within each
payment brand. It is displayed to the payment brand. It is displayed to the
Consumer during brand selection. Consumer during brand selection.
PayReceiptNameRefs Optionally contains element references to PayReceiptNameRefs Optionally contains element references to
(32) other elements (containing payment scheme (32) other elements (containing payment scheme
specific data) that together make up the specific data) that together make up the
receipt. Note that each payment scheme receipt. Note that each payment scheme
defines in its supplement the elements that defines in its supplement the elements that
must be referenced must be referenced
The IOTP Application Core should save all The IOTP Application Core should save all
the components referenced so that the the components referenced so that the
payment receipt can be reconstructed when payment receipt can be reconstructed when
required. required.
PayReqNetLocn The Net Location indicating where an PayReqNetLocn The Net Location indicating where an
unsecured Payment Request message should be unsecured Payment Request message should be
sent if this protocol choice is used. sent if this protocol choice is used.
The content of this attribute must conform The content of this attribute must conform
to [URL] and depends on the Transport to [URL] and depends on the Transport
Mechanism. Mechanism.
PercentComplete (3) A number between 0 and 100 which indicates PercentComplete (3) A number between 0 and 100 which indicates
the progress of the payment transaction. The the progress of the payment transaction. The
values range between 0 and 99 for pending values range between 0 and 99 for pending
and suspended transactions. and suspended transactions.
ProcessState Contains a Process State Code that ProcessState Contains a Process State Code that
indicates the current state of the process indicates the current state of the process
being carried out. Valid values are: being carried out. Valid values are:
o NotYetStarted. The Payment Request Block o NotYetStarted. The Payment Request Block
has been received but processing of the has been received but processing of the
Payment Request has not yet started Payment Request has not yet started
o InProgress. The payment transaction is o InProgress. The payment transaction is
pending. The processing of the (Payment) pending. The processing of the (Payment)
Request Block has started but it is not Request Block has started but it is not
yet complete. yet complete.
o (*)Suspended: The payment transaction has o (*)Suspended: The payment transaction has
been suspended and can be resumed. been suspended and can be resumed.
This process state is mapped to This process state is mapped to
"InProgress", if it is passed to the "InProgress", if it is passed to the
counter party's IOTP Application Core. counter party's IOTP Application Core.
o CompletedOk. The processing of the (Payment) o CompletedOk. The processing of the (Payment)
Request Block and any following Payment Request Block and any following Payment
Exchange Blocks has completed successfully. Exchange Blocks has completed successfully.
o Failed. The payment processing has finally o Failed. The payment processing has finally
failed for a Business Error. failed for a Business Error.
o ProcessError. This value is only used o ProcessError. This value is only used
when the Status Component is being used in when the Status Component is being used in
connection with an Inquiry Request Trading connection with an Inquiry Request Trading
Block. It indicates there was a Technical Block. It indicates there was a Technical
Error in the Request Block which is being Error in the Request Block which is being
processed or some internal processing processed or some internal processing
error. Each party's IOTP Payment Bridge error. Each party's IOTP Payment Bridge
uses this value in order to notify the uses this value in order to notify the
IOTP Application Core about the presence IOTP Application Core about the presence
of technical errors. of technical errors.
PropertyType (14) The property type defines codes used for PropertyType (14) The property type defines codes used for
interrogation of specific properties about a interrogation of specific properties about a
payment instrument. They are unique for each payment instrument. They are unique for each
payment brand. The predefined property "all" payment brand. The predefined property "all"
is used on general inquiries. However, these is used on general inquiries. However, these
property types are not used during normal property types are not used during normal
payment processing. E.g., they may apply to payment processing. E.g., they may apply to
payment brand specific transactions or out- payment brand specific transactions or
of-band failure resolution. out-of-band failure resolution.
PropertyDesc The property description carries the PropertyDesc The property description carries the
respective human readable property (value)'s respective human readable property (value)'s
description. description.
PropertyValue The actual property value intends automatic PropertyValue The actual property value intends automatic
post processing. post processing.
ProtocolBrandId (64)This is an identifier to be used with a ProtocolBrandId (64)This is an identifier to be used with a
particular payment protocol. For example, particular payment protocol. For example,
SET and EMV have their own well defined, yet SET and EMV have their own well defined, yet
different, values for the Brand identifier different, values for the Brand identifier
to be used with each protocol. The valid values to be used with each protocol. The valid values
of this attribute are defined in the of this attribute are defined in the
supplement for the payment protocol supplement for the payment protocol
identified by "ProtocolId" that describes identified by "ProtocolId" that describes
how the payment protocol works with IOTP. how the payment protocol works with IOTP.
Identifier maps to at most one Protocol Identifier maps to at most one Protocol
Brand Identifier. Brand Identifier.
ProtocolId (64) An identifier for a specific payment ProtocolId (64) An identifier for a specific payment
protocol and version, e.g. "SETv1.0", protocol and version, e.g., "SETv1.0",
"ecash". Valid values are defined by "ecash". Valid values are defined by
supplements to the IOTP specification and supplements to the IOTP specification and
they are unique within each payment brand. they are unique within each payment brand.
ProtocolIds A sequence of Protocol Identifiers ProtocolIds A sequence of Protocol Identifiers
ProtocolName A narrative description of the payment ProtocolName A narrative description of the payment
protocol and its version in the language protocol and its version in the language
identified by "xml:lang". For example identified by "xml:lang". For example
"Secure Electronic Transaction Version 1.0". "Secure Electronic Transaction Version 1.0".
Its purpose is to help provide information Its purpose is to help provide information
on the payment protocol being used if on the payment protocol being used if
problems arise. problems arise.
SecPayReqNetLocn The Net Location indicating where a secured SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if Payment Request message should be sent if
this protocol choice is used. this protocol choice is used.
A secured payment involves the use of a A secured payment involves the use of a
skipping to change at page 55, line 42 skipping to change at page 56, line 39
The content of this attribute must conform The content of this attribute must conform
to [URL]. to [URL].
ReceiverOrgId The Organization Identification which ReceiverOrgId The Organization Identification which
receives the payment bridge processing receives the payment bridge processing
Trading Role Data PackagedContent. Trading Role Data PackagedContent.
StatusDesc (256) An optional textual description of the StatusDesc (256) An optional textual description of the
current process state in the language current process state in the language
identified by "xml:lang" that should be identified by "xml:lang" that should be
displayed to the Consumer. The usage of this displayed to the Consumer. The usage of this
attribute is defined in the payment attribute is defined in the payment
supplement for the payment method being supplement for the payment method being
used. Particularly, it provides hints for used. Particularly, it provides hints for
out-of-band failure resolution. Its length out-of-band failure resolution. Its length
is limited to 256 characters. is limited to 256 characters.
StyleSheetNetLocn This contains the net location to a style StyleSheetNetLocn This contains the net location to a style
sheet with visualisation rules for XML sheet with visualisation rules for XML
encoded data. encoded data.
TimeStamp (30) The date and time in UTC Format when the TimeStamp (30) The date and time in UTC Format when the
payment transaction has been started. payment transaction has been started.
For more information on UTC, see [UTC].
WalletId (32) Many existing payment wallet software are WalletId (32) Many existing payment wallet software are
multiple wallet capable. The Wallet multiple wallet capable. The Wallet
Identifier selects the actual wallet. It is Identifier selects the actual wallet. It is
assumed, that the wallet identifier is a assumed, that the wallet identifier is a
public item, that might be stored by the public item, that might be stored by the
IOTP Application Core. IOTP Application Core.
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
Content originates from a Authentication Content originates from a Authentication
(Data/Response) Component's content (Data/Response) Component's content
whereby the outermost element tags are whereby the outermost element tags are
prefixed with "AuthReq". Its declaration prefixed with "AuthReq". Its declaration
coincides with the Packaged Content's coincides with the Packaged Content's
declaration (cf. IOTP Specification). It declaration (cf. IOTP Specification). It
encapsulates the authentication challenge encapsulates the authentication challenge
value. The content of this information is value. The content of this information is
defined in the supplement for a payment defined in the supplement for a payment
protocol. protocol.
AuthResPackagedContent The Authentication Response Packaged AuthResPackagedContent The Authentication Response Packaged
Content originates from a Authentication Content originates from a Authentication
Response Component's content whereby the Response Component's content whereby the
outermost element tags are prefixed with outermost element tags are prefixed with
"AuthRes". "AuthRes".
Its declaration coincides with the Its declaration coincides with the
Packaged Content's declaration (cf. IOTP Packaged Content's declaration (cf. IOTP
Specification). It encapsulates the Specification). It encapsulates the
authentication response value. The authentication response value. The
content of this information is defined in content of this information is defined in
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).
BrandSelBrandInfoPackagedContent BrandSelBrandInfoPackagedContent
This contains any additional data that This contains any additional data that
may be required by a particular payment 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.
BrandSelProtocolAmountInfoPackagedContent BrandSelProtocolAmountInfoPackagedContent
This contains any additional data that This contains any additional data that
may be required by a particular payment 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.
BrandSelCurrencyAmountInfoPackagedContent BrandSelCurrencyAmountInfoPackagedContent
This contains any additional data that is This contains any additional data that is
payment brand and currency specific in 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 IDs to access some mall data, contain IDs to access some mall data,
but not cryptographic keys. Its Packaged but not cryptographic keys. Its Packaged
declaration coincides with the Content's declaration coincides with the Content's
declaration (cf. IOTP Specification). declaration (cf. IOTP Specification).
PackagedContent Generic Container for non-IOTP data (cf. PackagedContent Generic Container for non-IOTP data (cf.
IOTP Specification). IOTP Specification).
PayProtocolPackagedContent PayProtocolPackagedContent
The Pay Protocol Packaged Content The Pay Protocol Packaged Content
originates from a Pay Protocol 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).
PaySchemePackagedContent PaySchemePackagedContent
The PayScheme Packaged Content originates The PayScheme Packaged Content originates
from a Payment Scheme Component's content 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.
ProtocolAmountPackagedContent ProtocolAmountPackagedContent
The Protocol Amount Packaged Content The Protocol Amount Packaged Content
originates from a Protocol Amount 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.
ProtocolBrandPackagedContent ProtocolBrandPackagedContent
The Protocol Brand Packaged Content The Protocol Brand Packaged Content
originates from a Protocol Brand 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.
ResponsePackagedContent ResponsePackagedContent
Container for authentication response Container for authentication response
data. Its content originates from a 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).
TradingRoleDataPackagedContent TradingRoleDataPackagedContent
The TradingRoleData Packaged Content The TradingRoleData Packaged Content
originates from a TradingRoleData 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
protocol. The Name attribute in this protocol. The Name attribute in this
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". See [SET/IOTP] for
more information.
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: XML definition:
<!ENTITY % AuthReqPackagedContent "PackagedContent"> <!ENTITY % AuthReqPackagedContent "PackagedContent">
skipping to change at page 60, line 5 skipping to change at page 61, line 10
"PackagedContent"> "PackagedContent">
<!ENTITY % BrandSelCurrencyAmountPackagedContent <!ENTITY % BrandSelCurrencyAmountPackagedContent
"PackagedContent"> "PackagedContent">
<!ENTITY % ProtocolAmountPackagedContent <!ENTITY % ProtocolAmountPackagedContent
"PackagedContent"> "PackagedContent">
<!ENTITY % PayProtocolPackagedContent "PackagedContent"> <!ENTITY % 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.,
appropriate point of view at the interface between the IOTP the 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
completely mimic the more detailed view on the actual payment by the not completely mimic the more detailed view on the actual payment by
actual Existing Payment Software or IOTP Payment Bridge. the actual 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
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
skipping to change at page 61, line 15 skipping to change at page 62, line 24
created and transmitted to the Consumer. created and transmitted to the Consumer.
Suspended The IOTP transaction has been suspended Suspended The IOTP transaction has been suspended
before the order request block has been before the order request block has been
transmitted to the Consumer. transmitted to the Consumer.
Implicitly, the payment is also deferred. Implicitly, the payment is also deferred.
CompletedOk The IOTP Order Request has been CompletedOk The IOTP Order Request has been
successfully created and transmitted to successfully created and transmitted to
the Consumer. Actually, this process the Consumer. Actually, this process
state indicates only that the order state indicates only that the order
processing has been finished. processing has been finished.
But it contains no indication about the But it contains no indication about the
status of the actual payment, which is status of the actual payment, which is
accepted by the Payment Handler. accepted by the Payment Handler.
However, successful order processing However, successful order processing
signals the IOTP Application Core that a signals the IOTP Application Core that a
payment with some specific parameters is payment with some specific parameters is
expected within the near future. And this expected within the near future. And this
signal might be used by the Existing signal might be used by the Existing
Payment Software for similar purposes. Payment Software for similar purposes.
This attribute might be interpreted as This attribute might be interpreted as
successful preparation of the payment successful preparation of the payment
system. system.
Particularly, it is expected that the Particularly, it is expected that the
Existing Payment Software maps this IOTP Existing Payment Software maps this IOTP
status value to some other internal status value to some other internal
value, e.g. "NotYetStarted", that is more value, e.g., "NotYetStarted", that is more
accurate from its point of view. accurate from its point of view.
As IOTP provides no communication channel As IOTP provides no communication channel
between the Merchant and Payment Handler, between the Merchant and Payment Handler,
any change of payment process state will any change of payment process state will
be initiated out-of-band to IOTP, e.g. by be initiated out-of-band to IOTP, e.g., by
electronic statements of account or electronic statements of account or
payment scheme specific mechanisms. payment scheme specific mechanisms.
Failed The IOTP transaction, i.e. order Failed The IOTP transaction, i.e., order
processing, has failed for some processing, has failed for some
(business) reason and it is known that no (business) reason and it is known that no
payment will occur. payment will occur.
This indication might be used to clear This indication might be used to clear
all data about this transaction within all data about this transaction within
the Existing Payment Bridge (by the Existing Payment Bridge (by
"RemovePaymentLog" or "RemovePaymentLog" or
"ChangeProcessState") or to reverse any "ChangeProcessState") or to reverse any
preparation (with the Payment Handler preparation (with the Payment Handler
out-of-band to IOTP). out-of-band to IOTP).
However, the ideal point of view of IOTP However, the ideal point of view of IOTP
suspects that the actual payment suspects that the actual payment
transaction has been neither started nor transaction has been neither started nor
initiated. initiated.
ProcessError The IOTP transaction, i.e. order ProcessError The IOTP transaction, i.e., order
processing, has failed for some processing, has failed for some
(technical) reason and it is known that (technical) reason and it is known that
no payment will occur. no payment will occur.
This indication might be used to clear This indication might be used to clear
all data about this transaction within all data about this transaction within
the Existing Payment Bridge (by the Existing Payment Bridge (by
"RemovePaymentLog" or "RemovePaymentLog" or
"ChangeProcessState") or to reverse any "ChangeProcessState") or to reverse any
preparation (with the Payment Handler preparation (with the Payment Handler
skipping to change at page 62, line 31 skipping to change at page 63, line 43
the Existing Payment Bridge (by the Existing Payment Bridge (by
"RemovePaymentLog" or "RemovePaymentLog" or
"ChangeProcessState") or to reverse any "ChangeProcessState") or to reverse any
preparation (with the Payment Handler preparation (with the Payment Handler
out-of-band to IOTP). out-of-band to IOTP).
However, the ideal point of view of IOTP However, the ideal point of view of IOTP
suspects that the actual payment suspects that the actual payment
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 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 is set during brand selection but it
normally will not change during the whole brand normally will not change during the whole brand
selection process. selection process.
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.
Suspended The payment transaction has been Suspended The payment transaction has been
suspended. Suspension may occur anywhere suspended. Suspension may occur anywhere
during brand selection (with the during brand selection (with the
Merchant) or payment processing (with the Merchant) or payment processing (with the
Payment Handler). On resumption, the IOTP Payment Handler). On resumption, the IOTP
Application Core and the IOTP Payment Application Core and the IOTP Payment
Bridge have to use other internal data to Bridge have to use other internal data to
decide whether brand selection or actual decide whether brand selection or actual
payment processing needs to be continued, payment processing needs to be continued,
i.e., whether the process state needs to i.e., whether the process state needs to
be reset to "NotYetStarted" or be reset to "NotYetStarted" or
"InProgress". "InProgress".
Note that the Payment API assumes Note that the Payment API assumes
stateless brand selection by the IOTP stateless brand selection by the IOTP
Payment Bridge. Typically, any suspension Payment Bridge. Typically, any suspension
during brand selection requires the during brand selection requires the
repetition of the whole process. Hereby, repetition of the whole process. Hereby,
the IOTP Application Core might need to the IOTP Application Core might need to
consider any already negotiated consider any already negotiated
conditions in a brand depended purchase conditions in a brand depended purchase
(brand, protocol). (brand, protocol).
CompletedOk The successful payment has been CompletedOk The successful payment has been
acknowledged by the Payment Handler, i.e. acknowledged by the Payment Handler, i.e.,
the successful IOTP Payment Response has the successful IOTP Payment Response has
been received. been received.
Implicitly, this implies successful order Implicitly, this implies successful order
processing. processing.
Failed The IOTP transaction, i.e. order or Failed The IOTP transaction, i.e., order or
payment processing, has failed for some payment processing, has failed for some
(business) reason. In either case it is (business) reason. In either case it is
known that the payment will not succeed. known that the payment will not succeed.
ProcessError The IOTP transaction, i.e. order or ProcessError The IOTP transaction, i.e., order or
payment processing, has failed for some payment processing, has failed for some
(technical) reason. (technical) reason.
However, the local process state might be However, the local process state might be
different from that of Payment Handler. different from that of Payment Handler.
Table 6: Consumer Table 6: Consumer
3.3.3 Payment Handler 3.3.3. Payment Handler
The Payment Handler is responsible for the actual payment processing. 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 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.
Note that this does not assume that the Note that this does not assume that the
"StartPaymentPaymentHandler" API function "StartPaymentPaymentHandler" API function
has been called. has been called.
Suspended The payment transaction has been Suspended The payment transaction has been
suspended. suspended.
CompletedOk The payment has been processed, CompletedOk The payment has been processed,
successfully, i.e. the IOTP Payment successfully, i.e., the IOTP Payment
Response Block was created and Response Block was created and
transmitted to the Consumer. transmitted to the Consumer.
Failed The payment transaction, has finally Failed The payment transaction, has finally
failed for some (business) reason. failed for some (business) reason.
Note that this value encodes the payment Note that this value encodes the payment
state reported by the IOTP Payment Bridge state reported by the IOTP Payment Bridge
on "InquireProcessState". It neither on "InquireProcessState". It neither
reflects whether the payment receipt has reflects whether the payment receipt has
been inquired nor whether the IOTP been inquired nor whether the IOTP
Payment Response Block has been created Payment Response Block has been created
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 function 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
skipping to change at page 66, line 36 skipping to change at page 68, line 5
<!ATTLIST BrandItem <!ATTLIST BrandItem
BrandId CDATA #REQUIRED BrandId CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
BrandName CDATA #REQUIRED BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED > BrandNarrative CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.1.2 Find Accepted Payment Protocol 4.1.2. Find Accepted Payment Protocol
This API function determines the instances of payment protocols (and This API function determines the instances of payment protocols (and
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 the function responds with both the supported brand identifiers and
payment protocols being specified by the Brand Elements. the payment protocols being specified 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
multiple merchants that share the some IOTP merchant system multiple merchants that share the some IOTP merchant system
o Wallet Identifier - managed by the IOTP Application Core o Wallet Identifier - managed by the IOTP Application Core
o (Brand) Packaged Content - further payment brand description; o (Brand) Packaged Content - further payment brand description;
returned by "Find Accepted Payment Brand"; this elements are returned by "Find Accepted Payment Brand"; this elements are
only provided iff the Brand Identifier is set only provided if the Brand Identifier is set
o Merchant Data - specific data used by the IOTP Payment Bridge o Merchant Data - specific data used by the IOTP Payment Bridge
which is managed in the IOTP Application Core. which is managed in the IOTP Application Core.
XML definition: XML definition:
<!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*, <!ELEMENT FindAcceptedPaymentProtocol (BrandPackagedContent*,
MerchantData?) > MerchantData?) >
<!ATTLIST FindAcceptedPaymentProtocol <!ATTLIST FindAcceptedPaymentProtocol
BrandId CDATA #IMPLIED BrandId CDATA #IMPLIED
PayDirection (Debit|Credit) #REQUIRED PayDirection (Debit|Credit) #REQUIRED
skipping to change at page 68, line 43 skipping to change at page 70, line 14
<!ELEMENT CurrencyAmount EMPTY > <!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount <!ATTLIST CurrencyAmount
CurrCodeType NMTOKEN 'ISO4217-A' CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #IMPLIED CurrCode CDATA #IMPLIED
Amount CDATA #IMPLIED > Amount CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.1.3 Get Payment Initialization Data 4.1.3. Get Payment Initialization Data
This API function provides the remaining initialization data being This API function provides the remaining initialization data being
required by the Consumer's or Payment Handler's Existing Payment required by the Consumer's or Payment Handler's Existing Payment
Software. This function might be called both for "brand dependent" Software. This function might be called both for "brand dependent"
and "brand independent" transaction types. In ether case, this and "brand independent" transaction types. In either case, this
function is called with one particular brand. function is called with one particular brand.
Input Parameters Input Parameters
o Brand Identifier - returned by "Find Accepted Payment Brand" o Brand Identifier - returned by "Find Accepted Payment Brand"
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 Payment Direction o Payment Direction
o Currency Code and Currency - from the Brand List Component's o Currency Code and Currency - from the Brand List Component's
Currency Amount Element Currency Amount Element
skipping to change at page 70, line 37 skipping to change at page 72, line 11
MerchantOrgId CDATA #IMPLIED MerchantOrgId CDATA #IMPLIED
WalletID CDATA #IMPLIED WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
o OkFrom, OkTo - for insertion in the Payment Component o OkFrom, OkTo - for insertion in the Payment Component
o (TradingRoleData) Packaged Content - further payment protocol o (TradingRoleData) Packaged Content - further payment protocol
description; the Name Attribute of the packaged Content description; the Name Attribute of the packaged Content
element must include "Payment:" as the prefix, element must include "Payment:" as the prefix,
for example "Payment:SET-OD". for example "Payment:SET-OD". For more information, see
[SET/IOTP].
o (Order) Packaged Content - defaults to the supplied order o (Order) Packaged Content - defaults to the supplied order
packaged content if omitted. packaged content if omitted.
XML definition: XML definition:
<!ELEMENT GetPaymentInitializationDataResponse <!ELEMENT GetPaymentInitializationDataResponse
(OrderPackagedContent*, (OrderPackagedContent*,
TradingRoleDataPackagedContent*) > TradingRoleDataPackagedContent*) >
<!ATTLIST GetPaymentInitializationDataResponse <!ATTLIST GetPaymentInitializationDataResponse
OkFrom CDATA #IMPLIED OkFrom CDATA #IMPLIED
OkTo CDATA #IMPLIED> OkTo CDATA #IMPLIED>
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.1.4 Inquire Authentication Challenge 4.1.4. Inquire Authentication Challenge
This API function inquires any payment protocol specific This API function inquires any payment protocol specific
authentication challenge value from the IOTP Payment Bridge. In authentication challenge value from the IOTP Payment Bridge. In
Baseline IOTP this API function is called by the Merchant (or Baseline IOTP this API function is called by the Merchant (or
Financial Institution). The IOTP Application Core may propose a Financial Institution). The IOTP Application Core may propose a
choice of algorithms to the IOTP Payment Bridge. However, the IOTP choice of algorithms to the IOTP Payment Bridge. However, the IOTP
Payment Bridge may ignore the proposal and select some other Payment Bridge may ignore the proposal and select some other
algorithm. algorithm.
The inquiry is assumed to be stateless. E.g., the IOTP Application The inquiry is assumed to be stateless. E.g., the IOTP Application
Core may check the returned algorithm and stop transaction processing Core may check the returned algorithm and stop transaction processing
without notifying the IOTP Payment Bridge. without notifying the IOTP Payment Bridge.
The IOTP Application Core may issue several API calls to the IOTP The IOTP Application Core may issue several API calls to the IOTP
Payment Bridge to build up the IOTP Authentication Request Block. Any Payment Bridge to build up the IOTP Authentication Request Block.
subsequently submitted choice of algorithms should be constrained by Any subsequently submitted choice of algorithms should be constrained
the accepted algorithms from earlier API responses. by the accepted algorithms from earlier API responses.
The IOTP Payment Bridge responds with the Business Error Code if it The IOTP Payment Bridge responds with the Business Error Code if it
does not provide any (more) authentication algorithms and challenges. does not provide any (more) authentication algorithms and challenges.
Input Parameters Input Parameters
o Authentication Identifier - the authenticator may provide its o Authentication Identifier - the authenticator may provide its
payment identifier, i.e., Payment Handler or Merchant Payment payment identifier, i.e., Payment Handler or Merchant Payment
Identifier. Identifier.
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
skipping to change at page 72, line 5 skipping to change at page 73, line 33
o list of Authentication Challenge Packaged Contents - for o list of Authentication Challenge Packaged Contents - for
insertion into the IOTP Authentication Request Component insertion into the IOTP Authentication Request Component
o Algorithm Element - for insertion into the IOTP Authentication o Algorithm Element - for insertion into the IOTP Authentication
Request Component Request Component
XML definition: XML definition:
<!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*, <!ELEMENT InquireAuthChallengeResponse (AuthReqPackagedContent*,
Algorithm) > Algorithm) >
Tables 4 and 5 explain the attributes and elements; Table 3 4.1.5. Authenticate
introduces the Error Codes.
4.1.5 Authenticate
The Consumer's IOTP Application Core defers payment protocol specific The Consumer's IOTP Application Core defers payment protocol specific
authentication processing and the current challenge value to the authentication processing and the current challenge value to the
active IOTP Payment Bridge. Alternative authentication algorithms active IOTP Payment Bridge. Alternative authentication algorithms
might be tried sequentially or offered to the user for selection. might be tried sequentially or offered to the user for selection.
Note that the IOTP Application Core has to consider both the current Note that the IOTP Application Core has to consider both the current
context and the algorithm in order to determine the responsible IOTP context and the algorithm in order to determine the responsible IOTP
Payment Bridge. Payment Bridge.
Failed authentication is reported by the Business Error Code which Failed authentication is reported by the Business Error Code which
might trigger the inquiry of the details ("Inquire Process State"). might trigger the inquiry of the details ("Inquire Process State").
Final failures might be encoded by the process state "Failed". Final failures might be encoded by the process state "Failed".
skipping to change at page 73, line 5 skipping to change at page 74, line 34
o Authentication Response Packaged Content - for insertion into o Authentication Response Packaged Content - for insertion into
the IOTP Authentication Response Component the IOTP Authentication Response Component
XML definition: XML definition:
<!ELEMENT AuthenticateResponse (AuthResPackagedContent*) > <!ELEMENT AuthenticateResponse (AuthResPackagedContent*) >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.1.6 Check Authentication Response 4.1.6. Check Authentication Response
This API function verifies the Consumer's payment protocol specific This API function verifies the Consumer's payment protocol specific
authentication response. In Baseline IOTP this API function is called authentication response. In Baseline IOTP this API function is
by the Merchant (or the Financial Institution). It is called only if called by the Merchant (or the Financial Institution). It is called
the counter party has responded with an IOTP Authentication Response only if the counter party has responded with an IOTP Authentication
Component within the Authentication Response Block. Of course, the Response Component within the Authentication Response Block. Of
IOTP Application Core traces the need of such an response. course, the IOTP Application Core traces the need of such an
response.
Due to the authentication's statelessness, all parameters (algorithm, Due to the authentication's statelessness, all parameters (algorithm,
challenge and response) are submitted to the IOTP Payment Bridge. challenge and response) are submitted to the IOTP Payment Bridge.
Authentication failure is reported by a Process State different from Authentication failure is reported by a Process State different from
"CompletedOK". "CompletedOK".
Input Parameters Input Parameters
o Authentication Identifier o Authentication Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
skipping to change at page 74, line 4 skipping to change at page 75, line 41
<!ELEMENT CheckAuthResponseResponse EMPTY > <!ELEMENT CheckAuthResponseResponse EMPTY >
<!ATTLIST CheckAuthResponseResponse <!ATTLIST CheckAuthResponseResponse
ProcessState (NotYetStarted | ProcessState (NotYetStarted |
InProgress | InProgress |
Suspended | Suspended |
CompletedOk | CompletedOk |
Failed | Failed |
ProcessError)#REQUIRED ProcessError)#REQUIRED
CompletionCode NMTOKEN #IMPLIED CompletionCode NMTOKEN #IMPLIED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
StatusDesc CDATA #IMPLIED > StatusDesc CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.2 Brand Selection Related API Calls 4.2. Brand Selection Related API Calls
4.2.1 Find Payment Instrument 4.2.1. Find Payment Instrument
This API function determines which instances of a Payment Brand, This API function determines which instances of a Payment Brand,
e.g., two Mondex cards, are present. The same physical card may even e.g., two Mondex cards, are present. The same physical card may even
represent multiple payment instruments. represent multiple payment instruments.
The IOTP Application Core supplies possible payment brand and payment The IOTP Application Core supplies possible payment brand and payment
protocol to the IOTP Payment Bridge that has to be considered when protocol to the IOTP Payment Bridge that has to be considered when
the IOTP Payment Bridge searches for appropriate payment instruments. the IOTP Payment Bridge searches for appropriate payment instruments.
This set represents the (sub)set of payment alternatives being This set represents the (sub)set of payment alternatives being
supported by the Merchant. If the IOTP Application Cote has multiple supported by the Merchant. If the IOTP Application Cote has multiple
possible payment brand/protocol, it can call this function in turn. possible payment brand/protocol, it can call this function in turn.
The Existing Payment Software responds with PayInstrument Elements The Existing Payment Software responds with PayInstrument Elements
with empty PayInstId attributes if it does not distinguish between with empty PayInstId attributes if it does not distinguish between
different payment instruments for the particular payment different payment instruments for the particular payment
alternatives. alternatives.
Note that the Payment API assumes that the values of the attributes Note that the Payment API assumes that the values of the attributes
BrandId, ProtocolId, ProtocolBrandId and the currency amount suffice BrandId, ProtocolId, ProtocolBrandId and the currency amount suffice
for the determination of the appropriate Packaged Content Element for the determination of the appropriate Packaged Content Element
skipping to change at page 75, line 38 skipping to change at page 77, line 32
ConsumerPayId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED > WalletID CDATA #IMPLIED >
Output Parameters Output Parameters
o The known Payment Instrument Identifiers, these are internal o The known Payment Instrument Identifiers, these are internal
values values
o The user-defined names of the payment instrument and their o The user-defined names of the payment instrument and their
language encoding language encoding
The Existing Payment Software responds with an empty list of The Existing Payment Software responds with an empty list of
identifiers, either if it does not distinguish between different identifiers, either if it does not distinguish between different
payment instruments or if there are no registered payment instruments payment instruments or if there are no registered payment
available despite brand support for at least one (unspecified) instruments available despite brand support for at least one
payment protocol. In the latter case, the IOTP Payment Bridge has to (unspecified) payment protocol. In the latter case, the IOTP
request the registration of a suitable payment instrument at a Payment Bridge has to request the registration of a suitable
subsequent step of the payment process. payment instrument at a subsequent step of the payment process.
XML definition: XML definition:
<!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) > <!ELEMENT FindPaymentInstrumentResponse (PayInstrument*) >
<!ELEMENT PayInstrument EMPTY > <!ELEMENT PayInstrument EMPTY >
<!ATTLIST PayInstrument <!ATTLIST PayInstrument
Id CDATA #REQUIRED Id CDATA #REQUIRED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
PayInstName CDATA #REQUIRED > PayInstName CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.2.2 Check Payment Possibility 4.2.2. Check Payment Possibility
This API function checks whether a payment (both debit and credit) This API function checks whether a payment (both debit and credit)
can go ahead. It can be used, for example, to check can go ahead. It can be used, for example, to check
o if there are sufficient funds available in a particular o if there are sufficient funds available in a particular currency
currency for an electronic cash payment brand, for an electronic cash payment brand,
o whether there is sufficient value space left on the payment o whether there is sufficient value space left on the payment
instrument for payment refund, instrument for payment refund,
o whether required system resources are available and properly o whether required system resources are available and properly
configured, e.g., serial ports or baud rate, configured, e.g., serial ports or baud rate,
o whether environment requirements are fulfilled, e.g., chip card o whether environment requirements are fulfilled, e.g., chip card
reader presence or Internet connection. reader presence or Internet connection.
If the payment method is based on external components, e.g., magnetic If the payment method is based on external components, e.g., magnetic
stripe or chip cards, and the check accesses the medium, the existing stripe or chip cards, and the check accesses the medium, the existing
payment method should not mutually exclusive lock system resources, payment method should not mutually exclusive lock system resources,
e.g., serial port or modem, that may also be required by other e.g., serial port or modem, that may also be required by other
Existing Payment Software, e.g., multiple payment software components Existing Payment Software, e.g., multiple payment software components
may share the same card reader. If this happens for API internal may share the same card reader. If this happens for API internal
request processing, the function has to unlock these components prior request processing, the function has to unlock these components prior
to return. Otherwise, the payment may not proceed if the Consumer to return. Otherwise, the payment may not proceed if the Consumer
cancels immediately and decides to use another payment instrument. In cancels immediately and decides to use another payment instrument.
this event the previous IOTP Payment Bridge is not notified about the In this event the previous IOTP Payment Bridge is not notified about
change. the change.
This function call happens immediately after the Consumer's payment This function call happens immediately after the Consumer's payment
instrument selection. For example, if the payment instrument is a instrument selection. For example, if the payment instrument is a
chip card, that is not inserted in the chip card reader, the Consumer chip card, that is not inserted in the chip card reader, the Consumer
may be prompted for its insertion. However, the Consumer should be may be prompted for its insertion. However, the Consumer should be
able to hit some 'skip' button, if the payment check is part of the able to hit some 'skip' button, if the payment check is part of the
actual payment protocol, too. Finally, the IOTP Payment Bridge may actual payment protocol, too. Finally, the IOTP Payment Bridge may
provide only a subset of these capabilities or may even directly provide only a subset of these capabilities or may even directly
generate a successful response without any checks. generate a successful response without any checks.
Input Parameters Input Parameters
o Brand Identifier - user selection o Brand Identifier - user selection
o Payment Instrument Identifier - user selection o Payment Instrument Identifier - user selection
o Currency Code and Currency Code Type - copied from the selected o Currency Code and Currency Code Type - copied from the selected
Currency Amount Element Currency Amount Element
o Payment Amount - copied from the selected Currency Amount o Payment Amount - copied from the selected Currency Amount Element
Element
o Payment Direction - copied from the selected Trading Protocol o Payment Direction - copied from the selected Trading Protocol
Option Block Option Block
o Protocol Identifier - copied from the selected Pay Protocol o Protocol Identifier - copied from the selected Pay Protocol
Element Element
o Protocol Brand Identifier - copied from the selected Protocol o Protocol Brand Identifier - copied from the selected Protocol
Brand Element of the Brand List Component which relates to the Brand Element of the Brand List Component which relates to the
selected Brand Element, if any selected Brand Element, if any
o Consumer Payment Identifier - Consumer's unique reference to o Consumer Payment Identifier - Consumer's unique reference to the
the current payment transaction current payment transaction
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o (Brand) Packaged Content - copied from the selected Brand o (Brand) Packaged Content - copied from the selected Brand Element
Element
o (Protocol Amount) Packaged Content - copied from the selected o (Protocol Amount) Packaged Content - copied from the selected
Protocol Amount Element Protocol Amount Element
o (Protocol) Packaged Content - copied from the selected Pay o (Protocol) Packaged Content - copied from the selected Pay
Protocol Element Protocol Element
o (Protocol Brand) Packaged Content - copied from the selected o (Protocol Brand) Packaged Content - copied from the selected
Protocol Brand Element of the Brand List Component which Protocol Brand Element of the Brand List Component which relates
relates to the selected Brand Element, if any to the selected Brand Element, if any
XML definition: XML definition:
<!ELEMENT CheckPaymentPossibility (BrandPackagedContent*, <!ELEMENT CheckPaymentPossibility (BrandPackagedContent*,
ProtocolBrand? ProtocolBrand?
ProtocolAmountPackagedContent*, ProtocolAmountPackagedContent*,
PayProtocolPackagedContent*> PayProtocolPackagedContent*>
<!ATTLIST CheckPaymentPossibility <!ATTLIST CheckPaymentPossibility
BrandId CDATA #REQUIRED BrandId CDATA #REQUIRED
PaymentInstrumentId CDATA #IMPLIED PaymentInstrumentId CDATA #IMPLIED
skipping to change at page 77, line 47 skipping to change at page 79, line 44
ConsumerPayId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
o three Brand Selection Info Packaged Content elements - for o three Brand Selection Info Packaged Content elements - for
insertion into the Brand Selection component insertion into the Brand Selection component
o Brand - additional data about the payment brand o Brand - additional data about the payment brand
o Protocol Amount - additional data about the payment protocol o Protocol Amount - additional data about the payment protocol
o Currency Amount - additional payment brand and currency o Currency Amount - additional payment brand and currency specific
specific data data
XML definition: XML definition:
<!ELEMENT CheckPaymentPossibilityResponse <!ELEMENT CheckPaymentPossibilityResponse
(BrandSelBrandInfoPackagedContent*, (BrandSelBrandInfoPackagedContent*,
BrandSelProtocolAmountInfoPackagedContent*, BrandSelProtocolAmountInfoPackagedContent*,
BrandSelCurrencyAmountInfoPackagedContent*) > BrandSelCurrencyAmountInfoPackagedContent*) >
<!ATTLIST CheckPaymentPossibilityResponse > <!ATTLIST CheckPaymentPossibilityResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.3 Payment Transaction Related API calls 4.3. Payment Transaction Related API calls
These Payment API calls may be made either by the Consumer's or These Payment API calls may be made either by the Consumer's or
Payment Handler's IOTP Application Core. Payment Handler's IOTP Application Core.
4.3.1 Start Payment Consumer 4.3.1. Start Payment Consumer
This API function initiates the actual payment transaction at the This API function initiates the actual payment transaction at the
Consumer side. The IOTP Payment Bridge and the Existing Payment Consumer side. The IOTP Payment Bridge and the Existing Payment
Software perform all necessary initialization and preparation for Software perform all necessary initialization and preparation for
payment transaction processing. This includes the reservation of payment transaction processing. This includes the reservation of
external periphery. E.g., 1) the Consumer's chip card reader needs to external periphery. E.g., 1) the Consumer's chip card reader needs
be protected against access from other software components, 2) the to be protected against access from other software components, 2) the
insertion of the chip card may be requested, 3) the Internet insertion of the chip card may be requested, 3) the Internet
connection may be re-established, or 4) the Payment Handler may open connection may be re-established, or 4) the Payment Handler may open
a mutual exclusive session to the security hardware. a mutual exclusive session to the security hardware.
The IOTP Payment Bridge monitors the payment progress and stores the The IOTP Payment Bridge monitors the payment progress and stores the
current payment states such that resumption - even after power current payment states such that resumption - even after power
failures - remains possible. Note that the IOTP Application Core failures - remains possible. Note that the IOTP Application Core
supplies only a subset of the following input parameter to the supplies only a subset of the following input parameter to the
associated resumption API function and refers to the payment associated resumption API function and refers to the payment
transaction through the party's payment identifier. transaction through the party's payment identifier.
Input Parameters Input Parameters
o Brand Identifier - copied from the selected Brand Element o Brand Identifier - copied from the selected Brand Element
o Payment Instrument Identifier - the user selection o Payment Instrument Identifier - the user selection
o Currency Code and Currency - copied from the selected Currency o Currency Code and Currency - copied from the selected Currency
Amount Element Amount Element
skipping to change at page 78, line 45 skipping to change at page 81, line 4
o Brand Identifier - copied from the selected Brand Element o Brand Identifier - copied from the selected Brand Element
o Payment Instrument Identifier - the user selection o Payment Instrument Identifier - the user selection
o Currency Code and Currency - copied from the selected Currency o Currency Code and Currency - copied from the selected Currency
Amount Element Amount Element
o Payment Amount - copied from the selected Currency Amount o Payment Amount - copied from the selected Currency Amount
Element Element
o Payment Direction - copied from the Brand List Component o Payment Direction - copied from the Brand List Component
o Protocol Identifier - copied from the selected Payment Protocol o Protocol Identifier - copied from the selected Payment Protocol
Element Element
o Protocol Brand Element - further information; copied from the o Protocol Brand Element - further information; copied from the
Protocol Brand Element of the Brand List Component which Protocol Brand Element of the Brand List Component which
relates to the selected Brand Element, if any relates to the selected Brand Element, if any
o OkFrom, OkTo - copied from the Payment Component o OkFrom, OkTo - copied from the Payment Component
o Consumer Payment Identifier - Consumer's unique reference to o Consumer Payment Identifier - Consumer's unique reference to
the current payment transaction the current payment transaction
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
o Call Back Language List. This list is required if the Call Back o Call Back Language List. This list is required if the Call Back
Function is set Function is set
o (Brand) Packaged Content - further payment brand description; o (Brand) Packaged Content - further payment brand description;
copied from the selected Brand Element's content copied from the selected Brand Element's content
o (Protocol Amount) Packaged Content - further payment protocol o (Protocol Amount) Packaged Content - further payment protocol
description; copied from the selected Protocol Amount Element's description; copied from the selected Protocol Amount Element's
content content
o (Payment Protocol) Packaged Content - further payment protocol o (Payment Protocol) Packaged Content - further payment protocol
description; copied from the selected Pay Protocol Element's description; copied from the selected Pay Protocol Element's
content content
o (Order) Packaged Content - further order description, copied o (Order) Packaged Content - further order description, copied
skipping to change at page 80, line 15 skipping to change at page 82, line 24
XML definition: XML definition:
<!ELEMENT StartPaymentConsumerResponse <!ELEMENT StartPaymentConsumerResponse
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
<!ATTLIST StartPaymentConsumerResponse <!ATTLIST StartPaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED > ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.3.2 Start Payment Payment Handler 4.3.2. Start Payment Payment Handler
This API function initializes the Consumer initiated payment This API function initializes the Consumer initiated payment
transaction at the Payment Handler's side. Similar to the Consumer's transaction at the Payment Handler's side. Similar to the Consumer's
system, the IOTP Payment Bridge and the Existing Payment Software system, the IOTP Payment Bridge and the Existing Payment Software
perform all necessary initialization and preparation for payment perform all necessary initialization and preparation for payment
transaction processing. transaction processing.
Input Parameters Input Parameters
o Brand Identifier - copied from the Consumer selected Brand o Brand Identifier - copied from the Consumer selected Brand
Element Element
o Consumer Payment Identifier - copied from the Payment Scheme o Consumer Payment Identifier - copied from the Payment Scheme
Component Component
skipping to change at page 80, line 44 skipping to change at page 83, line 4
o Protocol Identifier - copied from the Consumer selected o Protocol Identifier - copied from the Consumer selected
Payment Protocol Element Payment Protocol Element
o Protocol Brand Identifier - copied from the Brand Protocol o Protocol Brand Identifier - copied from the Brand Protocol
Element of the Brand List Component which relates to the Element of the Brand List Component which relates to the
Consumer selected Brand Element, if any Consumer selected Brand Element, if any
o OkFrom, OkTo - copied from the Payment Component o OkFrom, OkTo - copied from the Payment Component
o Payment Handler Payment Identifier - Payment Handler's unique o Payment Handler Payment Identifier - Payment Handler's unique
reference to the current payment transaction reference to the current payment transaction
o Merchant Organisation Identifier - copied from the Merchant's o Merchant Organisation Identifier - copied from the Merchant's
Organisation Element Organisation Element
o Wallet Identifier - renaming to till identifier neglected - o Wallet Identifier - renaming to till identifier neglected -
and/or Pass Phrase 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
o Call Back Language List. This list is required if the call back o Call Back Language List. This list is required if the call
function is set back function is set
o (Brand) Packaged Content - further payment brand description; o (Brand) Packaged Content - further payment brand description;
copied from the Consumer selected Brand Element's content copied from the Consumer selected Brand Element's content
o (Protocol Brand) Packaged Content - further information; copied o (Protocol Brand) Packaged Content - further information; copied
from the Protocol Brand Element of the Brand List Component from the Protocol Brand Element of the Brand List Component
which relates to the Consumer selected Brand Element, if any. which relates to the Consumer selected Brand Element, if any.
o (Protocol Amount) Packaged Content - further payment protocol o (Protocol Amount) Packaged Content - further payment protocol
description; copied from the Consumer selected Protocol Amount description; copied from the Consumer selected Protocol Amount
Element's content Element's content
o (Protocol) Packaged Content - further payment protocol o (Protocol) Packaged Content - further payment protocol
description; copied from the Consumer selected Pay Protocol description; copied from the Consumer selected Pay Protocol
Element's content Element's content
o (TradingRoleData) Packaged Content - further payment protocol o (TradingRoleData) Packaged Content - further payment protocol
description; the Name Attribute of the packaged contents must description; the Name Attribute of the packaged contents must
include "Payment:" as the prefix, for example "Payment:SET-OD". include "Payment:" as the prefix, for example "Payment:SET-OD".
For more information, see [SET/IOTP].
o Three Brand Selection Info Packaged Content Elements - copied o Three Brand Selection Info Packaged Content Elements - copied
from the Brand Selection Component from the Brand Selection Component
o Brand - additional data about the payment brand o Brand - additional data about the payment brand
o Protocol Amount - additional data about the payment protocol o Protocol Amount - additional data about the payment protocol
o Currency Amount - additional payment brand and currency o Currency Amount - additional payment brand and currency
specific data specific data
o (Payment Scheme) Packaged Content. o (Payment Scheme) Packaged Content.
XML definition: XML definition:
skipping to change at page 82, line 12 skipping to change at page 84, line 20
CallBackFunction CDATA #IMPLIED CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED > CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters Output Parameters
o Continuation Status o Continuation Status
o (Payment Scheme) Packaged Content - for insertion into the o (Payment Scheme) Packaged Content - for insertion into the
Payment Scheme Component of the IOTP Payment Exchange Block Payment Scheme Component of the IOTP Payment Exchange Block
The response message must contain payment schema data if the The response message must contain payment schema data if the
continuation status signals "Continue". The IOTP Application Core is continuation status signals "Continue". The IOTP Application Core is
allowed to reissue this request several times on failed analyses of allowed to reissue this request several times on failed analyses of
the response. the response.
XML definition: XML definition:
<!ELEMENT StartPaymentPaymentHandlerResponse <!ELEMENT StartPaymentPaymentHandlerResponse
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
<!ATTLIST StartPaymentPaymentHandlerResponse <!ATTLIST StartPaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED > ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.3.3 Resume Payment Consumer 4.3.3. Resume Payment Consumer
This API function resumes a previously suspended payment at the 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 Request 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 16 skipping to change at page 85, line 25
CallBackLanguageList NMTOKENS #IMPLIED > CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters Output Parameters
o Continuation Status o Continuation Status
o (Payment Scheme) Packaged Content - for insertion in the o (Payment Scheme) Packaged Content - for insertion in the
Payment Scheme Component of the next IOTP message (Payment Payment Scheme Component of the next IOTP message (Payment
Exchange or Request Block). Exchange or Request Block).
The IOTP Application Core is allowed to reissue this request several The IOTP Application Core is allowed to reissue this request several
times on failed analyses of the response. However, the IOTP Payment times on failed analyses of the response. However, the IOTP Payment
Bridge might reject the resumption request by using the "AttNotSupp" Bridge might reject the resumption request by using the "AttNotSupp"
Error Code "naming" the Consumer Payment Identifier attribute. Then Error Code "naming" the Consumer Payment Identifier attribute. Then
the Consumer has to apply normal error processing to the current the Consumer has to apply normal error processing to the current
(sub-)transaction and to issue a new Payment Request Block to the (sub-)transaction and to issue a new Payment Request Block to the
Payment Handler. Payment Handler.
XML definition: XML definition:
<!ELEMENT ResumePaymentConsumerResponse <!ELEMENT ResumePaymentConsumerResponse
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentConsumerResponse <!ATTLIST ResumePaymentConsumerResponse
ContStatus (End|Continue) #REQUIRED > ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.3.4 Resume Payment Payment Handler 4.3.4. Resume Payment Payment Handler
This API function resumes a payment at the Payment Handler side. This API function resumes a payment at the Payment Handler side.
Input Parameters Input Parameters
o Payment Handler Payment Identifier o Payment Handler Payment Identifier
o Wallet Identifier - renaming to till identifier neglected - and o Wallet Identifier - renaming to till identifier neglected - and
Pass Phrase Pass Phrase
o Call Back Function - used for end user notification/logging o Call Back Function - used for end user notification/logging
purposes purposes
o Call Back Language List. This list is required if the Call Back o Call Back Language List. This list is required if the Call Back
Function is set Function is set
o (Payment Scheme) Packaged Content - copied from the Payment o (Payment Scheme) Packaged Content - copied from the Payment
Scheme Component of the received IOTP message (Payment Exchange Scheme Component of the received IOTP message (Payment Exchange
or Request Block). or Request Block).
XML definition: XML definition:
<!ELEMENT ResumePaymentPaymentHandler <!ELEMENT ResumePaymentPaymentHandler
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandler <!ATTLIST ResumePaymentPaymentHandler
skipping to change at page 84, line 23 skipping to change at page 86, line 31
CallBackFunction CDATA #IMPLIED CallBackFunction CDATA #IMPLIED
CallBackLanguageList NMTOKENS #IMPLIED > CallBackLanguageList NMTOKENS #IMPLIED >
Output Parameters Output Parameters
o Continuation Status o Continuation Status
o (Payment Scheme) Packaged Content - for insertion in the o (Payment Scheme) Packaged Content - for insertion in the
Payment Scheme Component of the next Payment Exchange Block. Payment Scheme Component of the next Payment Exchange Block.
The response message contains payment schema specific data if the The response message contains payment schema specific data if the
continuation status signals "Continue". The IOTP Application Core is continuation status signals "Continue". The IOTP Application Core is
allowed to reissue this request several times on failed analyses of allowed to reissue this request several times on failed analyses of
the response. the response.
XML definition: XML definition:
<!ELEMENT ResumePaymentPaymentHandlerResponse <!ELEMENT ResumePaymentPaymentHandlerResponse
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
<!ATTLIST ResumePaymentPaymentHandlerResponse <!ATTLIST ResumePaymentPaymentHandlerResponse
ContStatus (End|Continue) #REQUIRED > ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
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
with the next IOTP Payment Scheme Component for submission to the responds with the next IOTP Payment Scheme Component for submission
counter party. to the counter party.
Input Parameters Input Parameters
o Payty's Payment Identifier 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.
skipping to change at page 85, line 27 skipping to change at page 87, line 36
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
o Continuation Status o Continuation Status
o (Payment Scheme) Packaged Content - for insertion in the o (Payment Scheme) Packaged Content - for insertion in the
Payment Scheme Component of the next Payment Exchange Block or Payment Scheme Component of the next Payment Exchange Block or
final Payment Response Block final Payment Response Block
The response message contains payment schema data if the continuation The response message contains payment schema data if the continuation
status signals "Continue". The IOTP Payment Bridge must signal "End", status signals "Continue". The IOTP Payment Bridge must signal
if the payment scheme data was received within an IOTP Error Block "End", if the payment scheme data was received within an IOTP Error
containing an Error Component with severity HardError. Block containing an Error Component with severity HardError.
XML definition: XML definition:
<!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) > <!ELEMENT ContinueProcessResponse (PaySchemePackagedContent*) >
<!ATTLIST ContinueProcessResponse <!ATTLIST ContinueProcessResponse
ContStatus (End|Continue) #REQUIRED > ContStatus (End|Continue) #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.3.6 Change Process State 4.3.6. Change Process State
The IOTP Application Core changes the current payment status by this The IOTP Application Core changes the current payment status by this
request. The IOTP Payment Bridge may be notified about business level request. The IOTP Payment Bridge may be notified about business
normal termination, cancellation, suspension, and processing errors. level normal termination, cancellation, suspension, and processing
Notification happens by requesting the intended process state. errors. Notification happens by requesting the intended process
state.
The IOTP Payment Bridge processes the status change and reports the The IOTP Payment Bridge processes the status change and reports the
result. result.
The IOTP Application Core has to analyze any returned process status The IOTP Application Core has to analyze any returned process status
in order to check whether the IOTP Payment Bridge has agreed to or in order to check whether the IOTP Payment Bridge has agreed to or
declined the status switch. E.g., the submitted Process State declined the status switch. E.g., the submitted Process State
"CompleteOk" may lead to the Payment Status "Failed" if the payment "CompleteOk" may lead to the Payment Status "Failed" if the payment
transaction has already failed. transaction has already failed.
Transaction Suspension is notified by the newly introduced Process Transaction Suspension is notified by the newly introduced Process
State "Suspended". The other attribute values have been taken from State "Suspended". The other attribute values have been taken from
the IOTP specification. the IOTP specification.
This API function might be called by the Consumer, Merchant, or This API function might be called by the Consumer, Merchant, or
Payment Handler for each payment transaction anytime after the Payment Handler for each payment transaction anytime after the
issuance of "FindPaymentInstrument" to the IOTP Payment Bridge by the issuance of "FindPaymentInstrument" to the IOTP Payment Bridge by the
Consumer, the issuance of "FindAcceptedPaymentBrand" by the Merchant, Consumer, the issuance of "FindAcceptedPaymentBrand" by the Merchant,
or the issuance of "StartPaymentPaymentHandler" by the Payment or the issuance of "StartPaymentPaymentHandler" by the Payment
Handler. Handler.
The Process States "CompletedOk", "Failed", and "ProcessError" are The Process States "CompletedOk", "Failed", and "ProcessError" are
final in the sense that they can not be changed on subsequent calls. final in the sense that they can not be changed on subsequent calls.
However, the API function should not return with an error code if However, the API function should not return with an error code if
such an incompatible call has been issued. Instead it should report such an incompatible call has been issued. Instead it should report
the old unchanged Process State. the old unchanged Process State.
Unknown payment transactions are reported by the Error Code Unknown payment transactions are reported by the Error Code
"AttValInvalid" pointing to the PayId attribute. "AttValInvalid" pointing to the PayId attribute.
Input Parameters Input Parameters
o Party's Payment Identifier o Party's Payment Identifier
o intended Payment Status o intended Payment Status
o intended Completion Code o intended Completion Code
skipping to change at page 87, line 29 skipping to change at page 89, line 44
Failed | Failed |
ProcessError) #REQUIRED ProcessError) #REQUIRED
PercentComplete CDATA #IMPLIED PercentComplete CDATA #IMPLIED
CompletionCode NMTOKEN #IMPLIED CompletionCode NMTOKEN #IMPLIED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
StatusDesc CDATA #IMPLIED > StatusDesc CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.4 General Inquiry API Calls 4.4. General Inquiry API Calls
The following calls are not necessarily assigned to a payment The following calls are not necessarily assigned to a payment
transaction and may be issued at any time. There are no dependencies transaction and may be issued at any time. There are no dependencies
on any other calls. on any other calls.
4.4.1 Remove Payment Log 4.4.1. Remove Payment Log
The IOTP Application Core notifies the IOTP Payment Bridge and/or the The IOTP Application Core notifies the IOTP Payment Bridge and/or the
corresponding Existing Payment Software via IOTP Payment Bridge that corresponding Existing Payment Software via IOTP Payment Bridge that
any record in the Payment Log file, that deals with the listed any record in the Payment Log file, that deals with the listed
payment transaction, might be removed. payment transaction, might be removed.
Input Parameters Input Parameters
o Party's Payment Identifier o Party's Payment Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
skipping to change at page 88, line 18 skipping to change at page 90, line 35
Output Parameters Output Parameters
XML definition: XML definition:
<!ELEMENT RemovePaymentLogResponse EMPTY > <!ELEMENT RemovePaymentLogResponse EMPTY >
<!ATTLIST RemovePaymentLogResponse > <!ATTLIST RemovePaymentLogResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.4.2 Payment Instrument Inquiry 4.4.2. Payment Instrument Inquiry
This API function retrieves the properties of the Payment Instrument. This API function retrieves the properties of the Payment Instrument.
The Payment Instrument Identifier could be omitted if this identifier The Payment Instrument Identifier could be omitted if this identifier
is derived by other means, e.g., by analysis of the currently is derived by other means, e.g., by analysis of the currently
inserted chip card. If the Payment instrument could not uniquely inserted chip card. If the Payment instrument could not uniquely
determined, the IOTP Payment Bridge may provide suitable dialogs for determined, the IOTP Payment Bridge may provide suitable dialogs for
user input. user input.
E.g., this API function might be used during problem resolution with E.g., this API function might be used during problem resolution with
the Customer Care Provider of the issuer of the payment instrument, the Customer Care Provider of the issuer of the payment instrument,
in order to inquire payment instrument specific values. in order to inquire payment instrument specific values.
Input parameters Input parameters
o Brand Identifier o Brand Identifier
skipping to change at page 89, line 13 skipping to change at page 91, line 29
o Payment Brand specific codes. o Payment Brand specific codes.
Generic codes for the Property Type List are: Generic codes for the Property Type List are:
Property Type Meaning Property Type Meaning
Balance Current balance Balance Current balance
Limit Maximum balance Limit Maximum balance
PaymentLimit Maximum payment transaction limit PaymentLimit Maximum payment transaction limit
Expiration Expiration date Expiration Expiration date
Identifier Issuer assigned identifier of the payment Identifier Issuer assigned identifier of the payment
instrument. Usually, it does not match with instrument. Usually, it does not match with
the API's payment instrument identifier. the API's payment instrument identifier.
LogEntries Number of stored payment transaction LogEntries Number of stored payment transaction
entries. The entries are numbered from 0 entries. The entries are numbered from 0
(the most recent) to some non-negative (the most recent) to some non-negative
value for the oldest entry. value for the oldest entry.
PayAmountn Payment Amount of the n-th recorded payment PayAmountn Payment Amount of the n-th recorded payment
transaction, n may negative transaction, n may negative
PayPartyn Remote party of the n-th payment recorded PayPartyn Remote party of the n-th payment recorded
transaction, n may negative transaction, n may negative
PayTimen Time of the n-th payment recorded PayTimen Time of the n-th payment recorded
transaction, n may negative transaction, n may negative
XML definition: XML definition:
skipping to change at page 90, line 4 skipping to change at page 92, line 23
o a list of zero or more sets of "Properties Types", "Property o a list of zero or more sets of "Properties Types", "Property
Values" and "Property Descriptions" Values" and "Property Descriptions"
XML definition: XML definition:
<!ELEMENT PaymentInstrumentInquiryResponse <!ELEMENT PaymentInstrumentInquiryResponse
(PaymentInstrumentProperty*) > (PaymentInstrumentProperty*) >
<!ATTLIST PaymentInstrumentInquiryResponse <!ATTLIST PaymentInstrumentInquiryResponse
xml:lang NMTOKEN #REQUIRED xml:lang NMTOKEN #REQUIRED
UnavailablePropertyList NMTOKENS #IMPLIED > UnavailablePropertyList NMTOKENS #IMPLIED >
<!ELEMENT PaymentInstrumentProperty EMPTY > <!ELEMENT PaymentInstrumentProperty EMPTY >
<!ATTLIST PaymentInstrumentProperty <!ATTLIST PaymentInstrumentProperty
PropertyType NMTOKEN #REQUIRED PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED > PropertyDesc CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.4.3 Inquire Pending Payment 4.4.3. Inquire Pending Payment
This API function reports the party's payment identifiers of any This API function reports the party's payment identifiers of any
pending payment transactions that the IOTP Payment Bridge/Existing pending payment transactions that the IOTP Payment Bridge/Existing
Payment Software recommends be completed or suspended prior to the Payment Software recommends be completed or suspended prior to the
processing of new payment transactions. It does not respond with processing of new payment transactions. It does not respond with
further transaction details. These have to be requested with "Inquire further transaction details. These have to be requested with
Process State". "Inquire Process State".
Note that the IOTP Payment Bridge has to respond without the benefit Note that the IOTP Payment Bridge has to respond without the benefit
of any pass phrase if there exist no pending payment transaction. But of any pass phrase if there exist no pending payment transaction.
if there are some pending payment transactions, the IOTP Payment But if there are some pending payment transactions, the IOTP Payment
Bridge may refuse the immediate response and may instead request the Bridge may refuse the immediate response and may instead request the
appropriate pass phase from the IOTP Application Core. 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
skipping to change at page 91, line 6 skipping to change at page 93, line 26
<!ELEMENT InquirePendingPaymentResponse (PaymentId*) > <!ELEMENT InquirePendingPaymentResponse (PaymentId*) >
<!ELEMENT PaymentId EMPTY > <!ELEMENT PaymentId EMPTY >
<!ATTLIST PaymentId <!ATTLIST PaymentId
PayId CDATA #REQUIRED > PayId CDATA #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.5 Payment Related Inquiry API Calls 4.5. Payment Related Inquiry API Calls
4.5.1 Check Payment Receipt 4.5.1. Check Payment Receipt
This function is used by the Consumer and might be used by the This function is used by the Consumer and might be used by the
Payment Handler to check the consistency, validity, and integrity of Payment Handler to check the consistency, validity, and integrity of
IOTP payment receipts which might consist of Packaged Content IOTP payment receipts which might consist of Packaged Content
Elements Elements
o from the IOTP Payment Receipt Component - provided by the o from the IOTP Payment Receipt Component - provided by the Payment
Payment Handler's "Inquire Process State" API call shortly Handler's "Inquire Process State" API call shortly before payment
before payment completion, completion,
o from Payment Scheme Components being exchanged during the o from Payment Scheme Components being exchanged during the actual
actual payment, or payment, or
o being returned by the Consumer's "Inquire Process State" API o being returned by the Consumer's "Inquire Process State" API call
call shortly before payment completion shortly before payment completion
The IOTP Application Core has to check the PayReceiptNameRefs The IOTP Application Core has to check the PayReceiptNameRefs
attribute of the IOTP Payment Receipt Component and to supply exactly attribute of the IOTP Payment Receipt Component and to supply exactly
the Packaged Content Elements being referred to. the Packaged Content Elements being referred to.
Failed verification is returns a business error. Failed verification is returns a business error.
Note that this Payment API assumes that any payment receipt builds Note that this Payment API assumes that any payment receipt builds
upon a subset of elements with reference to [IOTP]. Furthermore, the upon a subset of elements with reference to [IOTP]. Furthermore, the
Packaged Content Element have to be distinguishable by their Name Packaged Content Element have to be distinguishable by their Name
skipping to change at page 92, line 15 skipping to change at page 94, line 34
Output Parameters Output Parameters
XML definition: XML definition:
<!ELEMENT CheckPaymentReceiptResponse EMPTY > <!ELEMENT CheckPaymentReceiptResponse EMPTY >
<!ATTLIST CheckPaymentReceiptResponse > <!ATTLIST CheckPaymentReceiptResponse >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.5.2 Expand Payment Receipt 4.5.2. Expand Payment Receipt
This API function expands any IOTP payment receipt into a form which This API function expands any IOTP payment receipt into a form which
may be used for display or printing purposes. "Check Payment Receipt" may be used for display or printing purposes. "Check Payment
should be used first if there is any question of the payment receipt Receipt" should be used first if there is any question of the payment
containing errors. receipt containing errors.
The same conventions apply to the input parameter as for "Check The same conventions apply to the input parameter as for "Check
Payment Receipt" (cf. Section 4.5.1). Payment Receipt" (cf. Section 4.5.1).
Input Parameters Input Parameters
o Party's Payment Identifier o Party's Payment Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o All Packaged Content Elements that build the payment receipt o All Packaged Content Elements that build the payment receipt
XML definition: XML definition:
<!ELEMENT ExpandPaymentReceipt (PackagedContent*) > <!ELEMENT ExpandPaymentReceipt (PackagedContent*) >
<!ATTLIST ExpandPaymentReceipt <!ATTLIST ExpandPaymentReceipt
PayId CDATA #REQUIRED PayId CDATA #REQUIRED
WalletID CDATA #IMPLIED WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
skipping to change at page 93, line 4 skipping to change at page 95, line 26
o Payment Instrument Identifier o Payment Instrument Identifier
o Currency Code and Currency Code Type o Currency Code and Currency Code Type
o Payment Amount o Payment Amount
o Payment Direction o Payment Direction
o Time Stamp - issuance of the receipt o Time Stamp - issuance of the receipt
o Protocol Identifier o Protocol Identifier
o Protocol specific Transaction Identifier - this is an internal o Protocol specific Transaction Identifier - this is an internal
reference number which identifies the payment reference number which identifies the payment
o Consumer Description, Payment Handler Description, and a o Consumer Description, Payment Handler Description, and a
language annotation language annotation
o Style Sheet Net Location o Style Sheet Net Location
o Payment Property List. A list of type/value/description triples o Payment Property List. A list of type/value/description triples
which contains additional information about the payment which which contains additional information about the payment which
is not covered by any of the other output parameters; property is not covered by any of the other output parameters; property
descriptions have to consider the language annotation. descriptions have to consider the language annotation.
The Style Sheet Net Location refers to a Style Sheet (e.g. [XSLT]) The Style Sheet Net Location refers to a Style Sheet (e.g., [XSLT])
that contains presenetation information about the reported XML that contains presentation information about the reported XML encoded
encoded data. data.
XML definition: XML definition:
<!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) > <!ELEMENT ExpandPaymentReceiptResponse (PaymentProperty*) >
<!ATTLIST ExpandPaymentReceiptResponse <!ATTLIST ExpandPaymentReceiptResponse
BrandId CDATA #IMPLIED BrandId CDATA #IMPLIED
PaymentInstrumentId CDATA #IMPLIED PaymentInstrumentId CDATA #IMPLIED
Amount CDATA #IMPLIED Amount CDATA #IMPLIED
CurrCodeType NMTOKEN #IMPLIED CurrCodeType NMTOKEN #IMPLIED
CurrCode CDATA #IMPLIED CurrCode CDATA #IMPLIED
skipping to change at page 93, line 41 skipping to change at page 96, line 14
PaymentHandlerDesc CDATA #IMPLIED PaymentHandlerDesc CDATA #IMPLIED
StyleSheetNetLocn CDATA #IMPLIED> StyleSheetNetLocn CDATA #IMPLIED>
<!ELEMENT PaymentProperty EMPTY > <!ELEMENT PaymentProperty EMPTY >
<!ATTLIST PaymentProperty <!ATTLIST PaymentProperty
PropertyType NMTOKEN #REQUIRED PropertyType NMTOKEN #REQUIRED
PropertyValue CDATA #REQUIRED PropertyValue CDATA #REQUIRED
PropertyDesc CDATA #REQUIRED > PropertyDesc CDATA #REQUIRED >
The Existing Payment Software should return as many attributes as The Existing Payment Software should return as many attributes as
possible from the supplied IOTP Payment Receipt. The payment possible from the supplied IOTP Payment Receipt. The payment
supplement defines the attribute values for the payment properties. supplement defines the attribute values for the payment properties.
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.5.3 Inquire Process State 4.5.3. Inquire Process State
This API function returns the current payment state and optionally This API function returns the current payment state and optionally
further Packaged Content Elements that form the payment receipt. further Packaged Content Elements that form the payment receipt.
Called by the Payment Handler, the IOTP Payment Bridge might respond Called by the Payment Handler, the IOTP Payment Bridge might respond
with data intended for inclusion in the IOTP Payment Receipt with data intended for inclusion in the IOTP Payment Receipt
Component's Packaged Content. When the Consumer calls this function Component's Packaged Content. When the Consumer calls this function
shortly before payment completion, it may respond with further items shortly before payment completion, it may respond with further items
of the payment receipt. Such items might be created by a chip card. of the payment receipt. Such items might be created by a chip card.
Input Parameters Input Parameters
o Party's Payment Identifier o Party's Payment Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
XML definition: XML definition:
<!ELEMENT InquireProcessState EMPTY > <!ELEMENT InquireProcessState EMPTY >
<!ATTLIST InquireProcessState <!ATTLIST InquireProcessState
skipping to change at page 94, line 29 skipping to change at page 97, line 4
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
o Current Process State and Percent Complete o Current Process State and Percent Complete
o Completion Code o Completion Code
o Status Description and its language annotation o Status Description and its language annotation
o Payment Receipt Name References to all Packaged Content o Payment Receipt Name References to all Packaged Content
Elements that build the payment receipt (cf. Section 4.5.1), Elements that build the payment receipt (cf. Section 4.5.1),
even if they have not been created so far (Consumer's share) even if they have not been created so far (Consumer's share)
o Any Packaged Content Element being available that form the o Any Packaged Content Element being available that form the
payment receipt payment receipt
The IOTP provides a linking capability to the payment receipt The IOTP provides a linking capability to the payment receipt
delivery. Instead of encapsulating the whole payment specific data delivery. Instead of encapsulating the whole payment specific data
into the packaged content of the payment receipt, other Payment into the packaged content of the payment receipt, other Payment
Scheme Components' Packaged Content might be referred to. Scheme Components' Packaged Content might be referred to.
XML definition: XML definition:
<!ELEMENT InquireProcessStateResponse <!ELEMENT InquireProcessStateResponse
(PackagedContent*) > (PackagedContent*) >
<!ATTLIST InquireProcessStateResponse <!ATTLIST InquireProcessStateResponse
ProcessState (NotYetStarted | ProcessState (NotYetStarted |
InProgress | InProgress |
skipping to change at page 95, line 8 skipping to change at page 97, line 33
ProcessError) #REQUIRED ProcessError) #REQUIRED
PercentComplete CDATA #IMPLIED PercentComplete CDATA #IMPLIED
CompletionCode NMTOKEN #IMPLIED CompletionCode NMTOKEN #IMPLIED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
StatusDesc CDATA #IMPLIED StatusDesc CDATA #IMPLIED
PayReceiptNameRefs NMTOKENS #IMPLIED > PayReceiptNameRefs NMTOKENS #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.5.4 Start Payment Inquiry 4.5.4. Start Payment Inquiry
This API function responds with any additional payment scheme This API function responds with any additional payment scheme
specific data that is needed by the Payment Handler for Consumer specific data that is needed by the Payment Handler for Consumer
initiated payment transaction inquiry processing. Probably, the IOTP initiated payment transaction inquiry processing. Probably, the IOTP
Payment Bridge (or the corresponding Existing Payment Software) has Payment Bridge (or the corresponding Existing Payment Software) has
to determine the payment related items that were provided with the to determine the payment related items that were provided with the
"Start Payment Consumer" API function call. "Start Payment Consumer" API function call.
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
XML definition: XML definition:
<!ELEMENT StartPaymentInquiry EMPTY > <!ELEMENT StartPaymentInquiry EMPTY >
<!ATTLIST StartPaymentInquiry <!ATTLIST StartPaymentInquiry
ConsumerPayId CDATA #REQUIRED ConsumerPayId CDATA #REQUIRED
WalletID CDATA #IMPLIED WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED > Passphrase CDATA #IMPLIED >
Output Parameters Output Parameters
skipping to change at page 95, line 43 skipping to change at page 98, line 25
the Payment Scheme Component of the Inquiry Request Block the Payment Scheme Component of the Inquiry Request Block
XML definition: XML definition:
<!ELEMENT StartPaymentInquiryResponse <!ELEMENT StartPaymentInquiryResponse
(PaySchemePackagedContent*) > (PaySchemePackagedContent*) >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.5.5 Inquire Payment Status 4.5.5. Inquire Payment Status
The Payment Handler calls this API function for Consumer initiated The Payment Handler calls this API function for Consumer initiated
inquiry processing. It differs from the previous "Inquire Process inquiry processing. It differs from the previous "Inquire Process
State" API function by the optional inclusion of payment scheme State" API function by the optional inclusion of payment scheme
specific data. The response may encapsulate further details about the specific data. The response may encapsulate further details about
payment transaction. the payment transaction.
Input Parameters Input Parameters
o Payment Handler Payment Identifier o Payment Handler Payment Identifier
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o (Payment Scheme) Packaged Content - copied from the Inquiry o (Payment Scheme) Packaged Content - copied from the Inquiry
Request Block's Payment Scheme Component Request Block's Payment Scheme Component
XML definition: XML definition:
skipping to change at page 96, line 47 skipping to change at page 99, line 27
CompletedOk | CompletedOk |
Failed | Failed |
ProcessError) #REQUIRED ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED CompletionCode NMTOKEN #IMPLIED
xml:lang NMTOKEN #IMPLIED xml:lang NMTOKEN #IMPLIED
StatusDesc CDATA #IMPLIED > StatusDesc CDATA #IMPLIED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
4.6 Other API Calls 4.6. Other API Calls
4.6.1 Manage Payment Software
4.6.1. Manage Payment Software
The following API function notifies the IOTP Payment Bridge about the The following API function notifies the IOTP Payment Bridge about the
intended registration, modification, or deletion of a payment intended registration, modification, or deletion of a payment
instrument. The actual processing is up to the IOTP Payment Bridge. instrument. The actual processing is up to the IOTP Payment Bridge.
This API request may also be used to activate the IOTP Payment Bridge This API request may also be used to activate the IOTP Payment Bridge
(and the corresponding Existing Payment Software) for general (and the corresponding Existing Payment Software) for general
administration purposes. administration purposes.
Input Parameters Input Parameters
o Brand Identifier o Brand Identifier
o Protocol Identifier o Protocol Identifier
o Any action code: o Any action code:
skipping to change at page 97, line 26 skipping to change at page 100, line 4
o Brand Identifier o Brand Identifier
o Protocol Identifier o Protocol Identifier
o Any action code: o Any action code:
o New - add new payment method / instrument o New - add new payment method / instrument
o Update - change the payment method's / instrument's data o Update - change the payment method's / instrument's data
o Delete - delete a payment method / instrument o Delete - delete a payment method / instrument
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
o (Brand) Packaged Content - further payment brand description o (Brand) Packaged Content - further payment brand description
o (Pay Protocol) Packaged Content - further payment protocol o (Pay Protocol) Packaged Content - further payment protocol
description description
o (Protocol Amount) Packaged Content - further payment protocol o (Protocol Amount) Packaged Content - further payment protocol
description description
If the Action attribute is set, the Brand and Protocol Identifier If the Action attribute is set, the Brand and Protocol Identifier
have to also be set. The IOTP Payment Bridge has to provide the have to also be set. The IOTP Payment Bridge has to provide the
required user dialogs and selection mechanisms. E.g., updates and required user dialogs and selection mechanisms. E.g., updates and
deletions may require the selection of the payment instrument. A new deletions may require the selection of the payment instrument. A new
wallet might be silently generated on the supplement of a new Wallet wallet might be silently generated on the supplement of a new Wallet
Identifier or after an additional end user acknowledge. The IOTP Identifier or after an additional end user acknowledge. The IOTP
Application Core should not provide any pass phrases for new wallets. Application Core should not provide any pass phrases for new wallets.
Instead, the IOTP Payment Bridge has to request and verify them, Instead, the IOTP Payment Bridge has to request and verify them,
which may return their value to the IOTP Application Core in plain which may return their value to the IOTP Application Core in plain
text. In addition, the IOTP Payment Bridge returns the supported text. In addition, the IOTP Payment Bridge returns the supported
authentication algorithms when a new brand and protocol pair has been authentication algorithms when a new brand and protocol pair has been
registered. registered.
If the "Action" attribute is omitted, the IOTP Payment Bridge which If the "Action" attribute is omitted, the IOTP Payment Bridge which
is responsible for the Existing Payment Software pops up in a general is responsible for the Existing Payment Software pops up in a general
interactive mode. interactive mode.
XML definition: XML definition:
<!ELEMENT ManagePaymentSoftware (BrandPackagedContent*, <!ELEMENT ManagePaymentSoftware (BrandPackagedContent*,
skipping to change at page 98, line 21 skipping to change at page 100, line 50
o An action code: o An action code:
o New - added new wallet o New - added new wallet
o Update - changed wallet's configuration o Update - changed wallet's configuration
o Delete - removed a wallet o Delete - removed a wallet
o Wallet Identifier and/or Pass Phrase o Wallet Identifier and/or Pass Phrase
The IOTP Payment Bridge does not return any information about the set The IOTP Payment Bridge does not return any information about the set
of registered payment instruments because these data items are of registered payment instruments because these data items are
dynamically inferred during the brand selection process at the dynamically inferred during the brand selection process at the
beginning of each IOTP transaction. However, the IOTP Application beginning of each IOTP transaction. However, the IOTP Application
Core has to be notified about new wallets and should be notified Core has to be notified about new wallets and should be notified
about updated and removed wallet (identifier)s". Alternatively, about updated and removed wallets (identifier). Alternatively,
removed wallets can be implicitly detected during the next brand removed wallets can be implicitly detected during the next brand
selection phase. Updated wallets do no affect the processing of the selection phase. Updated wallets do no affect the processing of the
IOTP Application Core. The IOTP Payment Bridge should only support IOTP Application Core. The IOTP Payment Bridge should only support
the addition of at most one wallet because it is not able to report the addition of at most one wallet because it is not able to report
multiple additions at once back to the IOTP Application Core. multiple additions at once back to the IOTP Application Core.
XML definition: XML definition:
<!ELEMENT ManagePaymentSoftwareResponse EMPTY > <!ELEMENT ManagePaymentSoftwareResponse EMPTY >
<!ATTLIST ManagePaymentSoftwareResponse <!ATTLIST ManagePaymentSoftwareResponse
Action (New | Action (New |
Update | Update |
Delete) #IMPLIED Delete) #IMPLIED
WalletID CDATA #IMPLIED WalletID CDATA #IMPLIED
Passphrase CDATA #IMPLIED Passphrase CDATA #IMPLIED
AuthNames NMTOKENS #REQUIRED > AuthNames NMTOKENS #REQUIRED >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
5. Call Back Function 5. Call Back Function
This API function, called by the IOTP Payment Bridge, is used to This API function, called by the IOTP Payment Bridge, is used to
provide information for Consumer or Payment Handler notification provide information for Consumer or Payment Handler notification
about the progress of the payment transaction. about the progress of the payment transaction.
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.
Input Parameters Input Parameters
o the software identifier of the caller o the software identifier of the caller
o Party's Payment Identifier o Party's Payment Identifier
o Process State and Percent Complete o Process State and Percent Complete
o Completion Code o Completion Code
o Status Description and its language annotation, text which o Status Description and its language annotation, text which
provides information about the progress of the call. It should provides information about the progress of the call. It should be
be displayed or made available to, for example, the Consumer. displayed or made available to, for example, the Consumer.
Examples of Status Description could be: Examples of Status Description could be:
o "Paying 12.30 USD to XYZ Inc" o "Paying 12.30 USD to XYZ Inc"
o "Payment completed" o "Payment completed"
o "Payment aborted" o "Payment aborted"
The valid languages are announced in the Call Back Language List The valid languages are announced in the Call Back Language List
attribute in "Start Payment X" and "Resume Payment X" API function attribute in "Start Payment X" and "Resume Payment X" API function
calls. calls.
skipping to change at page 100, line 22 skipping to change at page 103, line 6
XML definition: XML definition:
<!ELEMENT CallBackResponse EMPTY > <!ELEMENT CallBackResponse EMPTY >
<!ATTLIST CallBackResponse <!-- see below --> > <!ATTLIST CallBackResponse <!-- see below --> >
Tables 4 and 5 explain the attributes and elements; Table 3 Tables 4 and 5 explain the attributes and elements; Table 3
introduces the Error Codes. introduces the Error Codes.
Basically, the call back function accepts all input arguments or Basically, the call back function accepts all input arguments or
rejects the whole request. It may even accept malformed requests. rejects the whole request. It may even accept malformed requests.
Some payment schemes may support or require that the Consumer might Some payment schemes may support or require that the Consumer might
be able to cancel the payment at any time. The Call Back function can be able to cancel the payment at any time. The Call Back function
be used to facilitate this by returning the cancellation request on can be used to facilitate this by returning the cancellation request
the next call (using the Business Error Code and Completion Code on the next call (using the Business Error Code and Completion Code
"ConsCancelled"). "ConsCancelled").
Vice versa the Payment Handler's Application Core might use the Vice versa the Payment Handler's Application Core might use the
similar mechanism to signal its IOTP Payment Bridges any exceptional similar mechanism to signal its IOTP Payment Bridges any exceptional
need for a fast shutdown. These IOTP Payment Bridges may initiate the need for a fast shutdown. These IOTP Payment Bridges may initiate
appropriate steps for terminating/canceling all pending payment the appropriate steps for terminating/cancelling 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
The IOTP Payment APIs only supports security using pass phrase to The IOTP Payment APIs only supports security using pass phrase to
access to payment Wallet. These can be protected over TLS, which access to payment Wallet. These can be protected over TLS, which
provides stronger security at the transport layer, but provides stronger security at the transport layer, but
implementations are out the scope of this document. 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 7. References
Copyright (C) The Internet Society 2001. 7.1. Normative References
This document and translations of it may be copied and furnished to [IOTP] Burdett, D., "Internet Open Trading Protocol - IOTP
others, and derivative works that comment on or otherwise explain it version 1.0", RFC 2801, April 2000.
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of