

It's Not a Digital Market, It's a Digital Payment System
March 8, 1999
Other Articles by Brian Walsh
|
The Once and Future Development Standard, November 1, 1998
Your Network's Not Ready for E-Commerce, December 1, 1998
Facing the Future, January 11, 1999
Heading for Disaster?, Features, January 11, 1999
The Almighty and All-Important Consumer, February 8, 1999
|
|
Other Columnists
|
Top of the Stack By David Willis
On the Edge By Art Wittmann
|
|
Company Directory
|
|
Browse our directory to get data, starting with a particular company.
|
|
Reader Service
|
|
Allows you to request additional product information from our advertisers.
|
|
Print The Full Article
|
Click Here
|
|
E-mail this URL
|
Click Here
|
|
Buy the Book
|
|
|
By Brian Walsh
My previous column addressed the importance of adding value to B2B (business-to-business) sites by taking some cues from the business-to-consumer side. I pointed out that your search to add value in any way--and by this I did not mean simply repackaging existing enterprise applications--would turn your users into consumers, and consumers demand choices. I also discussed the "shrinking margin" effect of Internet trading on financial markets. For more proof of diminishing margins, consider the insurance market. To compete on the Internet, companies have had to cut prices to ensure prime positioning on a search engine's results page. Traditional brokers have had to match those prices, and so for them, life insurance has become a service rather than a revenue generator.
Consumers have grown comfortable shopping on the Internet and are going online in droves. When the novelty wears off--soon--these consumers will become predators hunting for the best deal. Successful e-commerce sites will embrace this momentum and adopt the technology needed to facilitate price efficiency in their market sector.
The technology that forms the plumbing of the Internet is well understood and widely deployed, and the consumer has forced standardization of security to protect payments. But the technology that defines all the parts of a transaction prior to the buy is ill defined and ad hoc. Think about it: Internet brokerage firms simply front-end an incredibly sophisticated network of applications that seek to match buyer and seller by describing what's for sale and what the competing bid and asking prices are. Without leveraging the infrastructure already in place between NASDAQ and NYSE firms, the emergence of Internet trading would have been impossible.
As it exists, e-commerce is not really a digital market, but rather a digital payment system with some pretty pictures up front. Those pictures are hyped to a frenzy with traditional advertising, for-hire links and search words--inefficient and mostly annoying. They're just an alternative to many proprietary technologies and ad hoc applications that don't interact and lock in users.
It's no surprise that today's best-price solutions are at auction sites, such as eBay. It seems efficiency will come from middlemen. While sellers have significant motivation to provide payment mechanisms (hence the growth of bill-presentment technologies like OFX), on the surface there is little incentive for them to spend time on technologies that reduce margins. PriceLine has gone a step further and implemented a buyer-driven pricing model (a buyer specifies how much he or she wants to pay, and merchants compete for the right to supply). What customer demand exists is being addressed by portal sites. Note that most auction traffic comes from individual buyers and sellers, not corporations. To a buyer, heaven is a place where price competition is the only competition.
This trend isn't unique to consumer sites. Chemdex acts as middleman for buyers and sellers in the chemical and life sciences industry. To create its site, it converts from suppliers data to the Chemdex catalog and fulfillment orders flow via fax or e-mail. It's a prime example of how a motivated middleman can provide a service to the buying community, but it's like saying that when you're logged onto Charles Schwab, you can buy any stock you want as long as Schwab has a direct relationship with the company whose stock you want to buy. Clearly, we are not at the pinnacle of evolution.
Moving Forward Now that Internet technology has delivered universal access and security, the next step for e-commerce is to evolve from a payment system to a flexible market.
In addition to payments, we need to deploy technologies for product descriptions, best price determination, contract terms, delivery, customer care and payment dispute reconciliation. While it's relatively easy to predict the short-term future of e-commerce--lots more of the same--making predictions for a year from now is trickier. Three things are for sure: Standard high-level shopping protocols won't appear without customer demand, different industries will adopt different solutions, and the technology will be a combination of the new and old--new in the form of agents and old in the form of EDI-style record exchanges.
Examine the messages that make up the payment protocols used on the Web, and you'll see that at their core are strictly defined fields corresponding with real world elements (credit-card number, payment amount). The protocols that make up stock-market trades have, at their core, defined fields for bid, ask, symbol and number of trades. To make progress, we must extend that analogy by providing message formats that include broader concepts to describe arbitrary products, their prices and matching buyers with sellers.
Whether it's a consumer learning and/or remembering a merchant's site structure or two businesses exchanging data online, today's process is error- prone and nonscalable. To maintain the pace of progress on the Internet we need continued agreement on message structure and content at ever higher levels. On an ad hoc or formal basis, organizations within an industry (including retail customers and merchants) must automatically exchange information in a trusted fashion without human intervention, custom mapping programs, or reliance on the structure of another organization's Web site.
The contribution that commerce will have in efficient markets is directly proportional to our ability to represent, within signed XML documents, the widest possible repertoire of commercial transactions across the widest possible merchant population. In that way, shoppers can submit a standard set of XMLs to multiple merchants querying price and availability. The merchant in turn can rely on the certificate of that query, authenticate the customer and identify custom pricing. The certificate, in effect, replaces member registration.
Standard representation of commercial transactions is nothing new. EDI has been in place for years. It hasn't achieved widespread functionality for a number of reasons, such as cost, complexity, lack of native support in applications and proliferation of custom implementations. However, it did succeed in arriving at a standard representation for most transactions.
In October 1998, the IOTP (Internet Open Trading Protocol) version 1.0 was introduced as an Internet draft at the IETF, to provide an interoperable framework for Internet commerce. Payment systems such as SET, Mondex, CyberCash and DigiCash are handled as plug-ins. IOTP defines message content and flows for the shopping site, the payment handler, the Delivery Handler and the customer-support provider.
From a high level, the IOTP defines components (XML documents) that describe the consumer and merchant organizations (signatures, payment handlers, shipping methods and destinations), the order (description of goods or services), the payment (currency and amount), the Delivery Component, pointers to customer service and handlers. Finally, a signature component digitally signs it all to ensure integrity.
Also in October 1998, the OBI (Open Buying on the Internet) consortium, sponsored an interoperability bake-off. Personalization of catalogs based on certificates and secure synchronization of orders in both buyer and supplier systems were demonstrated.
David Burdett, the principle author of the IOTP, states that, "We can't hope to define a standard way of defining all the necessary attributes of every single product anybody might want to buy, or all the kinds of 'special offers' or customer service that a merchant might want to provide. This doesn't mean there are no parts of e-commerce that can be standardized. For example, we need a reliable way of identifying, requesting and getting a 'service' where a service can potentially be almost anything, such as 'give me a quote for this building work' or 'what's the status of my order?" In addition, common "services," for example: making a payment, requesting and processing a delivery, requesting a price, etc. Only when we get some standardization will we be able to concentrate on what we're trying to do with e-commerce and not on how we transfer the information. IOTP does this in that it has a standard way of sending a request for a service and responding to it and then uses this to provide standard ways of doing some of the most common things such as payment and delivery of goods/services."
The success of the Internet proves the link between standards and progress. More than ever, we need to track, actively champion and insist on third-party support for higher-level protocols. The rigor of protocols relative to ad hoc schemes developed unilaterally should be self-evident. Consider that the only alternative to "open" standards is to wait until a vendor with an ax to grind and marketing muscle to spare provides a compelling solution that all other vendors would then have to follow.
The coming year will doubtless squeeze the various portals now riding high with stock valuations. Just as EDI was championed by large customers insisting that suppliers automate to keep their business, it is in the interests of the portals, acting as middlemen, to pool the interests of their constituents and champion the catalog query, best bid/ask protocols that we will need to fulfill e-commerce's promise.
Brian Walsh is the founder of bwalsh.com, a Portland, Ore., consulting firm specializing in Internet and client/server product strategies, development and testing. Send your comments on this column to him at brian@bwalsh.com.
|