WISL Bank Authorization

WISL Bank Authorization

Overview

Waterloo Information Systems Limited

33 Dupont Street East

Waterloo, Ontario

N2J 2G8

The information contained herein is proprietary and considered a trade secret of Waterloo Information Systems Limited and shall not be reproduced in whole or in part without the written authorization of Waterloo Information Systems Limited.

INTRODUCTION

The WISL Bank Authorization Interface(WISL BA) is a group of computer programs that connect WATPOS(the Waterloo Point of Sale System) to bank authorization services. It provides for credit and debit authorization through the register/computer system on a centralized communication link rather than requiring separate devices with separate communication links per register. WISL BA has been designed to interface with any bank authorization service but since there is no standard for bank authorization transactions as with many other business transactions(EDI), the transaction formats and communication protocols are unique for each authorization service. The pinpad hardware which incorporates proprietary encryption for security, also requires a custom interface for each authorization service.

WISL BA may be implemented on any Open Systems(UNIX, Linux ,or Windows Server) platform that supports the UniVerse data base management system. A schematic illustrating transaction flow and a point form authorization scenario follows:

WISL BA Authorization Scenario

1. WATPOS Cashier initiates authorization transaction by swiping a credit card or customer initiates debit transaction through pinpad input.

2. The WISL BA Interface program is invoked to write the authorization request to the Authorization Request File

3. The WISL BA Interface program begins to periodically interrogate the Authorization Response File until a response is received from the bank. The cashier is provided with the appropriate authorization message and sale processing continues.

4. The WISL BA Communication processor alternately interrogates the Authorization Request File and the modem. If new requests are found then they are sent to the bank over the modem. If the bank has sent any transactions to the modem then they are written to the Authorization Response File.

5. The WISL BA Communication Processor writes a copy of every transaction to or from the bank into the Transaction Log File.

6. The WISL BA Communication Processor is initiated at system boot time, runs continuously and does not require a dedicated UNIVERSE user.

IMPLEMENTATION CONSIDERATIONS

The first implementation of WISL BA was undertaken with the Bank of Montreal bank authorization service. They indicated that they had no other UNIX based solutions interfacing with their service. A key benefit of a multi-user based application is the capability to share data and facilities. In the case of bank authorization, the connection of the registers to the bank authorization service via a centralized communication link results in significant savings. Single user solutions require a separate driver/modem for each register. The WISL BA solution requires only that the register be connected to the multi-user system and the communication services may be shared. The capital cost of additional driver/modems is saved.

As with the single user solutions the acquisition cost of specialized authorization printing devices is also saved. The cashiers have fewer devices cluttering up the work space and fewer operations to perform with each sale that requires bank authorization.

The service now interfaced with WISL BA is Moneris, a joint venture of the Bank on Montreal and the Royal Bank of Canada.

SYSTEM FEATURES

1. The transactional activity between individual registers and the authorization service is controlled by the monitoring of two transaction holding files. When an authorization is required a request transaction is written to the request holding file. WISL BA then monitors the response holding file until a response is received.

2. The WISL BA communication processor is a separate UniVerse process that runs continuously, monitoring the transaction holding files to control the communication between the individual registers and the bank authorization facility. Using this approach the communication between the individual registers and the authorization facility may be interleaved. The conversations are therefore independent and possible delays in a specific authorization do not affect other transactions.

3. As UniVerse does not include the facilities to conduct a conversation using the authorization facility's protocol, a "C" program has been developed that runs continuously in the background exchanging data with the authorization service on a remote computer. It communicates with the UniVerse based communication processor through UNIX pipes or Windows com port.

4. The proprietary pinpad that is utilized for debit transactions is an intelligent device that must be interfaced to WISL BA for communication with the individual registers. As it is a one to one communication link it can be handled within the facilities of UniVerse but it does require some involved data manipulation.

5. Supervisor or function control activities are handled with the same transaction handling facilities used for the authorization transactions but within the framework of a separate supervisor routine invoked from the Backroom facility of WATPOS.

6. Receipt printing in WATPOS is accomplished concurrent with the entry of transaction information. The procedure would be simplified if the receipt could be printed after transaction data entry is completed. However the time required for printing the receipt dictates that the printing commence as soon as possible. Options are therefore limited to accommodate the requirements of bank authorization hard copy. The approach taken is to print a complete receipt for the customer followed by an abbreviated bank authorization hard copy including a space for customer signature.