APPL-1012
`APPLE INC. / Page 1 of 20
`
`APPL-1012
`APPLE INC. / Page 1 of 20
`
`

`

`Designing Systems
`
`for
`
`Internet Commerce
`
`Second Edition
`
`
`
`G.Winfield Treese
`
`Lawrence C. Stewart
`
`..,4., Addison-Wesley
`
`
`
`Boston• San Francisco• New York• Toronto• Montreal
`
`
`
`London • Munich • Paris • Madrid
`
`
`
`Capetown • Sydney • Tokyo • Singapore • Mexico City
`
`
`
`APPL-1012
`APPLE INC. / Page 2 of 20
`
`

`

`Manyofthe designations used by manufacturers and seller
`claimed as trademarks. Where those designations appear in
`aware of a trademark claim, the designations have been pr
`all capitals.
`
`The authorsand publisher have takencare in the preparatior
`or implied warranty of any kind and assume no responsib
`liability is assumed for incidental or consequential damages
`the use ofthe information or programs contained herein.
`
`The publisher offers discounts on this book when ordered =
`special sales. For more information, please contact:
`
`U.S. Corporate and GovernmentSales
`(800) 382-3419
`corpsales@pearsontechgroup.com
`
`Forsales outside of the U.S.. please contact:
`
`International Sales
`(317) 581-3793
`international@pearsontechgroup.com
`
`Visit Addison-Wesley on the Web: www.awprofessional.c
`
`Library of Congress Cataloging-in-Publication Data
`
`Treese, G. Winfield.
`Designing systems for Internet commerce / G. Winfielé Trossc.
`2nded.
`p. cm.
`Includes bibliographical references and index.
`ISBN 0-201-76035-5 (pbk. : alk. paper)
`1. System design. 2. Electronic commerce. I. Stewart. La
`
`QA76.9.S88 T74 2003
`658.8'00285’°4678—de21
`
`Copyright 2003 by Pearson Education, Inc.
`
`=r products are
`+cison-Wesley was
`capital letters or in
`
`make no expressed
`
`missions. No
`“> orarising out of
`
`k purchases and
`
`rence C. Stewart—
`
`=
`
`If. Title.
`
`202074788
`
`i ina retrieval system,
`All rights reserved. No part of this publication may be reproduced
`or transmitted, in any form, or by any means, electronic, mec
`otocopying, recording,
`or otherwise, without the prior consentofthe publisher. Printed in the - nited States of America.
`Published simultaneously in Canada.
`
`Forinformation on obtaining permissionfor use of material from this wor
`written request to the following address:
`
`k, please submit a
`
`Pearson Education, Inc.
`Rights and Contracts Department
`75 Arlington Street, Suite 300
`Boston, MA 02116
`Fax: (617) 848-7047
`
`ISBN: 0-201-76035-5
`Text printed on recycled paper
`123456789 10—CRS—0605040302
`First printing, September 2002
`
`APPL-1012
`APPLEINC./ Page 3 of 20
`ennARSESESSLERESTOS
`
`APPL-1012
`APPLE INC. / Page 3 of 20
`
`

`

`[PETTERSELEYEETELT
`
`
`
`CHAPTER21
`
`Putting It All Together
`
`Three things are to be looked to in a building: that it stand on the right
`spot; that it be securely founded; that it be successfully executed.
`—Johann Wolfgang von Goethe!
`
`
`
`
`
`Building Complete Systems
`
`In Part One ofthis book, we discussed issues of business, architecture, and implemen-
`tation. In Part Two, we discussed implementation technologies for various aspects of
`Internet commerce. In this chapter, we try to assemble the pieces into complete sys-
`tems. There are many workable ways to build Internet commerce systems; the ap-
`proaches we describe here are but a few examples.
`
`We will first present an architecture for a federated commerce system. Next, we de-
`scribe a core system architecture and its requirements, followed by a discussion of
`how this architecture may be applied to the business models discussed in Chapter 4.
`
`Federated Commerce System
`
`We envision many individual Internet commerce systems as being membersofa glo-
`bal federated commerce system, as shown in Figure 21-1. In the federated commerce
`system, customers may join one or more buyer communities and conduct commerce
`
`
`1.
`
`Johann Wolfgang von Goethe, Elective Affinities (1808).
`
`APPL-1012)
`APPLEINC./ Page 4 of 20
`
`APPL-1012
`APPLE INC. / Page 4 of 20
`
`

`

`402
`
`Chapter 21 Putting It All Together
`
`
`
`Customer
`
`Customer
`
`Community
`
`
`
`
`
`
`STEGERFTATATETEETEREARLE
`
`Community ASP
`
`Value-Added
`Service
`
`a
`Value-Added
`Service
`
`
`
`FIGURE21-1. Federated Commerce System
`
`with any numberofsellers. Buyers get the advantages of a single account to remem-
`ber and unified customerservice. Sellers gain the advantages ofstandardization, ease
`of use, access to a large aggregation of customers, and easy access to network-based
`value-addedservices. In this example, we will abbreviate the generic federated com-
`merce system as FCS.
`
`The authorsfirst proposed an FCS ina series of memoranda at Open Market in March
`1995. In December 1998, Open Market launched an effort called CommerceToneto
`bring a federated commerce environment to the market. The project wasn’t finished,
`but a separate company called CommerceTonewascreated to deliver some of the en-
`visioned marketing and value-added services.”
`
`In March 2001, Microsoft announcedits Passport system, whichit intended to be the
`single buyer communityfor the entire Internet. Passport provides single sign-on for
`its affiliated Web sites such as the Microsoft Network (MSN) and Hotmail, and also
`provides a server-side wallet for storage of credit card numbers and other personal in-
`formation such asbill-to and ship-to addresses. Some of Microsoft’s competitors, led
`by Sun Microsystems, then announced the Liberty Alliance, whose purpose wasto
`create an open, federated single sign-on system, to be followed by some kind of FCS.
`Microsoft then announced the opening up of Passport to a federated model. At the
`
`
`
`2. CommerceTone waslater acquired by Mercantec.
`
`LT
`
`APPL-1012
`APPLEINC./ Page 5 of 20
`
`
`APPL-1012
`APPLE INC. / Page 5 of 20
`
`

`

`PEERS10000000 TLLaImEEennratureerersere see
`
`
`
`|
`
`Authentication
`Statements
`
`Customer
`
`ol
`
`
`— Ed
`
`C="
`
`Orders
`
`Status
`
`“4
`
`i ig
`
`Registration and
`
`
`
`2HL
`
`Lec
`~~
`;
`4d
`Sas
`E
`Login
`eI
`
`
`
`
`Clearinghouse
`
`Customer Info
`
`Transaction Record
`
`
`FIGURE21-2. Federated Commerce System Transaction
`
`time this book is being written,all of these systemsare in the early stages of deploy -
`ment, at best.
`Let’s follow a typical consumertransaction through its life cycle, with reference t
`Figure 21-2.
`1. Previously, customer Jane joined a buyer community, completing its registration
`process.
`2. Jane connects to the catalogWebsite of the seller andselects items for purchase.
`3. On the checkout screen, Jane selects Use my FCS account.
`4. Theseller system usesthe services of the FCS clearinghouse to locate Jane’s home
`community system (FCS Login).
`5, Jane authenticates herself to her own homesystem.
`6. Theseller system requests buyer information from the home system, which Jane
`chooses to release.
`7. The seller system completes the transaction and transmits a transaction record to
`Jane’s unified customer statement held on her home system. This could be just a
`link to the seller’s customerservice module.
`s. Later, Jane can view a unifiedlist of all her FCS transactions and query any of
`them for status. The status link will take her to the particularseller system for cur-
`rent order status.
`
`APPL-1012
`APPLEINC./ Page 6 of 20
`cc
`
`APPL-1012
`APPLE INC. / Page 6 of 20
`
`

`

`404
`
`Chapter 21 Putting It All Together
`
`ConsumerServices
`
`The federated commerce system,if built correctly, has many benefits for consumers.
`
`With isolated systems, customerservice is problematic because the customer must
`rememberall the sites at which she has made purchases. With federated com-
`merce, the seller always sends a short transaction record to the buyer's home sys-
`tem, to be placed on a unified statement. The unified account statement can also
`easily be integrated with personal finance software.
`e Privacy
`People desire different levels of privacy. Some may chooseto join a buyer commu-
`nity that provides cash-back oran affinity program in exchangefor revealing addi-
`tional personal information and accepting advertising. Others may chooseto join a
`high-privacy community, which could go so far as to conceal completely the
`buyer’s true identity from all other sites. In any event, the buyerhasthe ability to
`configure her personalprivacy policy without the full-time job of studying the pol-
`icies of everysite visited.
`e Multiple accounts
`Becausethere is a single point of control for an account, it is possible to put con-
`trols on the use of that account. This might be useful, for example, to allow chil-
`dren to shop online at selected sellers and with preestablished limits on their
`spending. The parents would have control overthe limits on the account, and they
`would have access to a combined statement summarizingall activity on the fam-
`ily’s accounts.
`e Multistore gift registry
`Gift registries are typically limited to a single store or chain ofstores. In a feder-
`ated system, it wouldbestraightforward to create gift registries that span multiple
`stores, providing more choices and easier shopping.
`
`Value-Added Services
`
`Federated commerce,by virtue of standardized APIs and service agreements, makes
`it straightforward to create value-added services, suchas the following.
`
`e Affiliate programs
`The FCSis a natural venuefor affiliate programs. Rather than requiring affiliates
`to join seller programsindividually, the affiliate can set up one account and poten-
`tially join many programsat once.
`
`APPL-1012
`APPLEINC./ Page 7 of 20
`ooo EEE
`
`e
`
`Simple purchasing
`If the consumerallows, her home system can release ship-to addresses and pay-
`ment informationto theseller. This allowsall participating sites to haveastraight-
`forward checkout process with few clicks and no typing.
`e Unified statements
`
`
`
`APPL-1012
`APPLE INC. / Page 7 of 20
`
`

`

`
`
`Federated Commerce System
`
`405
`
`e
`
`Payment providers
`Payment providers can more easily connect with sellers by virtue of FCS standard
`interfaces. Standardized service agreements also promote competition.
`° Tax calculation
`
`Domestic and international tax services can easily provide services. Of course, ba-
`sic Web services do not require a federated system, but standardizationof the rele-
`vant interfaces makes integration easier. For greater value, tax services could
`provide filing and payment as well.
`e Logistics
`Logistics companies can offer rate calculators, shipping, and package tracking
`through standard interfaces. By connecting with both the buyerand seller, a logis-
`tics company could enhanceprivacy by concealing the ship-to address fromthe
`seller.
`
`The FCS can offer many services, but they all build on three mechanisms.
`
`1. The powerof standardized APIs
`The FCS uses a Web services model for communications and integration. This
`meansthat interfaces are defined by agreed-on XML data types, and the existence
`and typesofinterfaces are defined by XML metadata. The FCS sets standards for
`the APIs to the network, which helps to ensure that systems provided by different
`vendors will interoperate.
`2. The powerof standardized contracts and directories
`Participants in the FCS can take advantageofstandardroles. For example, some-
`one can registeras an affiliate and agree to the standardaffiliate “deal” and then
`consult listings of sellers who offer that deal and sign up with many ofthemat
`once. Similarly, customers of a service who accept a standard deal can select sup-
`pliers who offerit. Standardized specifications of agreements suchas percentage
`discounts for quick payment can evenbe processed automatically.
`3. The power of networking
`Metcalfe’s Law saysthat the value of a networkincreases as the square of the num-
`ber of participants. Something similar seems to apply to the FCS: the aggregate
`expense of the network growslinearly with its size, but the savings grow withthe
`numberofpossible interactions. In addition, the FCS is a boonfor service provid-
`ers, such as logistics companies, that must communicate with both the buyer and
`theseller. In standalone systems, this contact point is internal andinaccessible, but
`in the FCS, the contact between buyerandseller is external and easy to hookinto.
`
`Who Pays Whom?
`As we have learned from the late 1990s, there are many possible business models for
`Internet services. It is probably easiest to compareparts of the FCS to the credit card
`system. In the credit card system, whenever a consumeruses a card, most of the
`
`APPL-1012
`APPLEINC./ Page 8 of 20
`
`APPL-1012
`APPLE INC. / Page 8 of 20
`
`

`

`406
`
`Chapter 21
`
`Putting It All Together
`
`money goes to the merchant, but a portion of the paymentis split among the mer-
`chant’s bank, the cardholder’s bank, and processing companies. Generally, small fixed
`fees go to those parties whoserole is merely to route transactions, whereaslarger, al-
`thoughstill small, percentage amounts go to parties who take on the financialrisks of
`fraud, default, and so on. This seems to be a good modelfor the FCS. Roughly speak-
`ing, the networkitself, the clearinghouse, may qualify for a fixed processing fee, and
`the buyer’s community may qualify fora fixed fee for record keeping,but unless par-
`ties take on financialrisk, they should not qualify for a fee based onthe size ofthe
`transaction.
`
`
`
`System Functionality
`
`In Chapter 2, we introduced the commercevalue chain: attract and keep customers,
`turn interest into orders, manage orders, and provide customer service. Excellence in
`managing orders and providing customer service can help attract and keep customers.
`The more one learns about one’s customers (with great attention to privacy), the better
`one can market to them.
`
`Our implementation approach divides the components ofthe value chain into the fol-
`lowing groups.
`
`* Content servers and applications
`e Linking the content to transactions
`¢ Order management, including order processing, payment, fulfillment, and cus-
`tomerservice
`
`Sv LLETREATEETHTL ENTUICNTETTETTT1
`
`Walking Through a Transaction
`Before we discuss the system architecture and design issues, we’ll walk through a
`transaction.
`
`Before opening for business, a seller creates an online catalog containing the product
`descriptions, prices, and so forth. The seller also creates a merchantprofile, which de-
`scribes the accepted means of paymentand tax and shipping rules, and configures the
`fulfillment system to route orders.
`
`Whenthe buyer browsesthecatalog, the purchasing process begins, consisting of the
`followingsteps.
`
`1. The buyerlocates products of interest in the catalog and clicks the associated of-
`fers. This creates items in the buyer’s shoppingcart.
`2. On checkout, the buyer sees the order form, an example of which is shownin Fig-
`ure 21-3. The screen shownalready has somebuyer informationfilled in, as
`would bethe case for a repeat buyer, based on saved memberinformation.
`
`TEETEOOEETEEEEOEEECOETTEEETE
`
`SSS TESSTSGT TESTS TEES TESSTE
`
`APPL-1012
`/ Page 9 of 20
`TEETER SAE
`TT
`Bann
`
`
`APPL-1012
`APPLE INC. / Page 9 of 20
`
`

`

`
`
`System Functionality
`
`407
`
`3. The transaction engine calculates sales tax using the buyer’s billing address, the
`seller’s tax profile, and the producttax classification code.
`4. The transaction engine calculates shipping charges using the buyer's choice of
`seller-defined shipping methods, together with productprice or weight.
`5. The buyer clicks Buy Now.
`6. The transaction engine performsa credit card authorization and address verifica-
`tion check with the seller’s choice of card processing network.
`7. The transaction is recorded in permanentstorage.
`s. An adviceof order received is routed to the seller.
`9. The transaction enginereturns a receipt to the customer, which contains a copy of
`the invoice and a link to a status page for customerservice.
`10. The seller ships the product and informs the transaction engine of the shipment,
`using the online order status pages.
`11. The transaction engine performs credit card settlement, transferring funds from
`the buyer to the seller’s account.
`12. The transaction engine updates the buyer’s online statement and optionally sends
`the buyer an e-mail advising of the order shipment.
`
`Afterward, the buyer’s receipt remainsactive, bringing the buyerto his online state-
`mentofactivity. Each itemis a hypertextlink to a status page for the particulartrans-
`action.
`
`Digital Goods
`If the product purchasedis in electronic form, the buyer’s receipt is a hypertext link
`directly to the fulfillment area. Either the receipt carries with it security codes grant-
`ing access by the buyerto specified areas within the fulfillmentsite for a specified
`periodof time, or access control for the fulfillment area must be updated.
`
`Subscriptions
`If the product purchasedis an ongoing subscriptionto an electronic publication, the
`transaction engine makes appropriate entries in its subscription database for the pur-
`posesofbilling and control of access to the fulfillment servers.
`
`Whenthe buyerlinks to the fulfillment serverata latertime, he will be challenged to
`authenticate himself against the customer database. Then an access control check will
`be performedagainst the subscription database. If the subscription is current, the
`buyerwill be granted a ticket good for access to the contentareas. Only whenthe
`ticket expires, perhaps weekly,will the buyer be required to reauthenticate himself.
`
`APPL-1012
`APPLEINC./ Page 10 of 20
`
`APPL-1012
`APPLE INC. / Page 10 of 20
`
`

`

`408
`
`Chapter 21 Putting It All Together
`
`
`
` Order Form - Netscape
`File Edit View Go ‘Communicator Help
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Use my Regictered Information
`
`|
`
`Marre [Eawrence C. Stewart
`Address [1 Wayside Road
`
`-
`
`;
`
`Set differnt Shin To ecidness
`
`J
`
`
`
`
`
`City or town [pari ington
`State or province fas
`Zip or postal Code foreos
`Country [United States
`Phone number
`
`[781-259-7272
`
`
`
`
`
`
`
`Payment card nuher |
`
`Expiration date
`Month [os 2 |vear [oe =|
`(Your payment information will be kept secure.)
`
`
`* Recalculate atter = eo |
`
`
`
`Copyright © 1997 Open Market, Duc. All rights reserved.
`
`=e
`OpenMiket Transact™servicesprovidedbyfreame ofTransactcamer).
`_ :
`:
`:
`r
`Document
`
`
`FIGURE21-3. Example of Order Form
`
` APPLE INC. / Page M1 of 20
`
`APPL-1012
`
`APPL-1012
`APPLE INC. / Page 11 of 20
`
`

`

`
`
`System Architecture
`
`409
`
`Transaction
`
`
`Fulfillment
`
`
`Business
`Catalog
`Server |
`Retail
`Content
`Server
`
`Information
`Content
`Server
`
` Financial
`Networks
`
`Networks
`
`
`
`
`End User
`
`Merchant
`
`Operator
`
`
`
`FIGURE21-4. Commerce Architecture
`
`
`
`System Architecture
`
`Whenwe introduced various architectures in Chapter 6, we said, “The architecture of
`a system defines its basic components and important concepts and describes the rela-
`tionships among them.” Figure 21-4 showsa block diagram of a commerce system
`built from these components. Overall, this is a three-tier architecture with clients us-
`ing Web browsers connecting over the Internet to content servers of various types.
`The content servers in turn use shared commerceservices. The applicationis inter-
`connected overthe public Internet. Finally, the transaction engine connects to services
`off the public Internet, such as financial networks and fulfillment systems.
`
`The key architectural ideas are to separate management of content from management
`of transactions, to support a broad range of applications, to enable scaling of the sys-
`tem, and to accommodate evolution in technology and functionality.
`
`Separating Content from Transactions
`
`Whenwestarted thinking through the problems of commerceon the Internet, ourfirst
`observation was that although we usually think of Web content as being present on a
`server somewhere on the network, it becomesdisplayable, rendered text and graphics
`only on the screen of the end user’s Web browser. Consequently, the buyer’s decision
`to buy will be communicated to the rest of the system as a network event, and we do
`not have to send that event to the same system that generated the page of content.
`
`APPL-1012
`APPLEINC./ Page 12 of 20
`
`APPL-1012
`APPLE INC. / Page 12 of 20
`
`

`

`410
`
`Chapter 21 Putting It All Together
`
`Our key decision was to treat product information as content and to maintain it on a
`content server, and then to deliver the product informationto the transaction serveras
`part of the click-to-buy process, using the standardWeb HTTPprotocol. This idea en-
`ables managementof content to be separated from managementoftransactions, and
`permits several benefits.
`
`Reduction of Operational Costs
`Splitting up content and transaction managementcan reduce total operationalcosts.
`
`Content servers have very different operational requirements than transaction servers.
`Indeed, if content is delivered by e-mail or CD-ROM,there may not be a content
`serveratall.
`
`Ournext observation was on the nature of a business transaction. Typically, informa-
`tion aboutthe buyer, the seller, and the product being purchased must be brought to-
`gether in one place. Buyer information includes items such as means ofpayment,
`shipping address, andso forth. Seller information includes items that are not depen-
`denton the particular item sold but that relate to the seller across multiple products,
`such as payment methodsaccepted and meansoffulfillment. Product information in-
`cludesitems suchasdescription, price, weight, and taxability.
`
`siiTEEESEET LN
`
`Placing the transaction and business records in one place minimizes the number of
`systemsthat require database management systems and expensivereliability and in-
`tegrity protections, and minimizes the numberof systemsthat require specialized
`managementand operationsskills.
`
`Because many content servers can share the services of a transaction engine, the costs
`of the transaction engine are amortized over many users. The content server costs are
`reduced because there is no need for each system to build in all the commoncosts of
`transaction handling.
`
`Enabling ofService Providers
`Multiple content servers can rely on shared commerceservices providedbya transac-
`tion engine. This creates a new business—a commerceservice provider, which oper-
`ates a shared transaction system onbehalf of multiple contentservers. The transaction
`server can be shared across multiple divisions of a corporate enterprise or as a busi-
`ness in its own right.
`
`Provision of Security Containment
`A security systemsis as strong asits weakest link. If valuable information is spread
`around the system,the security properties of the system must be equally strong every-
`where. By placing mission-critical business functions and transaction records in a
`
`APPL-1012
`APPLEINC./ Page 13 of 20 OORTPERETEETEET
`
`APPL-1012
`APPLE INC. / Page 13 of 20
`
`

`

`System Architecture
`
`411
`
`shared transaction server, the security effort can be focused. The efforts of attackers
`may be concentrated on the transaction system “becausethat’s where the moneyis,”
`but the vigilance of security mechanisms is concentrated as well.
`It is actually easier to secure the transaction engine, which has limited and stylized
`connections with the outside world, than it is to secure a content server, which must be
`accessible to content creation and management personnel as well as to customers.
`
`Supporting a Broad Range of Applications
`A shared commerce services environmentenables a very broad range of commerce
`applications. At the very simple endof the spectrum, small stores can be prepared
`with desktop publishing tools and uploaded onto the Net. Offers to sell, encoded in
`the content, point to a commerceservice provider, which managesthe resulting orders
`on a fee basis. There is no need for the content provider to understand or operate a
`complex transaction system.
`In the midrange, dynamic content and rich site-development tools can create a com-
`pelling commerce experience for the consumer and provide compelling value for the
`business user.
`
`At the high end, an enterprise may have multiple divisions with different content sys-
`tems, sharing transaction services provided by the IT department. Thetransaction en-
`gine may be integrated closely with enterprise financial and logistics systems.
`By leveraging a shared infrastructure, small and medium-sized enterprises can access
`all the servicesthat are available to large enterprises.
`
`Supporting System Scaling
`Splitting up content and transaction systemsallowsthemto scale independently. Con-
`tent systems need to grow according to the type and volumeofcontent, which may be
`unrelated to the volume oftransactions. A dynamic content site delivering pages rich
`in graphics and multimedia will have greater computing and bandwidth requirements
`than a content system delivering even a large numberof simple pages. On the fulfill-
`mentside for digital goods, a single transaction may grant very substantial access
`rights to fulfillment servers over an extended period.
`With the shared services design, content servers can be added to the system as the
`need for them arises as a result of increased demandfor or volume of content. Content
`servers representing additional businesses may register for commerce services at any
`time.
`
`Thetransaction engine also needsto be scalable. Wedesignedit as a set oflogical
`servers backed byarelational database managementsystem. The application logic
`scales by running the componentservers on more powerful hardware or by load shar-
`
`_
`
`APPL-1012
`APPLEINC./ Page 14 of 20
`
`-
`
`———
`
`APPL-1012
`APPLE INC. / Page 14 of 20
`
`

`

`412
`
`Chapter 21 Putting It All Together
`
`ing. The database scales by running on more powerful hardware and by exploiting the
`database vendors’ parallel and cluster capabilities.
`
`Supporting System Evolution
`Anarchitecture is needed when one doesn’t know whatkinds of problemswill arise
`tomorrow. Internet commerceis changing very rapidly, and so systemsinstalled today
`will need to add new functionality and exploit new technologies as the industry ma-
`tures,
`
`Functional Evolution
`
`Separating contentandtransaction systems permits functions to be addedto each sys-
`tem without affecting or requiring upgradesto the other. For example, a new payment
`method such as purchase orders can be added in one place at the transaction server,
`making the new functionality immediately availableto all affiliated content servers.
`
`A content server employing dynamically generated pages can replacea server using
`static pages without any changein the transaction machinery.
`
`Technological Evolution
`An importantpart of an architecture is defining interfaces between the partsof the
`system that remain stable across multiple releases and technological changes. For ex-
`ample, server-side wallets may replace HTML forms and SSL/TLSforcredit card
`paymenton the Internet. When wallet supportis added to the transaction engine,all
`the affiliated content servers can take immediate advantageofit without having to up-
`grade each content system—perhapsusing several different content creation and man-
`agement systems.
`
`
`
`Transaction Engine
`
`The best way to think ofthe transaction engineis as a suite of applications for its dif-
`ferent users: buyers, sellers, and operators. This model is shown in Figure 21-5. In
`more traditional business settings, buyers interact directly with sellers, and both
`interact directly with operations and support groups. On the Internet, the situationis
`different because the parties involved arerarely online at the same time. Instead, each
`group ofusers interacts with applications that place their retained state in a database
`where the next group can pick it up and carry on. The database, without loss of gener-
`ality, can be a set of databases with workflow capabilities.
`
`The transaction engine is organized in this way, with application logic and user inter-
`face capabilities for buyers, sellers (merchants), and system operators.It is a rich ap-
`plication; the following sections are not exhaustive but are included here to give
`
`SEEETERSTAGEDToDoOOEEEDETOOSGUESEenoanaT
`
`APPL-1012
`APPLEINC./ Page 15 of 20
`
`
`
`|aS
`
`
`
`
`
`OREREGTTOSENSSSTONITOCUTECUCTETIETUUSTONOTOOONOCGACETECTTEEEOOEEO OSESDESEOSOCOSTTOTORENMeNTTTeTDanH NTEyTeTTy yre yang ese eeTTT TTT PTET TE TTT FFTEEEERECOTENTTTTUGS, CERSERRSTORE
`
`APPL-1012
`APPLE INC. / Page 15 of 20
`
`

`

`
`
`pL LLIRLLLEEEES000S012TETETPTETnpCperereNeerERENTETEame4 cesta a
`
`
`
`Transaction Engine
`
`413
`
`
`
`
`Catalog
`System
`
`User
`Database
`
`Order
`Management
`
`Other
`Functions
`
`Internet Commerce System
`
`
`|
`
`SAP R/3
`ERP System
`
`|
`
`||| |
`
`Marketing Data
`
`
`
`FIGURE 21-5. Transaction Engine Application
`
`readers an appreciation ofthe kinds of functionalities and APIs that are included. In
`many implementations, the transaction engine includesthe userinterface, but in our
`example,the userinterface for the buyers is specifically provided by the content man-
`agementand catalog systems through transaction engine APIs.
`
`Buyer Applications: User Interface and APIs
`The buyer experienceis primarily with catalog and other content systems.In the case
`of high-end content systems, or those with complex marketing and promotionslogic.
`buyerinteractions with the transaction engine are indirect, through contentserver user
`interfaces supported by application programmerinterfaces provided by the transac-
`tion engine. In support of simpler catalog systemsor of offers made by advertise-
`ments, buyersinteract directly with transaction engine userinterface software.
`
`BuyerApplications with User Interface
`
`e Order capture
`The ordercapture application appearsto be aninteractive order form. Buyers pop-
`ulate the order formdirectly by clicking digital offers and digital coupons. or ths
`seller may prepopulate the order form through an API. The order form provices
`the facilities for the buyer to adjust item quantities, choose coupons, enter or oo
`billing and shipping addresses, and select payment and shipping methods. In acc-
`tion to providing the order form userinterface, the order capture subsystem ca oo
`lates discounts from coupons (including matching coupons against items
`validates addresses, and calculates sales tax and shipping charges, leading |
`
`ordertotal. If a consumer payment methodsuch asa credit card is selectec
`transaction engine obtains the necessary authorization in real time. The prs
`
`is to validate the success of the orderto the fullest extent possible while the >
`is online, in order to resolve any problems right away. In the case of digita’
`2
`
`APPL-1012
`APPLEINC./ Page 16 of 20
`
`APPL-1012
`APPLE INC. / Page 16 of 20
`
`

`

`414
`
`Chapter 21 Putting It All Together
`
`The goal of the customerservice applications is customerself-service. For regis-
`tered buyers, the system provides online statements of all transaction activity.
`Each item is active and can be clicked through to reach detailed order status infor-
`mation or the catalog page from which the item wasoriginally selected. From the
`orderstatus screen, the buyer can click through to the package tracking services
`offered by some logistics companies. The subscription capabilities are also sup-
`ported by somespecial customer service applications. For example, if a subscrip-
`tion involves periodic payments and the associated credit card expires oris
`canceled, the system permits the buyerto substitute a different paymentinstru-
`ment without intervention by the operator.
`
`Buyer APIs
`
`Buyers will not use these APIs themselves. Instead, these are APIs that sellers who
`have relationships with the transaction engine use in order to implementthe buyerex-
`perience.
`
`and subscriptions, the buyer experience ends with a receipt, granting immediate
`access to the appropriate fulfillment server. For physical goods, the buyer obtains
`a receipt that can be used later for order status and customerservice.
`e Accountregistration and managementprofiles
`There are multiple models of buyers. Walk-in buyers may have no previousrela-
`tionship with the system. Walk-in buyers mustfill out the complete order form,al-
`though parts of the process may be automated by buyer software such as an
`electronic wallet. There are also registered buyers, who have chosen to save an ac-
`countprofile as repeat visitors. Registered buyers get the order form already pop-
`ulated with their stored information, for faster checkout. Registered buyers also
`have access to account administration applications, for creating and changing user
`and security profiles and for registering additional means of payment, suchas a
`microtransaction account. Finally, there are buyers whose profiles are held else-
`where by a buyer communitythat is part of the FCS. These buyers can be handled
`either as walk-in buyers whose orderformsare filled out automatically or as regis-
`tered buyers, some of whoseregistration informationis held remotely.
`e Customerservice
`
`
`
`¢ Commerce objects
`The commerceobjects, including offers, coupons, and receipts, constitute the pri-
`mary APIto the transaction engine. These objects are the primary mechanisms
`through which items for sale, merchandising, and fulfillment of digital goods are
`handled between content servers and the transaction engine.
`
`¢ Orderinjection API
`Whena buyeris online,