PayPoint Merchant Integration Guide 5.8.22.pdf

<PayPoint>® <Merchant Integration Guide>

<May 8, 2022/22.05.08>

Contents Fiserv

<Merchant Integration Guide> FISERV CONFIDENTIAL 2 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

© 2022 Fiserv, Inc. All Rights Reserved. This document contains confidential and proprietary information of Fiserv, Inc. You may not disclose, copy or use any portion of these materials for any purpose without the express written consent of Fiserv, Inc. All trademarks, service marks and trade names referenced in this material are the property of their respective owners. Periodic revisions to this manual are issued to reflect technical changes and enhancements to the System and to ensure that all information contained herein remains current and accurate

<Merchant Integration Guide> FISERV CONFIDENTIAL 3 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Table of Contents Disclaimer

Revision History

1.0 Introduction

Purpose Key Assumptions Best Practices

2.0 Implementation Approach

Overview Pre-Implementation Preparation Phase 1: Account Registration

PayPoint Account Credit Card/Debit Card Payments eCheck Payments PINless Debit Payments PIN-Based Debit Payments

Phase 2: Application Program Interface Design and Development Web Services API Secure HTTP API Batch API Retrieve Payment API

Phase 3: Test Mode Function: MakePayment Test Cases Function: CancelPayment Test Cases Function: PaymentStatus Test Cases Function: Calculate Convenience Fees Test Cases Function: RegistrationCRD Test Cases Function: RegistrationInquiry Test Cases Function: RegistrationLookup Test Cases Function: RecurringPaymentCD (Create, Delete) Test Cases Function: RecurringPaymentInquiry Test Cases

Phase 4: Certification Mode and Training Training

Phase 5: Production Mode (Go Live)

<Merchant Integration Guide> FISERV CONFIDENTIAL 4 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

3.0 Integration and Development

Real-Time Payment Interface Options Web Service Web Service Integration Web Service Operational Objects

Header Object PaymentInfo Object PaymentInfoCC Object PaymentInfoEFT Object PaymentInfoPOSCC Object PaymentInfoPOSEFT Object EPayAddress Object EpayRegistration Object EpayWSRegistration Object RecurringPaymentInfo Object EpayWSRecurringSchedule Object

Functional Objects MakePayment MakePOSPayment UpdatePOSPayment PINlessDebitCheck CardTypeInquiry CalculateConvenienceFee CancelPayment PaymentStatus RegistrationCRD RegistrationInquiry RegistrationLookup RecurringPaymentCRD RecurringPaymentInquiry RetrieveSchedules RegistrationLookupFS

Secure HTTP Integration Standard Input Parameters Standard Output Parameters Client Side Usage Example Server Side Usage

<Merchant Integration Guide> FISERV CONFIDENTIAL 5 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Reading the API Method Specifications CalculateConvenienceFee PinlessDebitCheck CancelPayment RegistrationCRD (Create, Replace, Delete) RegistrationInquiry MakePayment PaymentStatus RecurringPaymentCRD (Create, Update, Delete) RecurringPaymentInquiry

Encryption Support Batch Interface Option Return Code Definitions Plugin Support – Pre and Post Authorization

4.0 Payment Posting File

Select Extract File Type Extract File Name Standard Extract File Format Specifications Sequence of Records in Extract File Extract File Structure

SH = Site Header AH = Application Header AD = Standard Application Detail AD = Extended Application Detail AF = Application Footer SF = Site Footer

Additional Application Detail (AD) Posting File Fields

5.0 Resources Available

6.0 Integration Timeline

7.0 Project Organization

8.0 Support Services

9.0 TeleCheck Authorization and Disclosure Legal Compliance

Authorization Components

General Additional or Different Required Components for Certain Products

<Merchant Integration Guide> FISERV CONFIDENTIAL 6 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Authorization Retention Providing Proof of Authorization Providing Authorizations in Alternate Languages Return Payment Fees and Costs – This Only Applies If You Are Using TeleCheck Warranty Services Sales Decline or Error Required Language for Sales Decline Due to Negative Data/Risk

Required Language – Sale Error Response – to be Used When the Payment is Not Declined but Data Provided is Non-Verifiable:

Required Language – Sale Ineligible Response – to be Used When the Payment is Not Eligible for Processing as an Electronic Item:

Changes to the Authorization and Disclosure Language Checks-by-Phone - General Required Language – Checks-by-Phone – Single Payment – Consumer Required Language – Checks-by-Phone – Settlement Only – Consumer Required Language - Checks-by-Phone – Non-Consumer Required Language – Internet Check Acceptance – Single Payment – Consumer Required Language – Internet Check Acceptance – Partial Shipment/Partial Payment – Consumer Required Language – Internet Check Acceptance – Recurring Payments – Consumer Required Language – Internet Check Acceptance – Settlement Only – Consumer Required Language – Internet Check Acceptance – Non-Consumer Required Language – Prearranged Payment or Deposit – Single Payment – Consumer Required Language – Prearranged Payment or Deposit – Recurring Payments – Consumer ... 165 Required Language – Prearranged Payment or Deposit – One-Time Settlement Only – Consumer Required Language – Prearranged Payment or Deposit – Non-Consumer

Appendix A: PayPoint Account Application

Appendix B: Acronyms and Definitions

Disclaimer Fiserv

<Merchant Integration Guide> FISERV CONFIDENTIAL 7 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Disclaimer The material presented in this PayPoint Integration Guide is for general guidance only. First Data Corporation, which is now Fiserv, does not represent or warrant that this is the only information available or the only information that should be considered when deciding to implement an electronic payment processing solution.

Fiserv shall not be held liable for any losses caused by reliance on the accuracy, reliability or timeliness of this information. Portions of such information may not be useful or applicable to an entity's particular circumstance.

Any person or entity that relies on any information obtained from this Guide does so at his or her own risk.

Revision History Fiserv

<Merchant Integration Guide> FISERV CONFIDENTIAL 8

Revision History

Date PayPoint Version

Section Integration Guide Update Description

01/24/2021 21.01.24 The guide was reviewed and there are no updates from the

21.01.24 Release.

02/14/2021 21.02.14 The guide was reviewed and there are no updates from the

21.02.14 Release.

8/15/2021 21.08.15 2.0 Implementation Approach

The Secure Sockets Layer (SSL) has been changed from 128- to 256-bit encryption.

8/15/2021 21.08.15 3.0 Integration and Development Secure HTTP Integration

The secure Web interface (HTTPS) has been changed from 128- to 256-bit encryption.

The description of input parameter m, Return Mode, has been updated.

10/10/2021 21.10.10 The guide was reviewed and there are no updates from the

21.10.10 Release

1/9/2022 22.01.09 The guide was reviewed and there are no updates from the

22.01.09 Release

3/6/2022 22.03.06 The guide was reviewed and there are no updates from the

22.03.06 Release

5/8/2022 22/05/08 The guide was reviewed and there are no updates from the

22.05.08 Release

1.0 Introduction Fiserv

<Merchant Integration Guide> FISERV CONFIDENTIAL 9 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

1.0 Introduction

PayPoint, a product of First Data, facilitates electronic commerce by enabling governmental entities to accept credit card, pin-less debit card and ACH/EFT payments for goods and services. PayPoint is designed as an enterprise-wide payment system. This provides the flexibility to setup the organizational, administrative and reporting structure for any size entity. The service can easily scale to handle both small and large-scale transaction volume. Our standard API interface can easily connect a business application to the financial institutions and payment networks that authorize and settle electronic payments. PayPoint’s administrative features and functionality enable consistent management and reporting on electronic payment activity across the enterprise, regardless of electronic payment type, through a common user interface.

Feature Description

Enterprise Approach PayPoint is built to support enterprises with multiple sub-entities that need payment processing capabilities. Our enterprise approach allows financial administrators to delegate online line access reporting and payment history research to any level within the enterprise including the ability to perform reporting across the entire enterprise.

Online Reporting PayPoint provides the ability to produce on demand summary as well as detailed reports.

Online Payment Inquiry PayPoint provides dynamic payment search options for viewing payment history. Payments can be searched by dates, amounts and last 4 digits of an account, name, status, custom references and more.

Payment Administrators are able to view all details associated with payments including history of activity associated with payments.

Settlement Management PayPoint provides a unique ability to monitor settlement activity and perform reconciliation checks through online inquiry and reporting options.

Multi-Processor Credit Card Support PayPoint supports most major Credit Card processors including:

First Data BuyPass, First Data Nashville (Envoy), First Data North (CardNet), First Data South (Nabanco), Vital (including TSYS) and PaymentTech.

Fraud Detection Fraud detection services for both Credit Card and eCheck.

eCheck – Positive/Negative risk rating, Account and Bank Routing Validation, User Transaction Limits, Identity Verification and duplicate payment detection.

Credit Card – Address Verification, CVV2, Transaction Limits and duplicate payment detection.

Application Programming Interface (API) PayPoint provides a set of open standard API interfaces for integrating payment processing into any environment. Our Web Service based API can be utilized by most all platforms. This support allows for multi-channel access through Web, IVR, PC, Kiosk and so on PayPoint also offers a Batch Processing API through a standard XML API request and response files for offline payment commands such as issuing payments in bulk.

Multiple Payment Options (Credit Card , eCheck, PINless Debit, PIN based Debit)

Support for eCheck, Credit Card and PINless Debit Payments. Includes the ability to issue and manage initial payments, refunds, charge-backs, returns, voids non-sufficient funds and notice of change.

<Merchant Integration Guide> FISERV CONFIDENTIAL 10 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Feature Description

Registered and Unregistered Payments PayPoint registration option allows integrators to register consumer payment information with PayPoint limiting security risk and repeat consumer payments easy.

Recurring Payments PayPoint provides the ability to establish recurring payment schedules.

Once establish PayPoint will execute payments on defined schedule and provide Email confirmation of any authorization issues.

Convenience Fees PayPoint can automatically calculate and collect convenience fees on a per payment basis.

Custom Reference Management Payments include the ability to assign a custom identifier linking the PayPoint payment to your transactions. For example, if your application is accepting payments for parking tickets, the ticket number could be placed in our Custom Reference. When researching payments this Custom Reference can be used in locating payments.

eCheck Payment Warehousing Payments can be postdated up to 365 days. PayPoint manages payment execution based on the payment date provided.

Third-party Payments Reporting PayPoint accepts payment data relating to payments authorized, collected and/or settled through a separate system. The third-party payment mediums supported are ACH Credit, POS, Cash, Remote Capture and Lockbox. This provides an enterprise approach to payment management, customer service and reconciliation. Even though these third-party payments are not settled within PayPoint, they are available to all other services of PayPoint payment management including payment searching, reporting and are exported in the posting file along with other PayPoint payment transactions.

Secure Processing PayPoint is built on a highly secure infrastructure including; End to End encryption of communications, C2 Level Secure Data Centers, Data Security including encrypted storage of sensitive information and Roles Based security access to payment management and reporting features.

The PayPoint Integration Guide describes the phased approach to integrating a business application to our standard Application Program Interface (API). PayPoint can be integrated to business applications on a variety of platforms including Web sites, e-stores, Interactive Voice Response (IVR) systems, POS devices and Kiosks. The API offers a programmable interface that is platform independent. Batch Processing is also offered. With Batch Processing you have the ability to execute payments and/or any other PayPoint API calls offline through a batch interface provided with PayPoint. Integrators can create an XML file with payment instructions to be executed by PayPoint. The XML file includes the ability to do any of the existing Real-Time API functions including Make Payment, Cancel Payments, Payment Inquiry, Registration CRD, Registration Inquiry, Recurring Payment CRD and Recurring Payment Inquiry. The XML file must adhere to the standards defined in our PayPoint Integration Guide.

While PayPoint can process many types of electronic payments, it is especially useful for processing non face-to-face payment transactions where the merchant and their customer are not in the same physical location. For a government entity, this allows interaction with citizens or businesses through a web/portal application or an IVR system. The business application transmits payment information for the transaction to PayPoint. PayPoint secures an authorization and then returns a response to the business application for further processing. The business application communicates the success or failure of an authorization request to their customer. PayPoint can support both registered and unregistered payees.

<Merchant Integration Guide> FISERV CONFIDENTIAL 11 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

For credit card payments, PayPoint can perform real-time credit card authorization with all the major processors. PayPoint can accept payments made with numerous types of credit cards, including Visa®, Mastercard®, Discover®, American Express® and other specialty cards such as Diners Club. PayPoint can also accept payments made with debit cards displaying a Visa or Mastercard logo. PayPoint’s daily batch settlement will process all authorizations processed and accepted during a given day.

For PINless Debit, PayPoint can perform real-time authorizations through the STAR®, PULSE or NYCE networks. PINless debit is an online payment process which requires no settlement processing within PayPoint.

For PIN- based Debit, PayPoint can perform real-time authorizations. PIN-base debit is an online payment process which requires no settlement processing within PayPoint.

PayPoint supports electronic check (eCheck) transactions. eCheck allows a government entity to accept payments from personal or business bank accounts online. The business application collects a bank account number and bank routing number from the payee to fund the electronic payment. eCheck authorization services range from checking the validity of the account information to other value added services including identity verification and guaranteed check processing. PayPoint originates ACH transactions through the government entity’s chosen clearing account for all eCheck payments authorized.

The intended audience for this integration guide includes project managers, programmer analysts and testers.

It explains in detail how electronic payments transactions are submitted to PayPoint for processing.

Purpose This Integration Guide describes a Phased Approach to integrating electronic payment functionality into a new or existing business application. This guide has a prescribed list of implementation and deployment tasks and activities, best practice information, as well as technical options and detailed programming specifications for easy integration. The detailed programming specifications describe how to create the necessary environment for integrating with PayPoint.

The intent of this guide is not to recommend how to code a web site or system interface. This guide presents the various technical options offered for integration with PayPoint.

Key Assumptions

• The government or commercial entity has the ability to build a real-time interface for presentment of payments regardless of the platform

• The resources performing the development of the integration with PayPoint have a working knowledge of the business application development (programming) environment

• The government or commercial entity has a bank or financial institution and, if offering credit card payments, a merchant services agreement

Best Practices These Best Practices are a courtesy to our clients. They are based on industry best practices and practical experience. You should find useful the information in the table as you begin to design and develop the interface to PayPoint. Please be sure to contact your Project Manager or implementation support team for additional suggestions.

<Merchant Integration Guide> FISERV CONFIDENTIAL 12 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Best Practice Description

Descriptive entity name Ensure the name selected on the Account Application to be displayed on the payee’s statement contains a descriptive name. A descriptive name helps eliminate confusion regarding the entity receiving the payment.

Payment Amount Validation If possible, add an amount validation on the payment amount entered by your customers.

This will minimize payment processing errors and associated fees and facilitate timely accurate deposits.

Always use AVS (Address Verification System)

When accepting credit cards, you should incorporate an appropriate level of fraud prevention techniques. AVS is a feature that verifies the cardholder's address and zip code at the time of payment authorization. The issuing bank verifies that the address entered by the cardholder matches the address they have on record. AVS has become an expected minimum level of fraud prevention. Eliminating AVS will nearly always result in higher interchange rates.

Electronic Payment Policies Educate your customers. Make sure your electronic payment policy is available and accessible by your customer. Do not bury these policies deep within your web site or portal. Be open and up front.

Single Point of contact for Customer Service

If possible, set up a single point of contact. Make sure your customers know how to contact customer service and when customer service is available. Display the phone numbers and email addresses in prominent positions on all web pages. Be available for customers with questions about their payments. If you choose to outsource first line customer service, speak with your Project Manager. We offer a fully staffed customer service center around the clock which can support a fully outsourced operation or after-hour support for your own customer service organization.

Fraud prevention using C V V 2 and/or C V C 2

If possible, incorporate advanced fraud prevention techniques. The CVV2/CVC2 is a code printed on the back of a Visa or Mastercard credit card. This service helps validate that a genuine card is being used during a non face-to-face payment transaction.

PayPoint can validate the CVV2/CVC2 and return the results to the business application.

The benefit of implementing this service is a possible reduction in fraud-related chargebacks.

Disaster Recovery/Business Continuity Planning

We recognize that service disruptions can greatly impact your business. For that reason, we continue to invest in redundant, fault-tolerant systems to minimize service disruptions.

Unfortunately, bank processors sometimes experience outages that are entirely out of our control. When these disruptions occur, they can hamper your ability to complete sales in a timely fashion. To ensure a minimum of disruption to your business, we recommend only using processors that offer the same high-level of service availability as PayPoint.

2.0 Implementation Approach Fiserv

<Merchant Integration Guide> FISERV CONFIDENTIAL 13 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

2.0 Implementation Approach

Overview The following is a summary of the implementation tasks required to ensure a successful PayPoint implementation. Be sure to review the Implementation task detail section for more information about each task, as well as access to links to additional technical documentation.

Phase 1: Account Registration. Set up a PayPoint account. Request a PayPoint Application (Account) Identifier (ID) by filling out the PayPoint Account Application Form. We will provide a unique Application Identifier and your own unique User ID and password. The ID and Password will allow your administrative users to securely access the administrative interface and manage payment transactions for your business applications.

Phase 2: Application Program Interface Design and Development. Construct an interface to PayPoint using the API specifications (For example web service and so on). After receiving an account, you can complete the design and development of your interface to PayPoint. The PayPoint API supports Web Service integration utilizing SOAP (Simple Object Access Protocol).

Phase 3: Test Mode. Test the interface between your business application and PayPoint. Once you have an active account, the account will be placed in Test Mode. In Test Mode, we will provide you with basic guidance on how to verify that your business application can initiate payment transactions through the API. We encourage our clients to formulate and process as many test scenarios as possible. This phase will demonstrate that the business application can interact successfully with PayPoint.

Phase 4: Certification Mode and Training. We require certification of your business application before activating your PayPoint account for production use. Upon successful completion of the Phase 3 testing, we place your account into Certification Mode. Certification involves testing a set of payment transactions and validating the results. You will execute the certification transactions associated with the payment methods you have selected (That is Credit Card, eCheck or both).

We verify and validate the certification test results before activating your PayPoint account.

During this phase, your operational personnel are introduced to the features of PayPoint. Your staff will learn about PayPoint, including the Administration, Search and Report modules. This training assists your personnel with successfully managing payment transactions.

Phase 5: Production Mode. We have specific requirements for activating PayPoint accounts. It is important to review and understand the certification detailed in the Certification Checklist to ensure that your business application is deployed in a timely manner. Once we have certified your application, we mutually agree upon a schedule for placing the PayPoint account into Production Mode for live payment processing.

<Merchant Integration Guide> FISERV CONFIDENTIAL 14

Pre-Implementation Preparation The first step in building an interface to PayPoint is to become familiar with common electronic payment terms, payment processing (external) entities, basic electronic payment functions and the specific banking and/or merchant services contract.

Payment Processing (External) Entities A number of external entities may participate in the electronic payment process. They include all organizations that take part in the initiation, authorization origination and/or settlement of electronic payment transactions. See the table at right for the common external entities referenced in this guide. You should become familiar these terms in preparation for implementation.

Banking/Merchant Services Contract The agreement between you and your banking and/or merchant services provider is very important to the proper setup and configuration of PayPoint. PayPoint is flexible enough to accommodate most types of agreements. In some cases, the configuration of PayPoint can have an impact on your banking or merchant services fees.

Policy and Procedures for Electronic Payments It is important to have well defined electronic payment policies and procedures regarding accepting credit card, debit card and electronic check transactions over the Internet or from other input channels. These policies and procedures should define the operating guidelines related to electronic payments at the enterprise, work group or agency and business application level. The Electronic Payment Policy should provide the structure for assigning responsibility and authority for controlling the configuration and usage of PayPoint.

Phase 1: Account Registration

PayPoint Account The first step in obtaining a PayPoint account is to complete the “PayPoint Account Application Form” (See Appendix A). We then establish a unique PayPoint Application (Account) ID. Our PayPoint project manager will provide you an electronic copy of the form prior to the implementation project. To successfully complete the form, you will need access to banking and/or merchant services provider information. Complete the form and return it to the PayPoint project manager or Client Relationship Representative. We process the completed form and activate your new account. The sooner the form is completed and verified, the quicker we can activate your account.

External Entity

Acquiring (Merchant) Bank: An entity must establish a merchant account with an Acquiring Bank, before accepting credit card payments. The merchant account must be configured to process card-not-present transactions.

Issuing (Consumer) Banks: An Issuing Bank grants credit to a consumer and provides (issues) a credit card.

Some cards may be co-branded, with the Issuing Bank, by another (non-bank) organization.

Credit Card Association: Credit card associations manage the interchange between acquiring banks and issuing banks. They also develop industry standards, market their brands and establish fees for acquiring merchants.

Payment (Acquiring) Processor: Payment processors process electronic transactions through the payment network for authorization, clearing and settlement on behalf of the Acquiring Bank.

PayPoint: Centralized electronic payment engine used by business applications to request authorization and settlement of funds for payments by either credit/debit card or electronic check. It provides a standard interface and consolidated processing environment.

PayPoint Account: An authorized Application ID on PayPoint for accepting credit cards and/or electronic checks for all types of payments to government entities.

<Merchant Integration Guide> FISERV CONFIDENTIAL 15 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

It takes approximately 5 – 10 business days to process an application from the time of receipt. Once the application is processed, we issue a unique Application (Account) ID number. This number identifies your account to PayPoint. PayPoint can then accept and process payment transactions originating from a business application using the Application ID. The PayPoint project manager coordinates and facilitates the account registration process and provides all the key values created specifically for your application (For example Account ID, Security Key and so on).

Credit Card/Debit Card Payments For Credit/Debit Card payments, a Merchant Account is required.

A Merchant Account is necessary to accept online credit card/debit card payments. Your merchant account number is used by PayPoint to identify all your credit card related electronic payment transactions. A merchant account establishes a relationship with a Merchant Bank (or its Processor) authorized to settle credit card payments through a card association interchange.

The terms and conditions of your Merchant Account are between you and your bank or merchant service provider. You should allow three to four weeks to establish your merchant account if you don’t have an existing account. If you plan to use an existing account, you may be required to contact your Merchant Bank to inform them about accepting payments through the PayPoint payment engine. The Merchant Account must allow Card Not Present transactions.

eCheck Payments For eCheck payments, a Bank Account is required.

To accept eCheck payments, you are required to establish a bank account with a financial institution before filling out the PayPoint Account Application form. The bank account number and routing number are used by PayPoint to process all ACH related electronic payment transactions.

PINless Debit Payments For PINless Debit payments, a Bank Account is required.

If you’re interested in implementing a PINless debit option, please contact our Customer Service.

PIN-Based Debit Payments For PIN-based debit payments, a Bank Account is required.

If you’re interested in implementing a PIN-based debit option, please contact our Customer Service.

Phase 2: Application Program Interface Design and Development PayPoint has a standard Application Programming Interface (API), which supports three methods for processing transactions. The three methods are Web Services, Secure HTTP and Batch. Technical details of each method can be found within this section. All real-time PayPoint API’s interactions are performed using Secure Sockets Layer (SSL) 256-bit encryption.

<Merchant Integration Guide> FISERV CONFIDENTIAL 16 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

PayPoint has a standard set of payment functions, regardless of the type of API integration method selected.

The following table describes the payment functions available in this release. The specifications for the inputs and outputs can be found later in this document.

Function Description

MakePayment This function initiates a payment transaction. Inputs to this function include Payment Amount, Account Number (Credit Card, Checking) and other information required to authorize a payment. The function responds with a return code identifying the status of the payment and a unique confirmation number associated with the payment transaction in PayPoint.

PinlessDebitCheck This function identifies if am account is eligible for PINless debit or is a signature debit card account. Signature Debit is when a credit association-branded debit card may be processed as debit or credit.

CalculateConvenienceFee This function calculates a convenience fee for a given payment amount. This function can be used by your business application to present the payer with the convenience fee prior to submitting the payment transaction for authorization.

CancelPayment This function voids or refunds a payment previously authorized by the ‘Make Payment’ function.

PaymentStatus This function returns the status of an existing payment.

RegistrationCRD This function enables ay business application to register a payer’s financial account (either bank account or credit/debit card). PayPoint securely stores the financial account information, eliminating the security risk associated with storing sensitive financial data in multiple locations. PayPoint allows an application to manage account data without needing to store the data. This function provides a unique Registration ID for inquiring on, updating or deleting the registered account information.

RegistrationInquiry This function allows a business application to request registration data stored in PayPoint. For example, a web application may request registration information through this inquiry and present it to the user for confirmation and/or update of their financial account information.

RegistrationLookup This function allows a business application to retrieve one or more registrations using a reference lookup field.

RecurringPaymentCD This function allows a business application to create a schedule of automatically recurring payment requests. In order to establish a Recurring Payment, the payer must have a registered account. This function allows an application to add (create) or delete a recurring payment schedule.

RecurringPaymentInquiry This function allows a business application to request recurring payment details (For example, schedule)

Web Services API The PayPoint Web Service API enables a business application to access the electronic payment services using XML and SOAP (Simple Object Access Protocol) standards for sending messages using the Internet

Business applications can call on a PayPoint WSDL (Web Service Description Language) document, which presents the functionality exposed by the Web Service. This standard integration method enables existing applications (That is Web, IVR, Desktop applications and so on) to integrate with PayPoint to manage payment processing. The advantage of this method is that it allows your technical staff (That is developers, programmers and so on) to develop in their preferred programming language including Java, Perl or Visual Studio.

<Merchant Integration Guide> FISERV CONFIDENTIAL 17 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Your technical resources responsible for PayPoint integration need a working knowledge of Web Services, SOAP and XML, as well as an understanding of how to integrate data into an application or Web site. In addition, the technical staff performing integration must have all required software to support web services already installed in a development environment and be proficient in their preferred programming language.

Secure HTTP API PayPoint allows access to its web service methods through an alternative interface API known as the “Secure HTTP API.” It uses secure HTTP (HTTPS) to communicate between the business application and PayPoint.

The Secure HTTP API interface accepts two types of inputs and can return two types of output. The business application may send data to the interface either through the query string or as FORM POST data. Depending on the application request, the API returns its results either through the query string or as the HTTP GET results of the application’s query.

Batch API The PayPoint batch interface allows a business application to initiate and access payment transactions in an off-line mode. The application accumulates a number of payment transaction requests (a batch) in a single file, uploads them to PayPoint for processing and then receives a results file.

Retrieve Payment API Consult with your PayPoint Implementation Advisor for assistance with the Retrieve Payment API.

Phase 3: Test Mode During Test Mode, you will test the technical interface between your business application and PayPoint to ensure you can execute each PayPoint function. A limited set of scripted test cases is defined in this section.

These test cases will ensure the business application can successfully connect to and communicate with the service. It is very important to extensively test the interaction between the business application and PayPoint before entering Certification mode.

You can begin Phase 3 testing after your PayPoint Project Manager has assigned a PayPoint Application ID.

Our support staff will provide the necessary information to get started. In test mode, use the test data (For example credit card #, expiration date, confirmation # and so on) for each test case. Do not deviate from the test data found in the table. Unpredictable results may occur if you deviate from the scripted test cases.

These test transactions will simulate the production system. It is intended as quick and easy way to allow your development team to test the system interface to PayPoint and ensure each function can be initiated and the results processed. All test transactions will appear to be processed as real transactions. Test transactions will not be authorized by your card processor or reach the bank for settlement. PayPoint will simulate the interaction with a card processor or ODFI. In addition, the test transactions are not stored in PayPoint and therefore will not be displayed in reports and/or by the administrative screens.

After you successfully verify and validate all test transactions, you may request a change to Certification Mode.

The PayPoint Project Manager or Support Group updates your account status from Test mode to Certification mode. The following information provides details on each test case. If you have any questions, please contact your PayPoint Project Manager.

<Merchant Integration Guide> FISERV CONFIDENTIAL 18 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Function: MakePayment Test Cases The Make Payment function is used to initiate a payment. The test cases in the following table test the interface between your business application and PayPoint. You are required to insert the required data values for each object, including information like Card Number, Expiration Date, Payment Amount and other data required to authorize a payment. For example, the Header Object is a required object for each Make Payment request. The Header object contains important information such as the Application ID and Security Key, specifically assigned to your application.

This function will provide a return code through the response object member. The Return Code gives the status of the transaction. The ReturnCode value is either a sting or integer based on the type of interface you select. If you deploy a Web Service interface, the return code will be a string value. If you deploy a Web HTTP (Form POP or Query String) interface, the return code will be an integer value. Your PayPoint Project Manager is prepared to answer any questions you may have.

To successfully execute these test cases through PayPoint, the application’s PayPoint account set up must be complete.

Test 1. Process a Successful Credit Card Transaction.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

CardNumber 1890886512515590 1890886512515590

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value Result Message <Blank> <Blank>

ReturnCode Payment_Success 2

Total Amount <amount requested> <amount requested>

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate Date when the payment will be submitted Date when the payment will be submitted

<Merchant Integration Guide> FISERV CONFIDENTIAL 19 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Field Name WebServices or Batch Value HTTPS Value for settlement. for settlement.

Test 2. Process a Credit Card Transaction That Generates a Technical Difficulty Error Message.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

CardNumber 1890886512515591 1890886512515591

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message Error in Payment Gateway, unable to process request.

Error in Payment Gateway, unable to process request.

ReturnCode Error 4

Total Amount 0 0

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate 1/1/0001 1/1/0001

Test 3. Process a Credit Card Transaction That Generates a Communication Error.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

<Merchant Integration Guide> FISERV CONFIDENTIAL 20 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message Error in Payment Gateway, unable to process request.

Error in Payment Gateway, unable to process request.

ReturnCode Communication_Error 7

Total Amount 0 0

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate 1/1/0001 1/1/0001

Test 4. Process a Credit Card Transaction That Generates an Authorization Declined Response.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

CardNumber 1890886512515593 1890886512515593

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

CardNumber 1890886512515592 1890886512515592

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

<Merchant Integration Guide> FISERV CONFIDENTIAL 21 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Field Name WebServices or Batch Value HTTPS Value

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message Declined Declined

ReturnCode Declined 5

Total Amount 0 0

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate 1/1/0001 1/1/0001

Test 5. Process a Credit Card Transaction that Generates an Authentication Fails Error Message – This Message is for Those Customers Using AVS, CVV2 or Other Fraud Detection Schemes.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

CardNumber 1890886512515594 1890886512515594

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

CVV2 Code Any Three or Four Digit Number Any Three or Four Digit Number

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

<Merchant Integration Guide> FISERV CONFIDENTIAL 22 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Field Name WebServices or Batch Value HTTPS Value

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message Verification_Failed Verification_Failed

ReturnCode Verification_Failed 6

Total Amount 0 0

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate 1/1/0001 1/1/0001

Test 6. Process a Credit Card Transaction That Generates an Invalid Card Type Error Message.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount 123.45 123.45

CardNumber 1890886512515595 1890886512515595

CardStatusFlag Any Valid CardStatus Flag Any Valid CardStatus Flag

ExpirationDate* Any Future Two-digit Month and Two-digit Year

Any Future Two-digit Month and Two-digit Year

ExpirationMonth* Any Future Two-digit Month Any Future Two-digit Month

ExpirationYear* Any Future Two-digit Year Any Future Two-digit Year

PaymentMedium CreditCard 2

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass

*(Expiration Month and Expiration Year) or Expiration Date may be entered.

<Merchant Integration Guide> FISERV CONFIDENTIAL 23

Response Object Members:

Result Message This application does not allow payments to be made using your type of card. Please select another card and retry.

This application does not allow payments to be made using your type of card. Please select another card and retry.

ReturnCode Unaccepted_Card_Type 13

Total Amount 0 0

Confirmation Number <blank> <blank>

SettlementSubmissionDate 1/1/0001 1/1/0001

Test 7. Process an eCheck Transaction That Generates Successful eCheck Payment.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

AccountType Any Valid Account Type Any Valid Account Type

BankAccountNumber 8745720 8745720

BankRoutingNumber 123123123 123123123

AuthorizationMedium Any Valid Authorization Medium Any Valid Authorization Medium

PaymentMedium eCheck 1

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message blank blank

ReturnCode Payment_Success 2

<Merchant Integration Guide> FISERV CONFIDENTIAL 24 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Field Name WebServices or Batch Value HTTPS Value

Total Amount <amount requested> <amount requested>

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate Date when the payment will be submitted for settlement.

Date when the payment will be submitted for settlement.

Test 8. Process an eCheck Transaction That Generates a Technical Difficulty Error Message.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid Amount Greater Than Zero

NameFirst Any Valid First Name Any Valid First Name

NameLast Any Valid Last Name Any Valid Last Name

AccountType Any Valid Account Type Any Valid Account Type

BankAccountNumber 8745721 8745721

BankRoutingNumber 123123123 123123123

AuthorizationMedium Any Valid Authorization Medium Any Valid Authorization Medium

PaymentMedium eCheck 1

All other fields Optional, but if provided must pass validation rules

Optional, but if provided must pass validation rules

Response Object Members:

Field Name WebServices or Batch Value HTTPS Value

Result Message Unable to process Payment Gateway request: (TEST MODE) Error in Payment Gateway while processing the requested transaction.

Unable to process Payment Gateway request: (TEST MODE) Error in Payment Gateway while processing the requested transaction.

ReturnCode Error 4

Total Amount 0 0

Confirmation Number <confirmation num> <confirmation num>

SettlementSubmissionDate 1/1/0001 1/1/0001

<Merchant Integration Guide> FISERV CONFIDENTIAL 25 May 8, 2022 22.05.08 Distribution restricted to clients of Fiserv

Test 9. Process an eCheck Transaction That Generates a Communications Error Message.

Request Object Members:

Field Name WebServices or Batch Value HTTPS Value

ApplicationID Valid Application ID Valid Application ID

PaymentChannel Any Valid Payment Channel Any Valid Payment Channel

SecurityKey Valid Security Key Valid Security Key

PaymentAmount Valid Amount Greater Than Zero Valid…