draft-ietf-trade-iotp-v1.0-papi-03.txt   draft-ietf-trade-iotp-v1.0-papi-04.txt 
TRADE Working Group Werner Hans TRADE Working Group Werner Hans
INTERNET-DRAFT Hans-Bernhard.Beykirch INTERNET-DRAFT Hans-Bernhard.Beykirch
SIZ SIZ
Masaaki Hiroya Masaaki Hiroya
Yoshiaki Kawatsura Yoshiaki Kawatsura
Hitachi Hitachi
Expires: May 2001 November 2000 Expires: September 2001 March 2001
Payment API for v1.0 Internet Open Trading Protocol (IOTP) Payment API for v1.0 Internet Open Trading Protocol (IOTP)
------- --- --- ---- -------- ---- ------- -------- ------ ------- --- --- ---- -------- ---- ------- -------- ------
<draft-ietf-trade-iotp-v1.0-papi-03.txt> <draft-ietf-trade-iotp-v1.0-papi-04.txt>
Status of this Memo Status of this Memo
This document is intended to become an Informational RFC. This document is intended to become an Informational RFC.
Distribution of this document is unlimited. Please send comments to Distribution of this document is unlimited. Please send comments to
the TRADE working group at <ietf-trade@lists.elistx.com >, which may the TRADE working group at <ietf-trade@lists.elistx.com >, which may
be joined by sending a message with subject "subscribe" to <ietf- be joined by sending a message with subject "subscribe" to <ietf-
trade-request@lists.elistx.com>. Discussions of the TRADE working trade-request@lists.elistx.com>. Discussions of the TRADE working
group are archived at http://www.elistx.com/archives/ietf-trade. group are archived at http://www.elistx.com/archives/ietf-trade.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Copyright
Copyright (C) The Internet Society 2000. Copyright (C) The Internet Society 2001.
Abstract Abstract
The Internet Open Trading Protocol provides a data exchange format The Internet Open Trading Protocol provides a data exchange format
for trading purposes while integrating existing pure payment for trading purposes while integrating existing pure payment
protocols seamlessly. This motivates the multiple layered system protocols seamlessly. This motivates the multiple layered system
architecture which consists of at least some generic IOTP application architecture which consists of at least some generic IOTP application
core and multiple specific payment modules. core and multiple specific payment modules.
This document addresses the common interface between the IOTP This document addresses 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 an
interface provides the foundations for a plug-in- mechanism in actual interface provides the foundations for a plug-in- mechanism in actual
implementations of IOTP application cores. 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 Intended Readership
skipping to change at page 3, line 51 skipping to change at page 3, line 51
4.1.5 Authenticate.......................................72 4.1.5 Authenticate.......................................72
4.1.6 Check Authentication Response......................73 4.1.6 Check Authentication Response......................73
4.2 Brand Selection Related API Calls....................74 4.2 Brand Selection Related API Calls....................74
4.2.1 Find Payment Instrument............................74 4.2.1 Find Payment Instrument............................74
4.2.2 Check Payment Possibility..........................76 4.2.2 Check Payment Possibility..........................76
4.3 Payment Transaction Related API calls................78 4.3 Payment Transaction Related API calls................78
4.3.1 Start Payment Consumer.............................78 4.3.1 Start Payment Consumer.............................78
4.3.2 Start Payment Payment Handler......................80 4.3.2 Start Payment Payment Handler......................80
4.3.3 Resume Payment Consumer............................82 4.3.3 Resume Payment Consumer............................82
4.3.4 Resume Payment Payment Handler.....................83 4.3.4 Resume Payment Payment Handler.....................83
4.3.5 Continue Process ..................................84 4.3.5 Continue Process...................................84
4.3.6 Change Process State...............................85 4.3.6 Change Process State...............................85
4.4 General Inquiry API Calls............................87 4.4 General Inquiry API Calls............................87
4.4.1 Remove Payment Log.................................87 4.4.1 Remove Payment Log.................................87
4.4.2 Payment Instrument Inquiry.........................88 4.4.2 Payment Instrument Inquiry.........................88
4.4.3 Inquire Pending Payment............................90 4.4.3 Inquire Pending Payment............................90
4.5 Payment Related Inquiry API Calls....................91 4.5 Payment Related Inquiry API Calls....................91
4.5.1 Check Payment Receipt..............................91 4.5.1 Check Payment Receipt..............................91
4.5.2 Expand Payment Receipt.............................92 4.5.2 Expand Payment Receipt.............................92
4.5.3 Inquire Process State..............................93 4.5.3 Inquire Process State..............................93
4.5.4 Start Payment Inquiry..............................95 4.5.4 Start Payment Inquiry..............................95
skipping to change at page 7, line 12 skipping to change at page 7, line 12
schemes. The preceding agreements about the goods, payment method, schemes. The preceding agreements about the goods, payment method,
purchase amount, or delivery rules are omitted. purchase amount, or delivery rules are omitted.
Payment State Party Example Behavior Payment State Party Example Behavior
------------- ----- ---------------- ------------- ----- ----------------
Mutual Payment Handler Generation of identification Mutual Payment Handler Generation of identification
Authentication request, solvency request, or Authentication request, solvency request, or
and Init- some nonce and Init- some nonce
ialization Consumer Responses to the requests and ialization Consumer Responses to the requests and
generation of the own nonce generation of 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),
generation of the authorization generation of the authorization
skipping to change at page 9, line 24 skipping to change at page 9, line 24
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 hand,
the Payment API should not be overloaded with nice-to-haves being the Payment API should not be overloaded with nice-to-haves being
unsupported by Existing Payment Software. 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. Eventually, 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
skipping to change at page 10, line 43 skipping to change at page 10, line 43
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 expected,
that the Existing Payment Software tries to resolve many errors that the Existing Payment Software will try to resolve many errors
first by the extended exchange of Payment Exchange messages. The first by the extended exchange of Payment Exchange messages. The
most significant and visible failures arise from sudden most significant and visible failures arise from sudden
unavailability or lapses of the local or opposing payment 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
skipping to change at page 12, line 48 skipping to change at page 12, line 48
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 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 errors
are tried to be resolved first by the extended exchange of Payment are tried to be resolved first by the extended exchange of Payment
skipping to change at page 14, line 38 skipping to change at page 14, line 38
"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 two
trading roles Consumer and Payment Handler. 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 successful/- less transactions. Typically, this call is used for termination or
termination or suspension. 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.
skipping to change at page 17, line 45 skipping to change at page 17, line 45
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 presence of an IOTP Authentication Block within the received 2. On the presence of an IOTP Authentication Block within the
IOTP message, the Authenticatee's IOTP Application Core checks received IOTP message, the Authenticatee's IOTP Application Core
whether the IOTP transaction type in the current phase actually checks whether the IOTP transaction type in the current phase
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
skipping to change at page 19, line 41 skipping to change at page 19, line 41
1. The Merchant's commerce server controls the shopping dialog with 1. The Merchant's commerce server controls the shopping dialog with
its own mechanisms until the Consumer checks out the shopping cart its own mechanisms until the Consumer checks out the shopping cart
and indicates the payment intention. The notion shopping subsumes and indicates the payment intention. The notion shopping subsumes
any non-IOTP based visit of the Merchant Trading Role's (which any non-IOTP based visit of the Merchant Trading Role's (which
subsumes Financial Institutes) web site in order to negotiate the subsumes Financial Institutes) web site in order to negotiate the
content of the IOTP Order Component. The subsequent processing content of the IOTP Order Component. 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 inquires 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 Accepted
Payment Brand"). Their responses provide most of the attribute Payment Brand"). Their responses provide most of the attribute
values for the compilation of the Brand List Component's Brand values for the compilation of the Brand List Component's Brand
Elements. The IOTP Application Core might optionally match the Elements. The IOTP Application Core might optionally match the
returned payment brands with Merchant's general preferences. returned payment brands with Merchant's general preferences.
The IOTP Application Core must provide any wallet identifiers, if The IOTP Application Core must provide any wallet identifiers, if
they are required by the IOTP Payment Bridges which signal their 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 that
could not immediately solved by the IOTP Application Core should could not be immediately solved by the IOTP Application Core
be logged - this applies also to the subsequent API calls of this should be logged - this applies also to the subsequent API calls
section. In this case, the IOTP Application Core creates an IOTP of this section. In this case, the IOTP Application Core creates
Error Block (hard error), transmits it to the Consumer, and an IOTP Error Block (hard error), transmits it to the Consumer,
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 List
Component's Protocol Amount and Pay Protocol Elements. Component's Protocol Amount and Pay Protocol Elements.
Furthermore, the organisational data about the Payment Handler is Furthermore, the organisational data about the Payment Handler is
returned. The IOTP Application Core might optionally match the returned. The IOTP Application Core might optionally match the
returned payment brands with Merchant's general preferences. returned payment brands with Merchant's general preferences.
Alternatively, the IOTP Application Core might skip the calls of Alternatively, the IOTP Application Core might skip the calls of
"Find Accepted Payment Brands" (cf. Step 3) and issue the "Find "Find Accepted Payment Brands" (cf. Step 3) and issue the "Find
Accepted Payment Protocol" call without any Brand given on the Accepted Payment Protocol" call without any Brand given on the
input parameter list. In this case, the IOTP Payment Bridge input parameter list. In this case, the IOTP Payment Bridge
responds on the latter call with the whole set of payment schemes responds to the latter call with the whole set of payment schemes
supported w.r.t. the other input parameters. supported w.r.t. the other input parameters.
5. The steps 3 and 4 are repeated during IOTP Value Exchange 5. The steps 3 and 4 are repeated during IOTP Value Exchange
transactions - these steps are omitted in the previous figure. transactions - these steps are omitted in the previous figure.
6. The IOTP Application Core compiles the Brand List Component(s) and 6. The IOTP Application Core compiles the Brand List Component(s) and
the IOTP Trading Protocol Options Block. It is recommended that the IOTP Trading Protocol Options Block. It is recommended that
"equal" items returned by IOTP Payment Bridge function calls are the "equal" items returned by IOTP Payment Bridge function calls
shared due to the extensive linking capabilities within the Brand are shared due to the extensive linking capabilities within the
List Component. However, the compilation must consider several Brand List Component. However, the compilation must consider
aspects in order to prevent conflicts - sharing detection might be several aspects in order to prevent conflicts - sharing detection
textual matching (after normalization): might be textual matching (after normalization):
o Packaged Content Elements contained in the Brand List o Packaged Content Elements contained in the Brand List
Component (and subsequently generated Payment and Order Component (and subsequently generated Payment and Order
Components) might be payment scheme specific and might depend Components) might be payment scheme specific and might depend
on each other. on each other.
o Currently, IOTP lacks precise rules for the content of the o Currently, IOTP lacks precise rules for the content of the
Packaged Content Element. Therefore, transaction / brand / Packaged Content Element. Therefore, transaction / brand /
protocol / currency amount (in)dependent data might share the protocol / currency amount (in)dependent data might share the
same Packaged Content Element or might spread across multiple same Packaged Content Element or might spread across multiple
skipping to change at page 23, line 11 skipping to change at page 23, line 11
application, e.g., the Web browser invokes a helper application application, e.g., the Web browser invokes a helper application
(e.g., Java applet or external application). Its IOTP Application (e.g., Java applet or external application). Its IOTP Application
Core Core
o infers the accepted payment brands, payment protocols, o infers the accepted payment brands, payment protocols,
payment direction, currencies, payment amounts, any payment direction, currencies, payment amounts, any
descriptions etc., and their relationships from the IOTP descriptions etc., and their relationships from the IOTP
message, message,
o determines the registered IOTP Payment Bridges, o determines the registered IOTP Payment Bridges,
o compiles one or multiple set of brand and protocol such that o compiles one or multiple sets of brand and protocol such that
the join of all set describes exactly the set of payment the join of all sets describes exactly the payment
alternatives being offered by the Merchant. alternatives being offered by the Merchant.
o inquires payment (protocol) support and the known payment o inquires payment (protocol) support and the known payment
instruments from each registered IOTP Payment Bridge for each instruments from each registered IOTP Payment Bridge for each
compiled set ("Find Payment Instrument"). However, some IOTP compiled set ("Find Payment Instrument"). However, some IOTP
Payment Bridges may refuse payment instrument distinction. 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.
skipping to change at page 24, line 9 skipping to change at page 24, line 9
from any configured preferences. Any selection ties one IOTP from 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 requested 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 some required physical payment o required peripheral inclusive of some required physical
instrument (chip card) is unavailable, payment 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 accurate alternatives. Most probably, the user might be offered
recommended
o to resolve the problem, e.g. to insert another payment o to resolve the problem, e.g. to insert another payment
instrument or to verify the periphery, instrument or to verify the periphery,
o to proceed (assuming its success), o to proceed (assuming its success),
o to cancel the whole transaction, or o to cancel the whole transaction, or
o to suspend the transaction, e.g., initiating a nested o to suspend the transaction, e.g., initiating a nested
transaction for uploading an electronic purse. transaction for uploading an electronic purse.
If the payment software implements payment instrument selection on If the payment software implements payment instrument selection on
its own, it may request the Consumer's choice at this step. its own, it may request the Consumer's choice at this step.
skipping to change at page 25, line 10 skipping to change at page 25, line 10
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.
Technically, two payments happen during IOTP Value Exchange (Technically, two payments happen during IOTP Value Exchange
transactions. transactions.)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB Consumer Start Payment Consumer(Amount,[PS0]...) -> IPB
Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB Start Payment Cons. Res.([PS1], CS=Cont.) <- IPB
Create and transmit Payment Request Block Create and transmit Payment Request Block
Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB Payment Handler Start Payment Pay. Handler(Amount, [PS1]) -> IPB
Start Payment PH Response(PS2, CS=Cont.) <- IPB Start Payment PH Response(PS2, CS=Cont.) <- IPB
Create and transmit Payment Exchange Block Create and transmit Payment Exchange Block
Consumer Continue Process(PS2) -> IPB Consumer Continue Process(PS2) -> IPB
Continue Process Response(PS3, CS=Cont.) <- IPB Continue Process Response(PS3, CS=Cont.) <- IPB
skipping to change at page 26, line 5 skipping to change at page 26, line 5
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 genuine payment legacy payment schemes. Simply, because the actual payment legacy systems
systems have not been involved in the current transaction. 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.
skipping to change at page 26, line 33 skipping to change at page 26, line 33
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 be payment scheme specific, might be payment scheme specific,
o payment scheme specific data inclusive payment protocol o payment scheme specific data inclusive of the payment
descriptions from the IOTP Protocol Amount Element, and IOTP protocol descriptions from the IOTP Protocol Amount Element,
Pay Protocol Element, and and IOTP Pay Protocol Element, and
o payment scheme specific data inclusive payment protocol o payment scheme specific data inclusive of the payment
descriptions, in which the name attribute includes the prefix protocol descriptions, in which the name attribute includes
as "Payment:" from the Trading Role Data Component. the prefix as "Payment:" from the Trading Role Data
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 similar 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 they are part of the specific payment protocol. sufficiency, if such checks are part of the specific payment
protocol.
If the IOTP Payment Bridge requests wallet identifiers or pass If the IOTP Payment Bridge requests wallet identifiers or pass
phrases anywhere during the payment process, they should be 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.
skipping to change at page 28, line 21 skipping to change at page 28, line 23
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 signaled by specific error codes which fail for several reasons. These are signaled by specific error
are transformed to IOTP Payment Response Blocks (generated by codes which are transformed to IOTP Payment Response Blocks
Payment Handler) or IOTP Error Blocks (both parties may generate (generated by Payment Handler) or IOTP Error Blocks (both parties
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, the
status response, and the optional payment scheme specific data in status response, and the optional payment scheme specific data in
an IOTP Payment Response Block and transmits this block to the an IOTP Payment Response Block and transmits this block to the
skipping to change at page 30, line 11 skipping to change at page 30, line 11
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 similar 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 stores 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
skipping to change at page 30, line 44 skipping to change at page 30, line 44
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 for 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 depth on 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 genuine 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
skipping to change at page 32, line 7 skipping to change at page 32, line 7
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 success's is 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 by
the IOTP Payment Bridge for display by the IOTP Application Core. the IOTP Payment Bridge for display by the IOTP Application Core.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Any Party Error Block or Cancel Block Received Any Party Error Block or Cancel Block Received
If Change Process State required If Change Process State required
| Change Process State (State) -> IPB | Change Process State (State) -> IPB
| Change Process State Response(State) <- IPB | Change Process State Response(State) <- IPB
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Figure 8. Error Notification from counter party Figure 8. Error Notification from counter party
Not every failure might be visible at the IOTP layer, e.g., the Not every failure might be visible at the IOTP layer, e.g., the
processing of payment transactions might temporarily be hampered by processing of payment transactions might temporarily be hampered by
intermediate failures at the payment scheme or protocol transport intermediate failures at the payment scheme or protocol transport
layer which might be resolved by the genuine components. layer which might be resolved by the 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 the
counter party and local system components, like chip card readers or counter party and local system components, like chip card readers or
IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core IOTP Payment Bridges. Anyway, the Consumer's IOTP Application Core
skipping to change at page 32, line 49 skipping to change at page 32, line 49
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 Any "Resume Payment ..." API function responds with an Error Code
on non suspended payment transaction that signals a business error. on non-suspended payment transaction that signals a business error.
Afterwards the IOTP Application Core has to issue the "Inquire Afterwards the IOTP Application Core has to issue the "Inquire
Process State" API call for further analysis of the process state. Process State" API call for further analysis of the process state.
o One IOTP message sent by one party might not be processed o One IOTP message sent by one party might not be processed
successfully or even received by the counter party. successfully or even received by the counter party.
This needs to be handled by the genuine payment scheme. It is This needs to be handled by the actual payment scheme. It is
expected that the IOTP Application Core will not recognize expected that the IOTP Application Core will not recognize
anything. anything.
o IOTP does not provide any specific signal for payment 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 Process
State" API function to update any lack of knowledge. State" API function to update any lack of knowledge.
Any "Resume Payment" API function responds with an Error Code on Any "Resume Payment" API function responds with an Error Code on
non suspended payment transaction that signals a business error. non-suspended payment transaction that signals a business error.
Similar, the "Continue Process" API function should report business Similar, the "Continue Process" API function should report business
errors on non pending payment transactions. errors on non-pending payment transactions.
o The payment transaction may not have been created at the Payment o The payment transaction may not have been created at the Payment
Handler (early suspension and failed data transmission). In that Handler (early suspension and failed data transmission). In that
case, the IOTP Application Core should respond with a business case, the IOTP Application Core should respond with a business
error that signals the repetition of the payment transaction (by error that signals the repetition of the payment transaction (by
the Consumer). the Consumer).
Any "Resume Payment", "Continue Process" or "Inquire Process State" Any "Resume Payment", "Continue Process" or "Inquire Process State"
API function should return with an Error Code "AttValIllegal" on API function should return with an Error Code "AttValIllegal" on
non existent payment transaction whereby the further Error non-existent payment transaction whereby the further Error
Attribute "Names" denote the payment identifier. Attribute "Names" denote the payment identifier.
o The IOTP Application Core should always request fresh payment o The IOTP Application Core should always request fresh payment
scheme specific data on resumption - for synchronization purposes scheme specific data on resumption - for synchronization purposes
with the Existing Payment Software. Old data in the cache that has with the Existing Payment Software. Old data in the cache that has
not been send to the counter party should not be accessed. not been send to the counter party should not be accessed.
If the Consumer does not reconnect within an acceptable amount of If the Consumer does not reconnect within an acceptable amount of
time, the Payment Handler's system may perform local failure time, the Payment Handler's system may perform local failure
resolution in order to close the transaction and to retain resources resolution in order to close the transaction and to retain resources
skipping to change at page 34, line 33 skipping to change at page 34, line 33
interface for the registration of new payment methods / instruments interface for the registration of new payment methods / instruments
("Manage Payment Software"). It receives the initial user request and ("Manage Payment Software"). It receives the initial user request and
defers the actual registration to the corresponding IOTP Payment defers the actual registration to the corresponding IOTP Payment
Bridge. 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:
skipping to change at page 38, line 52 skipping to change at page 38, line 52
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 being omitted by the IOTP Payment Bridge. the ErrorLocation elements that are omitted by the IOTP Payment
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
skipping to change at page 41, line 12 skipping to change at page 41, line 14
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 non-
PackagedContent element. 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
skipping to change at page 42, line 17 skipping to change at page 42, line 20
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
skipping to change at page 45, line 18 skipping to change at page 45, line 21
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 The connection to some periphery or the
periphery or the counter party could not be counter party could not be established,
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
skipping to change at page 46, line 14 skipping to change at page 46, line 16
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
visualize 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.
skipping to change at page 46, line 53 skipping to change at page 47, line 6
(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
visualize 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
skipping to change at page 48, line 8 skipping to change at page 48, line 8
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 behind the attribute tag recommends the - 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
skipping to change at page 49, line 40 skipping to change at page 49, line 40
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 card) o "insufficient capacity left (on your stored
for refund", 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 to 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
skipping to change at page 51, line 52 skipping to change at page 51, line 52
Payment Handler may accept the payment. Payment Handler may accept the payment.
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 inquired 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
skipping to change at page 53, line 11 skipping to change at page 53, line 11
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 to 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
skipping to change at page 55, line 29 skipping to change at page 55, line 29
"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
secure channel such as [SSL]/[TLS] in order secure channel such as [TLS] in order
to communicate with the Payment Handler. to communicate with the Payment Handler.
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
skipping to change at page 57, line 31 skipping to change at page 57, line 31
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 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 access keys to some mall keys. contain access keys to some mall keys.
Its declaration coincides with the Its declaration coincides with the
skipping to change at page 59, line 33 skipping to change at page 59, line 33
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"
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 % <!ENTITY % AuthReqPackagedContent "PackagedContent">
AuthResPackagedContent "PackagedContent"> <!ENTITY % AuthResPackagedContent "PackagedContent">
<!ENTITY % BrandPackagedContent "PackagedContent"> <!ENTITY % <!ENTITY % BrandPackagedContent "PackagedContent">
BrandSelInfoPackagedContent "PackagedContent"> <!ENTITY % <!ENTITY % BrandSelInfoPackagedContent "PackagedContent">
BrandSelProtocolAmountPackagedContent <!ENTITY % BrandSelProtocolAmountPackagedContent
"PackagedContent"> <!ENTITY % "PackagedContent">
BrandSelCurrencyAmountPackagedContent <!ENTITY % BrandSelCurrencyAmountPackagedContent
"PackagedContent"> "PackagedContent">
<!ENTITY % ProtocolAmountPackagedContent <!ENTITY % ProtocolAmountPackagedContent
"PackagedContent"> <!ENTITY % "PackagedContent">
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. the
appropriate point of view at the interface between the IOTP appropriate point of view at the interface between the IOTP
Application Core and IOTP Payment Bridge. This point of view does not Application Core and IOTP Payment Bridge. This point of view does not
completely mimic the more detailed view on the actual payment by the completely mimic the more detailed view on the actual payment by the
skipping to change at page 60, line 13 skipping to change at page 60, line 12
<!ENTITY % MerchantData "PackagedContent"> <!ENTITY % MerchantData "PackagedContent">
<!ENTITY % PaySchemePackagedContent "PackagedContent"> <!ENTITY % PaySchemePackagedContent "PackagedContent">
3.3 Process States 3.3 Process States
The IOTP Payment API supports six different attribute values that The IOTP Payment API supports six different attribute values that
encode the transaction status from the IOTP's point of view, i.e. the encode the transaction status from the IOTP's point of view, i.e. the
appropriate point of view at the interface between the IOTP appropriate point of view at the interface between the IOTP
Application Core and IOTP Payment Bridge. This point of view does not Application Core and IOTP Payment Bridge. This point of view does not
completely mimic the more detailed view on the actual payment by the completely mimic the more detailed view on the actual payment by the
genuine Existing Payment Software or IOTP Payment Bridge. 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
skipping to change at page 60, line 38 skipping to change at page 60, line 37
------------ ----------- ------------ -----------
NotYetStarted The Payment Transaction exists within the NotYetStarted The Payment Transaction exists within the
IOTP Application Core, i.e., the IOTP Application Core, i.e., the
Merchant's shop has already signaled to Merchant's shop has already signaled to
the IOTP Application Core that an IOTP the IOTP Application Core that an IOTP
transaction has been initiated by the transaction has been initiated by the
Consumer. Consumer.
However, neither any API call has been However, neither any API call has been
issued to the IOTP Payment Bridge nor the issued to the IOTP Payment Bridge nor has
IOTP Order Request has been created. the IOTP Order Request has been created.
InProgress The IOTP Application changes the process InProgress The IOTP Application changes the process
state to this value when it issues the state to this value when it issues the
first API call to the Payment Bridge first API call to the Payment Bridge
during Brand List compilation. during Brand List compilation.
This value indicates that the Payment This value indicates that the Payment
Bridge might have some knowledge about Bridge might have some knowledge about
the expected payment or might have the expected payment or might have
performed some preparatory tasks (even performed some preparatory tasks (even
with the Payment Handler out-of-band to with the Payment Handler out-of-band to
IOTP). IOTP).
However, this value does not indicate However, this value does not indicate
that some IOTP Order Request has been that any IOTP Order Request has been
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 genuine 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
skipping to change at page 62, line 14 skipping to change at page 62, line 10
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 genuine 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
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 genuine 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 will is set during brand selection but it
not change during the whole brand normally will not change during the whole brand
selection process, normally. 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
skipping to change at page 63, line 26 skipping to change at page 63, line 23
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 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
skipping to change at page 64, line 44 skipping to change at page 64, line 44
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 does neither on "InquireProcessState". It neither
reflect 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
skipping to change at page 66, line 49 skipping to change at page 66, line 49
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 the
payment protocols being related by the Brand Elements. 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
skipping to change at page 71, line 21 skipping to change at page 71, line 21
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. Any
subsequently submitted choice of algorithms should be reduced by the subsequently submitted choice of algorithms should be constrained by
accepted algorithms from earlier API responses. 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 76, line 21 skipping to change at page 76, line 21
o if there are sufficient funds available in a particular o if there are sufficient funds available in a particular
currency for an electronic cash payment brand, currency 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 bases 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. In
this event the previous IOTP Payment Bridge is not notified about the this event the previous IOTP Payment Bridge is not notified about the
change. change.
skipping to change at page 78, line 17 skipping to change at page 78, line 17
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 genuine 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 to
be protected against access from other software components, 2) the 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
skipping to change at page 90, line 17 skipping to change at page 90, line 17
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 to complete or suspend prior to the Payment Software recommends be completed or suspended prior to the
processing of new payment transactions. It does not respond further processing of new payment transactions. It does not respond with
transaction details. These have to be inquired by "Inquire Process further transaction details. These have to be requested with "Inquire
State". Process State".
Note that the IOTP Payment Bridge has to respond without the Note that the IOTP Payment Bridge has to respond without the benefit
supplement of any pass phrase if there exist no pending payment of any pass phrase if there exist no pending payment transaction. But
transaction. But if there are some pending payment transactions, the if there are some pending payment transactions, the IOTP Payment
IOTP Payment Bridge may refuse the immediate response and may instead Bridge may refuse the immediate response and may instead request the
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
skipping to change at page 91, line 12 skipping to change at page 91, line 12
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 whereby any receipt might consist of Packaged IOTP payment receipts which might consist of Packaged Content
Content Elements Elements
o from the IOTP Payment Receipt Component - provided by the o from the IOTP Payment Receipt Component - provided by the
Payment Handler's "Inquire Process State" API call shortly Payment Handler's "Inquire Process State" API call shortly
before payment completion, before payment completion,
o from Payment Scheme Components being exchanged during the o from Payment Scheme Components being exchanged during the
actual payment, or actual 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 shortly before payment completion call 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 returned with 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 w.r.t. [IOTP]. Furthermore, the Packaged upon a subset of elements with reference to [IOTP]. Furthermore, the
Content Element have to be distinguishable by their Name attribute. Packaged Content Element have to be distinguishable by their Name
attribute.
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 in the payment receipt
XML definition: XML definition:
<!ELEMENT CheckPaymentReceipt (PackagedContent*) > <!ELEMENT CheckPaymentReceipt (PackagedContent*) >
<!ATTLIST CheckPaymentReceipt <!ATTLIST CheckPaymentReceipt
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 92, line 21 skipping to change at page 92, line 21
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 Receipt"
should be used first if there is any question of the payment receipt should be used first if there is any question of the payment receipt
containing errors. containing errors.
There apply the same conventions 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:
skipping to change at page 93, line 11 skipping to change at page 93, line 11
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 visualization information about the reported XML that contains presenetation information about the reported XML
encoded data. encoded 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
skipping to change at page 93, line 41 skipping to change at page 93, line 41
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 define that attribute value 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
skipping to change at page 95, line 9 skipping to change at page 95, line 9
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 any additional payment scheme specific This API function responds with any additional payment scheme
data that is needed by the Payment Handler for Consumer initiated specific data that is needed by the Payment Handler for Consumer
payment transaction inquiry processing. Probably, the IOTP Payment initiated payment transaction inquiry processing. Probably, the IOTP
Bridge (or the corresponding Existing Payment Software) has to Payment Bridge (or the corresponding Existing Payment Software) has
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 >
skipping to change at page 95, line 46 skipping to change at page 95, line 46
<!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 supplement 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 the
payment transaction. 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
skipping to change at page 97, line 31 skipping to change at page 97, line 31
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 be set, too. 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 which Instead, the IOTP Payment Bridge has to request and verify them,
may return their value to the IOTP Application Core in plain text. In which may return their value to the IOTP Application Core in plain
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 101, line 7 skipping to change at page 101, line 7
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 Full Copyright Statement
Copyright (C) The Internet Society 2000. Copyright (C) The Internet Society 2001.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at page 101, line 35 skipping to change at page 101, line 35
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
References References
[IOTP] - Internet Open Trading Protocol Specification, Version 1.0,
April 2000, See RFC2801.
[IOTPBOOK] - D. Burdett, D.E. Eastlake III, and M. Goncalves,
Internet Open Trading Protocol, McGraw-Hill, 2000. ISBN 0-07-135501-
4.
[HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language [HTML] - Hyper Text Mark Up Language. The Hypertext Markup Language
(HTML) is a simple markup language used to create hypertext documents (HTML) is a simple markup language used to create hypertext documents
that are platform independent. See RFC 1866 and the World Wide Web that are platform independent. See RFC 1866 and the World Wide Web
(W3C) consortium web site at: http://www.w3.org/MarkUp/ (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC [HTTP] - Hyper Text Transfer Protocol versions 1.0 and 1.1. See RFC
1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R. 1945: Hypertext Transfer Protocol - HTTP/1.0. T. Berners-Lee, R.
Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer Fielding & H. Frystyk. May 1996. and RFC 2068: Hypertext Transfer
Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Protocol - HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T.
Berners-Lee. January 1997. Berners-Lee. January 1997.
[IOTP] - Internet Open Trading Protocol Specification, Version 1.0,
April 2000, See RFC2801.
[IOTPBOOK] - D. Burdett, D.E. Eastlake III, and M. Goncalves,
Internet Open Trading Protocol, McGraw-Hill, 2000. ISBN 0-07-135501-
4.
[ISO4217] - ISO 4217: Codes for the Representation of Currencies. [ISO4217] - ISO 4217: Codes for the Representation of Currencies.
Available from ANSI or ISO. Available from ANSI or ISO.
[MIME] - Multipurpose Internet Mail Extensions. See RFC822, RFC2045, [MIME] - Multipurpose Internet Mail Extensions. See RFC822, RFC2045,
RFC2046, RFC2047, RFC2048 and RFC2049. RFC2046, RFC2047, RFC2048 and RFC2049.
[URL] - Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31, [SET] - SET Secure Electronic Transaction(TM) , Version 1.0, May 31,
1997 1997
Book 1: Business Description Book 1: Business Description
Book 2: Programmer's Guide Book 2: Programmer's Guide
Book 3: Formal Protocol Definition Book 3: Formal Protocol Definition
Download from: <http://www.setco.org>. Download from: <http://www.setco.org>.
[SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently [SET/IOTP] - Yoshiaki Kawatsura "SET Supplement for IOTP" (currently
draft-ietf-trade-iotp-v1.0-set-02.txt) draft-ietf-trade-iotp-v1.0-set-02.txt)
[URL] - Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[UTC] - Universal Time Coordinated. A method of defining time [UTC] - Universal Time Coordinated. A method of defining time
absolutely relative to Greenwich Mean Time (GMT). Typically of the absolutely relative to Greenwich Mean Time (GMT). Typically of the
form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number form: "CCYY-MM- DDTHH:MM:SS.sssZ+n" where the "+n" defines the number
of hours from GMT. See ISO DIS8601. of hours from GMT. See ISO DIS8601.
[XML] - Extensible Mark Up Language (XML) 1.0 (Second Edition). A [XML] - Extensible Mark Up Language (XML) 1.0 (Second Edition). A
W3C recommendation. See http://www.w3.org/TR/1998/REC-xml W3C recommendation. See http://www.w3.org/TR/1998/REC-xml
[XSLT] - Extensible Style Language Transformations 1.0, November
1999, See http://www.w3.org/TR/xslt
[XML-NS] - Namespaces in XML Recommendation. T. Bray, D. Hollander, [XML-NS] - Namespaces in XML Recommendation. T. Bray, D. Hollander,
A. Layman. Janaury 1999. http://www.w3.org/TR/1999/REC-xml-names A. Layman. Janaury 1999. http://www.w3.org/TR/1999/REC-xml-names
[XSLT] - Extensible Style Language Transformations 1.0, November
1999, See http://www.w3.org/TR/xslt
Author's Addresses Author's Addresses
Hans-Bernhard Beykirch and Werner Hans Hans-Bernhard Beykirch and Werner Hans
IT Development & Coordination Center for the German Savings Banks IT Development & Coordination Center for the German Savings Banks
Organization (SIZ) Organization (SIZ)
Konigswinterer Strase 553 Konigswinterer Strase 553
53227 Bonn 53227 Bonn
Germany Germany
E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de E-mail: Hans-Bernhard.Beykirch@siz.de, Werner.Hans@siz.de
Masaaki Hiroya and Yoshiaki Kawatsura Masaaki Hiroya and Yoshiaki Kawatsura
Hitachi, Ltd. Hitachi, Ltd.
890 Kashimada Saiwai-ku Kawasaki-shi 890 Kashimada Saiwai-ku Kawasaki-shi
Kanagawa, Japan 212-8567 Kanagawa, Japan 212-8567
E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp E-mail: hiroya@sdl.hitachi.co.jp, kawatura@bisd.hitachi.co.jp
Expiration and File Name Expiration and File Name
This draft expires May 2001. This draft expires September 2001.
Its file name is draft-ietf-trade-iotp-v1.0-papi-03.txt. Its file name is draft-ietf-trade-iotp-v1.0-papi-04.txt.
 End of changes. 

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