Appendix 3 - The Architecture of E*MERGE®

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.

The Buyer Requires

Ø*                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®.

The Seller Requires

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 seller’s 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

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[3].

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[4] 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. 

The E*MERGE® Profile is simple in structure:

Ø*                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 E*MERGE® Consumer Payment Server (EMERGE®CP Server)

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 buyer’s 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 buyer’s 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 buyer’s 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 seller’s 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.

The E*MERGE® Merchant Payment Server  (EMERGE®MP Server)

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 Acquirer’s operations and systems people to develop and operate a mechanism that will be used to make sure the information necessary to insert the seller’s 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 buyer’s 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 seller’s 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. 

Payment Server Authenticity

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 server’s 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  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  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 can manage this secure directory.

The Transaction Flow (Flow Chart) of E*MERGE®


E*MERGE® Data Elements Relationship between Profiles, Logs, Hashes and Messages

The 3DASä E*MERGE® Transaction Flow (narrative)

1) Shopping Completed with a Request to Buy

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 buyer’s PC. 

Sometime during the buyer's shopping process the merchant OLTP server will send a message to the buyer’s 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[5].  The E*MERGE® assumption is that this information forms part of the seller’s 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.

2) Seller’s Invoice

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

3) Buyer Commits to Purchase

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) Seller’s 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 bank’s 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 buyer’s 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 buyer’s 3DASä Signature

3*                The unique 3DAS™ serial number

4) Request Payment Authorization

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 seller’s and the buyer’s 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.

5) Validate Seller and Buyer

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 buyer’s 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.

6) Existing EFTPOS Networks, Domestic, MasterCard, SWIFT … VISA

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. 

7) Notify Seller of Acceptance

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 organization’s logistics system.

8) Notify Buyer of Seller Authentication & Payment Approval

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.

A) Request for Payment on Delivery

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.

· Physical and Soft Goods Delivery

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.

The Customer Interface

To describe what is taking place at the consumer site it is important to understand how 3DASä and E*MERGE® are integrated into the consumer’s 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.

i) Select Payment Method

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) Seller’s 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.

In the event that the buyer wishes to 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.

ii) Payment Agreement

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.

iii) E*MERGE® Browser Plug-In Status Screen and Electronic Log Functions

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.

horizontal rule

[1] The number is a function of the throughput of a 3DASä Reader at 150 milliseconds per read and the number of simultaneous transactions that require a 3DASä Signature.

[2] This module replaces any payment functionality that may already exist.  Built into this software will be the logic to conduct an E*MERGE® transaction or decide to employ a standard SSL form to allow input of credit card details.

[3] APACS is the Association of UK clearing banks.

[4] In the schematics included later in this document, these transactions are in lower case roman numerals.

[5] A more appropriate solution is to integrate the functionality of these wallets into the 3DAS™ Browser Plug-in.  At the time of the preparation of this document dialogues with the key suppliers of wallet software have not taken place.