RFC2801 - Internet Open Trading Protocol - IOTP Version 1.0(4)
If the Merchant receives an IOTP Message containing a Cancel block,
then the Consumer is likely to go to the CancelNetLocn specified on
the Trading Role Element in the Organisation Component for the
Merchant.
If the Consumer receives an IOTP Message containing a Cancel block,
then the information contained in the IOTP Message should be reported
to the Consumer but no further action taken.
9.1.2.2 Brand Independent Offer Document Exchange
In a Brand Independent Offer Document Exchange the TPO Block and the
Offer Response Block are sent together by the Merchant to the
Consumer, i.e. there is one IOTP Message that contains both a TPO
Block, and an Offer Response Block.
The message flow is illustrated by the diagram below:
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
Merchant
STEP
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols,
currencies and amounts apply, places then in a Brand List
Component inside a TPO Block, creates an Offer Response
containing details about the IOTP Transaction including
price, etc., optionally signs it and sends to Consumer
C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; TPO Block; Offer Response Block
3. IOTP aware application started. Consumer selects the
payment brand, payment protocol and currency/amount to
use. Records selection in a Brand Selection Component,
checks offer is OK, combines the Brand Selection
Component with information from the TPO Block and Offer
Response Block to create the next IOTP Message for the
Transaction and sends it together with the Signature
Block if present to the required Trading Role.
CONTINUED ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 20 Brand Independent Offer Exchange
Note that a Brand Independent Offer Document Exchange always occurs
when only one payment brand, protocol and currency/amount is being
offered to the Consumer by the Merchant. It is also likely to, but
will not necessarily, occur when multiple brands are being offered,
the Payment Handler is the same, and all brands use the same set of
protocols.
Note that the TPO Block and the Offer Response Block can be sent in
separate IOTP messages (see Brand Dependent Offer Document Exchange)
even if the Offer Response Block does not change. However this
increases the number of messages in the transaction and is therefore
likely to increase transaction response times.
IOTP aware applications supporting the Consumer Trading Role must
check for the existence of an Offer Response Block in the first IOTP
Message to determine whether the Offer Document Exchange is brand
dependent or not.
MESSAGE PROCESSING GUIDELINES
On receiving a TPO and Offer Response IOTP Message (see below), the
Consumer may either:
o generate and send the next IOTP Message in the IOTP transaction
and send it to the required Trading Role. This is dependent on the
IOTP Transaction, or
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Offer, a ProcessState of Failed and the
CompletionCode (see section 7.16.1) set to either: ConsCancelled
or Unspecified.
If the Merchant receives an IOTP Message containing a Cancel block,
then the Consumer is likely to go to the CancelNetLocn specified on
the Trading Role Element in the Organisation Component for the
Merchant.
9.1.2.3 TPO IOTP Message
The TPO IOTP Message is only used with a Brand Dependent Offer
Document Exchange. Apart from a Transaction Reference Block (see
section 3.3), this message consists of just a Trading Protocol
Options Block (see section 8.1) which is described below.
TPO (TRADING PROTOCOL OPTIONS) BLOCK
The Trading Protocol Options Block (see section 8.1) must contain the
following Trading Components:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 7.1.
o one Brand List Component (see section 7.7) for each Payment in the
IOTP Transaction that contain one or more payment brands and
protocols which may be selected for use in each payment
o Organisation Components (see section 7.6) with the following
roles:
- Merchant who is making the offer
- Consumer who is carrying out the transaction
- the PaymentHandler(s) for the payment. The "ID" of the Payment
Handler Organisation Component is contained within the PhOrgRef
attribute of the Payment Component
If the IOTP Transaction includes a Delivery then the TPO Block must
also contain:
o Organisation Components with the following roles:
- DeliveryHandler who will be delivering the goods or services
- DelivTo i.e. the person or Organisation which is to take
delivery
AUTHENTICATION STATUS AND SIGNATURE BLOCKS
If the Offer Document Exchange was preceded by an Authentication
Document Exchange, then the TPO IOTP Message may also contain:
o an Authentication Status Block (see section 8.6), and
o an optional Signature Block (Authentication Status) Signature
Block
See section 9.1.1.4 Authentication Status IOTP Message for more
details.
9.1.2.4 TPO Selection IOTP Message
The TPO Selection IOTP Message is only used with a Brand Dependent
Offer Document Exchange. Apart from a Transaction Reference Block
(see section 3.3), this message consists of just a TPO Selection
Block (see section 8.1) which is described below.
TPO SELECTION BLOCK
The TPO Selection Block (see section 8.2) contains:
o one Brand Selection Component (see section 7.8) for use in a
later Payment Exchange. It contains the results of the consumer
selecting a Payment Brand, Payment Protocol and currency/amount
from the list provided in the Brand List Component.
9.1.2.5 Offer Response IOTP Message
The Offer Response IOTP Message is only used with a Brand Dependent
Offer Document Exchange. Apart from a Transaction Reference Block
(see section 3.3), this message consists of:
o an Offer Response Block (see section 8.1) and
o an optional Signature Block (see section 8.16).
OFFER RESPONSE BLOCK
The Offer Response Block (see section 8.3) contains the following
components:
o one Status Component (see section 7.16) which indicates the status
of the Offer Response. The ProcessState attribute should be set to
CompletedOk
o one Order Component (see section 7.5) which contains details about
the goods and services which are being purchased or the financial
transaction which is taking place
o one or more Payment Component(s) (see section 7.9) for each
payment which is to be made
o zero or one Delivery Components (see section 7.13) containing
details of the delivery to be made if the IOTP Transaction
includes a delivery
o zero or more Trading Role Data Components (see section 7.17) if
required by the Merchant.
SIGNATURE BLOCK (OFFER RESPONSE)
If the Authentication Status Block is being digitally signed then a
Signature Block must be included that contains a Signature Component
(see section 7.19) with Digest Elements for the following XML
elements:
If the Offer Response is being digitally signed then a Signature
Block must be included that contains a Signature Component (see
section 7.19) with Digest Elements for the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o the following components of the TPO Block :
- the Protocol Options Component, and
- the Brand List Component
- all the Organisation Components present
o the following components of the Offer Response Block:
- the Order Component
- all the Payment Components present
- the Delivery Component if present
- any Trading Role Data Components present
9.1.2.6 TPO and Offer Response IOTP Message
The TPO and Offer Response IOTP Message is only used with a Brand
Independent Offer Document Exchange. Apart from a Transaction
Reference Block (see section 3.3), this message consists of:
o a Trading Protocol Options Block (see section 8.1)
o an Offer Response Block (see section 8.1) and
o an optional Signature Block (see section 8.16).
TPO (TRADING PROTOCOL OPTIONS) BLOCK
This is the same as the Trading Protocol Options Block described in
TPO IOTP Message (see section 9.1.2.3).
OFFER RESPONSE BLOCK
This the same as the Offer Response Block in the Offer Response IOTP
Message (see section 9.1.2.5).
AUTHENTICATION STATUS
If the Offer Document Exchange was preceded by an Authentication
Document Exchange, then the TPO and Offer Response IOTP Message may
also contain an Authentication Status Block (see section 8.6).
SIGNATURE BLOCK
This is the same as the Signature Block in the Offer Response IOTP
Message (see section 9.1.2.5) with the addition that:
o if the Offer Document Exchange is Brand Dependent then the
Signature Component in the Signature Block additionally contains a
Digest Element for the Brand Selection Component contained in the
TPO Selection Block
o if the Offer Document Exchange was preceded by an Authentication
Document Exchange then the Signature Component in the Signature
Block additionally contains a Digest Element for the
Authentication Status Block.
9.1.3 Payment Document Exchange
The Payment Document Exchange is a direct implementation of the last
part of a Payment Trading Exchange (see section 2.2.2) after the
Brand has been selected by the Consumer. A Payment Exchange consists
of:
o the Consumer requesting that a payment starts by generating
Payment Request IOTP Message using information from previous IOTP
Messages in the Transaction and then sending it to the Payment
Handler
o the Payment Handler and the Consumer then swapping Payment
Exchange IOTP Messages encapsulating payment protocol messages
until the payment is complete, and finally
o the Payment Handler sending a Payment Response IOTP Message to the
Consumer containing a receipt for the payment.
The IOTP Messages which are involved are illustrated by the diagram
below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
Payment
Handler
STEP
1. Consumer generates Pay Request Block encapsulating a
payment protocol message if required and sends to Payment
Handler with the Signature Block if present
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Request Block
2. Payment Handler processes Pay Request Block, checks
optional signature and starts exchanging payment protocol
messages encapsulated in a Pay Exchange Block, with the
Consumer
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
3. Consumer and Payment Handler keep on exchanging Payment
Exchange blocks until eventually payment protocol
messages finish so Payment Handler creates a Pay Receipt
Component inside a Pay Response Block, and an optional
Signature Component inside a Signature Block, sends them
to the Consumer and stops.
C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Response Block
4. Consumer checks Payment Response is OK. Optionally keeps
information on IOTP Transaction for record keeping
purposes and either stops or creates the next IOTP
message for the Transaction and sends it together with
the Signature Block, if present, to the required Trading
Role
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 21 Payment Document Exchange
9.1.3.1 Message Processing Guidelines
On receiving a Payment Request IOTP Message, the Payment Handler
should check that they are authorised to carry out the Payment (see
section 6 Digital Signatures). They may then either:
o generate and send a Payment Exchange IOTP Message back to the
Consumer, if more payment protocol messages need to be exchanged,
or
o generate and send a Payment Response IOTP Message if the exchange
of payment protocol messages is complete, or
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: BrandNotSupp,
CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds,
InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.
On receiving a Payment Exchange IOTP Message, the Consumer may
either:
o generate and send a Payment Exchange Message back to the Payment
Handler or
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Payment Handler containing a Status Component
with a StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.2) set to either: ConsCancelled
or Unspecified.
On receiving a Payment Exchange IOTP Message, the Payment Handler may
either:
o generate and send a Payment Exchange IOTP Message back to the
Consumer, if more payment protocol messages need to be exchanged,
or
o generate and send a Payment Response IOTP Message if the exchange
of payment protocol messages is complete, or
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.2) set to either: PaymtCancelled
or Unspecified.
On receiving a Payment Response IOTP Message, the Consumer may
either:
o generate and send the next IOTP Message in the IOTP transaction
and send it to the required Trading Role. This is dependent on the
IOTP Transaction,
o stop, since the IOTP Transaction has ended, or
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.1) set to either: ConsCancelled
or Unspecified.
If the Consumer receives an IOTP Message containing a Cancel block,
then the information contained in the IOTP Message should be reported
to the Consumer but no further action taken.
If the Payment Handler receives an IOTP Message containing a Cancel
block, then the Consumer is likely to go to the CancelNetLocn
specified on the Trading Role Element in the Organisation Component
for the Payment Handler from which any further action may take place.
If the Merchant receives an IOTP Message containing a Cancel block,
then the Consumer should have completed the payment but not
continuing with the transaction for some reason. In this case the
Consumer is likely to go to the CancelNetLocn specified on the
Trading Role Element in the Organisation Component for the Merchant
from which any further action may take place.
9.1.3.2 Payment Request IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this
message consists of:
o a Payment Request Block, and
o an optional Signature Block
PAYMENT REQUEST BLOCK
The Payment Request Block (see section 8.7) contains:
o the following components copied from the Offer Response Block from
the preceding Offer Document Exchange:
- the Status Component
- the Payment Component for the payment which is being carried
out
o the following components from the TPO Block:
- the Organisation Components with the roles of Merchant and for
the PaymentHandler that is being sent the Payment Request Block
- the Brand List Component for the payment, i.e. the Brand List
referred to by the BrandListRef attribute on the Payment
Component
o one Brand Selection Component for the Brand List, i.e. the Brand
Selection Component where BrandListRef attribute points to the
Brand List. This component can be either:
- copied from the TPO Selection Block if the payment was preceded
by a Brand Dependent Offer Document Exchange (see section
9.1.2.1), or
- created by the Consumer, containing the payment brand, payment
protocol and currency/amount selected from the Brand List, if
the payment was preceded by a Brand Independent Offer Document
Exchange (see section 9.1.2.2)
o an optional Payment Scheme Component (see section 7.10) if
required by the payment method used (see the Payment Method
supplement to determine if this is needed).
o zero or more Trading Role Data Components (see section 7.17).
Note that:
o if there is more than one Payment Components in an Offer Response
Block, then the second payment is the one within the Offer
Response Block that contains a StartAfter attribute (see section
7.9) that identifies the Payment Component for the first payment
o the Payment Handler to include is identified by the Brand
Selection Component (see section 7.8) for the payment. Also see
section 6.3.1 Check Request Block sent Correct Organisation for an
explanation on how Payment Handlers are identified
o the Brand List Component to include is the one identified by the
BrandListRef attribute of the Payment Component for the identified
payment
o the Brand Selection Component to include from the Offer Response
Block is the one that contains an BrandListRef attribute (see
section 3.5) which identifies the Brand List Component for the
second payment.
SIGNATURE BLOCK (PAYMENT REQUEST)
If the either the preceding Offer Document Exchange included an Offer
Response Signature (see section 9.1.2.5 Offer Response IOTP Message),
or a preceding Payment Exchange included a Payment Response Signature
(see section 9.1.3.4 Payment Response IOTP Message) then they should
both be copied to the Signature Block in the Payment Request IOTP
Message.
9.1.3.3 Payment Exchange IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this
message consists of just a Payment Exchange Block.
PAYMENT EXCHANGE BLOCK
The Payment Exchange Block (see section 8.8) contains:
o one Payment Scheme Component (see section 7.10) which contains
payment method specific data. See the Payment Method supplement
for the payment method being used to determine what this should
contain.
9.1.3.4 Payment Response IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this
message consists of:
o a Payment Response Block, and
o an optional Signature Block
PAYMENT RESPONSE BLOCK
The Payment Response Block (see section 8.9) contains:
o one Payment Receipt Component (see section 7.11) which contains
scheme specific data which can be used to verify the payment
occurred
o one Payment Scheme Component (see section 7.10) if required which
contains payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain
o an optional Payment Note Component (see section 7.12)
o zero or more Trading Role Data Components (see section 7.17).
SIGNATURE BLOCK (PAYMENT RESPONSE)
If a signed Payment Receipt is being provided, indicated by the
SignedPayReceipt attribute of the Payment Component being set to
True, then the Signature Block should contain a Signature Component
which contains Digest Elements for the following:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies the
IOTP Transaction,
o the Payment Receipt Component from the Payment Response Block,
o the Payment Note Component from the Payment Response Block,
o the other Components referenced by the PayReceiptNameRefs
attribute (if present) of the Payment Receipt Component,
o the Status Component from the Payment Response Block,
o any Trading Role Data Components in the Payment Response Block,
and
o all the Signature Components contained in the Payment Request
Block if present.
9.1.4 Delivery Document Exchange
The Delivery Document Exchange is a direct implementation of a
Delivery Trading Exchange (see section 2.2.3). It consists of:
o the Consumer requesting a Delivery by generating Delivery Request
IOTP Message using information from previous IOTP Messages in the
Transaction and then sending it to the Delivery Handler
o the Delivery Handler sending a Delivery Response IOTP Message to
the Consumer containing details about the Handler's response to
the request together with an optional signature.
The message flow is illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
Delivery
Handler
STEP
1. Consumer generates Delivery Request Block and sends it to
the Delivery Handler with the Signature Block if present
C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Delivery Request Block
2. Delivery Handler checks the Status and Order Components
in the Delivery Request and the optional Signatures,
creates a Delivery Response Block, sends to the Consumer
and stops.
C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; Delivery Response Block
3. Consumer checks Delivery Response Block and optional
Signature Block are OK. Optionally keeps information on
IOTP Transaction for record keeping purposes and stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 22 Delivery Document Exchange
9.1.4.1 Message Processing Guidelines
On receiving a Delivery Request IOTP Message, the Delivery Handler
should check that they are authorised to carry out the Delivery (see
section 6 Digital Signatures). They may then either:
o generate and send a Delivery Response IOTP Message to the
Consumer, or
o indicate failure to continue with the Delivery by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Delivery, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: DelivCanceled,
or Unspecified.
On receiving a Delivery Response IOTP Message, the Consumer should
just stop since the IOTP Transaction is complete.
If the Consumer receives an IOTP Message containing a Cancel block,
then the information contained in the IOTP Message should be reported
to the Consumer but no further action taken.
9.1.4.2 Delivery Request IOTP Message
The Delivery Request IOTP Message consists of:
o a Delivery Request Block, and
o an optional Signature Block
DELIVERY REQUEST BLOCK
The Delivery Request Block (see section 8.10) contains:
o the following components copied from the Offer Response Block:
- the Status Component (see section 7.16)
- the Order Component (see section 7.5)
- the Organisation Component (see section 7.6) with the roles of:
Merchant, DeliveryHandler and DeliverTo
- the Delivery Component (see section 7.13)
o the following Component from the Payment Response Block:
- the Status Component (see section 7.16).
o zero or more Trading Role Data Components (see section 7.17).
SIGNATURE BLOCK (DELIVERY REQUEST)
If the preceding Offer Document Exchange included an Offer Response
Signature or the Payment Document Exchange included a Payment
Response Signature, then they should both be copied to the Signature
Block.
9.1.4.3 Delivery Response IOTP Message
The Delivery Response IOTP Message contains a Delivery Response Block
and an optional Signature Block.
DELIVERY RESPONSE BLOCK
The Delivery Response Block contains:
o one Delivery Note Component (see section 7.15) which contains
delivery instructions about the delivery of goods or services
in3 SIGNATURE BLOCK (DELIVERY RESPONSE)
The Signature Block should contain one Signature Component that
contains Digest elements that refer to
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Delivery Response Signature
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Delivery Response Signature
o the Consumer Delivery Data component contained in the Delivery
Request Block (if any)
o the Signature Components contained in the Delivery Request Block
(if any)
o the Status Component
o the Delivery Note Component
9.1.5 Payment and Delivery Document Exchange
The Payment and Delivery Document Exchange is a combination of the
last part of the Payment Trading Exchange (see section 2.2.2) and a
Delivery Trading Exchange (see section 2.2.3). It consists of:
o the Consumer requesting that a payment starts by generating
Payment Request IOTP Message using information from previous IOTP
Messages in the Transaction and then sending it to the Payment
Handler
o the Payment Handler and the Consumer then swapping Payment
Exchange IOTP Messages encapsulating payment protocol messages
until the payment is complete, and finally
o the Payment Handler sending to the Consumer in one IOTP Message:
- a Payment Response Block containing a receipt for the payment,
and
- a Delivery Response Block containing details of the goods or
services to be delivered
The IOTP Messages which are involved are illustrated by the diagram
below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
Payment
Handler
STEP
1. Consumer generates Pay Request Block encapsulating a
payment protocol message if required and sends to Payment
Handler with the Signature Block if present
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Pay Request Block
2. Payment Handler processes Pay Request Block, checks
optional signature and starts exchanging payment protocol
messages encapsulated in a Pay Exchange Block, with the
Consumer
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
3. Consumer and Payment Handler keep on exchanging Payment
Exchange blocks until eventually payment protocol
messages finish so Payment Handler creates a Pay Receipt
Component inside a Pay Response Block, and an optional
Signature Component inside a Signature Block, then uses
information from the Offer Response Bock to create a
Delivery Response Block and sends both to the Consumer
and stops.
C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
Block; Signature Block; Pay Response Block; Delivery
Response Block
4. Consumer checks Payment Response and Delivery Response
Blocks are OK. Optionally keeps information on IOTP
Transaction for record keeping purposes and either stops
or creates the next IOTP message for the Transaction and
sends it together with the Signature Block, if present,
to the required Trading Role
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 23 Payment and Delivery Document Exchange
The Delivery Response Block and the Payment Response Block may be
combined into the same IOTP Message only if the Payment Handler has
the information available so that she can send the Delivery Response
Block. This is likely to, but will not necessarily, occur when the
Merchant, the Payment Handler and the Delivery Handler Roles are
combined.
The DelivAndPayResp attribute of the Delivery Component (see section
7.13) contained within the Offer Response Block (see section 8.3) is
set to True if the Delivery Response Block and the Payment Response
Block are combined into the same IOTP Message and is set to False if
the Delivery Response Block and the Payment Response Block are sent
in separate IOTP Messages.
9.1.5.1 Message Processing Guidelines
On receiving a Payment Request IOTP Message or a Payment Exchange
IOTP Message, the Payment Handler should carry out the same actions
as for a Payment Document Exchange (see section 9.1.3.1).
On receiving a Payment Exchange IOTP Message, the Consumer should
also carry out the same actions as for a Payment Document Exchange
(see section 9.1.3.1).
On receiving a Payment Response and Delivery Response IOTP Message
then the IOTP Transaction is complete and should take no further
action.
If the Consumer receives an IOTP Message containing a Cancel block,
then the information contained in the IOTP Message should be reported
to the Consumer but no further action taken.
If the Payment Handler receives an IOTP Message containing a Cancel
block, then the Consumer is likely to go to the CancelNetLocn
specified on the Trading Role Element in the Organisation Component
for the Payment Handler from which any further action may take place.
If the Merchant receives an IOTP Message containing a Cancel block,
then the Consumer should have completed the payment but not
continuing with the transaction for some reason. In this case the
Consumer is likely to go to the CancelNetLocn specified on the
Trading Role Element in the Organisation Component for the Merchant
from which any further action may take place.
9.1.5.2 Payment Request IOTP Message
The content of this message is the same as for a Payment Request IOTP
Message in a Payment Document Exchange (see section 9.1.3.2).
9.1.5.3 Payment Exchange IOTP Message
The content of this message is the same as for a Payment Exchange
IOTP Message in a Payment Document Exchange (see section 9.1.3.3).
9.1.5.4 Payment Response and Delivery Response IOTP Message
The content of this message consists of:
o a Payment Response Block,
o an optional Signature Block (Payment Response), and
o a Delivery Response Block.
PAYMENT RESPONSE BLOCK
The content of this block is the same as the Payment Response Block
in the Payment Response IOTP Message associated with a Payment
Document Exchange (see section 9.1.3.4).
SIGNATURE BLOCK (PAYMENT RESPONSE)
The content of this block is the same as the Signature Block (Payment
Response) in the Payment Response IOTP Message associated with a
Payment Document Exchange (see section 9.1.3.4).
DELIVERY RESPONSE BLOCK
The content of this block is the same as the Delivery Response Block
in the Delivery Response IOTP Message associated with a Delivery
Document Exchange (see section 9.1.4.3).
9.1.6 Baseline Authentication IOTP Transaction
A Baseline Authentication IOTP Transaction may occur at any time
between any of the Trading Roles involved in IOTP Transactions. This
means it could occur:
o before another IOTP Transaction
o at the same time as another IOTP Transaction
o independently of any other IOTP Transaction.
The Baseline Authentication IOTP Transaction consists of just an
Authentication Document Exchange (see section 9.1.1) as illustrated
by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -------------------------------------------------------
v
----------------
AUTHENTICATION
----------------
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
v
STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 24 Baseline Authentication IOTP Transaction
Example uses of the Baseline Authentication IOTP Transaction include:
o when the Baseline Authentication IOTP Transaction takes place as
an early part of a session where strong continuity exists. For
example, a Financial Institution could:
- set up a secure channel (e.g., using [SSL/TLS]) with a customer
- authenticate the customer using the Baseline Authentication
IOTP Transaction, and then
- provide the customer with access to account information and
other services with the confidence that they are communicating
with a bona fide customer.
o as a means of providing a Merchant role with Organisation
Components that contain information about Consumer and DelivTo
Trading Roles
o so that a Consumer may authenticate a Payment Handler before
starting a payment.
9.1.7 Baseline Deposit IOTP Transaction
The Baseline Deposit IOTP Transaction supports the deposit of
electronic cash with a Financial Institution.
Note: The Financial Institution has, in IOTP terminology, a role of
merchant in that a service (i.e. a deposit of electronic cash) is
being offered in return for a fee, for example bank charges of some
kind. The term "Financial Institution" is used in the diagrams and in
the text for clarity.
The Baseline Deposit IOTP Transaction consists of the following
Document Exchanges:
o an optional Authentication Document Exchange (see section 9.1.1)
o an Offer Document Exchange (see section 9.1.2), and
o a Payment Document Exchange (see section 9.1.3).
The way in which these Document Exchanges may be combined together is
illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
v
----------------
AUTHENTICATION
----------------
--------------------------------------
-------------- -------------
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
-------------------
v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
----------------
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
-----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 25 Baseline Deposit IOTP Transaction
See section 9.1.12 "Valid Combinations of Document Exchanges" to
determine which combination of document exchanges apply to a
particular instance of an IOTP Transaction
Note that:
o a Merchant (Financial Institution) may be able to accept a deposit
in several different types of electronic cash although, since the
Consumer role that is depositing the electronic cash usually knows
what type of cash they want to deposit, it is usually constrained
in practice to only one type. However, there may be several
different protocols which may be used for the same "brand" of
electronic cash. In this case a Brand Dependent Offer may be
appropriate to negotiate the protocol to be used.
o the Merchant (Financial Institution) may use the results of the
authentication to identify not only the consumer but also the
account to which the payment is to be deposited. If no single
account can be identified, then it must be obtained by other
means. For example:
- the consumer could specify the account number prior to the
Baseline Deposit IOTP Transaction starting, or
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an
account selected from a list provided by the Financial
Institution.
o The Baseline Deposit IOTP Transaction without an Authentication
Document Exchange might be used:
- if a previous IOTP transaction, for example a Baseline
Withdrawal or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained, therefore
the authenticity of the consumer is known
- if authentication is achieved as part of a proprietary payment
protocol and is therefore included in the Payment Document
Exchange
- if authentication of the consumer has been achieved by some
other means outside of the scope of IOTP, for example, by using
a pass phrase, or a proprietary banking software solution.
9.1.8 Baseline Purchase IOTP Transaction
The Baseline Purchase IOTP Transaction supports the purchase of goods
or services using any payment method. It consists of the following
Document Exchanges:
o an optional Authentication Document Exchange (see section 9.1.1)
o an Offer Document Exchange (see section 9.1.2)
o either:
- a Payment Document Exchange (see section 9.1.3) followed by
- a Delivery Document Exchange (see section 9.1.4)
o a Payment Document Exchange only, or
o a combined Payment and Delivery Document Exchange (see section
9.1.5).
The ways in which these Document Exchanges are combined is
illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
v
----------------
AUTHENTICATION
----------------
--------------------------------------
-------------- -------------
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
---------------
-------------- --
v v v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
-----------------------------
v
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
v
----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 26 Baseline Purchase IOTP Transaction
See section 9.1.12 "Valid Combinations of Document Exchanges" to
determine which combination of document exchanges apply to a
particular instance of an IOTP Transaction.
9.1.9 Baseline Refund IOTP Transaction
In business terms the refund process typically consists of:
o a request for a refund being made by the Consumer to the Merchant,
typically supported by evidence to demonstrate:
- the original trade took place, for example by providing a
receipt for the original transaction
- using some type of authentication, that the consumer requesting
the refund is the consumer, or a representative of the
consumer, who carried out the original trade
- the reason why the merchant should make the refund
o the merchant agreeing (or not) to the refund. This may involve
some negotiation between the Consumer and the Merchant, and, if
the merchant agrees,
o a refund payment by the Merchant to the Consumer.
The Baseline Refund IOTP Transaction supports a subset of the above,
specifically it supports:
o stand alone authentication of the Consumer using a separate
Baseline Authentication IOTP Transaction (see section 9.1.6)
o a refund payment by the Merchant to the Consumer using the
following two Trading Exchanges:
- an optional Authentication Document Exchange (see section
9.1.1)
- an Offer Document Exchange (see section 9.1.2), and
- a Payment Document Exchange (see section 9.1.3).
The ways in which these Document Exchanges are combined is
illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
v
----------------
AUTHENTICATION
----------------
--------------------------------------
-------------- -------------
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
-------------------
v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
----------------
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
-----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 27 Baseline Refund IOTP Transaction
A Baseline Refund IOTP Transaction without an Authentication Document
Exchange might be used:
o when authentication of the consumer has been achieved by some
other means, for example, the consumer has entered some previously
supplied code in order to identify herself and the refund to which
the code applies. The code could be supplied, for example on a web
page or by e-mail.
o when a previous IOTP transaction, for example a Baseline
Authentication, authenticated the consumer, and a secure channel
has been maintained, therefore the authenticity of the consumer is
known and therefore the previously agreed refund can be
identified.
o when the authentication of the consumer is carried out by the
Payment Handler using a payment scheme authentication algorithm.
9.1.10 Baseline Withdrawal IOTP Transaction
The Baseline Withdrawal IOTP Transaction supports the withdrawal of
electronic cash from a Financial Institution.
Note: The Financial Institution has, in IOTP terminology, a role of
merchant in that a service (i.e. a withdrawal of electronic cash) is
being offered in return for a fee, for example bank charges of some
kind. The term "Financial Institution" is used in the diagrams and in
the text for clarity.
The Baseline Withdrawal IOTP Transaction consists of the following
Document Exchanges:
o an optional Authentication Document Exchange (see section 9.1.1)
o an Offer Document Exchange (see section 9.1.2), and
o a Payment Document Exchange (see section 9.1.3).
The way in which these Document Exchanges may be combined together is
illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
v
----------------
AUTHENTICATION
----------------
--------------------------------------
-------------- -------------
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
-------------------
v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
----------------
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
-----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 28 Baseline Withdrawal IOTP Transaction
Note that:
o a Merchant (Financial Institution) may be able to offer withdrawal
of several different types of electronic cash. In practice usually
only one form of electronic cash may be offered. However, there
may be several different protocols which may be used for the same
"brand" of electronic cash.
o the Merchant (Financial Institution) may use the results of the
authentication to identify not only the consumer but also the
account from which the withdrawal is to be made. If no single
account can be identified, then it must be obtained by other
means. For example:
- the consumer could specify the account number prior to the
Baseline Withdrawal IOTP Transaction starting, or
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an
account selected from a list provided by the Financial
Institution.
o a Baseline Withdrawal without an authentication might be used:
- if a previous IOTP transaction, for example a Baseline Deposit
or a Baseline Authentication, authenticated the consumer, and a
secure channel has been maintained, therefore the authenticity
of the consumer is known
- if authentication is achieved as part of a proprietary payment
protocol and is therefore included in the Payment Document
Exchange
- if authentication of the consumer has been achieved by some
other means, for example, by using a pass phrase, or a
proprietary banking software solution.
9.1.11 Baseline Value Exchange IOTP Transaction
The Baseline Value Exchange Transaction uses Payment Document
Exchanges to support the exchange of value in one currency obtained
using one payment method with value in the same or another currency
using the same or another payment method. Examples of its use
include:
o electronic cash advance on a credit card. For example the first
payment could be a "dollar SET Payment" using a credit card with
the second payment being a download of Visa Cash e-cash in
dollars.
o foreign exchange using the same payment method. For example the
payment could be an upload of Mondex value in British Pounds and
the second a download of Mondex value in Euros
o foreign exchange using different payment methods. For example the
first payment could be a SET payment in Canadian Dollars followed
a download of GeldKarte in Deutchmarks.
The Baseline Value Exchange uses the following Document Exchanges:
o an optional Authentication Document Exchange (see section 9.1.1)
o an Offer Document Exchange (see section 9.1.2), which provides
details of what values and currencies will be exchanged, and
o two Payment Document Exchanges (see section 9.1.3) which carry out
the two payments involved.
The way in which these Document Exchanges may be combined together is
illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
v
----------------
AUTHENTICATION
----------------
--------------------------------------
-------------- -------------
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
-------------------
v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
----
v
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
-----------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 29 Baseline Value Exchange IOTP Transaction
The Baseline Value Exchange IOTP Transaction occurs in two basic
forms:
o Brand Dependent Value Exchange. Where the content of the offer,
for example the rate at which one form of value is exchanged for
another, is dependent on the payment brands and protocols selected
by the consumer, and
o Brand Independent Value Exchange. Where the content of the offer
is not dependent on the payment brands and protocols selected.
Note: In the above the role is a Merchant even though the
Organisation carrying out the Value Exchange may be a Bank or some
other Financial Institution. This is because the Bank is acting as a
merchant in that they are making an offer which the Consumer can
either accept or decline.
The TPO Block and Offer Response Block may only be combined into the
same IOTP Message if the content of the Offer Response Block does not
change as a result of selecting the payment brands and payment
protocols to be used in the Value Exchange.
BASELINE VALUE EXCHANGE SIGNATURES
The use of signatures to ensure the integrity of a Baseline Value
Exchange is illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Signature generated IotpMsg (TPO)
by Merchant ensures - Trans Ref Block
integrity of the Offer --------> - - Signature Block
- TPO Block MERCHANT
- Offer Response Block
Signature generated by
the Payment Handler of IotpMsg (Pay Resp 1)
the first payment binds - Trans Ref Block PAYMENT
Pay Receipt for the first -----> -> - Signature Block ----- HANDLER
payment to the Offer - Pay Response Block 1 1
Signature generated by
the Payment Handler of IotpMsg (Pay Resp 2) PAYMENT
the second payment binds - Trans Ref Block HANDLER
the second payment to the -----> - Signature Block <------ 2
first payment and therefore - Pay Response Block 2
to the Offer
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 30 Baseline Value Exchange Signatures
9.1.12 Valid Combinations of Document Exchanges
The following diagram illustrates the data conditions in the various
IOTP messages which can be used by a Consumer Trading Role to
determine whether the combination of Document Exchanges are valid.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START
v
Auth Request Block in =TRUE
first IOTP Message ? ---------------------------------------
= FALSE
v v
Offer Response Block in ----------------
first IOTP Message ? AUTHENTICATION
=TRUE =FALSE ----------------
v
---------------------- TPO & Offer Response
------------- Blocks in last IOTP Msg
=TRUE =FALSE
v
------------- ---- TPO Block only if
last IOTP Message
of Authentication
=TRUE =FALSE
v v v v
------------------- -----------------
BRAND INDEPENDENT BRAND DEPENDENT
OFFER OFFER
------------------- -----------------
v v
Offer Response Block contains
Delivery Component ?
=FALSE =TRUE
--- v
Value of DelivAndPayResp
attribute of Delivery Component ?
=FALSE =TRUE
v v v
--------- --------------
PAYMENT PAYMENT WITH
(first) DELIVERY
--------- --------------
v
Offer and Response Block contains -------------->
Delivery Component ?
=TRUE =FALSE
v
Two Payment Components
present in Offer Response Block?
=TRUE =FALSE
v v
---------- ---------
DELIVERY PAYMENT
{second)
---------- ---------
v
----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 31 Valid Combinations of Document Exchanges
1) If first IOTP Message of an IOTP Transaction contains an
Authentication Request then:
a) IOTP Transaction includes an Authentication Document Exchange
(see section 9.1.1). (Note 1)
b) If the last IOTP Message of the Authentication Document
Exchange includes a TPO Block and an Offer Response Block then:
i) IOTP Transaction includes a Brand Independent Offer Document
Exchange (see section 9.1.2.2). (Note 2)
c) Otherwise, if the last IOTP Message of the Authentication
Exchange includes a TPO Block but NO Offer Response Block,
then:
i) IOTP Transaction includes a Brand Dependent Offer Document
Exchange (see section 9.1.2.1). (Note 2)
d) Otherwise (Authentication Status IOTP Message of the
Authentication Document Exchange contains neither a TPO Block
but nor an Offer Response Block)
i) IOTP Transaction consists of just an Authentication Document
Exchange. (Note 3)
2) Otherwise (no Authentication Request in first IOTP Message):
e) IOTP Transaction does not include an Authentication Document
Exchange (Note 2)
f) If first IOTP Message contains an Offer Response Block, then:
i) the IOTP Transaction contains a Brand Independent Offer
Document Exchange (Note 2)
g) Otherwise (no Offer Response Block in first IOTP Message):
i) the IOTP Transaction includes a Brand Dependent Offer
Document Exchange (Note 2)
3) If an Offer Response Block exists in any IOTP message then:
h) If the Offer Response Block contains a Delivery Component then:
i) If the DelivAndPayResp attribute of the Delivery Component
is set to True, then:
(1) the IOTP Transaction consists of a Payment And Delivery
Document Exchange (see section 9.1.5) (Note 4)
ii) otherwise (the DelivAndPayResp attribute of the Delivery
Component is set to False)
(1) the IOTP Transaction consists of a Payment Document
Exchange (see section 9.1.3) followed by a Delivery
Document Exchange (see section 9.1.4) (Note 4)
i) otherwise (the Offer Response Block does not contain a Delivery
Component)
i) if the Offer Response Block contains just one Payment
Component, then:
(1) the IOTP Transaction contains just one Payment Document
Exchange (Note 5)
ii) if the Offer Response Block contains two Payment Components,
then:
(1) the IOTP Transaction contains two Payment Document
Exchanges. The StartAfter attribute of the Payment
Components is used to indicate which payment occurs
first (Note 6)
iii) if the Offer Response Block contains no or more than two
Payment Components, then there is an error
4) Otherwise (no Offer Response Block) there is an error.
The following table indicates the types of IOTP Transactions which
can validly have the conditions indicated above.
Note IOTP Transaction Validity
1. Any Payment and Authentication IOTP Transaction
2. Any Payment and Authentication IOTP Transaction except Baseline
Authentication
3. Either Baseline Authentication, or a Baseline Purchase, Refund,
Deposit, Withdrawal or Value Exchange with a failed Authentication
4. Baseline Purchase only
5. Baseline Purchase, Refund, Deposit or Withdrawal
6. Baseline Value Exchange only
9.1.13 Combining Authentication Transactions with other Transactions
In the previous sections an Authentication Document Exchange is shown
preceding an Offer Document Exchange as part of a single IOTP
Transaction with the same IOTP Transaction Id.
It is also possible to run a separate Authentication Transaction at
any point, even in parallel with another IOTP Transaction. Typically
this will be used:
o by a Consumer to authenticate a Merchant, Payment Handler or a
Delivery Handler, or
o by a Payment Handler or Delivery Handler to authenticate a
Consumer.
In outline the basic process consists of:
o the Trading Role that decides it wants to carry out an
authentication of another role suspends the current IOTP
transaction being carried out
o a stand-alone Authentication transaction is then carried out. This
may, at implementer's option, be linked to the original IOTP
Transaction using a Related To Component (see section 3.3.3) in
the Transaction Reference Block.
o if the Authentication transaction is successful, then the original
IOTP Transaction is restarted
o if the Authentication fails then the original IOTP Transaction is
cancelled.
For example, a Consumer could:
o authenticate the Payment Handler for a Payment between receiving
an Offer Response from a Merchant and before sending the Payment
Request to that Payment Handler
o authenticate a Delivery Handler for a Delivery between receiving
the Payment Response from a Payment Handler and before sending the
Delivery Request
A Payment Handler could authenticate a Consumer after receiving the
Payment Request and before sending the next Payment related message.
A Delivery Handler could authenticate a Consumer after receiving the
Delivery Request and before sending the Delivery Response.
Note: Some Payment Methods may carry out an authentication within the
Payment Exchange. In this case the information required to carry out
the authentication will be included in Payment Scheme Components.
In this instance IOTP aware application will not be aware that an
authentication has occurred since the Payment Scheme Components that
contain authentication request information will be indistinguishable
from other Payment Scheme Components.
9.2 Infrastructure Transactions
Infrastructure Transactions are designed to support inquiries about
whether or not a transaction has succeeded or a Trading Role's
servers are operating correctly. There are two types of transaction:
o a Transaction Status Inquiry Transaction which provides
information on the status of an existing or complete IOTP
transaction, and
o Ping Transaction that enables one IOTP aware application to
determine if the IOTP aware application at another Trading Role is
operating and verify whether or not signatures can be handled.
Each of these is described below
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
The Baseline IOTP Transaction Status Inquiry provides information on
the status of an existing or complete IOTP transaction.
The Trading Blocks used by the Baseline Transaction Status Inquiry
Transaction are:
o an Inquiry Request Trading Block (see section 8.12),
o an Inquiry Response Trading Block (see section 8.13)
o an optional Signature Block (see section 8.16).
The Inquiry IOTP Transaction can be used for a variety of reasons.
For example:
o to help in resuming a suspended transaction to determine the
current state of processing of one of the other roles,
o for a merchant to determine if a payment, delivery, etc., was
completed. For example, a Consumer might claim that payment was
made but no signed IOTP payment receipt was available to prove it.
If the Merchant makes an inquiry of the Payment Handler then the
Merchant can determine whether or not payment was made.
Note: Inquiries on Baseline Ping IOTP Transactions (see section
9.2.2) are ignored.
MAKING INQUIRIES OF ANOTHER TRADING ROLE
One Trading Role may make an inquiry of any other Trading Role at any
point in time.
IOTP aware software that supports the Consumer Trading Role may not:
o digitally sign a response if requested, since it may not have the
capability, or
o respond to an Inquiry Request at all since it may not be on-line,
or may consider that the request is not reasonable since, for
example, the Request was not digitally signed.
As a guideline:
o the Consumer should send a Transaction Status Inquiry Block to a
Trading Role only after the following events have occurred:
- to the Merchant, after sending a TPO Selection Block,
- to the Payment Handler, after sending a Payment Request Block,
- to the Delivery Handler, after sending a Delivery Request Block,
o other Trading Roles should send a Transaction Status Inquiry Block
to the Consumer only after receiving a message from the Consumer
and before sending the final "Response" message to the Consumer
o there are no restrictions on non-Consumer Trading Roles sending
Inquiries to other trading roles.
TRANSACTION STATUS INQUIRY TRANSPORT SESSION
For a Transaction Status Inquiry on an ongoing transaction a
different transport session from the ongoing transaction is used. For
a Transaction Status Inquiry on a past transaction, how the IOTP
module on the software at the Trading Role is started upon the
receipt of Inquiry Request message is defined in each Mapping to
Transport supplement for IOTP.
TRANSACTION STATUS INQUIRY ERROR HANDLING
Errors in a Transaction Status Inquiry can be categorised into one of
the following three cases:
o Business errors (see section 4.2) in the original (inquired)
messages
o Technical errors (see section 4.1) - both IOTP and payment scheme
specific ones - in the original IOTP (inquired) messages
o Technical errors in the message containing the Inquiry Request
Block itself
The following outlines what the software should do in each case
BUSINESS ERRORS IN THE ORIGINAL MESSAGES
Return an Inquiry Response Block containing the Status Component
which was last sent to the Consumer Role.
TECHNICAL ERRORS IN THE ORIGINAL MESSAGES
Return an Inquiry Response Block containing a Status Component. The
Status Component should contain a ProcessState attribute set to
ProcessError. In this case send back an Error Block indicating where
the error was found in the original message.
TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK
Return an Error message. That is, send back an Error Block containing
the Error Code (see section 7.21.2) which describes the nature of the
error in the Inquiry Request message.
INQUIRY TRANSACTION MESSAGES
The following Figure outlines the Baseline IOTP Transaction Status
Inquiry process.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st Role
2nd Role
STEP
1. The first role decides to inquire on an IOTP Transaction
by, for example, clicking on the inquiry button of an
IOTP Aware Application. This will then generate an
Inquiry Request Block and send it to the appropriate
Trading Role.
1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
(optional); Inquiry Request Block
2. The Trading Role checks the digital signature (if
present). If the recipient wants to respond, then the
Trading Role checks the transaction status of the
transaction that is being inquired upon by using the
IotpTransId in the Transaction ID Component of the
Transaction Reference Block, then generates the
appropriate Inquiry Response Block, sends the message
back to the 1st Role and stops
1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry
Response Block; Signature Block (Optional)
3. First role checks the Inquiry Response Block and optional
signature, takes whatever action is appropriate or
perhaps stops. This may include displaying status
information to the end user.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 32 Baseline Transaction Status Inquiry
The remainder of this sub-section on the Baseline Transaction Status
Inquiry IOTP Transaction defines the contents of each Trading Block.
Note that the term "original transaction" is the transaction which a
trading role wants to discover some information about.
TRANSACTION REFERENCE BLOCK
A Trading Role making an inquiry must use a Transaction Id Component
(see section 3.3.1) where both the IotpTransId and TransTimeStamp
attributes are the same as in the Transaction Id Component of the
original transaction that is being inquired upon. The IotpTransId
attribute in this component serves as the key in querying the
transaction logs maintained at the Trading Role's site. The value of
the ID attribute of the Message Id Component should be different from
those of any in the original transaction (see section 3.4.1).
If up-to-date status information is required then the MsgId
Component, and in particular the ID attribute for the MsgId Component
must be different from any other IOTP Message that has been sent by
the Trading Role. This is required because of the way that
Idempotency is handled by IOTP (see section 4.5.2.2 Checking/Handling
Duplicate Messages).
INQUIRY REQUEST BLOCK
The Inquiry Request Block (see section 8.12) contains the following
components:
o one Inquiry Type Component (see section 7.18). This identifies
whether the inquiry is on an offer, payment, or delivery.
o zero or one Payment Scheme Components (see section 7.10). This is
for encapsulating payment scheme specific inquiry messages for
inquiries on a payment.
SIGNATURE BLOCK (INQUIRY REQUEST)
If a signature block is present on the message containing the Inquiry
Request Block then it may be checked to determine if the Inquiry
Request is authorised.
If present, the Inquiry Request Signature Block (see section 8.12)
contains the following components:
o one Signature Component (see section 7.19)
o one or more Certificate Components, if required.
Inquiry Response Blocks should only be generated if the Transaction
is authorised.
Note: Digital signatures on an Inquiry Request is only likely to
occur if the recipient of the request expects the Inquiry Request to
be signed. In this version of IOTP this will require some kind of
pre-existing agreement. This means that:
o Consumers are unlikely to generate requests with signatures,
although it is not an error if they do
o the other trading roles may agree that digital signatures are
required. For example a Payment Handler may require that an
Inquiry Request is digitally signed by the Merchant so that they
can check that the request is valid.
On the other hand if the original transaction to which the Inquiry
relates was carried out over a secure channel (e.g., [SSL]) then it
is probably reasonable to presume that if the sender of the Inquiry
knows the Transaction Id component of the original message (including
for example the timestamp) then the inquiry is likely to be genuine.
INQUIRY RESPONSE BLOCK
The Inquiry Response Block (see section 8.13) contains the following
components:
o one Status Component (see section 7.16). This component holds the
status information on the inquired transaction,
o zero or one Payment Scheme Components. These contain encapsulated
payment scheme specific inquiry messages for inquiries on payment.
SIGNATURE BLOCK (INQUIRY RESPONSE)
If a signature block is present on the message containing the Inquiry
Response Block then it may be checked by the receiver of the block to
determine if the Inquiry Response is valid.
If present, the Inquiry Response Signature Block (see section 8.13)
contains the following components:
o one Signature Component (see section 7.19)
o one or more Certificate Components, if required.
Note: Digital signatures on an Inquiry Response is only likely to
occur if the recipient of the response expects the Inquiry Request to
be signed. In this version of IOTP this will require some kind of
pre-existing agreement. This means that:
o Consumers are unlikely to generate responses with signatures,
although it is not an error if they do
o the other trading roles may agree that digital signatures are
required. For example a Merchant may require that an Inquiry
Response is digitally signed by the Payment Handler so that they
can check that the request response is valid.
9.2.2 Baseline Ping IOTP Transaction
The purpose of the Baseline IOTP Ping Transaction is to test basic
connectivity between the Trading Roles that may take part in an IOTP
Transaction.
It enables IOTP aware application software to:
o determine if the IOTP aware application at another Trading Role is
operating, and
o verify whether or not the two trading roles signatures can be
processed.
For example it can be used by a Merchant to determine if a Payment
Handler or Delivery Handler is up and running prior to starting a
Purchase transaction that uses those trading roles.
The Trading Blocks used by the Baseline Ping IOTP Transaction are:
o a Ping Request Block (see section 8.14)
o a Ping Response Block (see section 8.15), and
o a Signature Block (see section 8.16).
PING MESSAGES
The following figure outlines the message flows in the Baseline IOTP
Ping Transaction.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st Role
2nd Role
STEP
1. The IOTP Aware Application in the first Trading Role
decides to check whether the counterparty IOTP
application is up and running. It generates a Ping
Request Block and optional Signature Block and sends them
to the second trading role.
1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Request Block
2. The second Trading Role which receives the Ping Request
Block generates a Ping Response Block and sends it back
to the sender of the original Ping Request with a
signature block if required.
1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Response Block
3. The first Trading Role checks the Ping Response Block and
takes appropriate action, if necessary
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 33 Baseline Ping Messages
The verification that signatures can be handled is indicated by the
sender of the Ping Request Block including:
o Organisation Components that identify itself and the intended
recipient of the Ping Request Block, and
o a Signature Block that signs data in the Ping Request.
In this way the receiver of the Ping Request:
o knows who is sending the Ping Request and can therefore verify the
Signature on the Request, and
o knows who to generate a signature for on the Ping Response.
Note that a Ping Request:
o does not affect any on-going transaction
o does NOT initiate an IOTP transaction, unlike other IOTP
transaction messages such as TPO or Transaction Status Inquiry.
All IOTP aware applications must return a Ping Response message to
the sender of a Ping Request message when it is received.
A Baseline IOTP Ping request can also contain an optional Signature
Block. IOTP aware applications can, for example, use the Signature
Block to check the recipient of a Ping Request can successfully
process and check signatures it has received.
For each Baseline Ping IOTP Transaction, each IOTP role shall
establish a different transport session from other IOTP transactions.
Any IOTP Trading Role can send a Ping request to any other IOTP
Trading Role at any time it wants. A Ping message has its own
IotpTransId, which is different from other IOTP transactions.
The remainder of this sub-section on the Baseline Ping IOTP
Transaction defines the contents of each Trading Block.
TRANSACTION REFERENCE BLOCK
The IotpTransId of a Ping transaction should be different from any
other IOTP transaction.
PING REQUEST BLOCK
If the Ping Transaction is anonymous then no Organisation Components
are included in the Ping Request Block (see section 8.7).
If the Ping Transaction is not anonymous then the Ping Request Block
contains Organisation Components for:
o the sender of the Ping Request Block, and
o the verifier of the Signature Component
If Organisation Components are present, then it indicates that the
sender of the Ping Request message has generated a Signature Block.
The signature block must be verified by the Trading Role that
receives the Ping Request Block.
SIGNATURE BLOCK (PING REQUEST)
The Ping Request Signature Block (see section 8.16) contains the
following components:
o one Signature Component (see section 7.19)
o one or more Certificate Components, if required.
PING RESPONSE BLOCK
The Ping Response Block (see section 8.15) contains the following
component:
o the Organisation Component of the sender of the Ping Response
message
If the Ping Transaction is not anonymous then the Ping Response
additionally contains:
o copies of the Organisation Components contained in the Ping
Request Block.
SIGNATURE BLOCK (PING RESPONSE)
The Ping Response Signature Block (see section 8.16) contains the
following components:
o one Signature Component (see section 7.19)
o one or more Certificate Components, if required.
10. Retrieving Logos
This section describes how to retrieve logos for display by IOTP
aware software using the Logo Net Locations attribute contained in
the Brand Element (see section 7.7.1) and the Organisation Component
(see section 7.6).
The full address of a logo is defined as follows: Logo_address ::=
Logo_net_location "/" Logo_size Logo_color_depth ".gif"
Where:
o Logo_net_location is obtained from the LogoNetLocn attribute in
the Brand Element (see section 7.7.1) or the Organisation
Component. Note that:
- the content of this attribute is dependent on the Transport
Mechanism (such as HTTP) that is used. See the Transport
Mechanism supplement,
- implementers should check that if the rightmost character of
Logo Net Location is set to right-slash "/" then another, right
slash should not be included when generating the Logo Address,
o Logo_size identifies the size of the logo,
o Logo_color_depth identifies the colour depth of the logo
o "gif" indicates that the logos are in "gif" format
Logo_size and Logo_color_depth are specified by the implementer of
the IOTP software that is retrieving the logo depending on the size
and colour that they want to use.
10.1 Logo Size
There are five standard sizes for logos. The sizes in pixels and the
corresponding values for Logo Size are given in the table below.
Size in Logo Size
Pixels Value
32 x 32 or exsmall
32 x 20
53 x 33 small
103 x 65 medium
180 x 114 large
263 x 166 exlarge
10.2 Logo Color Depth
There are three standard colour depths. The colour depth (including
bits per pixel) and the corresponding value for Logo_Color_Depth are
given in the table below.
Color Depth Logo Color
(bits per pixel) Depth Value
4 (16 colors) 4
8 (256 colors) nothing
24 (16 million colors) 24
Note that if Logo Color Depth is omitted then a logo with the default
colour depth of 256 colours will be retrieved.
10.3 Logo Net Location Examples
If Logo Net Location was set to "FTP://logos.xzpay.com", then:
o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size
256 colour logo
o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16
colour logo
Note: Organisations which make logos available for use with IOTP
should always make available "small" and "medium" size logos and use
the "gif" format.
11. Brands
This section contains:
o a definition of Brands and an outline of Brand Selection using
Brand Lists, and
o some XML examples of Brand Lists
11.1 Brand Definitions and Brand Selection
One of the key features of IOTP is the ability for a merchant to
offer a list of Brands from which a consumer may make a selection.
This section provides an overview of what is involved and provides
guidance on how selection of a brand and associated payment
instrument can be carried out by a Consumer. It covers:
o definitions of Payment Instruments and Brands - what are Payment
Instruments and Brands in an IOTP context. Further categorises
Brands as optionally a "Dual Brand" or a "Promotional Brand",
o identification and selection of Promotional Brands - Promotional
Brands offer a Consumer some additional benefit, for example
loyalty points or a discount. This means that both Consumers and
Merchant must be able to correctly identify that a valid
Promotional Brand is being used.
Also see the following sections:
o Brand List Component (section 7.7) which contains definitions of
the XML elements which contain the list of Brands offered by a
Merchant to a Consumer, and
o Brand Selection Component (section 7.8) for details of how a
Consumer records the Brand, currency, amount and payment protocol
that was selected.
11.1.1 Definition of Payment Instrument
A Payment Instrument is the means by which a Consumer pays for goods
or services offered by a Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash payment instrument such as a
Mondex Card, a GeldKarte card or a Visa Cash card
o a software based electronic payment account such as a CyberCash or
DigiCash account.
Most Payment Instruments have a number, typically an account number,
by which the Payment Instrument can be identified.
11.1.2 Definition of Brand
A Brand is the mark which identifies a particular type of Payment
Instrument. A list of Brands are the payment options which are
presented by the Merchant to the Consumer and from which the Consumer
makes a selection. Each Brand may have a different Payment Handler.
Examples of Brands include:
o payment association and proprietary Brands, for example
MasterCard, Visa, American Express, Diners Club, Mondex,
GeldKarte, CyberCash, etc.
o promotional brands (see below). These include:
- store brands, where the Payment Instrument is issued to a
Consumer by a particular Merchant, for example Walmart, Sears,
or Marks and Spencer (UK)
- cobrands, for example American Advantage Visa, where an
Organisation uses their own brand in conjunction with,
typically, a payment association Brand.
11.1.3 Definition of Dual Brand
A Dual Brand means that a single payment instrument may be used as if
it were two separate Brands. For example there could be a single
Japanese "UC" MasterCard which can be used as either a UC card or a
regular MasterCard. The UC card Brand and the MasterCard Brand could
each have their own separate Payment Handlers. This means that:
o the merchant treats, for example "UC" and "MasterCard" as two
separate Brands when offering a list of Brands to the Consumer,
o the consumer chooses a Brand, for example either "UC" or
"MasterCard,
o the consumer IOTP aware application determines which Payment
Instrument(s) match the chosen Brand, and selects, perhaps with
user assistance, the correct Payment Instrument to use.
Note: Dual Brands need no special treatment by the Merchant and
therefore no explicit reference is made to Dual Brands in the DTD.
This is because, as far as the Merchant is concerned, each Brand in a
Dual Brand is treated as a separate Brand. It is at the Consumer,
that the matching of a Brand to a Dual Brand Payment Instrument needs
to be done.
11.1.4 Definition of Promotional Brand
A Promotional Brand means that, if the Consumer pays with that Brand,
then the Consumer will receive some additional benefit which can be
received in two ways:
o at the time of purchase. For example if a Consumer pays with a
"Walmart MasterCard" at a Walmart web site, then a 5% discount
might apply, which means the consumer actually pays less,
o from their Payment Instrument (card) issuer when the payment
appears on their statement. For example loyalty points in a
frequent flyer scheme could be awarded based on the total payments
made with the Payment Instrument since the last statement was
issued.
Note that:
o the first example (obtaining the benefit at the time of purchase),
requires that:
- the Consumer is informed of the benefits which arise if that
Brand is selected
- if the Brand is selected, the Merchant changes the relevant
IOTP Components in the Offer Response to reflect the correct
amount to be paid
o the second (obtaining a benefit through the Payment Instrument
issuer) does not require that the Offer Response is changed
o each Promotional Brand should be identified as a separate Brand in
the list of Brands offered by the Merchant. For example:
"Walmart", "Sears", "Marks and Spencer" and "American Advantage
Visa", would each be a separate Brand.
11.1.5 Identifying Promotional Brands
There are two problems which need to handled in identifying
Promotional Brands:
o how does the Merchant or their Payment Handler positively identify
the promotional brand being used at the time of purchase
o how does the Consumer reliably identify the correct promotional
brand from the Brand List presented by the Merchant
The following is a description of how this could be achieved.
Note: Please note that the approach described here is a model
approach that solves the problem. Other equivalent methods may be
used.
11.1.5.1 Merchant/Payment Handler Identification of Promotional Brands
Correct identification that the Consumer is paying using a
Promotional Brand is important since a Consumer might fraudulently
claim to have a Promotional Brand that offers a reduced payment
amount when in reality they do not.
Two approaches seem possible:
o use some feature of the Payment Instrument or the payment method
to positively identify the Brand being used. For example, the SET
certificate for the Brand could be used, if one is available, or
o use the Payment Instrument (card) number to look up information
about the Payment Instrument on a Payment Instrument issuer
database to determine if the Payment Instrument is a promotional
brand.
Note that:
o the first assumes that SET is available.
o the second is only possible if the Merchant, or alternatively the
Payment Handler, has access to card issuer information.
IOTP does not provide the Merchant with Payment Instrument
information (e.g., a card or account number). This is only sent as
part of the encapsulated payment protocol to a Payment Handler. This
means that:
o the Merchant would have to assume that the Payment Instrument
selected was a valid Promotional Brand, or
o the Payment Handler would have to check that the Payment
Instrument was for the valid Promotional Brand and fail the
payment if it was not.
A Payment Handler checking that a brand is a valid Promotional Brand
is most likely if the Payment Handler is also the Card Issuer.
11.1.5.2 Consumer Selection of Promotional Brands
Two ways by which a Consumer can correctly select a Promotional Brand
are:
o the Consumer visually matching a logo for the Promotional Brand
which has been provided to the Consumer by the Merchant,
o the Consumer's IOTP aware application matching a code for the
Promotional Brand which the application has registered against a
similar code contained in the list of Brands offered by the
Merchant.
In the latter case, the code contained in the Consumer wallet must
match exactly the code in the list offered by the Merchant otherwise
no match will be found. Ways in which the Consumer's IOTP Aware
Application could obtain such a code include:
o the Consumer types the code in directly. This is error prone and
not user friendly, also the consumer needs to be provided with the
code. This approach is not recommended,
o using one of the Brand Identifiers defined by IOTP and pre-loaded
into the Consumers IOTP Aware application or wallet by the
developer of the Wallet,
o using some information contained in the software or other data
associated with the Payment Instrument. This could be:
- a SET certificate for Brands which use this payment method
- a code provided by the payment software which handles the
particular payment method, this could apply to, for example,
GeldKarte, Mondex, CyberCash and DigiCash,
o the consumer making an initial "manual" link between a Promotional
Brand in the list of Brands offered by the Merchant and an
individual Payment Instrument, the first time the promotional
brand is used. The IOTP Aware application would then "remember"
the code for the Promotional Brand for use in future purchases.
11.1.5.3 Consumer Software Brand Id recommendation
New Brand Ids are allocated under IANA procedures (see section 12
IANA Considerations). Which also contains an initial list of Brand
Identifiers.
It is recommended that implementers of consumer IOTP aware
applications (e.g., software wallets) pre-load their software with
the then current set of Brand Ids and provide a method by which they
can be updated. For example, by going to the software developer's web
site.
11.2 Brand List Examples
This example contains three examples of the XML for a Brand List
Component. It covers:
o a simple credit card based example
o a credit card based brand list including promotional credit card
brands, and
o a complex electronic cash based brand list
Note that:
o brand lists can be as complex or as simple as required
o all example techniques described in this appendix can be included
in one brand list.
11.2.1 Simple Credit Card Based Example
This is a simple example involving:
o only major credit card payment brands
o a single price in a single currency
o a single Payment Handler, and
o a single payment protocol
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30'
BrandId='MasterCard'
BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31'
BrandId='Visa'
BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32'
BrandId='AmericanExpress'
BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com'
ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34'
Amount='10.95'
CurrCode='USD'/>
<PayProtocol ID ='M1.35'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>
11.2.2 Credit Card Brand List Including Promotional Brands
An example of a Credit Card based Brand List follows. It includes:
o two ordinary card association brands and two promotional credit
card brands. The promotional brands consist of one loyalty based
(British Airways MasterCard) which offers additional loyalty
points and one store based (Walmart) which offers a discount on
purchases over a certain amount
o two payment protocols:
- SET (Secure Electronic Transactions) see [SET], and
- SCCD (Secure Channel Credit Debit) see [SCCD].
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase ladies coat'
PayDirection='Debit' >
<Brand ID ='M1.3'
BrandId='MasterCard'
BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com'
ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4'
BrandId='Visa'
BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com'
ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5'
BrandId='BritishAirwaysMC'
BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6'
BrandId='Walmart'
BrandName='Walmart Store Card'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7'
PayProtocolRef='M1.10'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8'
PayProtocolRef='M1.11'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9'
Amount='157.53'
CurrCode='USD'/>
<PayProtocol ID ='M1.10'
ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>
11.2.3 Brand Selection Example
In order to pay by 'British Airways' MasterCard using the example
above using SET and therefore getting double air miles, the Brand
Selection would be:
<BrandSelection ID='C1.2'
BrandListRef='M1.3'
BrandRef='M1.5'
ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
11.2.4 Complex Electronic Cash Based Brand List
The following is an fairly complex example which includes:
o payments using either Mondex, GeldKarte, CyberCash or DigiCash
o in currencies including US dollars, British Pounds, Italian Lira,
German Marks and Canadian Dollars
o a discount on the price if the payment is made in Mondex using
British pounds or US dollars, and
o more than one Payment Handler is used for payments involving
Mondex or CyberCash
o support for more than one version of a CyberCash CyberCoin payment
protocol.
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Company report on XYZ Co'
PayDirection='Debit' >
<Brand ID ='M1.13'
BrandId='Mondex'
BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com'
ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14'
BrandId='GeldKarte'
BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de'
ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15'
BrandId='CyberCoin'
BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com'
ProtocolAmountRefs ='M1.20' >
</Brand >
<Brand ID ='M1.16'
BrandId='DigiCash'
BrandName='DigiCash Electronic Cash'
BrandLogoNetLocn='http://otplogos.digicash.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.22'>
</Brand>
<ProtocolAmount ID ='M1.17'
PayProtocolRef='M1.31'
CurrencyAmountRefs='M1.25 M1.29'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.18'
PayProtocolRef='M1.32'
CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.19'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.28'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.20'
PayProtocolRef='M1.34 M1.33'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<ProtocolAmount ID ='M1.21'
PayProtocolRef='M1.36'
CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.23'
Amount='20.00'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.24'
Amount='12.00'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.25'
Amount='19.50'
CurrCode='USD'/>
<CurrencyAmount ID ='M1.26'
Amount='11.75'
CurrCode='GBP'/>
<CurrencyAmount ID ='M1.27'
Amount='36.00'
CurrCode='DEM'/>