Subject: RE: Error Handling

From: Masaaki Hiroya <[email-masked]>
Date: Fri, 28 May 1999 02:45:37 +0900

I have additional questions regarding transient business errors.

In 4.4.1.9 of the IOTP specification and your previous mail,
>"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."

The above sentences seem descriptions about how to handle technical errors,
but is the last sentence applicable to the transient business errors? 

If so, do the transient (payment) business errors occur only while the 
server entities process received PayReq messages but not received PayExch 
messages?

In this case, when the server entities receive PayExch messages, PayReq
messages should have been processed normally, so I think that the server
entities reject new PayReq messages including new payment brands and 
protocols selected by the Consumers.

Otherwise, is it allowed to receive new PayReq messages even after 
processing original PayReq messages normally and sending back
PayExch messages to the client? 
If so, the business errors may occur during processing PayExch messages.

In this case, it is necessary to define which message should be send
by the client and be waited for by the server depending on each completion
code when a transient business error occurs.  For example,
if the "insufficient funds" business error occurs, the Consumer client
should send a new PayReq message including a new payment brand and 
protocol in it or a cancel message to the Payment Handler server, and
the Payment Handler server should wait for them. 

I think it is better to add how to handle business errors to Fig.10
and Fig.11 in the IOTP specification, which show Server Role Processing
Sequence and Client Role Processing Sequence respectively.

I would like to make clear the differences between transient technical 
errors and transient business errors in detail regarding the Server
Role bahavior and the Client Role behavior.

Thank you in advance
Masaaki

At 20:43 99/5/26 +0100, David Burdett wrote:
> 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
> > brand. Note that this might involve a different Payment Handler. The codes
> > to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds,
> > InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
> > 
> 	Recovery from Payments associated with Brand Dependent purchases is
> only possible, if the Brand Selection component sent by the Merchant to the
> Consumer does not change. In practice this means that the same Brand,
> Protocol Amount and PayProtocol elements must be used. All that can change
> is the Payment Instrument. Any other change will invalidate the Merchant's
> Offer as a changed selection will invalidate the Offer Response.
> 
> > ----------
> > From: 	David Burdett[SMTP:[email-masked]]
> > Sent: 	25 May 1999 14:05
> > To: 	Ietf Trade WG; [email-masked]
> > Subject: 	RE: Error Handling
> > 
> > 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
> > > 
> > > 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.
> > ## Should be answered by earlier comments ##
> > 
> > > [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.)
> > > ## 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."
> > >  ##
> > > 
> > > [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."
> > ## Answered by earlier comments ##
> > 
> > > [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?
> > ## Answered by earlier comments ##
> > 
> > > [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?
> > ## 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."
> > 
> > 
> > > 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]
> > > 
> > 
> > **************************************************************************
> > ********************
> > 
> > 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
> > 
> > **************************************************************************
> > *******************
> > -----------------------------------------------------------------------
> > 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]
> > 
> 
> ****************************************************************************
> ******************
> 
> 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
> 
> ****************************************************************************
> *****************
> -----------------------------------------------------------------------
> 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]
> 
-----
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: Masaaki Hiroya <[email-masked]>
Date: Mon, 31 May 1999 22:26:13 +0900

I have an addtional comment on the last mail I sent about
transient business error handling. 

Transient business errors may occur during PayExch message processing
after PayReq messages are processed normally: for example,

In SET, AuthReq messages are sent to the SET payment gateway by the SET
merchant server connected to the IOTP Payment Handler server after 
the Payment Handler receives PReq messages included in PayExch 
messages from the Consumer.

If an AuthRes message with AuthCode=Declined is returned as a response
from the SET payment gateway, the SET payment bridge may return a 
business error to the IOTP Payment Handler.

Therefore, I think it is necessary to describe which message the IOTP 
client should send to the server and which messages should not stored
by the server, depending on the completion code.

The IOTP client should send the new message defined below or abort
the transaction when business errors occur.

For example,
Offer Exchange
"AuthError": AuthResp message

Payment Exchange
"BrandNotSupp" : PayReq message
"CurrNotSupp" : PayReq message
"AuthError" : PayReq message
"InsuffFunds" : PayReq message
"InstrumentBrandInvalid" : PayReq message
"InstNotValid" : PayReq message
"BadInstrument" : PayReq message

The IOTP servers should not store the following messages and
the new messages can be processed as if they had never been received
before when business transient errors occur.

For example,
Offer Exchange Phase
"AuthError": received AuthResp message

Payment Exchange Phase
"BrandNotSupp" : received PayReq and PayExch messages
"CurrNotSupp" : received PayReq and PayExch messages
"AuthError" : received PayReq and PayExch messages
"InsuffFunds" : received PayReq and PayExch messages
"InstrumentBrandInvalid" : receivedPayReq and PayExch messages
"InstNotValid" : received PayReq and PayExch messages
"BadInstrument" : received PayReq and PayExch messages

Any comments?

If I misunderstand the specifications about transient 
business errors, please let me know.

Massaki

 them 
 of the 
-----
Masaaki Hiroya
tel: +81-44-966-9111(ext.3552)
fax: +81-44-966-1796