Charging for printing/downloading

The University of New South Wales has fully tested and will begin using the following Online Payment System (OPS). While it is desirable that theses are accessible without restriction or payment, some institutions may want to implement a pay per download/print procedure in some cases. Any Online payment service would have to be fully integrated within the local institution's accounting system. It is up to the individual institution to investigate the type of OPS that would work for them.
For ADT purposes, any payment required should 'kick' in after the 01front.pdf file. This similar to the UMI/Bell&Howell practice - a free sample view of the preliminary part of the thesis before charges kick in. The ADT philosophy regarding charging for access is that if implemented that some royalties be passed on to the author.

The UNSW setup is provided here as an example, a reference point only, on how such a payment system could operate.

UNSW Online Payment System
TERMINOLOGY

OVERVIEW

The UNSW Online Payment System (OPS) aims to provide secure online payment facilities to the various UNSW entitites (e.g. UDUS, Library) (vendors). A primary goal is to not have the vendor ever deal with (or even see) credit card details - and for the payment server to not have to know about vendor part numbers, inventories, etc. Additionally, the interface to the OPS must be flexible enough to allow a variety of vendor implementations to interact with the OPS. i.e. it shouldn't matter what backend the vendor is using, a standardised interface is used to communicate between the OPS and vendors.

From the vendor's point of view, the OPS consists of two distinct entities:

1. The Vendor Server
   
   • provides a means for the user to select item/s for purchase
     
   • holds some kind of meta-data for each user: i.e. an order or invoice
2. Online Payment System Server
   
   • collects credit card details for submission to the EFTPOS network
     
   • informs the user and vendor server of the payment result for the given order/invoice

THE SERVERS
The Vendor Server ('Shopping Cart')

The vendor's web site is responsible for providing the user interface to allow the user to select item/s. Once the user has created an "order" and is ready for payment, they are then directed to the OPS to enter their card details over a secured connection.
The vendor's system must support the concept of a unique order or invoice which allows the order details (e.g. payment amount) to be securely communicated from the Vendor Server to the OPS, and for the payment result to be securely communicated back to the vendor. This communication channel may be implemented via a shared database (the method used by the UDUS server), a private HTTP connection, or a digitally signed (immutable) CGI request carried by the client.

The order details required from the vendor are the order number / reference number (to tie the payment to the entity being paid for) and the amount. Optionally, the order details may contain a HTML snippet describing the order (e.g. item descriptions and individual amounts - an "invoice"), for presentation to the user at time of payment.

The OPS Server

As noted above, once a user wishes to make payment, an order request is issued from the client directly to the OPS (i.e. via a "Pay Now" / "Checkout" button). In the Shared Database and Private HTTP methods, this request contains only the Vendor ID and Order Number. The OPS queries the Vendor Server using the Order Number to retrieve the order details (e.g. payment amount). Then a payment page is returned to the user containing a form prompting for the user's credit card details. When submitted (via SSL) to the OPS Server, these details are passed on to the the EFTPOS system as a purchase request. When the request returns, both the user and Vendor server are notified of the payment result (accepted or declined). If declined, the user may try again from the payment page (for example, they may have mistyped a card digit, or choose to use a different card).

Thus, the OPS takes care of handling the sensitive card details in a secure envronment, and the interaction with the bank.

Details suppied by:

Benjamin Low, BEng (Comp) Hons I
Communications Unit, The University of New South Wales, Australia
b.d.low@unsw.edu.au