Attachment 3 - Scope of Work

A. Overview of Required Cashiering Capabilities

The proposed Solution must provide advanced, modern cashiering capabilities that support city-wide operations, including, but not limited to, the following:

1. In-person cashiering at multiple City locations

2. Online and remote payment processing, including payment kiosks in different City locations

3. Support for cash, check, credit/debit cards, ACH, E-check and IVR payments

4. Centralized configuration and management of cashiering rules and policies

5. Role-based access controls and segregation of duties

6. Real-time transaction reporting and processing into Workday Financial Management

7. End-of-day balancing, reconciliation, and audit reporting

8. Integration with Workday Financial Management and other City systems of record and payment-related applications.

The Solution shall support the ability to record and process transactions originating from external systems via file import or integration

The Solution must be configurable to meet varying departmental needs while maintaining consistency and control across the enterprise.

B. Point-of-Sale (POS) and Cashiering Functions

The proposed Solution shall support point-of-sale (POS) operations for departments that accept payments in person. The POS functionality must enable City staff to efficiently process payments while maintaining strong financial controls and accurate transaction records.

1. Core Cashiering Capabilities

The POS interface shall allow authorized users to:

a. Accept payments from customers for City services, fees, permits, fines, and other charges

b. Retrieve account and/or invoice information from integrated systems, where applicable

c. Process multiple payment methods within a single transaction

d. Issue receipts for all completed transactions (electronic and paper)

e. Search and retrieve prior transactions for research or customer service purposes

The Solution shall provide an intuitive and user-friendly interface suitable for high-volume cashiering environments. The Solution shall also support integration with kiosk-based payment channels where applicable.

The Solution should support self-service payment kiosks that allow customers to independently complete transactions without assistance from City staff. Kiosk functionality should utilize the same cashiering platform, business rules, security controls, reporting, and reconciliation processes used for staffed cashiering operations.

2. Transaction Processing

The POS system shall support the ability to:

a. Process full or partial payments, where permitted

b. Accept multiple tenders for a single transaction

c. Process refunds, reversals, or adjustments with appropriate authorization

d. Generate transaction receipts and confirmations

The Solution should support configurable business rules to enforce payment policies, city ordinances and departmental requirements.

3. Peripheral Device Support

The POS system shall support commonly used cashiering peripherals, including, but not limited to:

a. Receipt printers

b. Cash drawers

c. Barcode scanners

d. Check scanners or image capture devices

e. Credit and debit card terminals

f. Payment terminals shall support contactless (tap) payments, including NFC (Near Field Communication)-enabled devices and mobile wallets.

The Solution should support integration with devices required for electronic payment processing.

C. Payment Types and Tender Management

The proposed Solution shall support multiple payment methods and provide tools to manage various payment tenders across departments and payment locations.

1. Supported Payment Methods

At a minimum, the Solution shall support the following payment methods:

a. Cash

b. Check

c. Credit card

d. Debit card

e. ACH or electronic check (e-check)

The Solution should support integration with external payment channels such as bank bill pay or third-party payment providers where applicable. The Solution should support acceptance of these payment methods through both staffed cashiering locations and self-service kiosk environments. The Solution should also support additional payment methods that may become common in municipal payment environments.

2. Tender Management

The Solution shall provide functionality to manage payment tenders and ensure accurate recording of payment activity. At a minimum, the Solution shall support:

a. Tracking payment transactions by payment method

b. Recording split payments involving multiple payment types

c. Managing refunds, voids, and reversals by payment method

d. Reconciliation of payments by tender type

The Solution shall maintain clear records of all payment activity by tender type for reconciliation and reporting purposes.

3. Payment Processing Integration

Offeror will need to propose integrated payment processing that support the centralized acceptance, processing, settlement, and reconciliation of credit card, debit card, ACH/e-check, and other electronic payment types through a unified payment ecosystem.

D. User Roles, Permissions, and Internal Controls

The proposed Solution shall support configurable user roles and permissions that enforce internal financial controls and separation of duties.

1. Role-Based Access Controls The proposed Solution shall allow the City to define user roles that determine access to system functions and financial data. Access rights shall be configurable by role, department, or location.

At a minimum, the Solution shall support the ability to:

a. Assign roles to users based on job responsibilities

b. Restrict access to sensitive financial functions

c. Control access to reporting and administrative features

2. Separation of Duties

The Solution shall support separation of duties between key financial functions to reduce the risk of fraud or unauthorized activity. At a minimum, the Solution shall allow the City to configure separation of duties between roles such as:

a. Cashiers processing transactions

b. Supervisors approving refunds or adjustments

c. System administrators managing configuration settings

d. Audit or reporting users reviewing financial activity

3. User Management

The Solution shall provide tools to manage user accounts and permissions, including:

a. Creating, modifying, and disabling user accounts

b. Assigning user roles and access levels

c. Tracking changes to user permissions

The Solution shall maintain audit logs of changes to user roles and permissions.

E. Reports

The proposed Solution shall provide comprehensive reporting capabilities that support operational oversight, financial reconciliation, auditing, and reporting and operational decision-making. Reporting tools must be accessible to authorized City staff without requiring Offeror intervention or specialized technical expertise.

1. Standard and Custom Reports

a. Standard Reports

i. The Solution shall include a set of configurable, out-of-the-box standard reports to support daily cashiering operations and financial oversight. At a minimum, the Solution shall provide reports that support:

b. Daily cashier activity and drawer balancing

c. Transaction summaries by department, location, and cashier

d. Payment summaries by payment method (cash, check, credit card, debit card, ACH/e-check, and other supported tenders)

e. Deposit summaries and settlement reports

f. Refund, reversal, and void transaction reports

g. Audit trail reports identifying user activity and system actions

h. Transaction detail reports that allow drill-down to individual payment records

ii. Reports shall include transactions that are processed directly within the cashiering system as well as transactions imported from external systems. The Solution shall support retention and reporting of historical transaction data for a minimum of seven (7) years.

b. Custom Reporting Capabilities

i. The Solution shall allow authorized City staff to create and manage custom reports without Offeror assistance. At a minimum, the Solution shall support:

a. Creation of custom reports using available system data fields

b. Filtering, sorting, and grouping of report data

c. Ability to filter reports by department, payment location, payment method, transaction status, user, and date range

d. Ability to save report templates for future use

e. Ability to modify existing reports as business needs evolve

f. Scheduling or auto-run of saved reports at set times/intervals and sent via e-mail or autosaved to specified locations

c. Data Access and Query Tools

i. The Solution shall provide tools that allow authorized users to perform ad hoc queries and transaction research. Users shall be able to search and retrieve transaction records using multiple criteria, including, but not limited to:

a. Transaction or receipt number

b. Customer name or account identifier

c. Customer Address

d. Payment method i.e. last 4 digits of card number

e. Department or location

f. Date or date range

g. User or cashier

The Solution should allow users to drill down from summary reports to detailed transaction-level information.

d. Report Export and Distribution

i. Reports generated by the system shall be exportable in commonly used formats, including, but not limited to:

a. Microsoft Excel

b. CSV

c. PDF

The Solution should support the scheduling and automated distribution of reports to designated users via email or other electronic delivery methods.

e. Security and Access Controls

Reporting capabilities shall support role-based access controls to ensure that users can only view reports and data appropriate to their assigned roles and departmental permissions. The Solution shall support department-specific reporting access while allowing authorized Treasurer's Office staff to view reporting data across all participating departments.

2. Daily Reconciliation and Deposit Reporting

The proposed Solution shall support accurate and efficient reconciliation of payments, deposits, and settlements. The proposed Solution must provide reporting and functionality that allows the City to reconcile cashiering activity on a daily basis and verify that all payments are properly recorded, deposited, and posted to the appropriate financial systems.

a. Daily Reconciliation Capabilities

The Solution shall support daily reconciliation of cashiering activity across departments, locations, and payment methods. At a minimum, the Solution shall provide functionality and reporting to support:

i. Daily balancing of cashier drawers and cashier sessions

ii. Reconciliation of transactions by cashier, department, and payment location

iii. Reconciliation of transactions by payment method (cash, check, credit card, debit card, ACH/e-check, and other supported tenders)

iv. Verification that all transactions recorded in the cashiering system have been successfully processed and settled

The Solution should allow authorized users to identify and research discrepancies during the reconciliation process.

b. Deposit Reporting

The Solution shall generate reports that summarize deposits by date, department, payment location, and payment method. These reports must support the City’s ability to verify that funds collected through the cashiering system have been properly deposited with the City’s financial institution(s). At a minimum, the Solution shall support:

i. Daily deposit summaries

ii. Deposit reports by payment method

iii. Deposit reports by department or payment location

iv. Ability to trace deposits back to individual transactions and receipts

c. Settlement and Processor Reconciliation

For electronic payments (including credit cards, debit cards, and ACH/e-check transactions), the Solution shall support reconciliation between cashiering transactions and settlement data from payment processors or financial institutions. The Solution should provide reporting or tools that allow authorized City staff to:

i. Reconcile electronic payment transactions with settlement batches

ii. Identify failed, rejected, or returned transactions

iii. Track refunds, reversals, and chargebacks

iv. Research discrepancies between transaction totals and settlement amounts

d. Integration with Financial Systems

The Solution shall support integration with the City’s enterprise financial system, Workday Financial Management, which serves as the City’s system of record for the general ledger. The Solution shall support the ability to:

i. Generate transaction files or data feeds required for financial posting

ii. Ensure that cashiering transactions can be traced to corresponding financial entries

iii. Support reconciliation between the cashiering system and financial system postings

iv. The Solution shall support tracing transactions from initial payment through settlement, deposit, and posting to Workday Financial Management.

e. Audit and Compliance Reporting

The proposed Solution shall provide comprehensive audit and compliance reporting capabilities that support the City’s financial controls, internal audit activities, and regulatory compliance obligations. The Solution shall support reporting and data access necessary to demonstrate compliance with financial controls and audit requirements.

The Solution must maintain detailed records of all transactions, system actions, and user activities to ensure transparency and accountability in payment processing.

f. Transaction Audit Trails

The Solution shall maintain a complete and permanent audit trail of all payment transactions processed through the cashiering system. At a minimum, the audit trail shall capture:

i. Transaction date and time

ii. Unique transaction or receipt identifier

iii. Payment amount and payment method

iv. Department or payment location

v. User or cashier responsible for processing the transaction

vi. Any subsequent actions related to the transaction (such as refunds, reversals, or adjustments)

Audit trails shall also include transactions imported from external systems, including the source of the transaction data and the date and time the import occurred. The Solution shall allow authorized users to retrieve transaction histories and supporting details for audit or research purposes.

g. User Activity and System Access Logging

The Solution shall log all relevant user activities within the application. Audit logs shall capture key system actions performed by users, including, but not limited to:

i. User logins and logouts

ii. Creation, modification, or deletion of records

iii. Processing of payments, refunds, voids, or reversals

iv. Changes to system configuration or user permissions

v. Importing of external transaction files

The Solution shall maintain these logs in a manner that prevents unauthorized alteration or deletion.

h. Compliance Reporting

The Solution shall support reporting necessary to demonstrate compliance with applicable financial controls, regulatory requirements, and City policies. At a minimum, the Solution shall support reporting related to:

i. Payment card security requirements (PCI DSS compliance support)

ii. ACH and electronic payment processing requirements (NACHA compliance support)

iii. Audit logs of user activity

iv. Transaction history and changes

v. Exception and adjustment tracking

vi. Payment and settlement tracking

The Solution shall allow authorized users to generate reports that support internal and external audit reviews. Examples may include identifying unusual refund activity, excessive voids, or transactions processed outside normal business hours.

i. Exception and Control Monitoring

The Solution shall provide reporting capabilities that allow the City to monitor for potential control issues or unusual activity. At a minimum, the Solution shall support reports identifying:

i. Voided transactions

ii. Refunded transactions

iii. Adjusted or reversed transactions

iv. Transactions processed outside normal business hours

v. Imported transaction batches and associated exceptions

vi. Other configurable exceptions defined by the City, such as unusual refund activity or reconciliation discrepancies.

These reports should help City staff identify potential errors, policy violations, or fraudulent activity.

j. Data Retention and Historical Reporting

The Solution shall retain transaction records, audit logs, and related reporting data for a period consistent with City records retention policies and applicable regulatory requirements minimum of seven (7) years. The Solution shall allow authorized users to access historical records and generate reports for prior reporting periods.

3. Financial Transparency and Controls

The proposed Solution shall support strong financial transparency and internal control practices across all City departments that accept payments. The Solution must provide the City with centralized visibility into payment activity and ensure that financial processes are performed in a controlled, auditable, and consistent manner.

a. Centralized Visibility of Payment Activity

The Solution shall allow authorized City staff, including the Treasurer’s Office, to view payment activity across all participating departments and locations. The Solution shall support consolidated reporting that provides a citywide view of:

i. Payment transactions by department and payment location

ii. Payment activity by payment method

iii. Daily transaction totals and summaries

iv. Deposit activity across departments

This visibility shall include transactions processed directly through the cashiering system as well as transactions imported from authorized external systems. Authorized Treasurer's Office users shall have the ability to view payment activity and reporting data across all participating departments and payment locations. The Solution should allow authorized users to view both high-level summaries and detailed transaction-level data.

b. Internal Financial Controls The Solution shall support internal financial controls designed to reduce risk and ensure accurate financial reporting. At a minimum, the Solution shall support:

i. Controls that ensure all payments are recorded and tracked through the Solution

ii. Controls that prevent unauthorized modification of financial records

iii. Documentation of all adjustments, refunds, voids, and reversals

iv. Ability to identify and track discrepancies or irregularities

The Solution shall maintain a clear record of all actions taken on payment transactions.

c. Role-Based Access and Separation of Duties

The Solution shall support role-based access controls that restrict user permissions based on assigned responsibilities. The Solution shall allow the City to configure user roles that limit access to sensitive functions. At a minimum, the Solution shall support separation of duties between functions such as:

i. Cashiering and transaction processing

ii. Refund or adjustment approvals

iii. Solution administration and configuration

iv. Reporting and audit access

The Solution shall allow the City to assign and manage user permissions at the department, location, or role level.

d. Consistency of Financial Processes

The Solution shall support consistent payment processing practices across departments. The Solution should enable the City to establish standardized procedures for cashiering, reconciliation, and reporting.

The Solution should allow departments to manage their operational needs while maintaining centralized financial oversight and control.

4. Exception Reporting and Alerts

This section focuses on proactive monitoring and alerting, distinct from standard reporting and audit capabilities. The Solution shall provide reporting and alerting capabilities that allow the City to identify, investigate, and resolve discrepancies, errors, and unusual activity in a timely manner. The Solution must support proactive monitoring of financial activity to strengthen internal controls and reduce operational risk.

a. Exception Reporting

The Solution shall generate reports that identify transaction anomalies, discrepancies, or policy exceptions. At a minimum, the Solution shall support reporting related to:

i. Voided transactions

ii. Refunded transactions

iii. Adjusted or reversed transactions

iv. Transactions exceeding configurable thresholds

v. Transactions processed outside normal business hours

vi. Failed or rejected electronic payment transactions

vii. Potential duplicate transactions

viii. Imported transaction batches with validation errors

ix. Unbalanced cashier sessions or drawers

Exception reports shall allow authorized users to identify the department, user, and transaction associated with the exception.

b. Alerting and Notifications

The Solution should support configurable alerts that notify authorized City staff when defined conditions occur. Alerts may be triggered by transaction activity, reconciliation discrepancies, or system errors. Alerts shall support configurable thresholds by department, location, transaction type, or payment method. At a minimum, the Solution should allow alerts for:

i. Reconciliation discrepancies

ii. Failed payment processing or settlement errors

iii. Potential duplicate transactions

iv. Imported transaction file failures or validation errors

v. Excessive voids, refunds, or adjustments

vi. System or integration failures impacting payment processing

Alerts should be configurable and may be delivered through methods such as email, system notifications, or dashboards.

c. Exception Investigation Tools

The Solution shall provide tools that allow authorized users to investigate and resolve exceptions. Users shall be able to:

i. Drill down from exception reports to transaction-level detail

ii. Identify the user and department associated with the transaction

iii. Review associated audit trail information

iv. Track resolution or corrective actions taken

F. Integration with Workday Financial Management (including Sandbox Environment)

The City utilizes Workday Financial Management as its enterprise financial system of record. The proposed Solution must be integrated with Workday to support accurate, timely, and secure posting of financial transactions, reconciliation of payments, and maintenance of financial controls.

The awarded Offeror shall provide a robust integration with Workday that supports the automated exchange of financial data between the proposed cashiering solution and Workday Financial Management. Integrations must support the City’s operational requirements for receipting, payment settlement, refunds (including partial refunds), adjustments, and financial reporting.

1. Financial Transaction Processing

The proposed Solution must support the automated transmission of financial transactions to Workday Financial Management, including, but not limited to:

a. Payment receipts

b. Payment allocations

c. Refunds and reversals

d. Adjustments and corrections

e. ACH and card settlement records

f. Daily batch or summary Ad Hoc Bank Transactions where appropriate

2. Reconciliation & Financial Controls

The proposed Solution should provide mechanisms to support financial reconciliation between the cashiering system and Workday. The proposed Solution must support auditability and financial transparency consistent with municipal accounting practices.

3. Workday Sandbox & Integration Testing

The City maintains Workday non-production environments (e.g., Sandbox or Implementation tenants) used for integration development, testing, and validation. The awarded Offeror shall provide the following services:

a. Support development and testing of integrations using the City’s Workday Sandbox environment.

b. Integration configuration, testing, and validation across development, testing, and production environments.

c. Tools and documentation necessary to support integration testing.

d. Participate in integration testing activities with City technical staff during implementation.

G. Integration with Existing City Systems (ACT, Accela, CORIS, Salesforce, TMS, etc.)

The City maintains several custom systems that integrate with the custom Treasury Management System (TMS) client/server architecture. These integrating systems currently use a Windows Communication Framework (WCF) payment API for credit card payments that are hosted internally.

1. TMS Components

The custom TMS software consists of four major thick client components:

a. A cashiering point of sale system

b. A lockbox import system for NACHA ACH and other external payment transactions. These transactions generate an import file that is manually uploaded to Workday Financials for reconciliation.

c. A management dashboard for analytics and reporting,

d. An integration API for in-house systems and integrations.

The City desires to replace all these components with the Offeror’s proposed solution.

2. In-house Payment API

The API is responsible for validating and forwarding payment requests to Chase Payment Tech for credit cards and debit cards. Surcharge fees are calculated and applied during processing when credit card payments are detected, not debit card. The API returns responses to our in-house software to update account balances as necessary or report rejected transactions to the user. The City is willing to replace this API with the Offeror’s proposed API solution in remaining in-house systems and integrations.

3. Azure API Management Services

The City operates an Azure tenant and utilizes API management services to provide API integrations internally to our hybrid cloud as well as to external partners. In-house payment portals currently use WCF APIs to process payments.

The awarded Offeror can utilize existing APIs for integrations and/or coordinate proxy APIs for integrations to any remaining in-house custom system as needed to minimize cascading changes during implementation.

4. TMS Lockbox

The City’s lockbox is in-house software responsible for importing financial transactions from various sources and outputting an ad-hoc banking transaction file for import into Workday Financials. These transactions include the following:

a. Wells Fargo NACHA ACH/eCheck transactions are exported from the in-house TMS Cash Register when the register is closed. Fees are collected through cash, direct deposit, credit and debit cards, check, ACH, and e-check.

b. Golf Courses use Lightspeed payments and Stripe to collect fees and exports sales to lockbox via a CSV file. Fees are collected through credit and debit cards and checks.

c. Public Lands uses ActiveNet payment via https://www.slc.gov/parks/services-requests/ to collect reservation fees and exports sales to lockbox via a CSV file. Fees are collected through credit and debit cards and checks.

d. The City Library uses the T2 Parking system and hardware to collect parking fees and export sales to lockbox via a CSV file. Fees are collected through credit and debit cards.

e. The City uses Open Counter for collecting fees for some permits and special events via https://salt-lake-city.opencounter.com/. Those sales are exported as a CSV file and imported into lockbox. Fees are collected through debit and credit cards and checks.

The awarded Offeror shall replace the manual TMS lockbox processing and ease reconciliation workflows.

5. Automated Citation Tracking (ACT) System

The City Finance Department uses the in-house ACT system to manage collection of civil citation fees. The ACT system is a thick-client desktop software that users can utilize to collect credit card payments in-person or over the phone. The payment is processed via the City’s central payment API.

The City will continue to use ACT and integration into the awarded Offeror’s solution will be required via API calls. This integration may be a warm handoff for payment, or the City can provide API access for lookup of payment information if supported.

6. Parking & Civil Citation Payment Website

The City’s parking and civil citation payment website can be accessed via https://www.slc.gov/payments/. It works in conjunction with the ACT system database to allow the public to access and pay their fees. The website uses the same central payment processing API that ACT uses.

The awarded Offeror may subsume this functionality in their Solution or provide an integration.

7. Accela

The Accela system is cloud hosted and used to collect fees for permits and other public services fees. The Accela Citizen Access (ACA) is integrated with the Can/Am Teller system for payment processing. Teller posts its transactions to Workday Financials for reconciliation. The City is interested in consolidating Accela payments into one payment processing system.

8. Public Utilities Miscellaneous Payment Processing

a. Public Utilities is currently replacing their legacy billing system and customer information system that will handle customer invoicing and payment processing that is outside the scope of this RFP. However, Public Utilities has a requirement to generate accounts receivable and process payments outside of customer accounts.

b. Public Utilities uses Cityworks for project costing for repair services and new construction to costumer outside of Salt Lake City limits. It is also used for project costing for sewer repairs and other projects not managed and billed through Accela.

c. Public Utilities also uses the City’s custom Cashier Online System as well as Teller for receiving miscellaneous payments.

d. Public Utilities Cityworks will integrate with the new Solution to allow these miscellaneous payments to be processed.

9. Utah Courts Information System (CORIS)

Salt Lake City Justice Courts operate a custom court and traffic ticket payments portal accessible via https://www.slc.gov/payments/. It interacts with the Utah CORIS system APIs to obtain citation balances and post payments. The City IMS department maintains a custom WCF API that provides the integration to the Utah CORIS Case Information API methods.

Integration with the City’s Justice Court payment portal can be continued with the proposed Solution as a warm handoff for payment using API calls, or it can be replaced by the proposed Solution when it integrates with Utah CORIS during implementation or a future date.

10. Salesforce

The City’s business licensing division operates an online application and renewal application on the Salesforce platform that can be accessed via https://www.slc.gov/payments/. This Salesforce application presents fees for payment and collects payment information that is submitted to our internal payment API via the City’s Azure API management service.

The City will retain the existing business license application.

11. Special Assessments

Special Assessment Areas (SAAs) in Salt Lake City are designated zones where commercial property owners agree to self-assess to fund specific improvements, maintenance, or economic promotions, such as those run by the Downtown Alliance. These areas are established to enhance urban environments and promote economic activity beyond standard municipal services.

The City provides a public Special Assessment fee payment portal accessed via https://www.slc.gov/payments/. This portal allows participating entities to pay their fees annually, with the option to pay the full assessment in a single payment using either credit card or eCheck.

The proposed Solution currently uses the central in-house payment APIs and will convert the Offeror’s APIs during implementation. However, the City is planning to redesign this special assessment workflow and will require an API-based approach to payment in the future design.

12. Just FOIA

Just FOIA is the City’s Government Records Access Management Act (GRAMA) portal that can be accessed via https://saltlakecityut.justfoia.com/publicportal/home/newrequest. The portal is not currently accepting payment but should integrate with Offeror’s proposed Solution.

13. Bryt

Transactions are currently processed through Teller, but there is no integration with Teller. The portal is not currently accepting payment but should integrate with Offeror’s proposed Solution.

H. Secure APIs and Data Exchange

The proposed Solution shall support secure, standards-based mechanisms for data exchange with City systems and external services. Because the cashiering system will interface with Workday Financial Management, custom in-house applications, and other potential third-party systems, the Offeror must provide robust and secure API capabilities that enable reliable integration while protecting sensitive financial and personal information.

The City prefers API-first integration architectures that support real-time or near-real-time communication and minimize reliance on manual processes or file-based interfaces wherever feasible.

1. API Capabilities

The proposed solution shall provide modern, standards-based API capabilities that allow authorized systems to securely exchange data with the cashiering platform. At a minimum, the solution must:

a. Provide RESTful APIs for core integration functions where feasible.

b. Support JSON or XML data formats for structured data exchange.

c. Support secure API authentication and authorization mechanisms, such as OAuth 2.0, token-based authentication, or equivalent modern standards.

d. Support role-based or scoped API access controls to limit data access to authorized systems.

e. Provide mechanisms for API versioning to support future changes without breaking existing integrations.

f. Provide rate limiting and throttling controls to protect system performance and availability.

2. Data Exchange Methods

While the City prefers real-time API integrations, the proposed Solution must support multiple secure data exchange methods to accommodate existing and future system integrations.

3. Security Requirements for Data Exchange

All integrations and data exchanges must comply with the City’s security, privacy, and regulatory requirements. At a minimum, the Solution must:

a. Encrypt all data in transit using TLS 1.2 or higher.

b. Enforce strong authentication for API access.

c. Prevent unauthorized access to sensitive financial or personal data.

d. Log all API activity and integration transactions.

e. Support integration monitoring and anomaly detection where feasible.

4. API Documentation and Developer Support

The awarded Offeror shall provide comprehensive documentation to support integration development and ongoing maintenance. Documentation shall include:

a. API specifications and endpoint descriptions

b. Authentication and authorization requirements

c. Data schemas and payload examples

d. Error handling and response codes

e. Rate limits and usage constraints

5. Integration Monitoring and Error Handling

The proposed Solution should include capabilities to support operational monitoring of integrations and API activity. These capabilities shall support City IT staff in maintaining reliable integrations between the cashiering system and other enterprise systems.

I. Future Integration and Scalability

The City anticipates that additional systems, applications, and services will require integration with the Solution over the life of the system. These future integrations may include new City-developed applications, third-party SaaS platforms, departmental systems, payment channels, or emerging digital services.

The proposed Solution must therefore provide a flexible, scalable integration architecture capable of supporting future integration requirements without significant redesign or disruption to existing operations.

1. Extensibility and Integration Flexibility

The Solution architecture should support modular expansion and avoid tightly coupled integrations that may hinder future system enhancements. At a minimum, the Solution shall:

a. Provide extensible API-based integration capabilities that support new integrations without significant reconfiguration.

b. Support standards-based integration protocols and commonly used data exchange formats.

c. Allow integration with both on-premises and cloud-based systems.

d. Support integration with City-developed applications, third-party SaaS platforms, and external service providers.

e. Enable integration expansion without requiring major system downtime or reimplementation.

J. Monitoring and Error Handling for Integrations

The proposed Solution must provide robust monitoring, alerting, and error-handling capabilities for all integrations with City systems and external services. Because integrations will support critical financial processes—including payment processing, financial posting to Workday, reconciliation, and departmental system workflows—the City requires tools that ensure integration reliability, rapid issue detection, and efficient resolution of errors.

1. Integration Monitoring

The proposed Solution shall provide tools or capabilities to monitor the status and performance of integrations between the cashiering system and external systems. At a minimum, the Solution must:

a. Monitor API calls, data exchanges, and integration transactions.

b. Provide real-time or near-real-time visibility into integration status.

c. Track successful and failed transactions.

d. Capture processing timestamps and transaction identifiers.

e. Provide dashboards or reporting tools that allow City technical staff to review integration activity.

K. Interactive Voice Response (IVR) Integrations

The City currently provides multiple payment channels for residents and customers, including online, in-person, and automated phone-based payment services. The City may utilize an existing Interactive Voice Response (IVR) system, Lumen or Twilio, or may consider IVR capabilities offered by the Offeror as part of the proposed cashiering solution. The proposed Solution must support secure and reliable integration with IVR platforms to allow customers to make payments or retrieve payment-related information via automated telephone services.

The proposed Solution shall support integration with IVR systems to enable automated payment processing while maintaining compliance with applicable security and regulatory requirements, including PCI DSS.

1. IVR Payment Capabilities

The proposed solution must support IVR-based payment processing for applicable City services.

2. Integration with Existing IVR Platforms

If the City elects to retain its existing IVR system, the proposed Solution must support integration through secure interfaces. The proposed Solution should support reliable and efficient communication between the IVR system and the cashiering platform.

3. PCI Compliance for IVR Payments

Because IVR systems may process cardholder data, the proposed solution must support PCI DSS–compliant payment processing.

4. Monitoring and Reporting

The proposed Solution shall support monitoring and reporting for IVR transactions.

5. Future IVR Capabilities

The City may expand automated phone services during the life of the system. The proposed Solution should support future enhancements, including:

a. Expansion of IVR payment services to additional City departments.

b. Integration with customer account systems or service portals.

c. Support for new payment channels or authentication methods.

L. Implementation and Project Management

The City is seeking a structured, transparent, and well-governed implementation approach that ensures successful deployment of the proposed Solution. The implementation approach must account for a multi-department environment and support the transition of both direct payment processing and transactions originating from external systems.

M. Data Migration and Legal System Integration

The City anticipates that minimal data migration will be needed from the existing cashiering system. The proposed Solution must support the migration of relevant data from the City’s existing legacy systems that may be subsumed during implementation.

N. Testing, Training, and Go-Live Support

1. The awarded Offeror shall provide a plan for system testing, user training, and go-live support.

2. The awarded Offeror shall provide the following unit testing: Integration testing, security testing, performance testing, and User Acceptance Testing (UAT).

3. The awarded Offeror shall provide training resources for City staff, including:

a. System administrators

b. Finance and accounting personnel

c. Cashiering staff

d. IT support personnel

4. The awarded Offeror shall provide training materials including user guides, documentation, and instructor-led or online training sessions.

5. The awarded Offeror shall provide Go-Live support during system launch including rapid response for critical issues and the stabilization period following deployment.

O. Real Time System Synchronization

The proposed Solution shall support reliable synchronization of data between the cashiering system and other City systems, including Workday Financial Management and departmental applications.

P. Post-Implementation Support Guide and Documentation

Following Solution deployment, the awarded Offeror shall provide comprehensive documentation and operational guidance to support ongoing system maintenance and support. Documentation shall enable City IT staff to manage, maintain, and troubleshoot the Solution after implementation. The awarded Offeror shall provide documentation including:

1. Solution administration guides

2. Integration documentation

3. Configuration documentation

4. Troubleshooting procedures

5. Support escalation procedures

Q. Licensing, Support, and Maintenance

1. The City is seeking a Solution that provides predictable costs, reliable system availability, and long-term operational sustainability. The proposed Solution must support high-volume, multi-department operations and ensure consistent performance across all payment channels.

2. The awarded Offeror shall provide a comprehensive support services model to ensure reliable operation of the proposed Solution.

3. Upgrades and Enhancements:

The proposed Solution shall support regular system updates, enhancements, and improvements without significant disruption to City operations.