Purchasing Draft Exhibit A - Payment Platform Requirements Matrix.xlsx
XLSX spreadsheet 113 KB Posted
- Attached to
- RFP No. 223159 Enterprise Payment Platform
- Solicitation number
- S-KS0043-00006323
- Issued by
- Marion County, Oregon
About this file
This document is a Requirements Matrix for a state and local contract opportunity, specifically RFP No. 223159 for an Enterprise Payment Platform, involving Marion County and the City of Salem, Oregon.
The Requirements Matrix outlines the functional and technical requirements for the payment platform, including administrative portal features, API access, audit tracking, customer experience, payment method support, integrations, IVR capabilities, and reporting. The requirements are categorized as "must-have," "should-have," and "nice-to-have," with point values assigned. The document also includes a Requirements Dashboard that summarizes the overall solution requirements by category. The contract opportunity is seeking a payment platform that can provide a full range of payment processing capabilities to support the various jurisdictions involved.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 223159 Intent to Award.pdf | ||
| 223159 RFP v1.pdf | ||
| 223159 Supplemental Letter 1.pdf | ||
| 935030-20230413 Addendum 3.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
1. Introduction
| Requirements Gathering Documentation Tool |
| Use this tool to identify and track stakeholder involvement, elicitation techniques, and scheduling, as well as to track categorization and prioritization of requirements. Do not share this template with the stakeholders. Examples have been provided in dark grey font that should be deleted and replaced with your organization's information and situation. |
Identify stakeholders:
1. Identify the stakeholder's name and role.
2. Identify their influence and involvement.
3. Identify the elicitation techniques that you will be using.
4. Identify who will be conducting the elicitation sessions.
5. Identify if requirements were validated post elicitation session.
6. Identify when the elicitation will take place.
Categorize and prioritize requirements:
1. Identify the stakeholder.
2. Identify the core function.
3. Identify the business requirement.
4. Describe the requirement.
5. Identify the categorization of the requirement.
6. Identify the level of priority of the requirement.
For acceptable use of this tool, refer to Info-Tech's Terms of Use. These documents are intended to supply general information only, not specific professional or personal advice, and are not intended to be used as a substitute for any kind of professional advice. Use this document either in whole or in part as a basis and guide for document creation. To customize this document with corporate marks and titles, simply replace the Info-Tech information in the Header and Footer fields of this document.
2. Identify Stakeholders
| Project X – Requirements Gathering Elicitation Plan | |
| Project Sponsor | P = Planned |
| Project Sponsor | X = Completed |
| BA Team |
| Stakeholder Group | Stakeholder | Level of Influence | Level of Impact | Elicitation Technique | Requirements Validated | January | March | March | April | May | June | July | August | September | October | November | December | January | February | March |
| Project Sponsor | Alicia Blalock |
| User Groups | Margo Williams |
| Kelly Huber |
Architects Madan Mankala
| Specialty Stakeholder | Anja Hill |
| Josh Eggleston | |
| Scott Ruyle |
| Project Team | David Stoddard |
| Brad Briles | |
| Brian Foley | |
| Tom Scopacasa |
Exhibit A
| Exhibit A - Payment Platform Requirements Matrix |
| If Proposer is unable to fulfill a 'must-have' requirement, a comparable alternative must be described in notes. If no feasible alternative is provided, Proposer will be considered non-responsive and not be considered for award. |
| Points Possible | Core Function | Requirement | Description | Priority | Included? | Notes |
| 5 | Admin Portal | Customer Access Management | This must allow editing customer details, removing payment methods, removing scheduled payments, and researching payment or issues with payments (NSF, Declined, etc.) | Must Have | ||
| 5 | Admin Portal | Customer Login Access | Ability for administrators to view customer email and have the ability to update the email and reset the password. | Must Have | ||
| 5 | Admin Portal | Full-service admin portal | Ability to issue refunds. Robust search functions for locating individuals, accounts or payments. Access to historical interfaced files. Access to view customer records with audit history. | Must Have | ||
| 5 | Admin Portal | Issue Logging | Ability to submit tickets for tracking issues with a customer accessible self-service portal to view status of existing and past tickets. | Must Have | ||
| 3 | Admin Portal | Security Feature Control | Ability to enable/disable security features from within the Admin Portal. I.e. Zip Code requirement, Address Validation Service (AVS), etc. | Should Have | ||
| 3 | Admin Portal | Payment Minimums/maximums/frequency restrictions | Admin staff should have access to define minimum and maximum payment amounts as well as the maximum number of payments that would be accepted in a period of time. | Should Have | ||
| 5 | API | Customer Status Update | Ability to fully control and update customer status via API. (Active, Guaranteed Funds, Closed, Revoked, etc.). The customer status would need to impact recurring payments and ability to pay with various methods. | Must Have | ||
| 5 | API | Full Access to API Functionality | City staff must have access to leverage the API independent of the selected Payment Provider. | Must Have | ||
| 5 | API | Full feature API | Looking for a well developed API for extracting information from the payment processor for information such as customer details, payment schedules, sign up customers for recurring payments. | Must Have | ||
| 5 | API | Realtime Updates | Realtime confirmation of payments, balances updates, customer status updates, etc. | Must Have | ||
| 5 | API | Rest API or Web | Rest API or Web services based API (rather than only flat file). City prefers Rest API where possible. | Must Have | ||
| 5 | Audit Tracking | System notification on transmission failures, history of file transmissions, etc. | 24/7 access to systems. There should be a notification system in place for issues with interfaces, access to prior data transfers for a period of time, error tracking and reporting. Updates made in the system should generate an audit record on the individual accounts as well as any file loads. | Must Have | ||
| 5 | Audit Tracking | System tracking of changes made by customers on their accounts. | Viewable history of customer login dates, changes to payment schedules, updates on customer information. | Must Have | ||
| 3 | Customer Experience | Branding of Messaging | All messaging should have the capability to be branded as originating from the City. | Should Have | ||
| 5 | Customer Experience | Payment Confirmation Notice | Email/Text options for updates to customers as their payments progress through the process. (upcoming payments, scheduled payments, processed, confirmations, etc.) | Must Have | ||
| 3 | Customer Experience | Standalone Payment Portal | The solution must be capable of having a standalone payment portal allowing direct customer access to the system. | Should Have | ||
| 5 | Customer Experience | Clarity in IVR Audible Dialogue | IVR dialogue is to be clear and easy to understand | Must Have | ||
| 1 | Customer Experience | Migration: Payment History, Scheduled Payments, Etc. | The ability to migrate payment history, schedules, etc. would be nice to have and save our customers some work. | Nice to Have | ||
| 5 | Customer Experience | Reliability | Customers have 24/7 access to IVR and Web except when system maintenance or updates are necessary. | Must Have | ||
| 3 | Customer Experience | Time to process payments. | The IVR should allow citizens to process payments quickly and enable them to move forward to the next prompt without listening to the full dialogue. | Should Have | ||
| 3 | Customer Experience | Payment Plans | Scheduled one or more payments for a specific amount and specific payment date in advance. | Should Have | ||
| 5 | Customer Experience | Variable Recurring Payments | Customers must be able to schedule variable recurring payments so their full balance can be automatically processed. | Must Have | ||
| 5 | Digital Wallets | Manage Web Payment Methods | Customers must be able to add, edit, or delete funding sources in the web portal. | Must Have | ||
| 3 | Funds Availability | Next-day Availability | Funding should be available to the City the business day following customer payment | Should Have | ||
| 5 | Hardware | Compatibility | The solution must work with Ingenico payment devices which are currently used across the City. | Must Have | ||
| 5 | Infrastructure | 24/7 Monitoring and Network Operations | Proactive communication plan and support for when specific platforms are down, eta on resolution, and timing of next update. | Must Have | ||
| 3 | Infrastructure | Real-time System Performance and Analytics Dashboard | Realtime insight into the platform and system reporting. | Should Have | ||
| 5 | Infrastructure | Persistent Test Environment(s) | The proposer must have a persistent test environment. | Must Have | ||
| 5 | Infrastructure | Gateway and Real-Time Payment Processing | Centralizing the gateway and real-time payment processing reduces the number of entities involved in transactions and could reduce cost and simplify workflows. | Must Have | ||
| 5 | Integrations | Flat File Transfer | The proposer must be capable of developing integrations using Flat File transfers. | Must Have | ||
| 5 | Integrations | General Ledger Integration | System should have a robust process for General Ledger integration using Flat File or API. This includes daily summary files including a Remit File or End of Day Cleared Transaction Interface. These details must be added to the General Ledger (GL). | Must Have | ||
| 1 | Integrations | Granicus Government Solutions Integration | Existing full featured integration into Granicus Government solutions (which include Amanda, GovQA, CMS etc.,) | Nice to Have | ||
| 5 | Integrations | iFrame or Modal Window | Ability to integrate iFrame or Modal Window directly into connected systems for a streamlined user experience and collecting data in a PCI compliant manner. | Must Have | ||
| 3 | Integrations | Single Sign-On for Citizens | The user portal should be integrated with Single Sign-On (SSO) services for user access. The City is currently evaluating using Auth0 for our citizen facing SSO tool. | Should Have | ||
| 3 | Integrations | Single Sign-On for City Staff | Integration with Azure or ADFS. | Should Have | ||
| 1 | Integrations | SpryPoint Integration | Existing full featured integration into SpryPoint. | Nice to Have | ||
| 1 | Integrations | Tyler Technologies Solutions Integration | Existing full featured integration into Tyler Technologies Solutions. | Nice to Have | ||
| 3 | IVR (payments over the phone) | Live Transfer Calls for Payment Method Collection | Ability for CSR representatives to transfer callers into the IVR to have their payment details entered in compliance with PCI rules. Ideally be able to monitor the progress. | Should Have | ||
| 3 | IVR (payments over the phone) | Digital Wallet | Manage payment methods in the IVR, including saving, editing, or deleting payment sources. | Should Have | ||
| 5 | IVR (payments over the phone) | IVR | The proposer must include an IVR capable of handling Salem's payments. | Must Have | ||
| 5 | IVR (payments over the phone) | Multiple Languages | IVR must support English and Spanish at a minimum. | Must Have | ||
| 1 | IVR (payments over the phone) | Recurring Full Payments | Ability for customers to register in "Auto Pay" where the full balance of their utility account is paid automatically. | Nice to Have | ||
| 5 | IVR (payments over the phone) | Recurring Fixed Amount Payments | Customers will select an "Equal Pay" amount where they pay the same amount on a monthly basis regardless of their actual bill. Their account balance will then be trued up on a defined schedule and the Equal Pay amount will be adjusted as needed. | Must Have | ||
| 5 | IVR (payments over the phone) | Both the Web and IVR should be administered by the same entity. | The different platforms cannot be outsourced to 3rd party providers. | Must Have | ||
| 5 | Payment Methods | Fixed Recurring Payment | Customers will select an "Equal Pay" amount where they pay the same amount on a monthly basis regardless of their actual bill. Their account balance will then be trued up on a defined schedule and the Equal Pay amount will be adjusted as needed. | Must Have | ||
| 5 | Payment Methods | ACH | Proposer must accept ACH payments | Must Have | ||
| 1 | Payment Methods | Amazon Pay | Proposer should accept payments via Amazon Pay. | Nice to Have | ||
| 1 | Payment Methods | Apple Pay | Proposer should accept payments via Apple Pay. | Nice to Have | ||
| 5 | Payment Methods | Credit Card Processing | Proposer must be able to accept payment from various providers including all of the following at a minimum: Visa, MasterCard, Discover, American Express. | Must Have | ||
| 1 | Payment Methods | Digital Cash | Proposer should support payments using digital cash methods such as prepaid debit cards. | Nice to Have | ||
| 3 | Payment Methods | Digital Wallet | PCI compatible solution for entering and updating different payment sources. | Should Have | ||
| 5 | Payment Methods | E-Check | Proposer must accept e-checks. | Must Have | ||
| 1 | Payment Methods | Google Pay | Proposer should accept payments via Google Pay. | Nice to Have | ||
| 1 | Payment Methods | Government Assistance - Oregon Trail Card is Oregon's Electronic Benefits Transfer (EBT) card used for cash and food benefits. Works like a debit card from a bank. | Customers will often call in requesting to make payments with Government assistance cards. Would like to be able to accept payments from those. | Nice to Have | ||
| 5 | Payment Methods | Kiosks | Ability to support processing payments utilizing payment kiosks. | Must Have | ||
| 1 | Payment Methods | Mobile Payments | Ability for City staff to collect payments in the field. | Nice to Have | ||
| 5 | Payment Methods | Mobile Payments | Proposer must support mobile payments | Must Have | ||
| 3 | Payment Methods | Pay by Text | Proposer should support payment via text message. | Should Have | ||
| 3 | Payment Methods | Payment by Email | Proposer should support payment via email. | Should Have | ||
| 3 | Payment Methods | Payment in Apps | Proposer should support payment within Apps. | Should Have | ||
| 1 | Payment Methods | PayPal | Proposer should accept payments via PayPal. | Nice to Have | ||
| 5 | Payment Methods | Point of Sale | Ability to support over the counter payments handled by City staff using various cashiering modules. | Must Have | ||
| 1 | Payment Methods | Retail Store Partners | Ability to accept payments in person at various retail locations (Walmart, Fred Meyer, etc.) | Nice to Have | ||
| 1 | Payment Methods | Venmo | Proposer should accept payments via Venmo. | Nice to Have | ||
| 5 | Payment Methods | Web Payment Portal | Proposer must support web payments. | Must Have | ||
| 5 | Payment Methods | Quick Pay Option | Ability to pay without logging in, creating a profile, or providing an email. | Must Have | ||
| 5 | Payment Methods | Auto Pay (Variable Recurring Payment) | Ability for customers to register in "Auto Pay" where the full balance of their utility account is paid automatically. | Must Have | ||
| 5 | Payment Methods | Auto Pay (Variable Recurring Payment) without Online Profile | Ability to sign up for Auto Pay without creating a profile or requiring an email address (Web and IVR) | Must Have | ||
| 3 | Reports | Advanced Analytics - Vendor Provided Insights | Analytic feedback providing insights into the data from the vendor. Ability to ask questions of the data in plain language. | Should Have | ||
| 5 | Reports | Canned Reports | Existing system reports for tracking Cash Reports, General Ledger Summary Report, General Ledger Details reports, Customer Reports, Decline Payments, NSF Reports, etc. | Must Have | ||
| 5 | Reports | Ad-Hoc Reports | Ability to customize reports and export in flat file format (XLS/CSV) | Must Have | ||
| 5 | Reports | Dashboarding | Custom reporting and dashboarding for in depth analytics for viewing transactions with dynamic filtering based on source, custom fields sent with payments, payer, etc. | Must Have | ||
| 3 | Reports | Scheduled System Reports | Admin staff should be able to schedule automatic report run and delivery via email or other methods. | Should Have | ||
| 5 | User Interface (UI) | Create Account | Users must be able to create an account to manage web payment methods, view history, and make payments. | Must Have | ||
| 5 | User Interface (UI) | Mobile Accessibility | User Interface with a mobile app or responsive website that can be accessed on smart phone, tablet, or desktop computer. | Must Have | ||
| 1 | User Interface (UI) | Shopping Cart Concept | Ability for customers to process payments for multiple products in one payment. I.e. pay a parking permit fee and make a utility billing payment in a single transaction. | Nice to Have |
Sheet1
| Must Have | 5 | Yes |
| Should Have | 3 | No |
| Nice to Have | 1 |
4. Requirements Dashboard Project X – Requirements Dashboard
Requirements Categorization
Overall Solution Requirements Met yes Must Have Should Have Could Have Won't Have 0 0 0 0 no Must Have Should Have Could Have Won't Have 0 0 0 0 Must Have Should Have Could Have Won't Have
Performance Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Look & Feel Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Usability & Humanity
Usability & Humanity Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Legal Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Cultural & Political Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Security Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Maintainability & Support
Maintainability & Support Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
Operational & Environmental Yes No Yes No Yes No Yes No Must Have Should Have Could Have Won't Have 0 0 0 0 0 0 0 0
CALCs
| Must Have | Should Have | Could Have | Won't Have | |||||||||||
| Yes | No | Yes | No | Yes | No | Yes | No | |||||||
| Performance | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Look & Feel | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Usability & Humanity | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Operational & Environmental | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Maintainability & Support | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Security | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Cultural & Political | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Legal | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ERROR:#REF! | ||||||
| Total number of all answers | Must | Should | Could | Won't | ||||||||||
| 76 | 43 | 18 | ||||||||||||
| yes | no | |||||||||||||
| Must Have | ERROR:#REF! | ERROR:#REF! | ||||||||||||
| Should Have | ERROR:#REF! | ERROR:#REF! | ||||||||||||
| Could Have | ERROR:#REF! | ERROR:#REF! | ||||||||||||
| Won't Have | ERROR:#REF! | ERROR:#REF! |
yes Must Have Should Have Could Have Won't Have 0 0 0 0 no Must Have Should Have Could Have Won't Have 0 0 0 0 image1.jpeg
File details come from the government source that posted it. Updated .