SET Secure Electronic Transaction: a market survey and a test implementation of SET technology

This introductory chapter starts by presenting a background discussion before the purpose of this master thesis is declared. After the purpose has been specified, some methodological considerations are reported, before the chapter ends with a short description of the disposition of this report.

Today we a dawning revolution concerning the way we as consumers go about purchasing the goods and services we need and desire. The exceptional growth of the World Wide Web (www) has created a new medium for commercial transactions, here referred to as Internet commerce (I-commerce). From a marketing perspective I-commerce entails some powerful possibilities such as automated and personalized direct interaction with customers, and global market coverage. The predictions for I-commerce are close to exponential in nature for the next coming years. Estimates for 1997 are a total of about 700 million dollars. A sum that seems relatively insignificant compared to the predicted total for 2010, which amounts to the staggering sum of 1 000.000 million dollars. 1

Although the technology already is in place, I-commerce hasn’t really taken off. The primary reason for this reluctans is that most consumers still consider financial transactions over the Internet unsafe. In Europe the use of credit cards online is further hindered by national legislation, that in some countries prohibit online credit card transactions because these are considered not fulfill the requirement that all card transactions must be physically signed by the cardholder. In order to eliminate this barrier to the evolution of I-commerce, a consortium headed by Visa and MasterCard has developed a standard for secure electronic transactions (SET). 2

SET is a complex standard combining advanced cryptography for safe data transfer, and hashing technologies for data integrity, with digital certificates for authentication of the parties involved in the transaction. Being such a complicated standard there have been quite some problems with developing and now with implementing it. As of today there are no implementations in full production, but there are a number of pilot projects running. One of the major questions to be resolved is the issue of interoperability between the products from different SET-software vendors. Another is the issue of systems integration between merchant side SET-applications and the business systems already in use. These and many other must be answered before we can expect SET to become a widely implemented standard.

The purpose of this Master thesis is to research how Internet commerce applications can be made SET compliant, and to develop a prototype that clarifies the systems integration process and the main problem areas of the technology involved. This purpose can be seen as two distinct tasks. One task involves a market survey of the developers of SET technology and an appraisal of their respective products. The other task is to develop a prototype to evaluate the difficulties of systems integration between the SET application and the merchant I-commerce system.

The first thing to remark, concerning the methodology employed for this research, is that the approach employed has been of a rather explorative nature. This is especially true for the first task (the market research of SET developers/suppliers), which entailed a considerable amount of surfing the Web to gather the required information. This research was aided considerably by search engines (such as altavista), and by the collection of hyperlink references on MasterCard’s Web-page www.mastercard.com/set/set_products.html and on SetCo’s page www.setco.org/matrix.html. It should be mentioned that the market survey has been limited to those developers/vendors that supply SET technology applicatble for SET enabling merchant I-commerce systems. It should further be mentioned that this survey only aspires to outline the main differences between the products available on the market today, and therefore by no means claims to be complete in its depth and coverage.

It should further be added that the research topic as such required a not unsubstantial study of the SET standard and the technologies used by the case study company. Quite a number of days were spent gathering the knowledge required before the first research task could be commenced. And nearly a quarter of the total time spent on the research project was needed to acquire a sufficient understanding of the server side technologies that the prototype was to be built on. So all in all the "explorative" aspects of this project were considerable.

When all this rather explorative work was done and an appropriate supplier of SET technology had been selected, a more structured system development method was applied for the second research task (i.e. the development of the prototype). A relatively classic and linear method was practiced, as the research task was started with an analytical phase, followed by phases of design, implementation and testing (c.f. e.g. Sommerville, 1996). It should be added that the implementation was limited to a rather simple test implementation that only simulated the major aspects of a real systems integration, such as the communication between a SET application and a merchant I-commerce system.

This report starts with a chapter on Internet commerce (chapter 2) to supply the reader with some background information of the area that the SET protocol is intended to impact. There after the SET specification itself and its associated technologies are explored in chapter 3, before we take a closer look at the SET developers/suppliers that have appeared on the market (chapter 4). Finally, the test implementation/integration is reported in chapter 5. Finally, I would like to point out that notes (hyperlinks) have been added throughout the report. These contain both comments and references to the sources behind this master's thesis. When activated they will start and be displayed in a separate browser window, so that you don't have to backtrack all the time. The reference chapter at the end of this report contains more details about all references (both Web based and printed) that have been used, and these references are presented in the order of their appearance in the report, instead of the classical way of listing them alphabetically. All for Your convenience.

Because of all the hype, that surrounds the Internet and electronic commerce, there is quite some confusion concerning what the term electronic commerce really covers. Therefore I have chosen to use the term Internet commerce (I-commerce) in this paper. Definitions of and a distinction between the related terms is supplied below, together with a glimpse of the evolution of I-commerce and its state today. A further understanding of the topic is sought by looking at the levels and benefits of, and the barriers to Internet commerce.

As mentioned above, quite some confusion regarding the terminology has resulted from the fast evolution of the Internet and its related technologies. The semantics of the term electronic commerce (e-commerce) has shifted from before referring to EDI and other closed network solutions for transmitting business transactions, to today mainly be referring to commercial transactions taking place over the Internet.3 This is somewhat unfortunate since this could lead to misunderstandings concerning what the term really stands for. I therefore propose the use of the term Internet commerce (I-commerce) when referring to business transactions done over the open network known as the Internet.

Some further distinctions should be added to help clarify this large and overly hyped area. Firstly, one special case of Internet commerce is Internet trading, in which a supplier provides goods or services to a customer in return for payment. A special case of Internet trading is Internet retailing, where the customer is an ordinary consumer rather than another company.4

However, while these special cases are of considerable economic importance, they are still just examples of the more general case of any form of business operation or transaction conducted using Web based technologies. Other equally valid examples include internal transactions within a single company (intranet solutions) or exchange of information with external organizations such as suppliers (extranet solutions).

In this paper we will mainly be focusing on the sub section of Internet commerce that relates to Internet trading. This since the research subject is concerned with a protocol for secure payment of commercial transactions conducted over the Internet. Below follows a short summary of the evolution of this sub section of Internet commerce.

The birth of I-commerce has a short but explosive history, and is by its nature closely related to the evolution of the Internet. The Internet has been around since the 1960’s, but its wide spread use is quite novel, and it only first really took off with the development of the graphic hypertext service known as the World Wide Web (www). Since Tim Berners-Lee at CERN founded it back in 1992, the Web has grown from just 16 academic sites to over 11 million sites of all categories today.5 This astronomic growth can be attributed to a number of factors, two of the more important being the new graphical Web browsers (i.e. Netscape Navigator and Internet Explorer) and the low cost of and ease with which Internet Service Providers (ISPs) provide inexpensive access to the Internet.

After only five years of existence the Web has already become a popular market channel for diverse products and services. First out were, not surprisingly, the manufacturers/distributors of computer software and hardware. But now, as the Web population grows and diversifies demographically, more and more categories of products/services are being added. The graph in figure 1 below summarizes what is being traded on Wed today.

The graph shows that Web shoppers today still seek information about hardware and software over $50 to the greatest extent (61% and 58%, respectively). However, travel and books/magazines have surpassed hardware under $50 in terms of the percentage of respondents looking for information about these items. For items actually purchased over the Web, books/magazines are the most common (30%) followed by software under $50 (30%) and travel (26%). Other non-computer related categories are music CD/tapes (20 %), banking and investments (12% res. 10%), and clothing/shoes (10%).

Overall, the results of this study reveals that Web surfers still seek information on the Web about various items a lot more often than they actually make purchases. Another interesting revelation, is that the items which are purchased most frequently are not the same items that respondents seek information about most frequently.

It is a good idea to distinguish different forms of Internet commerce, as there are various "levels" at which Internet commerce is and can be conducted. These range from a simple Web presence to electronic support for processes that are jointly owned and enacted by two or more companies. Unfortunately there is no commonly accepted categorization of these levels, so I here below present both a categorization presented at an informational site on electronic commerce that the European Union supplies6, and a categorization that reflects the levels of online maturity an organization can display. Lets start with the latter.

According to a leading Internet spokes person in Sweden there are five distinct levels of "Internet maturity" that a company can display (Sturmark 1997). These levels are the following:

The company acquires an Internet access and starts exploring the Web with the objective of better understanding the new media.

The company decides to develop a presence on the Internet, and develops a simple informational company homepage.

The company realizes that customers can reach the company via the Internet, and starts adding links to key personnel at different departments within the organization that customers can write to.

The homepage is developed into a full service site where customers can give structured information to the company in order to get assistance in their shopping quest. Customers can also place orders for the company’s products/services online.

The site is further developed so that it can be instrumental in the pursuit of true relational marketing. This entails dynamic site generation based on information previously collected from the individual customers (stored in databases that are directly accessible by the Website). This form of Website strives to create personalized relations to every customer, by using database technology, in conjunction with technologies for dynamic Webpage generation, and push-technology, to create an informed and personal treatment of each individual customer. This includes aspects such as personalized offerings of products/services based on information about previous purchases and information supplied by the customer. Furthermore personalized pricing policies can be implemented, to accommodate price differentiation based on what ever criteria the company feels suitable and desirable.

The European Union’s categorization highlights the distinction between national and international transactions. The source of this distinction is thus legislative rather then technical, and emphasize that Internet commerce is more complex at the international level than the intra-national level because of such factors as taxation, contract law, customs payments, and differences in banking practices.

As seen in figure 1, the lower levels of electronic commerce are concerned with a basic network presence, company promotion, and pre- and post-sales support. By using available "off the shelf" technologies, these levels can be both cheap and straightforward to implement. By contrast, the more advanced forms of Internet commerce pose complex problems that are as much legal and cultural as technological. At these levels there are no "off the shelf" solutions, so companies are forced to develop their own custom systems. Thus at present it tends to be only the larger companies that are pioneering on these levels. However, the boundary of what is commonplace will gradually move up to encompass the more complex levels of Internet commerce, and further "off the shelf" technologies will be supplied to support these higher levels, just as they already are for the lower levels.

With the purpose of shedding light on the future potential for Internet commerce, we here take a closer look at the benefits it brings to companies and their customers.

The Internet provides access to a global marketplace that is open 24 hours a day, 365 days a year. Marketing efforts on the Internet therefore has the potential of unprecedented market coverage and that at very low costs. Theoretically every Webpage has the possibility of reaching everybody that is surfing the Web (today some 60 million users7). In practice Web marketing is a science in its own right. A science that will become increasingly intricate the more advanced and populated that commerce on the Internet becomes.8

Thanks to the Internet, companies that previously had access to only their local geographic area, now have the potential of reaching customers across the globe. Furthermore, small companies now have a chance to effectively compete with larger companies since everyone, regardless of size and resources, is just a click away. New purely Web based companies such as Amazon.com (an online book store) have been able to establish high levels of customer loyalty and are providing products at lower prices than their brick and mortar counterparts can match.

With I-commerce starting to be more and more interactive, companies are becoming able to gather detailed information on the needs of their individual customers, and can start to automatically tailor products and services to fulfill those individual's needs. In ideal cases this will have the potential of resulting in customized products comparable to those offered by specialized suppliers but at mass market prices. One simple example is an online magazine that is tailored for the individual reader on each access to emphasize articles likely to be of interest and exclude articles that have already been read.

This aspect of Internet commerce is a very powerful one, since it enables very far developed levels of market driven organizations. Customer orientation has been something of a hype in marketing and management during the last decade, but for most organizations its been very difficult to implement. The Internet has the potential to change this, and start a real wave of customer orientation at many diverse companies and organizations.

A natural consequence of the global scope of Internet commerce is that it entails higher degrees of competition, but the technology involved also enables suppliers to improve their competitiveness by becoming "closer to the customer" and responding faster to their inquires and needs.

Many companies are already employing Internet based technologies to offer improved levels of pre- and post- sales support. This allows for increased levels of product information, guidance on product use, and rapid response to customer inquiries. The latter is often implemented via e-mail on demand technology, which allows automation of e-mail responses to customer inquires. Considering the growing importance of online product/service information in the pre sales process of today’s customers, it is becoming increasingly important for companies to supply well structured and rich information on their Websites.9

Internet commerce often allows traditional supply chains to be shortened dramatically. There are many established examples where goods are shipped directly from the manufacturer to the end consumer, by-passing the traditional staging posts of wholesaler's warehouse, retailer's warehouse and retail outlet. Typically the contribution of I-commerce is not in making such direct distribution feasible - since it could also be achieved using paper catalogues and telephone or postal ordering - but rather in making it practical in terms of both cost and time delays.

The potential for supply chain shortening is greatest in the cases where products and services can be delivered electronically, that is where the distribution part of the supply chain can be eradicated entirely. This will have massive future implications for such industries as the entertainment industries (film, video, music, magazines, newspapers), the information and "edutainment" industries (including all forms of publishing), and for companies concerned with the development and distribution of computer software.

In addition to redefining the markets for existing products and services, Internet commerce also provides the opportunity for entirely new products and services. Examples include network supply and support services (e.g. ISP), directory services, contact services (i.e. establishing initial contact between potential customers and potential suppliers), and many other kinds of online information services.

One of the major contributions of Internet commerce is the reductions in transaction costs it entails. While the cost of a business transaction that involves human interaction might be measured in dollars, the cost of conducting a similar transaction electronically often is a few cents or less. Hence, any business process involving "routine" interactions between people offers a potential for substantial cost savings, which in turn can be translated into substantial price reductions for customers and there by increased competitiveness.

Although there are numerous benefits of doing commerce on the Internet, the fact is that most companies still remain hesitant about the whole idea. While this might to some extent be alluded to the common human instinct to resist change, there are also a number of other barriers to I-commerce. The most prominent of these barriers are listed and explained below.

The most significant barrier to Internet retailing is the fact that most customer have negative perceptions about the security of online financial transactions.10 They simply don’t perceive it as safe to transmit credit card information over the Web! And as long as these perceptions last, there is little chance for I-commerce to take off for real, at least concerning consumer oriented Internet commerce.

This barrier has been observed by a number of parties with interests in the integrated network security and secure electronic commerce markets. There are presently a number of secure payment providers (e.g. CyberCash, First Virtual Bank, DigiCash) that offer alternative ways of paying, instead of sending credit card information over the Web.11 Although these systems might be very secure and functional, they all have the unfortunate quality of being new and unfamiliar to most consumers, and are therefore experiencing difficulties in winning any substantial market shares.

The only payment systems that consumers are used to, besides cash and checks, are the credit/payment card systems (such as Visa, MasterCard and AmericanExpress). These systems have been marketed and built up under a period of several decades and are today household brands all over the world.12 So, as long as consumers regard using these payment systems over the Web, it will be difficult for Internet retailing to grow to it’s full potential. In response to this fact, MasterCard and Visa have established a consortium, together with a number of major players in the computer and banking industries, with the sole purpose of developing an open standard for secure electronic transactions (SET). This standard is thoroughly described and debated in chapter three, so it will suffice to say that it’s still in development and has both pros and cons associated to it.

Although the technology needed to perform advanced forms of Internet commerce exists, it’s still in an early state of evolution. It is important to understand that the Web was developed to display static information (primarily intended for scientific reports) and therefore requires Web developers to work around these limitations in order to create the dynamic sites needed for I-commerce. There are also considerable difficulties in integrating the Web applications with the backoffice systems (e.g. ordering, stock-keeping, and accounting systems), which is desired in order to take full advantage of direct interaction with the customers.

The above mentioned issues are mainly the concern of retailers/manufacturers that wish to go online. From the consumers pinot of the view there are some other issues to be added, such as the issues of authentication and merchandise tracking. Actually the issue of authentication is of interest to all parties involved in I-commerce, because for the customer it’s important to know that he/she is dealing with a reliable company, and for the company it’s important to be able to prove that a customer really place an order in case of payment disputes. Tracking the merchandise is important since it allows customers to stay informed about the processing and delivery of their order, and thereby feel more safe about ordering online.

The fact that the Web is such a new channel for commerce entails that there is only a limited number of potential customers online. At least this is what many manufacturers and retailers still believe, and therefore quote as a reason for not going online commercially. To some extent this perception is still true, but it won’t be for very much longer.13 The critical mass of potential customers online has already been reached for some product/service categories, and for many other categories this level will be attained relatively soon.14

Most distribution systems in operation today are ill-equipped for Internet commerce, as they are set up for bulk distribution (i.e. to move palletized products), not to pick, pack and ship individual consumer orders. Furthermore many of the Internet order systems in use today are not integrated with the backoffice distribution systems, instead these Web-sellers are using modified and sub optimal versions of their existing systems to fulfill orders. Although companies might get away with this now, fully integrated systems will become a critical success factor as volumes increase, unit value decreases and Internet sales begin to include more fragile goods that have limited shelf life.15

On the other hand these fulfillment problems represent a major opportunity for traditional wholesalers and distributors. Already more than a quarter of all Web sellers have outsourced their order fulfillment, and this number is expected to increase as I-commerce grows.16 Personally I believe that we soon will see the development of a new global distribution infrastructure which Internet retailers will be able to plug into. This infrastructure could be an extension of, and/or cooperation between, the third-party distributors already in operation (e.g. national postal services, Federal Express, UPS), but it would be further developed and more cost effective.

A great and very difficult barrier to the full potential of Internet commerce is that the Internet is more or less lawless. There exists little national and no international legislation concerning legal issues such as copyright, taxation, and online initiated agreements/contracts. What’s needed is both national and global legal frameworks that regulate online business in the same way as traditional business is regulated today.

Unfortunately such a legal framework requires both a better understanding (especially at the political levels) of information technology (and it’s societal implications), and much national and international negotiating. As most politicians still haven’t started to grasp the extent and importance of these issues (and when they do it will require a lot of work), it will most unfortunately be quite some time till we can expect to see such a framework in operation.

No matter how many the problems and barriers are to Internet commerce, there is no doubt that it is the way of the future. All reports and surveys point in the same direction. So, it’s not so much a question of if as one of when I-commerce will reach it’s full bloom. Predictions for online shopping and transactions vary, but even the most pessimistic predict substantial amounts for the years after 2000.17

And consumers are not the only source of commerce on the Internet. Business to business transactions are expected to take the lions share of the commerce on the Web.18 The greatest potential for I-commerce is found in the business-to-business segment, partly because it offers such a cost effective way for organizations to communicate with their clients and suppliers. Lets now take a closer look at the SET protocol, which is one of the standards that are being developed to facilitate the evolution of I-commerce.

This chapter covers the technologies used in the SET protocol and explains the process involved when making a purchase using SET. However, we start with a short background.

On February 1, 1996, Visa International and MasterCard announced together with others (including Microsoft, IBM, Netscape, SAIC, GTE, RSA, Terisa Systems, and VeriSign), the development of a single technical standard for safeguarding payment card purchases made over open networks. This standard was to be called the SET Secure Electronic Transaction^TM specification. Prior to this effort, Visa and MasterCard were pursuing separate specifications, and the new SET specification represented a convergence of those individual efforts.19 In mid December 1997, a new corporate entity called SET Secure Electronic Transaction LLC (SETCo), was formed by Visa and MasterCard to provide a structure that would govern and direct the future development of the SET Secure Electronic Transaction protocol, as well as other key functions that are required to support the implementation of this standard. In conjunction to this, agreements with American Express and JCB Co., Ltd. to become full partners in SETCo have been negotiated.20

The SET protocol provides three main advantages, that put together make it safer then other payment methods. These advantages are:

As these advantages involve diverse and rather complex technologies we will take a closer look at each separately here below. But in order to get some picture of what SET is all about, let’s start by having a peek at how the SET protocol processes a typical online purchasing order.

In order to introduce the technologies involved in SET, it’s useful to take a look at how SET operates. As the SET protocol is a rather complex standard, I’ve added figure 2 to visualize the parties and processes involved in a typical purchasing transaction.

Figure 2. The purchasing process when using the SET protocol. (Source: RSA Data Security)

As seen in figure 2, there are a number of parties involved in the purchasing process when using the SET protocol. First, there is the customer/cardholder and the merchant this cardholder wishes to purchase something from. Then there is the Acquirer, which is a financial institution that supports the card brand/s that the merchant accepts as payment. The acquirer is responsible for all the necessary financial transactions between the cardholder’s and merchant’s banks, and makes sure the merchant gets paid (point 6 in figure 2). Finally we have the Certificate Authority, who issues digital certificates to all the parties involved so that they can identify each other properly.

Before the SET protocol begins, it’s expected that the cardholder has browsed the merchants Webstore, has selected what to buy, and has chosen SET as form of payment. Assuming this has been done, the SET protocol starts with the merchant’s software sending the cardholder the merchant’s digital certificate for the brand of card that the cardholder has chosen to use. The merchant’s software also sends the acquirer's digital certificate, but separately. After the cardholder’s software (usually called the wallet application) has identified all relevant parties, it encrypts the cardholder's corresponding digital certificate and the payment agreement, and returns the results to the merchant (point 1 in figure 2).

The merchant’s software then decrypts the payment agreement message and forwards the still encrypted user account information and charge authorization request to the acquirer (point 2 in figure 2). It should be pointed out that this part of the SET protocol is designed to keep the consumer's account information (i.e. card number and expiry date) inaccessible to the merchant, so that only the payment processor (i.e. the bank) can see it. This actually makes SET shopping safer than shopping face-to-face, and much safer than mail or telephone ordering.

After receiving the authorization request from the merchant, the acquirer decrypts it and processes the request by requesting authorization for the amount from the cardholder’s bank (point 6 in figure 3). When the acquirer receives a response, it encrypts this and returns it to the merchant server (point 3 in figure 2).

When the merchant’s software receives the acquirer's response it checks that the required amount has been authorized and then encrypts and returns the response to the cardholder’s wallet application. Under the condition that funds where available the cardholder’s order is thus confirmed (point 4 in figure 2).

Lastly, when the order has been fulfilled the merchant requests payment from the cardholder’s bank via the acquirer (point 5 + 6 in figure 2).

Now that we have seen how the SET protocol works in action, it’s time to take a closer look at the specific technologies the protocol builds on. We start by exploring the cryptography involved in attaining the desirable levels of privacy.

The SET protocol uses two forms of cryptography to ensure the confidentiality of the transactions. First, an asymmetric form known as RSA is used for signatures and public-key encryption of symmetric encryption keys and bank card numbers, and then a symmetric form called DES takes care of the encryption of the data that is to be transmitted during the transaction. It might be of interest to take a closer look at these two forms of cryptation, so lets start with RSA.

RSA is form of cryptography developed at MIT by Ron Rivest, Adi Shamir, and Leonard Adleman back in 1977. RSA builds on the concept of asymmetric or public-key cryptography that was introduced in 1976 by Whitfield Diffie and Martin Hellman21 in order to solve the key management problem.. It uses pairs of so called private and public keys, that are mathematically related to each other. The public keys are shared over any network (including the Internet) and used to encrypt messages to the owners of them. The owner then decrypts the message using his/her private key. This way anyone can send an encrypted message, using only the public keys, but only someone in possession of the matching private key can decrypt the message. The need for exchanging the encryption keys over safe communication channels is thus eliminated, as you can make your public key openly available over the Internet without danger.22

DES (Data Encryption Standard) is an encryption block cipher defined and endorsed by the U.S. government in 1977 as an official standard. It was originally developed at IBM, and is the most well-known and widely used cryptographic system in the world. It is a symmetric cryptosystem, which means that both the sender and receiver must know the same secret key, which is used both to encrypt and decrypt the message. DES can also be used for single-user encryption, such as to store files on a hard disk in encrypted form. In a multi-user environment, secure key distribution may be difficult as it requires access to completely safe communication channels. This is also it’s major disadvantage compared to asymmetric public-key cryptography which provides an ideal solution to this problem. Why is then DES used in the SET protocol? It’s used because it’s much faster than RSA, generally at least 100 times as fast. 23

So how does the SET protocol combines the best of the two encryption methods? It does so by encrypting the message data using a randomly generated symmetric DES encryption key. This key is, in turn, encrypted using the message recipient’s RSA public key. This second encryption is referred to as the "digital envelope" of the message and is sent to the recipient along with the encrypted message itself. After receiving the digital envelope, the recipient decrypts it using his or her private key and obtains the randomly generated symmetric key and then uses the symmetric key to unlock the original message.24

SET is designed to be used with 1,024-bit cipher keys, making it one of the strongest encryption applications in public use. The time it would take to break the encryption described here, especially with all the various level of encryption that are occurring, is upwards to 2,800,000,000,000 years using 100 computers each able to process 10,000,000 instructions per second. Even then, only a single message could be broken and with the next message, the entire process would need to start over. While it may seem like overkill, the protocol is quite attractive to all those wanting to conduct widespread business over the Internet, especially the card issuers who have the most to lose from fraud. SET has been approved for export from the US, provided that it's only used in financial transactions, and not as a mechanism to pass secret or sensitive information to those outside the US.25

The SET protocol ensures data integrity by using one-way cryptographic hashing algorithms and digital signatures to make sure that the messages transmitted have not been modified in transit. A hashing algorithm is a function used to calculate a unique integrity value, called the hash value or message digest, from the original data (the message). But the hash function by it self does not guarantee absolute data integrity. For this it needs to be combined with a secret encryption key. Here is where digital signing comes into the picture. A digital signature is simply a hash value that has been encrypted using the sender’s private key before being appended to the rest of the message. The recipient decrypts the hash value using the sender’s (mathematically matching) public key and checks the resulting value. This procedure ensures the integrity of the data, since no one can encrypt a new and false message without the right private key. 26

However, anyone can generate a private/public key pair and impersonate someone else, so it’s essential to have some mechanism that binds the public key to the sender in a trustworthy way. This is where the digital certificates come into the picture.

Authentication deals with assuring that the message was in fact sent by the party who claims to have sent it. As mentioned above, each party in a SET transaction is authenticated by the use of digital certificates. These certificates are issued by a trusted third party known as a Certification Authority (CA), which vouches for the identity of the certificate holder. Each digital certificate contains both owner identification information, and a copy of one of the owner’s public keys. Furthermore each certificate is digitally signed by the Certificate Authority to ensure it’s validity. To administrate the validity of all certificates an hierarchy of trust has been constructed (see figure 3 below).

As illustrated in figure 3 there are a number of different digital certificates specified by the SET protocol. As mentioned earlier every party involved must have the appropriate certificates, so obviously both the cardholder, the merchant and the acquirer must have theirs. But this isn’t enough! The different Certificate Authorities (i.e. the cardholder, merchant, acquirer, brand and root Certificate Authorities) must also have theirs, and they are arranged in a tree of trust with the one unique Root CA as the base and origin of all the others (see figure 3). SET certificates are thus verified through this hierarchy of trust. Each certificate is linked to the signature certificate of the entity that digitally signed it. By following the trust tree to a known trusted party, one can be assured that the certificate is valid. For example, a cardholder certificate is linked to the certificate of the Issuer (or the Brand on behalf of the Issuer). The Issuer’s certificate is linked back to a root key through the Brand’s certificate. The public signature key of the root is known to all SET software and may be used to verify each of the certificates in turn. 27

Although the SET protocol has the potential of securing the financial transactions over the Internet, and thereby making I-commerce safe and attractive to the average consumer, it still suffers from some unresolved problems and issues. Most notable among these is the issue of interoperability between the SET applications developed by the different deliverers of SET software. Until this issue is resolved it’s not relevant to talk about an open standard regarding SET. Another problem is the issue of systems integration, which is especially complex for the merchants that wish to implement SET technology into there existing systems. Below we will take a closer look at these two issues.

Interoperability among different software vendor's of SET applications is a necessity if the SET protocol is to be widely adopted. As long as SET remains an open protocol it’s users (i.e. consumers/cardholders, merchants, financial institutions and certificate authorities) should be able to choose from multiple vendors for their SET software, and therefore it is critical that all the software vendor's products for SET work together flawlessly.

As of today this is not the case. In fact very few different vendor’s products are interoperable, and when they are, it’s only to a certain extent. Many issues still remain to be resolved, mainly because the SET Specification in itself is somewhat unspecified in certain areas and doesn’t cover the entire shopping process (e.g. SET-payment initiation, Order description content, communication port identification, Language support). To overcome these problems the SET vendor community has organized a task group (called I14Y), initiated interoperability testing projects and released a Set 1.0 Interoperability Test Plan.28 As part of this effort IBM has teamed up with VeriFone (a subsidiary of Hewlett-Packard) to make sure their respective SET software works together.29 These two companies have also released a Interoperability Reference Guide For SET 1.0 that describes their collective experience from their strivings.30 Although both these initiatives are applaudable, there still remains much to be done before all SET applications are truly interoperable. On top of these difficulties there is a new version of the SET protocol (version 2.0) on the way, which will require another round of synchronized implementation and interoperability efforts. Considering this it’s no doubt that the issue of interoperability is, and will remain for foreseeable future, the main obstacle that all developers and vendors of SET technology will have to face.

Besides the issue of interoperability there are other problem concerning the SET protocol. Considering the purpose of this research report, lets now take a look at the question of systems integration between SET software and the I-commerce systems already in use. But first it should be pointed out that his report will limit its scope to integration between SET applications and the systems that merchants use to create their Web-front stores, and to related backoffice systems such as order entry, inventory, invoicing and accounting systems. This focus has been chosen partly since it is the area that entails the greatest number of difficulties, and partly because it’s the main area of interest to the case study company, Jaybis AB, that has sponsored this research project.

During the test pilot implementations of the SET protocol around the world it has become evident that systems’ integration is a major issue.31 Experiences from the present Swedish test pilot project, where in the beginning only one out of the thirty participating companies had managed to fully integrate the SET software and get their store online,32 show that this clearly is an issue of importance. It should though be added that the technical problems, encountered by the mentioned Swedish companies, not only refer to integration issues. The issue of interoperability has in many cases contributed greatly to the difficulties and delays.33

As mentioned above, the main purpose of this reported research project is to map the problems of integrating SET software with the above mentioned legacy systems already in use by merchants. Although there are many different systems of this nature, it’s my belief that most of them have a great deal in common when it comes to this particular issue. Many of the main integration problems stem from the requirements that SET applications place on different flows of SET specified data, and from difficulties in integrating software components that are build using different programming languages and platforms.

Since this issue is the core purpose of this research project, it will be investigated and reported at length. The conclusions and further details are presented in chapter 5, which covers the systems integration between GlobeSET’s SET software and Jaybis E-com (i.e. the case study companies application for building Web stores and integrating these with related backoffice systems).

Besides the unresolved issues/problems reported above there has been quite substantial criticism of SET. This critique has been voiced from different camps, and has pointed out some interesting aspects and deficiencies of the SET standard. The main points are reported here bellow.

First of all, one of the major objections concerning the SET protocol is all the delays involved in the development and implementation of the standard. Already two years ago, Visa and MasterCard announced that they, together with a consortium of 11 technology companies, would make the Internet safe for credit card transactions and thereby pave the way for the full potential of I-commerce. With great fanfare, they introduced the SET protocol. Now, two years later the standard is still far from completion and the fanfare has become substantially subdued.

The delays have, together with all the technical difficulties and the high costs associated with the implementation of SET, made most merchants hesitant about adopting the standard. This thereby constitutes a real threat to the future success of SET, and if the delays should continue it’s quite possible that the standard will neither become truly accepted by the market, since the merchants will seek other more timely solutions to their needs for transaction security.

Another interesting objection is the question who the SET protocol really benefits the most. Is it the cardholders and merchants, or is it rather the credit card companies and their associated financial institutions that have the most to gain from SET? This is a most relevant question that has been voiced by parts of the merchant community that have investigated and in some cases invested in the standard.

On closer examination it stands quite clear that it’s the banks and card brands that have the most to gain, since SET is the only system that promises to protect their existing positions and market shares in the emerging era of Internet commerce. The competing solutions for financial transaction security ( e.g. CyberCash, First Virtual Bank, DigiCash) are proprietary and propose to replace the banks and credit card companies when it comes to payments over the Internet.

When it comes to the benefits for the merchants, it’s not as evident if SET really delivers any real advantages over other competing solutions, especially not after considering the cost-benefits analysis for the average online merchant. At least when it comes to the present, the costs associated with a SET implementation are simply to high for most merchants to be able to benefit from the standard, even if it were widely adopted by the Internet consumers (which it of course isn’t). But, it should be added that there are certain categories of merchants that stand to gain from SET. This is especially true for merchants that operate in countries where the banks don’t accept unsigned payment card transaction (e.g. Sweden), and where the use of SSL based credit card transaction thereby isn’t an available alternative. Today most of these merchants instead use CashOnDelivery (COD) and invoicing to finalize their financial transactions, despite all the disadvantages and limitations of these alternatives.

Finally, there is the question of what the consumers/cardholders have to gain from SET. This is also rather unclear, although there are some obvious benefits considering the high level of security that the SET protocol delivers. As long as the standard involves a customer side application and certificates that need to be downloaded and installed on the cardholders local machine prior to any purchases using SET, there exists a real obstacle to widespread adoption. Experience shows that anything that requires consumers to take an extra step deters them from adopting it.34 A solution to this problem could be the use of smart cards to contain the certificates and other necessary data, which would free the cardholder from his/here local machine and make SET portable.

Besides the above mentioned criticism there are some other weaknesses associated with the SET technology, two of the most notable being that it’s slow and expensive for the merchants to implement. Lets take a peak at these aspects.

The price for the higher levels of security that SET provides is that the transactions become quite slow. Lag times of up to 50 seconds have been reported for the processing of a typical cardholder initiated purchase request to the approval response from the acquirer and the finalization of the transaction by the merchants server (and this even in the controlled environments of SET pilot projects).35 This can hardly be considered acceptable for the average Web shopper, since one of the main advantages of I-commerce is that it’s supposed to be time saving and convenient. From experience anyone who has spent some time surfing the Web knows how frustrating it can be to wait for certain Site-pages to download. Commonly download times in the excess of 30 seconds are not recommended, not even for very attractive Webpages. Considering this it’s very unlikely that cardholders would find response times in the proximity of a whole minute acceptable. On the contrary it should be expected that anything over 15 seconds will probably be to long, especially since there (in today’s SET wallets) is little or no feedback to reassure and update the cardholder about the progress of the transaction processing. To make things worse, transactions using SSL (today’s most widely used alternative to SET) only takes a fraction of the time SET requires to process a purchase request. This could lead to misunderstandings for those that are used to Internet shopping using this alternative. They can be expected to be surprised and maybe even doubtful of the whole process if it takes much longer then they are accustomed to, and might simply cancel the process and move on to another site. This rather serious time lag issue could come to be resolved in the next version of the SET protocol (SET 2.0), since there exists plans to exchange the presently used RSA cryptography with another more efficient method called elliptic curve security, but this will take time and won’t become available in the next couple of years.36

Besides being slow for the cardholders to use SET is also relatively expensive for the merchants to implement. According to experiences during the Swedish SET pilot project the typical costs amount to around a quarter million SKr (equivalent to over 30 000 US$). Such high costs simply makes SET unprofitable for most smaller merchants, at least as long as their online markets remain relatively small.37 In the future this problem could be solved if Web-hosting companies start supplying SET enabled services for merchants to connect their storefront merchant server applications to.

To make things worse SET, in it’s present implementations, is neither portable nor completely safe for the cardholders. As mentioned earlier, the presently available SET systems are not portable for the cardholder, since they require both software and certificates to be installed on one of the cardholders local machines. This means that in order to shop using SET, the customer must have access to that particular machine. If he/she wishes to be able to use SET from some other computer (such as one at work) that machine must have not only a SET-wallet but also the required SET certificates. In other words a cardholder will have to download and install multiple certificates for each card he/she wants to be able to use over the Internet. Not very elegant or practical. However there exists a potential cure fore this problem to, and that’s the alternative of having the certificates and other necessary data stored on so called smart cards, which would free the cardholder from his/here local machine and make SET portable. There are numerous experiments in process at the time of writing, and especially the French have come a long way with what they call C-SET.38 Worth mentioning is also that the next version of SET (SET 2.0) most lightly will include the use of smart cards to solve this issue.

Although SET has been herald as the safest of all methods for securing financial transactions over open networks, it’s been pointed out that it’s not safe enough on the cardholders side. At least not as long as the cardholder certificates are stored on local machines protected only by a password. Even here the most obvious solution to this problem is the use of smart cards to safeguard the cardholder’s certificates.

From the above it’s quite clear that SET has both pros and cons. Now the question is if it’s going to become the standard of the future for I-commerce or not? Some say SET is simply too complex and expensive, others say it’s what is needed to make I-commerce safe and attractive for all parties involved. The fact is that as long as SET is backed by very powerful players that have much to gain on getting the standard widely adopted (i.e. card companies and banks), it stands an undeniable chance of being so. MasterCard and Visa have invested heavily in SET, both financially and status wise, and can’t be expected to abandon it in the first case. So, even if merchants won’t really want to implement the protocol, the financial community might come to force SET on them by manipulating the interchange rates merchants pay on their financial transactions. Presently, all card transactions over the Internet (e.g. using SSL) are placed in the highest risk category, called Mail Order/Telephone Order (MOTO) or Card Not Present (CNP), and thereby carry the highest interchange rate.39 By offering lower interchange rates on transactions that use SET, the merchants can come to be enticed to adopt the protocol, even with it’s limitations.

Now that we’ve covered some of the basics concerning Internet commerce and the pros and cons of the SET protocol, it’s time to survey the developers/vendors of SET technology. In this report we will limit our focus to the developers/vendors of SET software intended for merchants. However most of these companies also market products for cardholders, acquirers and certificates authorities, so the interested reader should be able to find useful references even for these other products. This chapter starts with some methodological considerations concerning the survey, followed by the main part that includes descriptions of all the ten relevant developers/vendors of SET software. A structured comparison between these companies and their respective products is then supplied, followed by some final conclusions.

The first natural step in conducting this survey of SET software developers/vendors was to find them. This was facilitated by the fact that the SET protocol is so new and complex that rather few developers have entered the market. The search was further aided by the role MasterCard and Visa play in the development of SET. Both companies have Websites that supply relevant information about the protocol and references to the other companies that are involved in it’s development and implementation.40 Furthermore, this spring they (together with the rest of the SET consortium) established a new independent organization, called SETCo, that is to be responsible for the SET standard itself and for the certification of SET compliant software products. SETCo’s Website includes a list of all the products that have enrolled in the SET Compliance Testing program.41 All in all ten different suppliers of merchant SET applications where thus located, including: RSA, Terisa, GlobeSET, VeriFone, IBM, Trintech, Maithean, CyberCash, Brokat, and OpenMarket.

Having located all relevant developers/vendors, the second step was to find out more about their respective SET products. This turned out to be more difficult then the first step. Although all companies had some Web-based information concerning their products, it was in most cases very short and shallow and therefore not adequate for the purpose of this survey. Consequently I had to contact the appropriate representatives for each product, which in turn turned out not be altogether easy either. Many where unexpectedly hard to get a hold of, and not always very informed about the products, once they were reached. However, I managed to get the software from two of the relevant suppliers, GlobeSET and Verifone. RSA, IBM and Trintech sent me some software documentation (but no software) that was helpful. Terisa supplied me with direct telephone access to there technical support, so that I could get the detailed technical information I needed. Maithean was contacted, but didn’t send any documentation except pricing information. CyberCash had a relatively informative Web-site, and therefore didn’t need to be contacted. Brokat and Open market were not contacted either due to their product’s platform depends, which render them less relevant since they can’t be integrated with other merchant I-commerce servers them the ones that the respective company supplies themselves. Now, lets take a look at the SET merchant developers/vendors and their products.

Alright, lets now examine the different SET software products available for merchants to SET-enable their Web-front stores. In order not to overload you with detailed information, I have striven to keep the respective descriptions short (in most cases less then one page each). As this might be a little on the short end for some readers, references to relevant sources have been supplied so that further information can be obtained if requested. However, in a few cases I’ve elaborated the description somewhat, in order to supply enough information for the average reader to be able to grasp the technology behind the systems involved. This is especially true in the case of VeriFone vPOS.

RSA has chosen to supply developers with toolkits designed to simplify SET application development, rather than to supply finished SET applications. They offer three different SET toolkits (each optimized for cardholder, merchant and acquirer gateway applications respectively), which build on the same core of cryptographic and SET message object libraries. With a high-level API, the S/PAY framework provides a complete SET transaction engine, including a C library of object modules for all the standardized SET messages. S/PAY’s object libraries also include certificate handling, SET transaction management, an interface to smart cards and crypto accelerators. The toolkits ship with sample code that illustrate how to build a complete application, and tools to debug and test it.42

In April 1998 RSA announced an agreement to license the S/PAY developer’s suite and related technology exclusively to Trintech. The new alliance is hoped to strengthen the market position of the two companies by integrating RSA’s S/PAY into Trintech’s range of secure e-payment applications. Besides implementing SET, Trintech will incorporate the functionality of S/PAY to include other payment types in current use, such as micro payments, electronic checks and cash cards. RSA and Trintech have previously collaborated on developing standards and technology for enabling secure payment applications for electronic commerce, and Trintech was one of the first customers of the S/PAY product which Trintech used to develop its secure e-payment applications PayPurse, PayWare and PayGate.43

Terisa also supplies toolkits, similar to those RSA now licenses to Trintech. The product that is most relevant to this survey is SecureWeb Payments™, which is an add-on module to Terisa’s more generic toolkit called SecureWeb Toolkit. The latter toolkit gives developers the tools needed to make implementations of the widely used WWW security protocols such as S-HTTP and SSL. The add-on module SecureWeb Payments supplies the technology needed to implement the SET protocol. It contains code/modules for secure key databases, certificate management systems, and the RSA BSAFE™ cryptography engine. It’s also shipped with sample application code.44

GlobeSET POS™ is the merchant side application of GlobeSET’s comprehensive SET software solution called GlobeSET Payment System.45 The latter also includes all the three other applications needed for a SET transaction, i.e. the GlobeSET Wallet™, GlobeSET Gateway™ and GlobeSET CA™ applications (see figure 4 below for their relation to each other).

GlobeSET POS is a SET payment server application that connects the merchant to the customer/cardholder’s electronic wallet and to the financial institution’s payment gateway. The application handles all the necessary merchant messaging for SET purchases. It accepts Web-based purchase requests from cardholders, generates payment authorization and funds capture requests to the payment processor, and returns purchase responses to the cardholder. It also supplies a Web-based graphical administration interface, for easy access by the system’s administrator where ever he/she may be.

Furthermore it supports multiple merchants and acquirers on each server, and can be modified for custom implementations with any merchant storefront application through an SDK (Systems Development Kit). Worth noting is that GlobeSET POS is the first SET merchant application to successfully pass the SET 1.0 compliance tests governed by SETCo and be given the right to use the SET Mark46, indicating that it’s well on the way concerning the key issue of interoperability. As this application was chosen for the test implementation of this research project, it will be quite thoroughly described in the next chapter (see section 5.2 below), and therefore needs no further description here.

A similar product to GlobeSET POS is VeriFone vPOS developed by VeriFone, a subsidiary of Hewlett-Packard. Besides the vPOS application, VeriFone also develops applications for both cardholders (vWALLET) and financial institutions (vGATE), as parts of it’s Internet Payment solutions47, and these applications interact in a fashion similar to the applications in the above described GlobeSET Payment System.

In order to better understand what the vPOS application consists of and how it operates, I have chosen to include two illustrations which summarize these aspects well. Figure 5 high-lights the three major components that the vPOS consists of, i.e. the Payment Module, the vPOS Engine Service and the Terminal Interface (all within the blue quadrant). The figure also depicts the two other SET software products from VeriFone (vWALLET and vGATE) and how they relate to the vPOS.

Although figure 5 gives an overview of the vPOS and it’s related products, it still doesn’t explain how the application operates, nor how it can be integrated with the merchant Web-store and legacy systems. As an attempt to overcome these shortcomings figure 6 has been added. Figure 6 focuses on the components and processes involved in a typical purchase transaction. Therefore the vPOS component called the Terminal interface has been left out, as it’s only used to administer the vPOS and to handle post-sales transactions such as captures, reversals and credits. Lets now take a closer look at the components and processes involved (see figure 6).

The gray colored components are applications that are part of the VeriFone’s Internet Payment solutions. The vWALLET is a plug-in to the cardholder’s Web browser, and is activated by the vPOS’s Payment Module ones the cardholder has browsed through the merchants site and decided that he/she wishes to purchase something using their SET certificates (the "I want to pay!"-arrow in the figure). The vWALLET then sends a Purchase Initiation Request (the SET specified message called PInitReq for short), which is the first message specified by the SET protocol. All the red colored arrows/texts represent SET messages that the software automatically generates and transmits between the different SET applications involved.

The only additional information flows needed are the ones generated to supply the Payment Module with enough information for it to be able to generate the appropriate SET messages. This need is satisfied by a special component called the Merchant System Component (MSC), which is custom built to be able to request and receive transaction related information from the merchant Webstore and it’s associated legacy systems (see the blue text in the figure). This transaction information includes details such as purchase amount and a description of the goods and services ordered (GSO). In other words, the MSC is the main issue when integrating the vPOS with a merchant’s other I-commerce related systems. All the integrator has to do is build an appropriate component that takes care of the transmission of the required transaction information. A task that is facilitated by the small high-level API which is supplied with the VPOS application, that the system integrator uses to implement the MSC.

IBM also supplies a suite of SET applications which they call IBM CommercePOINT Payment, and it includes a merchant application called eTill. The application suite is composed of a similar set of components as the ones supplied by GlobeSET and VeriFone, and they also interact in the same way (see figure 7 below).

As illustrated in figure 7, IBM supplies four SET applications (i.e. IBM CommercePOINT Wallet, eTill, Gateway, and the IBM Registry for SET CA). Also illustrated in the figure are the SET messages that flow over the Internet between the different SET applications. Both the Wallet and the Gateway operate much in the same way as GlobeSET’s and VeriFone’s respective products, and do therefore not command any further comment here.48 Concerning the issue of system integration between IBM’s eTill and a merchant’s other I-commerce related systems, the processes is very much aided if the merchant in question uses IBM’s own I-commerce software, IBM NetCommerce Merchant Server. In that case the integration is more or less plug-and-play, since eTill comes with a complete interface to this software. If, on the other hand, the merchant by chance doesn’t run his/her Web-store on IBM’s software, it’s still possible to use the eTill application, but it requires a special component (called a "cassette" by IBM) to be built. This "cassette" operates in much the same fashion as the MSC-component used in the VeriFone case. However, since it would require quite extensive elaboration to describe the specifics of the integration technology used in these "cassettes", no further description will be delivered here.49

Trintech is a financial software company specializing in the provision of card payment and electronic commerce solutions to the banking and retailing industries. Just like their competitors, Trintech supplies a suite of SET applications including a cardholder wallet (PayPurse™), a merchant application (PayWare for Internet (SET)™), and a gateway (PayGate™).50 See figure 8 here below.

As illustrated in the above figure, PayWare handles both SSL and the SET standard. This allows merchants to accept orders from customers that don’t have SET certificates, but still wish to purchase using their credit card. Besides the SSL compliance, PayWare basically resembles the other SET merchant applications supplied by the above reported competitors. That is the application is composed of both a SET engine that processes the transactions, and a graphical user interface (GUI) for the configuration and administration of the PayWare application.

Trintech has developed PayWare to integrate tightly with the merchant servers provided by Microsoft and Netscape.51 Hence, as long as the merchant runs his/here Web-store on one of these merchant servers, it’s rather simple to install and integrate Trintech’s SET application. The integration interface between the merchant server and PayWare vary depending on which merchant server that is being used. In the case of Microsoft the interface employed follows the common object model (COM), and in the case of Netscape the interface employed is based on the LiveWire development environment.52 If the merchant system builds on neither of these two merchant servers, it’s still possible to integrate PayWare since Trintech supplies a high-level API to permit integration with any merchant server on the market. This API defines both the message types needed to supply the PayWare application with the necessary transaction information (e.g. amount, order description), and the message types required for PayWare to generate and return certain information to the merchant server (e.g. an order identifier).53

Maithean, Inc., specializes in providing software for secure electronic commerce, transaction processing and electronic data interchange (EDI). The company’s main product, NetPay™, is an integrated secure electronic system that, besides supporting SET, also supports electronic billing, home banking and EDI applications. The part of NetPay that implements SET is a suite of applications called NetPay Payment System™, which consists of three applications (NetPay Wallet™, NetPay Merchant™ and NetPay Gateway™) similar to those of their above described competitors (se figure 9 below).

NetPay Merchant is a comprehensive payment authorization, settlement and management system that enables merchants to manage electronic payments. It supports traditional payments to processors via SSL, dial and lease line as well as SET. NetPay includes a comprehensive call center with integrated customer service and administration applications for credit-return management, transaction management and report generation. The system supports payment aggregation, recurring payments, loyalty, stand-in authorization and private label credit cards. The product works in concert with industry standard shopping catalog products such as Intershop, iCat, Oracle ICS and Microsoft Commerce Server.54 It can also be integrated with other merchant server systems for I-commerce via a supplied API, but since Maithean has failed to supply me with any further information, there will be no more details reported here on how this can be done.

CyberCash is a company that specializes in providing secure transactions of virtual payments for the Internet. They supply a range of alternative payment methods, including CyberCoin™ (electronic cash) for micro payments, PayNow™ (electronic checks) for payments directly from a checking account, and Credit for secure credit card transactions.55 These payment services are all supported by the CyberCash Secure Internet Payment Solution which consists of a consumer wallet (CyberCash Wallet), a merchant application (CyberCash CashRegister), and a payment gateway for financial institutions (CyberCash Payment Gateway).56 In the present version of this system the wallet is optional for a credit card paying consumer, as he/she can choose to enter the card information directly and have it transmitted via SSL to the merchant.57 The most interesting aspect of CyberCash’s system is the fact that it supports the three different forms of payment services mentioned earlier. To date, none of the system components supplied by CyberCash have been SET enabled. However, all will be released in new versions, and these new versions have all been submitted to SETCo for SET compliance testing.58 So in the future CyberCash might become an attractive alternative to other SET developers/vendors, since the company’s policy is to never charge it’s merchants for the systems needed. The costs are instead covered in the transaction fees charged by the financial institutions that offer CyberCash enabled accounts.

CyberCash offers three different alternatives when it comes to having their CashRegister integrated with a merchant’s Web-store. Either one of their so called Merchant Development Partners (MDP) can take care of it all59, or the merchant can chose to build the Web-store using an I-commerce application or store builder solution in which CyberCash is already integrated.60 Finally, if the merchant already has a Web-store, and it hasn’t been built using any of those alternatives, it’s still possible to integrate the CashRegister, but it requires some technical expertise (i.e. knowledge of Perl, C++, and HTML).61

Brokat is a German based competitor in the same niche of the software industry as Maithean. All the solutions that Brokat supply are based on a modular I-commerce platform called BROKAT Twister 2.0. This is a CORBA/IIOP based transaction system that enables secure solutions for both Internet banking, brokerage, and payments.62 The specific Twister 2.0 application that handles SET payments is called X^.PAY Electronic Payment. Besides handling SET credit card payments, X^.PAY also provides support for debit payments such as electronic debit notes, and various customer and cash cards. Furthermore the application is characterized by an open and modular architecture, which allows for rapid integration of any additional or future payment methods.

The X^.PAY Electronic Payment architecture is similar to the other SET application suits reported above. In Brokat’s case it consists of three applications: X^.PAY Wallet, X^.PAY Server and X^.PAY Gateway. The X^.PAY Server provides the merchant with a point of sale software and allows various merchant systems to be linked to the same server. The application receives the order and payment information from the consumer and communicates with the X·PAY Gateway for the authorization of payments. In the future, the use of the X·PAY Server will only be necessary if the merchant does not already have a SET system component. Furthermore, the integration of new payment methods into the payment system does not require the X·PAY Server or another SET merchant component to be replaced. As mentioned, this application like all Brokat’s products, is based on the BROKAT Twister 2.0 platform, and therefore requires this platform to operate. It can therefore not be integrated with any merchant system that does not have this platform installed.

Openmarket supplies an I-commerce platform product called Open Market Transact. This product manages Internet commerce and offers a wide range of functionality such as: complete order management, online customer service, security, authentication, record-keeping, flexible purchasing and payment models, and secure transaction processing, including sales tax and shipping charges.63 As such, Transact is a complete system for end-to-end I-commerce services, and thus not a SET enabled merchant application that can be integrated with any other merchant server application. Openmarket has enrolled Transact 4.0 in the SET certification and testing program, but has not to date been approved.64

Now that we have had a closer look at the different players in the SET technology market and their respective products, it’s time to analyze the similarities and differences of these products. In order to facilitate such an analysis and make it concise, a structured comparison will be presented. This comparison focuses on a set of aspects that can be considered relevant when selecting an appropriate supplier of SET technology that is to be integrated with another developer’s I-commerce server application (such as the one reported in the case study below, see chapter 5). These aspects are: 1) type of product, 2) supported merchant I-commerce servers, 3) integration interface for not supported merchant servers, 4) complexity of integration, 5) SET compliance testing status, 6) price.

Before presenting the summarizing structured comparison (in section 4.3.2), the mentioned aspects are explained and examined closer here below.

As we have seen from the descriptions of the SET products above (in section 4.2) it seems as if there exists quite tangible differences between some of the products. RSA and Terisa both deliver toolkits that are intended to facilitate the development of SET compliant applications, but they supply no complete SET applications for SET participants such as merchants. Such applications are supplied by the other developers/vendors of SET technology (i.e. GlobeSET, VeriFone, IBM, Trintech, Maithean, Brokat, CyberCash, Open Market). However, although all the others supply some kind of SET applications for merchants, not all these applications are fully comparable. This is especially true for both Brokat X^.PAY Server and Open Market Transact 4.0, which both build on non-standard, proprietary I-commerce platforms that the two companies supply. In other words, these two SET compliant products can’t be integrated with any merchant server application that doesn’t build on these respective platforms. I propose to refer to these kinds of SET applications as platform dependent (PD) in the comparison below. CyberCash is also different from the others since they don’t sell any products. Instead they provide a range of payment services (soon including SET), so I propose to define them as SET service providers (SSP) in the comparison. The rest of the application suppliers I propose to call just that, application providers (AP). RSA and Terisa will be defined as toolkit providers (TP).

This aspect has been included to high-light those applications that have been developed to integrate with certain merchant servers such as Microsoft Commerce Server 2.0, Oracle Internet Commerce Server, and IBM Net.Commerce. Since these applications come with complete system integration, they are very easy to install on the specified merchant servers. There is, in other words, no need for any special system integration process in these cases, and I have therefore chosen to call this aspect Plug-and-Play support (P&P-supported I-commerce servers) in the summarizing structured comparison below (see section 4.3.2).

In the cases where the SET merchant applications do not come with a complete integration, and in the cases where some other merchant server is used by the merchant than the server/s that is/are supported by the SET application, there exists a need for some kind of integration interface to support the system integration process. Most developers/vendors supply some kind of application programming interface (API) to accommodate these situations. These API’s are in most cases small and rather high-level. They mostly consist of a number of functions that need to be implemented in order to supply the SET transaction engine with the transaction information needed to complete the SET purchase transactions.

However, this is not the case when it comes to the toolkits supplied by RSA and Terisa. These are much more complex since they are intended to be used to develop entire SET applications, and thus come with much larger API, plus substantial C-libraries. The products from Brokat and Openmarket also differ from the rest, but in the opposite way. They simply don’t come with any integration interface, since they are only intended to be used in concert with the I-commerce products that the two companies market.

The API supplied by the developers/vendors are in most cases small and rather easy to implement. However, they do require advanced programming skills and knowledge of transport protocols such as HTTP and MIME. Therefore I have chosen to classify them as medium on the scale of integration complexity.

RSA’s and Terisa’s toolkits, that come with complex API and extensive C-libraries, are much more complicated to implement, and are thus classified as high on the scale of integration complexity. This is, however, some what misleading since these toolkits are intended to be used to build completely customized SET applications from scratch, and therefore should not be directly compared with the SET merchant applications delivered by the other companies.

This aspect states the SET compliance testing status as reported by SETCo at the time of writing this report (July 20 1998). SetCo categorizes products as enrolled, pending approval, or approved. Enrolled applies to all products for which legal agreements have been signed and testing software has been shipped. Products pending approval have had their test results submitted to Tenth Mountain Systems, and approved products have passed the compliance testing and have been awarded the license to display the SET™ Mark.65

Finally, we have the last but not least interesting aspect of the SET products, that of the price of each products. The reported prices in figure 9 refer to the price of a installation with one individual merchant’s Web-store. Furthermore, it should be mentioned that the quoted prices are approximate. The precise price depends on purchase volume and other aspects that are relevant in each specific case. The reader is recommended to personally contact those suppliers that are of interest.

A special note should be added for the prices of the toolkits supplied by RSA and Terisa. Since these products are intended for the development of SET applications they entail both a price for the development license for each toolkit’s use (RSA’s S/PAY Developer Kit: 5000 US$, and Terisa’s SecureWeb Payments: 65000 US$), and a royalty charge for every SET application sold that has been developed using the toolkit (RSA: 195 US$ per sold copy, and Terisa: 2% or minimum 100 US$ of the price of the sold SET application).

This section presents a summary of the similarities and differences between the surveyed SET systems/applications. With the aspiration of making such a summary as concise and useful as possible, it will be presented in the form of a structured comparison table (see table 1 below). The table reports how all the individual developer/vendor’s products rate on the above defined aspects (see section 4.3.1). As all the variables included in the table have already been explained and the table therefore pretty much speaks for it self, I now leave you to it with no further comments.

	Type	P&P-supported I-commerce servers	Integration interface	Integration complexity	SET- status	Price
RSA	TP	-	API and C-libraries	High	-	5000 $+195 $
Terisa	TP	-	API and C-libraries	High	-	65000 $+2%
GlobeSet	AP	none	small high-level API	Medium	approved	1000 US$
VeriFone	AP	MS Commerce Server + Oracle ICS	small high-level API	Medium	enrolled	2000 US$
IBM	AP	IBM Net.Commerce + Lotus Domino.Merchant	tailored API	Medium	enrolled	2000 US$
Trintech	AP	MS Merchant Server 1.0 + MS Commerce Server 2.0 + Netscape 1.6	small high-level API	Medium	enrolled	N/A
Maithean	AP	MS Commerce Server + iCat + Oracle ICS + Intershop	small high-level API	Medium	enrolled	11000 US$
CyberCash	SSP	-	(perl, C++, HTML)	Medium	enrolled	0 US$
Brokat	PD	Brokat Twister 2.0	-	-	enrolled	N/A
OpenMarket	PD	Open Market Transact	-	-	enrolled	N/A

The conclusion that I wish to draw from this market survey of SET merchant software suppliers, relates to the second research task of this master thesis, i.e. the test implementation of a suitable SET software with the case study merchant I-commerce server developed by Jaybis called Jaybis E-com. The conclusion concerns which SET software to chose for this task.

RSA’s and Terisa’s toolkits can be sorted out first, since they are far to complex and expensive for the task in question. According to the person I spoke to at Terisa’s technical support department, it take several man months to build a SET application using their toolkit, even if you have routined personnel to do the job. Brokat’s and Open Market can also be ruled out at ones, since they do not supply applications that are intended to be integrated with any other I-commerce servers then their own. Finally, CyberCash is also sorted out, because their product is dependent on the use of their services.

This leaves the five application providers GlobeSET, VeriFone, IBM, Trintech and Maithean. Since naturally none of these SET applications provide support for Jaybis E-com, there is no obvious candidate based on this aspect. On the contrary, there is no reason to pay for any support for any of the other I-commerce servers that most of the SET applications provide. GlobeSET’s application is the only pure OEM product66, and thus has no P&P-support for any special I-commerce server/s. Furthermore, it is of great value if the chosen application is SET compliance approved by SETCo, which only GlobeSET POS is to date. Due to these factors, I have selected GlobeSET POS for the test implementation which is reported in the next chapter (see chapter 5).

Now that a proper foundation has been lade in the form of the above reported background information, and a SET application has been selected for testing, it’s time to get into the details of how to integrate SET technology with a merchant I-commerce server application. But, before we dwell into the integration process itself, it’s vital to have an appropriate understanding of the two products that are to be integrated. This chapter therefore starts with an overview of the case study I-commerce application, Jaybis E-com (see section 5.1), and a closer examination of the selected SET application, GlobeSET POS (see section 5.2). The SET integration process is then reported in three sections that reflect the classical system development method employed for the test implementation; analysis & design (section 5.3), implementation (section 5.4), and finally testing(section 5.5).

Jaybis E-com is an I-commerce application designed as a complete "CyberMall" frame-work. It can thus serve everything from simple file-based catalogs with e-mail order messaging, to fully developed order-entry systems with EDI support and connections to in-house databases. The system can be seen as composed of three major components: the Jaybis client, the Jaybis E-com Server Extension, and a Web-based interface for system administration and catalog maintenance (see figure 10 here below).

The customer/buyer interfaces the system via their Web browser. When a Jaybis E-com powered site-URL is reached, the Web browser downloads the Jaybis client functionality, which is based on Java applets. This functionality includes: a shopping basket to keep track of selected products/services; a control panel with command buttons; a navigation tree for orientation in the selected catalog, and a client-server communications API (called Openshop) for secure transmission of transaction and business data. The control panel and the navigation tree is illustrated in the figure below (see figure 11) that depicts the Jaybis client interface as it looks like when a customer browses a merchant’s catalog.

As illustrated in the figure the navigation tree shows the contents of a catalog and helps orient the customer who is browsing through it. The control panel contains a number of buttons that activate diverse functionality in the Jaybis client such as access to the shopping basket. In the main area between these two frames, the selected catalog page is displayed.67

On the server side Jaybis E-com is implemented as a server extension (i.e. a DLL) to Microsoft Internet Information Server (IIS), which is Microsoft’s Web server. The extension handles the communication between the Jaybis client and the merchant’s back-office systems and channels the administration & catalog maintenance data between the administrator’s Web-based interface and the rest of the system. Jaybis E-com is developed to interface back-office systems from more or less any supplier. However, to start with Jaybis will only supply support for IMI’s System ESS, and for a in-house developed stand-alone system.

As Jaybis E-com is a highly customizable I-commerce application, it also needs some kind of interface for the systems administrator to access and configure the system. With Jaybis E-com this is done via a Web browser interface. Technically this interface is built using a server side scripting technology developed by Microsoft called Active Server Pages (ASP). Since this technology also was selected for my test implementation (reported in section 5.4), there will be no further presentation here.

In order to better understand the operation of Jaybis E-com, we will here take a look at the flow of activities carried out for a typical purchase using the system. To illustrate this process figure 12, that depicts the main activities of the purchasing process, has been added.

In the current first version of Jaybis E-com, which is primarily intended for business-to-business I-commerce, the customer is expected to be have a user name and password to be able to access the online ordering system. Therefore the first activity is the entering of these data, which are verified with the merchant’s customer database (Log on, in figure 12). After the customer has successfully logged on, he/she can start browsing the catalog/s and select any number of products desired (Shop, in figure 12). When the customer is finished shopping, they enter the shopping cart and accept the list of products specified to order there (Accept order, in figure 12). This invokes a final order page which contains the information available about the customer (including billing and shipping addresses). The customer checks that all these data are correct and then confirms/sends the order (Check info + Send order, in figure 12). The order is then directed to the merchant’s back-office system for order fulfillment, and the customer is directed to an order confirmation page, which he/she is prompted to print or save for future reference to the transaction.

It should be added that this illustration and verbal description gives a purposely simplified view of the functionally that Jaybis E-com possesses. Amongst other things, it ignores how the shopping experience is dynamically generated and presented using server based scripting. However, the illustration captures the flow of the main customer interaction activities, that are of relevance when a SET application is to be integrated with the system (see section 5.3 for more details on this topic).

This section presents the selected SET merchant application, GlobeSET POS, which is to be test implemented with the case study Merchant I-commerce system, Jaybis E-com. We will take a look at both the components/interfaces of the GlobeSET POS application, and the message flows generated during it’s operation. Finally, we will also examine the integration interface (called the SDK) provided for integration with I-commerce servers.

GlobeSET POS is composed of both network interfaces, database tables, and internal functional components such as the SET engine.68 To clarify this rather complex combination, an illustration has been added (see figure 13 below).

The main component, illustrated in the system architecture of the product, is obviously the GlobeSET POS itself. In addition to the POS component (that in itself is composed of a number of sub-components, such as a SET engine, that aren’t shown in the figure), the product also consists of three network interfaces and a number of database tables. The database tables contain both configuration data such as keys and SET certificates, and transaction data for all SET transactions that have been processed using the system. The database tables are created during the installation, and requires that a supported SQL database is installed on the merchant system. 69

As illustrated in figure 13, GlobeSET POS interacts with other SET applications (i.e. Wallet and Gateway) using the SET protocol. However, the illustration omits that this is done through a special network interface, called the SET interface. The SET interface consists of a TCP/IP server port that accepts HTTP-encapsulated SET messages from the cardholder, and sends HTTP-encrypted SET messages to the acquirer’s gateway. Besides the SET interface, GlobeSET POS possesses two other interfaces, which are better depicted in the figure. These are the SDK/Shopping Interface and the Administration Interface. The SDK/Shopping Interface provides a mechanism for the integrated I-commerce system to initiate a purchase transaction (how this is achieved is covered in section 5.2.3 below).

The Administration Interface is a Web-based interface (see figure 14) to the Administration manager, which provides access to several of the GlobeSET POS’s features. This interface allows general administration and configuration of the POS, including task such as: starting/stopping/resetting the POS server; adding/deleting merchants and monitoring the status of current merchants; configuring the server’s logs, URLs, ports, and databases.70

The Administration Interface also allows for manual processing of batch and transaction activity such as initiation of SET capture messages transactions, and reversal or credit transactions. This facility is especially useful in cases where the merchant doesn’t want to fully integrate the SET application with his/here back-office systems, since the administration interface permits a separate treatment of these transactions.71

Now that we have been familiarized with the components and interfaces of GlobeSET POS, it is time to take a glimpse under the hod and explore the message flows that occur during a purchase transaction using the system. Since this is best done with the help of an appropriate illustration, figure 15 has been supplied here below.

The figure illustrates the message flows for a typical SET purchase transaction. The messages that are transmitted remind very much of the ones that were reported for the competing product VeriFone vPOS (see figure 6 in section 4.2.4). However, there are a number of differences. When using GlobeSET POS, the I-commerce system has to channel the "I want to pay! "-message and generate a SDK Call to the SDK.72 Before the SDK sends a Wakeup to the Wallet, it first sends a Kickoff-message to the POS with all the transaction data needed to generate the "set-payment-initiation"-message, which is then channeled through the Kickoff Response and the Wakeup Wallet to the Wallet. Once the Wallet receives this message it starts the real SET-messaging (in red in figure 15) between the SET applications (i.e. Wallet, POS, and Gateway).

Although the illustration in figure 15 reveals the main messages generated when operating the GlobeSET POS, it reveals neither the order of these messages, nor all messages that pass between the POS and the rest of the system. Since this message flow is at the heart of the process when it comes to integrating the POS with Jaybis E-com, it deserves a thorough examination here. Figure 16 below illustrates all the messages related to the POS and the rest of the systems and the order in which they are invoked.

The above figure reveals four messages that where not illustrated in figure 15: the "Launch Wallet"-, "Asynchronous Completion Message"-, "HTTP/1.0 200 O.K."-, and the "Success/Failure URL"-messages. Lets now take a closer look at each of these and the other non-SET messages (the arrows with thin black broken lines in figure 16).

The first message in the flow that impacts the integration process is the "Decision to pay! "-message that is launched after the customer has browsed the Web-store and selected something to buy. Under the condition that the payment alternative the cardholder selects is the SET-payment alternative, the I-commerce system needs to connect to and transmit the request to the GlobeSET POS. This is done by generating a purchase operation call to the SDK (how this is done will be covered in section 5.2.3 below), and when the SDK receives this call, it channels the request and all associated transaction information to the POS in the form of the "Kickoff"-message. The POS then uses the request data as input to generate the message that is required to activate the SET wallet application (which the cardholder will use during the SET payment process itself). However, the POS will not activate the wallet directly. Instead, this is done by the I-commerce system after it has called the SDK to retrieve the "Kickoff Response"-message sent back from the POS, and after this response has been reformatted into the appropriate MIME format (with the content type: "application/set-payment-initiation"). Now, the "Wakeup"-message can be sent to the cardholder’s browser, which in turn sends the "Launch Wallet"-message to activate the SET wallet.

Once the SET wallet has been launched the messaging involved in the SET purchase transaction itself is automatically generated and transmitted by the POS and it’s associated SET applications (i.e. the wallet and the gateway). These message flows are high-lighted in red in figure 16, and since they do not affect the integration process itself, they will not be commented on any further here. Instead, we shall have a closer look at the four remaining non-SET messages that GlobeSET have included to facilitate the integration of the POS with any I-commerce system.

In figure 16, three of these non-SET messages have been illustrated as launched before the last SET-message (PRes) is transmitted. However, this is somewhat misguiding since the so called "Asynchronous Completion Message" (and it’s associated SDK Calls and "HTTP/1.0 200 O.K."-message) do not really affect the execution of the PRes. The purpose of the "Asynchronous Completion Message" is to facilitate the integration process with the merchant’s I-commerce backoffice systems, by sending a HTTP message (POST or GET) with the authorization response to the I-commerce server for further processing. Based on this response the I-commerce server can execute aspects such as updating the on-line order from a preliminary state to the state of an actual order booking, and have it entered in the backoffice system for order management and fulfillment.

The final message in the flow is the "Success/Failure URL"-message. This message is in fact a pair of URLs that redirect the cardholder back to an appropriate Web-page on the merchant’s I-commerce system after the SET Wallet is closed. The success page can be used to display a detailed receipt with all the relevant data of the transaction, which the customer can be prompted to save or print. The failure page is most appropriately used to inform the customer about the nature of the problem that caused the SET transaction to fail. It could also contain information to reassure the customer that nothing will be charged to their account.

In order to facilitate the integration with merchant I-commerce systems the GlobeSET POS application comes with a system development kit (SDK), through which the merchant I-commerce system and the GlobeSET POS can communicate. The SDK includes a small application programming interface (API) to access the functions it contains, plus sample code (in C) that illustrates how the SDK can be implemented.

The SDK supports the ten basic operations specified by the SET protocol73, and each such operation must be implemented by the systems integrator if it is to be called from the merchant I-commerce system. The implementation is done using the supplied API and a special context object (the MposContext object), which conveys the transaction information data between the POS and the I-commerce system. After having initialized the SDK using the function mposInit( ), the I-commerce system calls the necessary functions to create a MposContext object and sets the required transaction information data that the POS needs. The context is then dispatched to the POS using the function mposContextDispatch( ), which also accepts and parses the response from the POS. After the operation has been processed by the POS and a non-error response has been received by the SDK, the I-commerce system can access the returned data using a function called mposContextGetField( ).74

To summarize, the SDK thus both composes and transmits operation request messages from the I-commerce system to the POS. The SDK then waits for the POS to process and respond to the request. Finally the SDK receives and parses the response from the POS and makes it available to the I-commerce system via predefined fields in the MposContext object.

In this first part of the main system integration report we will focus on a high-level design description, with the intention of targeting the adjustments needed to the I-commerce system Jaybis E-com, and with the intention of illustrating how the systems could be integrated. We therefore start by presenting a flow description of a typical SET shopping process (section 5.3.1). Then, by comparing this flow description with the shopping process flow of Jaybis E-com presented in section 5.1.4, we will specify the adjustments that need to be done to Jaybis E-com (section 5.3.2). Finally, in section 5.3.3, a more detailed high-level description is presented for how the two systems can be integrated.

Here below, figure 17 depicts a high-level illustration of the shopping process flow for a typical SET purchase transaction, using a merchant I-commerce system that is SET enabled by a SET merchant application such as GlobeSET POS.

The above figure attempts to illustrate the main activities of the shopping process seen from a customer’s perspective, and therefore starts with the activity where the customer browses through the catalog and selects the products he/she wishes to purchase (Shop, in figure 17). Once the customer is finished with this first activity, and assuming that something has been selected for purchase, the second activity is for the customer to order whatever has been selected. This activity often involves the generation of order page, with a listing of all selected products, which the customer can check and then accept (Accept order, in figure 17). The third activity (Enter shipping information, in figure 17) has been included since many SET purchasing customers could be expected to be anonymous to the merchant system. As such, the system will have to prompt the customer to enter the billing and shipping information needed to fulfill the order. However, this activity would probably be necessary even for systems that are designed to support both anonymous and established customers, although the system in those cases probably would have the customer data pre-entered for established customers. All these customers will have to do is simply to confirm the data or change whatever needs changing. Once all the transaction information thus has been supplied and checked, the customer needs to select the form of payment he/she wishes to utilize (Select payment, in figure 17). This choice could involve any number of alternatives the merchant wants to support besides SET, including common forms such as SSL, invoicing, and cash on delivery. The activities applicable to any of these other alternatives has been left out of the illustration, since it focuses on the activities for SET purchasing. Assuming the SET payment alternative is selected the I-commerce server passes the control to the SET applications for processing of the transaction. During this process the customer interacts with the system via his/here SET wallet application (SET-wallet, in figure 17). After the SET transaction is terminated, the SET-wallet redirects the customer’s browser back to the merchant’s I-commerce server. Since a SET transaction has three possible ways of being terminated (success, cancellation, or failure), three different Web-pages are needed to appropriately affirm the finalization of the transaction. In the case of success, it is appropriate to display some form of a receipt page, which the customer can print or save for future reference. If the customer did decide to abort during the transaction, there should be a cancellation page which assures the customer that everything is alright and that nothing is going to be charged to their account. Finally, in the case of some problem with the processing of the transaction, a failure page should be supplied that informs the customer about the nature of the problem and prompts him/here to repeat the order.

If the SET shopping process flow (illustrated in figure 17) is compared to the purchasing process flow using the present version of Jaybis E-com (figure 12), it becomes apparent that there are certain differences between these two flows. We will here take a closer look at these differences and the adjustments they imply for Jaybis E-com.

First of all, Jaybis E-com starts by prompting the customer to log on, if he/she wishes to be invoiced (or chose the cash-on-delivery alternative which is the only alternative payment form), before he/she can access the shop. This might not be such a good solution if anonymous customers are to conduct their business via the system. Most Web-shopping customers are accustomed to start by checking out the products that are offered, before they are prompted to chose a form of payment, and might therefore be discouraged from entering the store if it demands that they select a form of payment before they enter. A SET enabled version of E-com should therefore change the point in the flow where the customer is prompted to log on, or include a special welcome page from which established customers can be redirected to the log on.

Since the activity related to the acceptance of the order is similar in both flows, there is no need for modification regarding that aspect. The third activity in the SET shopping process flow (Enter shipping information, in figure 17) is also rather similar to the corresponding activity in Jaybis E-com’s flow (Check info + Send order, in figure 12). However, the latter does more then assert that required billing and shipping information is available. It also sends the order, and thereby finalizes the ordering process. In the SET case, the customer needs to be prompted to select the form of payment he/she wishes to utilize. This can be done on the same page as the shipping information is handled, but if the merchant supports a wide selection, it is probably better to have a special page dedicated for this selection activity (Select payment, in figure 17). So, Jaybis E-com could accommodate these aspects by simply adding such a payment selection page.

As Jaybis E-com’s shopping process flow includes an order confirmation in the form of a receipt page (Order confirmation, in figure 12), this will fulfill the need for a confirmation of a successful termination of processed SET transactions (Receipt page, in figure 17). However, Jaybis E-com will have to add the two other termination pages that a SET transaction can terminate in (i.e. the cancellation page and failure page in figure 17).

Now, that we have a basic idea of the adjustments that need to the high-level design of Jaybis E-com, we can explore how E-com can be integrated with the GlobeSET POS application. For the sake of simplicity, we will limit this exploration to the part of a systems integration design that covers the implementation of the ability to process a SET purchase request (see figure 18 below). For each other SET operation that the system is intended to support, a similar integration design must be developed. However, the purchase operation is of central importance to all SET applications, and constitutes a good example of the components and processes involved.

Figure 18 strives to illustrate a high-level description of how the GlobeSET POS application can be integrated with Jaybis E-com and it’s associated merchant legacy systems. Lets start by taking a look at the parts of this figure. The attentive reader might recognize the SET shopping process flow (from figure 17) in the blue colored parts of figure 18 (Shop, Accept order, Enter/Check shipping info, Select payment, Receipt-, Cancellation-, and Failure page). These seven parts represent the customer’s interaction with a I-commerce system such as Jaybis E-com, and point out where the integration with a SET merchant application has to take place.

The very attentive reader might wonder why the SET-wallet has not been given the same blue color it had in figure 17. There are two main reasons for this. First of all, the SET-wallet isn’t a part of Jaybis E-com and should therefore (in this illustration) be separated from the other parts of the shopping flow that are handled by E-com. Secondly, the SET-wallet is a part of the suite of SET applications that handle the SET-messaging, and it is therefore most appropriately colored red as the other SET applications are in figure 18.

Finally, figure 18 includes the aspects dealing with the communication between the SET-enabled I-commerce system and a legacy order and fulfillment system that a merchant could be expected to operate. The purpose of these communications is both to ensure that a SET purchase is only activated under the condition that the merchant order system can take and fulfill the order, and to ensure that only authorized transactions are entered as true orders in the legacy system. I have chosen to handle these demands by having the ordered entered as temporary while the SET applications handle the authorization process, and then if the amount is authorized the order state is simply changed into a true order. If something goes wrong in the process the temporary order is simply deregistered.

So, to summaries the flow of interaction and activity in figure 18 it suffices to say that when the customer selects SET as the choice of payment, Jaybis E-com first tries to register a temporary order and if this succeeds E-com then activates the GlobeSET POS via its SDK, and then in turn the customer’s SET-wallet. Once the transaction has been terminated the customer is redirected to the appropriate termination page on E-com, and the asynchronous completion message sent by the POS is evaluated and the merchant’s order system is updated accordingly.

When it came to the issue of implementing the integration of the systems involved, I was asked to limit these efforts to a simple test implementation, which would simulate only the major aspects of a real implementation. The focus was to be on the communication between the GlobeSET POS application and a simple simulation of Jaybis E-com, and on potential technical problem areas in this communication. Since this task involved a number of choices regarding which technologies and programming languages to employ, we will start this section with a discussion of the alternatives and a short presentation of the selections that I made (section 5.4.1). Thereafter we’ll cut to the chase and go straight for a description of the problem areas that were detected during the test implementation (section 5.4.2).

The focus of the test implementation resulted in a limitation of the implementation task to a need to solve only two major implementation issues. First, an appropriate test simulation of Jaybis E-com had to be developed, since E-com itself was still in development at the time of this study. Secondly, the SDK sample code for SET purchase operations had to be modified and integrated with the I-commerce server. Here below we take a closer look at how these issues where handled.

In order to simulate the way Jaybis E-com processes of a purchase, I chose to develop a simple Web application using Microsoft’s server side scripting environment, called Active Server Pages (ASP). ASP was selected because it is less complex than the alternative technologies (such as CGI and ISAPI) used to develop dynamic Web sites. ASP allows executable scripts to be entered directly into the HTML files, and requires no manual compiling or linking. Furthermore, ASP is object-oriented and extensible with ActiveX server components, and therefore a quite powerful and scalable environment for Web application development.75

The Web application I developed using ASP included only five of the main interaction pages illustrated in the system integration design (see figure 18); namely the Select payment, Response evaluation, Receipt-, Cancellation-, and Failure pages. Furthermore, the Select payment page was modified so as to include the setting of all the transaction data relevant to the SET purchase transaction (including both order and customer/shipping data). The Response evaluation page, which I developed, only checked that the transaction had been successfully authorized. It made no attempts to update any legacy system.

These limitations were implemented deliberately, as the purpose of the test system primarily was to evaluate the communication between the Web application and the SET merchant application GlobeSET POS. However, this communication could not be managed directly between the two mentioned applications, since the POS only accepts function calls in the format that the supplied SDK generates. Thus, it was necessary to develop some kind of procedure or component, which the ASP-based Web application could call to generate the required SDK function call. This was accomplished by building an appropriate ActiveX server component.

The primary reason I chose to develop an ActiveX server component was that the ASP development environment supports this specific form of component better than other forms of components. Amongst other things, it’s simple to invoke an ActiveX component from an ASP file. All it take is a single statement, such as this one which creates an instance of a component called SdkInitComponent and assigns it to the variable sdk:

Once the component has been invoked, all its properties and methods can be called directly from the ASP file.76 Thus, all that was necessary to do for the test implementation, was to create an ActiveX component with a method that could be called to execute the SET purchase operation. However, there was another task involved. The sample code that was delivered with the SDK for this operation had to be modified. Since all supplied sample code was delivered in the C programming language, which the ActiveX technology supports, the modifications were basically a question of altering the code to fit the ActiveX encapsulation format. Nonetheless, there were certain difficulties involved in getting the sample code to fit the format required by ActiveX components. These and other problem areas will now be reported in the next section.

During the construction of the SET ActiveX server component, a number of problems were encountered (just as one would expect when several different technologies are involved). Since many of these problems could be related to the lack of sufficient programming skill on my part and inadequate documentation on the part of GlobeSET, I have decided to limit this presentation to the major problem areas that where uncovered. The two major areas were data type conversion and error handling.

The first and most difficult problem area that was encountered, was the one dealing with converting to and from the traditional C data types (e.g. string) and the data type (called VARIANT) that the ActiveX component requires to communicate with the ASP-based Web application via DCOM. It turned out to be very difficult to find the appropriate conversion functions that Microsoft had supplied. However, after much searching and testing some functions where located which could be used to build the necessary conversion methods. The two central functions that where located in Microsoft’s MSDN library were VarUI1FromStr( ) and MultiByteToWideChar( ). The VarUI1FromStr( ) function converts a BSTR (which is a form of VARIANT) into a BYTE (which is a STRING that C can use). The other function does the opposite. By only sending string type data the need for conversion methods was limited to the two that were constructed using these two functions.

It should be added that these problems basically were a result of the choice of Microsoft’s ActiveX technology to encapsulate the SDK sample code supplied with the GlobeSET POS. If some other technology had been selected these problems might have been avoided. On the other hand, other problems might then surface instead. Once the problem had been solved, the selected implementation technology functioned flawlessly in the test environment supplied by GlobeSET.

The second problem area that is worth noting is the one concerning the handling of potential errors that can occur during the execution of the methods in the SET component. These potential errors are rather numerous. The SDK uses a series of error codes to explain the basic problems that may be encountered during it’s operation. These error messages handle errors such as: bad formatting of input data, lack of memory, connection and transmission problems between the SDK and the POS. The SDK also supplies a function that returns a string that states which error the error code represents, this function is called mposError( ). By adding a special error handling method to the SET ActiveX component, these built-in error messages could be extracted and sent to the ASP-based Web application in order to be displayed to the user.

However, this built in functionality only informs the user of an error. In a live implementation there needs to exist some kind of error handling besides simply informing the user of the problem. If the customer’s transaction fails for some reason he/she should not only be informed, but also redirected so that they can reenter their purchase request once more without having to go through the whole process again. Since the implementation described in this report only was of a very preliminary prototype test nature, no such error handling was implemented.

As always when dealing with complex programming, testing has to be of an iterative nature. In other words, testing needs to be carried out continuously during the implementation process and can not be limited to a few check points that have been specified beforehand. Although many bugs can be detected by the software development tools (such as Microsoft Visual Studio 5.0 which was used for this implementation), there still remains an unidentified number which require a more advanced testing environment in order to be detected. This is especially true in cases like the test systems integration we are dealing with here, since it involves such a diversity of applications and technologies.

Fortunately, GlobeSET provided me with a functioning test version of the entire suite of SET applications needed to process a SET transaction. This test version included both the four necessary SET applications (i.e. GlobeSET POS, GlobeSET Wallet, GlobeSET Gateway, and GlobeSET CA) and other test environment specific components and certificates. Thanks to this test environment I was able to realistically simulate SET transactions, and capture the errors that are exposed only when such a transactions is processed.

Finally, it should be mentioned that this test implementation only was tested for errors that hinder basic functionality in the software. No testing for more sofisticated problems such as interoperability with other SET suppliers products was thus conducted.

Well, first of all, from the market survey results, we can conclude that it’s quite feasible to SET enable an I-commerce merchant application such as Jaybis E-com. The SET merchant applications that exist on the market today (with the exception of those delivered by Brokat and OpenMarket) all allow for integration with any such system. Most of them come with complete interfaces to some of the more common I-commerce servers on the market (such as Microsoft Commerce Server or Oracle ICS), and small high-level APIs for integration with other I-commerce servers.

Furthermore, we can conclude that the SET application supplied by GlobeSET (GlobeSET POS) turned out to be well suited for the integration task, although the documentation could have been a lot better. The application shipped with a small but sufficient API, which allows for full systems integration between the POS and the I-commerce application. However, some difficulties were encountered during the implementation face (especially with data type conversion), but these were basically a result of the choice of Microsoft’s ActiveX as implementation technology and therefore not necessarily relevant if some other integration technology was to be selected.

66) OEM is short for Original Equipment Manufacturer. The term is used for companies that produce products that are marketed by other companies under these other companies’ brands.

73) These basic SET-operations include: purchase initiation, opening a batch, closing a batch, authorization, authorization reversal, capture of previously authorized transaction, capture reversal, credit a previously captured transaction, credit reversal, and transaction inquiry.

74) GlobeSET POS Administration and Programming Guide (December 1997). chapter 5.

Sommerville, I. (1996) Software Engineering. Fifth edition. Workingham, England: Addison-Wesley, (pp. 7-12).

Sturmark, C. (1997) IT och renässansmänniskans återkomst. Stockholm, Sweden: Nordstedts Förlag AB.

Visa and MasterCard combine security specifications for card transactions on the Internet,

W. Diffie and M.E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22: 644-654, 1976.

SET Secure Electronic Transaction Specification, Book 1: Business Description (1997).

SET Secure Electronic Transaction Specification, Book 2: Programmer’s Guide (1997).

Sjögren, N, (1998) "Småföretag avstår dyr set-lösning", ComputerSweden, nr: 44 (5/15/98), p. 6.

GlobeSET Press Releases: GlobeSet Awarded Industry-First SET Mark for Merchant Payment Acceptance Software, http://www.globeset.com/062298.shtml , June 22, 1998.

Trintech™ for the Internet (SET): Product Overview. A PowerPoint presentation document supplied by Trintech on request.