Overview of NetPay

 < Day Day Up > 



In this section, we briefly describe our NetPay micro-payment protocol. We also outline the architecture of our NetPay prototype implementation and give some examples of an e-newspaper site augmented with NetPay-based micro-payment support.

NetPay Model

NetPay is a micro-payment model that allows customers to purchase information on a pay-per-click basis from vendors on the WWW (Dai & Lo, 1999). NetPay, a secure, cheap, widely available and debit-based protocol of a micro-payment system, is used for purchasing online services via the WWW. NetPay differs from previous micro-payment protocols in the following ways: NetPay uses "touchstones" signed by the broker, and coin indexes signed by vendors, which are passed from vendor to vendor. The signed touchstone is used by a vendor to verify the electronic currency—the "paywords" encoding e-coins—and the signed index is used to prevent double spending by customers and to resolve disputes between vendors. There is no dependency on customer trust required with this approach.

A NetPay micro-payment system includes customers (e.g., newspaper customers), vendors (e.g., online e-newspapers) and a broker. In our approach we make the assumption that the broker is honest and is trusted by both the customers and the vendors. The micro-payments only involve customers and vendors, and the broker is responsible for the registration of customers and for crediting the vendors' accounts and debiting customers' accounts. Figure 2 outlines some of the key NetPay system interactions.

click to expand
Figure 2: Basic NetPay Component Interactions

Software Architecture

We have developed a software architecture for implementing NetPay-based micro-payment systems for thin-client web applications (Dai & Grundy, 2002). NetPay micro-payment transactions involve three key parties: the Broker Server, the Vendor Server, and the Customer Browser. This architecture is illustrated in Figure 3.

click to expand
Figure 3: Basic NetPay Software Architecture

The Broker provides a database holding all customer and vendor account information, generated coins and payments, redeemed coins and macro-payments made (buying coins and redeeming money to vendors). The Broker application server provides a set of software interfaces vendor application servers communicate with to request touchstones and redeem e-coins. This server also communicates with one or more bank servers to authorize macro-payments (customer buying coins or broker paying vendors when redeeming spent coins). The Broker web server provides a point of access for customers to buy e-coins and check their e-wallet balances and transaction history.

The Customer runs a web browser that accesses the broker and vendor servers, and may also contain an e-wallet. In our current NetPay prototype we support the use of two kinds of e-wallet: one held server-side and one held client-side. The client-side e-wallet is an application running on the client PC holding e-coin information. The server-side e-wallet resides on the Vendor server and is transferred from the broker to each vendor in turn the customer is buying content from. Each has its own advantages and disadvantages. When buying e-coins the Broker's application server updates the Customer's e-wallet (cached e-coin information). When purchasing information using micro-payment, the Vendor's web server accesses e-coin information using the Customer's e-wallet.

The Vendor sites provide a web server and possibly a separate application server, depending on the web-based system architecture they use. The Vendor web server pages provide content that needs to be paid for and each access to these pages requires one or more e-coins from the Customers' e-wallets in payment. In our architecture the Vendor application server accesses the Broker application server to obtain touchstone information to verify the e-coins being spent and to redeem spent e-coins. They communicate with other Vendor application servers to pass on e-coin indexes and touchstones. Vendors may use quite different architectures. In the example above, Vendor #1 uses a web server, custom application server and relational database. Vendor #2 uses a J2EE-based architecture with J2EE server providing Java Server Pages (web services) and Enterprise Java Beans (application server services), along with a relational database to hold vendor data. We use the open standard CORBA distributed objects to support Broker and Vendor interactions (Dai & Grundy, 2002).

Customer Interaction Examples

Initially a customer accesses the broker's website to open an account and acquire a number of e-coins from the broker (bought using a single macro-payment). With a client-side e-wallet the broker sends an "e-wallet" that includes the e-coin ID and e-coins to the customer and the customer's PC caches this information. The HTML interface for client-side NetPay used by customers to register and purchase e-coins is shown in Figure 4. The customer can register with the broker, download and run e-wallet application software (1). When needing to buy some e-coins, the customer authorizes macro-payment by the broker who debits the customer's supplied credit card to pay for the coins (2).

click to expand
Figure 4: Interactions between Customer and Broker for Client-Side NetPay

The HTML interface for server-side NetPay used by customers to register with the broker is same as client-side NetPay, but it does not need to download and run e-wallet software. Customers purchase e-coins as shown in Figure 5. The differences between client-side and server-side are that there is no need for customer to download the e-wallet, but the customer needs to remember the e-coin ID and the customer needs to login and input their e-coin ID and password when accessing a newspaper site for server-side NetPay e-wallets.

click to expand
Figure 5: Interactions between Customer and Broker for Server-Side NetPay

Unlike regular, subscription-based newspaper sites a micro-payment-based newspaper not only provides searching, browsing and newspaper content for customers, but also indicates article cost, as shown in Figure 6 (1). When wishing to read the details of an article, a customer clicks on the article heading. The newspaper site debits the customer's e-coins (e.g., 10 cents) provided by the customer's e-wallet and verifies if these e-coins are valid by using of a "touchstone" obtained once only from the broker. If the payment is valid (coin is verified and sufficient credit remains), the article is displayed on the screen. The customer may browse other articles, his or her coins being debited (the index of spent coins incremented) each time an article is read.

click to expand
Figure 6: Customer Spending E-Coins at an E-Newspaper Site

If a customer's e-coins run out, the customer is directed to the broker's site to buy more. When the customer changes to another online newspaper (or other kind of vendor using the same e-coin broker currency), the new vendor site first requests the current e-coin touchstone information from previous vendor's site. The new vendor contacts the previous vendor to get the e-coin touchstone and "spent coin" index and then debits coins for further news articles. At the end of each day, the vendors all send the e-coins to the broker redeeming them for real money (done by macro-payment bank transfer from the broker to vendor accounts).



 < Day Day Up > 



Advanced Topics in End User Computing (Vol. 3)
Advanced Topics in End User Computing, Vol. 3
ISBN: 1591402573
EAN: 2147483647
Year: 2003
Pages: 191

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net