CA 02328807 2000-12-19
METHOD AND SYSTEM FOR SECURE DATA TRANSMISSION
BACKGROUND OF THE INVENTION
1. Field of Invention
The present invention is directed to a method and system for secure
transmission
of data across an unsecured network. More particularly, transmission is
performed with
the ability to identify both the party sending a software object and the party
receiving the
software object prior to processing the data in the software object.
2. Description of Related Art
Conventional eCommerce systems enable a computer operated under the control
of a merchant to obtain information offered by a customer and transmitted by a
computer
operating under the control of the customer over a publicly accessible packet-
switched
network, e.g., the Internet, to the computer operating under the control of
the merchant,
without risking exposure of the information to interception by third parties
that have
access to the network and to assure that the information is from an authentic
source.
Conventional eCommerce systems also enable merchants to transmit information,
including a subset of information provided by the customer, over a network to
a payment
gateway computer system, such as a dedicated financial server, that is
designated by a
bank or other financial institution. Such information is transmitted so that
the financial
institution can provide payment on behalf of the customer without the risk of
exposing
that information to interception by third parties. Such institutions include,
for example,
financial institutions offering credit or debit card services.
Conventional eCommerce systems have provided secure transmission channels
using secure payment technology such as Secure Electronic Transaction
(hereinafter
"SET"), jointly developed by the Visa and MasterCard card associations, and
described in
Visa and MasterCard's Secure Electronic Transaction(SET) Specification, Feb.
23, 1996.
Other such secure payment technologies include Secure Transaction Technology
("STT"),
Secure Electronic Payments Protocol ("SEPP"), and Internet Keyed Payments
("IKP).
However, such secure payment technologies require the customer to operate
software that
CA 02328807 2000-12-19
2
is compliant with the secure payment technology, interacting with financial
institutions,
thereby requiring the customer to interact with a third party who subsequently
provides
encoded information to the merchant.
In other words, a customer communicates directly with both a merchant and a
server of a financial payment certification authority, e.g., a credit card
company.
Subsequently, based on the information provided by the customer to the
financial
payment certification authority, the authority communicates with the merchant
to provide
some certification of payment authorization. Therefore, to date, such schemes
have not
been readily adopted because they are inconsistent with a real-world
transaction model in
which a customer purchases a product using credit only after a merchant has
taken steps
to ensure that the customer's credit is sufficient for the purchase.
Alternatively, another attempt to provide secure transmission channels for
eCommerce transactions is a general purpose communication protocol such as
Secure
Sockets Layer (hereinafter "SSL"), which was first introduced into the market
by
Netscape, Inc., as described in Freier, Karlton & Kocher (hereinafter
"Freier"), The SSL
Protocol Version 3.0, March, 1996. SSL provides means for secure transmission
between
two computers. SSL has the advantage that it does not require special-purpose
software
to be installed on the customer's computer because it is already incorporated
into widely
available software that many people utilize as their standard Internet access
medium and
does not require that the customer interact with any financial payment
certification
authority.
SSL is designed to only validate one of the two parties participating in the
online
transmission. Thus, it does not require, nor facilitate, the validation of the
sender; it only
provides validation of the server. Server-to-server eCommerce systems require
the
validation of both parties which participate in the transaction. Other
examples of general-
purpose secure communication protocols include Private Communications
Technology
("PCT") from Microsoft, Inc., Secure Hyper-Text Transport protocol ("SHTTP")
and
Pretty Good Privacy ("PGP") which meets the IPSEC criteria.
CA 02328807 2000-12-19
Financial institutions desire an Internet payment processing scheme that
emulates
existing Point of Sale (POS) applications that are currently installed on
their servers, and
that requires minimal changes to their network systems. The minimization of
network
system changes is a critical requirement since any downtime for a financial
institution's
server system represents an enormous expense. However, Internet-based payment
processing applications require additional security measures that are not
found in
conventional POS terminals. This additional requirement is necessitated
because Internet
communication is performed over publicly accessible, unsecured communications
lines in
stark contrast to the private, secure, dedicated phone or leased line service
utilized
between a traditional merchant and a financial institution. Thus, it is
critical that any
payment processing scheme utilizing the Internet for a communication backbone
employ
some form of cryptography or some type of digital signature to further ensure
security.
Open Market International offers SecureLink Commerce Architecture that
connects transaction participants using secure, standards-based commerce
objects; that is,
Digital Offers, Digital Receipts, Digital Tickets, Digital Coupons and Digital
Queries
which require no custom coding, are secure and can be embedded in a HyperText
Markup
Language (HTML) or HyperText Transfer Protocol (HTTP) capable medium. The
SecureLink Commerce Architecture provides online customer authentication and
authorization, online order and payment processing, automated tax and shipping
calculations, online order tracking and status and online customer service.
Open Market
International provides increased security using digitally signed Universal
Resource
Locators (URLs). Such a scheme uses a symmetric key generated by a payment
gateway,
i.e., the eCommerce service provider server. This key is used during
transactions to
digitally sign data communicated to and from the eCommerce service provider
server and
the merchant server.
However, the symmetric key is generated at the eCommerce service provider
server and needs to be transmitted to participating merchants. The symmetric
key must
be regenerated on a periodic schedule. As a result, computer architecture
located at the
eCommerce service provider server must perform the extensive task of
maintaining and
CA 02328807 2005-02-16
4
updating all the symmetric keys to ensure security. Also, conventional
digitally signed
URL technology is client-based, which requires that a consumer's browser re-
direct to an
eCommerce service provider server to interact with the eCommerce service
provider.
Additionally, use of digitally signed URL technology is limited by the size of
the Query
String parameter, utilized in an HTTP GET operation. The Query String is
required as
part of an HTTP GET, in order to send options to a server. The Query String
has a size
limit, which is approximately 2K. Further, there are practical limits to the
ability to
provide highly structured data streams, because of both the size limitation
and the
potential for proxy servers to mangle the data.
Alternatively, Cybercash~ provides payment authentication services and
software and provides access by merchants to their service via the Internet.
The
Cybercash~ eCommerce transaction scheme requires that a merchant download
software
from the Internet without charge. The merchant can actually develop their
entire catalog
and buyer-flow application, utilizing this software. Cybercash~ allows
merchants to
access the service in "test mode", without paying any fees. However, when the
merchant
decides to collect real payments then Cybercash~ starts collecting a fee. Many
Internet
Service Providers support Cybercash~ because it does not cost them any up-
front fee.
Thus, Web site developers are supportive of Cybercash~ technology. However,
merchants are less satisfied with the service because fees are quite high and
back-office
tools, e.g., tax and shipping calculation tools, can be difficult to integrate
within existing
business processes.
SUMMARY OF THE INVENTION
The present invention is directed to a method and system for providing
eCommerce services that is both secure and supports a highly structured data
interface,
utilizing an XML framework. According to the exemplary embodiment of the
invention,
an internal state of a software object is transmitted across an unsecured
network between
a merchant and an eCommerce service provider, wherein both the party sending
the
CA 02328807 2005-02-16
software object and the party receiving the software object are identified
prior to the
information contained in the object being processed by the receiving party.
An exemplary embodiment of the invention, hereafter referred to as "ECML"
(Electronic Commerce Markup Language) language, operates to format, digitally
sign and
encrypt the information transmitted to an ECML-enabled eCommerce service
provider.
(ECML is not to be confused with the Electronic Commerce Modeling Language,
which
is a completely different standard, designed primarily to support e-wallet
development.)
In accordance with one aspect of the present invention there is provided a
method
for providing eCommerce services, the method comprising: generating a software
object;
formatting the software object; digitally signing using a digest of clear text
of data within
the software object; encrypting at least one field within the software object
using public
key cryptography; passing the software object across an unsecured network
between a
merchant server and an eCommerce service provider server; and processing the
software
object by the eCommerce service provider server; wherein both the merchant
server and
the eCommerce service provider server are identified prior to the step of
processing the
software object by the eCommerce service provider server.
In accordance with another aspect of the present invention there is provided a
system for providing eCommerce services, the system comprising: an eCommerce
service provider server including a first software component and a first XML
processor; a
first link coupled between the eCommerce service provider server and a
publicly
accessible packet-switched network; a second link between the eCommerce
service
provider server and a private network; wherein the eCommerce service provider
server
receives software objects, generated by a second software component by request
of a
second XML processor at a merchant server, from the merchant server via the
first link
and the publicly accessible packet-switched network and wherein the first
software
component generates a modified software object at the request of the first XML
processor
and the eCommerce service provider server transmits the modified software
object to the
merchant server via the first link and the publicly accessible packet-switched
network.
CA 02328807 2005-02-16
Sa
The present invention provides an opportunity to perform secure eCommerce
transactions between two server machines without using a private, secured
network for
transmission of transaction data between a merchant server and an eCommerce
service
provider server.
BRIEF DESCRIPTION OF THE DRAWINGS
The exemplary embodiment of this invention will be described in detail, with
reference to the following figures, wherein:
Fig. 1 illustrates a system for secure data transmission according to the
exemplary
embodiment of the invention;
Fig. 2 illustrates the physical structure of an XML document;
Fig. 3 illustrates the logical structure of an XML document illustrated in
Fig. 2;
and
Fig. 4 illustrates a method of provisioning and performing an eCommerce
service
in accordance with the exemplary embodiment.
DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS
Design of ECML allows it to be dynamically extensible. Therefore, in
accordance
with the exemplary embodiment of the invention, an eCommerce service provider
has the
ability to distribute a software object, e.g., including a service software
improvement, to a
retailer without having to ship, i.e., hand deliver, a new software object
every time an
eCommerce feature is added. By utilizing the invention, an eCommerce service
provider
can add features and functionality without requiring an entire overhaul of the
merchant's
ECML client software. Such additions are possible because ECML provides a
format for
CA 02328807 2000-12-19
6
transmission of information by establishing a definition for structuring data
rather than a
definition for all data elements. Thus, support for new data elements can be
added by the
eCommerce service provider, without requiring completely new software on the
client
server.
Figure 1 illustrates a system for secure data transmission according to the
exemplary embodiment of the invention. In accordance with the exemplary
embodiment
of the invention, when prompted, a merchant server 110 uses ECML-based client
software components 112 to generate an ECML-based software object 111 that is
transmitted to the eCommerce service provider server 120 using a publicly
accessible
packet-switched network 130.
As shown in Fig. 1, the system architecture 100 includes at least one merchant
server 110 coupled to an eCommerce service provider server 120 via a public
network
130, e.g., the Internet. It should be appreciated that the public network is
an unsecured
network, as that term is commonly understood in the art. Therefore, data
transmitted
between the merchant server 110 and the eCommerce service provider server 120
is
protected using methods in accordance with the exemplary embodiment of the
invention.
The eCommerce service provider server 120 is also coupled to a firewall 150
through a communication link 140. The firewall 150 is also coupled to any
number of
financial institution servers 170 via communication links 160. It should be
appreciated
that communication links 140 and 160 can be any known or later developed
device or
system for connection, including a direct cable connection, a connection over
a wide area
network or a local area network, a connection over an intranet, a connection
over the
Internet, or a connection over any other distributed network or system.
Further, it should
be appreciated that the communication links 160 and 140 can each be a wired or
a
wireless communication link to a network. It is preferred that communication
links 140
and 160 are communication links forming part of secure networks.
Both the merchant server 110 and the eCommerce service provider server 120
include software modules called Extensible Markup Language (XML) processors
113 and
123, respectively, that read XML documents and provide access to their content
and
CA 02328807 2000-12-19
7
structure. XML processors 113 and 123 work on behalf of other modules, called
applications 114 and 124, also incorporated on the servers 110 and 120,
respectively.
ECML delivers powerful eCommerce components to merchants selling goods and
services on the Internet. These components connect online merchants to fast,
scalable
and reliable Internet eCommerce services, e.g., AT&T's SecureBuy. ECML is a
specification used by a combination of software components, application
programming
interfaces (APIs) and service platforms to connect a merchant store, i.e.,
merchant server
110, to various payment systems, i.e., financial institution servers 170.
The eCommerce service provider server 120 validates the software object 11 l
and
instantiates a local software object 125 on the eCommerce service provider
server 120
with the internal state of the transmitted software object 111. The eCommerce
service
provider then processes the data contained in the software object 111 and
returns a
modified software object state 121 to the merchant.
Part of processing the data involves obtaining transaction authorization from
a
1 S financial server 170 on a secure network 160. The software object 111
stores data
expressed in a way that the data can be transferred, e.g., using XML. In this
way,
software object data, e.g., the state of a software object, can be transmitted
from the
merchant server 110 to the eCommerce service provider server 120 and
subsequently
transferred to a financial institution server 170, e.g., a credit card
company, and back for
transaction purposes. The local software object 125 at the eCommerce service
provider
server 120 assumes the data state of the merchant's ECML-based software object
111. As
a result, the ECML software component 122 on the eCommerce server 120 acts as
a
gateway to eCommerce transaction systems, e.g., credit card companies that
require
private networks.
The eCommerce server 120 may have frame relay point-to-point links with
financial institution servers 170 or any type of connection that provides
secure
transmission of data. As a result, there are typically no unsecured networks
traversed
between the eCommerce service provider server 120 and the financial
institution servers
170.
CA 02328807 2000-12-19
g
In a method for secure data transmission according to the exemplary embodiment
of the invention, the local software object 125 on the eCommerce service
provider server
120 can call new software objects 126 to add new features. Additionally, the
local
software object 125 can call additional servers 127. Therefore, upgrades and
maintenance
of the eCommerce service provided using the service provider server 120 can be
implemented to more easily distribute functionality throughout multiple
servers.
Additionally, the exemplary embodiment of the present invention improves on
data transmission using conventional digital signature techniques in many
ways. First, by
implementing ECML-based software architecture, an HTTP POST buffer does not
suffer
from conventional buffer size restrictions. Transmission of ECML-based
software
components between the merchant server 110 and the eCommerce service provider
server
120 utilizes HTTP or HTTPS as the transport protocol. ECML client software
running on
the merchant server 110 utilizes an HTTP POST request for all such
transactions. An
ECML data stream is the post buffer of the request. The ECML data stream is an
XML
formatted buffer, not the standard HTTP name value pair POST buffer syntax.
Responses
to requests by the merchant server 110 from the eCommerce service provider
server 120
return to the merchant server 110 as a standard HTTP response from a POST
request.
The format of responses from the eCommerce service provider server 120 are
also in
XML, not HTML. Implementation of the exemplary embodiment of the invention
encrypts a number of fields using Public Key cryptography. Additionally, the
merchant's
digitally sign messages to the eCommerce service provider server 120. Such
messages
are signed using a digest of the clear text of the message. This requires that
the
eCommerce service provider server 120 decrypts the encrypted values before it
can verify
the signature of the merchant.
It is preferable that the present invention utilize public/private key
cryptography,
which does not require regeneration of the encryption keys.
The exemplary embodiments of the invention are server-based. Therefore,
methods and systems designed according to the invention focus on interaction
between
two servers. Hence, a user's browser is not involved in an ECML-based
conversion
CA 02328807 2000-12-19
9
between the eCommerce service provider server 120 and the merchant server 140.
Accordingly, implementing the present invention provides secure data
transmission
between server machines. Such an implementation allows the eCommerce service
provider to improve overall response time because the eCommerce service
provider
server is no longer burdened with rendering an HTML user interface for
browsers.
Another advantage of the present invention stems in part from the use of XML
vocabulary --upon which ECML is based-- which puts a highly structured
framework
around the data to be transmitted. This structure allows for nested data
elements, which
are not possible with standard URL or POST buffer encoding techniques.
The exemplary embodiment of the invention provides an interface that can
handle
all activities related to eCommerce. Such activities include "add items to a
network
shopping cart", online authorizations and settlement. The exemplary embodiment
of the
invention uses XML and HTTP to communicate directly between the merchant
server and
the eCommerce service provider server. Therefore, no browser is involved and
no
graphical user interface must be generated for personal review.
XML describes a class of data objects called XML documents and impacts the
document parsing behavior of applications that process them. XML is an
application
profile or restricted form of the Standard Generalized Markup Language (SGML),
which
is the international information coding standard to which HTML belongs. HTML
is an
application of SGML and is focused primarily on the presentation aspects of
Web pages.
By construction, XML documents are conforming SGML documents. XML was
developed by an XML Working Group formed under the auspices of the World Wide
Web Consortium (WC3) in 1996.
Traditionally, the term "document" has been associated with items such as
manuals, letters and proposals as well as invoices, purchase orders and travel
requests.
Forms-based information tends to be closely aligned with business transactions
having
numerical content. Document-based information tends to be used for requests
for
proposals (RFPs), contracts and so on. However, both of these business
communication
media are comprised of content arranged according to some predefined
structure.
CA 02328807 2005-02-16
With the influence of the World Wide Web, the properties of traditional forms
and documents are converging into dynamic business transactions. These
transactions
may be used to interchange a wide range of material including product
information,
pricing proposals and financial and legal settlements. These transactions can
be
5 dynamically constructed from data in relational databases and can include
descriptive text
and graphics from document management systems.
As depicted in Fig. 2, an XML document may be, for example, the text of a
printed work or a set of database records. In essence, an XML document may be
viewed
as a data object meeting certain criteria. Each XML document has both a
logical and a
10 physical structure. Figure 2 illustrates the physical structure of an XML
document.
Physically, the XML document 200 is composed of units 210 call entities. An
entity 210
may refer fo other entities 220 to cause their inclusion in the document 200.
An XML
document 200 begins in a "root" or document entity 230.
Figure 3 illustrates the logical structure of an XML document 200. Logically,
the
XML document 200 is logically composed of a declaration 310, elements 320,
comments
330, character references 340, and processing instructions 350, all of which
are indicated
in the document 200 by XML. The logical and physical structures must also nest
properly. An attribute 325 is a property of an element 320. Often attributes
325 are used
to convey information about the element 320 and hence can be said to provide
metadata
for the elements 320.
Referring again to Fig. 2, the entities 210 included in an XML document 200
contain either parsed data 240 or unparsed data 250. Therefore, these entities
210 act as
virtual storage units. An XML document 200 is often a separate file, but may
be a string
or even a database record. Parsed data 240 are made up of characters, some of
which
form character data 260 and some of which form markup data 270. Markup data
270
encodes a description of the XML document's storage layout and logical
structure as
shown in Fig. 3. XML provides a mechanism to impose constraints on the storage
layout
and logical structure of the stored data.
CA 02328807 2000-12-19
11
To qualify as an XML document, a data object must be well-formed. A data
object is well-formed if, taken as a whole, it contains one or more logical
elements 320,
the boundaries of which are either delimited by start-tags and end-tags or,
for empty
elements, by an empty-element tag. Also there must be exactly one root element
or
document element 230, as shown in Fig. 2, no part of which appears in the
content of any
other element 230. Additionally, to be well-formed, each of any of the
entities 210
containing parsed data 240 that is referenced directly or indirectly within
the document
must also be well-formed.
In the exemplary embodiment of the invention, ECML is an XML-based markup
language used to define eCommerce conversations between servers 110, 120 and
170.
ECML acts as an eCommerce middleware, which eliminates the tightly coupled
connection that conventional eCommerce systems require merchants to have with
payment processing mechanisms. ECML provides an abstraction of various
eCommerce
functions. The merchant who utilizes ECML-based components does not need to
implement the unique requirements of a particular payment processing
application.
Rather, the merchant server 110 communicates with a payment service, i.e., a
financial
institution server 170, using ECML-based software components 112. It should be
appreciated that the ECML-based software component 112 may be implemented into
a
new or existing Web-based eCommerce processing application architecture.
Accordingly, ECML is the language that the software components 112 at the
merchant server 110 use to communicate with the eCommerce service provider
120. The
ECML-based components 112 allow the merchant to obtain online credit card
authorizations, calculate tax and calculate shipping. The ECML-based
components 112
also support advanced programming interfaces to allow the merchant to perform
back-
office functions, e.g., settling the authorized transactions after the goods
or services have
been rendered. An online merchant may have an application 114 that displays
the catalog
of goods available for sale. Such an application 114 also manages the
customer's
shopping experience, including managing a customer's shopping cart.
CA 02328807 2000-12-19
12
An ECML-based component 112 creates an XML processor object 113 when a
customer decides to purchase goods or services from the merchant. The
merchant's
application 114 calls the ECML-based component 112 and adds the items to be
purchased
from the customer's shopping cart into the component 112. The ECML-based
component
112 then generates ECML data and sends this ECML data to the eCommerce service
provider server 120 in the form of an ECML-based software object 111. The
eCommerce
service provider server 120 then parses the data of the ECML-based software
object 111
and returns the results back to the ECML-based component 112 on the merchant
server
110 in the modified software object 121. Results are interpreted by the
merchant's
application 114, and a result is displayed to the merchant via a graphical
user interface,
not shown, supported by the server 110.
As mentioned above, it is preferable that the exemplary embodiment of the
invention can be implemented using XML. There are two main advantages to using
an
XML-based language.
First, because the use of XML renders ECML extensible, implementation allows
for growth that protects the merchant's investment in software. An eCommerce
service
provider has the ability to distribute a software object corresponding to a
new service
feature to a retailer without having to ship, i.e., hand deliver, an entirely
new software
package every time an eCommerce feature is added. Therefore, by utilizing the
invention, an eCommerce service provider can add features and functionality
without
requiring a complete overhaul of the merchant's ECML client software. Such
additions
are possible because ECML provides a definition for structuring data, rather
than a
definition for all data elements. Thus, support for new data elements can be
added by the
eCommerce service provider, without requiring completely new software on the
client
server.
Second, an XML-based eCommerce service architecture allows third party
vendors to utilize XML to develop components tailored specifically for their
particular
payment processing applications. This capability is especially significant and
beneficial
CA 02328807 2000-12-19
13
because it allows integration of ECML with a broad array of market available
catalog
applications, e.g., those produced by iCat, InterShop and IBM.
Payment processing applications can be as complex to implement as catalog
applications. In addition to the complexity of implementation, operation of
payment
processing applications can also be a significant load on merchant servers
that are already
burdened with rendering dynamic catalog pages from SQL databases. Because the
exemplary embodiment of the invention allows integration of payment processing
applications with catalog applications, further burdening of the merchant
server
infrastructure is limited. Thus, seamless integration of a payment processing
application
with other applications, e.g., catalog and buyer-flow management, results.
A merchant need only integrate a single ECML-based component 112 into his
Web site. This ECML-based component 112 not only obtains online authorization,
but
also calculates tax and shipping costs. In contradistinction, most
conventional
eCommerce service providers require the merchant to integrate additional tax
and
shipping components at the merchant server without integration, thus adding to
the
management burden of the merchant server.
Additionally, the ECML-based components 112 can provide a conventional
interface to perform back-office functions such as settlement and returns.
Thus, the
payment processing is handled by the eCommerce service provider server 120,
which
reduces the complexity of implementing and integration of the various
applications
provided in conjunction with the eCommerce service. As a result, the
throughput of the
merchant server 110 is increased. This is a significant difference from
conventional
eCommerce payment processing application architectures. Although conventional
payment processing applications provide good "buyer" flow integration, back-
office
interfaces are much more difficult to utilize.
Essentially, utilization of ECML-based components 112 enables a merchant to
bring a Web site online faster, with less cost and complexity. ECML-based
payment
processing applications also provide a great deal more scalability and
reliability than the
merchant could afford if he were to implement it on his own.
CA 02328807 2000-12-19
14
ECML-based components 112 also provide necessary security during
conversations between the merchant server 110 and the eCommerce service
provider
server 120. SSL security has generally been implemented between the customer
browsing the Web and the merchant's Web site. SSL is not sufficient to also
secure
server-to-server interaction between the merchant server 110 and the eCommerce
service
provider server 120 because it does not facilitate the authentication of both
parties
involved in the transaction.
Therefore, to provide improved security during server-to-server interaction,
the
exemplary embodiment of the invention uses ECML-based components 112 that
utilize a
Public/Private Key cryptographic system. Such cryptography secures the ECML-
based
conversation between the two servers. This encryption provides both encryption
of the
data as well as validation of the requesting merchant.
The exemplary embodiment of the invention also utilizes digital signature
technology. A digital signature is the network equivalent of signing a message
so that the
identity of the sender and receipt by the recipient cannot be denied. In the
exemplary
embodiment of the invention, the digital signature accomplishes two goals.
First, it
ensures that the message is not tampered with during transmission over the
unsecured
network 130. This is possible because the data within the ECML-based software
object
111 sent to the eCommerce service provider server 120 is utilized as part of
creating and
validating the digital signature. Second, the signature is validated using a
public key that
belongs only to a specific merchant. This ensures that the specific merchant,
or
nominally the holder of the merchant's private key, sent the ECML-based
software
object.
Additionally, according to the exemplary embodiment of the invention,
sensitive
data fields within the ECML-based software object are also encrypted.
Therefore,
sensitive data values are never sent openly on the unsecured network 130.
As a security option, the merchant can also choose to run the ECML-based
conversation via the HTTPS (SSL over HTTP) protocol. This operation encrypts
the
CA 02328807 2000-12-19
entire ECML-based session. However, this operation incurs a performance
penalty
involving speed and memory requirements that some merchants might select to
avoid.
There are five types of ECML-based conversations related to data transmission
between the merchant server 110 and the eCommerce service provider server 120.
As
5 shown in Fig. 4, the method of provisioning and performing an eCommerce
service
begins in step 400 and control proceeds to step 410. In step 410, to obtain
ECML client
software, a public key/private key pair is generated by the ECML-based
software
component 112 at the merchant server 110 and the public key of the public
key/private
key pair is registered with the eCommerce service provider server 120 as being
specific to
10 the merchant server 110. In such a transaction, state information of the
public key is
extracted and sent over the network using HTTP or HTTPS. Control then proceeds
to
step 420.
Transmission of an ECML-based software object 111 utilizes an XML-based tag
structure. Each ECML-based software object contains at least one data block
and a
15 header tag. The data block can contain elements, fields and other data
blocks. Each
ECML-based software object also contains a header tag, which describes the
name and
version, e.g., <ECMLv2.0>. In accordance with XML document structure
requirements
explained above, all opening tags have a corresponding closing tag. The
closing tag for
the example header is d ECMLv2.0>. A data block may, for example, look like:
<ECMLv2.0> opening header tag
<MerchantDataBlock> block opening tag
<MerchantID>www.junk.com</MerchantlD> field or element tag
</MerchantDataBlock> block closing tag
d ECMLv2.0> closing header tag
- CA 02328807 2000-12-19
16
A data block can contain either any number elements or additional data blocks.
The example shown above displays a data block that contains a single element,
i.e.,
<Merchant>D>www.junk.com</Merchant)D>. However, a data block may contain
additional data blocks, for example:
<ECMLv2.0> opening header tag
<MerchantDataBlock> block opening tag
<MerchantID>www.junk.com</MerchantlD> field or element tag
<CardConfig>Pre-Auth Only</CardConfig>
<TaxConfig>Sales</TaxConfig>
</MerchantDataBlock> block closing tag
</ ECMLv2.0> closing header tag
The merchant server 110 initiates registration. The software running on the
merchant server 110 both creates a public/private key pair and also digitally
signs
messages using a SHA 1 message digest. Registration uses cryptographic
standards
defined by RSA data security as PKCS #1.
Performing registration, as in step 410, is primarily designed to provide a
system
for cryptographic key exchange. For a new merchant, this process automatically
provisions the merchant into a test environment on the specified eCommerce
service.
The ECML software-based component 112 on the merchant server 110 generates new
public/private key pairs. Semantics of ECML support the transfer of the public
key
generated by the merchant to the eCommerce service provider server 120. These
semantics also allow the eCommerce service provider server 120 to send an
updated
service public key back to the merchant server 110.
CA 02328807 2000-12-19
17
A sample ECML registration data stream generated by the merchant server 110
and transmitted to the eCommerce service provider server 120 is shown below.
<ECMLv2.0>
<RegisterDataBlock>
<PublicKey>exp=00010001 !mod=490a579142e4562d868f6a9cc48fddac4
959ae8b54121ccad9db110a0ac4d6708c45571e4772f891ca211c045blaada
Ob6e 1b4b450992a7714e8103296f74827</PublicKey>
<MerchantID>e3baf940216fc55154e16f10a9e0fa4cadcb6e318dad7ba55e
ea850bf6d9e169aaf5e4515e85d26b325640e693accae755d3091a51e8b205
d9d 1 a 1 d 1 a8873109</MerchantId>
<HostAddress> 135.25.79.50</IiostAddress>
<Signature>Ofa9baf890d9cd967fa2552f231cb080c4be75bf91dblab3c547
62c975308021398d96c7fade12784d5e9900fd165efc0eddla28dad2944361
916a495b4d8954</Signature>
</RegisterDataBlock>
</ECMLv2.0>
In the above exemplary data stream, there is only one data block defined. The
data block is the RegisterDataBlock. Within the RegisterDataBlock, there are
four
required elements: PublicKey, MerchantlD, HostAddress and Signature. PublicKey
is an
ASCII representation of the merchant's public key of the key pair generated by
the
ECML-based software component 112 at the merchant server 110. MerchantlD is a
field
that is encrypted with the eCommerce service provider server's public key. The
Merchant
1D field contains the name of the Merchant. HostAddress defines the host 1P
address that
the request is trying to register. Lastly, Signature is an encrypted SHA1
digest of the
clear text version of this message.
For the service to accept any ECML-based software object as valid, two things
are
required. First, the service must be able to decrypt the MerchantlD field.
Second, the
service must be able to validate the digital signature. Validating the digital
signature
CA 02328807 2000-12-19
18
requires the clear text representation of the MerchantlD field. This is used
to retrieve the
public key stored by the eCommerce server provider 120. If the public key
cannot be
retrieved, then the transaction is not processed, and an error is returned. If
the public key
is retrieved, then this is used together with the clear text of the ECML
message and the
value of the Signature field to determine whether the signature is valid. If
it is, then
processing continues; otherwise an error is returned. If the service is able
to successfully
register the client, it will return the following message:
< ECMLv2.0>
<errorblock>
<numerrors>Odnumerrors>
derrorblock>
</ECMLv2.0>
If it is not able to successfully register the client, it will return errors,
e.g.:
< ECMLv2.0>
<errorblock>
<numerrors>ldnumerrors>
<error-0>
<errnum>Oderrnum>
<errval>Invalid XML file: No bytes found in stream</errval>
derror-0>
</errorblock>
</ECMLv2.0>
Two data blocks are defined in this ECML response: an ErrorBlock and an Error-
0 block. The Error-0 block is part of the overall ErrorBlock. The Error-0
block
represents the details of the first error. Subsequent errors are numbered
accordingly.
Thus, if there were two errors, a first error block would be Error-0 and a
second would be
CA 02328807 2000-12-19
19
Error-1. The Error-0 block contains an error code, called ErrNum and a text
description
of the error called ErrVal. This structure for representing errors is
consistent for all
ECML-based software object transmissions.
Also through registration, a merchant can register a new public key. However,
the
signature of the ECML-based software object including the new public key data
is
validated using the original public key that is stored at the eCommerce
service provider
server 120. Thus, if the signature cannot be validated with the original key,
the new
public key is not installed on the eCommerce service provider server.
In step 420, the eCommerce service provider 120 sets up an eCommerce
service with a payment system gateway and the merchant server 110 architecture
is
configured. Thus, during step 420, such configuration allows the now
registered
merchant to set configuration options for his eCommerce store. Such options
may
include, for example, card authorization, settlement, shipping and tax
procedures and
data.
Control then proceeds to step 430. In step 430, a transaction is initiated.
Shopping cart information and credit card information is expressed in XML.
Control then
continues to step 440. In step 440, the XML representation of the shopping
cart and
credit card information is sent over a network in HTTP to the eCommerce
service
provider. Control then proceeds to step 450. In step 450, the eCommerce
transaction is
processed for authorization after which control proceeds to step 460.
Processing an eCommerce transactions allows a merchant to submit an entire
basket of goods to the eCommerce service provider service 120. The ECML-based
software component 112 takes the state of a customer's shopping basket who is
shopping
at the merchant's eCommerce store and generates corresponding ECML data as the
ECML-based software object 111. This ECML-based software object is then sent
to the
eCommerce service provider server 120 for processing. Such processing produces
results
as an ECML confirmation message, which contains both a result section and an
error
section. The ECML-based software component 122 makes the result variables,
such as
CA 02328807 2000-12-19
- 20
total tax, total shipping, grand total and any errors, available to the
merchant's software
via transmission over the network 130.
An ECML-based software object containing transaction data is utilized to send
orders to the eCommerce service provider server 120. The response from the
eCommerce
S service provider server 120 includes calculation of the total of the order,
including tax
and shipping. Below is an example of an encrypted and digitally signed ECML
transaction generated by the merchant:
<ECMLv2.0>
<merchantdatablock>
<merchantid>Olcd7a86b6b94ablaa83ca440a23ea0390ba98076d5a964d0291e62
0818827b9e6da7ae77acaafef830fd779a6bda7e160fd210384d2edac2ef675898301
0641 dmerchantid>
<signature>38ba3c52d978dafd56ac170a82c6a4ced2bc74edb98cffdb7c2114b09b
30def045156e29bb7970e7055574b714624817b90d2f9287b0aff95e1b2f526599aa
df</signature>
<transactionid> 1002443111 dtransactionid>
<currency>usddcurrency>
<testmode>true</testmode>
</merchantdatablock>
<shopperdatablock>
<shippingaddress>
<same_as_billing>true</same_as_billing>
</shippingaddress>
<billingaddress>
<fname>j ohndfname>
<lname>smith</Iname>
CA 02328807 2000-12-19
21
<addressl>307 any roaddaddressl>
<address2></address2>
<city>lincroft</city>
<state_province>njdstate_province>
<zip_postalcode>07738</zip_postalcode>
<email>any@ any.com</email>
<phone>888-111-2222</phone>
<country>us</country>
</billingaddress>
<cardinfo>
<type>3f637ba6b020266b48baeffa4955d92564ffecb98e37f905991 e44fae64f9f3c
l3cca03b103c9a2f5b0148db361a53f0321032af19f17da2b7b2c3ca6b497f11
dtype>
<value>da6f1e3285ed3e720934527a5ccOf3660dd35ad93adlbcle9e2bd7981d717
231ccfd7de72b65f4000a11eeac99247dcd7cc5266e61bd8cabb6d78d63faadbf42
dvalue>
<expmonth> 11 dexpmonth>
<expyear>1999</expyear>
</cardinfo>
</shopperdatablock>
<transactiondatablock>
<action>buydaction>
<items>2ditems>
<item-0>
CA 02328807 2000-12-19
22
<name>test product</name>
<unitprice>25dprice>
<quantity> 1 </quantity>
ditem-0>
<item-1>
<name>test product</name>
<unitprice>25dprice>
<quantity> 1 </quantity>
</item-1>
dtransactiondatablock>
</ECMLv2.0>
There are three major data blocks defined for the all ECML-based software
objects containing transaction data: MerchantDataBlock, ShopperDataBlock and
TransactionDataBlock. MerchantDataBlock defines data about the merchant as
well as
configuration options for the transaction. ShopperDataBlock includes
information about
the customer. TransactionDataBlock contains data about the transaction that is
being
submitted to the eCommerce service provider server 120 for processing.
The digital signature validation is performed utilizing the clear text, the
merchant's public key, and the value of the Signature tag. The encrypted
values are
created utilizing the service's Public Key, which allows a valid ECML server
to decrypt
the values and validate the signature.
The MerchantDataBlock is designed to provide information about the merchant,
as well as provide a place for global processing configuration options. The
MerchantDataBlock contains the encrypted merchant identification as well as
the
transaction identification sent to the service. There are four required
elements contained
within the MerchantDataBlock: MerchantlD, Signature, Currency and
ShopperDataBlock. MerchantlD is a string used to uniquely identify the
merchant to the
system. This value is encrypted with the eCommerce Service provider's public
key. It is
always required.
CA 02328807 2000-12-19
23
Signature is an encrypted digest derived from the clear text version of the
ECML
buffer. The value for Signature is automatically generated by the ECML object
on the
merchant server.
Currency is the abbreviation of the currency being utilized.
In UseTestMode, if the value is true, the merchant is allowed to send
transactions
that will not have a financial impact to either the merchant or a consumer.
Essentially,
this means that the eCommerce service provider server 120 will not forward the
transaction onto the financial institution server 170, but instead will return
a predictable
response that is used for developing and testing systems. The ShopperDataBlock
describes the merchant's customer. This data is utilized to perform card
authorization,
address verification, set shipping options, set shipping destination and
billing
information. There are three sub-blocks contained within this block. These
are:
ShippingAddress, BillingAddress and CardInfo.
The ShippingAddress block contains either all the required shipping fields:
fname - First Name
Iname - Last Name
address 1 - Street Address
address2 - room or suite number - default is blank
city
state-province
zip_postalcode
email - default is blank
phone
country
Or contains the field:
Same as billing set to true
CA 02328807 2000-12-19
' 24
The BillingAddress block includes the supported fields for BillingAddress. The
Merchant must supply he fields without a default value when making a call via
ECML.
fname - First Name
lname - Last Name
address 1- Street Address
address2 - room or suite number - default is blank
city
state_province
zip-postalcode
email - default is blank
phone
country
There are no size restrictions on the data contained in these fields, via the
ECML
interface. The CardInfo block is designed for passing credit card data to the
eCommerce
service. The fields within the block include Type, Value, ExpMonth and
ExpYear. The
type field indicates the type of credit card being used by the customer, e.g.,
Mastercard,
Visa, etc. The Value field indicates the number of the credit card being used
by the
Merchant. Both the Type and Value fields are encrypted. ExpMonth indicates the
expiration month of the credit card. ExpYear indicates the expiration year of
the credit
card.
The TransactionDataBlock is designed for describing the details of the
transaction. This block contains fields that describe the transaction and sub-
blocks) that
describe the items being purchased. At least one item is required for an ECML
transaction; an error will be generated if no items are found.
The required fields within the TransactionDataBlock include: Action and Items.
In the Action field, validate and buy are both valid values. The Validate
value of the
Action field instructs the eCommerce service to calculate tax, shipping and
grand total,
but not to attempt authorization of the credit card. The Buy value of the
Action field
instructs the service to calculate tax shipping and grand total and attempt to
obtain an
CA 02328807 2005-02-16
authorization of the transaction from a financial institution, configured for
this merchant.
The Items field indicates the total number .of items that are part of the
transaction. The
determination of whether tax, shipping or other calculations are performed is
based on
configuration parameters set by the merchant directly on the eCommerce
service.
5 The Items data block is numbered utilizing a zero-based index. Thus, the
first
item in the block is named: <Item-0>. There are two required tags for each
item: Name
and Quantity. The Name tag indicates the name of the product. The Quantity tag
indicates the quantity of the product.
Some indication of price for each item is also required. However, this
indication
10 can be provided by either a L3UnitPrice tag, which indicates the unit price
of the product, or
a TotalPrice tag, which indicates the unit price multiplied by the value in
the indicated by
the Quantity tag:
The eCommerce service has a standard response for transmission of ECML-based
software objects containing transaction information from the merchant server.
A sample
15 response from the eCommerce service provider server 120 implementing the
SecureBuyTM
service is shown below.
<ECMLv2.0>
<merchantdatablock>
<mcrchantid>www.xmlifc.com<Imerchantid>
20 <transactionid>649493743</transactionid>
</merchantdatablock>
<errorblock>
<numerrors>Odnumerrors>
</errorblock>
25 <merchandiseamountblocka
<subtotal>50.00</subtotal>
<taxtype>SALES</taxtype>
<taxamountl>3.00</taxamountl>
<taxamount2>0<ltaxamount2>
CA 02328807 2000-12-19
26
<shipamount>S.OOdshipamount>
<total>58.OOdtotal> _
<receipt> 101100</receipt>
dmerchandiseamountblock>
<cardresponseblock>
<avscode>I3davscode>
<cardcode>100dcardcode>
<status>APPROVEdstatus>
<approved>true</approved>
<approvalcode>tntC00dapprovalcode>
dcardresponseblock>
</ECMLv2.0>
If data values are missing, servers are down, cards cannot be authorized,
etc., the
eCommerce service provider server 120 returns errors to the merchant server
110. The
following is an example of a potential error return:
< ECMLv2.0>
<errorblock>
<numerrors> 1 </numerrors>
<error-0>
<errnum>0</errnum>
<errval>Invalid XML file: No bytes found in streamderrval>
derror-0>
derrorblock>
</ECMLv2.0>
Two data blocks are defined in this ECML response: an ErrorBlock and an Error-
0 block. The Error-0 block is part of the overall ErrorBlock. The Error-0
block indicates
the details of a first error. Subsequent errors, if present, would be numbered
accordingly.
Thus, if there were two errors, the first error block would be Error-0 and the
second
CA 02328807 2000-12-19
27
would be Error-1. The Error-0 block contains an error code, called ErrNum, and
a text
description of the error called ErrVal. This structure for representing errors
is consistent
throughout all transmission of ECML-based software objects. Depending on the
error,
the MerchandiseAmountBlock and the CardResponse block may also be returned
from
the eCommerce service provider server, e.g., when the credit card was declined
by a
financial institution server 170.
The CardResponseBlock contains data specific to the results provided by the
financial institution server 170 utilized to validate and authorize the credit
card. An
Approved field within the CardResponseBlock represents a summary of the card
code
field's numeric result.
The Status field provides the eCommerce Service Provider's recommended
action. This value is either APPROVE or DECLINE. This is different from the
Approved field, in that it combines the results of both the credit card
authorization
response and the AVS (Address Verification System) response. The merchant can
configure the acceptable range of AVS responses for obtaining an APPROVE
result.
Thus, it is possible to have the credit-card-based Approved field set to true,
and yet have
the Status field recommend a DECLINE, because the AVS return code was not
within the
merchant's acceptable range.
In step 460, the transaction is settled and actual money is exchanged. Control
then proceeds to step 470.
It is important to note that transaction response data values are important to
the
ECML settlement process, utilized by the ECommerce service providers. The
Receipt
field in the MerchandiseAmountBlock is the required key value to submit a
transaction
for settlement. The CardResponseBlock is not directly required for settlement;
however,
a merchant can only settle transactions that have an Approved field value of
true. Thus,
even if the Status field recommends a DECLINE, the merchant can settle any
transaction
with a valid credit card authorization code. The result of the AVS does not
directly
impact the merchant's ability to settle the transaction. Once the merchant
server receives
CA 02328807 2000-12-19
28
transaction authorization using the transaction method steps, method steps for
settling the
authorized transaction are-performed:
The ECML-based software objects transmitted to perform Settlement allow the
merchant to complete an order for which there is a valid online authorization.
The
authorization gives the merchant the right to collect a specific amount of
money when the
goods and services are rendered. The authorization does not move money, but it
does
decrease the available credit of the card holder's account. The authorization
will
automatically expire in some designated time-period. The transmission of the
ECML-
based software objects is designed to allow the merchant to capture the funds
that have
been authorized. This happens after the goods or services have been delivered
to the
customer. Such ECML-based software object transmission also allows the
merchant to
submit returns for buyer credit.
The exemplary settlement request from the merchant server 110 shown below
requires a valid MerchantDataBlock. This block contains the encrypted
MerchantId and
the signature for this transaction. The signature is created utilizing the
clear text of this
message. The clear text is the unencrypted MerchantId value and an empty
signature tag
set.
<ECMLv2.0>
<merchantdatablock>
<merchantid>37c2568eb6d3591534e0a9e6daa0972089cf9fbcd86b63326b298ff5
abd4bf18dd1fa11847486b8522646c52c5eef1dd3f79faab4badb2e72179bdd07f80c830dm
erchantid>
<signature>1a59d663bec689bc4567d293d9dbb7d7ef96fb1049662cc7a79aefbac2
l2fce0f23ff2884c07dd31488426df85a5cc359c088df4dcd1ba411f161e1d458f9595dsign
ature>
dmerchantdatablock>
CA 02328807 2000-12-19
' 29
<orderdatablock>
<order-0>
<orderid>PSJ9GGU1GKS 12GG700GPBK3655</orderid>
<action>CAPTURE</action>
<amount> 1.5</amount>
<currency>USD</currency>
</order-0>
<orders> 1 dorders>
dorderdatablock>
</ECMLv2.0>
The OrderDataBlock contains an OrderId returned as the Receipt field in the
response generated and transmitted from the eCommerce service provider 120 in
response
to the ECML-based software object containing Transaction data. Each OrderId
must have
a valid authorization code, as explained above in relation to the description
of the
CardResponseBlock. There can be any number of Orders processed within a single
transmission of ECML-based software objects related to settlement. The
required fields
in the OrderDataBlock are: Orders, OrderId, Action, Amount and Currency.
The Orders Field indicates a count of the number of orders in the
OrderDataBlock. There is no limit to the number of orders that can be
contained within
the OrderDataBlock. The specific order tag utilizes a zero-based index. Within
the order
tag, a specific order can contain the following fields: OrderId, Action,
Amount and
Currency.
The OrderId field indicates the receipt value returned by eCommerce service
provider server in response to transmission of an ECML-based software object
containing
Transaction data.
The Action field indicates the action to be performed for the order. Within
the
Action field, the following are the valid action verbs: CAPTURE, STATUS UPDATE
and CANCEL.
CA 02328807 2000-12-19
The CAPTURE action verb assumes that an authorization has been obtained and
attempts to capture the funds. This action verb requires the AMOUNT field and
the
CURRENCY fields. A successful return sets the status for this transaction to
the value of
CAP BATCH.
5 The STATUS UPDATE action verb returns the current status information from
the eCommerce service provider server 120. This information is utilized to
determine
when the transaction has been settled. If the status of the transaction is CAP
BATCH,
then the eCommerce service provider server 120 queries a financial institution
server 170
to determine whether the settlement batch has been run. If the batch is not
complete, the
10 eCommerce service provider server 120 responds with a NO CHANGE. If the
batch has
completed, the eCommerce service provider server 120 responds with a COMPLETE
if
the capture was successful. If the capture failed, the eCommerce service
provider server
120 responds with a D DECLINE.
The CANCEL action verb cancels the order and requests a credit on the
15 customer's credit card if the order has settled. If the order has not
settled, then it will
attempt to void the authorization.
The Amount field is required when the Action field contains the CAPTURE
action verb. The value in the Amount field cannot exceed the value of the
original
authorization. However, it can be less than the original authorization amount.
20 The Currency field indicates the type of currency for the transaction.
The eCommerce service provider server 120 creates a response that contains an
order status value for each of the orders submitted by the merchant server
110.
The following is an example of a service response generated by the eCommerce
service provider server 120 to a settlement request by the merchant server
110.
CA 02328807 2000-12-19
31
<ECMLv2.0>
<errorblock>
<numerrors>Odnumerrors>
derrorblock>
<transactionresultblock>
<orders>2</orders>
<order-0>
<orderid>JCG9GGU 1 GKS 12GG700GPBK3655</orderid>
<status>NO CHANGEdstatus>
</order-0>
<order-1>
<orderid>CVG9GGU 1 GKS 12GG700GPBK3655</orderid>
<status>CAP_BATCH</status>
</order-1>
dtransactionresultblock>
</ECMLv2.0>
The TransactionResultBlock is returned from the eCommerce service provider
server 120 after a settlement request from the merchant server 110 has been
processed.
Each processed order contains a block and the status of the order. The status
represents
the status of the order at the eCommerce service provider server 120. If the
value of the
status field is NO CHANGE, then the status of the order at the merchant server
110 and
the status of the order at the eCommerce service provider server 120 are the
same. This is
a typical response when a merchant side application is polling the eCommerce
service
provider server 120 to determine when a transaction has settled.
The TransactionResultBlock includes an OrderId field and a Status field. The
OrderId field indicates the value that was returned by the eCommerce service
provider
server 120 as the Receipt. The Status field indicates the result of the
request for this
CA 02328807 2000-12-19
32
order. Return values can be: NO CHANGE, CAP BATCH, COMPLETE and
D DECLINE.
The NO CHANGE return value indicates that the data at the merchant server 110
and the data at the eCommerce service provider server 120 are consistent.
Therefore, a
requested action has not completed. The CAP BATCH return value indicates that
the
transaction was put in the Captured state and made available for the next
batch settlement
run. The COMPLETE return value indicates that the transaction has been
processed and
the dollar value has been successfully moved into the merchant's account. The
D DECLINE return value indicates that the transaction has been posted in a
settlement
batch, but has failed.
In step 470, the method ends.
While this invention has been described in conjunction with the specific
embodiments outlined above, it is evident that many alternatives,
modifications and
variations will be apparent to those skilled in the art. Accordingly, the
preferred
embodiments of the invention, as set forth above, are intended to be
illustrative, not
limiting. Various changes may be made without departing from the spirit and
scope of
the invention.
Preferably, ECML is a generic framework that uses XML vocabulary. However,
the vocabulary can change on each ECML-based software object. Although there
is a
finite vocabulary, a vocabulary subset can change. However, the present
invention may
be implemented without using XML. For example, the present invention may be
used
with a proprietary data protocol instead of HTTP. It is foreseeable that
merchants will
soon be able to design their own software objects. Therefore, it should be
appreciated
that the benefits of the present invention are not based solely on the use of
XML.
While the present invention has been described with reference to specific
illustrative embodiments, it is not confined to the specific details set
forth, but is intended
to cover such modifications or changes as may come within the scope of this
invention.
