Introduction

Welcome to 4D Payments SDK, the ultimate suite of components for integrating direct Internet payment processing into applications. The 4D Payments SDK combines the 4D Payments Integrators for FDMS, TSYS, Paymentech, and Global Payments into one comprehensive package for direct payment processing.

Included Classes

CardValidator	The CardValidator component is used to verify that a given credit card number is formatted properly, and could be a valid card number. Validating a card before actually submitting a transaction for authorization can reduce the fees that may be associated with invalid or declined transactions.
CertMgr	The CertMgr component is used to create, read, and manage certificates.
EMVKeyMgr	The EMVKeyMgr component simplifies the process of downloading EMV public keys for FDMS Rapid Connect and Paymentech.
FDMSBenefit	The FDMSBenefit component is used to authorize Electronic Benefits Transfer (EBT) transactions with the FDMS system on the North platform. An EBT transaction is similar to a Debit transaction, using a PIN and KSN, but is used for Food Stamp or Cash Benefit programs. This component allows for simple, direct, secure communication to the First Data platform through a standard Internet connection.
FDMSDebit	The FDMSDebit component is an advanced tool used to authorize debit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing debit card transactions with a customer PIN very easy.
FDMSDetailRecord	The FDMSDetailRecord component is a tool used to create off-line Credit or Force transactions to be settled by the FDMSSETTLE component. The FDMSDetailRecord component may also be used to modify the XML aggregates returned by the FDMSRETAIL or FDMSECOMMERCE component's GetDetailAggregate method.
FDMSECommerce	The FDMSECommerce component is an advanced tool used to authorize credit cards in both Mail Order (Direct Marketing) and eCommerce environments, where the customer is ordering products or services via the telephone or Internet. This component makes authorizing these types of transactions very easy.
FDMSGiftCard	The FDMSGiftCard component is used to manipulate funds on Stored Value (Gift) Cards with the FDMS Closed Loop Gift Card System. This component supports both card-present and card-not-present gift card transactions, and allows for simple, direct, secure communication to the Datawire gateway to FDMS through a standard Internet connection. This component can be integrated into web pages or stand- alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
FDMSHealthCare	The FDMSHealthCare component is an advanced tool used to authorize FSA cards for healthcare transactions in either a retail or e-commerce/moto environment. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores, direct marketing (e-commerce and mail order/phone order) and grocery or food stores.
FDMSHotel	The FDMSHotel component is an advanced tool used to authorize credit cards in a retail environment, where the customer is purchasing products or services in person. This component makes authorizing these types of transactions very easy.
FDMSLevel2	The FDMSLevel2 component is a tool used to create Level2 Corporate Purchasing Card addendum aggregates, which can then be passed to the FDMSSETTLE component and settled.
FDMSLevel3	The FDMSLevel3 component is a tool used to create Level 3 Corporate Purchasing Card addendum aggregates, which can then be passed to the FDMSSETTLE component and settled.
FDMSOmahaBatchMgr	The FDMSOmahaBatchMgr component is used to close batches and also handles the sending of all offline transactions to the FDMS Host.
FDMSOmahaDetailRecord	The FDMSOmahaDetailRecord component is a tool used to create off-line transactions (Captures, Refunds, Revisions, and Voids) to be settled by the FDMSOmahaBatchMgr component.
FDMSOmahaECommerce	The FDMSOmahaECommerce component is used to perform Credit card transactions in both Mail Order (Direct Marketing) and eCommerce environments, where the customer is ordering products or services via the telephone or Internet.
FDMSOmahaRestaurant	The FDMSOmahaRestaurant component is used to perform Credit, Debit, or EBT card transactions in a Restaurant environment, where the customer is purchasing products or services in a restaurant.
FDMSOmahaRetail	The FDMSOmahaRetail component is used to perform Credit, Debit, or EBT card transactions in a Retail environment, where the customer is purchasing products or services in person.
FDMSRcBenefit	The FDMSRcBenefit component is used to authorize Electronic Benefits Transfer (EBT) transactions. An EBT transaction is similar to a Debit transaction, using a PIN and KSN, but is used for Food Stamp, Cash Benefit or eWIC programs. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores and grocery or food stores.
FDMSRcDebit	The FDMSRcDebit component is an advanced tool used to authorize debit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing debit card transactions with a customer PIN very easy.
FDMSRcDetailRecord	The FDMSRcDetailRecord component is a tool used to create off-line Refund or Force/VoiceApproved transactions to be settled by the FDMSRcSettle component. The FDMSRcDetailRecord component may also be used to modify the XML aggregates returned by the FDMSRcRetail or FDMSRcECommerce component's GetDetailAggregate method.
FDMSRcECommerce	The FDMSRcECommerce component is an advanced tool used to authorize credit cards in both Mail Order (Direct Marketing) and eCommerce environments, where the customer is ordering products or services via the telephone or Internet. This component makes authorizing these types of transactions very easy.
FDMSRcHealthCare	The FDMSRcHealthCare component is an advanced tool used to authorize FSA/HSA cards for healthcare transactions in either a retail or e-commerce/moto environment. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores, direct marketing (e-commerce and mail order/phone order) and grocery or food stores.
FDMSRcRetail	The FDMSRcRetail component is an advanced tool used to authorize credit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores and restaurants.
FDMSRcSettle	The FDMSRcSettle component is used to do a Batch Settlement on all transactions that were successfully authorized with the FDMSRcECommerce or FDMSRcRetail components.
FDMSRegister	The FDMSRegister component is a tool used to Register and Activate a merchant account with the Datawire VXN. This allows you to send transactions through the Datawire system to the First Data Merchant Services (FDMS) processor. This component is also used to find the appropriate URLs to which authorizations and settlements will be posted.
FDMSRetail	The FDMSRetail component is an advanced tool used to authorize credit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores, restaurants, and grocery or food stores.
FDMSReversal	The FDMSREVERSAL component is used to reverse a transaction that was previously authorized using the FDMSRETAIL , FDMSECOMMERCE , or FDMSHEALTHCARE component. This immediately releases the funds in the cardholder's open-to-buy that were blocked by the original authorization.
FDMSSettle	The FDMSSettle component is used to do a Batch Settlement on all transactions that were successfully authorized with the FDMSECOMMERCE or FDMSRETAIL components. This component may also send Level 2 and Level 3 Corporate Purchasing Card data for better interchange rates.
GlobalBatchMgr	The GlobalBatchMgr component is used to manage your Global Transport account. It can be used to check the connection to the Server , verify your merchant setup, retrieve a summary of transactions in the current batch, and capture (settle) the current batch.
GlobalBenefit	The GlobalBenefit component is used to authorize Electronic Benefits Transfer (EBT) transactions with the Global Payments system, using the Global Transport Direct API. This component is supported in the Retail and Restaurant environments, and allows for simple, direct, secure communication to the Global Transport gateway through a standard Internet connection. An EBT transaction is similar to a Debit transaction, using a PIN and Key Sequence Number (KSN), but is used for Food Stamp or Cash Benefit programs.
GlobalCardValidator	The GlobalCardValidator component is used to verify with Global Payments that a given card number is formatted properly, and could be a valid card number. Validating a card before actually submitting a transaction for authorization can reduce the fees that may be associated with invalid or declined transactions.
GlobalCharge	The GlobalCharge component is used to authorize credit card transactions with the Global Payments system, using the Global Transport Direct API. This component supports Direct Marketing, e-Commerce, Retail, and Restaurant environments, and allows for simple, direct, secure communication to the Global Transport TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
GlobalDebit	The GlobalDebit component is used to authorize debit card transactions with the Global Payments system, using the Global Transport Direct API. This component is supported in the Retail and Restaurant environments, and allows for simple, direct, secure communication to the Global Transport gateway through a standard Internet connection. This component can be integrated into Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application can be deployed without the need for expensive dedicated TLS/SSL servers.
GlobalTransactionSearch	The GlobalTransactionSearch component is used to search for transactions made using the Global Transport Direct API. It can search for transactions in the open batch or in any previously closed batch.
PTechBenefit	The PTechBenefit component is used to authorize Electronic Benefits Transfer (EBT) transactions with the Paymentech NetConnect system on the Tampa platform. An EBT transaction is similar to a Debit transaction, using a PIN and Trace number, but is used for Food Stamp or Cash Benefit programs. This component allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection.
PTechCanadianDebit	The PTechCanadianDebit component is used to authorize face-to-face Interac (Canadian) debit card transactions with the Paymentech NetConnect system on the Tampa platform. This component allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechCharge	The PTechCharge component is used to authorize credit card transactions with the Paymentech NetConnect system on the Tampa platform. This component supports Direct Marketing, e-Commerce, and Retail environments, and allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechDebit	The PTECHDEBIT component is used to complete debit card transactions with the Paymentech NetConnect system on the Tampa platform. This component supports only Retail, Restaurant, and Hotel environments, and allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechDetailRecord	The PTechDetailRecord component is a tool used to create off-line Credit or Force transactions to be settled by the PTECHMANUALSETTLE component. The PTDetailRecord component may also be used to modify the XML aggregates returned by the PTECHCHARGE component's GetDetailAggregate method.
PTechECommerce	The PTECHECOMMERCE component is an advanced tool used to authorize credit card transactions in both Direct Marketing and E-Commerce environments with the Paymentech NetConnect system on the Tampa platform. It allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechGiftCard	The PTechGiftCard component is used to manipulate funds on Stored Value (Gift) Cards with the Paymentech NetConnect system on the Tampa platform. This component supports card-present gift card transactions, and allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand- alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechHealthCare	The PTECHHEALTHCARE component is designed to be a simple interface for those wishing to add Healthcare Auto- Substantiation (IIAS) support without redesigning their entire payment system. This component can be used for the Retail, Direct Marketing, and E-Commerce IndustryType s. It allows for simple, direct, secure communication to the Paymentech NetConnect (Tampa platform) TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechHostSettle	The PTechHostSettle component is used to manually settle an open Batch with the Paymentech NetConnect system on the Tampa platform. This component supports Direct Marketing, e-Commerce, and Retail environments, and allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechHotel	The PTECHHOTEL component is used to authorize credit card transactions for the Hotel IndustryType with the Paymentech NetConnect system on the Tampa platform. This component creates a simple interface for processing transactions in the Hotel environment. It allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechManualSettle	The PTechManualSettle component is used to do a Batch Settlement on all transactions that were successfully authorized with the PTECHCHARGE component in Terminal Capture mode.
PTechRetail	The PTECHRETAIL component is used to authorize face-to-face credit card transactions with the Paymentech NetConnect system on the Tampa platform. This component creates a simple interface for processing transactions in the Retail and Restaurant environments. It allows for simple, direct, secure communication to the Paymentech TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand-alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
PTechReversal	The PTECHREVERSAL component is used to reverse a transaction that was previously authorized with the Paymentech NetConnect system on the Tampa platform. This immediately releases the funds in the cardholder's open-to-buy that were blocked by the original authorization.
TSYSBenefit	The TSYSBenefit component is an advanced tool used to authorize Electronic Benefits (EBT) cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing EBT Food Stamp and Cash Benefit transactions (with a customer PIN) very easy. Supported Industry Types include retail stores, restaurants, and grocery stores.
TSYSDebit	The TSYSDebit component is an advanced tool used to authorize debit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing debit card transactions with a customer PIN very easy. Supported Industry Types include retail stores, restaurants, and grocery stores.
TSYSDetailRecord	The TSYSDetailRecord component is a tool used to create off-line Credit or Force transactions to be settled by the TSYSSETTLE component. The TSYSDetailRecord component may also be used to modify the XML aggregates returned by the TSYSRETAIL or TSYSECOMMERCE component's GetDetailAggregate method.
TSYSECommerce	The TSYSECommerce component is an advanced tool used to authorize credit cards in both Mail Order (Direct Marketing) and eCommerce environments, where the customer is ordering products or services via the telephone or Internet. This component makes authorizing these types of transactions very easy.
TSYSGiftCard	The TSYSGiftCard component is used to manipulate funds on Gift and Prepaid Cards using the Vital/TSYS payment system. This component supports card-present gift card transactions, and allows for simple, direct, secure communication to the Vital/TSYS TLS/SSL gateway through a standard Internet connection. This component can be integrated into web pages or stand- alone Point Of Sale applications. Because all TLS/SSL communications are handled inside the component, any application or web page can be deployed without the need for expensive dedicated TLS/SSL servers.
TSYSHCAdjustment	The TSYSHCAdjustment component is used to adjust a previously authorized transaction. This component makes adjusting transactions very easy.
TSYSHCBatchMgr	The TSYSHCBatchMgr component is used to manually close batches as well as retrieve details and summaries about batches. This component makes closing batches very easy.
TSYSHCBenefit	The TSYSHCBenefit component is used to authorize Electronic Benefits (EBT) cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing EBT Food Stamp and Cash Benefit transactions (with a customer PIN) very easy.
TSYSHCDebit	The TSYSHCDebit component is used to authorize debit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing debit card transactions with a customer PIN very easy.
TSYSHCECommerce	The TSYSHCECommerce component is used to authorize credit cards in both Mail Order (Direct Marketing) and eCommerce environments, where the customer is ordering products or services via the telephone or Internet. This component makes authorizing these types of transactions very easy.
TSYSHCLevel3	The TSYSHCLevel3 component is used to add Level 3 data to a previously authorized transaction. This component makes adding Level 3 data very easy.
TSYSHCRetail	The TSYSHCRetail component is used to authorize credit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing these types of transactions very easy.
TSYSHCReversal	The TSYSHCReversal component is used to reverse a previously authorized transaction. This component makes reversing transactions very easy.
TSYSHCTerminalMgr	The TSYSHCTerminalMgr component is used to authenticate and deactivate POS devices on the TSYS Host Capture System. This component makes authenticating and deactivating POS devices very easy.
TSYSHCTransactionDetails	The TSYSHCTransactionDetails component is used to retrieve details about authorized transactions. This component makes retrieving transaction details very easy.
TSYSHealthCare	The TSYSHEALTHCARE component is designed to be a simple interface for those wishing to add Healthcare Auto- Substantiation (IIAS) support without redesigning their entire payment system. This component is used to authorize FSA cards in a Retail environment, where the customer is purchasing products or services in person. Both full and partial authorizations are supported.
TSYSLevel2	The TSYSLevel2 component is a tool used to create Level2 Corporate Purchasing Card addendum aggregates, which can then be passed to the TSYSSETTLE component and settled.
TSYSLevel3	The TSYSLevel3 component is a tool used to create Level3 Corporate Purchasing Card addendum aggregates, which can then be passed to the TSYSSETTLE component and settled.
TSYSRetail	The TSYSRetail component is an advanced tool used to authorize credit cards in a Retail environment, where the customer is purchasing products or services in person. This component makes authorizing these types of transactions very easy. Supported Industry Types include retail stores, restaurants, grocery or food stores, Hotels, Auto Rental businesses and Passenger Transport.
TSYSReversal	The TSYSReversal component is used to reverse transactions that were previously authorized using the TSYSRETAIL , TSYSECOMMERCE , or TSYSHEALTHCARE components.
TSYSSettle	The TSYSSettle component is used to do a Batch Settlement on all transactions that were successfully authorized with the TSYSECOMMERCE or TSYSRETAIL components. This component may also send Level II and Level III Corporate Purchasing Card data for better interchange rates.
TSYSTerminalMgr	The TSYSTerminalMgr component is used to authenticate and deactivate POS devices on the TSYS Terminal Capture platform.

Additional Information

You will always find the latest information about 4D Payments SDK at our web site: www.4dpayments.com. We offer free, fully-functional 30-day trials for all of our products, and our technical support staff are happy to answer any questions you may have during your evaluation.

Please direct all technical questions to support@4dpayments.com. To help support technicians assist you as quickly as possible, please provide an detailed and accurate description of your problem, the results you expected, and the results that you received while using our product. For questions about licensing and pricing, and all other general inquiries, please contact sales@4dpayments.com.

Thank You!

Thank you for choosing 4D Payments SDK for your development needs. We realize that you have a choice among development tools, and that by choosing us you are counting on us to be a key component in your business. We work around the clock to provide you with ongoing enhancements, support, and innovative products; and we will always do our best to exceed your expectations!

PA-DSS Implementation Overview

PA-DSS stands for Payment Application Data Security Standard. PA-DSS is managed by the PCI Security Standards Council. Any payment application that is sold, distributed, or licensed to third parties are subject to the PA-DSS requirements. The key to this program is the PCI DSS, or "Payment Card Industry Data Security Standard." This standard describes how a merchant is to secure electronic data, physical servers, hard drives, employee access to data, and more.

For an entity (merchant, service provider, etc) to be PCI compliant, the application used to authorize credit cards and store customer data must conform to these Payment Application Data Security Standards.

This application is designed to be used to support another application. It can be used to create a PA-DSS compliant secure payment application. This documentation is intended for developers of payment applications to give you instructions on how to implement this application in such a way that it will meet PA-DSS and PCI requirements.

IMPORTANT: You must write your own implementation guide to be supplied with your product to your customers. This guide should not be distributed to your customers (end users), only your implementation guide that you create should be supplied.

All official updates to this product must be obtained from our website at a URL provided by our support staff or via our download page at https://4dpayments.com/download/. To verify that the build is an official build, right click the setup file (setup.exe) and choose properties. From this window select the Digital Signature tab and press the Details button to view details about the digital signature. The text "This digital signature is OK." should be present in this dialog window.

Installation

When installing this product the installer will create files on disk at the location specified during the setup. The default installation location is under a folder at "C:\Program Files\4D Payments". The files written include help files, demos, the uninstall program, and the application itself. Additionally during installation on windows machines a registry key is added under "HKEY_LOCAL_MACHINE/SOFTWARE/DPayments/RT" to hold the license.

Sensitive Authentication Data

This application does not store any authentication data, and has not done so in previous versions. As a result there is no sensitive authentication to delete from previous versions. If your application stores sensitive authentication data you must be sure it is properly deleted. Sensitive authentication data is not required for troubleshooting this product. If sensitive authentication data is received by our support staff it is immediately and permanently deleted. If you or your customer obtain sensitive authentication data as a result of troubleshooting the following rules must be followed:

• Sensitive authentication data (pre-authorization) must only be collected to solve a specific problem
• The data must be stored in a known, specific location with limited access.
• Limit the amount of data to only the amount necessary to solve the issue.
• Sensitive authentication data MUST be encrypted while stored.
• The data must be deleted immediately after it is no longer needed.

If your application stores any cardholder data it must be purged after the customer-defined retention period. It must be stored on servers that are NOT connected to the Internet. You must also document all locations where the data is stored. This application does not store any cardholder data, therefore there are no locations to disclose.

The system on which the application runs must be configured to prevent accidental exposure of sensitive cardholder information. In Windows this includes disabling system backup and restore to prevent inadvertent storage of cardholder data. Additionally the Windows paging file (pagefile.sys) should be cleared during shutdown to prevent unsecured data from being written to disk. In non-Windows systems the swap space should be cleared. To further protect cardholder data in both Windows and non-Windows systems the swap space, or the entire disk, may be encrypted. Any crash dumps from the application may contain cardholder data and must be encrypted if stored.

Cryptographic Keys

Cryptographic keys are used to encrypt cardholder data for storage. This application does not store any cardholder data, as such there are no keys to protect. No previous versions of this application have stored cardholder data, so there were no cryptographic keys in previous versions either.

If your application stores cardholder data you must protect the keys used to encrypt it against disclosure and misuse. Restrict access to the keys to the fewest number of custodians. Store the keys in the fewest possible locations and in the fewest possible forms. You must implement key management procedures to protect the keys (See Appendix B at the bottom of this document). A sample key custodian form can be found here: https://4dpayments.com/wp-content/docs/Sample_Key_Custodian_Form.pdf. If previous versions of your application stored cryptographic key material it must be rendered irretrievable.

Controlling User Ids and Authentication

This application does not provide any account management or authentication options. This application does not use any accounts. If your application allows authentication and provides accounts, you must use unique user IDs and secure authentication for administrative access and access to cardholder data. Secure authentication should be assigned to any default account, even if they are not used. Default accounts should be disabled and should not be used. Access to PCs, servers, and databases with payment applications must also be secured. Access to PCs, servers, and databases with payment applications must be secured by the completion of installation and for any changes after installation. See Appendix A at the bottom of this document for more details.

Logging

This application does not perform any administrative function that are required to be logged. It is your responsibility to implement logging in your application to meet the requirements for PA-DSS validation. You must implement and maintain automated audit trails. Automated audit trails must be implemented for all system components to reconstruct the following events:

• All individual accesses to cardholder data
• All actions taken by any individual with root or administrative privileges
• Access to all audit trails
• Invalid logical access attempts
• Use of identification and authentication mechanisms
• Initialization of the application audit logs
• Creation and deletion of system-level objects

Record at least the following audit trail entries for all system components for each event:

• User identification
• Type of event
• Date and time
• Success or failure indication
• Origination of event
• Identity or name of affected data, system component, or resource

Logging must be enabled. Disabling logs will result in non-compliance with PCI DSS.

You must also establish and maintain centralized logging. Examples of this functionality may include, but are not limited to:

• Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.
• Provided functionality and documentation to convert the application's proprietary log format into industry standard log formats suitable for centralized logging.

Audit trail files must be promptly backed up to a centralized log server or media that is difficult to alter.

Secure Protocols and Transmission

All communication performed by this product will be performed over SSL. The SSLCipherStrength configuration setting may be specified to force a minimum cipher strength. It is strongly recommended that this be set to a value of 128 to ensure at least 128 bit SSL is used. The SSLStatus event will fire with information about the negotiated SSL parameters which may be inspected to verify the connection was established securely.

In Windows this application relies on the Microsoft CryptoAPI to perform cryptographic functions. In other environments (Mac and Linux) this application relies on OpenSSL to perform cryptographic functions. This application does not have any other dependencies on any services, software, components, or hardware.

Wireless and Public Networks

If the application is used on a wireless or public network the transmission must be properly secured. You must:

• Change wireless vendor defaults, including default wireless encryption keys, passwords for access points, and SNMP community strings
• Change encryption keys anytime anyone with knowledge of the keys leaves the company or changes positions in the company.
• Update firmware on wireless devices to support strong encryption for authentication and transmission.
• Install a firewall between any wireless networks and systems that store cardholder data
• Configure the firewall to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment
• NOT use WEP as a security control
• Use industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission of cardholder data

Remote Access

This application does not allow remote access in any form. If your application may be accessed remotely, then remote access must be authenticated using a two-factor authentication mechanism. Two-factor authentication consists of a user ID and password and an additional authentication item such as a smart card, token, or PIN). Two forms of one-factor authentication are not sufficient. Examples of two-factor authentication include RADIUS with tokens, or TACAS with tokens.

This application does not deliver remote updates. If your application delivers remote updates via remote access into the customers' systems, instruct the customers to turn on remote-access technologies only when needed for downloads. The technologies must be turned off immediately after download completes. Alternatively, if updates are delivered via VPN or other high-speed connections, instruct customers to properly configure a firewall or a personal firewall product to secure "always-on" connections. The following actions must be taken:

• Establish firewall and router configuration standards that include:
  • A formal process for approving and testing all network connections and changes to the firewall and router configurations.
  • Current network diagram with all connections to cardholder data, including any wireless networks.
  • Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone.
  • Description of groups, roles, and responsibilities for logical management of network components.
  • Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure. Examples of insecure services, protocols, or ports include but are not limited to FTP, Telnet, POP3, IMAP, and SNMP.
  • Requirement to review firewall and router rule sets at least every six months.
• Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment. An "untrusted network" is any network that is external to the networks belonging to the entity under review, and/or which is out of the entity's ability to control or manage.
  • Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.
  • Secure and synchronize router configuration files.
  • Install perimeter firewall between any wireless networks and the cardholder data environment, and configure these firewall to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
• Prohibit direct public access between the Internet and any system component in the cardholder data environment.
  • Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
  • Limit inbound Internet traffic to IP addresses within the DMZ.
  • Do not allow any direct connections between the Internet and the cardholder data environment.
  • Do not allow internal addresses to pass from the Internet into the DMZ.
  • Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
  • Implement stateful inspection, also known as dynamic packet filtering. That is, only "established" connections are allowed into the network.
  • Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks.
  • Do not disclose private IP addresses and routing information to unauthorized parties. Methods to obscure IP addressing may include, but are not limited to:
    • Network Address Translation (NAT)
    • Placing servers containing cardholder data behind proxy servers/firewalls or content caches
    • Removal of filtering of route advertisements for private networks that employ registered addressing
    • Internal use of RFC1918 address space instead of registered addresses.
• Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization's network.

If your application can be accessed remotely, the remote access must be implemented securely. Examples of remote access security features include:

• Change default settings in the remote access software (for example, change default password and use unique passwords for each customer).
• Allow connections only from specific (known) IP/MAC addresses.
• Use strong authentication and complex passwords for logins. See "Appendix A - Unique UserIDs and Secure Authentication".
• Enable encrypted data transmission. Instruct customers to encrypt all non-console administrative access with strong cryptography, using technologies such as SSH, VPN, or SSL/TSLS for web-based management and other non-console administrative access. Telnet or rlogin must never be used for administrative access.
• Enable account lockout after not more than six failed login attempts.
• Configure the system so a remote user must establish a Virtual Private Network (VPN) connection via a firewall before access is allowed.
• Enable the logging function.
• Restrict access to customer passwords to authorized reseller/integrator personnel.
• Establish strong and complex customer passwords. See "Appendix A - Unique UserIDs and Secure Authentication".

Your payment application must support customers' use of remote access security features.

This application does not have an administrative interface, therefore encrypting non-console administrative access is not a concern. If your application does have an administrative interface non-console administrative access must be encrypted with strong cryptography, using technologies such as SSH, VPN, or SSL/TSLS for web-based management and other non-console administrative access. Telnet or rlogin must never be used for administrative access.

Messaging

This application does not support messaging. If your application supports messaging encrypt all PANs sent with end-user messaging technologies (for example, e-mail, instant messaging, chat). A solution must be in place that renders the PAN unreadable or implements strong cryptography to encrypt the PANs. Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).

Appendix A - Unique UserIDs and Secure Authentication:

The following guidelines must be adhered to.

• All users must be assigned a unique ID before being allowed to access the system components or cardholder data.
• At least one of the following methods must be used to authenticate all users.
  • Something you know, such as a passphrase.
  • Something you have, such as a token device or smart card.
  • Something you are, such as a biometric.
• The application must not require or use any group, shared, or generic accounts and passwords.
• The application must require changes to user passwords at least every 90 days.
• The application must require a minimum password length of at least seven characters.
• The application must require that passwords contain both numeric and alphabetic characters.
• The application must keep password history and requires that any new password is different than any of the last four passwords used.
• The application limits repeated access attempts by locking out the user account after not more than six logon attempts.
• The application must set the lockout duration to a minimum of 30 minutes or until the administrator enabled the user ID.
• If an existing session has been idle for more than 15 minutes, the application must require the user to re-authenticate to re-activate the session.

Appendix B - Key management Procedures:

Companies that use payment applications must have key management procedures that cover the points listed below. The following requirements and procedures must be addressed:

• The encryption algorithm used must be an industry recognized algorithm (proprietary in-house algorithms are not allowed).
• Generation of strong keys (minimum 128-bit key length)
• Secure key distribution
• Secure key storage
• Periodic changing of keys (as deemed necessary, but at least annually)
• Destruction of old keys
• Replacement of known or suspected compromised keys
• Revocation of old or invalid keys
• Split knowledge and establishment of dual control of keys so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key)
• Prevention of unauthorized substitution of keys
• Requirement for key custodians to sign a form stating that they understand and accept their key-custodian responsibilities.

Basic Credit Card Information

A credit card number consists of anywhere between 12 and 19 digits (depending upon the credit card type). The first six digits of a credit card number are known as the Issuer Identification Number (IIN) or Bank Identification Number (BIN), which is used to identify which organization issued the card along with other information. The remaining digits make up the account identifier/number with the exception of the last digit, which is the checksum digit used to validate the card number via the LUHN formula.

With the IIN/BIN, one can identify the card type (i.e. Visa, MasterCard, etc.), card level (i.e. business or purchasing card), along with issuer details (such as bank and country). The only type of card information able to be obtained by directly viewing the card number is the card type, as card brands are all assigned the same starting digits (i.e. all Visa cards start with a 4). Therefore the CardValidator component is only able to determine the CardType (along with validating the card number via the LUHN formula and verifying the Expiration Date). The remaining digits of the IIN/BIN are not specifically assigned (based on a formula) for a card issuer or level. Thus we cannot determine this information. However all this information is stored within IIN/BIN databases. There are multiple databases available but often require some sort of subscription to access the data. These are very helpful resources in the case that you need to determine if the card is a commercial card and sending Level2 and Level3 data (which is often associated with lower interchange fees).

Authorization Source Codes

This page lists authorization source codes. This information is not applicable to all processors.

TSYS

This is a list of possible ResponseAuthSource codes. These codes indicate the source of the ResponseApprovalCode.

* Currently in use by Japan Acquirer Services (JAS).

Paymentech

This is a list of possible ResponseAuthSource codes. These codes indicate the source of the ResponseApprovalCode.

* Currently in use by Japan Acquirer Services (JAS).

AVS Result Codes

This page lists AVS result codes.

TSYS

This is a list of possible ResponseAVSResult codes.

*AVS Result Code for International addresses only

Paymentech

This is a list of possible ResponseAVSResult codes.

If supporting international transactions, six additional International Address Verification Service (IAVS) codes are introduced:

FDMS

This is a list of possible ResponseAVSResult codes.

If supporting international transactions, four additional International Address Verification Service (IAVS) codes are introduced:

Global Payments

This is a list of possible ResponseAVSResultCode codes.

* These values are Visa specific.

** These values are returned by the Global Transport Gateway and not the issuing bank.

Response Codes

This page lists response codes.

TSYS

The following is a list of possible ResponseCode, and ResponseText that may be returned by the TSYS server.

TSYSTerminalMgr

The following is a list of ResponseCode values that may be returned by the TSYS server when using TSYSTerminalMgr.

Paymentech Server Errors:

The following is a list of error codes which may be returned by the Paymentech Server. In the case of a server-side error condition, the ResponseCode property will contain "E", the error code will be contained in the ResponseApprovalCode property, and the description in ResponseText

Paymentech Issuer Errors

Paymentech Format Errors

Paymentech Host / Setup Errors

Paymentech Debit / EBT Specific Errors

Paymentech Batch Management Errors (use the ErrorCode configuration setting to retrieve this information from the PTechHostSettle class.

FDMS North/Nashville

The ResponseCaptureFlag property indicates whether the transaction was successful. If True the transaction was successful. If False there was an error and the ResponseApprovalCode contains the error message.

Global Payments

The current response codes returned by Global Payments are listed below.

ResponseCode property: This value signifies the result of the transaction (i.e. approved, declined, etc). When programmatically validating a transaction's result, this value should ALWAYS be used instead of any response message describing the result. See the table below for a full list of result codes and descriptions.

ResponseHostCode property: Typically, if the transaction is approved, this will be the batch reference number. If the transaction is declined, the ResponseHostCode will indicate the reason for the decline. The table below lists the possible ResponseHostCode and ResponseMessage combinations for error conditions.

ResponseCVVResultCode property: This value is only applicable to credit card transactions. The card verification number is typically printed on the back of the card and not embossed on the front. It is used as an extra authentication method for "card not present" transactions. When programmatically validating a CV Result, this value should ALWAYS be used instead of any formatted response message describing the result, contained in the ResponseCVVResultMessage property.

The following table lists the possible CVV result codes:

ResponseAVSResultCode property: When programmatically validating an AVS Result, this value should ALWAYS be used instead of any formatted ResponseAVSResultMessage describing the result. The following table lists the possible AVS result codes:

* These values are Visa specific.

** These values are returned by the Global Transport Gateway and not the issuing bank.

FDMS Rapid Connect

Possible response codes returned by FDMS Rapid Connect are listed below along with a textual description.

Returned ACI Codes

This page lists ACI codes. This information is not applicable to all processors.

TSYS

This is a list of possible ResponseReturnedACI values. Please note that many of these return values result from features not available in any of the currently supported Industry Types.

FDMS

The following is a list of all returned ACI values. Please note that many of these return values result from features not available in any of the currently supported Industry Types.

Card Level Result Codes

This page lists Card Level Result codes. This information is not applicable to all processors.

TSYS

This is a list of possible ResponseCardLevel values.

Paymentech

Visa Card Level Results Code:

Testing Information

This page provides testing information for the various processors.

TSYS test account information

The following Merchant information may be used to test transactions. Note that the TSYS server will route the test account (indicated by the MerchantBankId) to a test server. If the test system is off-line, you will receive a "Bad BIN or Host Disconnect" error. This error is returned whenever the live server does not recognize a MerchantBankId.

TSYS Test Host Authorization Values for Regular Credit Card Transactions:

* Used for a debit switching. The amount provokes the host into sending "V" as the NetworkId instead of "G". If the NetworkId contains a "V" (or a "5"), this indicates the transaction was processed as a credit card purchase transaction even though it was originally submitted as a debit transaction. Therefore, the transaction must be settled as a credit card (non-debit) transaction.

Visa Commercial Card Group III Responses

MasterCard Commercial Card Group III Responses

Visa Infinite / Visa Signature Card Auth. Transaction Amount Limits (Cert box testing)

For testing, submit a Visa card transaction for $444,444.44 only.

Large Ticket - Commercial Card

For testing, submit a Visa card for $10,000,000.00 only.

Card Verification Value Test Responses (CVV2)

Address Verification Service Responses

*Use "8320" for the CustomerAddress in all of the above cases.

Test Card Numbers: (Use any future expiration date)

Paymentech test account information

The following Merchant information may be used to test transactions. Note that the you must use the test server URL as in the code below. PTechCharge1.Server = "https://netconnectvar1.chasepaymentech.com/NetConnect/controller" PTechCharge1.MerchantNumber = txtMerchantNumber.Text PTechCharge1.TerminalNumber = txtTerminalNumber.Text PTechCharge1.ClientNumber = txtClientNumber.Text PTechCharge1.UserId = txtUserId.Text PTechCharge1.Password = txtPassword.Text

The following amounts may be sent to test various responses from Paymentech. As a note, with the test server only the first three characters of the Response Approval Code should be checked as the server will append the cents portion of the amount to the approval code to indicate what value caused the error. Paymentech Test Host Capture Authorization Values for Regular Credit Card Transactions:

Paymentech Test Terminal Capture Authorization Values for Regular Credit Card Transactions:

FDMS

FDMS does not provide public testing facilities. You must contact FDMS to obtain a test account. Once you have an account you must also setup Datawire (unless you are using FDMS Omaha via a direct connection).

The FDMSRegister class is a tool used to Register and Activate a merchant account with the Datawire VXN. This class communicates with the Datawire VXN transaction transport network, and allows you to set up your account so that credit card transactions made with the FDMSECommerce, FDMSRetail, and FDMSSettle classs will pass through Datawire and ultimately reach the First Data Merchant Services (FDMS) transaction processor. Before you can charge a single credit card, you must Register and Activate your FDMS account, and then run a ServiceDiscovery to find acceptable URLs, which you will ultimately use to send credit card authorizations.

The first thing you must do is Register your merchant account. First Data Merchant Services will provide you with a MerchantNumber and a MerchantTerminalNumber, which are required for registering with Datawire. If you are registering on the Rapid Connect platform you must also set the GroupId configuration setting. In addition, you will need to set the TransactionNumber with a unique value (the TransactionNumber should be incremented for each transaction you send to the Datawire VXN). The example below also sets the URL to point to the Datawire test server.

FDMSRegister.MerchantNumber = "000000999990" FDMSRegister.MerchantTerminalNumber = "555555" //FDMSRegister.Config("GroupId=FDMS_Assigned_GroupId"); //Rapid Connect Only FDMSRegister.TransactionNumber = "0000001V002500" 'any unique number will do; check TransactionNumber property for format FDMSRegister.URL = "https://stagingsupport.datawire.net/staging_expresso/SRS.do" FDMSRegister.Register()

If the registration was successful, the DatawireStatus will contain "OK", and the DatawireId will contain the new Id which you must save and send with every subsequent transaction. The PrimaryDiscoveryURL and SecondaryDiscoveryURL properties will also be filled after a successful authorization. These URLs should be saved for later, and used to perform ServiceDiscovery.

After registering, you must immediately Activate the merchant. If you wait too long, your registration will time out, and you will have to contact Datawire to have them reset your account so that you may register again. When activating the merchant, the same properties are required as for the Register method, with the addition of the DatawireId property. Since the call to Register filled the DatawireId property with the correct value, all we need to do now is:

FDMSRegister.TransactionNumber = "0000002V002500" 'any unique number will do; check TransactionNumber property for format FDMSRegister.Activate()

After registering and activating the account, you may now move on to Service Discovery. The Register method will return both a PrimaryDiscoveryURL and a SecondaryDiscoveryURL. Use these URLs with the ServiceDiscovery method to retrieve a list of valid transaction URLs. For instance:

FDMSRegister.ServiceDiscovery("https://staging1.datawire.net/sd")

After a successful ServiceDiscovery the DatawireStatus will be "OK". The discovered URLs will be listed in the ServiceProviders array property. At this time, you should Ping each of these URLs and sort them in order of fastest to slowest response time. You will use the URL with the fastest response time to authorize transactions with FDMSRetail or FDMSECommerce. If the first URL stops responding, you should remove the URL and switch to the next URL in the list. The following example shows how to ping each of the ServiceProviders (you must save and sort the results yourself).

For i = 0 To FDMSRegister.ServiceProvidersCount - 1 FDMSRegister.Ping(FDMSRegister.ServiceProviders[i]) Debug.Print(FDMSRegister.ServiceProviders[i] & " = " & FDMSRegister.PingResponseTime) Next

If your list of servers becomes empty, perform ServiceDiscovery and the subsequent steps to re-populate the list of available servers.

You may now use the DatawireId and the Service Provider URLs retrieved by this class to submit transactions using the FDMSECommerce, FDMSRetail, and FDMSSettle classs.

FDMS Rapid Connect Test Cards

The Rapid Connect Sandbox also provides test cards that can be used for ad hoc testing.

The TransactionAmount also may have a special meaning.

• The value "4567" ($45.67) will result in a No Host Response to simulate Time-out Reversal testing.
• Values below "10000" ($100.00) will receive an approved response.
• Values above "10000" ($100.00) will receive a specific error. The last 3 digits of the value represent the 3 digit FDMSRcResponseCode. For instance to receive a response with error code 106 the amount should be "10116" ($101.16).

Global Payments test account information

The following merchant information may be used to test transactions. Note that the you must use the test server URL as in the code below. GlobalCharge1.Server = "https://certapia.globalpay.com" GlobalCharge1.UserId = "4dpayments_ecom" GlobalCharge1.Password = "Passw0rd" Since Global Payments separates industry types by UserId, there are several UserId values that can be used for testing depending upon the type of transaction you want to test. These are:

VendorNumber is only required when using GlobalTransactionSearch.

Note that for testing Server must be set to "https://certapia.globalpay.com".