US20120253976A1

Movatterモバイル変換

Info

Publication number: US20120253976A1
Application number: US13/494,507
Authority: US
Inventors: Eric Gunter Roubal; Amit Bartake
Original assignee: Digital River Inc
Current assignee: Digital River Inc
Priority date: 2008-08-21
Filing date: 2012-06-12
Publication date: 2012-10-04
Also published as: US9760921B2; US20100049656A1

Abstract

A half-graphical user interface (Half-GUI) order processing (HGOP) system with single sign on and its method of use is described. A set of web services may be utilized for order processing in an electronic commerce system which allows a merchant to host a product catalog and shopping cart, but post the transaction to an e-commerce system in one simple transaction. In response to a shopping cart request and utilizing single sign on technology, the HGOP system exposes a single checkout form, prepopulated with customer account information to a merchant web site. If no edits are required, the transaction posts and an order confirmation/thank you page is displayed. If edits are required or a new customer account is required, the customer's account is updated or created.

Description

This application is a divisional of U.S. patent application Ser. No. 12/195,990, filed 21 Aug. 2008, entitled “Half-GUI Order Processing System and Method,” which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to commerce systems for use on the Internet. More particularly, the present invention relates to a system and method for utilizing Web services in order processing in an electronic commerce system.

BACKGROUND OF THE INVENTION

Through the use of common software structures, a network of computers known as the World Wide Web (Web), or Internet, enables vast and immediate interconnectedness for many users. Web technologies (such as hypertext markup language (HTML), hypertext transfer protocol (HTTP), Web servers and browsers) and a combination of software applications known as “Web services” allow customers to connect with businesses and businesses to connect with each other to conduct transactions over the Internet. In most cases, these technologies are standardized to provide an interoperable means for internet content providers and merchants to expose their products and services to end users.

A browser application installed on a client computer allows the user access to internet resources. This access, and movement around the Internet, is enhanced by the use of hyperlinks (“links”) within a Web page's HTML content, which defines the document. The link, typically a word in a text field or an image on a Web page, acts as a path that moves the user from one Web page universal resource locator (URL) address to another using HTTP by means of the Transmission Control Protocol (TCP) and the Internet Protocol (IP) collectively known as the TCP/IP suite of protocols. The movement from one URL to another allows near-instant access to information, products, and services and is particularly well-suited to the exchange of information, goods, and services between buyers and sellers. Such business is commonly referred to as “electronic commerce,” or “e-commerce.”

With the abundance of goods and services available on the Internet, a Web merchant seeks a method for competitively processing orders for its goods and services in a way that makes sense for its size, product line, available resources, and goals and objectives. For some merchants, self-hosting of the e-commerce functions and processes makes sense. These merchants may only require the basic catalog display, shopping cart and transaction processing functions. For others, however, more extensive features are required, or the merchant may desire integration of these basic features with its own inventory control, order processing and accounting systems and/or with other services and features. These highly integrated systems require flexibility and interoperability in order to interface applications with one another across organizations. The use of Web services allows communications between these programs, where neither system need know anything about the software with which it communicates.

A web service is a standardized way of integrating Web-based applications using the Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and other open standards over an internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data. WSDL is used for describing the services available. These services provide the interoperability required to integrate a merchant's applications with another merchant or one or more service providers.

Unlike Web technologies, Web services are not meant to be displayed in a web browser or otherwise exposed to an end user. Instead, they allow communication between systems. XML is a framework for creating tags which convey the meaning of the information included within them. The meanings, or semantics, of the tagged data are described by an XML schema. The XML document is created in the sending system, and parsed and translated in the receiving system using that shared definitions provided by the schema.

WSDL is a standard published by the World Wide Web Consortium (W3C) which allows a service provider to describe Web services in an XML format as a set of endpoints operating on messages. It is used to describe and locate Web services. The WSDL allows endpoints and messages to be described regardless of the message formats or network protocols.

SOAP is used to send information over the internet. A SOAP message contains a way to bind the standard Web messaging protocol, HTTP, an envelope that specifies the start and end of the message, the message itself, and a header containing additional information related to the message being sent. An alternative to using SOAP is to use a Web Services Invocation Framework (WSIF), for which SOAP is one possible binding method. A WSIF is an open application programming interface (API) for invoking Web services regardless of how the Web services are provided. The API is a simple Java program. Rather than use a common message format, such as SOAP, the WSIF API allows application developers to interact directly with abstract representations of Web services through their WSDL descriptions.

Without privacy and security assurances, many customers would not purchase online. In addition to Web services, many Web applications use the popular, easy to use and effective Pretty Good Privacy (PGP) encryption standard to ensure communication channel security. PGP uses public key cryptography to encrypt the contents of a shopping cart and to provide authentication. It provides a higher level of security than user names and passwords, which are also required to create or log customers into an online store account.

Taking advantage of the interoperability and flexibility provided by Web services allows a web merchant to distribute its business logic and strategy among several systems, applications and providers in order to meet its own e-commerce objectives.

BRIEF SUMMARY OF THE INVENTION

In accordance with one embodiment of the invention, a half-graphical, or partial, user interface (half-GUI) order processing (HGOP) system and its method of use is described. The HGOP web service and system provides flexibility as to which components of the e-commerce system the merchant hosts, and which is supplied by the e-commerce provider. In the preferred embodiment of the present invention as outlined in more detail below, the HGOP system uses Web technologies and Web services to allow an internet merchant to host its own product catalog and partial shopping cart and other components of an online store as desired, but post the information from the shopping cart to the commerce system cart at checkout time using a single transaction, over a pre-existing communication network. Single sign on (SSO) may be used to provide broad, but low-level authentication, to maintain synchronization between the e-commerce system and the merchant system, to preload existing customer information and to maintain a seamless user experience. The e-commerce system provides a PGP key and a posting URL to the merchant at the outset of the merchant/e-commerce system relationship. PGP armors the shopping cart and customer information for added security. The posting URL directs the checkout process in a way that provides a natural load balancing effect and offers additional features that may be had by using local e-commerce servers.

Additional advantages and features of an embodiment of the invention will be set forth in part in the description which follows, and in part, will become apparent to those skilled in the art upon examination of the following or may be learned by practice of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the context of use for an HGOP system.

FIG. 2 illustrates the process flow of an HGOP system where customer accounts are in sync between the merchant system (storefront) and the e-commerce system.

FIG. 3 illustrates the added process flow required when a user is new to the e-commerce system.

FIG. 4 illustrates the use of an HGOP system on a “try before you buy” download transaction.

FIG. 5 illustrates the use of an HGOP system on a new user order in response to a marketing campaign.

FIG. 6 illustrates the use of an HGOP system on an order for an existing customer.

FIG. 7 illustrates the user of an HGOP system on an order for a returning customer who has no account on the e-commerce site.

DETAILED DESCRIPTION

A preferred embodiment of the present invention referred to as an HGOP web service is described in detail below. It will be appreciated by those skilled in the art that variations the following is an example embodiment and that other embodiments may be implemented which do not depart from the scope and spirit of the present invention. In one embodiment, an HGOP service allows a merchant web site to host its own product catalog and shopping cart, but post the information from the shopping cart to the commerce system cart in one XML-formatted WSDL transaction at checkout time. The use of SSO technology allows the system to match the customer's information transmitted in the transaction with the information in its accounts, preload the existing customer information, maintain synchronization between the merchant store and accounts and the e-commerce system customer accounts. It also facilitates transparency to the customer when s/he is redirected to the commerce system upon posting the shopping cart contents and avoids the annoying need to sign in to more than one system and create more than one account.

One embodiment of anHGOP system100 is illustrated inFIG. 1. A customer operating aclient computing device102 accesses a merchant's web site andsystem104 via a pre-existing communication network (e.g., the internet, a cellular data network, or any other data network). In an exemplary embodiment, the merchant may host the product catalog and virtual shopping cart on itssite104. When a customer clicks on a purchase button or otherwise indicates that s/he is committing to a purchase, the merchant system generates and transmits anXML request106 to an e-commerce system hosted on at least oneweb server108. The XML request may be similar to the CreateCartRequest described in Table 1, below, which conforms to the schema described in Table 2. In creating this request, the merchant system might use a PGP key and posting end point provided to the merchant by thee-commerce system108. Use of the PGP key ensures that the contents of the cart and the customer's personal information are encrypted and passed securely to the e-commerce system server. The posting end point allows a distributed e-commerce system to direct the traffic to a particular server.

Providing the merchant with the posting endpoint URL serves several purposes. It directs the transaction to the commerce system; however, if the commerce system operates multiple servers in world wide locations, the direct can be made to the server most appropriate to the customer's region. In one embodiment, the URL end point allows the e-commerce system to redirect the customer to a local server. For example, if the customer is located in Europe the end point could direct the customer to the nearest e-commerce server, located in, for example, Ireland rather than Canada. This provides an efficient and highly performant load balancing effect. It also allows a great deal of flexibility in supporting world-wide payment options.

The e-commerce system may respond to the XML request with asimple HTML form110, populated with the customer information as provided in the XML request, or pulled from the customer's e-commerce account. Additionally, the form may contain a single hidden HTML parameter, called “message,” and assign the results obtained above as its value. When the user submits the form with an HTTP request to the URL, it is posted to its assigned end point.

In an embodiment of this invention thee-commerce system108 provides authentication and the full spectrum of back-end order processing, including checkout, account management and fulfillment and distribution. Data may be stored on both sides of the transaction—in both themerchant system104 and the

e-commerce system

108,114. Sales records may be created in the

e-commerce system database

112,114 and could be accessible to the customer from the merchant'sweb site104 using SSO technology, allowing the customer to search his/her order history from the merchant site.

SSO is used to make the entire process transparent to the user and to keep the accounts on both systems in sync. Themerchant system104 passes the user login information to thecommerce system108 in theXML request106, or WSDL file. If the customer is a known customer, the system logs in the user, processes the order within the indicated account and prepopulates theHGOP form110 with the customer information. If the customer is new, the system creates a new account and processes the order within the new account. In this way, the commerce system is able to maintain a complete order history for the customer. In addition, account and order management functions may be performed at the application service provider (ASP) level.

CreateCartRequest

In the preferred embodiment, web services are provided for managing order processing in a commerce system through the use of an invoker application programming interface (API) or WSIF. A web service user may specify a number of input parameters for the invoke method of the API to invoke a specific commerce server operation. The input parameters in the illustrative examples that follow include a WSDL definition file location, the name of operation to be invoked, necessary parameters for the operation, a user name, and a password for accessing thecommerce server108 resource. The invoker API utilizes the WSIF to invoke commerce server operations dynamically as specified in the WSDL file.

The WSDL file of an embodiment of an HGOP contains just one function—the OrderService.CreateCart( ). This function sends order details to the commerce system by accepting the order contents (e.g., language, site, line items, product information, prices etc.) and returning the order ID and a redirect URL for the customer to complete the order.

A createCartRequest message of this type would be used to create a shopping cart in the commerce system and allow:

- Products to be added to the cart;
- Cart language and product language to be set;
- Authentication of the user;
- Additional information to be attached to the order or line items; and
- Customers to complete the order in their browser.

In one embodiment, where themerchant104 hosts the entire product catalog and pricing functions, client-driven pricing can be implemented by passing a LineltemPricelnfo structure for each line item. Since this information may not be verified on thee-commerce108 side, independent measures should be established to ensure that prices cannot be spoofed by unauthorized parties.

The following provide examples of XML and XSD for some of the functions of the system. It will be appreciated by those skilled in the art that other XML code could be devised that performs the same functions without departing from the scope and spirit of the present invention.

Within the XML sample software code, certain XML Schema Definitions (XSD) are identified. Tables 1 and 2 provide sample XSD software code that may be utilitized with the WSDL and XML in accordance with one embodiment of the present invention and its associated schema definitions. Generally, XSD software code specifies how to formally describe the elements in an XML document. This description can be used to verify that each item of content in a document adheres to the description of the element in which the content is to be placed.

TABLE 1

CreateCartRequest
Sample Code

	<?xml version=“1.0” ?>
	- <createCartRequest
	xmlns=“http://integration.digitalriver.com/HGOP2-1”>
	<externalReferenceID>order1234</externalReferenceID>
	<siteID>mysite</siteID>
	<locale>en_us</locale>
	<programID>112200</programID>
	- <user>
	<externalReferenceID>user1234</externalReferenceID>
	<loginID>testuser@digitalriver.com</loginID>
	<password>abc1234</password>
	<authenticate>true</authenticate>
	</user>
	- <billToAddress>
	<companyName>Digital River, Inc</companyName>
	<name1>John</name1>
	<name2>Doe</name2>
	<line1>9625 West 76th Street</line1>
	<line2>Suite 300</line2>
	<line3 />
	<city>Eden Prairie</city>
	<state>MN</state>
	<postalCode>55344</postalCode>
	<countryCode>US</countryCode>
	<email>jdoe@digitalriver.com</email>
	<phone1>952-253-1234</phone1>
	<phone2 />
	<fax />
	</billToAddress>
	- <shipToAddress>
	<companyName>Digital River, Inc</companyName>
	<name1>John</name1>
	<name2>Doe</name2>
	<line1>9625 West 76th Street</line1>
	<line2>Suite 300</line2>
	<line3 />
	<city>Eden Prairie</city>
	<state>MN</state>
	<postalCode>55344</postalCode>
	<countryCode>US</countryCode>
	<email>jdoe@digitalriver.com</email>
	<phone1>952-253-1234</phone1>
	<phone2 />
	<fax />
	</shipToAddress>
	- <lineItems>
	- <lineItem>
	<quantity>1</quantity>
	- <product>
	<externalReferenceID>sku1234</externalReferenceID>
	<productID>123456789</productID>
	<companyID>mycompany</companyID>
	</product>
	- <priceOverrideInfo>
	- <price>
	<type>unit</type>
	<currencyCode>USD</currencyCode>
	<amount>19.95</amount>
	</price>
	</priceOverrideInfo>
	- <lineItemExtendedAttributes>
	- <lineItemExtendedAttribute>
	<name>color</name>
	<value>red</value>
	</lineItemExtendedAttribute>
	</lineItemExtendedAttributes>
	</lineItem>
	</lineItems>
	- <offers>
	- <offer>
	<offerID>1222333</offerID>
	</offer>
	</offers>
	- <payment>
	- <customer>
	<first>John</first>
	<middle>Henry</middle>
	<last>Doe</last>
	</customer>
	- <creditcard>
	<type>visa</type>
	<number>24234234124312</number>
	<expirationMonth>11</expirationMonth>
	<expirationYear>2007</expirationYear>
	<securityIndicator>724</securityIndicator>
	<issueNumber>00</issueNumber>
	<issueMonth>01</issueMonth>
	<issueYear>2007</issueYear>
	</creditcard>
	- <paymentExtendedAttributes>
	- <paymentExtendedAttribute>
	<name>new payment method</name>
	<value>1234</value>
	</paymentExtendedAttribute>
	</paymentExtendedAttributes>
	</payment>
	- <taxInfo>
	<taxExempt>true</taxExempt>
	<buyerVatNumber>1341234123</buyerVatNumber>
	</taxInfo>
	- <test>
	<testOrder>true</testOrder>
	<sendEmail>true</sendEmail>
	</test>
	</createCartRequest>

In general, a schema is an abstract representation of an object's characteristics and relationship to other objects. An XML schema represents the interrelationship between the attributes and elements of an XML object (for example, a document or a portion of a document). To create a schema for a document, the structure of the document is analyzed, and each structural element is defined as it is encountered. For example, within a schema for a document describing a web site, a web site element, a web page element, and other elements that describe possible content divisions within any page on that site are defined. Elements may be defined within a set of tags. Table 2 is an exemplary schema for one embodiment of an HGOP request.

TABLE 2

Schema Components Table

		Null
Elements	Types	OK?	Definition

externalReferenceID	string	false	The client generated unique identifier for this order.
siteID	string	false	The e-commerce siteID of the site the
			customer is buying from.
locale	string	false	The requisition's locale. In the form of
			language + “_” + region.
programID	string	false	The e-commerce programID used for
			tracking purposes.
user	User	false	Information about the user placing this order.
billToAddress	common:	false	Billing Address for the order.
	AddressInfo
	(Version 1)
shipToAddress	common:	false	Shipping Address for the order. If empty
	AddressInfo		the billToAddress should be used.
	(Version 1)
lineItems	LineItems	false	Contains order line items. At least one
			line item should be included in this
			array.
offers	Offers	false	Use this xsd:element, if you want to
			define your order level incentives. If this
			xsd:element is skipped, the e-commerce
			system will determine the incentives if
			applicable for the order in consideration.
payment	Payment	false	Order payment information.
taxInfo	TaxInfo	false	Allows you to specify a taxExempt
			status and provide a buyer VAT
			Number.
test	Test	false	Allows you to place a test order and
			toggle options about it.
extendedAttributes	Extended	false	A place to pass client specific
	Attributes		name/value pairs.
externalReferenceID	string	false	The client generated unique identifier for
			this user.
loginID	string	false	The e-commerce loginID for the
			customer who placed this order.
password	string	false	A password is required when setting
			authenticated to ‘true’. An MD5 hash or
			equivalent is fine but the plaintext
			version is required if you actually want
			the customer to be able to log into the e-
			commerce site.
authenticated	boolean	false	Setting authenticated to ‘true’ asserts that
			the user has already been authenticated
			(on another system). Therefore, the e-
			commerce system will not ask the user to
			sign in again or to create a new account.
			In the case that the user does not exist on
			the e-commerce system site a password
			must also be supplied. Defaults to ‘false’.
lineItem	LineItem	false
offer	Offer	false
customer	Customer	false
creditcard	Creditcard	false
paymentExtended-	Payment	false
Attributes	Extended-
	Attributes
taxExempt	boolean	false	flag in expectation that we can not
			charge tax and code this up later [true,
			false]
buyerVatNumber	string	false	A place to supply the buyer vat number.
			Otherwise, under EU law, the e-
			commerce system is required to apply
			VAT to all products which are delivered
			by email or electronic download to
			customers who are located in an EU
			country. In the form, (country code + “ ” +
			vat number).
testOrder	boolean	false	Used to create a test order. Test orders
			do not get committed in production.
			Defaults to “false”. [true, false]
sendEmail	boolean	false	Email will be sent out if this is set to
			true. Defaults to “true”. By default,
			email will be sent out. [true, false]
quantity	int	false	The quantity of product on the line item.
product	Product	false
priceOverrideInfo	PriceOverrideInfo	false
lineItemExtended	LineItemExtended	false	Additional attributes for a line item as
Attributes	Attributes		name/value pair.
offerID	string	false	The E-commerce id of the order-level
			discount.
couponCode	string	false	Provides another way of referring to an
			order-level discount.
first	string	false	Customer's first name.
middle	string	false	Customer's middle name.
last	string	false	Customer's last name.
type	string	false	Contains the type of credit card used in
			the transaction. For example, visa,
			mastercard, discover,
			american express, diners club, jcb,
			maestro card, switchcard.
number	string	false	Contains the plaintext credit card
			number that is used in the transaction.
expirationMonth	string	false	2 digit month. [01, 02, 03, 04, 05, 06, 07,
			08, 09, 10, 11, 12]
expirationYear	string	false	4 digit year.
securityIndicator	string	false	CVV/CID code for visa, master,
			discover and americanExpress card.
issueNumber	string	false	2 digit issue number of switch card.
issueMonth	string	false	2 digit issue month for switch card. [01,
			02, 03, 04, 05, 06, 07, 08, 09, 10, 11, 12]
issueYear	string	false	4 digit issue year for switch card.
paymentExtended	PaymentExtended	false
Attribute	Attribute
externalReferenceID	string	false	The client generated unique identifier for
			this product.
companyID	string	false	E-commerce's unique id for the company
			who owns this product.
productID	string	false	E-commerce's unique id for the product.
price	Price	false
lineItemExtended	LineItemExtended	false
Attribute	Attribute
name	string	false
value	string	false
type	string	false	unit = “The per unit cost for the products
			in this line item. This includes contract
			discounts (buyer side contract discounts
			which is rare), and excludes all other
			discounts. It should be the same as
			ListPrice if there are no contracts.” [unit]
currencyCode	string	false	See the ISO 4217 maintenance agency
			(http://www.bsi-global.com/iso4217currency)
			for more information, including a table of
			currency codes.
amount	string	false
name	string	false
value	string	false
extendedAttribute	ExtendedAttribute	false
name	string	false
value	string	false

Use Cases

The flowcharts inFIGS. 2 and 3 describe a preferred

embodiment HGOP process

200 and300 and its associated processes. Referring toFIG. 2, the customer navigates to the merchant web site and adds items to thecart202. When the customer is ready to commit to an order, s/he submits the cart forprocessing204. If the customer has placed an order previously and has an account on bothsystems206, the merchant's system generates theencrypted XML request208 and transmits it to thee-commerce system210 with the customer's unique identifier and username. If the customer is new and not authenticated on the merchant system, the customer is redirected207 to a user account creation/edit process300 shown inFIG. 3. The e-commerce system receives, decrypts and processes therequest212. SSO logs the user in to both systems. The e-commerce system presents the checkout/landing page214 with the URL pointing to the local server, if more than one server is available. The e-commerce system allows the customer to verify his personal information (e.g. billing address) and verify theorder216. If the customer chooses to update the personal information, the system updates the customer's account accordingly218. The user remains authenticated throughout the verification andupdate process220. When the verification is complete, the customer confirms the order and receives a thank you page. The e-commerce system sends an order notification to thecustomer222, and also sends amessage226 to the merchant system with the details of the order using a standard processedorder XML message224. The merchant system updates its records for the customer/order.

FIG. 3 illustrates theprocess300 that occurs when a customer has not been authenticated on the merchant system. This might happen if a first time customer is making a purchase, or if the customer has an account on the merchant system, but not on the e-commerce system. SSO services may be used to login or create new users and ensure that both sytems are synchronized with user accounts. Building on theshopping process207 shown inFIG. 2, theHGOP request306 generated by themerchant site304 and received by thee-commerce site308 in this case does not pass login information, the checkout/landing page310 will expose login and new account fields. The customer may uselogin credentials312 from the merchant system, or create an account on thee-commerce system322. If the customer uses merchant-system credentials, the e-commerce system will send anXML API314 to retrievecustomer login information316, and will update the system and display it on the checkout page. If the customer chooses to create anew account322, one may be created on the e-commerce side and the new account information is passed from thee-commerce system324 to themerchant system326. The process continues withorder verification216 as described above.

FIGS. 4 through 7 illustrate some of the various scenarios in which the HGOP may be used. These different scenarios demonstrate the flexibility offered by the HGOP system for a product such as downloadable software; however, those skilled in the art will appreciate that the system may be used for any type of product and fulfillment method. In addition, any number of services may be provided by the e-commerce system, depending on the desired configuration of services or needs of the merchant (payment processing, fulfillment and distribution, digital rights management, etc).

FIG. 4 illustrates an example of a “try before you buy”conversion process400. In this example, a prospect orcustomer402, located in any part of the world, decides to purchase a digital product that it had previously downloaded and logs into the merchant web site. The customer in this scenario has an account on both systems from the previous “try” transaction. The merchant presents all product information to the

customer

404,406. The customer is redirected to thee-commerce cart408 with a merchant identifier so that the order may correctly be placed against the merchant's store. As noted earlier, an HGOP system managed by an e-commerce provider with multiple servers located throughout the world can pull the location information from the posting URL and use it to direct the customer to the nearest server to provide load balancing and the ability to offer benefits related to the geographic location of the customer, such as payment options. A customer may be identified on the e-commerce system by the merchant-assigned memberID (external reference id)408. If the customer is found on the e-commerce system, customer account information is preloaded into the form. The e-commerce system can collect any additional customer purchasing information, process the payment, and send the software license entitlement back to thecustomer410. The merchant may then fulfill the purchasedlicense404. In this scenario, the memberID is passed back from the e-commerce system so that the entitlement is included in the merchant's existingcatalog412. Alternatively, the e-commerce system may fulfill the product.

FIGS. 5,6 and7 (500,600,700) illustrate the same process for alternative customers and scenarios. Each uses the HGOP interface for a slightly different purpose. InFIG. 5, anew customer502 decides to make a purchase based on a marketing campaign for which an e-mail address was required. S/he loads the cart with the desireditems504, and submits the order. The e-commerce system presents the HGOP page with product details and the form to collect customer information. Once the order data is completed, the e-commerce system creates anaccount506 and uses a standard API to notify the partner that order is complete508, and the partner creates thecustomer account510 and sends an e-mail to the customer with information on downloading theproduct512.

InFIG. 6, theprocess600 is essentially the same; the customer has an account the e-commerce system from a previous transaction. Thecustomer602 fills its cart and submits the order. The prepopulated form is presented to the customer, the customer confirms and the verify order page is displayed604 to complete the customer's experience. The system then uses a standard order notification API to notify the merchant of the order details606, and the merchant processes the account on its

side

608,610,612 as per its normal procedures.

InFIG. 7, again, thebasic process700 is the same. The customer places items in thecart704, and the merchant requests the HGOP page, which is displayed with product details and a blank form for collectingcustomer information706. In this case, the e-commerce system might be creating an account for a previously existing customer of the merchant site (in other words, the customer has a merchant account, but not an e-commerce account). The HGOP displays the verify order and thank you pages to the customer to complete the customer experience. The e-commerce system returns the order details to the merchant using a standardorder confirmation API708. The merchant may choose to merge the accounts on itssystem710 or continue to match based on a field such as e-mail address. Subsequently, the merchant sends an e-mail to the customer with information on downloading theproduct712

The type of Web services described are preferably implemented in a data processing system configured as a server in accordance with an embodiment of the contemplated invention. The data processing system may be a symmetric multiprocessor (SMP) system including a plurality of processors and connected to system bus. Alternatively, a single processor system may be employed. Also connected to system bus is memory controller/cache, which provides an interface to local memory. An I/O bus bridge is connected to system bus and provides an interface to the I/O bus. Memory controller/cache and the I/O bus bridge also may be integrated together. A peripheral component interconnect (PCI) bus bridge connected to the I/O bus provides an interface to a PCI local bus. Communications links to clients may be provided through a network adapter connected to the PCI local bus. A memory-mapped graphics adapter and hard disk may also be connected to the I/O bus. Those of ordinary skill in the art will appreciate that the hardware described above may vary. For example, other peripheral devices, such as optical disk drives and the like, also may be used in addition to or in place of the hardware depicted. The example described is not meant to imply architectural limitations with respect to an embodiment of the present invention.

Instructions for the operating system, the object-oriented programming system, and applications or programs are located on storage devices, such as the hard disk drive, and may be loaded into memory for execution by a processor. The processes of an embodiment of the present invention are performed by a processor using computer implemented instructions, which may be located in a memory or in one or more peripheral devices.

It is to be understood that even though numerous characteristics and advantages of various embodiments of the present invention have been set forth in the foregoing description, together with details of the structure and function of various embodiments of the invention, this disclosure is illustrative only, and changes may be made in detail, especially in matters of structure and arrangement of parts within the principles of the present invention to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, the particular elements may vary depending on the particular application for the Web interface such that different dialog boxes are presented to a customer that are organized or designed differently while maintaining substantially the same functionality without departing from the scope and spirit of the contemplated invention.