Subject: Error Handling

From: Masaaki Hiroya <[email-masked]>
Date: Sun, 23 May 1999 16:59:38 +0900

David and Werner

I have some questions about error handling.

[Question 1]
The business error handling described in IOTP Payment API Supplement v1.0.1a
is inconsistent with the one described in IOTP specification v1.0-03.

In 4.3.3.3 Block Business Errors in the IOTP specification, there is a 
description as follows:
"If a business error occurs in a process such as a Payment or a
 Delivery, then the appropriate type of response block is returned. The
 Status Component (see section 6.14) within that response block
 indicates the error and its severity. No Error Component or Error Block
 is generated for business errors."

In 8.5.2 Intermediate Failures in the Payment API Supplement, there is a
description as follows:
"Transient Error: Failures, that might be resolved by the retransmission of 
the appropriate IOTP message, belong to this class. 
......
The behavior of the IOTP Application Core and IOTP Payment Bridge does not
depend on any further classification of this failure (technical/business)."

In Fig.31 in 8.5.2, an business error with severity "TransientError" is 
notified from the Payment Handler to the Consumer by using an Error message.

Which should be used, ErrorBlk and Error Component or PayRespBlk and Status
Component in the case of business errors with "TransientError" severity?
 
If the Status Component should be used in any business error, it is necessary
to add a "Severity" attribute to the Status Component, since there is no 
"Severity" attribute in the Status Component defined in 6.14 of the IOTP 
specification.

[Question 2]
This is a confirmation rather than a question.
After the Consumer receives the PayResp message with Severity "Transient
Error", the Consumer sends the retrying PayExch message in order to continue
the transaction, doesn't it?
I think the answer is "yes" since there is the Server Role description 
in 4.4.1.9 of the IOTP specification as follows:
  "Transient Errors" are not stored so that if the original Response
  Block is received again, then it can be processed as if it had never
  been received before.
(In the above sentence, I think that "the original Response Block" should 
 be "the original Request Block" because the Server Role receives request
 blocks.)

[Question 3]
Additional Confirmation.  It is allowed to set different values from the
original request message to the retrying request message in the case of
business errors with "TransientError" severity, isn't it?
I think the answer should be "yes" since in the case of "Insufficient Fund"
the Consumer may replace the e-cash card and then retry the transaction
so PaySchemeData in the original may be different from the one in the
retrying message.

The reason why I am confused is there is a description in 4.4.2.8 of
IOTP specification as follows:
  "Transient errors may be used to provide a manual or automatic
  resending (step 8b) of a block previously stored or alternatively may
  result in transaction cancellation."

[Question 4]
Some errors are not easy to classify as technical errors or business errors.
If the payment server such as the SET Merchant connected to IOTP Payment
Handler server through its payment bridge has an internel processing error,
is it a technical error or a business error with an completion code of
"BadInstrument"?  If the SET Merchant server doesn't respond to the request
from the payment bridge of the Payment Handler, is it a technical error or
a business error with "BadInstrument" completion code?

[Question 5]
Accoring to the IOTP specification, PayReceipt Component is mandatory in 
PayRespBlk and it is required to use PayRespBlk in the case of business 
errors, 
But I think most payment schemes doesn't generate payment receipts when errors
occur.  Taking it into consideration, the PayReceipt should be optional in the 
PayRespBlk.  What do you think about it?

Regards
Masaaki
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
tel: +81-44-959-0874
fax: +81-44-959-0856
email: [email-masked]
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: David Burdett <[email-masked]>
Date: Tue, 25 May 1999 22:05:32 +0100

Most of Masaaki's questions are to do with "Transient Errors" and how to
handle them. I think that Transient Errors can be caused by either business
or technical reasons. For example:
*	if a server that is handling a payment (e.g. a SET server, or a SCCD
server) is busy, even if the IOTP server is not, then the valid response
might be to tell the consumer to retry re-send exactly the same message some
time later. This is a transient technical error.
*	on the other hand if the payment instrument is not usable, for
example there are insufficient funds on a credit card, then the consumer
needs to select a different payment instrument. This is a transient business
error since the transaction can continue with a different payment
instrument.

This is consistent with the current defintions of the two types of error.
*	"technical errors" which are independent of the meaning of the IOTP
Message, and
*	"business errors" which indicate that there is a problem specific to
the process (e.g. payment or delivery) which is being carried out

Therefore I think that these two types of "transient" error need handling
differently with:
*	"transient technical errors" being handled by sending an Error
Component to the the other Trading Role which results in the re-transmission
of the original message at some slightly later point in time, and 
*	"transient business errors" where a "response" message is sent which
allows the other role, e.g. a Consumer, to retry with, for example, another
payment instrument

Below are detailed changes to the IOTP spec, and responses to Masaaki's
individual questions.

David

CHANGES TO THE SPEC

NEW SECTION - TRANSIENT TECHNICAL ERRORS
Add a new section on "Transient Technical Errors" after the section 4.3.3.2
on "Block and Component Consistency Checks" that says:

"If the block passes the "Block Level Attribute and Element Checks" and the
"Block and Component Consistency Checks" then it is processed either by the
IOTP Aware application or perhaps by some "back-end" system such as a
payment server. During this processing some temporary failure may occur that
can potentially be recovered by the other trading role re-transmitting, at
some slightly later time, the original message that they sent. 

In this case the other role is informed of the Transient Error by sending
them an Error Component (see section 6.19) with the Severity Attribute set
to TransientError and the MinRetrySecs attribute set to some value suitable
for the Transport Mechanism being used (see appropriate Transport
Supplement).

Note that transient technical errors can be sent by any of the Trading Roles
involved in transaction."

UPDATED SECTION - BLOCK BUSINESS ERRORS
Clarify the section on Block Business Errors (section 4.3.3.3) to read ...

"If a business error occurs in a process such as a Payment or a Delivery,
then the appropriate type of response block is returned containing a Status
Component (see section 6.14) with the ProcessState attribute set to Failed
and the CompletionCode indicating the nature of the problem.

Some business errors may be "transient" in that the Consumer role may be
able to recover and complete the transaction in some other way. For example
if the Credit Card that a consumer provided had insufficient funds for a
purchase, then the Consumer may recover by using a different credit card.

Recovery from "transient" business errors is dependent on the
CompletionCode. See the definition of the Status Component for what is
possible.

Note that no Error Component or Error Block is generated for business
errors."

REVISED COMPLETION CODES FOR STATUS COMPONENT
Change the defintion of the CompletionCode attribute in the Status component
to read ...

	"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."

Update sections 6.14.1 to 6.14.4 to indicate where recovery from transient
business errors are possible, as follows:

6.14.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	

6.14.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.	

If the Payment is Brand Independent, then recovery may be possible for some
values of the Completion Code, by the Consumer selecting a different payment
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 not
possible, since the Offer is dependent on a the entries selected from the
Brand List. A changed selection will invalidate the Offer Response.

6.14.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. 	
*	"Confirmed"	Confirmed. All goods have been delivered and
confirmation of their delivery has been received. This is only valid if
ProcessState is CompletedOk. 	
*	"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.	

	[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.
	[Note End]	 

6.14.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.	
*	"NoAuthData"	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 Authentication
Request Component are inconsistent with the Trading Role which the
Authenticatee is taking in the IOTP Transaction or is able to take. Examples
of inconsistencies include: asking a PaymentHandler for DeliveryHandler
information 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.	

Comments on questions below ...
> ----------
> From: 	Masaaki Hiroya[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	23 May 1999 00:59
> To: 	[email-masked]
> Subject: 	Error Handling
> 
> David and Werner
> 
## Should be answered by earlier comments ##

> ## Also answered by earlier comments and correct 4.4.1.9 to read ...
"If any of the previous steps resulted in an error being detected and an
Error Component being created then generate an Error Block (step 9)
containing the Error Components that describe the error(s).

Unless the error is a "Transient Error", the Error Component(s) and the
previous Request or Exchange block that caused the Error Components to be
generated should be stored so that it can be reused if the action request is
received again (step 6a).

"Transient Errors" are not stored so that if the original Request or
Exchange Block is received again, then it can be processed as if it had
never been received before."
>  ##
## Answered by earlier comments ##

> a business error with "BadInstrument" completion code?
## Answered by earlier comments ##

> PayRespBlk.  What do you think about it?
## I agree, Pay Receipt Component is only required if the Status component
is "Completed OK".

The DTD is changed from ...

<!ELEMENT PayRespBlk (Status, PayReceipt, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >

... to ...

<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
     PaymentNote?, TradingRoleData*) >

... and the description of the PayReceipt in the Pay Response Block is
changed to ...

	"Contains payment scheme specific data which can be used to verify
the payment occurred. See section 7.10 Payment Receipt Component. It must be
present if the ProcessState attribute of the Status Component is set to
CompletedOk. PayReceipt is optional for other values as specified by the
appropriate Payment Scheme supplement."

> email: [email-masked]

**********************************************************************************************

This Email and any attached files are confidential and may also be privileged. 
If you are not the intended recipient, please notify the postmaster using email 
address [email-masked] or call +44 171 557 5000 and ask for the 
IT Helpdesk.  You should not copy this email and any attached files, use them 
for any purpose or disclose the contents to any other person; all copies of the 
Email and associated files in your possession should be destroyed.

Mondex International Limited
47-53 Cannon Street
London EC4M 5SQ
United Kingdom
Registered No: 3122085, England

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200
Email:          [email-masked]
WebSite:        http://www.mondexinternational.com

*********************************************************************************************

---

From: David Burdett <[email-masked]>
Date: Wed, 26 May 1999 20:43:37 +0100

In my last email on Error Handling it said in the description of Payment
Completion codes that:

> If the Payment is Brand Independent, then recovery may be possible for
> some values of the Completion Code, by the Consumer selecting a different
> payment 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
not possible, since the Offer is dependent on a the entries selected from
the Brand List. A changed selection will invalidate the Offer Response.

This is not quite correct. It should have said ...

> 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
	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.

> ----------
> From: 	David Burdett[SMTP:[email-masked]]
> Sent: 	25 May 1999 14:05
> To: 	Ietf Trade WG; [email-masked]
> Subject: 	RE: Error Handling
> 
> > occur.  Taking it into consideration, the PayReceipt should be optional
> in
> > the 

Phone:          +44 171 557 5000
Fax:            +44 171 557 5200