procedures defined in section 12 IANA
Considerations user defined values may be
defined.
BrandName This contains the name of the brand, for example
MasterCard Credit. This is the description of the
Brand which is displayed to the consumer in the
Consumers language defined by xml:lang. For
example it might be "American Airlines Advantage
Visa". Note that this attribute is not used for
matching against the payment instruments held by
the Consumer.
BrandLogoNetLocn The net location which can be used to download
the logo for the Organisation. See section
Retrieving Logos (see section 10).
The content of this attribute must conform to
[RFC1738].
BrandNarrative This optional attribute is designed to be used by
the Merchant to indicate some special conditions
or benefit which would apply if the Consumer
selected that brand. For example "5% discount",
"free shipping and handling", "free breakage
insurance for 1 year", "double air miles apply",
etc.
ProtocolAmountRefs Identifies the protocols and related currencies
and amounts which can be used with this Brand.
Specified as a list of ID's of Protocol Amount
Elements (see section 7.7.3) contained within the
Brand List.
ContentSoftwareId See section 14.Glossary.
Content:
ProtocolBrand Protocol Brand elements contain brand information
to be used with a specific payment protocol (see
section 7.7.2)
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the brand
which may be used by the payment protocol. The
content of this information is defined in the
supplement for a payment protocol which describes
how the payment protocol works with IOTP.
Example Brand Elements are contained in section 11.2 Brand List
Examples.
7.7.2 Protocol Brand Element
The Protocol Brand Element contains information that is specific to
the use of a particular Protocol with a Brand. Its definition is as
follows.
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
Attributes:
ProtocolId This must match the value of a ProtocolId
attribute in a Pay Protocol Element (see section
7.7.5).
The values of ProtocolId should be unique within a
Brand Element otherwise there is an error.
ProtocolBrandId This is the Payment Brand Id to be used with a
particular payment protocol. For example, SET and
EMV have their own well defined, yet different,
values for the Brand Id to be used with each
protocol.
The valid values of this attribute are defined in
the supplement for the payment protocol identified
by ProtocolId that describes how the payment
protocol works with IOTP.
Content:
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the
protocol/brand which may be used by the payment
protocol. The content of this information is
defined in the supplement for a payment protocol
which describes how the payment protocol works
with IOTP.
7.7.3 Protocol Amount Element
The Protocol Amount element links a Brand to:
o the currencies and amounts in Currency Amount Elements (see
section 7.7.4) that can be used with the Brand, and
o the Payment Protocols and Payment Handlers defined in a Pay
Protocol Element (see section 7.7.5), which can be used with those
currencies and amounts.
Its definition is as follows:
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message
which uniquely identifies the Protocol Amount
element within the IOTP Transaction.
PayProtocolRef Contains an Element Reference (see section 3.5)
that refers to the Pay Protocol Element (see
section 7.7.5) that contains the Payment Protocol
and Payment Handlers that can be used with the
Brand.
CurrencyAmountRefs Contains a list of Element References (see
section 3.5) that refer to the Currency Amount
Element (see section 7.7.4) that describes the
currencies and amounts that can be used with the
Brand.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the protocol
amount which may be used by the payment protocol.
The content of this information is defined in the
supplement for a payment protocol which describes
how the payment protocol works with IOTP.
Examples of Protocol Amount Elements are contained in section 11.2
Brand List Examples.
7.7.4 Currency Amount Element
A Currency Amount element contains:
o a currency code (and its type), and
o an amount.
One or more of these elements is carried in each Brand List
Component. Its definition is as follows:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
Attributes:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Currency Amount Element
within the IOTP Transaction.
Amount Indicates the amount to be paid in whole and
fractional units of the currency. For example
$245.35 would be expressed "245.35". Note that
values smaller than the smallest denomination are
allowed. For example one tenth of a cent would be
"0.001".
CurrCodeType Indicates the domain of the CurrCode. This
attribute is included so that the currency code
may support non-standard "currencies" such as
frequent flyer points, trading stamps, etc. Its
values may be:
o ISO4217-A (the default) indicates the currency
code is a three character alphabetic currency
code that conforms to [ISO 4217]
o IOTP indicates that values of CurrCode are
managed under the procedure described in
section 12 IANA Considerations
CurrCode A code which identifies the currency to be used in
the payment. The domain of valid currency codes is
defined by CurrCodeType
As values of CurrCodeType are managed under the
procedure described in section 12 IANA
Considerations user defined values of CurrCodeType
may be defined.
Examples of Currency Amount Elements are contained in section 11.2
Brand List Examples.
7.7.5 Pay Protocol Element
A Pay Protocol element specifies details of a Payment Protocol and
the Payment Handler that can be used with a Brand. One or more of
these elements is carried in each Brand List.
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Pay Protocol element
within the IOTP Transaction.
xml:lang Defines the language used by attributes and
content of this element. See section 3.8
Identifying Languages.
ProtocolId Consists of a protocol name and version. For
example "SETv1.0".
The values of ProtocolId are defined by the
payment scheme/method owners in the document that
describes how to encapsulate a payment protocol
within IOTP.
ProtocolName A narrative description of the payment protocol
and its version in the language identified by
xml:lang. For example "Secure Electronic
Transaction Version 1.0". Its purpose is to help
provide information on the payment protocol being
used if problems arise.
ActionOrgRef An Element Reference (see section 3.5) to the
Organisation Component for the Payment Handler for
the Payment Protocol.
PayReqNetLocn The Net Location indicating where an unsecured
Payment Request message should be sent if this
protocol choice is used.
The content of this attribute is dependent on the
Transport Mechanism (such must conform to
[RFC1738].
SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if this
protocol choice is used.
A secured payment involves the use of a secure
channel such as [SSL/TLS] in order to communicate
with the Payment Handler.
The content of this attribute must conform to
[RFC1738]. See also See section 3.9 Secure and
Insecure Net Locations.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Optional Packaged Content elements (see section
3.7) containing information about the protocol
which is used by the payment protocol. The content
of this information is defined in the supplement
for a payment protocol which describes how the
payment protocol works with IOTP. An example of
its use could be to include a payment protocol
message.
Examples of Pay Protocol Elements are contained in section 11.2 Brand
List Examples.
7.8 Brand Selection Component
A Brand Selection Component identifies the choice of payment brand,
payment protocol and the Payment Handler. This element is used:
o in Payment Request messages within Baseline Purchase and Baseline
Value Exchange IOTP Transactions to identify the brand, protocol
and payment handler for a payment, or
o to, optionally, inform a merchant in a purchase of the payment
brand being used so that the offer and order details can be
amended accordingly.
In Baseline IOTP, the integrity of Brand Selection Components is not
guaranteed. However, modification of Brand Selection Components can
only cause denial of service if the payment protocol itself is secure
against message modification, duplication, and swapping attacks.
The definition of a Brand Selection Component is as follows.
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
Attributes:
ID An identifier which uniquely identifies the Brand
Selection Component within the IOTP Transaction.
BrandListRef The Element Reference (see section 3.5) of the
Brand List Component from which a Brand is being
selected
BrandRef The Element Reference of a Brand element within
the Brand List Component that is being selected
that is to be used in the payment.
ProtocolAmountRef The Element Reference of a Protocol Amount element
within the Brand List Component which is to be
used when making the payment.
CurrencyAmountRef The Element Reference of a Currency Amount element
within the Brand List Component which is to be
used when making the payment.
Content:
BrandSelBrandInfo, This contains any additional data that
BrandSelProtocolAmountInfo, may be required by a particular payment
BrandSelCurrencyAmountInfo brand or protocol. See sections 7.8.1,
7.8.2, and 7.8.3.
The following rules apply:
o the BrandListRef must contain the ID of a Brand List Component in
the same IOTP Transaction
o every Brand List Component in the Trading Protocol Options Block
(see section 8.1) must be referenced by one and only one Brand
Selection Component
o the BrandRef must refer to the ID of a Brand contained within the
Brand List Component referred to by BrandListRef
o the ProtocolAmountRef must refer to one of the Element IDs listed
in the ProtocolAmountRefs attribute of the Brand element
identified by BrandRef
o the CurrencyAmountRef must refer to one of the Element IDs listed
in the CurrencyAmountRefs attribute of the Protocol Amount Element
identified by ProtocolAmountRef.
An example of a Brand Selection Component is included in 11.2 Brand
List Examples.
7.8.1 Brand Selection Brand Info Element
The Brand Selection Brand Info Element contains any additional data
that may be required by a particular payment brand. See the IOTP
payment method supplement for a description of how and when it used.
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Packaged Content elements (see section 3.7) that
contain additional data that may be required by a
particular payment brand. See the payment method
supplement for IOTP for rules on how this is used.
7.8.2 Brand Selection Protocol Amount Info Element
The Brand Selection Protocol Amount Info Element contains any
additional data that is payment protocol specific that may be
required by a particular payment brand or payment protocol. See the
IOTP payment method supplement for a description of how and when it
used.
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Packaged Content elements (see section 3.7) that
may contain additional data that may be required
by a particular payment brand. See the payment
method supplement for IOTP for rules on how this
is used.
7.8.3 Brand Selection Currency Amount Info Element
The Brand Selection Currency Amount Info Element contains any
additional data that is payment brand and currency specific that may
be required by a particular payment brand. See the IOTP payment
method supplement for a description of how and when it used.
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Packaged Content elements (see section 3.7) that
contain additional data relating to the payment
brand and currency. See the payment method
supplement for IOTP for rules on how this is used.
7.9 Payment Component
A Payment Component contains information used to control how a
payment is carried out. Its provides information on:
o the times within which a Payment with a Payment Handler may be
started
o a reference to the Brand List (see section 7.7) which identifies
the Brands, protocols, currencies and amounts which can be used to
make a payment
o whether or not a payment receipt will be provided
o whether another payment precedes this payment.
Its definition is as follows.
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Component within the IOTP Transaction.
OkFrom The date and time in [UTC] format after which a
Payment Handler may accept for processing a
Payment Request Block (see section 8.7) containing
the Payment Component.
OkTo The date and time in [UTC] format before which a
Payment Handler may accept for processing a
Payment Request Block containing the Payment
Component.
BrandListRef An Element Reference (see section 3.5) of a Brand
List Component (see section 7.7) within the TPO
Trading Block for the IOTP Transaction. The Brand
List identifies the alternative ways in which the
payment can be made.
SignedPayReceipt Indicates whether or not the Payment Response
Block (see section 8.9) generated by the Payment
Handler for the payment must be digitally signed.
StartAfter Contains Element References (see section 3.5) of
other Payment Components which describe payments
which must be complete before this payment can
start. If no StartAfter attribute is present then
there are no dependencies and the payment can
start immediately
7.10 Payment Scheme Component
A Payment Scheme Component contains payment protocol information for
a specific payment scheme which is transferred between the parties
involved in a payment for example a [SET] message. Its definition is
as follows.
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Scheme Component within the IOTP
Transaction.
PaymentRef An Element Reference (see section 3.5) to the
Payment Component (see section 7.9) to which
this Payment Scheme Component relates. It is
required unless the Payment Scheme Component is
part of an Transaction Inquiry Status
Transaction (see section 9.2.1).
ConsumerPaymentId An identifier specified by the Consumer which,
if returned by the Payment Handler in another
Payment Scheme Component or by other means, will
enable the Consumer to identify which payment is
being referred to.
PaymentHandlerPayId An identifier specified by the Payment Handler
which, if returned by the Consumer in another
Payment Scheme Component, or by other means,
will enable the Payment Handler to identify
which payment is being referred to. It is
required on every Payment Scheme Component apart
from the one contained in a Payment Request
Block.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Contains payment scheme protocol information as
Packaged Content elements (see section 3.7). See
the payment scheme supplement for the definition
of its content.
Note that:
o the values of the Name attribute of each
packaged content element are defined by the
Payment Protocol Supplement
o the value of each Name must be unique within a
Payment where a Payment is defined as all
Payment Scheme or Payment Receipt Components
with the same value of the PaymentRef attribute
7.11 Payment Receipt Component
A Payment Receipt is a record of a payment which demonstrates how
much money has been paid or received. It is distinct from a purchase
receipt in that it contains no record of what was being purchased.
Typically the content of a Payment Receipt Component will contain
data which describes:
o the amount paid and its currency
o the date and time of the payment
o internal reference numbers which identify the payment to the
payment system
o potentially digital signatures generated by the payment method
which can be used to prove after the event that the payment
occurred.
If the Payment Method being used provides the facility then the
Payment Receipt Component should contain payment protocol messages,
or references to messages, which prove the payment occurred.
The precise definition of the content is Payment Method dependent.
Refer to the supplement for the payment method being used to
determine the rules that apply.
Information contained in the Payment Receipt Component should be
displayed or otherwise made available to the Consumer.
Note: If the Payment Receipt Component contains Payment Protocol
Messages, then the Messages will need to be processed by Payment
Method software to convert it into a format which can be understood
by the Consumer
The definition of a Payment Receipt Component is as follows.
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
PaymentRef Contains an Element Reference (see section 3.5)
to the Payment Component (see section 7.9) to
which this payment receipt applies
PayReceiptNameRefs Optionally contains a list of the values of the
Name attributes of Packaged Content elements that
together make up the receipt. The Packaged
Content elements are contained either within:
o Payment Scheme Data components exchanged
between the Payment Handler and the Consumer
roles during the Payment, and/or
o the Payment Receipt component itself.
Note that:
o each payment scheme defines in its supplement
the Names of the Packaged Content elements
that must be listed in this attribute (if
any).
o if a Payment Scheme Component contains
Packaged Content elements with a name that
matches a name within PayReceiptNameRefs, then
those Payment Scheme Components must be
referenced by Digests in the Payment Response
signature component (if such a signature is
being used)
The client software should save all the
components referenced so that the payment receipt
can be reconstructed when required.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Optionally contains payment scheme payment receipt
information as Packaged Content elements (see
section 3.7). See the payment scheme supplement
for the definition of its content.
Note that:
o the values of the Name attribute of each
packaged content element are defined by the
Payment Protocol Supplement
o the value of each Name must be unique within a
Payment where a Payment is defined as all
Payment Scheme or Payment Receipt Components,
with the same value of the PaymentRef attribute
Note that either the PayReceiptNameRefs attribute, the
PackagedContent element, or both must be present.
7.12 Payment Note Component
The Payment Note Component contains additional, non payment related,
information which the Payment Handler wants to provide to the
Consumer. For example, if a withdrawal or deposit were being made
then it could contain information on the remaining balance on the
account after the transfer was complete. The information should
duplicate information contained within the Payment Receipt Component.
Information contained in the Payment Note Component should be
displayed or otherwise made available to the Consumer. For
interoperability, the Payment Note Component should support, as a
minimum, the content types of "Plain Text", HTML and XML. Its
definition is as follows.
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Contains additional, non payment related,
information which the Payment Handler wants to
provide to the Consumer as one or more Packaged
Content elements (see section 3.7).
7.13 Delivery Component
The Delivery Element contains information required to deliver goods
or services. Its definition is as follows.
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Component within the IOTP Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
DelivExch Indicates if this IOTP Transaction includes the
messages associated with a Delivery Exchange.
Valid values are:
o True indicates it does include a Delivery
Exchange
o False indicates it does not include a
Delivery Exchange
If set to true then a DeliveryData element must
be present. If set to false it may be absent.
DelivAndPayResp Indicates if the Delivery Response Block (see
section 8.11) and the Payment Response Block (see
section 8.9 ) are combined into one IOTP Message.
Valid values are:
o True indicates both blocks will be in the
same IOTP Message, and
o False indicates each block will be in a
different IOTP Message
DelivAndPayResp should not be true if DelivExch
is False.
In practice combining the Delivery Response Block
and Payment Response Block is only likely to be
practical if the Merchant, the Payment Handler
and the Delivery Handler are the same
Organisation since:
o the Payment Handler must have access to Order
Component information so that they know what
to deliver, and
o the Payment Handler must be able to carry out
the delivery
ActionOrgRef An Element Reference to the Organisation
Component of the Delivery Handler for this
delivery.
Content:
DeliveryData Contains details about how the delivery will be
carried out. See 7.13.1 Delivery Data Element
below.
PackagedContent Contains "user" data defined for the Merchant
which is required by the Delivery Handler as one
or more Packaged Content Elements see section 3.7.
7.13.1 Delivery Data Element
The DeliveryData element contains information about where and how
goods are to be delivered. Its definition is as follows.
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
xml:lang Defines the language used by attributes within
this component. See section 3.8 Identifying
Languages.
OkFrom The date and time in [UTC] format after which the
Delivery Handler may accept for processing a
Delivery Request Block (see section 8.10).
OkTo The date and time in [UTC] format before which
the Delivery Handler may accept for processing a
Delivery Request Block.
DelivMethod Indicates the method by which goods or services
may be delivered. Valid values are:
o Post the goods will be delivered by post or
courier
o Web the goods will be delivered
electronically in the Delivery Note Component
o Email the goods will be delivered
electronically by e-mail
Values of DelivMethod are managed under the
procedure described in section 12 IANA
Considerations which allows user defined codes to
be defined.
DelivToRef The Element Reference (see section 3.4) of an
Organisation Component within the IOTP
Transaction which has a role of DelivTo. The
information in this block is used to determine
where delivery is to be made. It must be
compatible with DelivMethod. Specifically if the
DelivMethod is:
o Post, then the there must be a Postal Address
Element containing sufficient information for
a postal delivery,
o Web, then there are no specific requirements.
The information will be sent in a web page
back to the Consumer
o Email, then there must be Contact Information
Element with a valid e-mail address
DelivReqNetLocn This contains the Net Location to which an
unsecured Delivery Request Block (see section
8.10) which contains the Delivery Component
should be sent.
The content of this attribute is dependent on the
Transport Mechanism and must conform to
[RFC1738].
SecDelivReqNetLocn This contains the Net Location to which a secured
Delivery Request Block (see section 8.10) which
contains the Delivery Component should be sent.
A secured delivery request involves the use of a
secure channel such as [SSL/TLS] in order to
communicate with the Payment Handler.
The content of this attribute is dependent on the
Transport Mechanism must conform to [RFC1738].
See also Section 3.9 Secure and Insecure Net
Locations.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Additional information about the delivery as one
or more Packaged Content elements (see section
3.7) provided to the Delivery Handler by the
merchant.
7.14 Consumer Delivery Data Component
A Consumer Delivery Data Component is used by a Consumer to specify
an identifier that can be used by the Consumer to identify the
Delivery.
Its definition is as follows:
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
Attributes:
ID An identifier which uniquely identifies the
Consumer Delivery Data Component within the IOTP
Transaction.
ConsumerDeliveryId An identifier specified by the Consumer which, if
returned by the Delivery Handler will enable the
Consumer to identify which Delivery is being
referred to.
7.15 Delivery Note Component
A Delivery Note contains delivery instructions about the delivery of
goods or services or potentially the actual Delivery Information
itself. It is information which the person or Organisation receiving
the Delivery Note can use when delivery occurs.
For interoperability, the Delivery Note Component Packaged Content
should support both Plain Text, HTML and XML.
It's definition is as follows.
<!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the
Delivery Note Component within the IOTP
Transaction.
xml:lang Defines the language used by attributes or child
elements within this component, unless
overridden by an xml:lang attribute on a child
element. See section 3.8 Identifying Languages.
DelivHandlerDelivId An optional identifier specified by the Delivery
Handler which, if returned by the Consumer in
another Delivery Component, or by other means,
will enable the Delivery Handler to identify
which Delivery is being referred to. It is
required on every Delivery Component apart from
the one contained in a Delivery Request Block.
An example use of this attribute is to contain a
delivery tracking number.
ContentSoftwareId See section 14. Glossary.
Content:
PackagedContent Contains actual delivery note information as one
or more Packaged Content elements (see section
3.7).
Note: If the content of the Delivery Message is a Mime message then
the Delivery Note may trigger an application which causes the actual
delivery to occur.
7.16 Status Component
A Status Component contains status information about the business
success or failure (see section 4.2) of a process.
Its definition is as follows.
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
Attributes:
ID An identifier which uniquely identifies the Status
Component within the IOTP Transaction.
xml:lang Defines the language used by attributes within
this component. See section 3.8 Identifying
Languages.
StatusType Indicates the type of Document Exchange which the
Status is reporting on. It may be set to either
Offer, Payment, Delivery, Authentication or
Undefined.
Undefined means that the type of document exchange
could not be identified. This is caused by an
error in the initial input message of the
exchange.
Values of StatusType are managed under the
procedure described in section 12 IANA
Considerations which also allows user defined
values of StatusType to be defined.
ElRef If the StatusType is not set to Undefined then
ElRef contains an Element Reference (see section
3.5) to the Component for which the Status is
being described. It must refer to either:
o an Order Component (see section 7.5), if the
StatusType is Offer,
o a Payment Component (see section 7.9), if the
StatusType is Payment, or
o a Delivery Component (see section 7.13), if
the StatusType is Delivery
o an Authentication Request Component (see
section 7.2) if the StatusType is
Authentication.
ProcessState Contains a State Code which indicates the current
state of the process being carried out. Valid
values for ProcessState are:
o NotYetStarted. A Request Block has been
received but the process has not yet started
o InProgress. Processing of the Request Block
has started but it is not yet complete
o CompletedOk. The processing of the Request
Block has completed successfully without any
errors
o Failed. The processing of the Request Block
has failed because of a Business Error (see
section 4.2)
o ProcessError. This value is only used when the
Status Component is being used in connection
with an Inquiry Request Trading Block (see
section 8.12). It indicates there was a
Technical Error (see section 4.1) in the
Request Block which is being processed or some
internal processing error.
Note that this code reports on the processing of a
Request Block. Further, asynchronous processing
may occur after the Response Block associated with
the Process has been sent.
CompletionCode Indicates how the process completed. Valid values
for the CompletionCode are given below together
with the conditions when it must be present and
indications on when recovery from failures are
possible.
A CompletionCode is a maximum of 14 characters
long.
ProcessReference This optional attribute holds a reference for the
process whose status is being reported. It may
hold the following values:
o when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the
Payment Scheme Data Component
o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the
Delivery Note Component
o when StatusType is set to Authentication, it
should contain the AuthenticationId from the
Authentication Request Component
This attribute should be absent in the Inquiry
Request message when the Consumer has not been
given such a reference number by the IOTP Service
Provider.
This attribute can be used inside an Inquiry
Response Block (see section 8.13) to give the
reference number for a transaction which has
previously been unavailable.
For example, the package tracking number might not
be assigned at the time a delivery response was
received. However, if the Consumer issues a
Baseline Transaction Status Inquiry later, the
Delivery Handler can put the package tracking
number into this attribute in the Inquiry Response
message and send it back to the Consumer.
StatusDesc An optional textual description of the current
status of the process in the language identified
by xml:lang.
7.16.1 Offer Completion Codes
The Completion Code is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used and indicates whether or not recovery
might be possible. It is recommended that the StatusDesc attribute is
used to provide further explanation where appropriate.
Value Description
AuthError Authentication Error. The check of the
Authentication Response which was carried out has
failed.
Recovery may be possible by the Consumer re-
submitting a new Authentication Response Block with
corrected information.
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the transaction for some reason. This code is only
valid in a Status Component contained in a Cancel
Block or an Inquiry Response Block.
No recovery possible.
MerchCancelled Offer Cancelled. The Merchant declines to generate
an offer for some reason and cancels the
transaction. This code is only valid in a Status
Component contained in a Cancel Block or an Inquiry
Response Block.
No recovery possible.
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes.
No recovery possible.
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
Recovery is possible if the last message from the
other Trading Role is received again.
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but
no response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
No recovery possible.
7.16.2 Payment Completion Codes
The CompletionCode is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used and indicates where recovery may be
possible. It is recommended that the StatusDesc attribute is used by
individual payment schemes to provide further explanation where
appropriate.
Value Description
BrandNotSupp Brand not supported. The payment brand is not
supported by the Payment Handler.
See below for recovery options.
CurrNotSupp Currency not supported. The currency in which the
payment is to be made is not supported by either
the Payment Instrument or the Payment Handler.
If the payment is Brand Independent, then the
Consumer may recover by selecting a different
currency, if available, or a different brand. Note
that this may involve a different Payment Handler.
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the payment for some reason. This code is only
valid in a Status Component contained in a Cancel
Block or an Inquiry Response Block.
Recovery is not possible.
PaymtCancelled Payment Cancelled. The Payment Handler declines to
complete the payment for some reason and cancels
the transaction. This code is only valid in a
Status Component contained in a Cancel Block or an
Inquiry Response Block.
See below for recovery options.
AuthError Authentication Error. The Payment Scheme specific
authentication check which was carried out has
failed.
Recovery may be possible. See the payment scheme
supplement to determine what is allowed.
InsuffFunds Insufficient funds. There are insufficient funds
available for the payment to be made.
See below for recovery options.
InstBrandInvalid Payment Instrument not valid for Brand. A Payment
Instrument is being used which does not correspond
with the Brand selected. For example a Visa credit
card is being used when MasterCard was selected as
the Brand.
See below for recovery options.
InstNotValid Payment instrument not valid for trade. The
Payment Instrument cannot be used for the proposed
type of trade, for some reason.
See below for recovery options.
BadInstrument Bad instrument. There is a problem with the
Payment Instrument being used which means that it
is unable to be used for the payment.
See below for recovery options.
Unspecified Unspecified error. There is some unknown problem
or error which does not fall into one of the other
CompletionCodes. The StatusDesc attribute should
provide the explanation of the cause.
See below for recovery options.
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on
a Transaction Inquiry.
Recovery is possible if the last message from the
other Trading Role is received again.
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but
no response received. The document exchange has
therefore "Timed Out". This code is only valid on
a Transaction Inquiry.
No recovery possible.
If the Payment is Brand Independent, then recovery may be possible
for some values of the Completion Code, by the Consumer selecting
either a different payment brand or a different payment instrument
for the same brand. Note that this might involve a different Payment
Handler. The codes to which this applies are: BrandNotSupp,
PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid,
BadInstrument and Unspecified.
Recovery from Payments associated with Brand Dependent purchases is
only possible, if the Brand Selection component sent by the Merchant
to the Consumer does not change. In practice this means that the same
Brand, Protocol Amount and PayProtocol elements must be used. All
that can change is the Payment Instrument. Any other change will
invalidate the Merchant's Offer as a changed selection will
invalidate the Offer Response.
7.16.3 Delivery Completion Codes
The following table contains the valid values for the CompletionCode
attribute for a Delivery. It is recommended that the StatusDesc
attribute is used to provide further explanation where appropriate.
Value Description
BackOrdered Back Ordered. The goods to be delivered are on order
but they have not yet been received. Shipping will be
arranged when they are received. This is only valid
if ProcessState is CompletedOk.
Recovery is not possible.
PermNotAvail Permanently Not Available. The goods are permanently
unavailable and cannot be re-ordered. This is only
valid if ProcessState is Failed.
Recovery is not possible.
TempNotAvail Temporarily Not Available. The goods are temporarily
unavailable and may become available if they can be
ordered. This is only valid if ProcessState is
CompletedOk.
Recovery is not possible.
ShipPending Shipping Pending. The goods are available and are
scheduled for shipping but they have not yet been
shipped. This is only valid if ProcessState is
CompletedOk.
Recovery is not possible.
Shipped Goods Shipped. The goods have been shipped.
Confirmation of delivery is awaited. This is only
valid if ProcessState is CompletedOk.
Recovery is not possible.
ShippedNoConf Shipped - No Delivery Confirmation. The goods have
been shipped but it is not possible to confirm
delivery of the goods. This is only valid if
ProcessState is CompletedOk.
Recovery is not possible.
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the delivery for some reason. This code is only valid
in a Status Component contained in a Cancel Block or
an Inquiry Response Block.
Recovery is not possible.
DelivCancelled Delivery Cancelled. The Delivery Handler declines to
complete the Delivery for some reason and cancels the
transaction. This code is only valid in a Status
Component contained in a Cancel Block or an Inquiry
Response Block.
Recovery is not possible.
Confirmed Confirmed. All goods have been delivered and
confirmation of their delivery has been received.
This is only valid if ProcessState is CompletedOk.
Recovery is not possible.
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes. The StatusDesc attribute should
provide the explanation of the cause.
Recovery is not possible.
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
Recovery is possible if the last message from the
other Trading Role is received again.
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
No recovery possible.
Note: Recovery from failed, or partially completed deliveries is not
possible. The Consumer should use the Transaction Status Inquiry
Transaction (see section 9.2.1) to determine up-to- date information
on the current state.
7.16.4 Authentication Completion Codes
The Completion Code is only required if the ProcessState attribute is
set to Failed. The following table contains the valid values for the
CompletionCode that may be used. It is recommended that the
StatusDesc attribute is used to provide further explanation where
appropriate.
Value Description
AutEeCancel Authenticatee Cancel. The Organisation being
authenticated declines to be authenticated for some
reason. This could be, for example because the
signature on an Authentication Request was invalid or
the Authenticator was not known or acceptable to the
Authenticatee.
Recovery is not possible.
AutOrCancel Authenticator Cancel. The Organisation requesting
authentication declines to validate the
Authentication Response received for some reason and
cancels the transaction.
Recovery is not possible.
NoAuthReq Authentication Request Not Available. The
Authenticatee does not have the data that must be
provided so that they may be successfully
authenticated. For example a password may have been
forgotten, the Authenticatee has not yet become a
member, or a smart card token is not present.
Recovery is not possible
AuthFailed Authentication Failed. The Authenticator checked the
Authentication Response but the authentication failed
for some reason. For example a password may have been
incorrect.
Recovery may be possible by the Authenticatee re-
sending a revised Authentication Response with
corrected data.
TradRolesIncon Trading Roles Inconsistent. The Trading Roles
contained within the TradingRoleList attribute of the
Trading Role Information Request Component (see
section 7.4) are inconsistent with the Trading Role
which the Authenticatee is taking in the IOTP
Transaction or is able to take. Examples of
inconsistencies include:
o asking a PaymentHandler for DeliveryHandler
information
o asking a Consumer for Merchant information
Recovery may be possible by the Authenticator re-
sending a revised Authentication Request Block with
corrected information.
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes.
Recovery is not possible.
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
Recovery is possible if the last message from the
other Trading Role is received again.
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
No recovery possible.
7.16.5 Undefined Completion Codes
The Completion Code is only required if the ProcessState attribute is