Exhibit 2.1.2 - Payment Services Statement of Work.docx

State of South Carolina State Fiscal Accountability Authority (SFAA)

Request for Proposal Exhibit 2.1.2 Payment Services Statement of Work

RFP Solicitation No. 5400021069

Table of Contents

Exhibit 2.1.2 (Payment Services Statement of Work)

RFP Solicitation No. 5400021069 Page i of ii

INTRODUCTION

General As of the Commencement Date, Service Provider will be responsible for providing Payment Services as described in this Exhibit 2.1.2 (Payment Services Statement of Work).

The Service Provider shall provide Payment Services described in Exhibit (4.1 Pricing Structure), as it may be amended from time to time or supplemented through Change Control as defined in the Agreement. Additionally, the Service Provider shall provide a payment gateway that will interface with two or more merchant card processors. The Office of the State Treasurer (STO) will designate a merchant card processor for subject entities. The Service Provider will provide a merchant card processor for the remaining entities. The payment gateway will receive payment requests from multiple sources such as SC.gov applications, Customer applications, over-the-counter devices, and other standard interfaces. The Service Provider is responsible for providing standard and custom reporting, data files meeting different Customer requirements, and ensuring funds are properly processed using standard credit/debit and ACH rules.

Service Provider will be responsible for providing Payment Services for the SC.gov Applications and Customer Applications using Payment Services existing as of the Commencement Date (as described in the preceding paragraph) and those Applications developed and transitioned into the production environment.

Service Provider is also required to provide the Services in Exhibit 2.1.1 (Cross-Functional Services Statement of Work) in conjunction with the Services described in this Exhibit 2.1.2 (Payment Services Statement of Work).

Overview The Service Provider shall deliver the Services in the best interests of the South Carolina Department of Administration's Office of Technology and Information Services (OTIS), STO, and Customers. Service Provider will be responsive to OTIS and Customers' current and future requirements by proactively anticipating needs and adjusting Services. Requirements for New Services will be per Exhibit 4 (Business Model). The Service Provider shall work with OTIS to assess these requirements on the Digital Government Services (DGS), Customers, and OTIS's operating environments and supported Applications per the terms of the Agreement.

This Exhibit 2.1.2 (Payment Services Statement of Work) sets forth the Payment Services that the Service Provider shall provide, as of the Commencement Date unless otherwise specified.

The Service Provider shall provide Charges inclusive of all activities required to provide the Services outlined in this Exhibit 2.1.2 (Payment Services Statement of Work), including project-related support activities. The Service Provider confirms that it will provide a solution that supports all of the requirements described in this Statement of Work and its Exhibits unless otherwise explicitly stated. Unless otherwise stated, all Services are included within the Charges described in Exhibit 4 (Business Model). Accordingly, the Service Provider also confirms that Customers will not incur any other charges concerning the services described in this Exhibit 2.1.2 (Payment Services Statement of Work).

This scope of work defines requirements the Service Provider must meet to achieve the objectives of this procurement.

Operating Model OTIS has defined a DGS operating model aimed at achieving the overall Digital Government Service program objectives. This model provides context for the DGS solution and outlines general responsibility boundaries between OTIS Shared Services Governance, OTIS DGS Sourcing Management, Digital Government Services towers, STO, and the DGS Customers.

South Carolina Digital Government Services Operating Model

OTIS Shared Services Governance and Sourcing Management As the overall service owner, OTIS operates a sourcing management and governance organization that performs customer relationship leadership, service and sourcing strategy, service portfolio management, and contract and financial management roles. The OTIS DGS Sourcing Management function works closely with the Service Provider to ensure the South Carolina Digital Government Services meet the State’s desired outcomes.

Digital Government Services The Digital Government Services includes two specialized service towers, SC.gov Services and Payment Services, each defined by a respective statement of work provided by a single Service Provider.

SC.gov Services Tower As specified in Exhibit 2.1.3 (SC.gov Services Statement of Work) and in accordance with Exhibit 2.1.1 (Cross-Functional Services Statement of Work) and per the SMM, the SC.gov Services tower includes web application development and support, Customer and citizen support, Customer and citizen services outreach and growth, support for all required Infrastructure, cross-functional and IT security capabilities, and Payment Card Industry Data Security Standard (PCI-DSS) security management.

Payment Services Tower

South Carolina Digital Government Services Payment Services Key Interfaces

As specified in this Exhibit 2.1.2 (Payment Services Statement of Work) and in accordance with Exhibit 2.1.1 (Cross-Functional Services Statement of Work) and per the SMM, the Payment Services tower includes front-end payment services consisting of web interfaces, hosted payment page, point of sale (POS) processing, over-the-counter (OTC) payment capabilities, and payment gateway operations. The Payment Services tower provides merchant card services and can be the Merchant of Record for non-state entities. For state entities (e.g., agencies), the Payment Services tower uses the Statewide Merchant Agreement (SMA) and supports the state entities in their role of Merchant of Record. Both SC.gov and Payment Services towers will provide financial and operational transparency to OTIS DGS Sourcing Management, Customers, and STO. Service Provider will be responsible for ensuring PCI-DSS compliance for all non-state entity Customers and will provide PCI-DSS support for state entity Customers.

STATEMENT OF WORK

General Requirements Requirements The Service Provider shall, at a minimum:

Obtain prior OTIS and STO approval of any fees or charges associated with the proposed electronic payment options. All fees must conform to card brand rules.

Perform according to Customer Statement of Work which contain configurations, fees, and other pertinent information.

Implement new, modified, or expanded payment options as required and agreed to by the Parties and STO.

Provide a web-based application for payment processing where the Customer is not providing data via API or other transmission method. The application will include a Citizen friendly landing page that renders as a Customer website. The Customer will be able to provide limited SKUs and pricing for Citizen selection to facilitate Customer delivery of services.

Provide access to the payment administration portal hosted and furnished by the Service Provider to perform approved Level 1 support and Customers to perform approved Customer functions (e.g., refund and chargeback processing).

Periodically review all user accounts established to the payment administration portal for appropriateness by OTIS or their designee(s) with the results provided to Service Provider.

Provide access and terminate access to the payment administration portal or other required portals for OTIS, SC.gov Services Tower, and Customer users upon request.

Assist authorized Customer users in gaining portal access to merchant card processor for additional reporting and chargeback activities.

Support Customers specific payment requirements, which may have multiple interactions with payment gateway, including validity and success of payment transaction.

Provide technical and business support to onboard new Customers or new services, including onboarding documentation, responding to Customer inquiries, supporting testing, and other relevant activities.

Obtain at least twelve (12) months of the most recent historical transaction data from Incumbent Service Provider and make it available in the Service Provider system for Customer merchant cards chargeback, refund, and reconciliation purposes.

Identify any point of sales equipment or devices in need of replacement, including reason and options for replacement.

Participate in the appropriate governance activities outlined in Exhibit 1.2 (Governance Model). Duties include but are not limited to:

Provide and present agenda items, in alignment with OTIS, concerning the gateway services with prior governance review; and Perform all relevant administrative functions.

Office of the State Treasurer Banking In accordance with the South Carolina Code of Laws Sections 11-13-120 and 11-13-125, Service Provider must deposit funds into the designated account(s) for subject Customers.

Under the South Carolina Department of Administration's direction and authority, Service Provider will be responsible for the designated Composite Reservoir Account (CRA).

All matters pertaining to the payment gateway service that involves the utilization of the SMA or a STO bank account will be addressed directly between the Service Provider and STO, in accordance with the applicable South Carolina Code regarding the STO's role in acceptance of merchant cards by State agencies:

SECTION 11-5-280. Acceptance of merchant cards by state agencies.

The State Treasurer may enter into contracts allowing a state agency or institution to accept merchant cards as payment for goods or services provided.

SECTION 12-54-75. Electronic collection of revenues.

(A) The State Treasurer may authorize a state agency which collects revenues, either as taxes or license fees or as payment for goods or services, to accept electronic forms of payment including, but not limited to, merchant cards, debit cards, bank debits or credits, or electronic purse options. These electronic payments may be accepted in the course of an electronic commerce transaction, in which the business transaction is conducted by means of the internet, interactive voice response, or other fully electronic means.

(B) The State Treasurer may contract on behalf of the agencies with payment service providers for the processing of electronic payments, and may negotiate associated processing fees. The agency collecting revenues electronically may withhold the negotiated processing fees for payment to service providers from the revenues collected.

Adhere to the Delegation of Authority Agreement Addendum for CRAs between the South Carolina State Treasurer and South Carolina Department of Administration.

Service Provider must ensure funds related to non-subject Customers are not deposited into the CRA.

Service Provider is prohibited from withdrawing funds from the CRA unless expressly approved by OTIS and STO. Approved withdrawals may be made for Customer initiated refunds or required chargebacks.

Complete a monthly bank account reconciliation. The Service Provider will provide the reconciliation as documented in Exhibit 3.3A (Reports), and the Service Provider will include sufficient supporting detail as required by OTIS and STO.

Subject to STO guidance, Service Provider must deposit sufficient funds to offset all monthly bank fees.

STO may require the Service Provider to enter into a separate agreement. Such agreement will include, but not be limited to: 1) the manner in which funds will be moved from the CRA; 2) who has access to the CRA; 3) how chargebacks and reversals will be handled; 4) how the Service Provider will be paid for any service fees levied against cardholders (associated with POS transactions) that may be credited to the CRA, due to the fee portion being included/combined with the payment amount due to the Customer; and 5) who will pay the fees associated with a CRA.

For Customers, opting to pay the program fee, Service Provider must deposit 100% of collected receipts directly into CRA accounts without removing any fees. Service Provider will then invoice Customer for program fees.

Service Provider must deposit sufficient funds to ensure that no overdrafts are incurred in the CRA. Funds deposited should be separately tracked on the bank reconciliation.

Program Fee Collection Service Provider shall, at a minimum:

Ensure all revenue earned under the program guidelines is appropriately processed, tracked, collected, and reported to ensure the State receives the full benefit of revenue.

Track all transactions processed based on the approved fee schedule to determine the amount due.

Use available payment processing technology and rules-based methodology to route fee revenue to Service Provider account where possible to minimize invoicing.

If the fee is unable to be split from the Customer amount, then Service Provider will invoice and collect fees from Customer. The Service Provider may not net the fee against the Customer amount where Customer has agreed to pay the fee.

Refunds or chargebacks deducted from the Service Provider bank account will be invoiced to the Customer. Chargebacks related to the fee portion of Visa's Government and Higher Education Program (GHEP) transaction may be included as an expense under the self-funded program.

For ACH, the Service Provider will retain the program revenue fee. If the deposit settles into the Customer account, then Service Provider will invoice the Customer for program revenue fees.

Escalate if fees being remitted are not following agreed-upon fee or Customer receivables are greater than ninety (90) days.

Data Access and Reporting Service Provider shall, at a minimum:

Provide financial reporting and support for electronic payment transaction information, reconciliation, and auditing purposes.

Provide program fee revenue reports by Customer, service, fee type, and other decision-making criteria.

Provide standard and custom dashboards and reports summarizing payment information by Customers such as trends, refunds, chargebacks, payment type, and other decision-making criteria.

Provide Customer defined data file(s) via the prescribed transfer process (e.g., FTP) using the required frequency to support Customer processing and reporting of transactions.

Provide reconciliation processes that account for funds held either by the Service Provider or by any card acquiring banks or ACH origination banks for transactions considered in the process but not yet remitted to the Customers. The reconciliation processes shall also include identifying the ownerships of any funds that may be in any CRA account belonging to STO or any local procurement bank account. Service Provider must resolve any unreconciled items with Customer and or STO.

Through the gateway service, provide for an interface between the gateway and the Customer's accounting system to accommodate the identity of daily deposits made to the Customer's depository bank account.

Provide financial and transaction details as described in Exhibit 3.3 (Description of Reports).

The Service Provider shall provide all pre-processing and processing data files to OTIS in support of SCEIS integration. The file requirements, delivery mechanism, and timing will be provided by OTIS and STO.

Service Provider must provide OTIS, STO, and Customers real-time access of all attempted and failed transactions and payment reports online, in human-readable reports (e.g., Excel, PDF) with export capabilities through Service Provider's interfaces, with access to at least seven (7) years of history, including at a minimum:

SC.gov customer hierarchy setup Processed transactions Charges Deposits Fees (split into three (3) categories: Customer/Agency, OTIS, Payment Services) Exception transactions Chargeback/Reversals transactions Refund transactions Settlement and exception reporting Reconciliation reporting Payment decline analysis by payment method, region, currency, amount range, Merchant Identification Number (MID), Terminal Identification Number (TID), Gateway Identification Number (GID), Bank Identification Number (BIN), and reason code The flow of funds and data through the ACH network/gateway Provide tools, API, and processes for ad hoc retrieval and reconciliation of processed and exception transaction data.

Provide tools, API, and processes for ad hoc retrieval and reconciliation of charges, deposits, and fees.

Provide tools, API, and processes for direct access to the merchant cards processor(s), enabling access to research and escalate issues on behalf of OTIS or a Customer.

Gateway Services Requirements The Service Provider shall, at a minimum:

Provide and perform gateway functions supporting the channels, devices, payment types denominated in United States Dollar (USD) currency.

Provide for additional data elements such as SKUs, product description, or other information need to produce Customer-friendly reports to allow for reconciliations, the internal distribution of funds, service delivery to the Citizen, and other required activities.

Provide a distinction between interchange-related fees (card associations and debit networks) and payment gateway processing-related fees. Service Provider shall indicate who will pay the interchange-related fees (Service Provider or Customer). Arrangements may provide two different situations where the cardholder or the ACH payer is being levied a service fee and what entity is absorbing the fee for the payment gateway services.

Provide a payment gateway service as part of its menu of services that includes: 1) Front-end application and 2) a payment engine that connects to either an ACH originating depository financial institution (ODFI) or to a merchant card processor. The gateway must be in accordance with the following requirements:

The gateway must accommodate the receipt of funds (electronic payments), offering two payment methods: 1) ACH debits originated against customers, and 2) merchant card payment transactions initiated by customers.

The gateway must accommodate electronic payments initiated through websites provided by the Service Provider or websites provided by Customers. The gateway must accommodate both URL redirects from and API-related arrangements. The gateway must accommodate interfacing with shopping cart applications and other applications.

The gateway service must be structured to accommodate two categories: 1) public procurement units whose custodian of funds is STO (e.g., State universities and most State procurement units); and 2) public procurement units whose custodian is not STO (local procurement units, technical colleges, and a few designated State procurement units exempt from having STO as its custodian).

The gateway service must provide an interface between the gateway and Customer proprietary accounting systems to accommodate the identity of daily deposits made to the depository bank account.

State agencies where the custodian is STO must utilize the South Carolina Enterprise Information System (SCEIS), a centralized accounting system provided by SAP. Service Provider to provide a interface files, in an the agreed OTIS/STO formats, delivery mechanisms and timing, to support the SCEIS interface.

All Customers must be offered online access to view their deposit activity, as well as being provided the ability to download transaction reports.

Provide support for all payment channels through Service Provider standard interfaces, including, but not limited to:

Payments made online Payments made from a mobile browser Payments made within a mobile application POS Payments made with mobile applications Payments made through standard APIs Payments made via interactive voice response (IVR) Payments made over the phone Payments using third party applications such as PayPal, Google Pay, Apple Pay, and Amazon Pay Provide and support Service Provider-certified POS payment devices, including, but not limited to:

In-store mobile POS.

Countertop POS.

Allow a connection between applications utilizing swipe devices purchased before the Effective Date and Service Provider's payment interface, so long as Customer transmits to Service Provider swiped transaction data and not transaction data that has been keyed into the swipe devices. For other Customer-supplied swipe devices on approved SC.gov Applications, the Service Provider may allow a connection between the Application and the Service Provider's payment interface so long as Customer transmits to Service Provider swiped transaction data and not transaction data that has been keyed into the swipe devices.

Provide a solution that will support and accept various electronic payments from Citizens and other Authorized Users. Electronic payment types include, but are not limited to:

Online merchant cards and signature debit card payments Online PIN debit card Online branded prepaid or gift cards (e.g., American Express, MasterCard, Visa) Automated Clearing House (ACH) processing with support for all NACHA formatted Standard Entry Class (SEC) Codes Provide processing and support for subscription and recurring payments with equal or varying amounts per billing period.

Provide option for Customers to select what card brands or ACH will be accepted for each MID, including unique requirements at different locations.

Provide advanced anti-fraud protection capabilities, including:

Fraud thresholds and escalation process Real-time automated fraud detection, prevention, and ID theft protection Dispute mediation policies, processes, and operations Provide a test environment to included testing of payment methods and processes during Transition, new Customer onboarding, maintenance and Upgrade activities, enhancement projects, and as requested by Customers. Test environment will include integration into STO systems and data feeds.

Citizen Experience Requirements The Service Provider shall, at a minimum:

Deliver an intuitive, compelling, easy-to-pay Citizen experience.

Work with Customer to develop and implement a process for Citizens to set up recurring electronic payments.

Provide custom branded checkout option and Hosted Payment Page (HPP) for SC.gov or Customer applications.

Provide the option for Citizens to save payment method(s) on file for repeat or future one-click purchases.

Provide mobile payment presentation at checkout.

Provide mobile presentation of receipts.

Provide the option for one-click / frictionless (buy now) payments.

Provide payment processing service availability meeting or exceeding the service levels as defined in Exhibit 3.0 (Performance Model) and all attached Exhibits.

Customer Support Support Common requirements (applies to State Entities and Non-State Entities) The Service Provider shall, at a minimum:

Provide a designated contact for the operational payment support to Customers and STO.

Provide Level 2 and Level 3 technical support in English available twenty-four (24) hours a day, seven (7) days a week, 365 days a year, according to the SLAs defined in Exhibit 3.0 (Performance Model) and all attached Exhibits, to SC.gov Services tower service desk agents to contact and receive support. Support contact methods include:

Phone Email Live Chat and Chatbot Payment Services Merchant Cards Payments Merchant Card Transactions – General For Customers required to have funds deposited in the CRA, Service Provider must use the SMA. All other Customer payments will be processed under the Service Provider merchant card agreement.

Deposit all funds into the CRA or Customers bank account by the next business day using standard ACH banking procedures.

Be responsible for the proper settlement of the funds according to the applicable payment industry rules for services related to electronic payments through a payment gateway. Service Provider stands in a relationship of trust and confidence with the State, Customers, and Citizens who use the services. Settlement of funds must adhere to the requirements specified.

All major card brands are to be processed, including Visa, MasterCard, Discover, and American Express. The SMA provides for a full-service arrangement with Discover and STO has a master contract with American Express.

The payment gateway must accommodate card-not-present transactions (e-commerce and MOTO) and card-present transactions (POS terminals and POS software applications). A virtual terminal feature may be offered that accommodates both card-present and card-not-present transactions. All capture methods must comply with the PCI-DSS. The terminals used for card-present transactions must be EMV certified.

Service Provider must support capture devices and equipment currently in use at Commencement until equipment becomes end-of-life.

For Customers participating in the SMA, the capture device and equipment must be procured from the SMA vendor unless otherwise agreed to by Parties and STO.

Service Provider must identify what capture devices and equipment it will provide and what devices and equipment the Customer will be responsible for delivering. All devices and equipment must be PCI-DSS compliant. Examples include POS terminals, magstripe devices, pin pads, printers, etc. POS terminals must be chip capable. The Service Provider must identify responsibility for replacing end-of-life supported devices and equipment or equipment currently utilized with the current vendor that the Service Provider does not support. Service Provider will use the most secure type of encryption.

The payment gateway must allow the Customer to either absorb the gateway's costs or levy a "service fee" against the cardholder, as permitted under the card associations' rules.

SMA offers Customers proprietary payment gateways, which may be utilized based on Customer preference. The gateway will generally be allowed if the Service Provider's role is only to establish a Customer's website (not involving the Service Provider's payment gateway). In this case, the Customer is the enrollee in the SMA gateway and pays SMA directly for the gateway service and associated merchant fees. This requirement does not apply to Customers being serviced under a payment facilitator arrangement.

Customers participating in the SMA and utilizing the Service Provider's payment engine will be assigned a Primary MID. They will be grouped under a single corporate MID assigned to the service provider. Service Provider to have access to SMA's online reporting for all Customers' MIDs (both primary and outlet MIDs associated with the corporate MID). The Service Provider must ensure that a separate outlet MID is established for each of the Customer's physical locations accepting merchant cards. This requirement does not apply to Customers under a payment facilitator arrangement.

A Customer using the Service Provider for merchant card services does not preclude the Customer from securing other merchant card services directly from SMA.

Customers participating in the SMA must execute a Participation Agreement with SMA according to the STO contract with the SMA. The Service Provider is not a party to this agreement. The Service Provider must ensure the Customer has executed the required Participation Agreement before providing payment gateway services. The arrangement between the Service Provider and the Customer will be in accordance with a Statement of Work (SOW) between the two entities. This requirement does not apply to Customers under a payment facilitator arrangement.

The SMA fee schedule will apply for Customers, and the Service Provider will be invoiced for the fees. This requirement does not apply under a payment facilitator arrangement.

If a new merchant card processor is selected for the SMA or Service Provider, the Service Provider must identify the tasks required to complete the transition. The Service Provider will manage the transition for Customers.

Merchant Card Transactions – For Customers whose custodian is STO Service Provider may not be a Payment Facilitator.

Customer will be the merchant of record under the Card Associations' Rules, as it is considered the entity selling the product or service.

Settlement of funds from the Acquiring bank will be made directly to each Customer Bank account. However, consideration will be made for the funds to settle to a single CRA owned by STO, with subsequent disbursement from the CRA to each Customer's depository bank account owned by STO.

This Agreement is not intended to provide POS applications to State procurement units that do not levy a service fee against the cardholder. Such service is typically provided to the procurement unit directly by SMA. Exceptions may be granted considering the economic and efficiency benefit that may be obtained by the Customer acquiring all merchant card services from the Service Provider. Exceptions must be obtained from STO.

Merchant Card Transactions – For Customers whose custodian is NOT STO Service Provider may propose either a typical third-party service provider arrangement or a Payment Facilitator arrangement.

Customer will be considered either as a "merchant," or if under a payment facilitator arrangement, as a "sub-merchant, as in either case, it is regarded as the entity that is selling the product or service.

Customers whose custodian is not STO are not required to utilize the SMA but may do so if the Customer is the "merchant", and the Customer's funds do not flow through a STO bank account. In this case, a Participation Agreement is required to be executed by the Customer with SMA, which allows for funds to be deposited directly to a Customer's depository bank account. A payment facilitator arrangement is not allowed under the SMA.

Settlement of funds from the Acquiring bank will be made directly to each Customer depository bank account. If a payment facilitator arrangement is offered, the initial settlement bank account may be one that is allowed under the Card Associations' rules pertaining to payment facilitators.

If a payment facilitator arrangement is provided, the Service Provider's acquiring bank will dictate the MID structure.

If a payment facilitator arrangement is provided, the Service Provider's acquiring bank or the Service Provider will dictate any participation agreement needed, in addition to the required sub-merchant agreement required by the Card Associations.

Demonstrate that it complies with the US Department of Treasury's Financial Crimes Enforcement Network (FinCEN), which issues the federal licenses; or is in compliance with the State's money transmitter licensing requirements, unless exempt. If deemed a money transmitter – whether a payment facilitator, third-party payment processor, or other organization - is considered a type of Money Services Business (MSB) under federal law. The Service Provider must provide proof of any exemptions.

Merchant Cards Chargebacks The Service Provider shall, at a minimum:

Provide processing and resolution of merchant card chargebacks.

Implement processes and procedures to minimize instances of payment transaction merchant card chargebacks to the greatest extent possible.

Ensure that the descriptor appearing on Citizen's monthly statement identifies the transaction from the Citizen's perspective.

Ensure that the descriptor includes the name of the Customer and a description of the item being charged.

Build edits and validations into automated systems to prevent erroneous transactions, including, at a minimum:

Prevent Citizens from erroneously submitting the same transaction multiple times.

Eliminate the need for Citizens to enter payment amounts. This is not meant to preclude an application from allowing a partial payment from Citizens.

Prevent Citizens from modifying payment amounts computed by automated systems.

Utilize card number check digit routines Utilize address verification and merchant card security codes.

Provide traceability of any online payment transaction from acceptance through authorization, settlement, posting, and any refunds or transaction merchant card chargebacks.

Ensure all pull-back funds by the merchant card companies for transaction chargebacks (a Remitter-initiated return of funds) are from the Customer's bank account unless otherwise agreed to by Parties.

Coordinate with Customers as necessary to resolve disputes.

Support Customer activities to dispute a chargeback, such as facilitating online access, advising on documentation needed to be successful in dispute, and other chargeback-related support.

Dedicate adequate resources to respond to payment disputes promptly, as defined in the SMM.

Provide automated processes and administrative tools supporting research, voids, refunds, and customer-disputed charges.

Automatically match merchant card chargeback to the original authorization and settlement record.

ACH

The Service Provider shall, at a minimum:

Provide Customer with the ability to accept ACH payments through the payment gateway. The ACH transactions will be originated through the Service Provider’s ACH Originating Bank. If approved by the STO, the Customer may instead request the Service Provider submit the ACH file to the Customer’s ACH Originating Bank for processing. For Customers whose custodian is STO, Service Provider will deposit all funds into the CRA by the next business day using standard NACHA guidelines. Service Provider will adhere to STO definition of business day.

For Customers whose custodian is NOT STO, Service Provider will deposit all funds into the Service Provider bank account and then transfer funds to the Customer bank account the next business day using standard NACHA guidelines.

Provide processing to invoice the Customer for original ACH amount disbursed to Customer in the event of an ACH Return for a service where the funds flow to the Service Provider owned bank account.

ACH Returns are any ACH/eCheck items returned for non-payment by the end user's financial institution. Service Provider is not responsible for collecting non-payment or for the ACH Return amount debited from the State's depository account.

Refunds The Service Provider shall, at a minimum:

Develop and implement a process for handling refunds for electronic payments. Refunds will be processed manually by a Customer via the payment gateway or an application via API.

Process automated refunds within twelve (12) months of the original sales transaction date.

Look up refunds online with or without the reference number in accordance with the SMM.

Cost Reduction The Service Provider shall, at a minimum:

Reduce costs with features such as lowest cost routing and software development kits with open APIs for web service development.

Provide interchange optimization to achieve the lowest possible interchange costs from the issuing banks. Assist Customers to configure options to secure best rates such as Merchant Category Code (MCC), additional verifications, or other cost reduction strategies.

Increase revenue with features such as sophisticated fraud detection, local authorization requests, and one-click payments.

Provide multiple settlement periods to enable the State to receive funds as soon as possible.

Provide multiple settlement timing options, including:

Multiday Consolidated Risk and Regulatory Compliance The Service Provider is required to store, route, and process transactions while minimizing risk.

Security The Service Provider shall, at a minimum:

Provide Europay, MasterCard, Visa (EMV) compliant processing.

Maintain audit trails for all actions taken, including, but not limited, to routing changes, fee changes, permissions changes, user management changes, and any relevant actions for all enabled products and features.

Support all data security and financial audits as required by State.

Support all data security and financial audits as required by regulatory or oversight bodies such as ACH compliance, SOC, PCI, or other frameworks.

Provide audit reports including:

SOC 2 Type II report audited over the previous twelve months.

PCI Attestation of Compliance (AOC).

Provide support for end-to-end encryption for inline frames, web services, APIs, HPPs or any other methods deployed to process payments and transact Citizen information.

Provide support for end-to-end tokenization for inline frames, web services, APIs, HPPs or any other methods deployed to process payments.

Provide fraud prevention capabilities to, at a minimum:

Provide verification of customer address to card billing address for card-related transactions.

Provide address verification of customer shipment to address.

Provide flexible 3D Secure cardholder verification from Visa and MasterCard.

Provide CVV2 and CVC code verification for merchant cards.

Provide Account Verification System (AVS) capability.

Provide a fraud score generated for each transaction.

Provide fraud controls with parameters for flagging outlier transactions.

Provide online access and workflow for reviewing fraud scores.

Store and secure merchant cards/off-line debit card data to ensure that it meets or exceeds merchant card issuer privacy and security requirements.

Isolate all electronic records and supporting evidence of suspected or confirmed security or privacy incidents or breaches of the payment processing system, transactions, or related databases.

Securely and permanently delete temporary files for all secure online transactions after each transaction.

Clearly state how Citizen(s) privacy is protected in privacy policies and procedures in compliance with applicable State, Federal, and industry requirements.

Comply with all physical security procedures in all Customer facilities.

Adhere to all security requirements as defined in Exhibit 2.1.1 (Cross-Functional Services Statement of Work).

Cooperate with and assist the SC.gov Services tower in any subsequent investigation of suspected or confirmed security and privacy incidents.

PCI Compliance The Service Provider shall, at a minimum:

Provide PCI-DSS compliant operations for all payment-related services, including point of sale devices. Adhere to all rules and best practices relating to PCI-DSS.

Service Provider must be recognized as a Level 1 service provider by the PCI Security Council. Achieve PCI-DSS Level 1 compliance and perform annual on-site reviews by an internal auditor and network scan by an approved scanning vendor (ASV).

Support Customers that are participants in the SMA, each Customer is subject to various policies associated with PCI-DSS compliance. They include compliance with the PCI Data Security Standard, and a related supplemental policy. The policies may be viewed at: https://treasurer.sc.gov/resources/banking-forms-and-policies/ For Customers that are not participants in the SMA, the Service Provider will be responsible for dictating how the Customers will validate their PCI-DSS compliance. The Service Provider will indicate: if it has a tool available for validating the compliance or for obtaining necessary vulnerability scanning; if it has an association that provides such validation services; and who will pay for these validation requirements.

Service Provider will be considered to meet the PCI Security Council's definition of a "service provider:” "business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data."

Service Provider agrees that execution of any contract under this Contract represents the Service Provider's agreement to be, and to remain, compliant with the PCI-DSS. The Service Provider must provide evidence of compliance whenever requested by the Customer or the Customer's qualified security assessor (QSA).

For each Customer, the Service Provider will provide a matrix of responsibilities specifying the PCI compliance responsibilities of the Customer for each card capture solution provided by the Service Provider. Liability for any non-compliance (including paying any fines) for which the Service Provider is responsible will be that of the Service Provider. The matrix must be included in the Customer Statement of Work.

Service Provider must provide supporting PCI-DSS artifacts demonstrating successful compliance. If a deficiency is identified, Service Provider must provide a remediation plan, including resolution dates. Before implementing any payment solution for a Customer, the Service Provider must advise the Customer of the possible PCI-DSS impact, including external vulnerability scanning being involved with specific capture solutions provided.

Customers that are participants in the SMA have access to a tool to validate and attest its PCI-DSS compliance. The tool allows for the completing and submitting of the appropriate annual SAQ to SMA and the ability to obtain any required quarterly external vulnerability scanning.

For Customers that are participants in the SMA, prior to being able to activate an outlet MID associated with merchant card processing, the Customer must complete several actions to demonstrate PCI-DSS compliance. This includes 1) Development of a PCI-DSS compliance policy, 2) Development of a security incident plan, and 3) Participation in an employee PCI awareness training program. This requirement does not apply to Customers that are serviced under a payment facilitator model.

NACHA Operating Rules The Service Provider shall, at a minimum:

Service Provider must comply with all applicable NACHA Operating Rules, whether expressly identified in this Contract or not.

Be knowledgeable of all payment industry rules. The Service Provider must advise the State of any changes in either the NACHA Operating Rules or the Card Associations' Rules that may impact the arrangements specified in the contract and will take the appropriate actions to rectify any violations of the Rules once becoming aware. This will include, but is not limited to, those about functioning as a service provider, functioning as a payment facilitator, levying of service fees against cardholders, adhering to the PCI Data Security Standard, and adhering to the protection and safeguarding of bank account information pertaining to Customers.

Regarding certain NACHA Operating Rules (not all-inclusive) Service Provider must specify in its response to this solicitation how it will adhere to certain Rules, including 1) the registration of the Service Provider, or its intermediary, by the ODFI as a third party sender; 2) the appropriate ACH agreements to be executed with the ODFI; 3) the annual ACH compliance audit required of the third party sender to be performed; 4) the execution of authorizations for reoccurring ACH debit transactions to be executed; 5) the Web debit account validation Rule for consumers to be adhered to, and 6) the Rule for encryption of any bank account data stored "at rest" to be correctly encrypted.

Regulatory Compliance The Service Provider shall, at a minimum:

Allow the State to audit Service Provider's books and records and the books and records of any subcontractor to the extent that such books and records relating to the performance of the Services. Such books and records shall be maintained by the Service Provider for a period of three years from the date of expiration of this Contract and by the subcontractor for a period of three years from the date of final payment under the subcontract unless a shorter period is otherwise authorized in writing by the Chief Procurement Officer.

Follow and adhere to Visa's Government and Higher Education Service Fee Program (GHEP), including proper registration with Visa and processing the fee under a separate Primary MID belonging to the Service Provider if levied by the Service Provider. (The separate MID requirement does not apply if the service fee is associated with card-present transactions. Preference is for these fees deposited to the Customer's bank account to be invoiced by the Service Provider.)

Be willing to develop, extend, or expand payment methods and processing to accommodate regulatory requirements not currently identified.

Redundancy and Disaster Recovery Processing Controls The Service Provider shall, at a minimum:

Provide monitoring, logging, and capture of processes, performance, and support for payment transactions and systems failures throughout the electronic payment process.

Disaster Recovery The Service Provider shall, at a minimum:

Provide fully redundant Services to allow for 24/7 payment Availability and achievement of the service levels as required in Exhibit 3.0 (Performance Model).

Adhere to the IT Service Continuity Management (ITSCM) requirements in Exhibit 2.1.1 (Cross-Functional Services Statement of Work) and provide redundant processes to recover from potential disasters to minimize effects and enable the Service Provider's organization to maintain or quickly resume mission-critical functions.

Application Integration Application Integration The Service Provider shall, at a minimum:

Integrate all electronic payment services with public-facing web-based applications provided and maintained by the SC.gov Services tower, Customers, and Service Provider.

Provide fully licensed, PCI-DSS compliant payment entry pages and HPP using the Service Provider's services branded to Customer and OTIS specifications.

Ensure that the HPP template is compliant with Federal and South Carolina state laws for Accessibility, including Section 508 compliance (with §1194.22 Web-based Intranet and Internet Information and Applications) and Web Content Accessibility Guidelines (WCAG) 2.0 Level AA, and provide validation documentation of compliance.

Provide payment entry pages with customizations, including, but not limited to, SC.gov and Customer logos, as approved by OTIS and Customer, service options, donation selection options, and messages, as requested by OTIS or Customer.

Provide HPP customizations, including, but not limited to, SC.gov and Customer logos, as approved by OTIS and Customer, and messages, as requested by OTIS or Customer.

Through Service Provider standard integrations and configurations, provide API integration and multiple language Software Development Kit (SDK), processing, and support to allow Customers to host their own PCI PA-DSS compliant payment pages integrating with the Service Provider's web payment channels that support payments, including, but not limited to:

Payments made online, including multi-item purchases Payments made within a mobile app (i.e., in app payments) Payments made using an eCommerce shopping cart with Service Provider standard integrations to the most popular industry applications (e.g., WordPress) Provide a standard method and support for identifying requirements, configuring, integrating, testing, and implementing HPP and API capabilities into the SC.gov applications.

Provide a controlled test environment(s) for use during Transition, development, break/fix testing of all payment transaction types (e.g., merchant cards, debit card, ACH).

Provide integration with the SC.gov Services tower systems as required in Exhibit 2.1.1 (Cross-Functional Services Statement of Work).

Support capabilities to enable SC.gov to optimize payment processing costs (e.g., open API's for direct integration).

TRANSITION

Transition Requirements General The Service Provider shall, at a minimum:

Acquire all knowledge necessary to operate Payment Services for SC.gov Digital Government Services.

Work collaboratively with the Incumbent Service Provider to affect an orderly transition of Payment Services.

Coordinate payment processing integration and implementation activities to ensure technological compatibilities among payment processing Equipment, Software, System interfaces, and telecommunications infrastructures.

Adhere to all governance structures and requirements described in this RFP and implemented during Transition and as stated in the SMM.

Participate in consolidation planning and execution processes with OTIS, STO, and SC.gov Services tower as required.

Establish all financial mechanisms and accounting procedures to manage SC.gov Payment Services operations. This activity includes maintaining detailed information on transactions processed by the Service Provider beginning on the Commencement Date and continuing for at least the next twelve (12) months and thereafter for no less than the most recent twelve (12) months. This rolling twelve (12) months of historical financial information will be available in the Service Provider system for Customer merchant cards chargeback, refund, and reconciliation purposes.

Establish all necessary processes and interfaces with stakeholders for SC.gov transaction processing as it relates to Payment Services. This may include establishing or transferring merchant accounts for Customers who have applications on SC.gov.

Provide sufficient staff, tools, and processes to ensure all Services successfully transition from the Incumbent Service Provider without service…