Product Overview

10550 DEERWOOD PARK BLVD., SUITE 700 JACKSONVILLE, FL 32256 904.281.9090 800.963.5000 FAX: 904.281.0075 www.systeminnovators.com

Copyright © 2008 by System Innovators, Inc.

iNovah Product Overview

The System Innovators logo is a registered trademark of System Innovators, Inc. The name iNovah and the iNovah logo are trademarks of System Innovators, Inc. The following items are registered trademarks or trademarks of Microsoft Corporation: Windows, SQL Server, .NET.

This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose other than the customer’s own use without written permission from System Innovators, Inc. The layout of this document was designed for double-sided printing/copying.

System Innovators, Inc. 10550 Deerwood Park Blvd., Suite 700 Jacksonville, Florida 32256

i

Table of Contents

Introduction ...................................................................................................................................................1 Payment Database........................................................................................................................................2 Cashiering Module ........................................................................................................................................3 Entering Payments........................................................................................................................................4 Suspend and Resume Payments .................................................................................................................5 Void Payments ..............................................................................................................................................5 Adjust Transactions.......................................................................................................................................6 Reverse Credit Card Payments ....................................................................................................................6 Process Multiple Receipts in the Same Transaction ....................................................................................6 Imaging At The Counter ................................................................................................................................7 Receipts & Endorsements.............................................................................................................................7 Audit Trails ....................................................................................................................................................7 Audit Window ................................................................................................................................................8 Financial Control with Flexibility ....................................................................................................................8 Deployment ...................................................................................................................................................9 Operating Environment for Cashiering Workstations....................................................................................9 Cashiering Workstations .............................................................................................................................10 Peripheral Devices ......................................................................................................................................11 Batch Management .....................................................................................................................................12 Transaction Adjustment ..............................................................................................................................14 Reporting Services......................................................................................................................................16 Query...........................................................................................................................................................19 System Configuration..................................................................................................................................21 Payment Import...........................................................................................................................................22 Payment Export...........................................................................................................................................23 Connectivity.................................................................................................................................................24 Operating Environment ...............................................................................................................................27

This page intentionally left blank.

Introduction

1

Introduction

iNovah is a browser based software package that manages the payment collection and processing activities from all your collection sources to all your accounting and information systems. It combines the latest Web based technologies available today and over two decades of experience with the payment collection needs of government and utilities to create a system that really makes sense!

Replacing old collection procedures with iNovah provides an impressive list of advantages that are discussed in this document. These include:

iNovah stores all payment transactions in a single consolidated database that provides extensive research, revenue and statistical reporting capabilities with unlimited data retention. This database resides at your location. You own the data!

iNovah comes with a full compliment of tools to collect, manage and audit revenue data including Cashiering, Payment Balancing, Payment Administration, Query, Reporting, Import, Export and Configuration Modules. All of these tools combined truly empower you to get the maximum value from your revenue data.

iNovah connects all your collection sources (e.g., remittance processor, over-the-

counter, self-service stations, Internet, phone, etc.) with all your posting systems (e.g., customer information systems, receivable systems, general ledgers and treasury systems) through reusable Web Service interfaces.

iNovah interfaces with most existing computer infrastructures using industry-standard hardware and software. Consequently, it is not necessary to replace current systems to take advantage of the power and flexibility of this system.

iNovah includes a comprehensive feature-packed cashiering module for processing over-the-counter transactions and miscellaneous collections.

Payment Database

2

Payment Database

iNovah is built around a Consolidated Payment Database that stores all of the payment details for every transaction from every collection source. This database serves as the central repository for all types of collections regardless of the number and type of interfaces to collection sources or host based systems. It can house payment activity for different locations, departments and organizations.

The Consolidated Payment Database consists of a set of tables stored in a Microsoft SQL Server 2005 relational database. All access to the database for adding, updating and inquiring on payment activity is controlled through ADO.NET classes using the Microsoft .NET environment.

The structure of the Consolidated Payment Database has been normalized for optimal performance. It includes tables for deposits, payments, audit trail, configuration parameters, report layouts and event logs. Referential integrity is enforced through the use of foreign key constraints. All payments are recorded with a unique identifier consisting of a random 128 bit global unique identifier (GUID) as a primary key.

A local version of the Consolidated Payment Database is stored in a SQL Server Desktop Engine Database on each Cashiering Workstation. It includes the configuration parameters and report layouts used for offline processing. It also stores all of the payments taken during offline processing until these payments are rolled up to the Consolidated Payment Database.

Historical transactions may be kept indefinitely or archived to offline storage after a user-defined period of time. These transactions can be retrieved for subsequent use in queries, report preparation or audits.

The event logging tables include status flags and logs of maintenance activities and sign on attempts. These tables are used to provide a history of activities for security purposes.

An Entity Relationship Diagram (ERD) of the Consolidated Payment Database is available upon request.

Cashiering Module

3

Cashiering Module

To solve your over the counter cashiering needs iNovah includes a feature rich cashiering module. This is the only module that isn’t browser based and we wrote it that way with you in mind. Because our customers must be able to process receipts regardless of network and system status, the system processes in an on-line and off-line mode. This means that our cashiering module will allow you to continue to process payments over-the-counter until network communications are restored and then all off-line payments are automatically sent without requiring cashier intervention or interrupting their current activities.

In addition, the Cashiering Module of iNovah supports a variety of payment collection functions such as:

Entering any type of payment including: Payments allocated to multiple charges Payments for multiple bills Payments without a bill Partial payments Payments made with multiple types of tender Refunds and credit vouchers

Applying any accepted form of tender (such as cash, checks and credit cards)

Suspending and resuming payments

Voiding payments

Correcting Payments

Cashiering Module

4

Entering Payments

Entering payments has never been easier. With the Cashiering Module, you can:

Select payment type by icon, item list, entering a code or scanning a document (such as a bill)

Enter customer account information required for each type of payment

Retrieve customer account information from another computer application

Specify the payment amount

Allocate the payment to one or more revenue accounts automatically or manually

Specify the tender (cash, check, credit card, etc) by selecting a tender type from a list

Specify checking account information by scanning the check or entering checking account numbers

Enter credit/debit card account numbers through a Mag-Stripe Reader, Pin Pad or keyboard

Authorize credit/debit cards through processors or gateways

Validate bills and print receipts based on user-defined formats

Endorse each item of tender based on user-defined formats

Accept Credit and Debit Cards

Image Coupons/Bill Stubs and Checks at the counter

Cashiering Module

5

The Cashiering Module provides you with all the features you need to process credit and debit cards for payments including:

Magnetic stripe and Pin Pad reading and decoding

Keyboard entry of credit card number and other required information

Automatic online credit card authorization through third party processors and gateways

Credit and debit card receipt printing

Credit and debit card reporting

Suspend and Resume Payments

One of the most used features of our system is the ability to Suspend and subsequently Resume payments. Our clients have shared countless situations where the cashier had to suspend a transaction and then resume and complete it at a later time. In addition, it also allows you to resume suspended payments on any cashiering workstation. With the appropriate security, a transaction could be started by one person and then completed by another. This capability can even be used to start a payment on the phone and complete it when the payment is tendered in the office. When a user suspends a payment, the Cashiering Module stores the payment in a “suspense” file that is accessible to other authorized users for a number of days defined in the system’s parameters (typically 2-10 days).

Void Payments

Even the best cashiers can a make mistake, or a customer may come back asking to void their payment. Whatever the reason may be, the Cashiering Module lets you void payments. To void a payment, you simply select the transaction in the Audit Window and void it. Instead of deleting the transaction, the Cashiering Module flags the transaction to indicate it is voided. A new transaction is automatically added to reverse the original one. This feature improves the audit trail by showing that the payment was not only taken but also voided. You may restrict a cashier’s ability to void in the Security settings.

Cashiering Module

6

Adjust Transactions

In some instances, the cashier does not want to void the payment entirely. The cashier may need to correct or adjust the details of the transaction. For this reason, we also have a payment adjustment feature that guides the cashier through the exact steps necessary to alter a previously posted payment. All fields associated with the payment including account number, payment distribution and tender types may be changed in the correction process. The Cashiering Module processes the changes through an automatic void and re-posting process to create a full audit trail. Like the void process, the adjustment process is controlled in Security.

Reverse Credit Card Payments

If the payment being voided or adjusted was paid by credit card, the Cashiering Module lets you reverse these credit card payments from open batches. To reverse a credit card payment, you simply select the original transaction in the Audit Window and the Cashiering Module will void the payment and post the credit card reversal to the current batch.

Process Multiple Receipts in the Same Transaction

The Cashiering Module lets you process any combination of payments (receipts) together as a single transaction. Each receipt is numbered separately in addition to the transaction number and sequence within the transaction. Amounts tendered in a “multi” are applied to all of the receipts in a many to many relationship. Since the update process occurs at the end of the transaction, changes can be made to any of the receipts prior to completing the transaction.

Cashiering Module

7

Imaging At The Counter

Like all good applications, iNovah continues to evolve and new features and functionality are added regularly. Most recently System Innovators has announced Imaging-At-The-Counter as a standard feature of iNovah. With this feature you can image the front and back of bill stubs and/or the tenders used to satisfy the payment. These images are stored in the iNovah database for your reference when researching payment activity. Imagine being able to find a payment processed months ago and immediately see the bill stub and checks used to pay that receipt!

In addition, these images can be printed on the customer’s receipt!

Receipts & Endorsements The Cashiering Module enables users to print receipts and endorse documents in the following ways:

Printing a tear off receipt on a receipt printer Printing a receipt on a shared or dedicated document printer (up to 8 ½ X11) Validating a document as a receipt on a validation or slip printer Endorsing a check or other form of tender on a validation or slip printer Printing a duplicate receipt (with duplicate label) on a receipt, validation, slip or

document printer Printing a duplicate endorsement on a validation or slip printer

Audit Trails

The Cashiering Module records all activity to create a thorough audit trail in both online and offline modes. All payments are recorded to transaction files and audit files while all other activity, such as sign-ons and opening a cash drawer, are recorded only to the audit file. When a cashiering workstation is online, this information is recorded to the Consolidated Payment Database where it is accessible to supervisors and auditors for oversight. When a cashiering workstation is offline, this information is recorded to a local version of the database where it is maintained until it can be automatically synchronized with the Consolidated Payment Database.

Cashiering Module

8

Audit Window

The Cashiering Module includes an Audit Window to view an electronic version of the audit tape. With the Audit Windows, you can:

Search for transactions with filtering capabilities

View transaction details

Print transaction details

Filter to view any combination of batch, transaction, receipt, validation or security entries

Print duplicate receipts or endorsements

Void or correct payments

Financial Control with Flexibility

The Cashiering Module records payments to batches that can be grouped together for daily activity. Batches are assigned to a single cashier and a single processing day for

accountability. All activity for each batch is balanced to a cash till. Cashiers may access one or more batches from any workstation in order to complete their work. Using batches to account for all payment activity rather than workstation or date provides the following capabilities:

Cashiers can use multiple batches per day to segment their work in any appropriate way (work in more than one batch at a time)

Cashiers can record payments at a customer counter and balance their drawer in the back room (remote balancing, away from the counter)

Cashiers can record payments for a new processing day before the old processing day is balanced (multiple days open at the same time)

Cashiers can access their own batch(es) from any workstation or location in order to relieve other cashiers

Cashiering Module

9

Deployment

In order to process payments in both online and offline modes, the Cashiering Module must reside on each cashiering workstation. Authorized individuals can download the Cashiering Module to any PC simply by selecting Download Cashiering Client from the iNovah home page. Once the Cashiering Module is deployed to a PC, both the program and configuration parameters will automatically be updated from the iNovah server based on options maintained by the System Administrator.

Operating Environment for Cashiering Workstations

The Cashiering Module is a .NET application designed to run on Microsoft Windows XP Professional.

The recommended hardware and software for the Cashiering Module are listed below:

Cashiering Module

10

Cashiering Workstations Component Minimal Optimal Processor Intel® Celeron® D Processor 320

(2.40 GHz, 533 FSB) Intel® Pentium® 4 Processor w/ HT Technology (3GHz, 800 FSB)

Memory 512MB Dual Channel DDR SDRAM at 400MHz

1GB Dual Channel DDR SDRAM at 400MHz (or better)

Storage 40GB Ultra ATA/100 7200RPM Hard Drive

40GB Ultra ATA/100 7200RPM Hard Drive (or larger)

Media CD-ROM drive CD-ROM drive Network Access 100MB network card 100MB/1GB auto switching network

card Peripheral Monitor, keyboard and mouse Monitor, keyboard and mouse Operating System Microsoft® Windows® XP Professional Microsoft® Windows® XP Professional Other Virus protection software Virus protection software

Each cashiering workstation (PC) can operate in the following modes:

Offline, independent of all other computers Connected to a Local (or Wide) Area Network using iNovah connectivity

Cashiering Module

11

Peripheral Devices

The Cashiering Module supports USB, serial and parallel printers using OPOS drivers as well as network connected printers. It also supports OCR, bar code, MICR readers, magnetic stripe and PIN-pad readers. Supported cash drawers may be connected to journal/validation printers or PC ports. Some of the specialized peripheral devices that are supported include:

Journal/validation printers

Ithaca PcOS Model 153 (serial or parallel models) Ithaca PosJet 1500 (USB or serial) TPG A776 (USB only)

Slip printers

Epson TM295 Epson TMU395

Input Scanning Devices

Caere 800 Series OCR Readers (Serial only) Caere 5000 Series OCR Readers (with or without built-in mag stripe reader) Welch Allyn IT3800 Bar Code Readers (Serial or USB) Welch Allyn SCANTEAM® 8300 MICR Check Readers (Serial only) IDTech Mag Stripe Readers, Triple-Track (decoded or non-decoded) (Serial only)

Imaging Device

Canon CR-55 Imager (USB)

Supported Cash Drawers

APG Cash Drawers

Batch Management

12

Batch Management Batch Management provides all the capabilities associated with counting and balancing monies collected in each payment batch. It can be accessed from any PC by any authorized user using a web browser.

Balancing capabilities include:

Counting cash in a till based on the number of bundled and unbundled bills and coins Recording and tracking cash pickups Recording counted tender amounts and comparing them with system calculated

amounts Calculating over and short amounts for each type of tender Preparing bank deposit(s) for the batch

Batch Management

13

Balancing can be completed as a one or two step process. Each batch must be balanced and authorized before it can be closed. Balancing can be performed by one person and authorization (acceptance) performed by another or one person can be permitted to perform both steps.

Batches that are not accepted can be electronically returned to the originating cashier along with comments regarding why the batch was rejected so that the cashier may resolve any discrepancy.

Payment Balancing also allows authorized users to combine deposits from different batches into a single consolidated deposit once each batch is balanced. Consolidated deposits can be modified to add, delete or move deposits as needed to create the final bank deposits that can be tracked to reconcile bank statements.

Batch Deposit Reports can be viewed and printed for any individual or consolidated deposit.

Transaction Adjustment

14

Transaction Adjustment

Transaction Adjustment provides the tools to void and correct previously posted payment transactions in closed batches. Powerful query capabilities enable individual transactions to be isolated and displayed on the screen. Changes may be made to individual fields but are recorded as a reversal of the original transaction and the entry of a new transaction to provide a complete audit trail including the date, time, location and ID of the person making the change. Once the change is completed, the reversal entry and the new transaction are automatically posted to customer and accounting systems based on the posting requirements of the original entry. Any associated deposit is automatically updated as well. A reason for the change may also be recorded.

Adjustments can be completed as a one or two step process. Each adjustment must be recorded and authorized. Adjustments can be recorded by one person and authorized by another, or one person can be permitted to perform both steps.

Payment Administration also provides the capability to adjust non-balancing information associated with deposits such as batch date, cash overage and cash shortage. An audit trail is recorded for each change consisting of a reversal entry and a new deposit record. Deposit adjustments also support the separate recording and authorization steps listed above.

Another feature of Payment Administration is the ability to create ACH files for selected payment transactions. Check payments from any Collection Point can be converted to ACH files for electronic transmission to your bank if the required information has been collected.

Transaction Adjustment

15

The flexibility provided in Transaction Adjustment makes it an ideal tool to perform functions such as:

Correcting payments posted to the wrong account

Correcting out-of-balance conditions in bank deposits

Reversing payments due to NSF conditions

Correcting payment distribution errors

Creating ACH files on demand

Reporting Services

16

Reporting Services

iNovah ships with over 150 standard reports. In addition, as new reports are authored they are immediately available to all clients.

The reporting services included with iNovah allow authorized users to display and print formatted reports from any PC with a Web browser. Reports may also be scheduled to run automatically on pre-defined dates and times. Reports are generated as files and can be automatically distributed via e-mail to designated users who need the reports.

Each report contains pre-defined selection criteria such as date range that can be satisfied with entered data or meta-data such as ‘this week’ or ‘today’. Reports also provide extensive drill down capabilities to see the details behind each total. Access to report as well as the data on the reports is controlled by you through flexible security settings.

Reporting Services

17

All standard reports have been created using Microsoft SQL Server 2005 Reporting Services and are stored as XML-based Report Definition Language (RDL) tables in the iNovah database. Any reporting tool that utilizes RDL formatting can be used to create or modify reports. New and modified reports can be added to the library of standard reports through the configuration module.

There are 6 types of reports included in the standard report library – Batch, Deposit, Payment, Allocation, Tender and Analysis & Audit.

Reporting Services

18

Many of the standard payment reports have drill-down capabilities (where applicable) and may be sorted by batch, date, batch owner, office, collection point, payment origin, machine id, company or department. They include:

Allocation Totals Credit/Debit Card Totals GL Totals Payment Type Totals Tender Totals ACH Totals ACH Transaction Detail Adjusted Transaction Detail Cashier Over/Short/Deposits Fund Transfer Detail Transaction Detail for a Single Batch Payment Batch Detail Report Single Transaction Report

Queries

19

Query

The Query Module of iNovah provides incredible flexibility and access to the data. Security throughout the product ensures that your users can only query and report on those payment and audit records that you have given them access to.

Queries are constructed by picking the fields to be viewed and entering the search and sort criteria. In addition to setting search and sort criteria, Queries can be built with user prompts for dynamic query results. This powerful interface simplifies the construction of queries, allows them to be saved for subsequent use and the implementation of user prompts eliminates the need for redundant queries.

Record counts and totals are automatically provided on each query.

Queries

20

Repetitive research requests can be completed and printed through saved queries from any authorized person. The following types of queries are available:

Transaction queries Payment queries Payment Allocation queries Tender queries Deposit queries

Audit queries provide an extra level of verification. Since all information printed on receipts and associated documents are recorded in a separate audit table of the Consolidated Payment Database, queries can be performed on this data as well. An electronic audit tape can be accessed from the Query Module to identify what happened before, during and after a transaction in question.

Saved queries can be run using any payment data in the Consolidated Payment Database. Query results can be printed or exported to other applications as an XML document.

A special query process has been created to browse payment data without creating a query definition. This browsing capability will retrieve payment data based on selected filters such as office, cashier id or date.

.

Configuration

21

System Configuration

Configuration capabilities allow the system administrator to add, change and delete a wide variety of parameters that control the operation of the system.

These types of enterprise wide changes are done from the comfort of an individual desk while the results are pushed to all components that utilize that function. Parameters that are maintained in this module include:

Server based services for connectivity, performance Credit card authorization ACH processing Email Notification Scheduling for imports, exports, reports and maintenance deployment Payment types and the information required for each type Payment type collection options User defined data fields Payment allocations and the information required for each allocation Tender types and the information required for each type of tender Collection points Receipt and endorsement forms Offices Banks Funds Workstations Peripheral devices Security settings, user accounts and groups

Payment Import

22

Payment Import

Payment Import capabilities provide a means to import payments from other systems into the Consolidated Payment Database. The module is accessed from any PC through a Web browser and supports the following capabilities:

Importing payments in standard XML or ASCII file formats

Importing payments in non-standard file formats (once a process is tailored)

Performing account inquiries using inquiry web services

Accept and reject payments based on user-defined criteria in web service

Save rejected payments to a separate file

View import results and statistics

Payment Export

23

Payment Export

Payment Export capabilities provides a means of exporting payments from the Consolidated Payment Database to payment files for use by other systems. The module is accessed from any PC through a Web browser and supports the following capabilities:

Exporting payments in standard XML or ASCII file formats

Exporting payments in non-standard file formats (once a process is tailored)

Selecting payment batches and date ranges for export

Connectivity

24

Connectivity

iNovah includes a server based transaction processor to connect the various collection points with each of your customer information, receivable, general ledger and treasury applications using resource pools. The resource pools are collections of shared system resources that ensure performance when a large number of client systems interface the host systems, databases and legacy applications where customer information is stored. For example, 100 cashiering workstations could be updating the Consolidated Payment Database using 10 shared connections.

Five basic types of transactions are managed using separate resource pools for each source of payment. They include host inquiries, host updates, client requests, client updates and message logging. A description of each type of transaction is included below.

Connectivity

25

Host Inquiries

iNovah can interface other computer applications such as customer information systems, billing systems and receivable ledgers to retrieve account information about a payment that is being made. This serves two purposes: first, the account identification can be verified; second, payment options can be determined and enforced.

Each host inquiry routine is tailored to meet your needs using a Web Service. Web Services can support many different types of interface techniques such as stored procedures, Dynamic Link Libraries (DLL) and XML data exchange. The design of iNovah allows these Web Services to be shared by different collection sources. For example, the online account inquiry used in the cashiering module to take over-the-counter payments can also be used by IVR or Web based payment options.

Host Updates

Other computer applications are also interfaced to post payment and summary information. Collected payment details can be sent to customer information systems, billing systems and receivable ledgers using online or batch interfaces. Summary information, such as the total amount collected by payment type, can be sent to the general ledger and deposit information can be sent to a treasury system.

Each host update routine is also tailored to meet your needs. Online updates use the Web Services listed above while batch posting routines typically create file layouts that match an existing update process in the receiving application. Host update routines can also be shared by different collection sources. For example, payments collected over-the-counter, through the mail and through other agencies can all use the same host update routine(s) to post the payments to the appropriate applications.

Client Requests

iNovah supports several different types of collection sources (clients) that can make online requests for information including over-the-counter or miscellaneous collections through the Cashiering Module, remittance processors, Interactive Voice Response Systems (IVR) and Web based collection clients. When a request is made by one of these systems, iNovah processes the request and activates the appropriate host inquiry to retrieve the information and send it to the workstation or terminal that requested it. Each client request module can be tailored to process any number of information fields that need to be retrieved in order to properly process each payment.

Client Updates

All payments collected through each type of collection source (client) are written to the Consolidated Payment Database using an ADO.NET update routine. This update can be performed online as each payment is collected or in a batch mode depending on the capabilities of the client. In addition, payments can be queued for an immediate host update or they can be flagged for update at a later time.

Connectivity

26

Payments collected through online interfaces such as the Cashiering Module are normally written to the database as they are collected but can also be written at a later time if the client is operating offline for any reason. Payments processed through batch interfaces to clients, such as remittance processors or other third party applications, are written to the database as payment batches are made available.

Message Logging

As system events occur, iNovah logs these events in an internal log file. Selected event messages can also be e-mailed to one or more e-mail addresses to identify potential problems before they occur. The following events are logged by the system:

Routine statistical performance

Completion statuses for each payment update

Warnings about low system resources

Host availability statuses

Payment transmission errors

System failures

Operating Environment

27

Operating Environment

iNovah is a Web based application developed in .NET that utilizes the Microsoft IIS Web Server capabilities of Windows Server 2003 R2 Enterprise Edition. PCs accessing the system, such as cashiering workstations, also use the .NET features of their operating system, Windows XP Professional. All modules are written in Microsoft Visual C# or C++ and use Java for HTML manipulation.

A Microsoft SQL Server 2005 relational database is used to consolidate all payment activity across all collection sources. All collection sources access the database through ADO.NET compliant routines. Microsoft SQL Server Reporting Service is used to create all standard reports. RoboHelp Office Pro for .NET is used to create the Help systems.

The system utilizes TCP/IP network protocol to support access to all internal applications such as Customer Information Systems and Accounting Systems as well as external systems through the Internet.

The recommended hardware and software for iNovah are listed below:

Web Server / Database Server Component Minimal Optimal Processor Dual-Core Intel® Xeon® 5110 (166 GHz

processor, 2MB Cache, 1066MHz Front Side Bus)

2 or more Quad-Core Intel® Xeon® 200 GHz processors, 2x4MB L2 Cache, 1333MHz Front Side Bus

Memory 4GB DDR2 400MHz (2X2GB), Dual Ranked DIMMs (upgradeable)*

16GB DDR2 400MHz (8X2GB),Dual Ranked DIMMs (upgradeable)*

Storage Five 36 GB hot swap, high speed SCSI hard drives

8 or more 72+ GB hot swap, high speed SAS/SATA drives

RAID Level 5 Level 10 Power Supply Dual 200-240 Volt Dual 200-240 Volt Media CD/DVD ROM drive CD/DVD ROM drive Network Access Dual 1GB network cards Dual 1GB network cards Peripheral Monitor, keyboard and mouse Monitor, keyboard and mouse Operating System Microsoft Windows Server 2003 R2

Standard Edition Microsoft Windows Server 2003 R2 Enterprise Edition

Database Platform Microsoft SQL Server 2005 Standard Edition SP2 or later

Microsoft SQL Server 2005 Enterprise Edition SP2 or later

Other Backup software and hardware Virus protection software

Backup software and hardware Virus protection software

NOTE: Sizing depends on the number of users and transaction volumes (the minimum recommended size is

shown). The database server and the transaction server could be combined in one server at installations with less than 1,000,000 payments per year however this is not the recommended configuration.

28

(This page intentionally left blank)