Supplement 1

Enterprise ePaymentGateway Service Requirements and Statement of Work

Table of Contents

Supplement 1

Enterprise ePayment Gateway Service Requirements and Statement of Work

1.0Service Overview and General Scope

1.1Initial Implementation and Future Project Opportunities

1.2Offeror Differentiators

1.3Offeror Proposed Team and State Relationship Management Requirements

1.4Contactor Best Practices and General Support Requirements

2.0ePayment Requirements

2.1Contractor Capability Requirements

2.2Requirements Matrix and Response Instructions

2.3Offeror Narrative and Response

2.4Technical and Business Requirements

3.0Support of Additional State Agency Adoption and Future Phases

3.1Future Phases Objectives

3.2Future Project Services Pricing Response and Rate Card

3.3Submission and Acceptance of Offer and Statement of Work associated with a Future Project

3.4Utilize DAS OIT’s Document Sharing/Collaboration Capability

4.0Service Level Requirements

4.1Service Level Specific Performance Credits

4.2Overall Contract Performance

4.3Monthly Service Level Report

4.4Failure to Report or Report Late after Mutually Agreed Dates

4.5ePayment Applications and Environments

4.6Temporary Escalation of an SLO to an SLA

4.7State Provided Service Support Infrastructure Elements

4.8Managed Service: Service Level Commitments

4.8.1Incident Resolution – Mean Time to Repair (Severity 1 Outages)

4.8.2Incident Resolution – Mean Time to Repair (Severity 2 Outages)

4.8.3Incident Resolution – Mean Time to Repair (Severity 3 Outages)

4.8.4Service Availability – Application Availability

4.8.5Application Performance and Responsiveness

4.8.6Incident Resolution - Issue Triage, Closure and Recidivist Rate

4.8.7Security – Monitoring & Auditing – Security Breach Detection

4.8.8Job Schedule and Scheduled Reporting Performance

4.8.9Operational Process Control & Repeatability – Changes to Production Environments

4.8.10Service Quality – System Changes

4.8.11Service Timeliness – System Changes

5.0Exhibit One: State Systems Inventory and ePayment Methods

1.0ServiceOverview and General Scope

The 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 otherpayment transactionsand 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 ePaymentService will be a State-wide enterprise service that will provide each agency with the technology to facilitate and processpayment 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 Stateagencies 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 Stateagencies 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 withState 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 Opportunities

This 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 servicemeets 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; and
  • Standardization of the State’s enterprise approach to ePayment based on a configurable integrationservices platform.

The State requires an Enterprise ePayment Gateway Service and implementation services to provide execution leadership to State Agencies tomigrate 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.

Notwithstanding 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; and
  • Include 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 Differentiators

The 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 theirorganization, 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 theirfive (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 Requirements
  • The 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 Requirements
  • The 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.

2.0ePayment Requirements