Supplement 1 - Ohio



Supplement 1Enterprise ePayment Gateway Service Requirements and Statement of WorkTable of Contents TOC \o "1-3" \h \z \u Supplement 1 PAGEREF _Toc484524212 \h 1Enterprise ePayment Gateway Service Requirements and Statement of Work PAGEREF _Toc484524213 \h 11.0Service Overview and General Scope PAGEREF _Toc484524214 \h 31.1Initial Implementation and Future Project Opportunities PAGEREF _Toc484524215 \h 41.2Offeror Differentiators PAGEREF _Toc484524216 \h 61.3Offeror Proposed Team and State Relationship Management Requirements PAGEREF _Toc484524217 \h 61.4Contactor Best Practices and General Support Requirements PAGEREF _Toc484524218 \h 72.0ePayment Requirements PAGEREF _Toc484524219 \h 82.1Contractor Capability Requirements PAGEREF _Toc484524220 \h 82.2Requirements Matrix and Response Instructions PAGEREF _Toc484524221 \h 82.3Offeror Narrative and Response PAGEREF _Toc484524222 \h 92.4Technical and Business Requirements PAGEREF _Toc484524223 \h 93.0Support of Additional State Agency Adoption and Future Phases PAGEREF _Toc484524224 \h 213.1Future Phases Objectives PAGEREF _Toc484524225 \h 213.2Future Project Services Pricing Response and Rate Card PAGEREF _Toc484524226 \h 213.3Submission and Acceptance of Offer and Statement of Work associated with a Future Project PAGEREF _Toc484524227 \h 213.4Utilize DAS OIT’s Document Sharing/Collaboration Capability PAGEREF _Toc484524228 \h 224.0Service Level Requirements PAGEREF _Toc484524229 \h 234.1Service Level Specific Performance Credits PAGEREF _Toc484524230 \h 234.2Overall Contract Performance PAGEREF _Toc484524231 \h 254.3Monthly Service Level Report PAGEREF _Toc484524232 \h 264.4Failure to Report or Report Late after Mutually Agreed Dates PAGEREF _Toc484524233 \h 264.5ePayment Applications and Environments PAGEREF _Toc484524234 \h 264.6Temporary Escalation of an SLO to an SLA PAGEREF _Toc484524235 \h 264.7State Provided Service Support Infrastructure Elements PAGEREF _Toc484524236 \h 274.8Managed Service: Service Level Commitments PAGEREF _Toc484524237 \h 274.8.1Incident Resolution – Mean Time to Repair (Severity 1 Outages) PAGEREF _Toc484524238 \h 294.8.2Incident Resolution – Mean Time to Repair (Severity 2 Outages) PAGEREF _Toc484524239 \h 304.8.3Incident Resolution – Mean Time to Repair (Severity 3 Outages) PAGEREF _Toc484524240 \h 314.8.4Service Availability – Application Availability PAGEREF _Toc484524241 \h 324.8.5Application Performance and Responsiveness PAGEREF _Toc484524242 \h 324.8.6Incident Resolution - Issue Triage, Closure and Recidivist Rate PAGEREF _Toc484524243 \h 344.8.7Security – Monitoring & Auditing – Security Breach Detection PAGEREF _Toc484524244 \h 354.8.8Job Schedule and Scheduled Reporting Performance PAGEREF _Toc484524245 \h 364.8.9Operational Process Control & Repeatability – Changes to Production Environments PAGEREF _Toc484524246 \h 374.8.10Service Quality – System Changes PAGEREF _Toc484524247 \h 384.8.11Service Timeliness – System Changes PAGEREF _Toc484524248 \h 395.0Exhibit One: State Systems Inventory and ePayment Methods PAGEREF _Toc484524249 \h 40Service Overview and General ScopeThe State of Ohio, through the Department of Administrative Services (DAS), Office of Information Technology (OIT), is requesting proposals for a vendor hosted, operated and maintained electronic payment processing gateway service (ePayment) that can process Automated Clearing House (ACH), Credit Card and other payment transactions and support on-line bill presentment in support of State Agency systems and processes. The ePayment service must process payments on various platforms (web, mobile devices, IVR (interactive voice response) etc.). The ePayment Service will be a State-wide enterprise service that will provide each agency with the technology to facilitate and process payment for services by State customers. The goal of the State is to consolidate all ACH, Credit Card and other payment transactions to a single supplier for all State systems that require such functionality.This enterprise service will be part of the current State of Ohio (State) ePayment program and shall be provided in accordance with all applicable Credit Card/ACH transaction security rules and regulations including payment card industry and data security standards (“PCI DSS”) compliance, all laws, and any other governing authority requirements as may apply. The following diagram depicts the State's current ePayment architecture. The State, via more than 120 agencies, boards and commissions (agencies) currently uses over 10 ePayment gateway processors. The current largest ePayment program consists of seventeen customer agencies with a total of 159 applications. During the last fiscal year, the ePayment program processed over 4 million credit card and ACH transactions. These applications have been developed over time with a variety of development and integration approaches, many of which are tightly coupled to the payment engine making migration a non-trivial endeavor should a change of payment engine be necessary. Therefore, as part of this project, the State seeks to migrate to a “transaction/integration” agnostic set of methods to allow a phased migration to new technologies, establish modern (e.g., web-based or enterprise service-based) methods and develop an architecture that supports the inclusion of additional payment gateway services that allows the State vendor-diversity, processing fee cost competitiveness and minimize the impact to existing Agency applications that utilize such payment functions. The State has a variety of requirements that need to be fulfilled by an ePayment service that are specific to the business needs of the State and aligned with the missions of each agency, board and commission. The State of Ohio needs to identify, select and implement an extensible platform that is suited to the requirements of the enterprise. The State seeks to identify a service via this Request for Proposal (RFP) to:Address the State’s current and foreseen ePayment needs and requirements contained in this RFP;Serve as a basis for ongoing standardization for other ePayment needs as an extensible enterprise standard for future systems development and enhancement initiatives;Lower payment processing costs by aggregating statewide transaction and dollar volumes;Provide efficient migration of existing ePayment applications, including development of an ePayment “adapter” that is technology and integration methods agnostic (i.e., web standards based) to support easier migrations and adoptions of ePayment Gateway services in the future;Enhance operational efficiencies with standard reporting facilities such as on-line reporting, error detection and recovery;Allow State agencies to implement a variety of payment processing options for bill presentment, payment methods, channels, convenience fees, recurring and one time payments, etc.;Offer the ability to host State payment applications including presenting customer billing statements, billing history, payment history, and account information;Provide a reliable, cost effective, extensible enterprise payment service for the State;Allow State agencies to offer a mobile device payment option;Provide significant experience implementing and supporting electronic payment applications for a variety of governmental and non-governmental organizations across the State inclusive of State, Local and Municipal user-groups;Provide the experience and ability to provide the State with direction, advice, analysis, workflow/business process recommendations, and technical implementation support;Meet all PCI compliance standards as required by Federal, State and Banking law, rules and conventions;Provide the ability and resources to provide electronic payment (credit card and ACH) processing technology and services. This technology and services will be integrated with State systems that provide customers with the ability to pay for services and/or goods. The technology must also provide settlement processing with the State’s banks; and Provide the ability to migrate existing payment applications to the new payment platform with minimal disruption to State applications and operations.Initial Implementation and Future Project OpportunitiesThis RFP will be evaluated upon criteria contained in the base RFP and requirements in this Supplement (Supplement 1) and Supplement 2. At a high-level, the State will evaluate using the following considerations:Validation that the ePayment service meets the State’s requirements and is a viable and sustainable platform for ePayment needs for all State agencies; Confirmation that the proposed ePayment service is cost effective for the State and scalable to meet the State’s immediate and future needs; andStandardization of the State’s enterprise approach to ePayment based on a configurable integration services platform.The State requires an Enterprise ePayment Gateway Service and implementation services to provide execution leadership to State Agencies to migrate existing applications to the new ePayment Service inclusive of Agency Engagement (e.g., Project definition, requirements gathering/confirmation), Design/Build Services (e.g., solution and integration development, testing/validation and migration to production use) and ongoing Operations and Maintenance of the solution (e.g., upgrades, enhancements/extensions, reporting and system administration and support functions). In summary, the services and system functions required by this RFP fall into the following broad categories:ePayment Service - Implementation of the Contractor’s ePayment Gateway service to support all State agencies and the general public in a variety of routine and private/personal transactions. Credit Card Transaction Processing - Contractor must implement the State’s bank settlement file and response file processes as part of the ePayment service. The settlement file is generated by the Contractor listing all daily credit card transactions. The file allows for a unique transaction identifier to be generated by the payment engine and sent to the bank. The unique ID is then accessible within the bank for customer reconciliation. The response file is sent from the bank back to Contractor listing settled transactions as well as failed transactions and reason for failure. The Contractor must also have the capability to implement any proprietary settlement and response file should the State of Ohio use a different bank for credit card processing. The ePayment service must also be able to work with any third party payment processor the State may use for payment authorization and settlement. Currently the payment processor is Vantiv.ACH Transaction Processing - The State Municipal Tax Initiative works with many banks. The State requires the ability to configure ACH limits at the account level. In the case of a banking partner change, all outstanding deferred payments to the old banking partner must be transferred to the new banking partner. The Contractor will be required to set up and maintain the processes and relationships with the banks. Please refer to Figure 1: Current ePayment Architecture diagram above. Implementation, Migration and Training Services – For these services, the intent of this RFP is to establish a contracting mechanism only. Once the contract is established, each agency will be responsible for creating work orders with the Contractor to migrate existing State Agency applications to the new platform or implement new lines of business. As identified above, the State has 159 applications that use the largest current ePayment Gateway service, and additional applications using other ePayment Gateway providers. The State may request work orders in the form of Statements of Work from the Contractor to the State under the contract arising from this RFP for the modification, integration, testing and deployment of agency applications that use existing ePayment gateways, to the Contractors statewide ePayment Gateway service. Such Statements of Work will be incorporated into the contract through an Interval Deliverable Agreement (IDA). Upon completion of a project services implementation, the completed work, once meeting the State’s acceptance criteria, will, in most cases, be managed by the State on an ongoing basis. Kick Off Meeting. The Contractor, in conjunction with State staff, must plan and conduct a Project kickoff meeting. The Contractor in collaboration with the State will initiate the project with a mobilization effort for the first 15 days of the project, followed by the project kick-off event. This effort will focus on planning, processes, and project methodology. The goal will be to discuss and evaluate the Contractor’s proposed practices, methodologies and recommendations and ensure Contractor’s understanding of their commitment to deliver the proposed solution to the State. The Contractor in conjunction with the State must develop and deliver a presentation to the sponsors, key stakeholders and core project team after the mobilization effort. At a minimum, the presentation must include a high level overview of the following:?Project scope and schedule;?Goals of the Project; ?Methodology, approach, and tools to achieve the goals;?Roles, responsibilities, and team expectations;?Tasks, Deliverables, Milestones and significant work products; and?Contract content review. Not withstanding the Contractor proposed service under the aforementioned classification, the proposed service must:Demonstrate adherence to all requirements in this RFP and its Supplements;Demonstrate, via their response narrative to this Supplement, the interoperable features, capabilities, architecture elements and known limitations of deploying such a model for the State; Include all costs required to implement, operate and maintain the service based on the requirements herein and provisions of this RFP; andInclude a detailed bill of materials in the Cost Workbook, listing all elements that the State must acquire by way of hardware, storage, networking and other infrastructure to utilize the service as proposed, including any third party licenses required to support integration with State solutions (both custom developed or third party solutions). Offeror DifferentiatorsThe State requires Offerors to provide brief overviews of their company, capabilities, core competencies, and market differentiators in the following areas:Offerors will provide a brief overview of their organization, including their organization’s corporate structure, holding companies, parents, corporate affiliates and significant correspondent banks. Offerors will identify their headquarters location, and what year they began offering ePayment Gateway services. Offerors will provide approximate percentage of their volume, by number of transactions and dollar amount of transactions contributed by each of their five (5) largest customers, as well as an indication how many clients they have in total. Offerors will provide a statement regarding the number and nature of any clients that account for more than 10% of their business including length of relationship. Offerors will provide a statement on the number, volume and nature of any clients that are similar in size to the State of Ohio (using Exhibit One statistical and volumetric information as an indicator of the potential size of a relationship with the State of Ohio).Offerors must disclose any other companies or subsidiaries under the same ownership, and their products and services that utilize, are dependent upon, or in the absence of which would undermine or render unavailable or not viable, those services provided by the Offeror to the State. As part of this response the Offeror will identify any of these companies that provide services directly to the organization which are critical or essential to the delivery of the services referenced in this RFP to the State.Offerors will provide the number of full-time employees (locally, nationally, and internationally) dedicated to supporting the services described herein to all customers and the locations from which these employees will be assigned (should the offeror’s proposal be awarded) to provide services to the State.The Offeror must provide significant customer testimonials that highlight the strength of relationship and partnership between the Offeror and their customers that have resulted in achieving the strategic goals of customers of the Offeror, specifically with respect to each of their five (5) largest customers.The offeror will provide a Change of Control Statement to the effect of: Should the Contractor merge with, or is acquired by another financial institution, or acquires a financial institution, does the Contractor agree that all of its responses to this RFP, and all of the provisions of a Services Agreement, if awarded, will be incorporated into any subsequent merger, assignment, acquisition agreement(s), and/or any other governing document(s) executed to facilitate the completion of the merger, acquisition, or assignment of the terms of the Services Agreement to another entity as to not adversely impact the scope, quality or cost of the Service to the State.Offeror Proposed Team and State Relationship Management RequirementsThe Offeror must propose and as Contractor assign a Relationship Manager (RM) dedicated to the gateway services account after selection, implementation, and each application “go-live” has occurred. This RM shall remain assigned to the State during the contract period as set out in the Gateway Services Agreement or the contractual relationship has ended; or if the State requests another Relationship Manager.The Offeror must propose, and as Contractor provide an implementation team that maintain the knowledge, skills and experience required to successfully implement State payment integration projects inclusive of requirements confirmation, design/build services and production deployment until such time as the State accepts each integration project inclusive of meeting business, integration and technical requirements as mutually agreed under a Statement of Work as approved by the State in conjunction with each Agency implementation project.For all of the aforementioned roles, the Offeror must provide a brief description, including years of experience, and brief (2-3 page) biographical resumes for each of the key staff and Contractor role responsible for the performance of any service described in this RFP. Further, the Offeror will identify all key support staff that the Relationship Manager will rely on for day-to-day operations, including where those key support members provide services to the State whether they be project/implementation related or ongoing operations and maintenance functions. The offeror, as part of their response, must disclose all proposed subcontracted functions and identify the firm(s) that will deliver each service, such as settlement banks or front-end authorization and capture process.Contactor Best Practices and General Support RequirementsThe offeror must describe, and as Contractor performing the work deliver, access to best practices that the Offeror has developed with customers that result in rapid, high quality and low cost operational usage of the service while mitigating needs to customize the system.The offeror must describe, and as Contractor performing the work deliver, Offeror’s support capabilities that will be implemented or utilized to drive the highest levels of support and service that ensure maximal usage and availability of the system – particularly during critical financial periods, but also during routine or planned maintenance and enhancement periods that minimize disruption to business and user communities.The offeror must describe, and as Contractor performing the work deliver, its commitment to scalable, upgradeable services to ensure the State has access to current features/functionality and can pursue migrations and new service implementation in a timely and cost effective manner.The offeror must describe, and as Contractor performing the work deliver, innovative practices and methodologies provided and followed by the Offeror that are market proven and help drive successful migrations, implementations and enhancements while mitigating project risk wherever possible.The offeror must include, and as Contractor performing the work follow, a full description of the Offeror’s rapid implementation and quality methodologies designed to help ensure that migrations and implementations go as quickly as possible, are reviewed at each major step against quality requirements, and result in minimal business interruptions, auditable performance, and a lasting operational capability that the State can build on.ePayment RequirementsContractor Capability RequirementsOfferors are to provide the State, and as Contractor performing the work must deliver, as part of the response to this RFP a complete description of the Offerors capabilities and experiences that are available to all customers of the offeror, as well as those specific capabilities that directly align with the requirements of the State as contained in this Supplement that will be provided as part of the Service to the State.Experience with large volume electronic:Credit Card Payment Processing;ACH Payment Processing; andHosted Electronic Payment Services.Inclusive of:All electronic (i.e., internet, telephone, E-check, third party integrations) payment gateway services and merchant services you offer including the list of merchant processors you settle with and their respective settlement times.New technologies you currently offer. Provide examples of any product launches or enhancements you have had in the past five (5) years.Strategic plans, product roadmaps or product initiatives that the Offeror has planned over the next two (2) years including any unique processing products or services Offeror currently offers to other government entities that differentiate the Offeror from other vendors providing similar services.Research and development efforts as to keep pace (or establish leadership) with new payment technology, security, and industry trends in order to advance your product suite.Frequency of independent PCI compliance audits with a copy of your most recent assessment. The Offeror must provide summaries of all agreement(s), approval(s), and any permit(s) necessary for all major credit card institutions (such as Visa, MasterCard, American Express and etc.) Similar to the Payment Card Industry Data Security Standard (PCI DSS) developed for the credit card industry, the ACH world is headed in the same direction. Offeror must provide information on where it is at in regards to this issue. Specifically state what is currently being done in the area to prepare for current and future security/encryption requirements set by NACHA.Archival component of your solution for moving the data from the production database to near and offline data stores as well as data deletion, including thresholds for relocating the data, database storage, retrieval process, automatic or manual, etc.Describe how your payment gateway service supports 24 x 7 x 365 operations.Requirements Matrix and Response InstructionsThe State has developed a set of functional requirements contained in this supplement pertaining to ePayment service needs. The State requires Offerors to provide a complete service that will be used in production by the State, inclusive of all identified requirements. In order for the State to evaluate Offeror proposals, the State requires Offerors to complete the Requirements Matrix below in its entirety. Offerors will indicate (using the requirements matrix) an “X” in the column that is most reflective of the method to deliver the State’s required functionality:Functionality DeliveredBaseThose items that can be delivered as part of a base installation without any configuration or customization. Config(uration) Those items that can be delivered as part of the base installation through configuration or administrator level graphical user interface driven configuration items, scripts or methods or otherwise do not require custom programming and development effort. Custom Those items that can be delivered as part of the configuration of a base installation through structured development methods or otherwise require custom programming or development effort. Formal system and acceptance testing would be considered mandatory. Not Supported or Recommended Those items that are not supported as part of a base installation, or in the opinion of the Offeror cannot be reasonably achieved in a commercially reasonable or recommended manner (e.g., cost, time, platform, architecture, maintenance and other factors).Offerors will indicate (using the requirements matrix) an “X” in the column that is most reflective of the effort required to deliver the State’s required functionality (when the functionality is not offered as part of base installation as described above):Effort ComplexityLow Minimal or trivial effort (i.e., less than 10 hours) of total effort to implement, verify and be ready for live production use. Medium Minimal to moderate effort (i.e., less than 40 hours) of total effort to implement, verify, test or validate and be ready for live production use. High Those items that require structured development methods or otherwise require custom programming and development effort with moderate to extensive effort (i.e., more than 40 hours) of total effort to implement, test and be ready for live production use. Offeror Narrative and ResponseIn addition, the State has provided as part of the Requirements Matrix, a free form field labeled ‘Offeror Narrative’. Offerors must use this field to explain how their service meets the requirement for every requirement in the requirement matrix.Offerors may also use the free form field to convey any additional considerations, showcase Offeror capability to deliver or identify any Offeror requirements for the State.The State suggests that Offerors should not assume a uniform level of expertise in all facets of their proposal and are encouraged to illustrate the rationale, merits, completeness, capabilities and limitations of all service components including: technical, software elements, process elements, services, integrations and other operating considerations as part of their responses to this RFP.The State further suggests that Offerors provide screen captures, diagrams, graphics or other information of relevant elements of their service to illustrate to the State the degree of compliance with the State’s requirements wherever possible. Brief statements to the effect of “Offeror understands and complies” are strongly discouraged unless for those requirements that are of a trivial or affirmative representation in nature.Technical and Business RequirementsThe State’s requirements are defined in the following pages. Offerors may not alter or renumber any requirements.Functionality Delivered Through:(indicate with 'X')Effort Complexity (indicate with 'X')Reqmnt. NumberRequirement DescriptionCategoryBaseConfigCustomNot SupportedHighMediumLowOfferor Narrative and Response(This column MUST be completed for every requirement. Refer to section REF _Ref481646755 \r \h 2.3 for instructions.)Technical Requirements T.1The payment gateway service must provide a minimum of 99.982% uptime for 24 x 7 x 365 operations.TechnicalT.2The complete payment architecture must provide an overall average response time of two (2) seconds or less from the point at which the inquiry hits the server complex until the time when a response is returned.TechnicalT.3The payment gateway service must be able to process 40,000 ACH and 40,000 credit/debit card transactions simultaneously per hour during peak periods.TechnicalT.4The payment gateway service must be able to process a minimum of 5,000,000 transactions per year. Further, the service must have the scalability to accommodate significant growth in number of transactions in the coming years.TechnicalT.5The payment gateway service must support a peak load of twice (2x) the expected maximum concurrency to ensure adequate spare capacity for growth and expansion without any degradation of performance.TechnicalT.6The payment gateway service must provide a web service/API for processing payments from web applications and mobile devices. The web service/API must support several methods to provide flexibility in developing the payment applications.TechnicalT.7The payment gateway service must include hosted payment forms (tokenized URL pages) functionality so that the State can quickly implement an application without having to integrate the software components using web service/API.TechnicalT.8The payment gateway service must provide an integration interface that allows the State to adopt future Contractor solutions without impact to existing State Applications integrated with this interface (i.e., only modification required is to the integration interface without application integration change.)TechnicalT.9The payment gateway service must allow the State’s applications to collect customer information (not including credit/debit card, bank account) and pass control to the payment gateway for payment processing. This processing includes two way communication between the application and the Contractor’s payment gateway.TechnicalT.10The payment gateway service must integrate with Telecheck.TechnicalT.11The data center where the payment gateway service is hosted must be an Uptime Institute or TIA-942 Tier 3/Rated 3 (e.g., “concurrently maintainable”) or above. TechnicalT.12The payment gateway service must include a separate fully functional test environment that mirrors the production environment for application development and testing. Further, the test environment should have the same 24 x 7 x 365 availability as production environment.TechnicalT.13The Contractor hosted disaster recovery sites must be located as to be technically diverse from the primary production site. Technical diversity factors include at a minimum: alternative and redundant power providers or grids, as well as different telecommunications network providers that service the primary and disaster recovery sites respectively.TechnicalT.14The payment gateway service must support and be implemented with a failover configuration to ensure high availability. The payment gateway service must not have a single point of failure.TechnicalT.15The payment gateway service must support full backup and restore capabilities so that the payment gateway service (inclusive of software elements, data, configuration value and other elements as required to operate the service) can be restored from the media with minimal additional intervention.TechnicalT.16The batch and backup operations must not degrade the response times of the system in off hours, assuming a lower request load to be estimated and justified by the service provider.TechnicalT.17The Contractor must execute annual disaster recovery testing and provide the State with documented results and a remediation plan with committed resolution dates for any item identified as a weakness, material or otherwise from a technical, process, procedural or organizational perspective as provided to the State by the Contractor under this RFP.TechnicalT.18The payment gateway service must provide a unique transaction ID as well as a unique application ID to identify and track each transaction from beginning to end.TechnicalT.19The payment gateway service must have the ability to provide extract files (excluding PCI data) back to the State’s application for auditing, reporting and reconciliation purposes.TechnicalT.20The payment gateway service must provide the State with read-only access to Contractor’s database and logs (excluding PCI data) for the purpose of obtaining basic transactional information to assist with production issues.TechnicalT.21The payment gateway service must support a multi-tenancy implementation to allow each agency in the State to have their own administrators and their own merchant IDs. TechnicalT.22The Contractor must state in detail the estimated timeframes for setting up a State agency profile, making changes to the profile etc. on the payment gateway service.TechnicalT.23The payment gateway service must implement automated audit trails to reconstruct systems events and user actions. At a minimum audit trail entries for each recorded event must include the following information:- User identification - Type of event - Date and time stamp - Success or failure indication - Origination of event - Identity or name of affected data, system component, or resourceTechnicalT.24The audit trail must be extensible by providing for user or application defined events.Access to all audit journals Invalid physical and logical access attemptsUse of identification and authentication mechanisms Initialization of the audit logs Deletion of objectsActions taken in response to the compromise of cryptographic keys Changes in the custody of keys and custody of devices or media holding keysAll encryption key management operationsSystem initializationKey generationKey useKey storage (back-up and archiving)Key destructionKey custodian actionsCertificate generationCertificate validationKey exchange (import and export)TechnicalRegulatory RequirementsR.1The payment gateway service must meet the standards for web accessibility as outlined in Ohio Administrative Policy IT-09 “Website Accessibility”. RegulatoryR.2The payment gateway service must align with the requirements outlined in Chapter 1306 of the Ohio Revised Code, the Uniform Electronic Transactions Act (UETA).RegulatoryR.3The payment gateway service must comply with the statewide requirements for advertisements, sponsorships or endorsements on State-controlled/Contractor-hosted websites as defined in Ohio Administrative Policy IT-10, “Moratorium on the Use of Advertisements, Endorsements, and Sponsorships on State-Controlled Web sites”.RegulatoryR.4The payment gateway service must align with the browser requirements outlined in Ohio Administrative Policy IT-08, “Executive Branch Cabinet Agency Web Site Standardization”. RegulatoryR.5The data center where the solution/data is hosted must allow for auditing by the State or State authorized third-parties.RegulatoryR.6All of the State’s data & documents must be hosted and processed within the United States. (See Executive Order 2011-12K Governing The Expenditure of Public Funds for Offshore Services.) RegulatoryReporting RequirementsRR.1The payment gateway service must provide a web-based reporting system for State personnel to perform ad hoc reporting (other than APIs) – this would enable State personnel to access both administrative information and transactional information (excluding PCI data) without having to write a Web Application. The reports should include transactional information such as credits, debits, chargebacks, voids, test transactions and location identifiers. This service must be able to handle any load submitted by the State and produce reports in a timely manner.ReportingRR.2The State requires the ability to generate the following reports:API based reporting so State can develop applications for reporting if desiredUnique Transactional Identifier Reports with the ability to send a list of transaction IDs to receive transaction detail in the report (excluding PCI data)Monthly Reports for OIT (No transactional data must be accessible by OIT)Ad Hoc ReportsReportingRR.3The payment gateway service must be able to produce the following monthly reports (excluding PCI data) in MS Excel or CSV file formats. Number of Credit Card transactions broken down by customerNumber of ACH transactions broken down by customerNumber of total transactions broken down by customerNumber of total transactions for the programList of all costs broken down by customerTotal of all costs for the program (State must be able to define the scope of ‘Customer’ in the above reports).ReportingSecurity RequirementsS.1The entire payment gateway service must be compliant with the following standards and legislation:Payment Card Industry Data Security Standard (PCI DSS);Electronic Fund Transfer Act (EFTA);Sarbanes-Oxley Act (SOA). The Contractor must show how this is accomplished and provide proof of such certification with dates included. Furthermore, the Contractor must maintain compliance during the life of the contract and provide annual reports on status of compliance.SecurityS.2Payment data transmitted over the Internet must be encrypted using 128 bit Secure Socket Layer (SSL) encryption or better (preferably using TLS 1.2). Contractor must maintain compliance during the life of the contract and provide annual reports on status of compliance. Additionally, the Contractor must demonstrate the ability to keep up with payment industry security standards.SecurityS.3Minimum of field level encryption for database storage of any confidential information (e.g. credit/debit card numbers, account numbers, client personal information, etc.). Stand-alone storage of this encrypted information whenever possible is recommended.SecurityS.4The payment gateway service must not require that PCI data be stored on the State’s environment for any length of time. (If the Contractor cannot collect and hold PCI data in an outage situation then no payments should be accepted.)SecurityS.5The payment gateway service must allow for role based security and provide for defined profiles within those roles for application and administrative access. The Offeror must provide a description of the various roles and their associated functional abilities currently available. SecurityS.6The payment gateway service must be able to link all actions and processes to an active user or system. There should be no generic users or roles or root administrator access. Each user must have a unique user identification and password.SecurityS.7The payment gateway service must have the access controls to ensure that the State’s customers can view, edit, and void their own transactions only.SecurityS.8On-line and off-line report availability of the payment gateway service must be based on user’s access rights.SecurityS.9Restriction and close monitoring of outsider’s presence in areas where sensitive data is accessible is required.SecurityS.10Physical security of all paper and electronic payment gateway service components that contain sensitive data is required.SecurityS.11The Contractor must have the ability to perform automatic archival of sensitive data for storage on secure electronic file or database once a payment has been processed. SecurityS.12The Contractor must have the capability to encrypt the bank settlement file. SecurityBusiness RequirementsB.1The payment gateway service must be hosted and managed by the Contractor. BusinessB.2The payment gateway service must have the ability to support the following business model:No PCI data flows through the State but white labeled (custom branding) screens are presented to customer to appear as if it does. The customer is redirected outside of State’s web application to the Contractor’s payment gateway and after completed payment the customer is redirected back to State’s web application. BusinessB.3At a minimum, the payment gateway service must have the following functions available for processing credit/debit cards and ACH payments:- Payment Edit- Payment Void - Payment Refund- Payment Deferment- Payment Settlement Query- Payment Deferred Settlement Query - Payment Refund Query - Payment Chargeback Query - Payment Status QueryBusinessB.4The payment gateway service must support on-line bill presentment functionality where customers can view all of their outstanding bills and choose the bill(s) they wish to make payment(s) on.BusinessB.5The payment gateway service must provide an administrative interface for State agency use in tracking and reporting of payment transactions.BusinessB.6The Contractor must implement the State’s bank settlement file and response file process as part of the payment gateway service.BusinessB.7The Contractor must have the capability to implement any proprietary settlement and response file should the State of Ohio use a different bank or processor for credit card processing.BusinessB.8Should the State change their banking partner or processor, all outstanding deferred payments to the old banking partner or processor must be transferred to the new banking partner or processor.BusinessB.9The payment gateway service must be able to work with any third party payment processor the State may use for payment authorization and settlement etc. The payment processor currently in use by the State is Vantiv.BusinessB.10The payment gateway service must allow the payments to be made via web, interactive voice response(IVR), mobile devices, POS machines and by a customer service representative(CSR) processing an on-behalf-of (OBO) payment. Additionally, the CSR must not have access to card data. BusinessB.11The payment gateway service must accept payments with a credit card, debit card and checking account debit (via ACH).BusinessB.12The payment gateway service must verify the ABA routing and transit number (RTN) by matching name of bank to RTN, in addition to “bad check list” validation. (Please explain how this is accomplished in your service.)BusinessB.13The payment gateway service must allow the option to charge or not charge a convenience fee based on the business rules of each application. BusinessB.14The payment gateway service must support the following models The State agency pays the credit card convenience feeThe end user pays the credit card convenience feePayment gateway service provider collects and pays the convenience fee BusinessB.15The payment gateway service must accept debit cards (using PIN debit or signature debit) for payments. This would include Visa and Master Card branded debit cards.BusinessB.16The payment gateway service must accept credit cards for payments. This would include Visa, Master Card, American Express and Discover branded credit cards.BusinessB.17The payment gateway service must provide support for level 3 data for credit/debit card transactions. This would enable additional detail to be passed through the settlement process to the end customer.BusinessB.18The payment gateway service must have the ability to do CVV2, CVC and CID code verification for credit cards.(VISA refers to the code as CVV2, MasterCard calls it CVC2, and American Express calls it CID.)BusinessB.19The payment gateway service must support EMV chip card technology on POS machines.BusinessB.20The payment gateway service must provide the functionality for scheduling of recurring payments as needed by each application.BusinessB.21The payment gateway service must allow customers to specify payment methods/accounts for each transaction when making payments for multiple transactions.BusinessB.22The Contractor must agree that the State is the Merchant of Record and owns all Merchant IDs.BusinessB.23The payment gateway service must provide confirmation numbers, notifications and messages at the end of payments process.BusinessB.24The payment gateway service must provide ability to migrate existing web and IVR payment applications to the new payment platform with minimal impact to State applications. BusinessB.25The Contractor will be responsible for oversight and management of account on-boarding process. This process must be auditable.BusinessB.26The Contractor must allow for State controlled flexibility in batching transactions. The ability to group multiple batches together is required.BusinessB.27The payment gateway service must provide the ability for State agencies to configure limits on ACH, debit cards and credit cards at the account level based on their business needs.BusinessB.28The payment gateway service must provide support for all NACHA formats including CCD and WEB.BusinessB.29The payment gateway service must support balanced and unbalanced ACH files.BusinessB.30ACH transactions must not be delivered to the State on non-business days. A non-business day is defined as Saturday, Sunday or any other day observed as a State holiday. Any ACH transactions processed by the Contractor on a non-business day, is required to be included with the next State business day's file.BusinessB.31The Contractor must have the ability to regenerate ACH files upon request. This will include times when any operational additions or deletions are made.BusinessB.32The Contractor will be required to provide a method for the State to extract ACH data for balancing as well as provide a process to allow ACH files to be edited and, if needed, regenerated prior to delivery to the bank.BusinessB.33The State must have control over how long ACH files will be retained at the Contractor’s site.BusinessB.34The Contractor must be compliant with all current NACHA rules and remain compliant with any future changes to the NACHA rules.BusinessB.35The payment gateway service must have the ability to support the following ACH delivery models:ACH files are delivered directly to the bank by the ContractorACH files are delivered to OIT by the ContractorACH files are delivered by the Contractor to a pickup location provided by the ContractorBusinessB.36The Contractor must provide daily processing times so the State will know cutoff times for the addition and deletion of outstanding payments.BusinessB.37All NACHA files must be properly formatted and delivered to the State of Ohio consistent with the State’s business requirements. If the State chooses to have the files processed by the Contractor, the files must be processed and delivered at times consistent with the State’s business requirements. The State must have the ability to manage the distribution timing of these files.BusinessB.38The Contractor must publish a quarterly scheduled maintenance calendar no later than ten (10) State business days prior to the start of each quarter for all scheduled outages. Any changes to the calendar will require ten (10) State business days advance notice unless the change involves an extended outage. In this case a minimum of one (1) month advance notice is required.BusinessB.39The Contractor must provide a support center that must be available 24 hours a day, 7 days a week. The Contractor must define levels of support to include on site vs. mobile vs. pager response vs. answering service, number of support staff available by shift, etc. The support center must be able to answer questions and resolve issues from both the State and State’s customers.BusinessB.40The payment gateway service must provide robust monitoring and alert notification for hosted systems and processes.BusinessB.41The Contractor must provide user documentation and guides with code examples for each development technology supported by the payment gateway service as well as documentation on related policies and procedures for use by the State agencies.BusinessB.42The Contractor must provide a dedicated support team for problem resolution for system, communication, file transport, transactional, and reconciliation issues etc.BusinessB.43Credit/Debit card and ACH transactional data must be stored at the Contractor’s site and have a retention period of seven (7) years for audit and retrieval purposes.BusinessB.44In the event of a data breach as a result of a hacking incident or an insider act, the Contractor is responsible for notifying the customers, answering questions and providing credit monitoring services to the affected customers.BusinessB.45Contractor agrees to assign one Relationship Manager dedicated to the payment gateway services account after selection, implementation, and “go-live” has occurred. This Relationship Manager shall remain assigned to this account until the contract period as set out in the Gateway Services Agreement or the contractual relationship has ended; or if the State requests another Relationship Manager.BusinessDigital Wallet RequirementsDW.1The payment gateway service must offer customers the option to create a user profile so that the customers can store and reuse their payment information (name, address, bank account/routing data, credit/debit card numbers etc.) for future payments. This must be stored in the Contractor’s environment.Digital WalletDW.2The payment gateway service must have the ability to recall a previously entered account number, per session, for a user who may have multiple entries for the same account. All numbers in the account number except for the last 4 characters must be masked allowing the user the option of using the account again for the next entry. (The account numbers must be stored in the Contractor’s IT environment instead of the State’s IT infrastructure.)Digital WalletSupport of Additional State Agency Adoption and Future PhasesThe State may from time to time request proposals from the Contractor to the State in the form of Statements of Work (SOW) under the contract arising from this RFP for the modification, integration, testing and deployment of agency applications that use the current statewide ePayment gateway, to the Contractors statewide ePayment Gateway service. Such Statements of Work will be incorporated into the contract through an Interval Deliverable Agreement (IDA). Upon completion of a project services implementation, the completed work, once meeting the State’s acceptance criteria, will, in most cases, be managed by the State on an ongoing basis. Future Phases ObjectivesFuture project services are defined to achieve one or more of the following: Modification of existing agency applications to replace the existing statewide ePayment Gateway with the Contractors statewide ePayment Gateway service in agency applications.The addition of ePayment requirements designed to support agencies that have a more complex scope or additional functionality requirements.The addition of enterprise requirements that are designed to drive a higher degree of integration with State systems, data, standards, processes or business requirements. Future Project Services Pricing Response and Rate CardThe Offeror must provide a rate card, (included in the cost summary) by project personnel role and experience level as well as technical role and experience level that is binding over the contract term. The Offeror may not propose rates in any project SOW that differ from this rate card as allowed under any contract arising from this RFP. Submission and Acceptance of Offer and Statement of Work associated with a Future ProjectAt the State’s request, the Contractor must provide an offer that addresses the State’s SOW for future agency implementation projects. Contractors are advised that the State, at its sole discretion, may elect to competitively source these projects in part or in full and may not be required to continue utilizing the Contractor’s services for future work. If the State chooses to continue utilizing the Contractor’s services for future work, the State may issue change requests or amendments to any agreement arising from this RFP. The Contractor’s offer must be priced based on either the rate card (for time based projects) or fixed price deliverables/milestones included in the cost summary for the completion of the deliverables required by the State’s requirements and as contained in a mutually agreeable SOW. The State will review the Contractor’s offer and provide feedback as needed to the Contractor within thirty (30) days of receipt of the offer. Under no circumstances will work be started without State approval, and the State will have no financial obligation for services performed without State approval. Utilize DAS OIT’s Document Sharing/Collaboration CapabilityIn conjunction with the delivery of the project, coincident with the start of the project through its conclusion, the Contractor must use the State provided and hosted document management and team collaboration capability (Microsoft? SharePoint?) to provide access through internal State networks and secure external connections to all project team members, approved project stakeholders and participants. In conjunction with the utilization of this tool, the Contractor must:Structure the document management and collaboration pages and data structures in such a manner as to support the overall requirements of the project;Be responsible for the maintenance and general upkeep of the designer configurations of the tool in keeping with commercially reasonable considerations and industry best practices as to not adversely impact the project delivery efforts performed by the Contractor and State; andAt the conclusion of the project, or upon request of the State, ensure that the State is provided a machine readable and comprehensive backup of the SharePoint? database(s) contained within the tool that is owned by the State and not proprietary to the Contractor or otherwise required by the State to maintain ongoing project documentation and artifacts (i.e., Contractor is to remove all Contractor proprietary or non-State owned or licensed materials from the tool).Service Level Requirements This section sets forth the performance specifications for the Service Level Agreements (SLA) and Service Level Objectives (SLO) to be established between the Contractor and the State that are applicable to any work associated with the operation, maintenance, updates or upgrades of any software associated with this Supplement in general.The section contains the tables and descriptions that provide the State framework, requirements relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. This document defines the State’s detailed performance, management, and reporting requirements for the Operations and Run Services and to all subsequent Operations and Run services and phases that are contracted under future Statements of Work between the State and the Contractor related to this RFP. The mechanism set out herein will be implemented to manage the Contractor’s performance against each Service Level, in order to monitor the overall performance of the Contractor.The Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of this RFP and will provide these reports to the State on a no less frequent than monthly basis: Service Level Specific Performance – Agreed upon specific Service Levels to measure the performance of specific Services or Service Elements. Most individual Service Levels are linked to financial credits due to the State (“Performance Credits”) to incent Contractor performance.Overall Contract Performance – An overall performance score of the Contractor across all Service Levels. The overall performance score is linked to governance and escalation processes as-needed to initiate corrective actions and remedial processes.Service Level Specific Performance CreditsEach Service Level (SL) will be measured using a “Green-Yellow-Red” traffic light mechanism (the “Individual SL GYR State”), with “Green” representing the highest level of performance and “Red” representing the lowest level of performance. A Performance Credit will be due to the State in the event a specific Individual SLA GYR State falls in the “Yellow “or “Red” state. The amount of the Performance Credit for each SLA will be based on the Individual SLA GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. No Service Level Performance Credit will be payable for the Contractor’s failure to meet a Service Level Objective.Set forth below is a table summarizing the monthly Performance Credits for each SLA. All amounts set forth below that are contained in a row pertaining to the “Yellow” or “Red” GYR State, represent Performance Credit amounts.Consecutive (SLA Performance Credits)Individual SL GYR State1st Month2nd Month3rd Month4th Month5th Month6th Month7th Month8th Month9th Month10th Month11th Month12th MonthRedA =1.71% of MPCA + 50% of AA + 100% of AA + 150% of AA + 200% of AA + 250% of AA + 300% of AA + 350% of AA + 400% of AA + 450% of AA + 500% of AA + 550% of AYellowB = 0.855% of MPCB + 50% of BB + 100% of BB + 150% of BB + 200% of BB + 250% of BB + 300% of BB + 350% of BB + 400% of BB + 450% of BB + 500% of BB + 550% of BGreenNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneNoneThe Contractor agrees that in each month of the Contract, 12% of the monthly project charges (MPC) associated with the Project Implementation portion of this RFP will be at risk. MPCs are the charges for the deliverables accepted during a given month. The MPC for the Project Implementation will be at risk for failure to meet the Service Levels set forth in the Contract. The Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event; the highest Performance Credit available to the State for that particular event will apply. On a quarterly basis, there will be a “true-up” at which time the total amount of the Performance Credits will be calculated (the “Net Amount”), and such Net Amount will be set off against any fees owed by the State to the Contractor. Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to credit the State the maximum Performance Credit under the terms of the Contract. The Contractor will not be liable for any failed Service Level caused by circumstances beyond its control, and that could not be avoided or mitigated through the exercise of prudence and ordinary care, provided that the Contractor immediately notifies the State in writing and takes all steps necessary to minimize the effect of such circumstances and resumes its performance of the Services in accordance with the SLAs as soon as possible.For example, if an Individual SL GYR State is Yellow in the first Measurement Period, Red in the second Measurement Period and back to Yellow in the third Measurement Period for an SLA then the Performance Credit due to the State will be the sum of Yellow Month 1 (B) for the first Measurement Period, Red Month 2 (A + 50% of A) for the second Measurement period, and Yellow Month 3 (B + 100% of B) for the third Measurement period, provided (1) such Performance Credit does not exceed 12% of the MPC (the At-Risk Amount); and, (2) no single Service Level Credit will exceed 20% of the total At-Risk Amount, as stated below: SLA Calculation EXAMPLEMonthly Project Charge (MPC) = $290,000.00Monthly At Risk Amount = 12% of MPC = $34,800Maximum for any one SLA = 20% of At Risk Amount = $6,960GYR State1st Month2nd Month3rd MonthRed0$0$7,438.500Yellow1$2,479.5011$4,959.00Green6$66Totals7$2,479.507$7,438.507$4,959.00Adjusted Totals by At Risk Amount and 20% per individual SLA Limitations (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes (Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - Yes(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - No(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - Yes$2,479.50 $6,960.00 $4,959.00 Total Quarterly Credit: $ 2,479.50 + $ 6,960.00 + $ 4,959.00Total Quarterly Credit: $ 14,398.50Service Level Performance Credit payable to the State = (B) + (A + 50% A) + (B + 100% B), based on an illustrative MPC of $290,000;The total of any weighting factors may not exceed 100% of the total At-Risk Amount. To further clarify, the Performance Credits available to the State will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. Service Levels will commence with Project initiation for any Implementation Project. Overall Contract PerformanceIn addition to the service specific performance credits, on a monthly basis, an overall SL score (the “Overall SL Score”) will be determined, by assigning points to each SL based on its Individual SL GYR State. The matrix set forth below describes the methodology for computing the Overall SL Score:Individual SLAs and SLOs GYR StatePerformance MultipleGreen0Yellow1Red4The Overall SL score is calculated by multiplying the number of SLAs and SLOs in each GYR State by the Performance Multiples above. For example, if all SLAs and SLOs are Green except for two SLAs in a Red GYR State, the Overall SL Score would be the equivalent of 8 (4 x 2 Red SLAs).Based on the Overall SL Score thresholds value exceeding a threshold of fifteen (15), mandatory Executive escalation procedures outlined in this RFP will be initiated to restore acceptable Service Levels. If a successful resolution is not reached, then the State may terminate the Contract for cause if:The overall SL score reaches a threshold over a period of 3 consecutive months with the equivalent of 50% of the service levels in a red state; and the Contractor fails to cure the affected Service Levels within 30 calendar days of receipt of the State’s written notice of intent to terminate; ORThe State exercises its right to terminate for exceeding the threshold level of 75% of Service levels in total over a six (6) month period.The Overall Contract Performance will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. The State retains the right to terminate for Overall Contract Performance under the terms of this Contract.Monthly Service Level ReportOn a monthly basis, the Contractor will provide a written report (the “Monthly Service Level Report”) to the State which includes the following information: (i)the Contractor’s quantitative performance for each Service Level; (ii) each Individual SL GYR State and the Overall SL Score; (iii) the amount of any monthly Performance Credit for each Service Level (iv) the year-to-date total Performance Credit balance for each Service Level and all the Service Levels; (v) a “Root-Cause Analysis” and corrective action plan with respect to any Service Levels where the Individual SL GYR State was not “Green” during the preceding month; and (vi) trend or statistical analysis with respect to each Service Level as requested by the State . The Monthly Service Level Report will be due no later than the tenth (10th) accounting day of the following month. Failure to report any SLA, SLA performance in a given month, or for any non-Green (i.e., performing to Standard) SLA a detailed root cause analysis that substantiates cause will result in the State considering the performance of the Contractor for that period as performing in a Red State.Failure to Report or Report Late after Mutually Agreed DatesShould for any reason the Contractor fail to report or produce the Monthly Service Level Report to the State on a mutually agreeable date, in part or in total, the Contractor performance for the Service Levels, in part or in total, must be considered Red for that period. Should, under agreement of the State a Service Level not apply in a given period, the report must reflect this agreement and indicate “not applicable this period”.ePayment Applications and EnvironmentsThe State acknowledges that its ePayment environment requirements fall into two major categories: 1) critical applications – those that are required to perform day-to-day State functions in production; and 2) non-critical application environments – which are defined as items that do not have a significant impact on day-to day operations, are used in a non-production capacity, which may not adversely impact the productivity of State development efforts or are otherwise used to support non-commercial activities. The Contractor must deliver Service Levels in keeping with the criticality levels as described herein.Temporary Escalation of an SLO to an SLAIn general, SLOs are considered measurable objectives by the State and the SLA framework accommodates their treatment and importance to the State via Contract termination considerations as opposed to financial credits as contained herein. However, in the event that Contractor performance is not meeting the established standards and requirements for SLO related items, the State may determine that an SLO needs to be escalated to an SLA. The following conditions must prevail in this escalation:Contractor performance falls below yellow standard in an SLO area for three consecutive months; orContractor performance falls below 75% of red standard in any given month; or Contractor performance is consistently in a yellow or red status for four of any six consecutive months.Should one or more of these conditions exist, the State may:Temporarily replace any SLA of its choosing with the SLO until such time as the below standard SLO is determined to be consistently (i.e., more than 3 months in a row) performing to standardAdd the SLO to the SLA group and rebalance the weighting accordingly such that the monthly fees at risk percentage agreed to is maintained (i.e., fees at risk remain constant, the number of SLAs that are considered against those fees changes) until such time as the below standard SLO is determined to be consistently (i.e., more than 3 months in a row) performing to standardAt the conclusion of period of three consecutive months where the escalated SLO is deemed to be performing in a green status, the State and Contractor must revert the escalated SLO (now an SLA) back to its SLO state.State Provided Service Support Infrastructure ElementsThe following items will not be considered Contractor Fault with respect to Service level failures and therefore not apply to any Contractor Performance Credits or Overall Contract Performance considerations discussed later in this section:Failures outside of the scope of the Contractor responsibilities pursuant to the Services responsibility scope;Failures due to non-performance of State retained responsibilities pursuant to the services responsibility scope;Failure of an out-of-scope State provided element that directly impacts an in-scope Contractor element;Failures arising from State provided equipment or networks; A pre-existing or undocumented deficiency in a State provided computing element as they pertain to adhering to State Policies and Standards. In this case, upon identification the Contractor is to promptly notify the State of the identified deficiency; Failure of a State provided resource to follow and comply with Contractor provided processes and procedures except where: (i) State policies and Contractor policies are in conflict in which case the State resource must notify the Contractor of the conflict and resolve which process applies or; (ii) in cases of emergency that would place the State resource at physical peril or harm; Failure of a State provided third party warranty or maintenance agreement to deliver services to the Contractor for in-scope services and infrastructure elements that result in the Contractor’s inability to perform at required levels; The period of time associated with an incident where a State provided or contracted 3rd party service, repair or replacement service renders an in-scope infrastructure element unusable by the Contractor to provide the Contracted Services must be reduced from the overall duration timing of an incident; The incident requires assistance for a State retained responsibility, is delayed at the State’s request, or requires availability of an End User that is not available;Mutually agreed upon service interruptions such as scheduled changes to the technical environment; and State implemented changes to Production Environments that the Contractor is not aware or apprised of.Managed Service: Service Level CommitmentsContractor must meet the Service Level Commitment for each Service Level set forth in the table below and specified in detail later in this section Service LevelSLA or SLOCoverage1Incident Resolution – Mean Time to Repair (Severity 1 Outages)SLA7x242Incident Resolution – Mean Time to Repair (Severity 2 Outages)SLA7x243Incident Resolution – Mean Time to Repair (Severity 3 Outages)SLOBusiness Hours4Service Availability – Application AvailabilitySLA7x245Application Performance & Responsiveness SLA7x246Incident Resolution - Issue Triage, Closure and Recidivist RateSLOBusiness Hours7User Interaction - Completion of Administrative, Root, DBA, Privileged User Adds/DeletesSLOBusiness Hours (non-emergency)8Security – Security ComplianceSLOcontinuous9Monitoring & Auditing – Application Security Breach Detection, Notification and ResolutionSLA7x2410Job Schedule and Scheduled Reporting Performance SLAScheduled Hours11Operational Process Control & Repeatability – Changes to Production environmentsSLOScheduled Maintenance12Service Quality – System ChangesSLAScheduled Maintenance13Service Timeliness – System ChangesSLAScheduled Maintenance14Data AccuracySLAcontinuousIncident Resolution – Mean Time to Repair (Severity 1 Outages)Business Intent:Prompt resolution of ePayment outages that impact State processing and processesDefinition:Mean Time to Repair (Severity 1 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 1 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. “Severity 1 Outage” is defined as :An Incident must be categorized as a “Severity 1 Outage” if the Incident is characterized by the following attributes: the Incident (a) renders a business critical System, Service, Software, Equipment or network component un-Available, substantially un-Available or seriously impacts normal business operations, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function. This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.The Contractor must report updates and progress to the State every thirty (30) minutes for this SLA until resolved.Formula:Mean Time to Repair (Severity 1 Outages)=Total elapsed time it takes to repair Severity 1 Outage Service RequestsTotal Severity 1 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Monthly Service ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 1 Outages).Green<= 4 hoursYellow> 4 hours and <= 6 hoursRed> 6 hoursIncident Resolution – Mean Time to Repair (Severity 2 Outages)Business Intent:Prompt resolution of ePayment outages that impact State processing and processesDefinition:Mean Time to Repair (Severity 2 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 2 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. “Severity 2 Outage” is defined as : An Incident shall be categorized as a “Severity 2 Outage” if the Incident is characterized by the following attributes: the Incident (a) does not render a business critical System, Service, Software, Equipment or network component un-Available or substantially un-Available, but a function or functions are not Available, substantially Available or functioning as they should, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.In the event of “go live” of new functionality, an Upgrade, or significant change in the architecture of the Application environment, this Service Level will be suspended temporarily from the time the “go live” of the applicable Change through two (2) business days following completion of stabilization criteria in accordance with the transition to production plan.The Contractor must report updates and progress to the State every sixty (60) minutes for this SLA until resolved.Formula:Mean Time to Repair (Severity 2 Outages)=Total elapsed time it takes to repair Severity 2 Outage Service RequestsTotal Severity 2 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Monthly Service ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 2 Outages).Green<= 8 hoursYellow> 8 hours and <= 12 hoursRed> 12 hoursIncident Resolution – Mean Time to Repair (Severity 3 Outages)Business Intent:Prompt resolution of ePayment issues and irregularities that impact State processing and processesDefinition:Mean Time to Repair (Severity 3 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 3 Outage Service Requests in the Contract Month. “Time to Repair” is measured from time a Service Request for in-scope Services is received at the Level 2/3 Contractor Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution. “Severity 3 Outage” Is defined as:An Incident must be categorized as a “Severity 3 Outage” if the Incident is characterized by the following attributes: the Incident causes a group or individual to experience an Incident with accessing or using a System, Service, Software, Equipment or network component or, a key feature thereof and a reasonable workaround is not available, but does not prohibit the execution of productive work.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the stabilization and transition to production plan. The Contractor must report updates and progress to the State every twenty-four (24) hours for this SLA until resolved.Formula:Mean Time to Repair (Severity 3 Outages)=(Total elapsed time it takes to repair Severity 3 Outage Service Requests)Total Severity 3 Outage Service RequestsMeasurement Period:Reporting MonthData Source:Monthly Service ReportFrequency of Collection:Per incidentService Level Measures:Individual SL GYR StateMean Time to Repair (Severity 3 Outages).Green<= 5 business daysYellow> 5 business days <=7 business daysRed> 7 business daysService Availability – Application AvailabilityBusiness Intent:ePayment is available to all State users for all Business Functions to support State processes.Definition:Application Availability for each in-scope Platform, Environment, Module and Business ProcessApplication Availability means access to the production system is enabled; log-in permitted from the local user LAN and business transactions can be executed. While it is dependent on State provided infrastructure and Third Party software availability the expectation is that the Contractor must implement operational processes, instrumentation, monitoring and controls that validate availability of ePayment to the end-user and development community in the State.This SLA will be calculated for those Service Elements that are directly in the Contractor’s scope and will be measured from the end-user community desktop to the ability to process transactions to the ePayment databases. If, in determination of the root cause of an “unavailable” condition, the State LAN, WAN and Data Center outages, or the outage of State provided Infrastructure is the cause of the condition, the Contractor must be excused from those outages that arise from such a condition, unless the outage is a direct result of a Contractor created situation.Critical Environments shall be those that are hosting or supporting State SDLC environments for those projects in excess of $5M in a given 12-month period and Production environmentsNon-Critical Environments include routine development, testing, training, demo and the like.Formula:Application Availability=Total Application Scheduled Uptime – Total Application Unscheduled OutagesTotal Application Scheduled UptimeMeasurement Period:Reporting MonthData Source:Monthly Service ReportFrequency of Collection:Continuous, 24 hours a dayService Level Measures:Individual SL GYR StateCritical/Production EnvironmentNon Critical EnvironmentsGreen>= 99.9%>= 99.0Yellow>= 99.7% and < 99.9%>=95.0 and < 99.0Red<99.7%<95.0%Application Performance and ResponsivenessBusiness Intent:ePayment Online and Batch Processes perform within expected norms, the end user experience is high performance and responsive and scheduled jobs, processes and reports execute within the established job schedule without intruding upon online application users or other business functionsDefinition:System Performance and Responsiveness will be based upon an end-to-end service class performance baseline (e.g., network time, application/session response time, system time, and network return time) performed by the Contractor during the transition or as mutually agreed will perform for key service elements for a statistically valid sample of ePayment scheduled reports.Should the Contractor wish to accept State written requirements for each of the above in lieu of benchmarking, or use the aforementioned benchmarking, this sample shall serve as the “Performance Baseline” for this SLA.Thereafter, the Contractor must perform automated testing on a daily basis for online transaction elements or provide objective evidence from system generated statistics, and provide run-time statistics for scheduled/batch system jobs and scheduled report and compare these to the Performance Baseline.Two % deviations from the Performance Baseline will be calculated: 1) % Variation Online Transactions and 2) % Variation Batch/Scheduled Operations; The higher variation (i.e., online or batch) shall be used in the below formula for both the numerator and denominator.Formula:System Performance and Responsiveness=Observed (Online or Batch Scheduled) PerformanceBaseline (Online or Batch) PerformanceMeasurement Period:Reporting MonthData Source:Monthly Service ReportFrequency of Collection:Continuous, 24 hours a day and Schedule Job/Report PerformanceService Level Measures:Individual SL GYR StateSystem Performance and ResponsivenessGreen< = 100%Yellow>100% - <=110%Red> 110%Incident Resolution - Issue Triage, Closure and Recidivist RateBusiness Intent:Incidents affecting ePayment, online batch or otherwise, are promptly addressed, prioritized and resolved to the satisfaction of the State and to not reoccur or cause corollary or spurious issues to occur as a result of the repair to the element that was the root cause of the Incident.Definition:Incident Triage, Closure and Recidivist Rate will be determined by monitoring compliance with the following four key performance indicators (KPI):Incident Triage: Contractor to indicate high-level diagnosis and estimate to remedy to the State within 30 minutes of acknowledgementIncident Closure: Incident to be documented with root cause remedy, (where root cause is within Contractor’s control), and procedures to eliminate repeat of incident within 24 hours of incident closeIncident Recidivist Rate: Closed incidents not to reappear across all in scope Services no more than 1 times following incident closureIncident means any Severity 1 or 2 incident where the Services for which Contractor is responsible are unavailableFormula:Issue Triage, Closure and Recidivist Rate=Total Severity 1 and 2 Incidents for which Contractor is responsible under the SOW, where solution Services are unavailable) - (Number of Incidents where the KPI was not in compliance(Total Severity 1 Incidents where Services for which Contractor is responsible under the SOW are unavailable)Measurement Period:Calendar QuarterData Source:Incident Management System ReportFrequency of Collection:Calendar Quarter, All Severity 1 and 2 IncidentsService Level Measures:Individual SL GYR StateIncident Resolution - Incident Triage and Closure and Recidivist RateGreen>= 99.5Yellow< 99.5 and > =99.3Red< 99.3Security – Monitoring & Auditing – Security Breach DetectionBusiness Intent:Ensure that State Security policies are implemented correctly, and monitored and followed at all times for all users of ePayment whether end-user, State, Contractor or 3rd Party.Definition:System Security Breach Detection will be determined by monitoring compliance with the following three key performance indicators (KPI):System security breach success notification due within 30 minutes of physical intrusion detection of any element within the Contractor’s responsibility area or Contractor provided facility or element that accesses ePayment including contractor’s machines. Notification will be as set forth in the State/Contractor Process Interface Manual or other supporting documents.Suspension or Revocation of unapproved or intruder access in accordance with State established procedures within 10 minutes of State approval or (absent State approval) 15 minutes.System security breach (attempt, failure) notification due within 1 hour of such physical intrusion detection. Notification will be as set forth in the Process Interface Manual or other supporting documents.Formula:Security Breach Detection=Number of instances where individual KPI’s were not in complianceMeasurement Period:MonthData Sources:Infrastructure Antivirus/Malware/Rootkit Scan logs, Active Port Scanning Logs, User Account Review ReportFrequency of Collection:MonthlyService Level Measures:Individual SL GYR StateSecurity Breach DetectionGreen 0YellowN/ARed> 0Job Schedule and Scheduled Reporting PerformanceBusiness Intent:Scheduled Jobs and Reports Start and Complete with established time parameters and execute in such a manner as to not intrude upon online users of ePayment. Job abends and restarts are monitored and executed within the established schedule.Definition:Job Schedule and Scheduled Reporting Performance shall consider all scheduled daily, weekly, monthly and business cycle Jobs and Reports that execute under the responsibility and scope of the Contractor, automated operating system job schedulers (e.g., cron, task scheduler), interfaces and any reports in the Contractor’s scope.The Contractor shall, as part of establishing and maintaining the ePayment Run Book, establish automated schedules for ePayment scheduled processes and reports and set Start, Stop and Completion and Job dependencies as appropriate.The actual Start and Completion of all Scheduled Jobs and Reports shall be recorded on a daily basis as afforded by the automated schedule. For those jobs that cannot be automated for any reason and require Contractor personnel to manually execute these jobs, the actual Start and Stop times shall be recorded and included in the below calculation.Formula:Job Schedule and Scheduled Reporting Performance=(Total Number of Minutes Jobs/Reports were delayed from Starting) + (Total Number of Minutes Jobs/Reports Ran in Excess of Completion/Stop Parameters)Total Number of Minutes Jobs/Reports Ran as ScheduledMeasurement Period:MonthlyData Sources:Scheduled Job ReportFrequency of Collection:DailyService Level Measures:Individual SL GYR StateJob Schedule and Scheduled Reporting PerformanceGreen<= 10%Yellow> 10% <= 15%Red> 15%Operational Process Control & Repeatability – Changes to Production EnvironmentsBusiness Intent:All changes to production environments follow a disciplined process, are authorized by the State and documentation is updated at all times to ensure that the operating environment of ePayment is up to date and documentation is current. Production changes are tested/validated and move as a comprehensive change package as opposed to piecemeal elements that result in unintended consequences. Definition:The changes to production environment measure is determined by monitoring compliance with the following six key performance indicators: All changes to production environments have an authorization from an approved State employee Code or System changes are promoted to production environments that use contemporary change control methods including version control, data backup/back out procedures (if applicable)All elements that comprise a system change inclusive of code, configuration values, environment parameters, database elements, security, executables and other required change elements are applied as part of a Production change No untested or unapproved changes or changed elements that are not required by a production change are introduced into the production environmentChanges that are detected to introduce errors or unavailability to production systems are reversed in accordance with the Contractor back-out procedure and the system is restored to the pre-change state without impacting regular operationsCorresponding updates to the supporting documents are completed within a reasonable timeframe of receiving and implementing minor approved change request(s)Formula:Changes to Production Environments=Total Number of KPIs not metTotal Number of KPIs metMeasurement Period:MonthlyData Sources:Production Change ReportFrequency of Collection:Each Change to ProductionService Level Measures:Individual SL GYR StateChanges to Production EnvironmentsGreen<= 1%Yellow> 1% <= 3%Red> 3%Service Quality – System ChangesBusiness Intent:System Changes are implemented correctly the first time, and do not cause unintended consequences to ePayment users, scheduled jobs and reports, corrupt or compromise data or data relationships and otherwise perform as intended from a functional, technical and performance perspective. Non-Production environments reflect Production.Definition:The Service Quality System Changes measure is determined by monitoring compliance with the following four key performance indicators (KPI): System changes or updates (i.e., break fix, configuration, and patches) in any release to production environment are implemented correctly the first time inclusive of all code, non-code, configuration, interface, scheduled job or report, database element or other change to the production environmentSystem changes or updates are propagated within 5 business days as mutually deemed appropriate to non-production environments such that environment configurations are synchronized and reflect the then current environment and a common development, testing, QA, demonstration and training environment is carried forward that is reflective of productionProduction system changes (i.e., break fix, configuration, and patches) in releases that do not cause other problemsSystem changes or updates (i.e., break fix, configuration, and patches) in emergency releases are implemented correctly the first time that comprise the ePayment systemFormula:Service Quality – System Changes=Total Number of KPIs not metTotal Number of KPIs metMeasurement Period:MonthlyData Sources:Production Change ReportFrequency of Collection:Each Change to Production and Follow-On Changes to Non-ProductionService Level Measures:Individual SL GYR StateService Quality – System ChangesGreen<= 2%Yellow> 2% <= 5%Red> 5%Service Timeliness – System ChangesBusiness Intent:System Changes are implemented in a timely manner as scheduled with the State or (if applicable) during a Scheduled Maintenance Period or as required by the State.Definition:The Service Timeliness System Changes measure is determined by monitoring compliance with the following two key performance indicators (KPI): Emergency system changes or updates (i.e., break fix, configuration, and patches) to ePayment will be initiated within 24 hours of the State approved request and Change Management Process and to be reported complete within 1 hour of completion Non-emergency system changes or updates (i.e., break fix, configuration, and patches) to ePayment to be initiated in accordance with the State policies during a scheduled maintenance period or as mutually scheduled between the Contractor and State and reported within 2 days of post implementation certificationFormula:Service Quality – System Change Timeliness=Total Number of KPIs not in Compliance in a MonthTotal Number of System Changes in a MonthMeasurement Period:MonthlyData Sources:Production Change ReportFrequency of Collection:Each Change to Production and Follow-On Changes to Non-ProductionService Level Measures:Individual SL GYR StateService Quality – System ChangesGreen<= 2%Yellow> 2% <= 5%Red> 5%Exhibit One: State Systems Inventory and ePayment MethodsThis section is provided for Offeror consideration in the development of proposals to this RFP and includes general descriptions of State systems, and volumes. ApplicationFY 2016 VolumeTransactions%Ohio Business Gateway 3,218,396 81.38%DOCUNCLAIMEDFUNDS??JFSFANDI??JFSUCTAX??ODTASSESSMENT??ODTASSESSMENTEWH??ODTASSESSMENTSDWH??ODTCASINOTAX??ODTFITTAX??ODTHORSERACINGTAX??ODTIFTATX??ODTKWHDTAX??ODTMVFTAX??ODTNGTAX??ODTNGTAX??ODTNONRESSALESTAX??ODTPATACTTAX??ODTPATANLFEE??ODTPWH??ODTSALESTAX??ODTSDWH??ODTSERVRNCETAX??ODTWRLESS911??OHIOBWC??OHIODEFERREDCOMP??RSCMOR??Ohio Boards and Commissions 219,633 5.55%Hearing Aid & Fitters Lic VPOS??Hearing Aid and Fitters Lic ??Ohio B & C - Casino Control Commission VPOS??Ohio B&C Accountancy - TEST??Ohio B&C- VPOS Embalmers and Funeral Directors??Ohio B&C-Accountancy??Ohio B&C-Architects??Ohio B&C-Barber Board??Ohio B&C-Casino Control??Ohio B&C-Chemical Dependency??Ohio B&C-Chiropractic Board??Ohio B&C-Cosmetology??Ohio B&C-CSWMFT??Ohio B&C-Dental Service Fees ??Ohio B&C-Dental??Ohio B&C-Dietetics??Ohio B&C-Embalmers and Funeral Directors??Ohio B&C-Engineers and Surveyors??Ohio B&C-Manufactured Homes??Ohio B&C-Medical Board??Ohio B&C-Motor Vehicle Repair??Ohio B&C-Occ, Phys Therapy & Athletic Trainers??Ohio B&C-Optical Dispensers??Ohio B&C-Optometry??Ohio B&C-Orthotics, Prosthetics and Pedorthics??Ohio B&C-Pharmacy??Ohio B&C-Psychology??Ohio B&C-Respiratory Care??Ohio B&C-Sanitarian Registration??Ohio B&C-Speech Language, Path & Audiology??Ohio B&C-Veterinary Medical Licensing??Ohio Attorney General 175,785 4.44%Ohio Attorney General Collections??BCII Background Check??Charitable Trust Late Fee??Charitable Trust??COIN BINGO??Distributor License??Manufacturer Bingo License??Professional Solicitor??Solicitation Registration??Law Enforcement Conference Payment Portal ??AGO - Environmental Background Investigations Unit??AGO - Webcheck??Ohio Department of Education 132,133 3.34%Ohio Department of Education - Account Receivable??Ohio Department of Education - Educator Licensure??Ohio Department of Education - Online Payments??Ohio Dept of Jobs and Family Services 56,397 1.43%Medicaid??Ohio Children's Trust Fund??Ohio Department of Job and Family Services ??Ohio Department of Health 50,915 1.29%EIDC??Environmental Licensing??Online Vital Statistics??Radiologic Protection??Ohio Department of Commerce 32,990 0.83%Commerce - Above Ground Tank Permits??Commerce - BCC Electronic Plan Submission System??Commerce - Cigarettes Manufacturers Renewals??Commerce - Consumer Finance Renewal??Commerce - Explosives Renewal??Commerce - Fire Protection Renewal??Commerce - Fireworks Renewal??Commerce - Hotel Motel Renewal??Commerce - Industrialized Unit Plans??Commerce - OH Construction and Industry Renewal??Commerce - Ohio Fire Academy??Commerce - Real Estate and Professional Renewal??Commerce - Securities Filings and Funds??Commerce - UST Installers/Inspectors??Commerce - UST On-Line Payment System??Ohio Department of Natural Resources 19,646 0.50%ODNR - Division of Watercraft??ODNR - Ohio Wildlife Diversity Conference??Ohio DNR??DAS eLicense 17,878 0.45%eLic-Cosmetology Board??eLic-MedicalBoard??eLic-Occ-PYT Board??eLic-SanitarianBoard??Ohio B&C-Nursing Fiscal??Ohio Ethics Commission 5,600 0.14%Ohio Ethics??Counselor and Social Worker Board 5,534 0.14%CSWMFT Board VPOS??CSWMFT Board??Department of Developmental Disabilities 4,966 0.13%DODD Providers Cert Wizard??Ohio Department of Insurance 4,211 0.11%State of Ohio Department of Insurance ??Public Utilities Commission of Ohio 3,725 0.09%PUCO - Damage Prevention??Ohio Environmental Protection Agency 2,996 0.08%8275_OH_EPA_PWS_LTO??8276_OH_EPA_WW_OPCERT??8277_OH_EPA_FEE??8278_OH_EPA_Title_V??8279_OH_EPA_AIR_PTI??8280_OH_EPA_NonTitle_V??8281_OH_EPA_Asbestos??8282_OH_EPA_SM_Title_V??8283_OH_EPA_SERV_FEE??8284_OH_EPA_NPDES_ISS??8285_OH_EPA_STORM_ADF??8286_OH_EPA_ANNL_SLUJ??8287_OH_EPA_NPDES_ADF??8288_OH_EPA_GEN_PERM??CDD-GW: 8273 Ohio EPA Payment Summary??CDD-ODNR: 8274 Ohio EPA Payment Summary??CDD-OEPA: 8272 Ohio EPA Payment Summary??MSW-EPA: 8270 Ohio EPA Payment Summary??MSW-ODNR: 8271 Ohio EPA Payment Summary??Ohio State Chiropractic Board 1,648 0.04%Ohio State Chiropractic Board??Ohio Department of Transportation 929 0.02%ODOT Aviation??Ohio LTAP Center??Ohio Auditor 821 0.02%2015 Ohio Auditor – Village Officers Training??Ohio Auditor - 2015 IPA Conference??Ohio Auditor - 2016 Ohio Auditor Conference??Ohio Auditor - 2016 Local Gov Officers Conference??AOS - LEAP Audit Fees??AOS - LEAP Audit Interest??AOS - LGS Audit and LFF Fees??AOS - Local Audit Fees??AOS - State Audit Fees??AOS - UAN Fees??Ohio Auditor - 2016 CFAE Conference??Treasurer of State 415 0.01%CPIM??Ohio Dept of Administrative Svc 78 0.00%Ohio DAS/OIT??Ohio Department of Aging 46 0.00%ODA - Aging Credit Card Fee??ODA - Medicaid Application Fee??AGE-Ohio BELTSS??AGE Ohio BELTSS – CC Fee??AGE Ohio Ombuds Bed Fee??AGE Ohio Ombuds Bed Fee – CC Fee??AGE Ohio LTCCG??AGE Ohio LTCCG – CC Fee??Casino Control Commission - 0.00%Casino Control - Renewal Application??Casino Control - Renewal License??Casino Control Commission - Application Fees VPOS??Casino Control Commission - Renewal License VPOS??Ohio State Employment Relations Board - 0.00%State Employment Relations Board??State Employment Relations Board Credit Card Fee??Ohio Capitol Square Review and Advisory Board - 0.00%Statehouse Misc??Statehouse Parking??Statehouse Special Events?? ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download