The essence of the design involves the development of a set
of interconnected Payment Servers that securely manage consumer and merchant
trust and the payment details necessary to interface with the existing bank
card payment networks i.e. EFTPOS networks.
Built into this secure environment are all the firewalls and
appropriate interfaces necessary to securely interface the Internet with the
card accepting side of appropriate EFTPOS networks. Inherent in the design is the isolation of where confidential
merchant and consumer data resides.
This thus established the trust and security that is fundamental to the
relationships the banks have had and desire to retain between their end users -
the consumers and merchants.
The design assumption is that a trusted party would operate
these secure Payment Servers. Either
this trusted third party operated on behalf of a group of banks or the Issuing
and Acquiring Banks may own and operate these trusted Payment Servers.
In order to assure the level of authenticity demanded by the
consumers, merchants and banks the following hardware and software is required.
Ř
A 3DASä
Payment Card
Ř An inexpensive
Plug & Play 3DASä
Reader with a secure PIN pad
Ř A CD with E*MERGEŽ
Browser Plug-in and a set of device
drivers
The installation is simple plug the 3DASä Reader in and let the Plug & Play
routine request the insertion of the install CD. The rest is automatic.
The E*MERGEŽ Browser Plug-in
is loaded and communication to the 3DASä Reader and Internet is tested.
When the buyer receives the 3DAS Card and starts the new
card program, the E*MERGEŽ Browser Plug-in
will automatically connect to the Payment Server of the card Issuer and the
consumer's payment profile is loaded.
The buyer is ready to start
shopping, secured by E*MERGEŽ.
In order to avail themselves of the security afforded by the
E*MERGEŽ service the seller will need to integrate into their Web hosting
environment.
A number of 3DASä Readers[1].
The software required
that drives the 3DASä
Readers.
The E*MERGEŽ Merchant
OLTP Control Software.[2]
A set of documents
defining the 3DASä
and E*MERGEŽ APIs
A guide to assuring
interoperability both with
The consumer E*MERGEŽ
Browser Plug-in
The Payment Server
interfacing to the EFTPOS networks on the sellers behalf
A 3DAS Merchant card for each 3DASä Reader
Once these have been integrated into the seller web server
environment, the seller has performed the interoperability test, the payment methods
the sellers will accept have been set-up and the seller has activated the 3DASä Cards through the one time registration
process, the seller is live and ready to trade secure in E*MERGEŽ.
The
payment server is the trusted party that offers a range of services to its
users - the Issuing Banks, Acquiring Banks, consumers and merchants. Inherent in the E*MERGEŽ design is the user
profile. It is the responsibility of
the operator of the payment server to securely manage the user profile that
contains the confidential details necessary to prepare valid instructions based
on the prevailing EFTPOS interface specifications.
The payment server will interface to the existing EFTPOS
networks used to execute electronic payments for the assortment of payment
methods that the buyers, sellers and banks will wish to employ over the
Internet. The specifications and many
cases off the shelf software modules for the appropriate electronic interchange
protocols already exist and
simply have to be integrated into the payment servers. An example is the UK
Implementation of the MasterCard and Visa ISO 8583 specification defined by
APACS.
For purposes of simplicity and acknowledging
that, there must be a competitive environment for the provision of this trusted
service, also acknowledging that the Issuers and Acquires may wish to perform
the function of the payment server, E*MERGEŽ segments the payment server's into
two components:
Ř The
first component is associated with the trust relationship between the banks and
the buyers, consumers or cardholders.
Ř The
second component is associated with the trust relationship between the banks
and the sellers or "merchants".
Any number of trusted parties can exist and
it is business and technically possible for a party to operate both
functions.
To
interconnect the trusted merchant and consumer payment
servers a secure "VPN" Virtual Private Network
exists to assure the confidentiality of data transmitted between the trusted payment servers.
In the
specification of the Secure E*MERGEŽ VPN, a set of transactions are defined. This network allows the
independent seller or buyer payment servers to communicate with the payment server associated with the counter-party to the
purchase-taking place over the Internet.
These messages define how either party will communicate in order to
complete the transaction and to assure the authenticity of the buyer, the
seller and the transaction.
Ř Each registered user -
seller or buyer - has a random pseudonym assigned, which identifies the user on
the Internet
Ř Each payment method the
buyer is willing to use has a random pseudonym assigned which identifies the
payment method over the Internet.
Ř Each payment method the
seller is willing to use has a random pseudonym assigned which identifies the
payment method over the Internet.
Ř The 3DASä Key
is secure inside the payment server database along with the confidential
information necessary to populate the EFTPOS message formats.
Four E*MERGE Profiles exist.
Two matching consumer payment
profiles one on the payment server the other in the E*MERGE Browser Plug-in.
Two matching merchant payment
profiles one on the payment server the other in the E*MERGEŽ Merchant OLTP
Control Software.
The CP server is
responsible for assuring the seller that the buyer can be trusted (see 5) Validate Seller and
Buyer) and that the Issuing Bank can process a
legitimate payment transaction.
The operator of
the CP server will build relationships with the Issuers. They will develop and operate a mechanism to
make sure that the information necessary to insert the buyers details into the
payment instructions is accurate and up to date. It will provide appropriate
support to the customer service center that will be in contact with buyer
during the installation and registration process.
During the
transaction process it will assure buyer authenticity, provide the necessary
payment details, monitor the progress of the payment authorization and provide
feedback to the buyer through the E*MERGEŽ
Browser Plug-in.
The payment server maintains electronic logs
that prove that documents buyers action.
In the event of a dispute the Issuer is assured that the customer was
present, that a valid copy of the invoice was provided, that the seller was
authentic and that the buyers card was present at the time of the
transaction. To perform this function
the bank simply asks the buyer to provide the invoice as originally
received and compares this to the sellers signature of the
invoice generated at the time of the transaction and approved with a
signature by the buyer's card.
Assuming the seller has fulfilled the terms of the invoice then the
buyer's responsibility to payment is irrefutable. In the event that the card was lost and not reported, then the
Issuer, like today will have agreed to specific terms with cardholder, which
define the cardholder liabilities.
It will also be responsible for
monitoring buyers using E*MERGEŽ to assure overall system integrity.
Is responsible
for assuring the buyer that the seller can be trusted (see 5) Validate Seller and Buyer). The MP
server also handles communications with the EFTPOS networks. To support these networks the operator of
the MP server must build and support the requisite interfaces to the existing
EFTPOS systems necessary to support the payment methods that it wants to offer
to its clients the merchants. The role
of these interfaces is to simulate, on behalf of the seller, a point of sale
terminal connecting to the Acquiring Bank authorization and clearing system.
The operator of
the MP server will build relationships with the Acquirers operations and
systems people to develop and operate a mechanism that will be used to make
sure the information necessary to insert the sellers details into the payment
instructions is accurate and up to date.
It also has responsibility to develop and manage the technical interface
to the appropriate EFTPOS networks used to process authorization and payment
instructions.
The operator
will work with sellers to install the E*MERGEŽ
Merchant OLTP software, 3DASä Readers
and the 3DASä Cards
required to meet peak performance. As appropriate
it may provide proprietary interfaces to the sellers' management and logistical
systems.
During the
transaction process, the payment server will assure seller authenticity,
provide the necessary MP details, monitor the progress of the payment
authorization and provide feedback to the seller of approval or rejection. Given that many payment systems work on the
concept of payment on delivery it must also support the ability to subsequently
receive a confirmation of delivery, from the seller, and submit the appropriate
EFTPOS clearing message to initiate payment.
Electronic logs
shall exist that can be used to prove claims of seller irrefutability. In the event of a dispute the Acquirer is
assured that the customer was present, that a valid copy of the invoice was
provided, that the seller was authentic and that the buyers card was present
at the time of the transaction. To
perform this function the bank simply asks the seller to provide the invoice
as originally sent and compares this to the sellers signature of
the invoice generated at the time of the transaction and approved
with a verifiable signature by the buyer's card. Assuming the seller has fulfilled the terms of the invoice,
payment is guaranteed.
Both the seller
and the buyer must be confident that the E*MERGEŽ CP or MP Server that they are
communicating with is authentic. The
simplest way to achieve this essential level of trust is to require each
payment server to create a secret key and then to derive a public key using an
E*MERGEŽ specified public key algorithm
E*MERGEŽ
employs the most basic form of Public Key cryptography and therefore does not
requires a certification authority or any registration authorities.
When the buyer or seller initialises
the payment profile, the public key of the trusted payment server is
automatically loaded. The matching
public key held by the buyer or seller therefore can validate each message
signed with the payment servers unique secret key.
Unicate has
insisted in developing a solution that is easy to use and mobile. To achieve this result its effort to assure
an easy to use mobility option required the creation of an easy to form URL. As will be described in Error! Reference
source not found.
by the E*MERGEŽ Browser
Plug-in simply needs to know the name of the cardholders issuer to make a
connection to www.issuerID.3DAS.org. Employing the power of the Internet
addressing scheme makes this simply to do and only requires the management of a
DNS server responsible for the sub addresses of the domain 3DAS.org. The task simply to provide the central
domain server capable of populating the Internet with the IP addresses of the
appropriate E*MERGEŽ CP Servers.
Further
recognizing that parties do cease to operate or that the addresses of servers
connected to the Secure VPN may change a single master directory of currently
authorized payment servers will need to exist. The same entity responsible for managing 3DAS.org can manage this secure directory.
The
3DASä
E*MERGEŽ Transaction Flow (narrative)
The
buyer has located a shop on the web and goes shopping.
During
this shopping experience the sellers will want to find out if they will receive
card present or card not present terms on the
sale. In E*MERGEŽ this means that the
seller wants to know if a 3DASä Reader is attached to the buyers PC.
Sometime
during the buyer's shopping process the merchant OLTP server will send a
message to the buyers browser asking if it can talk to an E*MERGEŽ Browser Plug-in.
If the
E*MERGEŽ Browser Plug-in does not
respond then the merchant web server can plan to use a payment request form
protected by SSL. If this were case
then transaction are card not present
or as a Mail Order Telephone Order transaction.
If the
E*MERGEŽ Browser Plug-in does
respond, then the seller can assume there is a high probability that it will be
a card present transaction.
In the
case the goods will be delivered to a buyer the seller could request specified
address information contained in another plug-in performing services like the
Microsoft Wallet plans to offer. The
E*MERGEŽ assumption is that this information forms part of the sellers final
terms and conditions.
At the
end of the shopping experience, the buyer will agree to purchase a set of goods
under a set of the terms & conditions and for a specific price.
The
seller encapsulates all of this information into a digital format that can be
displayed by the buyer's browser and processed by the E*MERGEŽ Browser Plug-in.
For the purpose of this write up, the plug-in was located during the
shopping experience. This message
contains:
3 The invoice
3 A unique reference number
3 A random pseudonym used
to identify the seller
3 An random pseudonym used
to identify the 3DASä Merchant Card
3 The payment options the
seller accepts (AMEX, electronic check, Electron, Maestro, MasterCard, Visa)
3 A random Pseudonym used
to identify each payment method
3 The Hash of the invoice
and other elements of the message
3 The seller's 3DASä
Signature
3 The unique 3DAS serial
number
Assuming
the buyer is happy with the deal, the buyer should be ready to commit to pay
for the goods or services offered. The
E*MERGEŽ Browser Plug-in will request the buyer to insert a 3DASä Card.
Using the results of this first read of the 3DASä Card the E*MERGEŽ Browser Plug-in will
identify which payment profile the buyer wants to use. (See Error!
Reference source not found. on page 5 for further details).
In the
event that the buyer does not insert a card, the E*MERGEŽ Browser Plug-in sends an error message back to the
merchant web server. The seller then
defaults to requesting payment through an SSL script, assuming they wish to take
the risk of a card not present transaction. It would also be recommended that they display a warning and an E*MERGEŽ advertisement.
The
E*MERGEŽ Browser Plug-in compares
the consumer payment profile, associated with that card, to the list of payment
methods found in message 2) Sellers Invoice. In
the E*MERGEŽ Browser Plug-in payment window the payment methods that both
parties employ are displayed with easy to recognize icons. The screen prompt requests the buyer to
choose a payment method or decline the purchase. The buyer clicks on a payment method and the E*MERGEŽ Browser
Plug-in calculates a Hash and requests
the 3DASä Reader to create a 3DASä Signature.
In the
event that the buyer wishes to change the terms of the invoice, then the E*MERGEŽ Browser Plug-in assumes the
seller will resubmit the invoice and this request to pay session is closed.
If
appropriate, the 3DASä Reader can include a PIN Pad to allow the PIN
as a second security mechanism. By including this inexpensive,
tamper evident keypad allows the banks customers to use debit cards as a secure payment product
on the Internet. Simultaneously the
E*EMERGE allows banks the ability to introduce PIN on credit cards, eliminating
fraud loses attributed to lost and stolen cards.
If
this is the case, the plug-in will instruct the buyer to enter the PIN into the
appropriate PIN Pad before the creation of the 3DASä Signature. For a complete description of the process
please see the description of a Error! Reference source
not found. on page 5.
At the
completion of this session, the merchant web server receives a message from the
plug-in with the buyers commitment to pay.
This message contains selected information from the merchant
invoice message and adds the following
3 The address of the CP
server
3 A random pseudonym used
to identify the buyer
3 The payment method
selected
3 The random pseudonym of
the payment method selected
3 The Hash of elements of
this message
3 The buyers 3DASä
Signature
3 The unique 3DAS serial
number
The E*MERGEŽ Browser Plug-in sends a message
to the address of the CP server, stored during the registration process described
on page 5. This message
contains all the information necessary to allow the payment servers to
authenticate both the buyer and seller and submit a request for payment
authorization through the existing EFTPOS networks.
Since
both the sellers and the buyers identities are masked by a set of random
pseudonyms known only to the payment servers and the respective E*MERGEŽ Browser Plug-in, their identities are secure over the
public Internet.
The
only other information that must pass across the Internet to the banks (payment
servers) is:
3 The amount
3 A code indicating the
type of merchandise, as specified by the payment system
3 A time stamp
3 The 3DASä
Signatures that confirm authenticity
3 The address of the MP
server
3 A set of random numbers
that are meaningless to outside parties
The
E*MERGEŽ Browser Plug-in creates an electronic log of the event and statuses
the log record as pending the results of the request for payment.
If the
buyer wishes to await further information the status of the request for payment
is monitored and displayed in the plug-in's window.
Employing
the random pseudonyms sent in the message by the E*MERGEŽ Browser Plug-in the
E*MERGEŽ CP Server identifies the buyer and the selected means of payment from
the E*MERGEŽ Consumer Profile. The
authenticity of the buyer is validated as described in the section on the Error!
Reference source not found. on page 5 to 3DASä Key held in the E*MERGEŽ Consumer
Profile. If appropriate, the buyers
PIN is verified using the logic described in the section on a Error!
Reference source not found. on
page 5
The
data, held in the secure 3DASä Consumer Profile, needed to fill in the
appropriate EFTPOS message, i.e. the ISO 8583, MT or domestic electronic
clearing houses formats, is inserted and sent over the Secure VPN to the
E*MERGEŽ MP Server.
The
E*MERGEŽ MP Server employs the random pseudonyms of the seller, passed from by
the E*MERGEŽ Browser Plug-in, to identify the seller and its selected means of
payment. The E*MERGEŽ MP Server validates the authenticity of the seller using
the 3DASä Key held in the E*MERGEŽ Merchant Profile. Then using the content of the E*MERGEŽ Merchant Profile the necessary
details to complete the requisite EFTPOS message are inserted into the EFTPOS
message already containing the buyer's details.
In the
event either party does not pass the 3DASä authentication process, both the buyer and the
seller receive error messages.
Ř In the case of the
seller, this is essential to further processing of the order. If the buyer is not authentic, the seller
will want to halt the delivery of goods or services.
Ř If the buyer does not
know that there was an error, no deduction of funds from their account will
occur and the seller will lose a sale.
Ř Obviously appropriate
fraud alerts will be created and further investigation can begin.
Assuming
both parties are authentic, all of the necessary items required to assure
irrefutability from this point forward are logged by the payment servers and held for as long as E*MERGEŽ and the
EFTPOS networks dictate.
Knowing
that the seller is authentic, the buyer is authentic and acknowledging the
capability of assuring irrefutability, the merchant OLTP server starts the
EFTPOS payment process as defined by the authorities responsible for its
management.
All
the information required by the EFTPOS network to prove that a card was present
becomes part of an appropriate EFTPOS record.
The E*MERGEŽ MP Server sends the record to the appropriate EFTPOS
network and a response is awaited. In
the case of a credit card, a response will come back within a matter of
seconds, approved or declined. The results are electronically logged.
Based
on the terms agreed with the buyer and seller notification of the final status
of the payment is returned to the seller and/or buyer on-line or via an
off-line process. If the worst was to happen and the bank denied the request
for payment, then MP Server must informs the seller and the CP Server shall
informs and the buyer. The CP and the
MP notify their client be using the same logic, described below, to notify the
buyer and seller of the decline.
In the
case of the seller, a confirmation is important given that the seller will not
wish to ship until confirmation that the bank has authorized payment. In the case of real-time delivery of goods,
this would want to be an instant response.
In the case of physical goods, this may be a file sent every hour,
formatted based on the seller's requirements.
For example, the seller may wish it formatted for direct input into the
organizations logistics system.
In most cases, the buyer assumes that
everything is ok after they have agreed to pay.
In some cases, a buyer may be concerned that the
bank will not approve. Therefore they
will wish to remain connected to the status screen of the E*MERGEŽ Browser Plug-in started at step
4. In the event of a decline, the buyer
would then be in a position to propose another payment method.
This willingness to stay connected will also
apply to soft goods delivery, which will require a download, an electronic
process, the E*MERGEŽ Browser Plug-in could be used to facilitate.
This background connection to the E*MERGEŽ CP
Server also affords the server the ability to send any enhancements or updates.
Acknowledging
that the terms of payment for goods bought and sold over the Internet is a
subject of much regulatory discussion, our design approach is to assume that
present conditions covering mail order telephone order transactions will
prevail.
When
the seller rightfully believes that they have delivered the goods to the
rightful buyer then they can either submit through the Internet or through a proprietary
interface a request for payment message.
The MP
server will authenticate the seller and prepare the necessary EFTPOS message
using information in the transaction log and further information included in
the request for payment message.
This
clearing message will be submitted to the appropriate EFTPOS interface. Settlement will occur, as today, employing
existing settlement procedures.
Independent
of the payment process the seller may wish to send the buyer an e-mail or
surface mail to provide details associated with delivery of goods.
Working
on the assumption that the merchant is delivering soft goods then E*MERGEŽ
Browser Plug-in, on acknowledgement of merchant authentication and payment
approval, can organize the connection to the appropriate merchant download
site. When this message and the "notify merchant of acceptance"
match, then the download site can authorize the transfer.
Assuming the E*MERGEŽ
Browser Plug-in successfully connects to the download site, all is well. If not, the seller can use other
means to deliver the soft goods to the buyer such as sending the hyperlink of
the download site in e-mail.
To describe what is taking place at the
consumer site it is important to understand how 3DASä and E*MERGEŽ are integrated into the
consumers Internet access device. This
device could be a personal computer a mobile phone, a set top box, a digital TV
or a personal digital assistant. In the
case of many of these devices, the 3DAS Reader would be integrated during the
manufacturing process. IN THE CASE OF A
PC, it is probable that the installation would occur after the initial
purchase; as would be the case will the 100s of millions of PCs now in
operation.
This specification will dwell on this PC
environment.
In simple terms, the buyer is provided with
or purchases a 3DASä
Reader, connects the 3DASä
Reader to the PC and loads the E*MERGEŽ
Browser Plug-in. The 3DASä
embedded card is received and the plug-in is registered with E*MERGEŽ CP
Server.
Picking
up from the point during the shopping experience when the E*MERGEŽ Browser Plug-in became aware, and
informed the buyer, that the seller also supports E*MERGEŽ it sits idle awaiting receipt of a message 2) Sellers Invoice.
After
the invoice is received and while the invoice is being displayed by the
browser, the E*MERGEŽ Browser Plug-in AUTOMATICALLY updates a local electronic
log indexed by the Ref# and validates the Hash, thus assuring the integrity of
the data sent by the seller.
An
E*MERGEŽ Browser Plug-in window will appear and request the buyer to enter
their 3DASä Card.
A 3DASä read is performed and the E*MERGEŽ Browser
Plug-in determines if it has a payment profile associated with that card. (See Error! Reference source
not found. for more details)
The
E*MERGEŽ Browser Plug-in then compares the list of payment options sent by the
seller to the set of payment options found in the seller's payment
profile.
The
E*MERGEŽ Browser Plug-in will state that the buyer has requested secure
E*MERGEŽ payment and offers the list of matching payment options. The buyer has the option to select one or
cancel.
The
seller receives a response based on the information found in the invoice
message defining how to respond to the buyer selecting the cancel button.
The
buyer has selected which means of payment and committed to pay. The E*MERGEŽ Browser Plug-in sends a commit
message, message 3, to the seller and issues the request payment authorization
message, message 4, to the CP server.
The
E*MERGEŽ Browser Plug-in window will begin to display the status of the payment
process. The buyer can either decide to
wait and watch or go and surf somewhere else.
Assuming the buyer's Internet connection is still active the E*MERGEŽ Browser Plug-in remains active
and awaits a response to confirm the commit to pay. If the buyer disconnects from the Internet the E*MERGEŽ Browser
Plug-in is left in a pending response state.
In the
event that the user leaves the E*MERGEŽ
Browser Plug-in window visible the first update will be acknowledgement of
seller authenticity. Acknowledgement of
payment approval by the bank will follow.
In any
case the E*MERGEŽ Browser Plug-in will need a response to the request for
authorization so that it can internally acknowledge completion of the
transaction. If the Internet connection
is not interrupted and the E*MERGEŽ Browser Plug-in remains active the CP
server will return confirmation of seller authentication and approval of the
payment.
In the
event the connection is lost, the ability for the plug-in is not longer able to
receive a response. Therefore, upon
reactivation of the plug-in, the plug-in will (in the background) connect to
each of the CP servers in the profile, that should have outstanding messages,
requesting delivery of any outstanding messages targeted for that buyer's
plug-in.
In some cases, the buyer will disconnect from the
Internet. In other cases, the buyer
will not always use their designated home device. In order to keep the electronic log up to date and to assure the
customer they have all the information they might need in the event of a
dispute. The E*MERGEŽ Browser Plug-in
must have a means of synchronizing itself and collecting information about
E*MERGEŽ purchases performed on other devices.
To assure that the home E*MERGEŽ Browser Plug-in is
fully synchronized it must have the ability to automatically connect to the
various CP
servers it is registered with. So
periodically when the home device is connected to the Internet the 3DAS
Browser Plug-in will request permission from the buyer to synchronize
itself. Assuming the buyer grants
permission, the plug-in will automatically connect to each payment servers it
knows and perform a synchronization process.
During
these synchronization sessions the plug-in will request downloads of any
pending messages concerning seller authentication and payment approval. It then requests a download of the messages associated
with the mobile purchases kept on the buyer's that have taken place since the
last synchronization session.
All
messages are logged and as appropriate matched to any the pending commits to
pay records.
This
electronic log offers the buyer all he needs to track goods purchased over the
Internet using E*MERGEŽ. The buyer uses
a simple viewer, installed at the time the E*MERGEŽ
Browser Plug-in was loaded, to monitor his Internet purchasing activity.
As
described in the section 7)
Notify Seller of Acceptance the E*MERGEŽ
Browser Plug-can be used to authorize the download of soft goods. Part of the function of the status screen
would be to inform the buyer to initiate the download. Assuming the buyer agrees the plug-in can
initiate the FTP session and provide any corrective action as may be
appropriate.
In the event of dispute the E*MERGEŽ Viewer can be used
to print the necessary information to support the claim that the seller has not
fulfilled their commitment to deliver.
Services that extend the features of the E*MERGEŽ solution, such as integration to
Quicken or MS Money, can use this file to offer expanded value added
capabilities.
Secure E*MERGEŽ VPN
