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; www.issuerID.3DAS.org.
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.
