The transaction procedure is as follows: When a customer wants to make a
transaction, she establishes a connection to the merchant by invoking the
client software. This software asks the customer to type the secret p,
and establishes a connection
to the merchant. Then the merchant generates
a transaction identifier t and sends it back to the customer.
This value is a nonce for preventing from replay attacks, and it consists of
transaction time, date, and a serial number. After reading the random number
from the diskette 
, the software calculates 
,
and sends 
to the merchant.
It should be guaranteed that the client program does not send
the customer secret p to the merchant.
The merchant looks up his database with searching key C, and
checks validity of for customer authentication.
If it is valid, the merchant calculates 
,
and sends it to the customer with an acknowledgement.
After accepting the acknowledgement, the customer checks the hash value with
for merchant authentication.
When the customer makes an order, the merchant requests her to pay, and sends
a payment serial number y and payment amount u.
The customer generates a nonce 
, calculates 
,
and confirms payment to the merchant by sending 
.
The merchant asks the bank B to clear the amount, by
sending 
.
If 
is correct, the bank transfers
the money to the merchant with an acknowledgement
including 
.
The value is used by the merchant to generate an acknowledgement
ticket for the customer.
The bank has to store 's that it has received for a pre-defined period
in order to detect replays. In current credit card systems, the merchant must request that
the bank clear transactions within a specified period from the transaction date -
such as 21 days in UEPS/VISA COPAC [And92] -
otherwise payment will not be made.
The storage of does not require much resource.
After receiving the acknowledgement from the bank, the merchant
calculates 
and sends this value as an
acknowledgement to the customer.
The customer checks this value, which can be used as a proof of the purchase order
and of a proof of payment in case of dispute.
We may consider a false merchant who wants to cause problems for
the real merchant by taking orders and not delivering.
Since contains 
,
he cannot gain monetarily.
Furthermore, he has to send
containing 
back to the customer,
so that the customer can check the eligibility of the merchant.
Such a false merchant cannot step into the transaction.
