An E-commerce Strategy for the Australian Government

Part 2: The Solution?

Tom Worthington FACS

Visiting Fellow, Department of Computer Science, Australian National University, Canberra

For: Computing 3410 Students, The Australian National University

This document is Version 1.0 19 August 2002: http://www.tomw.net.au/2002/ecg2.html

Introduction

This material was prepared for the unit Information Technology in Electronic Commerce (COMP3410) at the Australian National University, semester 2, 2002. It illustrates issues discussed with e-commerce metadata by proposing a solution to the problem of implementing a system to electronically transmit information about payments to Australian businesses by Commonwealth Government agencies.

Proposed solution:

Provide a web address for the Electronic Remittance Advice in the Eighteen Character field of the payment.
Use lightweight authentication to protect the remittance advice
Provide the remittance advice by default as a simple web document.
Provide a Web Services interface for a more complete XML based interface.
Provide documentation online about how to use the system.

Under this strategy the payment transaction sent via the bank would contain a web address (part of a URL), which could be used to obtain the payment advice via the web. Small businesses would use a web browser to display the details as a web page (or PDF file) by simply typing in the web address shown on their bank statement. Larger businesses would use XML transactions via a web services interface.

The system would be self documenting, in that the format of the payment field would indicate it was a web address. Entering the web address would offer options for displaying the payment details. There would be details on how to the business can authenticate itself to the online system, how to simply display payments and the technical details for the transaction interface.

As a lightweight form of identification, the organizations ABN is suggested. This is a standard number now issued to most companies in Australia. The ANB is not secret, but it would be difficult to guess the combination of an ABN and payment code. To make guessing more difficult, the payment codes could be allocated as pseudo random numbers, rather than sequentially (as is usually done with invoice numbers). Payment details may only be placed on the system for a period of weeks, or moths, for additional security. Large suppliers would be offered a more advanced security option.

An informal test showed that the banking system can transmit digits, upper and lower case alphabetic characters, and the special characters / = - &~. Characters which could not be sent (received as spaces) were: ? and %. As a result is possible to send a web address (part of a URL) which would be both human and machine readable. As an example: tomw.net.au/123456

As there are only eighteen characters available a full URL is impractical. Assuming that a four character organisation name is used, followed by a three digit second level domain (GOV) and country code (AU), this leaves six characters for the payment identification. A six digit number may not be sufficient for the number of payments from large agencies and may need to be supplemented by alphabetic characters. It should be noted that the codes need only be unique to the one supplier and agency (allowing for 999999 payments from each agency to each supplier, with a numeric code).

This proposal does not require any central system, nor particular technical standard to be agreed. Existing payment advice formats can be used, with the documents generated as text output from accounting systems. Each agency can set up its own payment advice system at its own web address. The web services system can support multiple XML transaction formats.