Appendix 7 - Merchant Enrollment in E*MERGEŽ
The way that the E*MERGEŽ payment method is defined suggests
that the most efficient way to operate the E*MERGEŽ is to allow the operators
of the E*MERGEŽ MP Server to establish binary relationships with merchants.
Therefore, the model assumes that accredited operators of the E*MERGEŽ Payment
Servers will establish relationships with the merchant's banks working as an
agent of that particular merchant.
Merchant Enrolment Flowchart
A) Register with an E*MERGEŽ MP Server
The first step in the establishment of a
seller as 3DASä E*MERGEŽ capable is for the operator of the E*MERGEŽ MP
Server to contact the seller and convince them of the value of the E*MERGEŽ
service. Two items make this
proposition most attractive to a seller.
First, E*MERGEŽ authenticated transactions are card present
transactions. Second, the only risk
to an honest seller is that they do not meet their own terms; the terms
they propose and agree with their customers.
Buyers claiming that they did not purchase those goods will have to
prove that the card was not in their possession at the time of the transaction.
Once the seller has agreed to join the
E*MERGEŽ system, the operator will request from the seller a list of payment
options that they would like to employ.
The list the seller can select from will be restricted to those methods
that the E*MERGEŽ system has operational.
If these are all payment methods the seller
currently employs, each will be associated with a particular banking
relationship and have a set of technical characteristics and seller
parameters. These must be inventoried,
and as appropriate, replicated on the EFTPOS side of the E*MERGEŽ MP
Server. As an agent of the seller, the
operator will contact the appropriate banks and proceed accordingly (see Error!
Reference source not found.).
E*MERGEŽ Merchant Profile
|
Description |
Source |
Size |
|
|
Seller Pseudonym |
Randomly generated and changed on a random cycle |
MP server |
12 bytes |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
MP server |
12 bytes |
|
3DAS Card Key |
Data Table of 3DAS Marker |
Operator |
80 bytes |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
MP server |
12 bytes |
|
3DAS Card Key |
Data Table of 3DAS Marker |
Operator |
80 bytes |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
|
|
|
3DAS Card Key |
As many as maybe required to meet merchant Volume |
|
|
|
Payment Method Type |
E*MERGEŽ wide standard used to define if the method is MasterCard, Visa, Check, Micro-payment |
Merchant |
4 Bytes |
|
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
MP server |
12 bytes |
|
EFTPOS Interface |
Internal pointer to the appropriate EFTPOS Interface |
Acquirer and operator |
As necessary |
|
Payment Details |
Static Information required to complete EFTPOS Message |
Acquiring Bank |
Variable - based on Acquiring Bank EFTPOS specifications |
|
Payment Method Type |
E*MERGEŽ wide standard used to define if the method is MasterCard, Visa, Check, Micro-payment |
Merchant |
4 Bytes |
|
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
MP server |
12 bytes |
|
EFTPOS Interface |
Internal pointer to the appropriate EFTPOS Interface |
Acquirer and operator |
As necessary |
|
Payment Details |
Static Information required to complete EFTPOS Message |
Acquiring Bank |
Variable - based on Acquiring Bank EFTPOS specifications |
|
Payment Method |
As many as required |
|
|
B)
Set up and Maintain Merchant Payment Details
Based on the interfaces and procedures that were agreed
between the Acquiring Banks and the E*MERGEŽ MP Server operator, the necessary
details will be defined and input into the E*MERGEŽ Merchant Profile.
Within this record the operator will define the payment
methods that this seller will be allowed to accept as a means of payment
utilizing the E*MERGEŽ mechanism. Based
on the capabilities of E*MERGEŽ and its associated secure characteristics, the
seller can achieve similar terms to those now associated with card present
transactions, now also over the Internet.
In defining the content of the data element "payment
details" of this record, the static information described in the
underlining specification of the EFTPOS interface will be employed. This static information will allow the
E*MERGEŽ MP Server to complete the requisite EFTPOS message as agreed by the
associated Acquiring Bank.
At regular intervals and as agreed between the Acquiring
Banks and the operator there is data held in these records that might need to
be updated. Simultaneously, the seller
may elect to add new payment methods to the list or change its Acquiring Bank.
C) Implement E*MERGEŽ Merchant OLTP Server
After the seller has agreed to join the E*MERGEŽ system the
seller must organize to upgrade its existing Internet on line transaction
processing system to employ E*MERGEŽ as its preferred mechanism for effecting
payments over the Internet.
It is assumed that several software suppliers will develop
standard software capable of supporting the E*MERGEŽ solution and that the
seller will simply select the version that best meets the needs of their
particular environment and requirements.
The software will require integration at three points in the
seller's environment.
During the shopping
experience when the sellers system believes that the buyer is going to
purchase something the E*MERGEŽ Merchant OLTP control software pings the
buyers PC to ascertain if an E*MERGEŽ Browser Plug-in exists. The E*MERGEŽ Browser Plug-in can display to
the buyer that the seller uses E*MERGEŽ.
Assuming a positive acknowledgement, the next step in the E*MERGEŽ
process would take place or the seller would default to another less protected
payment mechanism.
At the stage that the buyer
has agreed to purchase goods and after the seller prepares the final invoice
the E*MERGEŽ Merchant OLTP control program takes control. It prepares the Error! Reference source
not found., and sends it to the buyer, it then waits
message Error! Reference source not found.
from the buyer and finally receives message Error! Reference source
not found. confirming the banks approval.
The final module goes
into the seller's goods delivery infrastructure. In the case of soft goods delivered via the Internet, this module
acts immediately following positive acknowledgement to the request for payment
authorization. In the case of physical
goods, this module acts immediately after the seller has delivered the
goods. The purpose of this module is to
format the request for payment on delivery and handle the submission of these
records to the E*MERGEŽ MP Server.
Links from this module to existing exception processing modules and cash
management systems would also be introduced to assure reconciliation and
appropriate error handling procedures.
D) Purchase 3DASä Reader
One of the key functions of this control software is the
management of the E*MERGEŽ Merchant OLTP Merchant Profile and the generation of
the requisite 3DAS Signatures that are used to assure transaction integrity
and merchant authenticity.
The next step in the merchant implementation process is to
acquire the appropriate number of 3DASä Readers and install them
within the merchant's Internet environment.
These readers will come with a set of software drivers and software that
must be inserted into the environment being built to integrate E*MERGEŽ into
the merchants eCommerce set-up.
The 3DASä Readers that will be employed on the seller side of the
E*MERGEŽ system can be identical to those employed on the buyer side. For larger sellers where volumes of
purchases require several 3DASä Readers to sign the seller invoice it is anticipated
that a rack mounted version of the reader will be required. This rack-mounted version will probably
include a server responsible for handling communications with the 3DASä
Readers and performing certain functions of the E*MERGEŽ process, as are
efficient.
E) Issue 3DAS Cards
When the E*MERGEŽ MP Server operator is comfortable that the
seller is ready to go into operation, a number of 3DAS Cards must be
registered in the E*MERGEŽ Merchant Profile and delivered to the seller. The number of cards that will be required is
a function of the peak volume of purchasing activity that can be expected to
occur on a seller site and the delays that the seller considers acceptable in
the creation and delivery of the invoice to a buyer.
At the time that the card is produced and personalized a
read of the 3DAS Marker must take place.
The data table created during the personalization process is the 3DASä Key
and in fact will be the result of two or more reads of the marker that are used
to derive the 3DASä
Key. This information is registered in
the E*MERGEŽ Merchant Profile within the database held by the MP server and
created during the step B)
Set up and Maintain Merchant Payment Details on page 5.
F) Register 3DAS Cards
After the 3DAS Keys are loaded onto the MP server a unique
CD[1]
or diskette is prepared for mailing to the seller simultaneous with the cards
being sent.
When the seller receives the 3DASä-enabled Card, and
depending on if a diskette/CD was sent or a URL was printed, the seller will be
instructed to enter some command into the E*MERGEŽ Merchant OLTP Control
Software. This action will activate the
payment profile initialization process of the E*MERGEŽ system.
This process will take place
Every time the seller receives a new
card.
Whenever a new payment method is added
a seller's 3DASä-enabled
Card
Any number of ways exist to facilitate these essential
updates ranging form employing a CD or including as part of any communications
session between the E*MERGEŽ Merchant OLTP Control Software and the E*MERGEŽ MP
Server.
During this initialization process the E*MERGEŽ Merchant
OLTP Control Software will either read from the diskette or attach to the URL
and load the E*MERGEŽ Merchant OLTP Merchant Profile. During this registration process, the seller is to insert the
3DASä
Cards into the readers. The E*MERGEŽ
Merchant OLTP Control Software will ask each 3DASä Reader to read the 3DASä
Marker inserted inside it and generate a 3DASä Signature using the
seller pseudonym, a seller secret[2],
the data and the time. It will then
connect to the E*MERGEŽ MP Server and request authentication of each of the
seller's cards. The MP server will
locate the seller profile, perform card authentication and respond accordingly.
The Public Key of the MP server will also be loaded into the
E*MERGEŽ system so that the E*MERGEŽ Merchant OLTP Control Software can be
confident that it is receiving updates and confirmations of payment and buyer
authentication from the legitimate E*MERGEŽ MP Server.
E*MERGEŽ Merchant OLTP Merchant Profile
|
Name |
Description |
Size |
|
Seller Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
|
E*MERGEŽ MP Server Address |
URL of MP server on the secure VPN |
Variable |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
|
Card Pseudonym |
Randomly generated and changed on a random cycle |
12 Bytes |
|
Payment Method Type |
E*MERGEŽ wide standard used to define if the method is MasterCard, Visa, Check, Micro-payment |
4 Bytes |
|
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
|
Payment Method Type |
E*MERGEŽ scheme wide Standard used to define if the method is MasterCard, Visa, Check, Micro-payment |
4 Bytes |
|
Payment Method Pseudonym |
Randomly generated and changed on a random cycle |
12 bytes |
|
Payment Method |
As many as required |
|
G) Activate Merchant on Payment Server
Assuming that the merchant enrolment completed successfully
and the E*MERGEŽ Merchant OLTP Control Software and associated merchant
eCommerce on line transaction processing system OLTP additions passed any tests
that were defined, the E*MERGEŽ MP Server will identify the merchant as
active.
Now that the Merchant has been activated or until the
merchant or its Acquiring Bank state otherwise, the E*MERGEŽ MP Server will:
1.
Accept requests for payment from E*MERGEŽ CP
Servers
2.
Issue appropriate merchant authentication
information to the CP server
3.
Handle the communications with the Acquiring
Bank side of the EFTPOS network on behalf of the merchant
4.
Inform the merchant of the status of each
request for payment authorization
