TCP/IP Credit Card Module 1
Table of Contents PCI Overview...4 Introduction and Scope...4 What Does PA-DSS Mean to You?... 4 PCI DSS Applicability Information... 4 PA-DSS Guidelines... 5 1. Sensitive Date Storage Guidelines...5 2. Protect Stored Cardholder Data... 6 4. Log payment application activity... 7 5. Develop secure payment applications... 7 6. Protect Wireless Transmissions... 8 7. Test payment applications to address vulnerabilities...8 8. Facilitate secure network implementation... 8 9. Cardholder data must never be stored on a server connected to the Internet...9 10. Facilitate secure remote software updates... 9 11. Facilitate secure remote access to payment application... 9 12. Encrypt sensitive traffic over public networks... 9 13. Encrypt all non-console administrative access... 9 14. Maintain instructional documentation and training programs for customers, resellers, and integrators... 10 More Information...10 Processor Versions...11 X-Charge... 11 Supported Versions... 11 PCCharge...11 Version... 11 Java Setup...11 Checking Installation...12 Problems After Installation of Java...12 Java Help: Java Help Index... 12 Jar Association Problems...12 Environment Variables...12 Campground Manager Module Setup... 13 Activate TCP/IP Integration... 13 Server Port Location...14 PCCharge... 14 X-Charge...15 Workstation Setup... 16 SaaS User...17 SaaS Daemon Setup... 18 Card Processing...19 Swipe... 19 Sale Transaction... 19 Credit / Return / Paid Out Transaction... 20 PCCharge Voiding... 21 X-Charge Voiding...22 2
BYS Encryption Setup... 23 BYS Reservation Request Screen... 25 With Credit Card Module Installed... 25 Without Credit Card Module Installed... 26 Clerk / Cashier Setup... 28 PCCharge Cashier Setup... 28 Campground Manager Setup For PCCharge... 30 Reset Password... 32 Disable Cashier Security...32 X-Charge Cashier Setup... 33 Retrieving Credit Card Number... 34 Retrieving PCCharge Credit Card Number...34 Retrieving X-Charge Credit Card Number...35 SSL Support... 38 SSL Configuration...38 Creating and Installation of SSL Certificate... 39 Creating your Own Certificate... 39 Generate a Certificate with Crypto4 PKI...40 SSL Certificate Installation... 45 Alternative Manual Installation...48 Campground Manager SSL Installation...49 LICENSE ISSUES... 51 3
PCI Overview Introduction and Scope The Payment Card Industry Payment Application Data Security Standard (PCI PA-DSS) is comprised of fourteen requirements that support the Payment Card Industry Data Security Standard (PCI DSS). The PCI Security Standards Council (PCI SSC), which was founded by the major card brands in June 2005, set these requirements in order to protect cardholder payment information. The standards set by the council are enforced by the payment card companies who established the Council: American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa, Inc. PCI PA-DSS is an evolution of Visa s Payment Application Best Practices (PABP), which was based on the Visa Cardholder Information Security Program (CISP). In addition to Visa CISP, PCI DSS combines American Express Data Security Operating Policy (DSOP), Discover Network s Information Security and Compliance (DISC), and MasterCard s Site Data Protection (SDP) into a single comprehensive set of security standards. The transition to PCI PA-DSS was announced in April 2008. In early October 2008, PCI PA-DSS Version 1.2 was released to align with the PCI DSS Version 1.2, which was released on October 1, 2008. What Does PA-DSS Mean to You? PCI DSS Applicability Information The following table illustrates commonly used elements of cardholder and sensitive authentication data; whether storage of each data element is permitted or prohibited; and whether each data element must be protected. This table is not exhaustive, but is presented to illustrate the different types of requirements that apply to each data element. PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply. Cardholder Data Sensitive Authentication Data 2 Data Element Storage Permitted Protection Required PCI DSS Req. 3.4 Primary Account Number (PAN) Yes Yes Yes Cardholder Name 1 Yes Yes 1 No Service Code 1 Yes Yes 1 No Expiration Date 1 Yes Yes 1 No Full Magnetic Stripe Data 3 No N/A N/A CAV2/CVC2/CVV2/CID No N/A N/A PIN/PIN Block No N/A N/A 1 These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted. 2 Sensitive authentication data must not be stored after authorization (even if encrypted). 3 Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere. 4
PA-DSS Guidelines 1. Sensitive Date Storage Guidelines Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data. 1.1 Do not store sensitive authentication data after authorization (even if encrypted): Sensitive authentication data includes the data as cited in the following Requirements 1.1.1 through 1.1.3. PCI Data Security Standard Requirement 3.2 Note: By prohibiting storage of sensitive authentication data after authorization, the assumption is that the transaction has completed the authorization process and the customer has received the final transaction approval. After authorization has completed, this sensitive authentication data cannot be stored. 1.1.1 After authorization, do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. In the normal course of business, the following data elements from the magnetic stripe may need to be retained: The account holder s name, Primary account number (PAN), Expiration date, and Service code To minimize risk, store only those data elements needed for business. Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI Data Security Standard Requirement 3.2.1 1.1.2 After authorization, do not store the card-validation value or code (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions. Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI Data Security Standard Requirement 3.2.2 1.1.3 After authorization, do not store the personal identification number (PIN) or the encrypted PIN block. Note: See PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for additional information. PCI Data Security Standard Requirement 3.2.3 1.1.4 Securely delete any magnetic stripe data, card validation values or codes, and PINs or PIN block data stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example by the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations. PCI Data Security Standard Requirement 3.2 Note: This requirement only applies if previous versions of the payment application stored sensitive authentication data. 1.1.5 Securely delete any sensitive authentication data (pre-authorization data) used for debugging or troubleshooting purposes from log files, debugging files, and other data sources received from customers, to ensure that magnetic stripe data, card validation codes or values, and PINs or PIN block data are not stored on software vendor systems. These data sources must be collected in limited amounts and only when necessary to resolve a problem, encrypted while stored, and deleted immediately after use. PCI Data Security Standard Requirement 3.2 5
2. Protect Stored Cardholder Data 2.1 Software vendor must provide guidance to customers regarding purging of cardholder data after expiration of customer-defined retention period. PCI Data Security Standard Requirement 3.1. 2.2 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). Notes: This requirement does not apply to those employees and other parties with a legitimate business need to see full PAN; This requirement does not supersede stricter requirements in place for displays of cardholder data for example, for point-of-sale (POS) receipts. PCI Data Security Standard Requirement 3.3 2.3 Render PAN, at a minimum, unreadable anywhere it is stored, (including data on portable digital media, backup media, and in logs) by using any of the following approaches: One-way hashes based on strong cryptography Truncation Index tokens and pads (pads must be securely stored) Strong cryptography with associated key management processes and procedures. The MINIMUM account information that must be rendered unreadable is the PAN. PCI Data Security Standard Requirement 3.4 The PAN must be rendered unreadable anywhere it is stored, even outside the payment application. Note: Strong cryptography is defined in the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms. 2.4 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts. PCI Data Security Standard Requirement 3.4.1 2.5 Payment application must protect cryptographic keys used for encryption of cardholder data against disclosure and misuse. PCI Data Security Standard Requirement 3.5 2.6 Payment application must implement key management processes and procedures for cryptographic keys used for encryption of cardholder data. PCI Data Security Standard Requirement 3.6 2.7 Securely delete any cryptographic key material or cryptogram stored by previous versions of the payment application, in accordance with industry-accepted standards for secure deletion, as defined, for example the list of approved products maintained by the National Security Agency, or by other State or National standards or regulations. These are cryptographic keys used to encrypt or verify cardholder data. PCI Data Security Standard Requirement 3.6 Note: This requirement only applies if previous versions of the payment application used cryptographic key materials or cryptograms to encrypt cardholder data. 3. Provide secure authentication features 3.1 The out of the box installation of the payment application in place at the completion of the installation process, must facilitate use of unique user IDs and secure authentication (defined at PCI DSS Requirements 8.1, 8.2, and 8.5.8 8.5.15) for all administrative access and for all access to cardholder data. PCI Data Security Standard Requirements 8.1, 8.2, and 8.5.8 8.5.15 Note: These password controls are not intended to apply to employees who only have access to one card 6
number at a time to facilitate a single transaction. These controls are applicable for access by employees with administrative capabilities, for access to servers with cardholder data, and for access controlled by the payment application. This requirement applies to the payment application and all associated tools used to view or access cardholder data. 3.2 Access to PCs, servers, and databases with payment applications must require a unique user ID and secure authentication. PCI Data Security Standard Requirements 8.1 and 8.2 3.3 Render payment application passwords unreadable during transmission and storage, using strong cryptography based on approved standards. Note: Strong cryptography is defined in PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms. PCI Data Security Standard Requirement 8.4 4. Log payment application activity 4.1 At the completion of the installation process, the out of the box default installation of the payment application must log all user access (especially users with administrative privileges), and be able to link all activities to individual users. PCI Data Security Standard Requirement 10.1 4.2 Payment application must implement an automated audit trail to track and monitor access. PCI Data Security Standard Requirements 10.2 and 10.3 5. Develop secure payment applications 5.1 Develop all payment applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices and incorporate information security throughout the software development life cycle. These processes must include the following: PCI Data Security Standard Requirement 6.3 5.1.1 Testing of all security patches and system and software configuration changes before deployment, including but not limited to testing for the following. 5.1.1.1 Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) 5.1.1.2 Validation of proper error handling 5.1.1.3 Validation of secure cryptographic storage 5.1.1.4 Validation of secure communications 5.1.1.5 Validation of proper role-based access control (RBAC) 5.1.2 Separate development/test, and production environments 5.1.3 Separation of duties between development/test, and production environments 5.1.4 Live PANs are not used for testing or development. 5.1.5 Removal of test data and accounts before production systems become active 5.1.6 Removal of custom payment application accounts, user IDs, and passwords before payment applications are released to customers 5.1.7 Review of payment application code prior to release to customers after any significant change, to identify any potential coding vulnerability. Note: This requirement for code reviews applies to all payment application components (both internal and public-facing web applications), as part of the system development life cycle required by PA-DSS Requirement 5.1 and PCI DSS Requirement 6.3. Code reviews can be conducted by knowledgeable internal personnel or third parties. 5.2 Develop all web payment applications (internal and external, and including web administrative access to product) based on secure coding guidelines such as the Open Web Application Security Project Guide. Cover prevention of common coding vulnerabilities in software development processes, to include: 5.2.1 Cross-site scripting (XSS). 5.2.2 Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws, as well as other 7
injection flaws. 5.2.3 Malicious file execution 5.2.4 Insecure direct object references. 5.2.5 Cross-site request forgery (CSRF). 5.2.6 Information leakage and improper error handling 5.2.7 Broken authentication and session management 5.2.8 Insecure cryptographic storage 5.2.9 Insecure communications 5.2.10 Failure to restrict URL access. Note: The vulnerabilities listed in PA-DSS Requirements 5.2.1 through 5.2.10 and in PCI DSS at 6.5.1 through 6.5.10 were current in the OWASP guide when PCI DSS v1.2 was published. However, if and when the OWASP guide is updated, the current version must be used for these requirements. PCI Data Security Standard Requirement 6.5 5.3 Software vendor must follow change control procedures for all product software configuration changes. PCI Data Security Standard Requirement 6.4. The procedures must include the following: 5.3.1 Documentation of impact 5.3.2 Management sign-off by appropriate parties 5.3.3 Testing of operational functionality 5.3.4 Back-out or product de-installation procedures 5.4 The payment application must not use or require use of unnecessary and insecure services and protocols (for example, NetBIOS, file-sharing, Telnet, unencrypted FTP, etc.). PCI Data Security Standard Requirement 2.2.2 6. Protect Wireless Transmissions 6.1 For payment applications using wireless technology, the wireless technology must be implemented securely. PCI Data Security Standard Requirements 1.2.3 & 2.1.1 6.2 For payment applications using wireless technology, payment application must facilitate use of industry best practices (for example, IEEE 802.11i) to implement strong encryption for authentication and transmission. Payment applications using wireless technology must facilitate the following regarding use of WEP: For new wireless implementations, it is prohibited to implement WEP after March 31, 2009. For current wireless implementations, it is prohibited to use WEP after June 30, 2010. PCI Data Security Standard Requirement 4.1.1 7. Test payment applications to address vulnerabilities 7.1 Software vendors must establish a process to identify newly discovered security vulnerabilities (for example, subscribe to alert services freely available on the Internet) and to test their payment applications for vulnerabilities. Any underlying software or systems that are provided with or required by the payment application (for example, web servers, 3rd-party libraries and programs) must be included in this process. PCI Data Security Standard Requirement 6.2 7.2 Software vendors must establish a process for timely development and deployment of security patches and upgrades, which includes delivery of updates and patches in a secure manner with a known chain-of-trust, and maintenance of the integrity of patch and update code during delivery and deployment. 8. Facilitate secure network implementation 8.1 The payment application must be able to be implemented into a secure network environment. Application 8
must not interfere with use of devices, applications, or configurations required for PCI DSS compliance (for example, payment application cannot interfere with anti-virus protection, firewall configurations, or any other device, application, or configuration required for PCI DSS compliance). PCI Data Security Standard Requirements 1, 3, 4, 5, and 6.6 9. Cardholder data must never be stored on a server connected to the Internet 9.1 The payment application must be developed such that the database server and web server are not required to be on the same server, nor is the database server required to be in the DMZ with the web server. PCI Data Security Standard Requirement 1.3.2 10. Facilitate secure remote software updates 10.1 If payment application updates are delivered via remote access into customers systems, software vendors must tell customers to turn on remote-access technologies only when needed for downloads from vendor, and to turn off immediately after download completes. Alternatively, if delivered via VPN or other high-speed connection, software vendors must advise customers to properly configure a firewall or a personal firewall product to secure always-on connections. PCI Data Security Standard Requirements 1 and 12.3.9 11. Facilitate secure remote access to payment application 11.1 The payment application must not interfere with use of a two-factor authentication mechanism. The payment application must allow for technologies such as RADIUS or TACACS with tokens, or VPN with individual certificates. PCI Data Security Standard Requirement 8.3 11.2 If the payment application may be accessed remotely, remote access to the payment application must be authenticated using a two-factor authentication mechanism. PCI Data Security Standard Requirement 8.3 11.3 If vendors, resellers/integrators, or customers can access customers payment applications remotely, the remote access must be implemented securely. PCI Data Security Standard Requirement 8.3 12. Encrypt sensitive traffic over public networks 12.1 If the payment application sends, or facilitates sending, cardholder data over public networks, the payment application must support use of strong cryptography and security protocols such as SSL/TLS and Internet protocol security (IPSEC) to safeguard sensitive cardholder data during transmission over open, public networks. Examples of open, public networks that are in scope of the PCI DSS are: The Internet Wireless technologies Global System for Mobile Communications (GSM) General Packet Radio Service (GPRS) PCI Data Security Standard Requirement 4.1 12.2 The payment application must never send unencrypted PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat). PCI Data Security Standard Requirement 4.2 13. Encrypt all non-console administrative access 13.1 Instruct customers to encrypt all non-console administrative access using technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access. Telnet or rlogin must never be used for administrative access. PCI Data Security Standard Requirement 2.3 9
14. Maintain instructional documentation and training programs for customers, resellers, and integrators 14.1 Develop, maintain, and disseminate a PA-DSS Implementation Guide(s) for customers, resellers, and integrators that accomplishes the following: 14.1.1 Addresses all requirements in this document wherever the PA-DSS Implementation Guide is referenced. 14.1.2 Includes a review at least annually and updates to keep the documentation current with all major and minor software changes as well as with changes to the requirements in this document. 14.2 Develop and implement training and communication programs to ensure payment application resellers and integrators know how to implement the payment application and related systems and networks according to the PA-DSS Implementation Guide and in a PCI DSS-compliant manner. 14.2.1 Update the training materials on an annual basis and whenever new payment application versions are released. More Information http://www.pcisecuritystandards.org http://www.visa.com/cisp http://www.sans.org/resources http://www.microsoft.com/security/default.asp https://sdp.mastercardintl.com/ http://www.americanexpress.com/merchantspecs 10
Processor Versions X-Charge Supported Versions For the new TCP IP credit card method, it is recommended to upgrade or install the newest version of X-Charge when it becomes available on their website. http://www.x-charge.com/ Current Tested versions: 7.1.1 Open Integration, 7.0.2 Open Integration. Older versions 6.2.2 and 6.2.7 should work as well. Currently we are using the Open Integration software versions of X-Charge. If you do not install the Open Integration version, you will not be able to process cards through Campground Manager but you will still be able to process cards through the X-Charge client software. If you are having problems processing a card for the first time, please check your X-Charge version to guarantee you have the correct version installed. PCCharge Version For the new TCP IP credit card method, it is recommended to upgrade or install the newest version of PCCharge when it becomes available on their website. http://www.verifone.com/card-acceptance/pccharge.aspx. Always check your PCCharge user manual for the exact process for upgrading. Current Tested versions: 5.7.11, 5.8.5, 5.9.0, 5.9.1, 5.9.2, 5.9.3 Java Setup The new credit card method requires java versions 1.6 and above, but it is recommended that you install the newest version when it becomes available. 11
Checking Installation To check if you have java installed, visit http://www.java.com/en/download/installed.jsp?detect=jre&try=1 to see if java is installed. If you do not find any version of java installed, please download the newest version of Java by clicking here or visit www.java.com. Problems After Installation of Java Java Help: Java Help Index Jar Association Problems If you have just installed or have already installed Java and it still indicates that there are no programs associated with.jar files, you might need to add a line to your environment variables. Depending on your operating system, you will find this by going to your control panel, selecting System and Security (Windows 7/Vista) or Performance and Maintenance (Windows XP) then select System. You will then select the Advanced tab and click Environment Variables button. Environment Variables You will need to add the path to the java folder in the Path System Variables. The path is usually C:\Program Files\Java\jre6\bin or C:\Program Files (x86)\java\jre6\bin. You might need to reset your computer after making the change. 12
Campground Manager Module Setup Throughout this document you will see the acronym SaaS which stands for Software As A Service. This only pertains to those parks using Campground Manager over the internet. You must have Campground Manager version 7.70 or greater in order to take advantage of the new integration method. If you need to upgrade, visit www.campgroundmanager.com web site and log into esupport. There you will find the upgrade download link. After the upgrade, you will still be using the old integration method and not the new credit card integration method. To activate the new method, go to the top pull-down menu called Credit Cards menu and click Parameters. Activate TCP/IP Integration Select the Use IP check box. Deselect the Pccw.mdb Location Check if it is turn on The field labeled Payment Server IP requires the IP address or the computer name of the computer 13
that has X-Charge or PCCharge running on it. If an IP address is going to be used, you must make sure that the IP address is a static address, not a dynamic address. (Apple computers are limited to only using the IP address and not the name of the computer) Payment Server Port is the TCP port X-Charge or PCCharge is listening for transactions on. The default port for PC Charge is 31419. The default port for X-Charge is 26. If you are using PCCharge version 5.8.0 or above, you can also setup the SSL TCP. Doing so will add additional layer of security (Please see SSL setup for more details). PCCharge uses a different port for SSL than standard TCP connection. If you plan on changing to a more secure connection in the future, please check to see if you entered the right port. Set the timeout to at least 65 seconds to ensure communication with the server and allow time for the process to end. The timeout time is not the total time to process but is a parameter passed to PCCharge to automatically stop the processing of a card if it hasn't been able to get validated. In some cases the wait time may be longer than indicated. This can occur if you connect to the wrong port for PCCharge. If your settings are set for SSL but you are trying to process to the none SSL port, the software will connect but will not be able to process. This miscommunication will cause the software to wait until it can timeout using the internal checks. This process can take up to four times the timeout time indicated. Requesting Response Tracking will create a file in the credit card folder for each user that is processing a card. If you need to track each stations credit card transactions for troubleshooting reasons, then select this check box. Turn Security Password Requirements Off should only be selected if you are using versions of PCCharge lower than 5.8.0 or if you need to process a card and the users password if forgotten or expired (only a manager should allow this temporary change) see PCCharge setup for more details. There will be an additional button located next to Use SSL if you already updated and installed an SSL Certificate. SaaS Environment Users Note: Merchant number is also entered in the CMPREFS window. Server Port Location PCCharge 1) After starting the payment server, go to the Setup menu and select Configure System. 2) You will now locate at the bottom of the Preferences window the Advanced button. Click on this button and the Integration Configuration window will open. 14
3) Enable the TCP/IP Integration that you wish to use. Note the listening ports. If you wish to use a secure TCP/IP you will need to select a certificate. See Creating and Installation of Certificate for more details. X-Charge 1) After starting the payment server, click the setup button. 15
2) Under the General Options button you will find on the right hand side under the Server tab the IP Address and Port number. Workstation Setup Now that you have configured your credit card software to use the new TCP/IP method, you will need to point Campground Manager to the location of the java jar files. Go to the Campground Manager menu, then Maintenance, then to the Workstations menu item. 16
Click on the IP Jar Path and Req Path 1 buttons to automatically set the correct paths. SaaS User Within the Local Preferences window, click on the Locate buttons to automatically set correct paths. 17
SaaS Daemon Setup This section will provide steps on how to use the RDP Daemon. The RDP Daemon should be installed into your CMPREFS folder which is taken care of if you installed the SaaS installer.the Daemon will process your credit cards locally and also has a few useful tools. You should see the Daemon icon in the bottom right corner of your system tray (Windows only). If you see this icon, it means that everything is running normally on the server (see below). The Icon will change images from time to time. If you see this Icon (see below), it means that the Daemon is trying to load the Twitter Feed. This feed will give you information to what is going on with the server. If you are having trouble logging onto the SaaS server, then you might want to take a look at the Twitter feed to see if there has been an update. If you see this icon (see below), it means that there is a new Twitter message from Campground Manager and you should take a look at the Twitter Feed. If you right-click the task bar icon, you will get a pop up menu with a few items to choose from. You will be able to look at the Twitter Feed, be able to open the newest SAAS Environment Manual, a direct link to Campground SaaS Daemon. 18
If you select Exit, the Daemon might not exit right away. If you are processing a credit card the Daemon will not turn off until you are done processing. You will see this message if you are in the middle of a transaction and you tried to exit the Daemon. Card Processing Some fields will not be editable during some transactions. The reason for this is that some of the field will be populated from either a swiped credit card or information that was stored in Campground Manager and needs to be the same to finalize the transaction. Swipe When you see this window swipe the card through the card reader. If it finds the correct track information, the window will close and the transaction processing screen will be displayed. If it was unable to find the correct track information then the field will clear after a few seconds after the swipe. If you are having trouble swipe, please try cleaning the swiper. We recommend the IDTECH Magnetic USB Credit Card Swipe. The newer versions of the swiper are able to read the cards faster than the older versions. Sale Transaction 1) The new sale screen now displays the option of Swipe or Manual input. 2) Enter in all the information about the person here. 19
3) Enter the credit card number and the expiration date. If you see any errors in the information about the customer you can edit it here. Don't forget to type in the CVV number found on the card. 4) Click the Process button Credit / Return / Paid Out Transaction 1) The new Credit / Return / Paid Out screen now displays the option of Swipe or Manual input. 2) Enter in all the information about the person here. 20
3) Enter the credit card number and the expiration date. 4) Click the Process button PCCharge Voiding When voiding with PCCharge you need no credit card number or expiration date. Campground Manager will store a TroutD number that has been issued from the PC Charge software. With this number, PCCharge will be able to look up the record and void it. 21
X-Charge Voiding To void with X-Charge you will need to the credit card number and expiration date. Most of the fields will not be editable. The original information must be the same to allow the transaction to void. If the information is not the same the void will fail. 22
BYS Encryption Setup This section will provide steps to add the secure RSA Encryption to BYS transactions. This guarantees that the BookYourSite request is opened by the intended park. RSA involves a public key and a private key. The public key can be known to everyone and is used for encrypting messages. Messages encrypted with the public key can only be decrypted using the private key. The new encryption will now only let your park be able to to have access to your private key for decryption. All generated keys will be saved in a safe location and are never removed from the database. Your keys will be protected with a password to prevent others from being able to gain access to the credit card information. You will need to enter this password every time you do a BYS transaction. If you change your keys before processing your old reservations you will still be able to decrypt them using the password associated with that encrypted key. Try to remember your last BYS password on the day that you change them. It is recommended that you change your key at times when you know people don't usually make BYS reservations. If you have forgotten the password for the key you will not be able to recover it. If there is no chance of remembering the password then you will need to create a new key and create a new password. If you have any transaction that were encrypted using the old key you will need to obtain the card information from the person again. 1) Go to BYS -> Set Encryption 2) You will be asked if you want to set the encryption key. It is recommended that prior to setting the keys that you click the BYS button on the main screen to see if there are any reservations that needed to be processed. 3) Select the strength of encryption that you wish to use. It is recommended that you generate a key that is 2048 bits and above. Keys with encryption below are becoming questioned because of faster computer being able to break them within a few months to a few years. The higher the encryption the better security but you will lose in performance in the encrypting and decrypting time. Most modern computers will have no problem and you will not notice any delay at all. It also takes a longer time to generate larger keys. 23
4) After the key has been generated, you will need to click the save button to save the key. If you change your mind about the level of security you picked, you can select a new level and click the generate button again to make a new key. 5) Now that the key is generated you will need to secure the key with a password. The password must contain: Must be minimum 7 alpha/numeric characters in length. Must be case sensitive Must contain at least one upper case character Must contain at least one numeric character Must contain at least one special character (e.g., @, $, %, etc.) 24
6) If you didn't type a password that was secure enough you will see the message indicating what is required for a strong password. 7) After you type the password twice, campground manager will send the key to the BYS server. Every transaction from that point on will use your new key. BYS Reservation Request Screen With Credit Card Module Installed 1) Using the new RSA encryption you will now see in the Card No field the word -ENCRYPTED-. From this point on you will not be able to see the credit card numbers anymore. Now process the reservation like normal. 2) After the reservation has been processed, it will be listed in the bottom ready for payment authorization. You will only be able to Authorize the encrypted cards within this window. The bottom list is saved so if you do not process your card at this time you can process it later. 25
3) After pressing the Authorize button, you will be ask to enter a password. Enter the password that was used when creating the BYS RSA encryption key. If you have not set the new encryption, you can just press the OK button. 4) If everything goes well you will see the credit card number in the credit card field and you will be able to process the card. Without Credit Card Module Installed 1) Using the new RSA encryption you will now see in the Card No field the word -ENCRYPTED-. From this point on you will not be able to see the credit card numbers anymore. Now process the reservation like normally. 26
2) If you do not have a credit card module installed with Campground Manager but you do process credit cards, you will need to have access to the card number directly. Click the Display Info button. 3) After pressing the Display Info button you will be ask to enter a password. Enter the password that was used when creating the BYS RSA encryption key. 4) If you entered the correct password you will see this window. The card information will be masked. 5) To display the card information, move your mouse over the account number field and expiration date field. If you move the mouse off the field, the number will be masked again. 27
Clerk / Cashier Setup This section will provide steps to add clerks to X-Charge and PCCharge. This setup will allow managers to restrict access to credit card processing and to allow clerks access to retrieve credit card information from either processor. PCCharge Cashier Setup 1) Start the Payment Server 2) Go to Setup -> Cashier Privileges. 3) Click the Add Cashier button to create a new cashier. 4) You will prompted to add a new cashier name and password. Please use the your same clerk name that is found in Campground Manager. You will be able to save your password within Campground Manager so you don't have to type in the password every time. 28
Note: PCCharge requirements for 'strong' password: Must be minimum 7 alpha/numeric characters in length. Must be case sensitive Must contain at least one upper case character Must contain at least one numeric character Must contain at least one special character (e.g., @, $, %, etc.) 5) After the cashier has been successfully created select the cashier and press the Change Permissions button. From here you can change what a cashier can do. For most cases you will need to select the Credit Transactions radio button, found on the left side and then check to boxes on the right side. If you wish to give this cashier more options please see your PCCharge user guide. 7) After you finish creating a user you will need to log in this user within PCCharge for the first time before you can use this cashier with Campground Manager. 6) Go to file -> log off 29
7) You will then be prompted to log on. Enter the new cashier information that you just created. 8) After you log in for the first time you will be prompted to change your password. The cashier should be the one to make the new password. This will prevent the manager from write down the password and have it taken by someone else. Passwords should never be shared or written down. Campground Manager Setup For PCCharge 1) Start Campground Manager, go to Campground Manager ->...Setup. 2) Go to Campground Manager ->...Setup -> Clerks. 3) After the upgrade you can either edit an existing clerk or create a new clerk. 4) Click the Insert button to create a new clerk. 30
5) The PCCharge Password will be the same one that you enter in during the cashier setup. See PCCharge setup for more details. 6) Now every time you process a credit card you will see this window. The fields will populate with the information that you entered in the Clerks setup in Campground Manager. 31
Reset Password Resetting the Cashiers password here will not prevent it from expiring. This will only change the password within the 90 PCCharge time limit. When your password expires you will need to go to the PCCharge server and log in and change your password when prompted. Disable Cashier Security If you have not upgraded to the newest version of PCCharge you will need to disable the cashier security to run PCCharge with Campground Manager. If your cashier permissions are not working and you need to quickly process transaction without security a manager can disable the security. By checking the check box and then pressing the Update button the security requirements will be turned off. 32
X-Charge Cashier Setup To gain access to the X-Charge reports and process cards through the X-Charge client please follow these steps. 1) Start the X-Charge Server. 2) Go to Setup. 3) Go to General Options. 4) Under the Security tab, Click the Enable User Security check box. 5) Now you can either add a new user or modify an existing user by select a user and clicking the add button. 5) Enter in the user name and password then select the options that you wish to give this user. After you are done entering in the information press the OK button. Then press the save button to go back to the X-Charge server. 33
Retrieving Credit Card Number Retrieving PCCharge Credit Card Number Before you can get the Credit Card Number you will first need to get the Trout ID. This can be found in many places. You can find this number in the batch file, in a transaction or in a PCCharge report. 1) We will look at how to get the Trout ID out of a transaction. 2) Click the hourglass next to the Credit Card# field and in the new window you will see the Trout ID number. Write this number down. 34
3) Start PCCharge Payment Server click Utilities -> Retrieve Account Number. 2) Enter in the TroutD number that you wrote down in the window. If it is the right number the credit card number will be displayed. Retrieving X-Charge Credit Card Number To be able to retrieve the credit card number from X-Charge you will need to to have a clerk user already setup. It is recommended that you only setup managers have the right to see all the credit cards in reports. If you wish to give other access to credit card number you will need to setup a policy within your own office. 1) Open X-Charge Server and click Setup. 35
2) Go to the General Options button -> Security tab 3) Now you can either add a new user or modify an existing user by select a user and clicking the add button. If you have already setup a user click the Modify button. 3) In the User Security Settings windows at the very bottom check the Display full CC# in Reports (GPN only). You will be warned that you should turn off this feature as soon as possible to prevent people passing by your computer from seeing credit card numbers and preventing accidental printing of reports with all card information listed. 4) Press OK and then save. 36
5) Open X-Charge Client and enter the user and password that you just setup to display credit card information. 6) Click the Reports button. 6) Select the Date Range of the transaction and click the Load button. 37
7) If you selected the correct date range you will now see all the transaction in the list. Search through the list until you find the card number you were looking for. SSL Support PCCharge now offers a new method of integration secure Socket Layer (SSL) via TCP/IP integration. It allows one to send transactions over a secure protocol. Due to its secure nature, this is the method of integration that is highly recommend. The SSL protocol is commonly used for managing the security of messages sent over a local network and the Internet. The default PCCharge certificate PCChargeDefaultCertificate-CA can be used on the PCCharge server and deployed with a POS on a workstation. PCCharge is also capable of using a certificate created and issued by the integrator. SSL Configuration This section will provide steps to install the local SSL Certificate and enable SSL within PCCharge. Follow these steps to select the certificate within PCCharge and enable SSL. 1) Open PCCharge. 2) Go to Setup -> Configure System. 3) Click the Advanced button on the bottom of the window. 38
4) 5) 6) 7) 8) 9) Check Enable Secure TCP/IP Integration. Use the Store Location drop down box and select Current User. Use the Store Name drop down box and select MY. Click Display Store. Highlight the correct certificate. This should complete the setup for SSL integration with PCCharge. Creating and Installation of SSL Certificate Requirements When creating or buying your own certificate it must provide a.pfx (PKCS#12) formatted certificate that meets specific requirements. Here is a list of the requirements that must be met by the certificate for use by PCCharge: Certificate Properties Description Version Number The version of the X.509 standard to which the certificate conforms. Serial Number A number that uniquely identifies the certificate and is issued by the certification authority. Certificate Algorithm Identifier The names of the specific public key algorithms that the certification authority has used to sign the digital certificate. Issuer Name The identity of the certification authority who actually issued the certificate. Validity Period The period of time for which a digital certificate is valid and contains both a start date and expiration date. Subject Name The name of the owner of the digital certificate. Subject Public Key Information The public key that is associated with the owner of the digital certificate and the specific public key algorithms associated with the public key. Issuer Unique Identifier Information that can be used to uniquely identify the issuer of the digital certificate. Subject Unique Identifier Information that can be used to uniquely identify the owner of the digital certificate. Extensions Additional information that is related to the use and handling of the certificate. Certification Authority's Digital Signature The actual digital signature made with the certification authority's private key using the algorithm specified in the certificate algorithm identifier field. Creating your Own Certificate Certificate Software We recommended using Crypto4 PKI. It is a free and simple software to create your own certificate in a few steps. 39
Generate a Certificate with Crypto4 PKI This section will provide steps to create a SSL Certificate that can be used with PCCharge. 1) Download: Crypto4 PKI Website 2) Install the software 3) Go to the start menu click All Programs then click to the EldoS. Click the Crypto4 PKI folder and then click Certificate Generator. 4) Click Next. We will be generating a self-signed certificate of your own Certificate Authority (CA). 5) Click Certificate and then click next. 40
6) Click Self-Signed Certificate and then click next. 7) Click new certificate from scratch and then click next. 8) Enter in your parks information. The common name should always be unique. This allows it to be easily identified within the list of all installed certificates and prevents certificate to be overwritten. 41
9) Select Authenticated SSL/TLS server and client. PCCharge is the server and CGM is the client. 10) These setting will be automatically selected if you select SSL Authentication. 42
11) If you want to be secure and your location is being maintained by someone you might want to set the range within one year. At the end of the date range the certificate will not be used and you will be unable to process cards until you set up a new certificate. 12) Click the Advanced button. 43
13) Under the Public Key Size pick the max security 4096 bits. The transaction information is relatively small so you will get the best security and the encryption and decryption will not be slow. 14) Even on new computer this process takes a long time. Do not stop the process. 44
15) You can now save the certificate. If you wish you can save a password or leave it blank. You can also export the certificate to windows certificate storage. It is recommended that you not export it but rather install the certificate manually. If you did not create the certificate on the PC that has the PCCharge server you will need to install to move the file to that computer and install it. SSL Certificate Installation You will need to install the certificate on the server computer that has PCCharge running on it. You do not have to install the certificate on all the workstations. See Campground Manager SSL Installation for detail on how to import the certificate into a trust store. This section will provide steps to installing a SSL Certificate that can be used with PCCharge. 1) Locate the certificate that you wish to install. After you have found the certificate double click the certificate or right-click the file and select Install PFX. 2) Click the Next button 45
3) This should already be the certificate that you selected from before. If you selected the wrong one you can browse to find the right one. 4) If your certificate was password protected please enter it now. If your certificate was not protected with a password please press next. 46
5) Select Automatically select the certificate store based on the type of certificate. 6) Click the Finish Button. 47
7) If there are no problems you will see this message. Alternative Manual Installation Another way to manually install the default PCCharge SSL certification or a certificate you have created please follow these steps: 1) Click Start then Run. 2) Type MMC in the Run dialog box and hit Enter or click OK. 3) Select Add/Remove Snap-in from the File menu. 4) Click Add and select Certificates from the Add Standalone Snap-in dialog. 5) Click Add and select Computer Account from the Certificates Snap-in dialog. 6) Select Local Computer on the Select Computer window. 7) Click Finish and then Close. 8) Click OK to close the Add/Remove Snap-in window. 9) Expand the Certificates (Local Computer) folder and right-click Personal under the Certificates tree. 10) Select Import. 11) The Import Wizard should start, click Next one time. 12) The 2nd screen should allow you to browse to your certificate. You ll need to change the file type to All files (*.*). 13) Once you have found your certificate click Next, without making further changes, until you get to Finish. 48
Campground Manager SSL Installation This section will provide steps to import a PFX certificate into Campground Manager. 1) Go to Credit Cards -> Parameters 2) Check the Use SSL check box and then press the Update button. 3) You will need to create a password to protect your certificates after you import the certificate. 4) Click the Import button. 5) Enter your trust store password or create a new trust store with a new password. 6) After you created a secure password you will now need to locate the certificate that you wish to install. 49
7) If the certificate is password protected please enter the certificates password. If the certificate does not have a password associated with it then please click OK. 8) You will see the process bar indicate the process of importing of the certificate. If there are any problems with the certificate there will be an error message. This process can be a little slow on older computers so do not worry if it takes a long time to finish. 9) If everything goes well you will see this message. 10) If you see this message then there might have been a problem with your certificate or the password you entered. If the certificate has already been installed then there was no need to add the certificate and this will also result in an error message. 50
LICENSE ISSUES ============== This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) This product includes software developed by The Legion Of The Bouncy Castle (http://www.bouncycastle.org) /* ===================================================================== OpenSSL License -------------------------The OpenSSL toolkit stays under a dual license, i.e. both the conditions of the OpenSSL License and the original SSLeay license apply to the toolkit. See below for the actual license texts. Actually both licenses are BSD-style Open Source licenses. In case of any license issues related to OpenSSL please contact openssl-core@openssl.org. /* ===================================================================== * Copyright (c) 1998-2005 The OpenSSL Project. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. All advertising materials mentioning features or use of this * software must display the following acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit. (http://www.openssl.org/)" * * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to * endorse or promote products derived from this software without * prior written permission. For written permission, please contact * openssl-core@openssl.org. * * 5. Products derived from this software may not be called "OpenSSL" * nor may "OpenSSL" appear in their names without prior written * permission of the OpenSSL Project. * * 6. Redistributions of any form whatsoever must retain the following * acknowledgment: * "This product includes software developed by the OpenSSL Project * for use in the OpenSSL Toolkit (http://www.openssl.org/)" * * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR 51
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED * OF THE POSSIBILITY OF SUCH DAMAGE. * /* ===================================================================== * * This product includes cryptographic software written by Eric Young * (eay@cryptsoft.com). This product includes software written by Tim * Hudson (tjh@cryptsoft.com). * */ Original SSLeay License ---------------------------------------------/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) * All rights reserved. * * This package is an SSL implementation written * by Eric Young (eay@cryptsoft.com). * The implementation was written so as to conform with Netscapes SSL. * * This library is free for commercial and non-commercial use as long as * the following conditions are aheared to. The following conditions * apply to all code found in this distribution, be it the RC4, RSA, * lhash, DES, etc., code; not just the SSL code. The SSL documentation * included with this distribution is covered by the same copyright terms * except that the holder is Tim Hudson (tjh@cryptsoft.com). * * Copyright remains Eric Young's, and as such any Copyright notices in * the code are not to be removed. * If this package is used in a product, Eric Young should be given * attribution as the author of the parts of the library used. * This can be in the form of a textual message at program startup or * in documentation (online or textual) provided with the package. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * "This product includes cryptographic software written by * Eric Young (eay@cryptsoft.com)" * The word 'cryptographic' can be left out if the rouines from the library * being used are not cryptographic related :-). * 4. If you include any Windows specific code (or a derivative thereof) from 52
* the apps directory (application code) you must include an acknowledgement: * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" * * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] */ The Legion Of The Bouncy Castle -----------------------------------------------Copyright (c) 2000-2009 The Legion Of The Bouncy Castle(http://www.bouncycastle.org) Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software" ), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sub license, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. 53