Appendix 8 - Exception Processing With E*MERGE®

In all electronic systems exists a possibility that errors will occur and that procedures must exist to assure successful resolution and continued operation.

Key to the E*MERGE® architecture is that it provides a secure interface between the insecure Internet and the secure EFTPOS networks employed to assure the shift and safe execution of payment transactions.  Therefore, exceptions in the EFTPOS environment must be extended into the E*MERGE® environment and appropriate mechanisms to support them must exist.

Operational issues always occur and it is important to recognize that the Internet protocols do not have within them inherent capabilities to support transactional activity.

EFTPOS Exception Processing

The E*MERGE® system offers a mechanism that allows the consumers, merchant and banks involved to prove that the following conditions occurred.

Ø*                A seller sent a signed invoice to the buyer.

Ø*                The buyer agreed to purchase the goods based on the content of the seller's signed invoice at a particular price with a particular payment method.

Ø*                Both the seller and buyer held valid 3DAS™-enabled Cards at the time of the purchase and this card was used to sign the terms and conditions of that transaction.[1]

Ø*                The conditions they claim in respect to the transactions were as recorded by the trusted E*MERGE® Payment Server operators.

Ø*                The Issuing Bank with the support of the CP and MP Server authenticates both, the seller and the buyer and perform an on-line authorization.

Therefore, the only exception that can occur is that the merchant did not fulfill the obligations as set down in the invoice agreed by the two parties. 

If either the buyer or the seller produce the original invoice the counterpart can validate that that was the original invoice sent or received.  If necessary, an arbiter can perform a similar validation if a neutral party is required to intervene to arbitrate the dispute between the two parties. 

In essence, the dispute is outside the payment system.  It is an issue between the seller and buyer. 

Assuming the seller agrees to resolve the dispute in the buyer’s favor then the only action that the E*MERGE® system must be able to handle is the reversal of the transaction.  To achieve this result the MP server issues a credit against the original transaction employing normal payment system procedures.  Acknowledging that the payment servers have kept a log of the original transaction, it can format a credit message by using the reference number of the transaction provided by the buyer or the seller.  The actual means of effecting the transaction can be through an Internet screen using the 3DAS™ mechanism to sign the authorization of a credit or via a human interface employing some other method of authentication.

In the event that the seller does not agree to the buyer's complaint then the buyer has the right to an appeal based on the conditions agreed in the invoice or the terms defined by the banking association responsible for payment method being employed.  What the E*MERGE® system can do is assure the authenticity of the token employed by the seller and buyer at the time of the transaction and can assure all parties that this was a unique and irrefutable transaction.

One other mechanism used to reverse a transaction is a charge-back.  In this case the financial transaction is handled outside of the E*MERGE® environment.  The only reason that the E*MERGE® system would need to be aware is in the event that other value added services are included in the operators offering to either the buyer or the seller.

Other exceptions will relate to the improper maintenance of the seller and buyer profile or situations where a seller or buyer has been removed from the banks' systems before the E*MERGE® Payment Servers has been notified.  In these cases, the EFTPOS system will return an error or exception message in response to the request for authorization. Based on the agreement reached with the involved banks actions will take place within the payment server to status the seller or buyer profiles and inform the involved parties accordingly. Actions that may be taken could extend to attempting to connect to the E*MERGE® Browser Plug-in or E*MERGE® Merchant OLTP Control Software.  Upon connection, the plug-in or control software maybe requested to delete the related payment profile.

Each payment method may have unique requirements on how to handle exceptions.  The design team will deal with each of them during the E*MERGE® detail design of each payment method.  By design the E*MERGE® system interfaces with the EFTPOS on-line, therefore financial risk is always made after due electronic consultation with the seller's and buyer's bank.  This, therefore, reduces the number of actions that could be required by the E*MERGE® system when attempting to react to exceptions issued by the EFTPOS systems.

Operational Issues

Ø*                There will be situations where, for some reason, one or more parties to a transaction disconnects from the Internet. 

Ø*                There will be situations where the EFTPOS system does not respond.

Ø*                There are also situations where failures may occur due to an interruption of software or hardware.

Ø*                There will also be situations where the EFTPOS systems fail and require the E*MERGE® system to reverse the transaction or act according to the specifications defined for those exceptions by the authority responsible for that EFTPOS scheme.

The E*MERGE® system is designed around a series of independent components that are each individually responsible to monitor the progress of the payment transaction. They shall also be responsible to recover from abnormal conditions that may occur.

Each component will maintain a log that allows it to determine what actions it performed and the perceived state of that action.  This is achieved by interrogating its logs and matching the condition recorded against the logic of the 8-step E*MERGE® transaction process.  Through this process, the component will be able to ascertain what the state of every previously executed transaction is. 

Examining a few specific conditions helps to articulate how this recovery mechanism will work.

·*               Loss of connection to the EFTPOS environment.  Each EFTPOS environment includes means of assuring successful delivery of messages and a set of recovery procedures.  As part of the design of these interfaces the operator of the E*MERGE® MP Server will have to make sure that all conditions are met and appropriate.  The E*MERGE® Specification may have to be amended to include new exception messages.  These exception messages will allow the E*MERGE® MP and CP Servers to communicate these exceptions to the seller and buyer.  The working assumption is that if the buyer has sent message Error! Reference source not found. to the payment server or the seller has sent message Error! Reference source not found. then both, the seller and the buyer, are expecting completion and the banks and the payment servers shall pursue within the confines of the EFTPOS specifications to effect completion.

·*               Buyer loses the Internet Connection.  For any number of reasons the connection to the Internet will fail. 

If this was to occur after the seller receives message Error! Reference source not found. and before the E*MERGE® Browser Plug-in sends message Error! Reference source not found., the seller will assume the buyer has agreed to the purchase.  In fact, the banking system has not attempted to approve the payment. 

Two events will occur sometime after losing the buyer’s connection to the Internet.

The merchant server will not receive message Error! Reference source not found. from his MP server.  The seller should not begin delivery of goods and record an exception.

The buyer reconnects to the Internet.  At this stage the E*MERGE® Browser Plug-in becomes active again and notes that message 4 had not been sent.  The E*MERGE® Browser Plug-in could automatically decide to submit message 4.  If some proscribed time limit has not passed or it could notify the buyer and ask the buyer to contact the seller and request status on transaction with reference number

If the connection is lost before the buyer plug-in has sent message Error! Reference source not found. to the seller, the E*MERGE Plug-in closes with an invoice awaiting buyer's agreement.  When buyer reconnects to the Internet, the plug-in restarts and can display the pending invoice restarting at step Error! Reference source not found..  Assuming the buyer confirms positively, the plug-in can attempt to send message 3 to the seller.  If the seller has not timed out the transaction all is well.  Otherwise, the seller’s server will reject the message and the buyer will have to connect to the seller and restart shopping process.

·*               Loss of a message from the E*MERGE® Browser Plug-in to the CP server.  Assume that message Error! Reference source not found. successfully left the buyer's computer but was not received by the E*MERGE® CP Server.  In this case both the seller and the E*MERGE® Browser Plug-in thinks that the payment will be completed.  Two events will occur after this Internet failure.

The E*MERGE® Browser Plug-in is awaiting the receipt of message Error! Reference source not found., which should be received in a period proscribed by the payment method.  After this time limit has expired the plug-in, if the Internet connection is available, can send an exception message to the CP server requesting the status of transaction Ref#.  If the CP server is unaware of the Ref# then an appropriate response is returned and the plug-in can re-send message 4. The merchant server is awaiting receipt of message Error! Reference source not found. from his MP server.  If it is not received in the proscribed time-scale then merchant should stop delivery of goods and record an exception.  Given that plug-in has in-built recovery log the merchant server should hold this commit to purchase as pending for some acceptable period.

In both cases the E*MERGE® scheme will have to define lower and upper time limits for each payment type.

·*               Loss of a message from the Merchant OLTP Server to the E*MERGE® Browser Plug-in.  If the buyer does not receive the invoice from the merchant server the E*MERGE® Browser Plug-in has not started processing the transaction.  In this case, it is up to the buyer to notice that the seller has not responded and re-issue the request to purchase. 

The merchant server will notice that the same buyer has requested a repeat of the send of the invoice and re-send the last transaction with the same Ref# and 3DAS™ Signature.  In the event that the seller’s system has timed out the transaction it may have to prompt the buyer to reconfirm the content of the shopping basket and process the transaction through the 3DAS™ process again. 

The previous transaction that was logged under a unique Ref# will remain pending in the merchant log.  At some point in time the merchant E*MERGE® Merchant OLTP Control Software will note that neither message 3 nor message 7 was received and will void the transaction.

·*               Loss of a message from the buyer plug-in to the merchant server.  If the seller does not receive message 3 but eventually receives message 7[2], an exception has occurred.  If the seller only logs message 3 and does not act then, from the merchant server’s point of view, the only requirement is to make sure that all data elements, normally received in message 3, are included in the merchant server’s log.  If the seller normally acts on message 3 then the seller must cause the actions that occur on receipt of message 3 to take place first, then continue processing as normal.

·*               In the event the buyer’s Internet connect is lost before delivery of soft goods.

If the seller’s download procedure requires that the buyer remained connected to the Internet until the seller receives Error! Reference source not found. and the buyer receives Error! Reference source not found. and the buyer prematurely disconnect, then the seller must assume that the buyer is not going to receive the soft goods.  Therefore, the seller will have to credit the buyer based on the requirement of the payment method employed.

For example, if the payment method employed is a debit card and employs the ISO 8583 1200[3] messages the seller will have to submit a request to credit the buyer’s account.  This will operate in a manner similar to the process employed in the event of a buyer dispute.  The merchant would use the reference number to ask the MP server to reverse the transaction.  The MP server would format an appropriate message as defined by the EFTPOS system. 

If conversely the seller has an e-mail address for the buyer, they can send e-mail to the buyer instructing them on how to download the product, or, the seller could include the file in the download.

If the seller was to employ the E*MERGE® Browser Plug-in soft good download initiation capability, the seller would simply status the matching download receiver to await a request for download from the buyer’s 3DAS™ plug-in.

·*               Loss of messages from the E*MERGE® MP Server to the merchant server.  The establishment of the technical interface between the MP server and the merchant server will be, due to volume considerations, much more robust and may in fact employ other communications channels than the Internet.  At this stage in the design of the E*MERGE® system the assumption is that there will be a transaction type that allows the merchant server to request the status of transactions by submitting the Ref#.  The payment server would then respond by sending a copy of message 7, if previously sent, or a new message 7.

·*               Loss of messages from the merchant server to the E*MERGE® MP Server.  If a request for status message is sent and a response is not received within a proscribed period, the merchant server would simply re-send the request.  In the case of message Error! Reference source not found. the seller will wish assurance that these messages have been received and properly processed.  During the technical design, it will be necessary to define a response message that is sent periodically to the seller confirming receipt of a series of message A(s).

During the technical design, further situations will be identified.  The guiding principle is that one of the E*MERGE® components will identify what should have occurred and either assume failure and await the buyer to restart the shopping experience or attempt to identify which message did not complete and restart the transaction at the stage when it failed.

Given the simplicity of the 3DASä E*MERGE® process, maintaining the state of the transactions is straightforward.  The only known event that will result in the buyer having to intervene is if the E*MERGE® Browser Plug-in is unable to reconnect to the Internet before the seller times out the transaction.  In this case, the buyer still wishes to buy the goods and restart the shopping process or the seller simply does not make a sale and purges the invoice from the system.

Hardware and Software Issues

The other set of operational issues that can create problems is the interruption of any element of the software or hardware associated with the buyers, sellers or payment servers’ configuration.

Consumer Hardware of Software Interruption

As is often the case, situations arise within the hardware or operating system that might damage the E*MERGE® Browser Plug-in, its environment or the E*MERGE® Browser Consumer Profile. 

Obviously, the easiest means of recovering the machine is by using the standard backup and recover procedures.  Unicate accepts that this is not a judicious assumption and that no user backs up their machine frequently enough to totally re-establish a damaged E*MERGE® environment.

The working assumption of E*MERGE® is the KISS principle "Keep It Simply Simple". 

The recover should simply require the consumer to insert the installation CD (received with the 3DAS™ Reader).  The installation CD would determine the extent of the damage and reload those elements.  Assuming it can locate and validate the logs and consumer profiles, the consumer is ready to purchase over the Internet again secure in E*MERGE®.

In the event of damage to the consumer profile or the log, the plug-in simply needs to connect to the appropriate E*MERGE® CP Servers and initiate the log and/or profile recovery mechanism.  Each payment server operator is responsible to maintain logs and operate recovery mechanisms designed to support such a situation.

If the E*MERGE® Browser Plug determines that the log or profile is corrupt it will ask the consumer to insert the first of their 3DAS™-enabled Cards.

In the event that the consumer profile is corrupted there might be just enough information in the PC to identify the address of the E*MERGE® CP Server and the Consumer Pseudonym.

If the E*MERGE® Browser Plug-in is unable to determine the address of the CP server or the Pseudonym, several methods exist to assure successful recovery.

Ø*                It could locate the E*MERGE® Mobility File if a protected memory chip is present.

Ø*                It could ask the consumer to insert the CD the Issuing Bank sent with the card.

Ø*                It could default to prompting the consumer to enter the Issuer Id as found printed on face of the card.  It would then prompt the consumer to enter their ID (e.g. name and sequence number) exactly as printed on the card.  The E*MERGE® Browser Plug-in can now derive the address of the payment server;

Independent of how the address is determined the plug-in formats a recovery message and connect to the E*MERGE™® CP Server to the URL with the extension /recovery and initiates the recovery procedure.  The payment server will prepare the necessary recovery files and instruct the plug-in to continue[4]. 

Identical to the process described in Error! Reference source not found. on page 5 the payment server will authenticate the 3DAS™ enabled card[5].  Once the card and consumer are authenticated the plug-in will download the files required to restore this card’s E*MERGE® Browser Consumer Profile.

If the log file was also corrupted, with the exceptions of those messages not received by the payment server, the CP server will prepare a download of the log allowing the plug-in to complete the rebuild of that card’s environment.  In order to protect consumer privacy the only element that the CP server will not be able to reconstruct is the detailed content of the invoices[6].

The browser will request the consumer to enter the next card and attempt to recover that cards profile and log.

In the event that the failure was to occur during a transaction, after the above outlined re-initialization is complete, the E*MERGE® Browser Plug-in should be able, with the assistance of the E*MERGE® CP Servers, to reconstruct exactly where it was, using the process described in the section Operational Issues on page 5. 

Using the same logic already discussed, the plug-in should be able to successfully complete all transactions that reached the stage where message Error! Reference source not found. had been sent.  If a major failure occurred between the transmission of message 3 and before message 4, then the working assumption must be that the merchant will not receive a confirmation of payment approval and will assume the consumer aborted the transaction.

Merchant OLTP Server Interruption

The situation with the interruption or corruption of the merchant server is much more complex and their loss of E*MERGE® functionality will be the least of the merchant's problems.  It is also assumed that the merchants will be much more prudent in making back-ups of their systems and the architecture of the environment will include RAID databases, operating system restoration procedures and application level recovery.

All transactions that were executed up until the time of interruption are still in process and therefore if delivery is not to happen then the MP server operator will have to identify and effect a reversal of these transactions. 

The operator of the E*MERGE® MP Server, as part of their right to operate will have to demonstrate the ability to successfully handle such merchant failures without causing the consumer any harm or effecting the financial integrity of the consumers, merchants or banks involved.

E*MERGE® Payment Server or Secure VPN Interruption

The design of this trusted environment assumes these systems are 100% reliable and have build in mirroring capabilities and employ robust data base management systems and communications protocols designed to assure 100% reliability and uptime.

Working with these assumptions the only situation that can be foreseen is a complete failure of a payment server or the VPN.  In this event the parties that are associated with the failed component will lose the ability to effect E*MERGE® payments until the system is restored.

The integrity of the E*MERGE® system is the fact that the payment servers can be trusted.  Built into the E*MERGE® specifications will be performance criteria that defines the obligations of the operators and a standard process to assure adherence to the minimum performance and quality standards.

horizontal rule

[1] Obviously, if the card was reported lost or stolen and it had been authorized by the Issuing Bank then another exception has occurred and would be handled the way those same exceptions are handled today.

[2] Within message Error! Reference source not found. are all of the data elements that the merchant will require to assure an irrefutable transaction.

[3] The ISO 8583 1200 series of messages are used to post to the consumer’s account at the time the transaction was approved and do not utilize a further clearing message as is typical in credit card transactions.

[4] If a criminal steals the card, he might fake out the system making it believe that the consumer's PC is damaged.  Therefore, it is prudent for the operator of the consumer payment server to validate that it is the rightful consumer.  How, is left to the discretion of the Issuing Bank and the payment server operators involved?

[5] The one problem Unicate recognizes is that the consumer has misplaced the secret distributed to them with the 3DAS™ enabled Card.  In this event, a customer service representative through an on-line dialogue can request the consumer enters other privileged information

[6] With the exception of situations where the consumer wishes to dispute a transaction their loss would have no effect.  In the event of a dispute the consumer would have to rely on the merchant to provide a valid copy of the invoice.  In any event the consumer will be able to validate that the invoice presented by the merchant was the same one that the consumer originally received and signed with his 3DAS™ Card.