Last Topic "Revision Information"

Executive Summary

Payment Application version 2.2 has been PA-DSS (Payment Application Data Security Standard) certified, with PA-DSS Version 2.2. For the PA-DSS assessment, we worked with the following PCI SSC approved Payment Application Qualified Security Assessor (PAQSA):

This document also explains the Payment Card Industry (PCI) initiative and the Payment Application Data Security Standard (PA-DSS) guidelines. The document then provides specific installation, configuration, and ongoing management best practices for using Payment Application as a PA-DSS validated Application operating in a PCI Compliant environment.

PCI Security Standards Council Reference Documents

The following documents provide additional detail surrounding the PCI SSC and related security programs (PA-DSS, PCI DSS, etc):

• Payment Applications Data Security Standard (PA-DSS)https://www.pcisecuritystandards.org/security_standards/pa_dss.shtml

• Payment Card Industry Data Security Standard (PCI DSS)https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

• Open Web Application Security Project (OWASP) http://www.owasp.org

Application Summary

Payment Application Name:	Restaurant Manager
Payment Application Version:	Version 19.1
Application Description:	Restaurant Manager is a POS solution for the hospitality industry. End users will process customers order through RMPOS. Payment solutions may include integrated credit card processing. Restaurant Manager's RMCCWin is needed to process credit cards. RMCCWin is not directly interface to acquiring banks or payment server provider. RMCCWin relies upon the use of third party software to communicate with payment server providers. Verifone's PAYWare PC, Vantiv (formerly Mercury) Payment Solutions, NETePAy, Paygistix, and Datacap are the only payment processors ASI supports with RMCCwin. Restaurant Manager does support EMV processing with Payment Logistics’s Paygistix and Vantiv EMV software. Paygistix and Vantiv's software does not use RMCCWin. Rather Paygistix will send out for authorization and then send RMPOS an encrypted authorization token that may only be used once.
Application Target Clientele:	Full Service Restaurants, Bars and Nightclubs, Quick Service Operations
Components of Application Suite	RMPOS: Restaurant Manager's RMPOS is the primary POS application that resides on the POS terminal. RMPOS is where all sales transactions occur including adding/deleting items from guest checks, payments, and guest check modifications. Employee clock in/out for time keeping also take place in RMPOS module . RMWIN:Restaurant Manager's RMWIN is the back office application used administer POS functionality. RMWIN is where menu, employee, and function button setup occurs. In addition, RMWIN is the application used to configure POS prompts, enabling/disabling modules and functions, and system security. RMWIN is installed and resides on a single back end server. RMCCWin: Restaurant Manager's RMCCWin is the application used to configure and process credit cards. RMCCWin is deployed and resides on a back end server. RMReports: Restaurant Manager's RMReports module resides on the back end server and is used for reporting functionality. RMInventory: Restaurant Manager's RMInventory resides on the back end server. RMInventory tracks the use of goods sold and purchased. RM Handheld: Restaurant Manager Handheld is a wireless application that performs similar functionality to the standard POS module.
Required Third Party Payment Application Software:	NETePay 5.0 Vantiv (Mercury Payment Systems ) Datacap's Datatran 162 & DialLink Modem Verifone's PAYWare PC version 1.2.2 Payment Logistic's Paygistix for EMV Vantiv (formerly Mercury) for EMV
Other Required Third Party Software:	Systems processing credit cards must use anti-virus software Systems processing credit cards must use firewall software or hardware Systems processing credit cards must two factor authentication software for remote access.
Operating Systems:	Restaurant Manager may be installed on the following operating systems: Window 7 Pro, Windows 8 Pro, Windows 10 Pro, Windows Server 2008, Windows Server 2012
Application Functionality Supported:
Payment Processing Connections:	Credit card transactions are processed by first swiping the credit card on the card reader device. The track data/PAN/Token is first sent to the POS computer and then to RMCCWin on the back end server computer. Encrypted track data is sent to the acquiring payment server provider. Track data/PAN/Token is encrypted and sent from the credit card authorization server to the acquiring bank or payment server provider. Authentication response is sent back to the parking system. If transaction has been granted then the PAN is stored encrypted within the back end computer.
Application Authentication:	Systems using standard non encrypted MSR have credit card track data encrypted using a Triple-DES encryption algorithm on the back end server. Restaurant Manager will retain credit card information in PMT<mmyy>.DBF. Card information is purged at the beginning on each business session based on the business specified need to store credit card info (but no longer than the specified need).
Description of Versioning Methodology:	ASI manages product baselines through a formal versioning program. Versioning allows developers, architects, and even business staff to assign and recognize differences between baselined outputs. As such, versions are applied to all deliverables within the project scope. ASI observes the following guidance rules when assigning version numbers: Major Version- Major version change may include changes greater than 30% to the codebase or add functionality to the system. Major versions are assigned “1.0” at release. Major changes may or may not have an impact on PA-DSS requirements. Minor Version- Incremented whenever a significant change occurs to the baselined product. Minor versions may add functionality to the system. Incremented upon release of a significant change. Minor changes Build- Incremented upon implementation of a single minor change or collection of minor changes to a production solution product. Build changes typically involve bug fixes and no impact on PA-DSS requirements.

Difference between PCI Compliance and PA-DSS Validation

As a software vendor, our responsibility is to be “PA-DSS Validated.”

ASI has performed an assessment and certification compliance review with our independent assessment firm, to ensure that our platform does conform to industry best practices when handling, managing and storing payment related information.

PA-DSS is the standard against which Payment Application has been tested, assessed, and validated.

PCI Compliance is then later obtained by the merchant, and is an assessment of your actual server (or hosting) environment.

Obtaining “PCI Compliance” is the responsibility of the merchant and your hosting provider, working together, using PCI compliant server architecture with proper hardware & software configurations and access control procedures.

The PA-DSS Validation is intended to ensure that the Payment Application will help you achieve and maintain PCI Compliance with respect to how Payment Application handles user accounts, passwords, encryption, and other payment data related information.

The Payment Card Industry (PCI) has developed security standards for handling cardholder information in a published standard called the PCI Data Security Standard (DSS). The security requirements defined in the DSS apply to all members, merchants, and service providers that store, process or transmit cardholder data.

The PCI DSS requirements apply to all system components within the payment application environment which is defined as any network device, host, or application included in, or connected to, a network segment where cardholder data is stored, processed or transmitted.

The 12 Requirements of the PCI DDS

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3. Protect Stored Data

4. Encrypt transmission of cardholder data and sensitive information across public networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to data by business need-to-know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security

Next Topic "Considerations for the Implementation of Payment Application in a PCI-Compliant Environment"

Proprietary and Confidential Information