Attachment_A_Technical_Requirements_Response.xlsx
XLSX spreadsheet 42 KB Posted
- Attached to
- Mobile Parking Payment System State and local contract opportunity
- Solicitation number
- TR0-6482
- Issued by
- King County, Washington
About this file
The document is a Technical Requirements Specification from the City of Seattle for a Mobile Parking Payment System Request for Proposals (RFP). The City is seeking a mobile parking payment service vendor to enable customers to pay for on-street public parking and commercial loading zones via mobile devices and web-connected services. The RFP is scheduled for submission through the Procurement Portal by 2:00 pm on Tuesday, June 24, 2025, with the new mobile payment system required to be operational within 6 months of contract execution. The current mobile parking payment contract expires on July 9, 2025, and the new system must seamlessly replace the existing service, maintaining the current level of usage while providing opportunities for technological enhancements.
The technical requirements specify comprehensive specifications for the mobile parking payment system, including detailed requirements for public user interface, back-office management, transaction processing, enforcement integration, and future capabilities. Key technical requirements include supporting multiple payment methods (Visa, MasterCard, Discover, American Express, Apple Pay, Google Pay), accommodating complex parking regulations with variable rates and time limits, providing multi-language support, ensuring 99.5% transaction success rate, and maintaining robust data privacy and security protocols. The City expects the vendor to use existing location codes, support various payment platforms (iPhone and Android), offer customer support during primary parking hours, and provide detailed reporting and system monitoring capabilities. The City remains the Merchant of Record for transactions and is open to potential cost-saving arrangements for credit card processing.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| Mobile_Parking_Payment_System_(Addendum_#3_Revision).pdf | ||
| Attachment_F_V2_Requirements_for_Insurance.docx | DOCX document | |
| Attachment_C_Mobile_Parking_Payment_System_Management_Response.doc | DOC document | |
| Requirements_for_Insurance.docx | DOCX document | |
| Attachment_C_V2_Mobile_Parking_Payment_System_Management_Response.docx | DOCX document | |
| Attachment_B_City_Technology_Terms_and_Conditions.pdf | ||
| Attachment_G_Supplemental_Information.docx | DOCX document | |
| Attachment_E_Rate_Policy_List.xlsx | XLSX spreadsheet | |
| Attachment_D_System_Support_Agreement_-_Vendor_Management.docx | DOCX document | |
| IT_Pricing_Table_Template.xlsx | XLSX spreadsheet | |
| Terms-and-Conditions.docx | DOCX document | |
| fas-pc-purchasing-technology-contract-hardware-software.docx | DOCX document | |
| Rebate_Template.xlsx | XLSX spreadsheet |
Show all 13
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Tech Requirements
| Specification No. | Section Name | Requirement/Specification | Yes, Full Compliance | Partial Compliance | No, Does Not Comply | Describe full, partial compliance, or if not compliant, any Vendor plans for compliance | Vendor Publication & Page number that shows compliance (if applicable) |
| 5.3 | General System Requirements | GENERAL SYSTEM REQUIREMENTS |
This section lays out Seattle's expectations and specifications for the new mobile parking payment service to enable customers to pay for parking and commercial vehicle loading on Seattle streets using app and web-based payment systems that seamlessly connect with existing City parking data and enforcement systems
| 5.3.1 | General System Requirements | The Vendor-provided mobile payment provider solution will include, at a minimum, options for payment for parking and commercial loading via dedicated mobile application and mobile-friendly website. Such options should be easy for the public, and may include using a short unique text message code or URL for ease of payment by infrequent visitors who may not be willing to install a dedicated application. In Section 5.6.11, the Vendor shall describe how these features provide non-English language and general accessibility options for the parking public via their personal mobile device. |
| 5.3.2 | General System Requirements | The Vendor system shall accommodate (1) pay by plate system at the blockface level which is the majority of parking spaces, (2) pay by space systems in Ballard Locks, Westlake Ave N, and Lake Union Park lot, and (3) individual commercial vehicle load zones (CVLZ), which are pay by plate with their own unique code for each zone. Vendor's pay by space system will allow City to manage parking rules by space and only accept payment for valid space numbers. |
| 5.3.3 | General System Requirements | Vendor system shall accept payment 24/7 in a portion of the Westlake Ave N pay by space area and for select CVLZs, while only allowing payment between 4AM and end of paid parking hours in all other areas. These details are further described in items 5.4.4 and 5.4.7. |
| 5.3.4 | General System Requirements | The Vendor shall offer, at a minimum, mobile payment platforms compatible with iPhone and Android. |
| 5.3.5 | General System Requirements | The Vendor mobile payment system shall be provided under this contract to City agencies that may make use of the mobile payment system. Transaction data, transaction fee billing, and parking codes for this service used by agencies other than SDOT must be kept distinct from those used in regular paid parking and CVLZ spaces as described in Section 5.4.15. The City Parks Department currently utilizes the existing service to manage daily and annual permits at five boat ramp facilities. |
| 5.3.6 | General System Requirements | The Vendor service should allow for Visa, MasterCard, Discover, and American Express charges at a minimum, along with accommodation of Apple Pay and Google Pay. |
| 5.3.7 | General System Requirements | The Vendor shall have a customer toll-free number, staffed by call center representatives for at least for Seattle’s main paid parking hours, which are currently between 8 am and 10 pm PST/PDT, Monday through Saturday. Vendor’s toll-free number shall be prominently displayed at the top of the ‘About Us’ or similar webpage of the vendor’s website and similar location inside a mobile application. The option to speak to a live customer representative shall be in the top 3 choices of the phone tree options. The Vendor shall be willing to establish protocols for answering customer calls for parking enforcement, general parking questions, and other questions between the Vendor and various parts of City government. Once a contract is approved, SDOT will lead a discussion with City stakeholders, mobile payment vendor, and enforcement vendor to develop and agree on a roles and responsibilities document for customer support and outreach. |
| 5.3.8 | General System Requirements | SDOT is interested in the Vendor’s ability to provide a recurring summary, or dashboard, of customer support contact volume and associated topics that relate to using the system for street parking in Seattle. |
| 5.3.9 | General System Requirements | For the contract development, system design and installation phases, the Vendor shall provide an assigned project manager. Once the system has started, the Vendor shall provide an assigned project manager that can respond to SDOT staff by phone or email within 24 hours from the time the request is made. Emergency technical support staff shall respond via email within 60 minutes of the time SDOT sends a request for assistance during the regular paid parking operating hours described in 5.4.2. |
| 5.3.10 | General System Requirements | The Vendor shall provide all initial training for City staff, with the expectation that initial training is provided in-person. The Vendor shall cover all their staff travel and other costs associated with training. The following areas are necessary for training to cover deployment, operations, and enforcement: |
-SDOT staff for mobile payment back office system and operations -Seattle Municipal Court / Adjudication for basic system understanding and specifics for how mobile payment citation issues might arise and need to be addressed -Finance and contract administration for invoicing process -Seattle Police Department Parking Enforcement for enforcement process and basic customer service support -Seattle Parks Department for management of their facilities
| 5.3.11 | General System Requirements | SDOT expects that any Vendor selected from this procurement shall retain use of our existing mobile payment codes. The Vendor shall pay costs for all design and manufacture of any new signage necessary for system operation. The SDOT Sign Shop will produce all necessary signage based on design approved by the Vendor and SDOT, and SDOT crews will install all signs. SDOT will cover labor costs for sign installation and associated work in the ROW. The mobile parking payment system will typically be designated by one to five 12” x 18” signs along each block face where paid parking or CVLZs exist. As of October 2024, there are approximately 3,150 such mobile payment signs within the SDOT and Parks system. At a minimum, the signs must indicate the mobile payment vendor, the location code for that blockface, and the Vendor’s customer service number. Seattle has traditionally not utilized mobile payment stickers or decals on the pay stations. Signs shall be double-faced, reflective, and have anti-graffiti coating. SDOT must approval of final sign design. At an estimated $100 cost per sign, system-wide sign design and manufacture for an estimated 3,150 installations would cost approximately $315,000. In addition to signs, Vendor will need to fund updated pay station graphic labels. If these graphic labels are reprinted, materials are estimated at $12,000. |
| 5.3.12 | General System Requirements | As part of this response, the Vendor shall provide a brief summary of a system launch and transition plan. Following contract execution, the Vendor shall provide a detailed system launch and transition plan. The current mobile parking payment contract expires July 9, 2025. The new mobile payment system shall be operational as soon as feasible on or after that date. The system must be operational within 6 months of contract execution. |
| 5.3.13 | General System Requirements | The City of Seattle has critical privacy policies that relate to this project. In September 2015, the City of Seattle adopted Privacy Principles, which provide an ethical framework for developing policies, standards and practices regarding the public’s personal information. More information is here: http://www.seattle.gov/tech/initiatives/privacy. SDOT requires that the selected Vendor comply with the City’s Privacy Policy. |
| 5.3.14 | General System Requirements | The Vendor shall not sell or make available any City or user data to third parties without written approval by the City, nor shall they use City or user data for purposes outside the scope as defined in project Contract without written approval by the City. |
| 5.3.15 | General System Requirements | Vendor system provides the ability to issue digital plate-based permits for an annual basis or other specified time period. SDOT does not currently use the system for this purpose, but Parks may use this functionality for boat launch facilities and SDOT may explore in the future for vehicle permits that include, but are not limited to, residential parking permits (long-term resident and short-term guest) and/or for commercial vehicle loading zones. |
| 5.3.16 | General System Requirements | At a minimum, SDOT is looking to maintain current level of use of mobile parking payment while also looking for opportunities to increase usage and staying current with payment technology. To this end, Vendor shall hold a once per year enhancement meeting with City staff, where staff and vendor can sit down and discuss enhancements that could be implemented to improve the service. The agreed-upon enhancements will then be incorporated into the next year's service updates and provide the City staff with regular updates on progress as well as a timeline for implementation of the enhancements. |
| 5.4 | Parking Management Service Specifications | PARKING MANAGEMENT SERVICE SPECIFICATIONS |
The Vendor is required to maintain an accurate recording of SDOT’s complete paid parking regulations in terms of maximum time limits, parking rate by hour of day, and the paid hours and days of operation. This section lays out Seattle's parking regulations and expectations for a mobile parking payment system.
| 5.4.1 | Parking Management Service Specifications | The Vendor user interface and back office system must have the capability to manage blockface-specific parking regulations and single-space regulations for CVLZs, each with their own unique payment codes. There are currently over 170 separate paid parking rate structures (i.e., configurations) in Seattle’s system based on pay station model, parking rate, maximum permitted parking duration and hours of operation. A detail of rate and time limits in place as of January 2024 is provided as part of this procurement as Attachment E - Rate Policy List. |
| 5.4.2 | Parking Management Service Specifications | Vendor system must accommodate paid parking and loading operations effective generally between 8 AM – 10 PM PST/PDT, Monday-Saturday; no regular paid parking on Sundays or defined holidays, but events on these days may require payment and paid parking days/hours may be expanded in the future. |
| 5.4.3 | Parking Management Service Specifications | Vendor system must have ability to accommodate progressive event rates and event-specific time limits and rates. |
| 5.4.4 | Parking Management Service Specifications | Vendor system must have ability for the user to pay for parking for the paid hours that overlap any 72 hour period, which is currently in place in Westlake Ave N paid parking area. In other words, in Westlake Ave N, which is paid parking 9AM - 4PM Monday - Friday, a parker must be able to initiate payment at any time for up to 72 hours where only the paid parking hours within a 72 hour period are charged. |
| 5.4.5 | Parking Management Service Specifications | Vendor system must accommodate parking with rates that vary by time of day, maximum time limits, hours of operation, and effective days within sub areas within an area and along different blockfaces |
| 5.4.6 | Parking Management Service Specifications | Vendor system must allow different rates or time limits by time of day (i.e., different morning, afternoon, evening hourly rates) and correctly calculate payment based on duration. That is, if rates are $1.00/hour from 8 AM to 11 AM and $2.00/hour from 11 AM to 5 PM, and if a customer purchases two hours between 10 AM and 12 PM, they should be charged 1 hour at the $1.00/hour rate and 1 hour at the $2.00/hour rate, for a total $3.00 charge. |
| 5.4.7 | Parking Management Service Specifications | Vendor system must provide ability to pre-purchase parking, which is currently allowed in most paid areas beginning at 4AM local time (note Westlake Ave N requirement in 5.4.4 which requires payment initiation abilities 24/7). Such pre-purchase is only allowed on blockfaces without AM parking prohibitions. No pre-purchases shall be allowed on certain blockfaces with morning and/or evening peak hour restrictions on Monday-Friday during those restricted hours (i.e., no stops between 6 and 9 am or 3-7 pm, noting that these times vary). No extra fees or costs shall be incurred by the user or City for a pre-purchase. |
| 5.4.8 | Parking Management Service Specifications | Vendor system must accommodate no parking payment allowed on blockfaces during sign posted peak period and/or bus layover restrictions for certain days and times, ideally with messages provided to warn users of these restrictions. SDOT's system identifies these blockfaces. |
| 5.4.9 | Parking Management Service Specifications | Vendor system must accommodate both a “pay by plate” and a “pay by space” management system depending on location, and the ability to change management in these areas from one management system to another. |
| 5.4.10 | Parking Management Service Specifications | The vendor's system must support the implementation and management of minimum payment amounts that allows SDOT to set a minimum either by fee amount OR time purchased and apply across some or all paid parking areas. If Vendor system is time-based, such a system must automatically update following periodic rate changes and not require manual updates. |
| 5.4.11 | Parking Management Service Specifications | Vendor system must support existing City requirements that "pay by plate" parking purchases are made specific to one blockface, per City law. This is currently managed by a unique code for every blockface. Vendor system must support this system and any potential shift, for example allowing payment on either side of the street. |
| 5.4.12 | Parking Management Service Specifications | The Vendor system shall be consistent with how parking enforcement works today with GTechna-provided handheld enforcement technology and system, or in the future with other established vendors. Details of this requirement are included in Section 5.9. |
| 5.4.13 | Parking Management Service Specifications | Vendor system shall accommodate multiple different time limits, with time limit set at the rate policy level (representing a group of blockfaces with identical rates and regulations). SDOT currently operates with four “base” maximum time limits around the city: 30-minute, 2-hour, 4-hour and 10-hour (or all-day / no limit). Time limits on a blockface can change over the course of a paid parking day. For instance, many areas have 2-hour max time between 8 am and 5 pm and 3-hour max time from 5 pm to 8 pm. The Vendor shall have a system that can accommodate these parking regulations. |
| 5.4.14 | Parking Management Service Specifications | The Vendor shall operate a system that automatically does not charge for typical parking on designated City of Seattle paid parking holidays. The Vendor will be expected to program in advance for ten years for these free parking days, which are listed here: |
https://www.seattle.gov/transportation/projects-and-programs/programs/parking-program/paid-parking-information/free-parking-days Note that paid parking rates are in effect during event overlays and for certain CVLZ areas, even on these paid holidays.
| 5.4.15 | Parking Management Service Specifications | As noted in 5.3.11, the vendor shall use the City’s existing location codes (five digit, all numbers). Generally each paid blockface is assigned an 8xxxx code and each individual commercial vehicle load zone (which are often located on paid blocks) is assigned a 9xxxx code. Transactions for an individual blockface are linked together for enforcement and management purposes. Any new paid parking or CVLZs would require new location codes that start with an 8 or 9. The location code system must be accurately updated regularly as paid parking areas may come in or out of service. |
| 5.5 | Outage and Delay Requirements | OUTAGE AND DELAY REQUIREMENTS |
This section describes requirements related to system up-time and dealing with outages related to service or security issues. For the purposes of this RFP and the resulting contract, an outage or delay is defined as follows:
-Duration: Any service interruption lasting 10 minutes or longer is considered an outage -Types of Outages:
--Management System Outage: Any interruption or unavailability of the vendor's back-end management system.
--Customer-Facing System Outage: Any interruption or unavailability of any customer-facing mobile payment system including website, smart phone application, etc.
--Real Time Paid Transaction Data Transfer Outage: Any delay exceeding 10 minutes in the transfer of transaction data to integration points (e.g. Parking Enforcement and IPS). Measured from the time a transaction is completed to the time it has been accepted by Parking Enforcement integration vendor or the data warehouse vendor.
--Planned Maintenance: Scheduled system downtime for maintenance is not considered an unexpected outage but must be coordinated with city staff a minimum of two weeks in advance and conducted outside of normal parking hours.
| 5.5.1 | Outage and Delay Requirements | The Vendor system shall allow for 99.5% or greater of transactions to be successfully processed during regular paid parking hours. |
| 5.5.2 | Outage and Delay Requirements | When an outage occurs, Vendor or their system must inform designated SDOT and SPD employees via email or similar notification that the service is out within 15 minutes of discovering the failure. The notification must be offered in multiple notifcation channels, include clear information about the nature and scope of outage, current status and outage impacts, and estimated time to resolution. |
| 5.5.3 | Outage and Delay Requirements | During an outage, customers trying to purchase parking should receive a web notice, text or app message that the service is not available and that they must pay for parking through other means. |
| 5.5.4 | Outage and Delay Requirements | For any outage lasting longer than 30 minutes, the vendor shall provide status updates to designated City staff every 30 minutes or more frequently as needed. These updates must include information on actions being taken and updates to restoration time. Updates must also include any impact on parking operations or revenue collection |
| 5.5.5 | Outage and Delay Requirements | Resolution and Post-Outage Reporting: The vendor shall provide a detailed post-outage report within 24 hours of the resolution of any outage. This report must include: |
-Root cause analysis of the outage -Duration of the outage -Impact on system functionality and any affected transactions -Steps taken to resolve the issue -Measures being implemented to prevent similar outages in the future
5.5.6 Outage and Delay Requirements Outage Prevention and System Monitoring: The vendor shall implement proactive system monitoring and maintenance procedures to minimize the occurrence of outages. This includes:
-24/7 system monitoring -Regular system health checks -Capacity planning to ensure system can handle peak loads -Redundancy and failover systems to minimize service interruptions -Application/interface look and feel and customization
5.6 Public User Interface PUBLIC USER INTERFACE
This section describes requirements for the public-facing portion of the Vendor's mobile application and web interface.
| 5.6.1 | Public User Interface | Vendor system shall allow customer payment and transaction without creation of an account, and also allow customers to set up an optional account with the Vendor to store plates and payment methods. |
| 5.6.2 | Public User Interface | Customers shall have the option to create and view an account, and modify their account profile, license plate, credit card, or other payment details either through a desktop browser or via mobile device browser or application. Customers shall have an option to disable or cancel their account online without any reason or cost. Cancellation shall take the user no more than 5 minutes and be effective immediately. |
| 5.6.3 | Public User Interface | Within the vendor system, an optional customer account should store the license plate and state issued (i.e., WA 1234567) for easy repeat use. SDOT is also interested in ways to improve the accuracy of how people enter their license plate, particularly if they have special design plates (see here: http://www.dol.wa.gov/vehicleregistration/specialdesign.html). This might entail the use of a fuzzy logic system, either when the customer enters their information or as part of enforcement integration. SDOT is interested in the Vendor’s experience with technical and public education solutions to address incorrectly entered license plates into a customer account, both in advance to prevent mis-entry, and after transaction completion to mitigate mis-entry. |
| 5.6.4 | Public User Interface | Within the vendor system if a user establishes an account, a user can update their stored plate information during an active parking session that applies to future parking sessions only. User receives an alert or confirmation that this license plate change is only effective for future transactions. |
| 5.6.5 | Public User Interface | Customers shall receive confirmation upon successful payment via the same means through which they initiated transaction without any additional fees. Confirmation could be provided by SMS/text, email, in-app, or other means. |
| 5.6.6 | Public User Interface | Customers who fail to complete the payment process due to time out, system communications issue, or similar will receive a message indicating that payment was not received. Communication should be via the means through which they initiated the transaction. |
| 5.6.7 | Public User Interface | Customers shall have the option to receive a digital receipt for any completed parking payment. Such a receipt will indicate for each transaction the location used, duration of time paid for, and amount charged. Receipts shall not include third-party advertising without written permission by the City of Seattle, nor shall email or other user account lists be sold or made available to any third party. Within an optional customer-created account, customers must be able to review previous parking transactions, payments, and adjustments for at least the previous 12 months. |
| 5.6.8 | Public User Interface | Customers shall be able to extend their parking session up to the posted time limit for the individual blockface using vendor system. Customers shall have the option to receive a reminder via SMS or email before the parking session expires, and such reminder notification shall not incur additional fees to the City or user. |
| 5.6.9 | Public User Interface | The Service shall block customers from adding additional time once the maximum time limit for the same blockface or CVLZ has been reached. SDOT will set the time frame that a new parking session by the same vehicle account can be purchased. The current time frame is 30 minutes after initial parking or loading session has expired. |
| 5.6.10 | Public User Interface | The Vendor shall have a system that allows for customers who establish optional accounts to have multiple credit cards and multiple vehicles on one account. |
| 5.6.11 | Public User Interface | Vendor application and/or website needs to accommodate multiple languages that Seattle residents may use as their default language on their mobile device, or otherwise as provided by the Vendor. Primary languages include English, Spanish, Chinese (simplified and traditional), Vietnamese, Somali, Tagalog, and Korean. More information about the City's Launguage Access Program is here: https://www.seattle.gov/iandraffairs/LA |
| 5.6.12 | Public User Interface | The mobile payment service, at the minimum, shall be able to communicate to the customer any input errors including but not limited to inputting an invalid location number or invalid paid parking duration request. |
| 5.6.13 | Public User Interface | Any advertising or third party service or discount offerings done inside the smart phone application shall be done only after a transaction has been completed, is limited to 2 such offerings, and each can be easily dismissed. Ideally, any advertising or offers would require the user to opt in, with the user having ability to opt out at any time. Any advertising on a web-based payment platform shall not include full screen or splash ads that require a user to exit an advertisement window to use the service. |
| 5.6.14 | Public User Interface | SDOT is not providing standards for the look and feel of the Vendor user interface, other than meeting the parking management specifications laid out in this RFP. SDOT is interested in Vendor solutions that provide information to users via map and/or table showing area or block rates and time limits over the course of day, notify users when event rates are applicable, and provide other information beyond current applicable rate and time limit. Vendors will required to present their system as part of interview and demonstrations. |
| 5.6.15 | Public User Interface | All Vendor provided, managed, or operated websites, web pages, mobile applications, or other digital experiences must comply with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA Standard as published by the World Wide Web Consortium. |
| 5.7 | Back office Management System | BACK OFFICE MANAGEMENT SYSTEM |
This section describes requirements for the vendor back office system that will be available for City staff.
| 5.7.1 | Back office Management System | The Vendor provided back office will be web-based and hosted by the selected Vendor, using North American English language descriptions. |
| 5.7.2 | Back office Management System | Permissions of authorized City staff shall be established. The system will have an access management administration feature to grant and control access to data and operational management. |
| 5.7.3 | Back office Management System | All back-office upgrades will be provided to the City during the term of the contract at no cost. |
| 5.7.4 | Back office Management System | The back-office system should be able to output a “current state” of parking rate and other regulations to a user-friendly file that SDOT staff can routinely check the accuracy of parking regulations charged by the mobile parking payment system. SDOT is seeking a Vendor that provides a robust QA/QC system because of the complexity of our parking system. The Vendor should provide an ability to download (csv file or equivalent) various “rules” for locations, including: rate charged by hours, hours of operation, maximum hours of allowable parking. |
| 5.7.5 | Back office Management System | The back-office system will provide real-time transaction information available for lookup and reporting, with multiple querying and filtering capabilities including but not limited to: by location code, by paid area and sub areas, by blockface address, and by date/date range. |
| 5.7.6 | Back office Management System | Parking regulations (hourly rates, maximum time limits, hours of operations, restrictions and other regulations) will be managed solely through the back office system, which must have the capability to manage location and blockface specific parking regulations. As noted in 5.7.8, SDOT is moving to a system where rate and rate updates are communicated to the vendor via API and the back office system would reflect those rates and allow manual modifications. |
| 5.7.7 | Back office Management System | The system will have map display capabilities and graphic reporting features. The City can provide x-y coordinates and related data for parking regulations in an API that could be used for system updates. |
| 5.7.8 | Back office Management System | The City is currently developing a rate change API which will state the hourly parking rates for each Area – Subarea and specify the future date that these rates go into effect. The Vendor shall be able to retrieve or accept a data file containing future rate information that will be implemented on the Vendor’s system on the specified date included in the data file. If the Vendor is not able to do this currently, it shall be implemented within 9 months of the contract signing. |
The Vendor's Parking Rate API implementation shall leverage COSIP (City of Seattle Integration Platform utilizing Java and open-source technologies) to transfer information between the SDOT Paid Parking Rates Solution and the Vendor's Parking Rate Solution. Vendor should partner with Seattle IT to ensure Safety, Audit, Durable and Recoverable events/transactions.
1) Safety: all API communication transactions must be encrypted, and all web services endpoints must be OAuth2 authenticated (City of Seattle is using AWS IAM and API Gateway for this purpose)
2) Audit: all transactions can be audited
3) Durable/Recoverable: all transactions can be recovered
| 5.7.9 | Back office Management System | Vendor system should provide automated customizable reporting to City staff to note where any transactions that are received that do not meet the rate and rules |
| 5.7.10 | Back office Management System | Vendor back office shall provide ability to generate reports by various parameters, including location code, area/subarea, date range, and transaction type. The vendor should describe their back office system's reporting capabilities in detail, including any limitations and potential for customization to meet the City's evolving needs. |
| 5.7.11 | Back office Management System | Vendor back office shall provide customizable report templates to meet the City's specific needs |
| 5.7.12 | Back office Management System | Vendor back office shall provide exportable data in common formats (e.g., CSV, Excel) |
| 5.7.13 | Back office Management System | Vendor back office shall provide historical data retention and easy accessibility for a minimum of 3 years, including detailed transaction logs |
| 5.7.14 | Back office Management System | Vendor back office shall provide User-friendly interface for city staff to access and generate reports, and provide ability to schedule automated reports |
| 5.7.15 | Back office Management System | Vendor back office shall provide City staff the ability to issue refunds using Vendor system. |
| 5.7.16 | Back office Management System | The City of Seattle users will be able to authenticate into the back office system using Microsoft Azure SSO (single sign on). |
| 5.8 | Transaction Fees and Revenue | TRANSACTION FEES AND REVENUE |
This section describes requirements and work related to transaction fees and revenue. Vendors should provide specific transaction fee proposals using the Pricing Response Form (Attachment B) available in the project procurement portal.
| 5.8.1 | Transaction Fees and Revenue | Vendor system shall allow for City to remain Merchant of Record related to credit card fees. Note future enhancement item 5.10.14 |
| 5.8.2 | Transaction Fees and Revenue | Vendor shall route all payments to the City’s designated merchant account processor (unless, through further negotiations, the vendor takes on this role). The Vendor shall submit an invoice on a monthly basis to SDOT for the previous month activities, based on number of successfully completed revenue-generating transactions in the previous month multiplied by the amount of the Transaction Fee (or as determined in the RFP and Contracting process). |
| 5.8.3 | Transaction Fees and Revenue | The vendor shall not charge service fee or transaction fee for zero time transactions or zero dollar transactions. Only transactions that result in revenue generation shall incur service fees. The vendor's system must be capable of identifying and excluding these non-revenue generating transactions from fee calculations. |
| 5.8.4 | Transaction Fees and Revenue | The City does not currently charge fees for SMS notifications or communications, and does not support introducing mandatory or optional fees for any notification options. Vendor shall confirm that a purchase confirmation and expiration notification, typically provided by SMS, email, or app notification, will be provided to users without additional fee. |
| 5.9 | Integration and Enforcement | INTEGRATION AND ENFORCEMENT |
This section describes the required integration with existing enforcement and data systems.
| 5.9.1 | Integration and Enforcement | The mobile parking payment system must maintain a real-time data integration to Seattle Police Department Parking Enforcement equipment so that officers can efficiently conduct enforcement in all paid parking areas. All completed successful mobile parking sessions must be communicated to the SPD Enforcement solution simultaneously with the transaction confirmation received by the customer. SPD Enforcement currently searches for valid mobile parking payment by entering in the hundred-block address (900 Virginia St (NW Side)) and by vehicle license plate. Vendor system shall support this system to look up by blockface and by vehicle license plate. |
| 5.9.2 | Integration and Enforcement | The Vendor must be able to demonstrate that they have an integrated system already up and running with GTechna or can ensure successful integration with GTechna at no cost to the City or GTechna when mobile parking payment services commence. SDOT and SPD expect that a new mobile payment system will be able to start immediately with enforcement activity. In the event SPD Enforcement should change enforcement vendors to another established enforcement vendor during this contract, the mobile payment vendor shall integrate with the new enforcement vendor at no cost to the City. |
| 5.9.3 | Integration and Enforcement | The Vendor must maintain a separate mobile web interface that allows SPD to directly access their database and verify payment. This would allow enforcement to remain in place if there are updates from Android, GTechna or the mobile parking Vendor that inadvertently make systems no longer compatible temporarily. SDOT and SPD expects that software updates on either side maintain integration. |
| 5.9.4 | Integration and Enforcement | The Vendor shall assist SDOT and SPD with selection and testing of any new enforcement handheld devices to be purchased by the City or with different Vendors while under this contract. |
| 5.9.5 | Integration and Enforcement | The Vendor assumes all responsibility for integration costs, on-going service costs, and/or any new equipment or software required to enable maintain the Vendor’s payment and enforcement services. |
| 5.9.6 | Integration and Enforcement | The City shall be the exclusive owner of all City of Seattle transaction data, whether the data is direct or derived, calculated or modeled. The City’s paid parking Vendor IPS currently provides the system of payment status record. The Vendor is expected to be able to transmit in real-time all mobile payment transactions to IPS. In addition, the Vendor shall be able to transmit in real-time all mobile payment transactions directly to the City of Seattle, or another Vendor, if other arrangements are established. SDOT follows City of Seattle law to share parking transactions on the city’s open data site – data.seattle.gov – already and will continue to do so. |
| 5.10 | Future Capabilities and System Enhancements | FUTURE CAPABILITIES AND SYSTEM ENHANCEMENTS |
SDOT is interested in future capabilities and direction of mobile parking payment. SDOT is committed to mobile parking payment and can envision a future when almost all transactions are by mobile device or other method not involving payment collection hardware installed in the public right-of-way. SDOT expects to contract with a Vendor that supports these growth goals.
| 5.10.1 | Future Capabilities and System Enhancements | Describe if vendor system currently, or is planned, to support for pay in vehicle via integrated vehicle technology. |
| 5.10.2 | Future Capabilities and System Enhancements | Describe if vendor system currently, or is planned, to support opt-into notifications, validation or special messages from the Vendor, the City, or a City- approved 3rd party . |
| 5.10.3 | Future Capabilities and System Enhancements | Describe if vendor system currently, or is planned, integrate with other mobile payment platforms or a mobility as a service experience. |
| 5.10.4 | Future Capabilities and System Enhancements | Vendor system can accommodate incentives, coupons, or other validations whether from a 3rd party, the City, transit agency partners, local neighborhood Chambers of Commerce, and/or private businesses |
| 5.10.5 | Future Capabilities and System Enhancements | Vendor system can send parking transaction data to SDOT for data warehousing, have data available on open data programs, or to other Vendors of SDOT’s choice (transaction data is currently routed through our paystation provider, IPS). |
| 5.10.6 | Future Capabilities and System Enhancements | Vendor system has integration with electric vehicle charging and can direct payment for electric vehicle charging stations with electricity-related revenues directed separately to a public utility or other entity . |
| 5.10.7 | Future Capabilities and System Enhancements | Vendor system can provide notification of parking citations and/or ability to pay City parking citations via the mobile phone parking payment application or via partnership to another Vendor but through the customer’s account. |
| 5.10.8 | Future Capabilities and System Enhancements | Vendor system can apply differential payment rate and/or time limit or use allowance based on a plate-based digital permit for different registered user classes (e.g., commercial vehicles, motorcycles/scooters, etc.), if SDOT wishes to establish this system in the future. |
| 5.10.9 | Future Capabilities and System Enhancements | Vendor system uses integrated system checks that alert Vendor or City to unused or incorrect mobile payment codes or rates. |
| 5.10.10 | Future Capabilities and System Enhancements | Vendor system integrates with municipal temporary No Parking systems to automatically not allow payment during temporarily permitted parking restrictions. |
| 5.10.11 | Future Capabilities and System Enhancements | Vendor system provides payment services for existing parking operators in the Pacific Northwest region, or plans to provide this service. |
| 5.10.12 | Future Capabilities and System Enhancements | Vendor system integrates with pay station transaction data and systems to preclude payments for cumulative parking sessions that are in excess of posted time limit. |
| 5.10.13 | Future Capabilities and System Enhancements | SDOT is a partner with the Open Mobility Foundation and is working to update curb management and event data to be compliant with the emerging Curb Data Specification (CDS) standard. We are interested in working with a vendor who will be positioned to support transition to this standard. Further information is available at https://www.openmobilityfoundation.org/about-cds/. |
| 5.10.14 | Future Capabilities and System Enhancements | The City currently pays credit card fees associated with parking transactions and is the Merchant of Record. Our intent is to retain this existing arrangement. However, during contract negotiations, the City is open to reviewing this arrangement if a Vendor can provide credit card processing services at lower fees than currently paid directly by the City. Vendor to confirm their ability to support becoming Merchant of Record on behalf of the City. |
| 5.10.15 | Future Capabilities and System Enhancements | SDOT is interested in the cost savings of having transactions processed in batches for one vehicle/user combination to reduce the amount of credit card transactions fees. This could include, for example, that an initial parking transaction and all associated additions of time to one session (defined as parking at one location within the posted time limit), are consolidated into a single credit card processing transaction. Such a system could not add delay to relay of transaction information for data warehouse and enforcement purposes. |
File details come from the government source that posted it. Updated .