Monsoon Commerce Implementation Guide. Monsoon Commerce Payment Module Version 1.0

Transcription

1 Monsoon Commerce Payment Module Version 1.0

2 Table of Contents Revision history...3 Attribution...3 Introduction...1 What are PCI SSC and PCI DSS?...1 What is PA-DSS certification?...2 PCI compliance and validation...2 About the Monsoon Commerce Payment Module...2 PA-DSS and the Payment Module...3 Considerations for existing Stone Edge Users...8 Identifying database backups and cleansing credit card data...8 Data migration tool The effect of tokenization Best practices All users Third-party integrators Deployment of software Software updates Distribution of hotfixes Prepare the environment Enable SSL 128-bit encryption SQL Server setup requirements Set access policies Disable system restore Protect encryption keys Set up password-protected screensavers Monitoring, auditing, and logging events Product installation Review the system requirements Download the installer Execute the Stone Edge installer Configure the Payment Module Execute a payment transaction Data migration (previous users) Launch and configure Stone Edge Customer Support Overview Connecting to the customer s desktop Using the SDelete utility Audit the secure location of customer data Contact information Technical product information Product name and version Supported operating systems Supported databases Supported hardware Resellers/Integrators Typical customer Scope of PA-DSS assessment Product overview and workflow Page ii

3 Software dependencies Service dependencies Protocols Appendix A Obsolete Parameters Revision history The contents of this guide are reviewed and updated at least once per year. 1.7 November. 25, 2014 Clarify that SQL Authentication is not required for V7.1, PA-DSS. Updated Payment Module installer instructions. 1.6 July 7, 2014 Added installation step of downloading Ghostscript for PDFWriter. Updated Knowledge Base links. 1.5 December 18, 2013 Added information about the $0.01 transaction charged and voided by AuthNet during the customer recording process 1.4 September 4, 2013 Corrected text in Force encryption of database communications 1.3 April 4, 2013 Added the version number to the title page. 1.2 February 11, 2013 Miscellaneous Updates for PCI Compliance 1.1 January, Updates for Cybersource Gateway 1.0 December, Initial publication. Attribution The information regarding Microsoft software has been borrowed heavily from the Implementation Guide for PCI Compliance for Microsoft Dynamics Retail Management System, under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license. Page iii

4 Introduction Introduction The Monsoon Commerce Payment Module (Payment Module) is a standalone payment processing application provided with Stone Edge Version 7.1 and higher. Its purpose is to help merchants comply with the Data Security Standards (DSS) for Card Holder Data (CHD) security, as set forth by the Payment Card Industry Security Standards Council (PCI-SSC). The Payment Module was designed to meet all of the requirements for Payment Application Data Security Standard (PA-DSS) Version 2.0. This document also includes information about cleansing cardholder data stored by previous versions of Stone Edge, as another milestone on the path to PCI DSS compliance. What are PCI SSC and PCI DSS? In 2006, major financial companies American Express, Discover Financial Services, JCB, MasterCard Worldwide, and Visa International formed the Payment Card Industry Security Standards Council (PCI SSC). The purpose of the council was to create Payment Card Industry Data Security Standards (PCI DSS) to reduce fraud and other threats to cardholder data. The main objectives of the PCI DSS are listed below, along with examples of steps that can be taken by merchants and/or their vendors to meet those objectives: Build and Maintain a Secure Network o Install and maintain a firewall to protect cardholder data o Do not use the vendor-supplied defaults for system passwords or other security parameters Protect Card Holder Data o Secure stored cardholder data o Encrypt the transmission of card holder data across open, public networks Maintain a Vulnerability Management Program o Use and regularly update anti-virus software o Develop and maintain strong systems and applications Implement Strong Access Control Measures o Restrict access to card holder data to need to know basis o Assign a unique ID to each person that has computer access o Restrict physical access to cardholder data Regularly Monitor and Test Networks o Track and monitor all access to network resources and card holder data o Regularly test security systems and processes Maintain an Information Security Policy o Maintain a policy that addresses information security More information can be found at Page 1

5 What is PA-DSS certification? Software development companies that distribute applications which handle or store credit card information must seek Payment Application Data Security Standards (PA-DSS) Certification as proof that the application can be implemented in accordance with the PCI-DSS guidelines. The PCI Security Standards Council itself does not require nor validate an application s compliance with the PA-DSS. PA-DSS certification is obtained through a Payment Application Qualified Security Assessor (PA- QSA). Qualified security assessors (QSA) provide validation of PA-DSS compliance. A list of qualified security assessors verified for payment application review is maintained by the PCI-SSC at: PA-DSS review of the Monsoon Commerce Payment Module for PA-DSS v2.0 certification has been performed by the following PA-QSA(s): Payment Software Company, Inc. (PSC) 591 W. Hamilton Avenue, Suite 200 Campbell, California US Contact Information: Phone: Fax: [email protected] Website: For more information about PA-DSS, visit PCI compliance and validation The PCI Security Standards Council itself does not require nor validate a merchant s compliance with their Data Security Standards. Individual payment processors, such as MasterCard or Visa, may require compliance with PCI DSS, depending on the volume of transactions processed annually. Check with your processor to determine your required level of compliance. QSAs provide validation of PCI Compliance. A list of qualified security assessors is maintained by the PCI at About the Monsoon Commerce Payment Module The Monsoon Commerce Payment Module (Payment Module) was designed using the latest information for secure coding techniques in accordance with PCI-DSS and PA-DSS requirements, and is annually subjected to PA-DSS certification by a Qualified Security Assessor (QSA). Page 2

6 The role of the Payment Module is to handle all aspects of payment processing for Stone Edge V7.1 and higher, regardless of whether the transactions are for ecommerce orders, Point of Sale orders or manually entered orders. When Stone Edge needs to process a credit or debit card transaction, it calls the Payment Module s API which provides the interface for accepting the card data, submitting it to the payment gateway and receiving the gateway s response. The Payment Module then returns the response data (which does not include any card data) and code control back to Stone Edge. The Payment Module is able to process manually keyed or swiped card transactions without the need to permanently store the cardholder s sensitive information. This is accomplished through the process of tokenization whereby the cardholder data is sent to the payment gateway in return for a token that permits the Payment Module to work with existing transactions and execute additional transactions against the customer s account without the presence of the customer s card information. The token is unique to the merchant and is useless to other parties that seek to acquire customer card information for illegitimate purposes. This interaction between the Payment Module and Stone Edge eliminates the need to store PAN (Primary Account Number) data in the Stone Edge store data file (database), thereby removing the Stone Edge application from the scope of PA-DSS certification. Merchants using these applications in tandem take a step closer towards becoming PCI compliant. Be aware, however, that the installation of the Monsoon Commerce Payment Module with Stone Edge V7.1 alone is not sufficient for a merchant to achieve PCI-DSS compliance. Other components of your environment must be reviewed and modified to adhere to PCI DSS, such as hardware, network and operating system configurations. Information about securing these areas is discussed later in this document. PA-DSS and the Payment Module PA-DSS Requirement 1: Card holder information, such as the card security code (CVV2), data from the card s magnetic stripe or any data from PIN entry devices used for Debit Card transactions is not stored in the Payment Module s database, system logs or debug logs. The Payment Module exceeds this requirement by also encrypting these data points while the information is maintained within RAM memory to prevent the information from being accessible should the PC write information from RAM memory to the Windows Swap File on hard drive. PA-DSS Requirement 2: The Payment Module does not store Primary Account Numbers (PAN) in its database or within the system log or debug logs. The PAN is only maintained within RAM memory for the life of the transaction and while in memory this data point is encrypted to prevent access to the information should the PC write information from RAM memory into the Windows Swap File on hard drive. At the completion of a transaction, the first six and last four digits of the PAN are recorded with the transaction information for customer reference purposes. The only location where a user of the Payment Module has access to the full PAN is at the Payment Terminal when hand keying a PAN or swiping a card to process a single transaction. Access to bulk card account numbers is not available to any user of the Payment Module. Page 3

7 Since the full PAN is not stored, the Payment Module does not need to support the encryption mechanisms identified within this requirement, thus, isolating the merchant from all cryptographic key management and data purging activities. PA-DSS Requirement 3: The Payment Module has its own User Security System which is able to track and restrict each employee s level of access to the application and its functions. A unique User ID and Password must be assigned to each employee who requires access to the Payment Module. User passwords are not maintained within the Payment Module s database. Passwords are run through a proprietary hashing algorithm prior to evaluation and storage within the system. The Payment Module requires the use of an Administrators group which is established when the system is initially launched. The first user of the application is prompted to enter a User Name and PCI compliant Password to gain access to the application, and is assumed to be a member of the Administrators group. Additional user accounts (Admin or non-admin) can be added after the initial administrator account is defined. Specific permissions for non-admin accounts can be granted when the account is added, or they can be edited at a later date. A second administrator account, MCTech, is also created when the Payment Module is initially launched and is exclusively for the use of Monsoon Commerce technical support staff. This account is disabled by default and cannot be used by Monsoon Commerce support staff until a local administrator enables it. This account uses a password algorithm that requires a new password daily. The password is generated through the use of a proprietary password application which is only available to Monsoon Commerce technical support staff. The use of this administrator account eliminates the need for the Monsoon Commerce support personnel to acquire the end user s login credentials when testing or debugging the Payment Module. At the completion of support activities, the local administrator is instructed to deactivate the account, preventing any unauthorized access by Monsoon Commerce technical support staff. Payment Module passwords follow PCI DSS guidelines, whereby users must change their passwords periodically (minimum of 30 days to a maximum of 90 days). Reuse of previous passwords is restricted to a minimum of four (default) to a maximum of six previous passwords. Invalid login attempts are also limited to a user-defined number between a minimum of three to a maximum of six (default) before an account is locked out. The lockout period is also defined by the user and can be a minimum of 30 minutes (default) to a maximum of two hours. An administrative account can override the lockout condition by resetting the password for the account. At least two local administrative User IDs should be created in the event an Administrator gets locked out. User account information for Payment Gateway access is also maintained within the Payment Module. Sensitive credentials are stored in an encrypted format when stored in the database. When these credentials are used to process transactions, they are transmitted to the payment gateway utilizing the https protocol, which must employ 128 bit SSL 3.0 encryption standards. Settings to establish this level of security are configured within Internet Explorer or other browser software and are detailed in the Enable SSL 128-bit Encryption section. Note: The use of the Stone Edge security system is still optional, however, its use is highly recommended. PA-DSS Requirement 4: The Payment Module employs an Event logging system which records user and system activity in both the Payment Module s database and in the workstation s Windows Event Log. For details on what information is recorded in the Payment System s log, Page 4

8 see the section, Monitoring, Auditing and Logging. PA-DSS Requirement 5: Monsoon Commerce ensures that all developers who contribute to the production of the Payment Module are trained in the most current secure coding standards and constantly seek to remain abreast of the latest security concerns. Any code changes undergo mandatory code review by trained personnel prior to it being released to our Quality Assurance group. The release code is also tracked through the use of a digital signature to ensure that changes have not occurred throughout the chain of ownership from the initial developer to the end user. The Payment Module is not distributed with any test accounts or data. The creation of the Payment Module s database is scripted at initial startup and does not create testing accounts for use by the end user. End users also must ensure that if they perform any testing of the Payment Module that they do so using test payment gateway accounts and test PANs. The most commonly used test card numbers are listed below, and can be used with any expiration date in the future. Remember that Payment Gateway sandbox (test) accounts should never be considered secure and should never be tested using live account numbers: Visa: (yes, valid card number) MasterCard: Discover: American Express: Should you wish to test other card issuers (JCB, Diner s Club, etc.), contact the issuer directly for test account numbers honored by the banking system. Changes to the Payment Module program code are tracked internally by a ticketing system, and requires a review and signoff by multiple departments to ensure the system is stable and secure prior to being released. New releases of the Payment Module are distributed as a complete replacement of the original product code base. There are no patch installations for code updates. Page 5

9 PA-DSS Requirement 6: It is not recommended to run the Payment Module in an environment that employs a wireless network. Performance will be degraded as the system s database grows. If this recommendation is disregarded, PCI requires that you: o Install a firewall between any wireless networks and systems that store cardholder data and configure the firewall to deny or control the traffic from the wireless portion of the environment into the portion of the network where cardholder data resides. o Use strong encryption for all wireless networks, such as AES. o Use WPA/WPA2 rather than WEP. o Ensure firmware on wireless devices is updated to support strong encryption for authentication as well as for transmission over wireless networks. o Change the default settings on your wireless router or modem. Some examples of settings to change are, encryption keys, default service set identifier (SSID), passwords or passphrases of access points, etc. Change your encryption keys when employees with knowledge of them leave the company. PA-DSS Requirement 7: Monsoon Commerce actively reviews the latest information pertaining to application security vulnerabilities from the following sources: SANS: The SANS Institute s top 25 application vulnerabilities: Microsoft: Banned API calls for the Windows Operating System: OWASP: Open Web Application Security Project s Top 10 web application vulnerabilities: Should vulnerabilities be identified from the above lists or internal requirements that may impact the Payment Module or one of its dependencies, the Monsoon Commerce QA and Development teams create a case ticket to investigate whether the vulnerability affects the security of the Payment Module. Test cases are developed jointly by those groups and are performed by the QA team to determine the Payment Module s susceptibility to the vulnerability. If the vulnerability is confirmed, a new case ticket is issued to the Development team to make corrections to the code. Upon completion of the code modifications, the QA team executes the previous test case to ensure the successful remediation of the vulnerability prior to update release to the public. All program updates are distributed as a complete code replacement for the Payment Module. Patching a portion of the installation is not supported by Monsoon Commerce at this time. Code releases are digitally signed by the development team to ensure code validity throughout the QA process and the installer build. End users can verify the code installer s authenticity via a digital signature applied to the installer prior to public distribution. PA-DSS Requirement 8: The Payment Module does not require special considerations when installing it within a secured network environment. The Payment Module communicates with payment gateways using Port 80 (http protocol) and Port 443 (https protocol) and does not require opening any inbound ports in the firewall. The Payment Module does not require disabling anti-virus applications, however, depending on performance requirements, certain anti-virus vendors may be recommended by Monsoon Page 6

10 Commerce. PA-DSS Requirement 9: The Payment Module and Stone Edge do not require their databases to reside on a Web server or in the DMZ (demilitarized zone) of your local network. Although the Payment Module and Stone Edge do not store sensitive cardholder data, the Payment Module does maintain your gateway access credentials; therefore, every effort should be made to protect these credentials and other customer information such as names, addresses, addresses and phone numbers. It is highly recommended that the applications databases are located behind a firewall on a dedicated database PC or server which has limited user access. PA-DSS Requirement 10: Remote access directly to the Payment Terminal is not supported. Remote access to the client PC on which the Payment Module resides via Terminal Services, GoToMyPC, etc., is not recommended or supported by Monsoon Commerce. Cardholder data transmitted between the client PC and the terminal PC could be subject to interception and is not recommended according to PCI guidelines. If this type of connection is a requirement, then the merchant must take all available precautions to ensure that client to terminal communications are encrypted and that two-factor authentication is used to validate the user. Verify this requirement with your QSA prior to implementation. Remote access to the client PC on which the Payment Module resides may be necessary for Monsoon Commerce technical support for testing or troubleshooting purposes. Monsoon Commerce uses Citrix s GoToAssist application for user support. This application encrypts client/terminal communications and offers two-factor authentication for support personnel validation and requires the merchant to grant access to the support session before the GoToAssist session is initiated. For more information regarding GoToAssist go to PA-DSS Requirement 11: The Payment Module does transmit cardholder data over public networks and/or the Internet; therefore, it is required that you implement 128-bit SSL (Secure Socket Layer) encryption between the client PC and the credit card gateway. Settings regarding Internet communications are configured within Microsoft s Internet Explorer or other browser application. More information is available in the Enable SSL 128-bit Encryption section of this document. Encrypted communications require outgoing access to Port 443 (https protocol). The Payment Module does not allow users to view or send full cardholder data via or other messaging technologies. The Payment Module does retain the first six and last four digits of the Primary Account Number (PAN) and the card expiry date for customer service account identification purposes; however the central 3-6 digits of the PAN are unavailable. PA-DSS Requirement 12: The Payment Module does not support Web-based or remote administration, including non-console administrative access. If you plan to use these methods, review them with your QSA prior to implementation. PA-DSS Requirement 13: Monsoon Commerce provides this Implementation Guide as well as an online Knowledge Base for users to review prior to installing the Payment Module. Documentation is reviewed for each application release, or annually at a minimum, to ensure Page 7

11 the content is relevant to the current application release and PA-DSS/PCI-DSS requirements. Monsoon Commerce does not employ resellers or integrators, therefore training documentation for third party vendors is not provided. Considerations for existing Stone Edge Users Identifying database backups and cleansing credit card data Older versions of Stone Edge stored card holder information in the store data file (database). While Stone Edge, V7.1 and higher, provides a utility for cleansing cardholder data from the production database, you must not overlook the cardholder data stored in any archive, backup, or road trip data files. Be sure to cleanse or delete those files that may be stored offsite as well as onsite. Cleansing or complete removal of this data is absolutely necessary for PCI DSS compliance. By default, backups of MS Access store data files created by Stone Edge are located in the folder specified by the Order group system parameter ArchiveLocation. If you are using an SQL database, consult SQL Server Management Studio settings to determine the location of database backups (.bak files), as Stone Edge does not make backups of SQL databases. 1. Create a list of affected files and decide whether to cleanse the cardholder information from these files, or forensically delete the files from your hard drive, in accordance with PCI DSS requirements. Depending on the version of Stone Edge, the naming convention of backup files differs slightly: Stone Edge Version 7.0+ uses the format: StoneEdgeDataBUYYYYMMDD Stone Edge Versions 5.9 and lower use the format: OrderManagerDataBUYYYYMMDD 2. For files to be deleted, be sure to use an application that securely removes the file contents from your hard drive. An example of a secure delete application is the free Microsoft SysInternals Suite (sdelete function), which overwrites the data on the physical disk drive. More information can be found at the following URL. a. Copy the file sdelete.exe to the C:\Windows\System32 folder on your computer. b. Open a command prompt. c. To delete a single file, type: sdelete p # \\fileserver\foldername\filename For example, to securely delete a file called Store A Orders.mdb that resides on a server named Server1, in a folder named CustomerData, you would type: sdelete p 7 \\Server1\CustomerData\ Store A Orders.mdb Page 8

12 The p # switch indicates the number of times the physical location of the data is overwritten. In this example, the program makes seven passes. The file extension must be included as part of the filename. File names with spaces must be surrounded by quotation marks. Those who prefer a graphical user interface rather than a command prompt can use an application called Eraser. It can be downloaded, installed and configured in a matter of minutes from the following URL: 3. For production or backup database files to be retained (SQL or Access), a data migration tool is provided when the application is installed. You must manually run the tool against these database files to ensure PCI compliance. See Data Migration in the Product Installation section for more information. 4. Historical paper documents such as invoices or reports may also contain sensitive cardholder data, such as PAN. These documents must be maintained in a secure location or they should be destroyed in an appropriate manner, such as cross-cut shredding. 5. Order information from shopping carts which pass cardholder data to Stone Edge must be checked for residual order files that may contain unencrypted cardholder data. a. File locations specified by the Order group system parameters NewOrderLocation or ArchiveLocation may contain substantial amounts of payment information. Forensically remove these files with a secure file deletion utility like Eraser or sdelete. b. Also review the Security group system parameter DeleteDownloadTextFiles. If this parameter is set to TRUE, Stone Edge deletes the files it downloads from the shopping cart. The deletion is performed by the Windows operating system installed on the given PC, which does not actually remove the file contents from the hard drive; it only removes the filename from the drive s indexing system. The contents of the file remain on the drive until the operating system writes new data to that location, making it possible to retrieve the file contents using drive recovery software. Setting parameter DeleteDownloadTextFiles to FALSE makes it easier to locate and remove files that contain unsecured payment information. To ensure remnants of order files previously deleted by Stone Edge are removed from the hard drive, use the freeware application Eraser to overwrite data in unused disk space. You are able to schedule a task to automatically perform this function on an ongoing basis. 6. Users of the CyberSource payment gateway who installed a version of the Simple Order API Client for ASP having a version earlier than v5.0.0 may have a CyberSource log file on the root of the c:\ drive of their computer which will likely contain card account numbers. The file is named cybs.log and is a hidden file. This file must be forensically removed from each PC where CyberSource payments have been processed. Should an earlier release of the Simple Order API Client for ASP be installed, the user must uninstall the earlier release, then download and install the latest release of the API from CyberSource s website. As of this publication, the most current release is v5.0.0 and can be found under the Developer Download section of the CyberSource website. This release can generate log files depending on the Payment Account Setting UseLog, however, the logs created now show only the first six and last four digits of the card account number. Page 9

13 Data migration tool The migration tool populates the new Payment Module database with active transactional data currently stored in the selected Stone Edge database after cleansing the Primary Account Number (PAN) from all locations in the Stone Edge database. The cleansing process retains the first six and last four digits of the PAN, X filled to the original card length, which is permissible according to PA-DSS requirement 2.2. The Payment Module itself does not store the full PAN for any transactions it receives during the data migration process; however, if the user employs a gateway that supports a customer information management system, the Payment Module can attempt to record the customer s card information at the gateway and retrieve a token to be used for future transactions against the customer s account. Once the cleansing of the Stone Edge database and data migration to the Payment Modules database is complete, Stone Edge is able to process credit and debit transactions through the Payment Module. See Data Migration in the Product Installation section for more information. The data migration tool must be run to remove any magnetic stripe data, card verification codes, PINs, or PIN blocks stored by previous versions of the Stone Edge application. Removal of this data is absolutely necessary for PCI DSS compliance. When the Switch Stores feature attaches the program to an un-cleansed database, the user is notified the database is not PCI compliant. At that time, you must run the Data Migration Tool against that database before credit or debit payment transactions can be performed through the Payment Module. If you have manually stored cardholder data in the Notes or any other text field in the Stone Edge database, you are not PCI compliant. The data migration tool only cleanses locations where the program stores PAN data. Therefore, you are responsible for removing or cleansing the PAN from any other fields. The effect of tokenization A merchant s ability to run new credit card transactions may be limited by the specific credit card processors and/or shopping cart systems they utilize with the Payment Module and Stone Edge. Merchants must ensure that the gateways offering a Customer Management System are also supported by their shopping cart. If a shopping cart does not support the customer management capability of the gateway and the gateway does not support the use of previous transaction identifiers for new payments, then the tokenization feature will NOT be available to the merchant. If this is the case, the merchant is limited to the use of an existing transaction generated by the shopping cart. Payment capture and credit is available for existing transactions; however, new transactions require the merchant to contact the cardholder to obtain their credit card information. The Payment Module also supports the concept of multiple captures against a single authorization, provided the payment gateway supports this feature. Payment Gateways currently supported by the Payment Module: AuthorizeNet AIM Does NOT support tokenization AuthorizeNet CIM Supports tokenization through a Customer Management System Page 10

14 CyberSource Supports tokenization through a Customer Management System USAePay CGI Does NOT support tokenization USAePay XML API Supports tokenization through a Customer Management System and through the use of previous transaction identifiers Additional Payment Gateways may become available in subsequent releases of the Payment Module, depending upon user demand, PCI compliance and shopping cart support. Best practices All users This section contains some best practices that help the merchant move towards compliance with the PCI Data Security Standard (PCI DSS). To be sure that you are fully compliant, read and implement all of the requirements outlined at 1. Prohibit the use of default administrative accounts. a. The Payment Module does not provide a default user account at initial startup the initial administrator account must be created prior to using the application. b. SQL Express or SQL Server, when using mixed authentication, includes the sa or System Administrator account. This account must be disabled to maintain PCI compliance. For information on disabling the sa account see the section Manage SQL Server without using the sa account, in this document, or 2. Prevent the use of group, shared, and generic accounts in SQL Server/SQL Express. See PCI DSS Requirement for a procedure to identify this activity. 3. Limit access to any PC, servers and databases where payment applications or cardholder data resides by using unique User IDs and using secure authentication methods whenever possible. 4. Control access to the Payment Module, SQL Server/SQL Express, and Stone Edge by assigning unique User IDs to all employees that use those applications as part of their job requirements. Do not use the same password for your Stone Edge User ID as you do for your Payment Module User ID. 5. Review event logs periodically for unauthorized access or other suspicious activities. 6. Remote access is not recommended for the Payment Module or Stone Edge. a. If you still choose to use remote access, you must use two-factor authentication (User ID with a password or other authentication item, such as a smart card, token or PIN) to be PCI compliant. Utilities such as GoToMyPC are not recommended as they do not utilize two-factor authentication. Be sure to change the default settings in the remote access software, such as a default password. b. Only allow access from known (specific) IP or MAC addresses. c. Use strong authentication and complex passwords for logins, according to PCI DSS Requirements 8.1, 8.3, and d. Enable encrypted data transmission. PCI DSS Requirement 4.1 e. Configure the remote access software so that the user must establish a VPN (Virtual Private Network) connection through a firewall before access is allowed. Page 11

15 7. Turn on the logging features. a. The Payment Module s internal logging system is on at all times and cannot be disabled. b. Activate the Windows Event Log and activate SQL Server/SQL Express Logging. 8. Restrict authorized integrators/contractors access to merchant passwords. 9. Establish merchant passwords according to PCI DSS Requirements 8.1, 8.2, 8.4, and 8.5. The Payment Module requires that passwords meet the defined requirements in PA-DSS V Be sure to keep up with the latest security updates for your operating system and components, especially your browser software. 11. If you purchase a Stone Edge generic shopping cart license, you must ensure your integration script does not send cardholder data to Stone Edge in order downloads from the shopping cart in order to be PCI compliant. 12. Stone Edge only supports integrations with shopping cart systems that cleanse the Primary Account Number (PAN) and/or supports the use of tokens instead of cardholder data in order to process payment transactions. In other words, Stone Edge and the Payment Module do not need the PAN to process a transaction. a. If your shopping cart provides the option to send credit card data in the order download, you must disable that option at the shopping cart to be PCI compliant. b. If the Shopping Cart provides the PAN in the order download without providing the user with a way to disable it, Stone Edge imports the order information, but not the PAN, into its database. However, order files containing the unencrypted PAN may remain on your computer s hard drive. To remain PCI compliant, these files must be forensically removed after order import. Refer to the Identifying database backups and cleansing credit card section of this document for suggested tools. 13. Collect sensitive authentication data only when absolutely necessary to solve a specific problem. 14. Collect only the limited amount of data needed to solve a specific problem. 15. Store such data only in specific, known locations with limited access. 16. Encrypt sensitive data while it is stored on your network. 17. Sensitive data must be securely deleted immediately after use. Failure to implement the security steps outlined in this section means your system does not comply with PCI DSS requirements. Third-party integrators Third-parties that develop and troubleshoot custom code or provide installation services on the behalf of others should also adhere to the following best practices for PCI Compliance: Collect only the minimum amount of data required to resolve a specific problem Sensitive authentication data should only be collected when absolutely necessary to resolve a specific problem Sensitive data should be stored in a specific, known location to which access is limited to those individuals that are working to resolve the problem Sensitive data must be encrypted while it is stored Sensitive data must be forensically deleted immediately after the problem is resolved Page 12

16 Deployment of software Software updates Updates to the software are distributed via an Installer that replaces the entire set of application libraries. To obtain a copy of the new release of the application, the customer must login to a secure website and download the installer. ( Payment Module installer files are digitally signed by Monsoon Commerce and indicate the publisher at the time of installation. If the installer file does not identify the publisher as Monsoon Commerce, discontinue the installation and contact Monsoon Commerce support. ([email protected]) The Implementation Guide (this document) is reviewed and updated as necessary when a new release of the software is distributed. It is included in the Documentation subfolder of the program installation folder and is also available in the online Knowledge Base. Distribution of hotfixes Hotfixes are not distributed. Prepare the environment Enable SSL 128-bit encryption All payment gateways require communications via the Internet to take place using the HTTS protocol employing Secure Socket Layer (SSL) 128 bit encryption to protect the communications between the merchant s PC and the credit card processor s server. This is configured through Internet Explorer settings. 1. Launch Internet Explorer. 2. Go to Tools > Internet Options > Advanced. 3. Select the check box Use SSL 3.0 in the list of Settings. 4. Click Apply. 5. Click OK. SQL Server setup requirements This section discusses the SQL Server 2005 R2, SQL Server 2008 R2 and SQL Server 2012 setup steps required for PCI compliance. You can obtain information regarding hardening SQL Server/Express for PCI Compliance through the following article: The Payment Module uses SQL Server or SQL Express for its back end database. You may use an existing instance of SQL Server/SQL Express in which to create and maintain that database, or you can create a new instance of SQL specifically for the Payment Module. To comply with PA-DSS/PCI DSS, complete all of the following procedures on the computer where the SQL Server software is installed. Be sure to confirm all settings match those shown below. Page 13

17 Select the service account 1. In SQL Server Configuration Manager, click SQL Server Services. 2. Right-click the correct instance and then select Properties. 3. In the Built-in account box, select Network Service, and then click OK. Switch to mixed-mode server authentication 1. In SQL Server Management Studio, open the Object Explorer, right-click the instance, and then select Properties. 2. On the Security page, under Server authentication, select SQL Server and Windows Authentication mode, and the click OK. This does not mean that the databases for Stone Edge and the Payment Module are required to use SQL Authentication. In fact, it is recommended to use Windows authentication unless there is a valid business reason to do otherwise. This step merely allows the business owner the option of using SQL Authentication. Manage SQL Server without using the sa account Completing this section helps to satisfy Requirement 2 of the PCI Security Standard. 1. Open SQL Server Management Studio Object Explorer, and then expand the folder of the correct instance. 2. Set up a new administrator account: a. Right-click the Security folder, point to New, and click Login. b. On the General page, type a unique login name, select SQL Server authentication, and provide a strong password. c. On the Server Roles tab, select sysadmin, and then click OK. 3. Disable the sa account by expanding the Security folder, expanding the Logins folder, and then completing these steps: a. Right-click the account name, and then click Properties. b. Click the Status page, select Disabled, and then click OK. OR c. Run the sp_setautosapasswordanddisable procedure within SQL Server Mgmt Studio. As the name suggests, this procedure will set a random value for the sa account password then disables the account. It is recommended to re-run this procedure at regular intervals to prevent attempts to reactivate the account. Force encryption of database communications. 1. In SQL Server Configuration Manager, expand SQL Server Network Configuration. 2. Right-click the protocols for the Payment Module instance, and then click Properties. 3. On the Flags tab, select Yes for the Force Encryption option, and then click OK. When the Force Encryption option for the database engine is set to Yes, all client/server communication is encrypted and clients that cannot support encryption are denied access. Restart the SQL Server and put the changes into effect 1. In SQL Server Configuration Manager, click SQL Server Services. 2. Right-click SQL Server (<instance name>), and then click Restart. Page 14

18 Set access policies Set policies to manage access to workstations, the Payment Module, and Stone Edge. Complete steps 1-4 on each computer where those applications are installed. Step 5 is a global function of the Payment Module that only needs to be done once on a single workstation. 1. Disable the local Administrator account 2. Set up a password policy for Windows 3. Setup a domain password policy 4. Setup a local password policy 5. Setup a password policy for the Payment Module. Disable the local Administrator account This account is disabled by default in Windows 7. Setup a password policy for Windows users Requirements through specify password and account security regulations for people with administrative access to the payment application. You can meet these requirements by establishing a password policy for Windows users. Policy settings that meet the requirements are set out in the following table. The policies in the table reflect the minimal requirements for PCI compliance. More stringent settings can be used. Policy Enforce password history Maximum password age Minimum password length Password must meet complexity requirements Account lockout duration Account lockout threshold Security setting 4 passwords remembered 90 days 7 characters Enabled 30 minutes 6 invalid logon attempts Periodically check PCI Data Security Standards for any changes to the latest password requirements. Setup a domain password policy If you are running the Payment Module on a domain, contact the domain administrator to establish group policies for the domain. For more information about managing password policy via group policies, see Working with Group Policy objects at Setup a local password policy If you are running the Payment Module in a workgroup, you must complete the following procedure on each computer in the network. 1. Click Start, and then click Control Panel. Page 15

19 2. View the full list of Control Panel items. Depending on your operating system, do this either by switching to Classic View or by clicking Small icons in the View by box. 3. Click or double-click Administrative Tools, and then double-click Local Security Policy. 4. Expand the Account Policies folder, and then change the settings under Password Policy and Account Lockout Policy as needed to meet the requirements in the table above. Set up a password policy for employees that use the Payment Module The default User ID and password settings in the Payment Module meet the PCI minimum standards, but you can change them to be more stringent by going to Main Menu > Settings. It is not possible to change the length of the password or the complexity requirements. Refer to the online Knowledge Base for Version 7.1 for more details. Policy Default setting Minimum password length 8 characters Password must meet complexity requirements Must contain at least one character from each of the following categories: upper case, lower case, number, and special etc.) Session Timeout (inactivity before logout) 15 minutes Max Login Attempts (failed) 6 Lockout Duration (amount of time to wait after 30 minutes failed login attempt) Password Duration (expiration) 90 days Password Reuse (number of previous passwords 4 to track)) The count of failed login attempts is reset on successful login. Password age is calculated from the date when the password was last changed. Disable system restore System Restore is a Windows feature that helps you restore the files on your computer to an earlier point time. The restore points saved by this feature are not considered secure by the PCI SSC. For Windows 7 1. On the Start menu, right-click Computer, and then select Properties. 2. Click System protection. 3. Select the C: drive, click Configure, select Turn off system protection, and then click OK. Protect encryption keys Monsoon Commerce Payment Module does not store PAN data and therefore does not use encryption keys to secure it, making the protection of encryption keys out of scope for PCI compliance. Page 16

20 Set up password-protected screensavers At each register (workstation), change the settings so that a screensaver comes on when the register has been inactive for a maximum of fifteen minutes (900 seconds), or less. The screensaver should require the employee to enter their Windows password to unlock the screen. In the C:\Windows\System32 folder, locate the name of the screen saver (.scr) file that you want to use. For Windows 7 1. Click Start, type mmc into the search box, and press Enter. 2. On the File menu, click Add/Remove Snap-in and then, if you are running Windows XP, click Add. 3. Select group Policy Object Editor, click Add, click Finish, and then click Close or OK. 4. Expand Local Computer Policy, expand User Configuration, expand Administrative Templates, expand Control Panel, and then click Personalization (in Windows 7) or Display (in other operating systems). 5. Double-click Force specific screen saver (in Windows 7) or Screen executable name (in other operating systems), select Enabled, type the path and name for the screen saver (.scr) file that you selected in step 1, and then click OK. 6. Double-click Password protect the screen saver, select Enabled, and then click OK. 7. Double-click Screen Saver timeout, select Enabled, type 900 or less, and then click OK. Completing this procedure on each computer helps to satisfy Requirement of the PCI DSS. The Payment Module The Payment Module has a user definable automatic logout feature that has a minimum of five minutes to a maximum of fifteen minutes. Should the workstation be idle for the given period, the user is logged out of the Payment Module (but not Stone Edge) and is required to log back in the next time a transaction is executed. Monitoring, auditing, and logging events Failure to enable the tools used to produce an audit trail of all activity related to sensitive data results in noncompliance with PCI DSS. Most of the items discussed in this section pertain to Requirement 10 of the PCI DSS. The Payment Module logs activity in its own database and in the Windows Event Log. For the Windows Event Log to be populated with the Payment Module s activities, the Windows Event Log must be enabled on each PC running the Payment Module. You can centralize the collection of Windows Event Log information on a single server for your convenience by using a tool such as Snare, or by reviewing the directions in this article. Enable windows event logging The following steps help you to comply with PCI DSS Requirements 10.2 and 10.3, and should be performed on all computers. For Windows 7 Page 17

21 1. Click Start, type Event Viewer into the search box, and press Enter. 2. Expand the Windows Log s folder. 3. Right-click Security and select Properties. 4. In the Maximum log size box, type Select Overwrite events as needed, and then click OK. Configure the auditing of files, objects and audit-policy changes Changes to each computer s audit policy can be recorded by implementing the following procedures on all computers. If your computers are on a domain, be sure to check with the Domain Administrator to ensure that local audit policies are not overwritten by domain policies. For Windows 7 1. Click Start, type Local Security Policy into the search box, and press Enter. 2. Double-click Audit account logon events and select both the Success and Failure check boxes. 3. Click OK. 4. Double-click Audit account logon events and select both the Success and Failure check boxes. 5. Click OK. 6. Double-click Audit object access and select both the Success and Failure check boxes. 7. Click OK. 8. Double-click Audit policy change and select both the Success and Failure check boxes. 9. Click OK. Enable audit access to system files and folders Depending on the operating system, different system file and folders need to be audited. Although the Payment Module and Stone Edge do not store any sensitive cardholder data, if you want to audit changes made to system files and folders, follow the procedure below for each file or folder in the list for your operating system. 1. In Windows Explorer, right-click the folder name, and then click Properties. 2. On the Security tab, select Advanced. (If Advanced is not visible, click Folder Options on the Tools menu. Click the View tab and clear the Use simple file sharing check box.) 3. Click the Auditing tab. (If a security message appears, click Continue.) 4. Click Add. 5. In the Enter the object name to select box, type Everyone, and the click Check Names. 6. If the name is valid, click OK. 7. In the Apply onto box, make sure that This folder, subfolders and files is selected. 8. In the Access list, select both the Successful and Failed check boxes for the following privileges, and then click OK. Create files/write data Create folders/append data Delete subfolders and files Delete Read Permissions Change permissions Page 18

22 9. If the settings above provide more auditing than is already setup for this folder, select the Replace all existing inheritable auditing entries check box, and click OK. 10. Click OK in the remaining dialog boxes. For Windows 7 1. C:\Windows\System32\winevt\Logs 2. The Payment Module does not currently write its own file based logs. Data is written to the Payment Module s database and the Windows Event Log. a. The default installation folder for the Payment Module is: c:\program Files\Monsoon Commerce\PayMgr\ 3. SQL Server data files and log files are stored in separate locations. a. The default installation location for an SQL Data File: c:\program Files\Microsoft SQL Server\MSSQL##.@@@@@@\MSSQL\DATA\DBName.mdf where ## represents the SQL version number represents the named instance of the SQL Server (if the instance is named). b. The default Installation location for the SQL Transaction Log File: c:\program Files\Microsoft SQL Server\MSSQL##.@@@@@@\MSSQL\DATA\DBName_log.ldf where ## represents the SQL version number represents the named instance of the SQL Server (if the instance is named). c. Default Install location for SQL Error Log File: Monitor the event logs c:\program Files\Microsoft SQL Server\MSSQL##.@@@@@@\MSSQL\Log\ where ## represents the SQL version number represents the named instance of the SQL Server (if the instance is named). Use the Windows Event Viewer to see information about the events that are being logged. You can control the way event logs are managed by opening the Event Viewer, selecting Windows Logs in the navigation pane and selecting Application >Properties in the right-most pane. Instructions for enabling the Windows logging feature are provided earlier in this section. For Windows 7 1. Click Start, type Event Viewer into the search box, and press Enter. 2. If available, expand the Windows Logs folder, and then click Security. Each event has a unique Event ID, and the following information is logged for each event: The Windows user account involved in the action The type of event, as well as the date and time the event took place The success or failure of the action Page 19

23 The point of origination of the event The name of affected data, component, or resource If applicable, the user group to which a user was added or removed The following table shows the Event IDs for actions of interest within the Windows OS: Action EventID Windows 7 Logon attempt 4776 Logon success 4624 Logon failure 529, 535, 539 Logoff 538 User password reset 4724 User account created 4720 User account disabled 4725 User account deleted 4726 User account added 4728 User account changed 4738 User account locked out 4740 Member added to user group 4733 Object access (updated or _ deletion of monitored files) File modified and saved 4663 Audit policy changed _ Domain policy changed 4739 Event Viewer Security log 1102 cleared The following table shows the Event IDs for actions of interest within the Payment Module: Login Successful 1 Login As Admin Successful 2 Login Unsuccessful 3 Log Out 4 Login Locked Out 5 Login Lockout Reset 6 User Change Password 11 User Change Password Unsuccessful 12 Admin Add User 21 Admin Add User Unsuccessful 22 Admin Edit User 23 Admin Edit User Unsuccessful 24 Admin Delete User 25 Admin Delete User Unsuccessful 26 Admin Enable User 31 Admin Enable User Unsuccessful 32 Page 20

24 Admin Disable User 33 Admin Disable User Unsuccessful 34 Admin Unlock User 35 Admin Unlock User Unsuccessful 36 Admin Reset Password 41 Admin Reset Password Unsuccessful 42 Admin Extract Log 51 Admin Security UI Access 52 Admin Security UI Access Denied 53 Admin Security Log Access 54 Admin Security Log Access Denied 55 System Convert User Table 61 Pay Admin UI Access 100 Pay Admin UI Access Denied 101 Pay Source Add 110 Pay Source Add Unsuccessful 111 Pay Source Edit 112 Pay Source Edit Unsuccessful 113 Pay Source Delete 114 Pay Source Delete Unsuccessful 115 Pay Account Add 120 Pay Account Add Unsuccessful 121 Pay Account Edit 122 Pay Account Edit Unsuccessful 123 Pay Method Add 130 Pay Method Add Unsuccessful 131 Pay Methods Edit 132 Pay Methods Edit Unsuccessful 133 Pay Methods Delete 134 Pay Methods Delete Unsuccessful 135 Pay Method BIN Add 140 Pay Method BIN Add Unsuccessful 141 Pay Method BIN Delete 142 Pay Method BIN Delete Unsuccessful 143 Pay Permissions Edit 150 Pay Permissions Edit Unsuccessful 151 Pay Terminal Access 160 Pay Terminal Access Denied 161 Pay Terminal Action 162 Pay Terminal Action Denied 163 Pay Parameter Access 170 Pay Parameter Access Denied 171 Pay Parameter Edit 172 Pay Parameter Edit Unsuccessful 173 System Object Created 200 Page 21

25 System Object Initialized 210 System Object Released 220 System Object Destroyed 230 Auth Init Successful 300 Auth Init No Users 301 Auth Init No Admin User 302 Auth Init Failed Windows Login 303 API Event 400 API Error 401 Microsoft SQL Server Enable C2 auditing This section discusses how to log database administrator activity by enabling C2 auditing in SQL Server. C2 refers to a security rating for computer software that was established by the U.S. National Computer Security Center (NCSC). It requires individuals to log on with a password, auditing must be enabled, and access to audit data must be restricted to authorized administrators. C2 auditing is enabled by using SQL Server Management Studio (SSMS) or SQL Server Management Studio Express (SSMSE, available from the Microsoft Download Center). Please be aware that C2 Audit Mode data is saved in a log file in the Data directory for your database. When the audit log file reaches its size limit of 200 megabytes, SQL Server creates a new file, closes the old file, and writes all new audit records to the new file. This process is repeated until auditing is disabled or the Data directory becomes full. The database log file can fill up quickly as C2 Audit Mode saves a large amount of event information. If auditing is set to start automatically, you must carefully monitor the space allocated to the Data directory and make sure there is enough free space or SQL Server will shut itself down when the directory becomes full. Review C2 audit trace files The events to look for in the C2 audit trace files are those created when the login ID of a database administrator accesses the database and performs a given action such as viewing a table or removing data. Each event shows the SQL user that performed the action. Event Type DBA logins Viewing the audit log table Search for statements (TextData) that begin with this text If(object_id( masterdbo.sp_mssqldm090_version ) is not null) Select * from AuditLog Refer to the following articles for more information: Page 22

26 SQL Server Management Studio Express (SSMSE) Enable C2 auditing 1. On the Start menu, click All Programs. 2. Select Microsoft SQL Server 2008 and then select SQL Server Management Studio or SQL Server Management Studio Express. 3. In the Connect to server dialog box, select the following settings: a. Select Database engine in Server type. b. Select the server/instance name of the database in Server name. c. Select Windows Authentication in Authentication. 4. Click Connect. 5. Right-click the instance specified in step 3, and click Properties. 6. Select Security in the Server Properties window. 7. Under Login auditing, select Both failed and successful logins. 8. Under Options, select Enable C2 audit tracing. 9. Click OK. 10. Right-click the instance and click Stop, and then right-click the instance and click Start. Review a trace audit file 1. In SSMS or SSMSE, connect to the appropriate SQL Server instance and database. 2. Right-click the instance, and then click Stop. 3. On the File menu, point to Open, and then click File. 4. Navigate to the folder where the trace files are located. 5. Use the dates within the file names to locate the appropriate trace (.trc) file, select, it and the click Open. The trace file opens in SQL Profiler, where the event details can be viewed. 6. When finished looking at the trace file, close it and right-click the instance and click Start. Enable auditing in the Payment Module The Payment Module s internal logging system is active at all times and cannot be disabled by the user. Enable auditing in Stone Edge No activity logging or activity auditing capabilities exist within the Stone Edge application. Other tools to monitor Stone Edge employee activities View the System Log Although the Payment Module and Stone Edge do not store sensitive cardholder data, you may want to keep an eye on changes made to other important areas, such as Changes to Users and Security Permissions Changes in Payment Accounts or API credentials Page 23

27 Changes to Payment Sources or Payment Methods Changes to Payment Account assignments to Payment Sources Changes to logged data. (The System Log can indicate if records in the database log have been manually altered.) To open the System Log viewer, select System Log on the Main Menu of the Payment Module. Daily Audit Report for Point of Sale The Daily Audit System is designed for cash drawer resolution at end of shift or end of day. The use of this system allows a user to reconcile transactions recorded for a given PC and or User against the actual receipts collected during the same period. The system can be a good indicator of fraud when reviewed regularly. In Stone Edge, go to Main Menu > Settings > Order Functions > Daily Audit. Product installation A copy of the Payment Module must be installed on every workstation where a copy of Stone Edge is installed, even though the Payment Module uses a single back-end database. Review the system requirements Verify that a supported version of SQL Server/SQL Express is installed or can be installed. Make sure all available service packs for the OS, SQL Server, and MS Office (Access) are installed. If you are a previous Stone Edge user and want to use an existing store file, ensure that all cardholder data has been cleansed by the method described in the section, Considerations for previous Stone Edge users. Phase 1 Install SQL Express The Payment Module uses an SQL database for data storage. This only needs to be done once, on a single computer which acts as the database server for the Payment Module. SQL Express (free edition) can be downloaded from the Microsoft web site, if you do not have SQL Server installed. SQL Express does have a database size limitation of 10GB. Double-click the installer and the SQL Server Installation Center appears: 1. Select New installation or add features to an existing installation. 2. Review the Microsoft User agreement and select I accept the license terms. 3. Click Next to continue. 4. Select Install on the Setup Support Files screen. 5. Click Next on the Feature Selection screen. 6. On the Instance Configuration screen, enter a Named instance, if you wish, or leave the default name as SQLExpress. 7. Click Next to begin the installation of SQL Express. 8. Select Next on the Server Configuration screen to accept the default settings and continue. 9. Click Next to accept the default settings (recommended) and proceed to the next step. 10. On the Error Reporting screen, click Next. 11. Select Next on the Installation Progress screen to copy files, etc. This process may take 5-10 minutes to complete. Page 24

28 12. At the conclusion of the process, you are presented with the Complete screen, which shows the outcome and contains a link to the installation log file. 13. Click Close to end the SQL Express installation process. Download the Stone Edge and Payment Module installers Go to the Monsoon Commerce download gateway and log in with the User ID and Password provided in the order confirmation sent by Monsoon Commerce when you purchased the program. Download the installers for Stone Edge and the Payment Module, and save them in a place that is backed up regularly. Execute the Stone Edge installer Phase 2 install Stone Edge 14. Navigate to the location of the Stone Edge installer downloaded from the Monsoon Commerce website. 15. Right-click the desktop icon and select Run as administrator to launch the installer. 16. Although the installer package is not digitally signed by Monsoon Commerce, Inc., select Yes. 17. Select Next to continue. 18. Review the Monsoon Commerce Licensing Agreement. Select I accept the terms in the license agreement and Agree to continue with the product installation. 19. Select Next to install Stone Edge to the recommended location of c:\stoneedge\. 20. Select Install to begin copying the files. 21. Select the link to Install Ghostscript and download the correct version for the operating system of the current machine. Install Ghostscript and select I Agree when prompted with the License Agreement. 22. To conclude the installation of Stone Edge, select Finish. Review the ReadMe file. Phase 3 install the Payment Module 23. Right-click the Payment Module installer and select Run as administrator. 24. Verify the installer package is digitally signed by Monsoon Commerce, Inc. and select Yes. 25. Select Next to begin the installation of the Payment Module. 26. Review the Monsoon Commerce Licensing Agreement. Select I accept the terms in the license agreement and Agree to continue with the product installation. 27. The installation of the Payment Module runs to completion. Configure the Payment Module 1. Double-click the desktop shortcut to launch the Payment Module or select it from the Windows Start Menu. 2. Identify the SQL Instance to use for the Payment Module s database. 3. Leave the check box clear to use Windows authentication (highly recommended). If SQL Authentication is used, select the check box to establish the login credentials. First time installation: Page 25

29 a. Specify a name for the Payment Module s database. The name must begin with MonsoonPaySys b. Select Create Database. Reinstalling or upgrading an existing installation: a. Select the name of the database used with the Payment Module b. Select Run Script to update the database schema to current requirements 5. Select Save to record the database settings. 6. The first time the program is launched, you are prompted to create the initial administrator User ID and Password. 7. Login to the application and: a. Define other users. b. Define additional credit card payment methods. The following payment methods are pre-defined in the program: Visa MasterCard Discover American Express echeck c. Define Payment Accounts. See the section Defining Payment Accounts for more information. d. Define Payment Sources. See the section Defining Payment Sources for more information. e. Define Payment Account/Payment Source/Payment Method associations. See the section Assigning Payment Accounts to Payment Sources for more information. Defining Payment Accounts A payment account is defined as a set of credentials which access a specific payment gateway account. The kinds of credentials required for a Payment Account are unique to the selected payment gateway when defining Payment Accounts. Previous releases of Stone Edge allowed the user to identify gateway credentials (user name, password, etc.) within the Credit Cards group of the System Parameters or Cart Based Parameters. With the release of Stone Edge 2012 V7.1, payment gateway credentials are no longer contained within the Stone Edge application. All payment gateway configurations take place in the Payment Module at the Payment Accounts and Assignments screen. 1. Select Payment Account Mgr on the Main Menu. 2. Select New to add a new Payment Account definition (or select an existing Payment Account and select Edit to make changes). 3. Enter a friendly name to identify the account in the Acct Name field. The name is limited to 255 characters, however, it is recommended to keep the name short for ease of use throughout the Payment Module. 4. Select the Gateway for the Payment Account. 5. Enter the appropriate credentials into the fields on the Access Credentials tab. The fields are different depending on the selected Payment Gateway. 6. Select Save to record the Payment Account or click Cancel to void the action. Page 26

30 Payment gateway credentials defined as password type data points are not visible once the value is submitted (the cursor is moved to another control). Please be certain to review the values you enter here prior to submission, as there is no secondary confirmation of the value entered. Also be careful not to include extra non-printing characters, such as a blank, when copying and pasting values into parameters as it may cause validation problems at the payment gateway. IMPORTANT NOTE: If the Payment Account is using the CyberSource Payment Gateway, the user must download and install the Simple Order API Client for ASP directly from CyberSource s Website. This control can be found under the Developer Download section of their website. The current available release as of this publication is v5.0.0 and is a requirement to remain PCI compliant. Older releases of the control may work with the Payment Module, however, they are NOT PCI compliant and, if installed, will cause the user to be out of compliance. Older controls may generate a system log file called cybs.log which is a hidden file on the root of the c: drive of the computer which will contain card account numbers processed through the CyberSource gateway. For more detailed information about specific payment gateways, please review the Knowledge Base for Version 7.1. Defining Payment Sources A payment source is defined as a payment s point of origin. For Stone Edge users, this equates to the Manual Orders screen, the Point of Sale (POS) screen or an individual shopping cart definition (web store). Previous releases of Stone Edge used System Parameters and Special Parameters (cart-based) to identify the specific gateway to use for each of those areas of the program. Starting with the release of Stone Edge 2012 V7.1, payment gateway configuration is now performed in the Payment Module, which includes two pre-defined (standard) Payment Sources: Monsoon Commerce Payment Module: all payments directly originating in the Payment Module user interface Monsoon Stone Edge: all payments originating from the Stone Edge application The Monsoon Stone Edge payment source is initially the default payment source for all orders coming from Stone Edge. The account designated as its Primary payment account is the default account used to process all transactions. If you want to use different payment accounts for Point-of-Sale orders, or orders from individual shopping carts, define separate payment sources for each of those and assign the desired payment accounts to their respective payment sources. To create POS or cart-based Payment Sources: 1. Select Payment Account Mgr at the Main Menu. 2. In the section of the screen labeled Payment Source Assignments, click New. 3. Enter a friendly name for the Payment Source in Source Name. Names can be up to 255 characters in length, however it is recommended to keep them less than 50 for ease of use throughout the Payment Module. 4. If you intend to assign this source to: a. a specific shopping cart, copy the Source Identifier (Key) and paste it into the Stone Edge cart-based parameter, PaymentSourceKey, for the specific shopping cart. Payment requests coming from the specific cart are then properly linked to the proper Payment Source in the Payment Module. Page 27

31 b. If the Stone Edge POS system is used, create a POS Payment Source if the gateway account used for the POS is different than the gateway used for Manual Orders. Enter the new Payment Source s key into the Stone Edge parameter, PaymentSourceKeyPOS. 5. Click Save. Assigning Payment Accounts to Payment Sources Once a Payment Source is defined in the Payment Module, one or more Payment Accounts can be assigned to the Payment Source. An account s source assignment can be set to one of four values: Not Assigned: the Payment Account is not assigned to the Payment Source and cannot be used to process transactions from that source Primary Assignment: the Payment Account is assumed to be the default account when a new transaction is run for a given Payment Source. Secondary Assignment: the Payment Account may be used to process new transactions from a given Payment Source by manually selecting it from the Account list in the Payment Terminal. Conditional Assignment: this option allows the user to dictate the Payment Account that is used for specific Payment Methods for transactions from a particular Payment Source. In other words, this assignment results in the selected Payment Account being the primary account for the designated Payment Method for a given Payment Source. Assignments are made at the Payment Accounts and Assignments screen: 1. Select Payment Account Mgr on the Main Menu. 2. Select an account in the Payment Accounts section of the screen. 3. Select All Sources to display all of the currently defined Payment Sources. 4. Click in the Assignment column in the row of the Payment Source to which the account is assigned and select Primary, Secondary, Conditional or Not Assigned. a. If the Assignment type is Conditional, a list of the Payment Methods defined in the Payment Module appears at the bottom of the screen. b. Click in the Assigned field for each conditional payment method and select Yes to use this account as the primary Payment Account when this Payment Method is used in orders from selected Payment Source. 5. Click Save to record the changes. Execute a payment transaction Test the configuration of the Payment Module 1. Ensure at least one Payment Account is assigned to the Monsoon Stone Edge payment source or whichever payment source is set as the System Default. Also ensure that the Payment Account assigned to the source is set up to operate in test mode. 2. Click Make a Payment on the Main Menu to open the Payment Terminal. 3. Select a Payment Method such as Visa. 4. Key in a test card number such as and an expiration date in the future. 5. Enter an amount greater than zero. Page 28

32 6. Click Authorize or Authorize and Capture (SALE) to execute the transaction. Assuming the credentials are correctly established, you will receive a prompt noting the success of the transaction. Should the credentials not be set correctly, an error is displayed indicating the reason for failure. 7. Be sure to set the test mode of the Payment Account back to FALSE in order to execute live transactions. Data migration (previous users) Overview The Data Migration Utility is a stand-alone application provided by Monsoon Commerce that must be executed by previous users of Stone Edge to cleanse cardholder data from existing production, backup and archive database files as a requirement for PCI Compliance. The Payment Module must be installed and configured before this utility is executed. Until the data migration process completed, you cannot process credit or debit card transactions through Stone Edge V7.1. In addition, at the completion of the migration, all system parameters related to payment gateway credentials are removed from the Stone Edge SystemParametersBackEnd and SpecialParameters tables. Should the migration not finish due to an error or user intervention, the parameters remain in the tables until the migration utility is completed successfully. See Appendix A for a list of obsolete Stone Edge system parameters. The data cleansing process includes the following activities: The transfer of current payment transaction data to the Payment Module if the gateway is supported typically this includes transactions less than two years old. You can set this to a shorter period to speed the migration process. The Payment Module can record the customer s payment data at the payment gateway if Customer Management capabilities exist at the gateway and the card information is still valid. Be advised that this activity can dramatically increase the amount of time required to complete the data migration, so please use it only if you experience a large amount of repeat business from your customer base. AuthNet CIM users should be aware that a $.01 transaction is charged and immediately voided during the conversion process. This is a requirement of AuthNet, it is not a Stone Edge issue. Cleansing of the PAN by the Payment Module to display only the first six and last four digits,, X filled to the original account number length, prior to storage in the Payment Module s database tables (Requests, Responses and Transactions). Cleansing the PAN in the Stone Edge database tables (Orders, Transactions and Subscriptions) to display only the first six and last four digits, X filled to the original account number length. Executing the Data Migration Utility VERY IMPORTANT NOTES: Prior to using the Data Migration Utility, be sure to back up the Stone Edge database and the Payment Module database. Should errors or configuration problems arise, it is much easier to start over using Page 29

33 backup copies of the databases rather than resetting the existing databases to the start of the migration process. The amount of data to be migrated directly affects the amount of time for the data migration process to complete. Please plan on running the utility off-hours, allowing a sufficient time for it to complete successfully. Be sure that the Payment Module has been configured with a database connection and any applicable Payment Accounts and Payment Methods to facilitate the uninterrupted execution of the data migration process. Upon completion of the data migration, the user is required to run a forensic review of the hard drive on the computer hosting the Stone Edge data file (SQL or MSAccess) to ensure that card data does not remain on the computer s hard drive. 1. Navigate to the installation directory of the Payment Module and double click the mcsepe01.exe file. The default location is c:\program Files\Monsoon Commerce\PayMgr\mcsepe01.exe. 2. The utility starts the Payment Module which attempts to connect with its database. If a database connection is not yet established or other required settings have not yet been configured, the utility requires the user to do so at that time, prior to continuing with the data conversion process. It is more time-effective to make sure those things are done prior to starting the data migration utility. 3. Select the type of database: a. If Stone Edge uses a Microsoft Access database for data storage, select the Access MDB option and click Browse to navigate to the database file s location. It is highly recommended to have the Access MDB on the local hard drive to speed the conversion process. b. If Stone Edge uses a Microsoft SQL Server database for data storage, select the SQL Server / ODBC DSN option and click Select to identify the ODBC connection to use for the conversion. It is strongly recommended that the SQL database reside on the local LAN to speed the conversion process. 4. Next, click Connect to establish a connection to the database. Upon completion of the connection, a list of payment sources and their associated payment gateways is generated from the Stone Edge database. This list is informational and is not editable by the user. If a particular gateway is established in Stone Edge multiple times, each with different access credentials, the screen displays the list of credentials for account identification. Critical items such as password or access keys remain encrypted to prevent visibility to the user. If any payment source is found not to have a corresponding payment account in the Payment Module, the user can click Open Payment Module to add the Payment Account. Do keep in mind that some of the gateways supported by Stone Edge are not supported by the Payment Module at this time. 5. Click Continue to advance to the next tab where the Stone Edge Payment Methods are mapped to the Payment Module s Payment Methods. The mapping is done by matching their names, which must be identical. This list is informational and is not editable by the user. Payment Methods in Stone Edge which are not supported in the Payment Module are not mapped. Verify that any credit card payment methods which exist in Stone Edge have a corresponding payment method established in the Payment Module. If any method shows as not mapped, you can click Open Payment Module to add the Payment Method. Transactions Page 30

34 associated with an unmapped Payment Method are not transferred to the Payment Module s database. 6. Click Continue to advance to the Map Processors tab. The utility displays the proposed mapping of Stone Edge gateways to the Payment Module s Payment Accounts. Please note that a gateway on the Stone Edge side of the screen is only identified by the gateway name, thus, if you use the same gateway with different accounts and credentials, you will see the gateway listed multiple times. To ensure the correct Stone Edge gateway is associated with the appropriate Payment Module Payment Account, select it in the grid to display its access credentials. If it is mapped incorrectly, you can change the mappings manually. If a payment gateway in Stone Edge is not supported by the Payment Module, leave the Payment Account set to not mapped to prevent the transactions from this gateway from being assigned to the wrong Payment Account in the Payment Module. 7. Next set the cutoff date for transaction migration. By default, the system moves transactions processed within a year of the current date from Stone Edge to the Payment Module. You can set this to a maximum of two years prior to the current date or to a minimum of the current date. The date chosen depends upon the length of your payment capture and return period. The shorter the length of time, the faster the data conversion is completed. 8. (Optional) If a Payment Account uses a gateway that supports Customer Information Management (CIM), the Payment Module can also send the customer s payment information to the payment gateway for permanent storage. If you would like the customer data stored, select Create Customer Processor Records. Warning! Selecting this option can substantially increase the amount of time required to migrate the data, so please use it only if you experience a large amount of repeat business from your customer base. Also, AuthNet CIM users should be aware that a $.01 transaction is charged and immediately voided during the conversion process. This is a requirement of AuthNet, it is not a Stone Edge issue. a. If you select the Create Customer Processor Records option, click Continue to advance to the Customers tab. This screen allows the association of customer payment data in Stone Edge to a Payment Account in the Payment Module. If a Payment Account uses a gateway that supports Customer Information Management (CIM), the Payment Module can send the customer s payment information to the payment gateway for permanent storage regardless of the gateway used in Stone Edge to run the customer transaction. Each Payment Source in Stone Edge is listed. b. Click in the Create Records In column to identify the Payment Account to which the customer data should be associated. If you do not wish the customer s payment data to be transferred to the gateway, leave the payment source s mapping set to Not Mapped. 9. Click Start to begin the conversion process. The Convert tab displays the progress of the conversion system. It also provides information pertaining to any errors encountered during the process. To stop the conversion for any reason, click Cancel. You can restart the migration at the point where it was halted by clicking Resume, however, if user configuration changes were made, the utility restarts from the beginning of the process. If the data migration process had already started, revert to backup copies of the Stone Edge and Payment Module databases before continuing. 10. At the completion of the data migration, the system displays the Cleanse button at the lower right side of the screen. This indicates that the system is now ready to clean all credit card account numbers from the Stone Edge database. Click Cleanse to have the account numbers Page 31

35 converted to the first six and last four digits of the account number, X filled to the original card number length. Upon completion of the cleansing utility, the utility displays the total number of records processed in the Orders, Transactions and Subscriptions tables in the Stone Edge database. The Stone Edge database is now considered to be PCI compliant. Launch and configure Stone Edge Open the Quick Start Guide for Stone Edge 2012 and follow the instructions to perform basic Stone Edge configuration. Customer Support Overview This section outlines the process Monsoon Commerce staff members follow when a customer requires assistance to resolve a specific problem with the application. The process is designed to protect any sensitive data contained in the databases, such as employee passwords, gateway settings, customer names and addresses, etc., as indicated in Requirement 3.2 of PCI-DSS. Collect sensitive authentication data only when needed to solve a specific problem Store such data only in specific known locations with limited access Collect only the amount of data required to solve a specific problem Securely delete such data immediately after use with a secure file deletion application like sdelete or Eraser Encrypt sensitive authentication data while stored When a customer contacts Monsoon Commerce Technical Support ([email protected]) or ) a support ticket is opened and a technician is assigned to investigate the problem, according to its Service Level. Connecting to the customer s desktop With the customer s explicit approval, a support agent accesses their desktop through a remote connection application to investigate the issue. The tool of choice is Bomgar s remote support. If the agent is unable to connect with Bomgar s remote support, another two-factor authentication tool may be used in its place. The connection tool used should not require the customer to make any changes to their firewall settings in order to establish a connection. 1. The support agent sets up the remote connection session to the customer s desktop and the customer accepts the request. 2. To access the application: a. Monsoon Commerce Payment Module (Payment Module), the technician uses an administrative User ID, MCTech, which is created in a disabled state when the program is initially launched. The technician must ask the customer to manually enable the ID before the technician can access the application. This prevents the customer from Page 32

36 having to reveal their own credentials as well as provides a record of transactions generated by the technician during testing. b. To access Monsoon Stone Edge, the technician asks the customer to login with an Admin User ID, which the customer may create specifically for this purpose rather than using a production User ID. 3. When it is necessary to obtain the customer s: a. Stone Edge MS Access database, the technician uses Ctrl+Shift+Z to secure credit card information that may exist in data files created by older versions of Stone Edge. If the file is too large to send via , the technician selects the File Transfer feature from the Bomgar menu to obtain the data by secure https file transfer services. The technician directs the file to a folder, named with the ticket number (use leading zeros), in the secure storage location in the Monsoon Commerce LAN. b. Stone Edge or Payment Module SQL database, the customer, support agent or developer creates a backup copy of the database. The agent or developer selects the File Transfer feature from the Bomgar menu to obtain the database by secure https file transfer services. The agent or developer directs the file to a folder, named with the ticket number (use leading zeros), in the secure storage location in the Monsoon Commerce LAN. c. User name or password information for a shopping cart system, the agent or developer requests that the customer create a new administrative account for their use, which can be deleted at the end of the session. If the customer prefers to provide credentials to their existing administrative account, accept them verbally, not via . Store the information in a folder named with the case number in the secure location. Encrypt the file(s) using AxCrypt. d. Payment Gateway private keys or client certificates, the agent or developer verbally requests their credentials and does not accept them via . Store the information in a folder named with the case number in the secure location. Encrypt the file(s) using AxCrypt. 4. When a customer s SQL or MS Access customer database is opened by Stone Edge on a Monsoon Commerce workstation, the custom function SETIMakeFileSafe is run. The function is executed manually in the IMMEDIATE window. There is no counterpart to SETIMakeFileSafe in the Payment Module, because it is not applicable. 5. When the troubleshooting activity is completed, the customer is instructed to disable the MCTech User ID or change the password of the Stone Edge User ID the technician used. 6. The support agent or developer documents their activity in the ticket, securely deletes any customer data stored on the Monsoon LAN using the procedure described in the section, Using the SDelete utility, and closes the ticket. Monsoon Commerce staff members do not have access to any cardholder data at any point during this process. Using the SDelete utility SDelete is a utility provided by Microsoft for the secure deletion of files. Typical OS file deletion only deletes the reference to the file s location in the hard drive s index. The information still exists on the disk and can be retrieved using forensic software until it is overwritten with new data. SDelete overwrites the file s data on the hard disk, and then deletes the reference to the file, making the information irrecoverable. Page 33

37 Exercise caution when deleting files be sure to double-check the command syntax and file/folder name before pressing Enter. 1. Copy sdelete.exe to the C:\Windows\System32 folder on your computer. 2. Open a command prompt. a. To delete the entire folder, type: sdelete s p 7 \\fs\clientfiles\foldername b. To delete a single file, type: sdelete p 7 \\fs\clientfiles\filename For example, to delete a file called Store A Orders.mdb you would type sdelete p 7 \\fs\clientfiles\store A Orders.mdb Where fs represents the name of the server, clientfiles represents the directory, and filename represents the name of the file to be wiped. The file extension must be included as part of the filename. File names with spaces must be surrounded by quotation marks. The p 7 switch tells SDelete to make 7 passes over the file to ensure the data is irrecoverable. The s switch tells SDelete to include the contents of any subdirectories The amount of time it takes the utility to run depends on the file size, so it may take several minutes to delete larger files. Audit the secure location of customer data Once a month, the support supervisor produces a report of closed tickets in Sales Force for which customer data was collected and compares it to the directory of the secure location. If obsolete data is found, the supervisor then runs the SDelete utility to securely delete the obsolete customer data. Contact information Monsoon Commerce, Inc. 399 Arcola Road Suite 200 Collegeville, PA Phone: [email protected] Page 34

38 Technical product information Product name and version Monsoon Commerce Payment Module Version 1.0 Supported operating systems Microsoft Windows 7 Supported databases Microsoft SQL Server/SQL Express 2005 SP4 Microsoft SQL Server/SQL Express 2008 R2 SP3 Microsoft SQL Server/SQL Express 2012 SP1 Supported hardware USB Card Swipe Wedge: Any hardware that utilizes the standard OPOS definition of a USB MSR (Magnetic Stripe Reader) device should function with the Payment Module. Magtek is the only USB brand of MSR which has been tested with the Payment Module. Keyboard Emulation Card Swipe Wedge: Any MSR (Magnetic Stripe Reader) device that communicates with the PC in a keyboard emulation mode should function with the Payment Module. Verifone 1000SE PinPad Serial/USB Device that is certified as PCI compliant Resellers/Integrators None Resellers are not tasked with implementation nor support of the product. Typical customer About 80% of the merchants that utilize the Stone Edge application are small 1 to 10 person operations that may process 10 to 100 orders/payment transactions per day. These users have one to five client installations of Stone Edge along with one or more back end store database files. The remaining 20% are small-to-medium sized businesses with anywhere from 10 to 100 employees that process 100 to several thousand orders/transactions daily. Client installations can run upwards of users or more. Scope of PA-DSS assessment The Monsoon Commerce Payment Module (Payment Module) handles all credit/debit card payment transactions for Stone Edge V7.1 and higher, making it subject to PA-DSS requirements which are reviewed and validated by a Qualified Security Assessor annually. During the assessment, the Stone Edge application and Payment Module must be used together to fully evaluate the compliance of the Page 35

39 Monsoon Commerce Payment Module, described in the PA-DSS 2.0 requirements, however, Stone Edge itself is not in scope. Product overview and workflow The Payment Module is not dependent on the Stone Edge application. The Payment Module is a selfsufficient application, whose programming interface is utilized by Stone Edge. The Payment Module requires users to be established as administrators or non-administrators. Users who are not members of the administrators group have limited access to the Payment Module s configuration systems and the types of payment transactions they can perform can be restricted through the Payment Module s user permissions system. When any user accesses the Payment Module it is logged in its database and the Windows Event Log. The same is true of all activities they perform. Log records maintained within the Payment Module s database are tagged with an encrypted data point that is utilized to detect record tampering in the logging system. The Stone Edge software is a multi-channel order management and inventory system for retailers engaged in the selling of goods through both e-commerce and store front operations. Orders may enter Stone Edge in several ways: imported from third party e-commerce shopping carts such as Miva Merchant or AbleCommerce through the Point of Sale (POS) module used in store front retail environments (card present transactions) phone and mail orders are created via the Manual Order interface (card not present transactions) In the scenarios described above, the processing of a credit card transaction is handled exclusively by the Payment Module application. The Payment Module application does not pass any cardholder data back to the Stone Edge application under any circumstances. The Payment Module stores partial Primary Account Numbers (PAN) as the first 6 digits and last 4 digits, X filled to the original card number length. No other sensitive account data such as magnetic stripe data or PIN Entry Device data is stored in the back end database or in files on the hard drive. While card data is being processed, sensitive data is encrypted within memory until actually transmitted to the payment processor. Once the transaction is complete, memory locations are cleansed prior to code release to prevent the data from remaining in memory for an extended period. The Payment Module supports the following transactional activities, depending on the payment processor utilized by the merchant: Authorizations Captures (Settlement Sales (Auth/Capture) Credits Voids Payment Data Storage at the Payment Processor Transaction Lookup Page 36

40 The Payment Module is designed to process a single transaction at a time. No batch processing, such as settlement, takes place within the application. When processing a transaction, one of three methods is used to communicate with the payment processor or gateway: 1) Web-based Application Programming Interface (API): The payment processor provides an API that is accessible via the Internet. Communications between the Payment Module and the Web API take place using the HTTPS protocol which takes advantage of Secure Socket Layer (SSL) technology to encrypt the communications between the client and the server. 2) COM ActiveX Control: The payment processor requires the use of a client based ActiveX control that the Payment Module invokes locally. The Payment Module passes the payment data to the control which, in turn, communicates with the payment processor. 3) Client Based Application: The payment processor provides a client based payment application that provides an API for external applications such as Payment Module. The Payment Module passes the payment data to the application s API then the application is responsible for communications to the payment processor. The methods described above also require some form of authentication before allowing access to transaction processing. Authentication can be a simple token, User Name and Password, or a client SSL certificate. The methodology used for authentication is at the discretion of the payment processor used by the merchant. If authentication is based on one or more data points such as a User Name and Password, the Payment Module encrypts and stores these credentials its database. Payment responses from the payment processors contain a token that can be used in place of the cardholder data for all subsequent transactions affecting the original order and any new orders from a given customer. As a result of tokenization, the Payment Module no longer requires the complete PAN for additional transactional activities. Orders that are imported into Stone Edge from shopping cart systems sites such as Miva Merchant or AbleCommerce must send the token acquired from the initial authorization/sale executed at the website when the order was placed. The PAN must be sent as the first 6 digits (BIN) and the last 4 digits (ACCT), X filled to the original card number length. For example: an account number of is sent as XX-XXXX-1111, with or without dashes. Payment Module components The Monsoon Commerce Payment Module is comprised of two EXEs, three DLLs and one OCX: MCPSE01.EXE Payment Module stand-alone application MCPSCL01.DLL Common object classes used by the Payment Module MCOCX01.OCX Visual elements used by the Payment Module Interfaces Page 37

41 MCPSPM01.DLL Payment Module business logic and its API MCPSN01.EXE Windows Event Log used by the Payment Module MCWINEVENTLOG.DLL Windows Event Log application business logic These files house all components that handle and process credit card and debit card payments via an https internet connection or through direct communication with third party COM controls or applications that interact with their payment system s Web APIs. The files are designed to work with its sibling application, Stone Edge, or independently as a stand-alone application. The Payment Module is designed to maintain card account data, PIN entry device output, card magnetic stripe data and card security codes in memory only. While in memory, the data is encrypted using the Microsoft s CAPICOM.dll employing the AES encryption algorithm utilizing 256 bit key length along with randomly generated seed values. Card account data, PIN entry device output, card magnetic stripe data and card security codes are never written to log files or to the Payment Module s database. Application programming interface (API) The Payment Module provides a programmatic interface (API) for use by external applications. The API is designed to allow Stone Edge or other potential applications to: 1. Populate the Payment Module with historic transactional data for future use. 2. Place a new payment request through a user interface for the collection of payment data. 3. Place a payment request for secondary actions against an existing transaction with or without customer interaction. 4. Place a transaction delete request for removal of unprocessed transactions. 5. Log activity pertaining to PCI compliance. Objects exposed by the API include the following: MCPSPM01.cKernelUI The KernelUI is the core interface to the Payment Module s functionality MCPSPM01.cPaymentRequest Request object populated by the caller for processing by the Payment Module MCPSPM01.cPaymentResponse Response object returned by the Payment Module containing results of the transaction processing Interaction with the Payment Module s API begins by instantiating the ckernelui object and setting various properties identifying the calling application: Set opaysys = CreateObject("MCPSPM01.cKernelUI") opaysys.clientappfolder = Calling application s installation folder opaysys.clientpathname = Calling application s folder and file name opaysys.clientsoftwareversion = Calling application s version number opaysys.clienttype = 1 Set to 1 for API Page 38

42 Next the caller initializes the Kernel. The RequestorName argument is a string value identifying the name of the calling application. The DefaultSourceKey argument is a string value (GUID) that the calling application uses to identify itself as a Payment Source to the Payment Module. if opaysys.initkernelui=100 then Initialization successful establish the source key for the calling application ssourcekey = opaysys.payui.createpaymentsource(requestorname,defaultsourcekey) Else Initialization failed raise error End If The Payment Module is now ready to accept payment processing requests from the caller. To process a payment request, the caller must first ask the Kernel for a Payment Request object. Set orequest = opaysys.payui.newrequestobject(requesttype) The RequestType argument is a long integer value and must be one of the following values: 10 Authorization 20 Auth/Capture 30 Full Capture 31 Partial Capture 32 Secondary Capture 40 Full Credit 41 Partial Credit 42 Secondary Credit 50 Void Authorization 51 Void Capture 52 Void Credit 53 Void Sale 105 Delete Transaction The caller populates the request object with the appropriate information depending on the type of transaction being executed. Should the caller have the PAN available, the Request object has a method called AccountNumberSet which accepts the PAN for processing. The Request object also has a method called AccountNumberSafe which only returns the cleansed PAN to the caller. After populating the request, the caller asks the Payment Module to process the request. If the caller requires the Payment Module to display the Payment Terminal user interface for data collection or transaction selection, the following call is provided: Set oresponse = opaysys.payui.showpaymentui(orequest) If the caller does not require the Payment Module to display the Payment Terminal, the following call is provided. This is typically used for batch processing secondary actions against existing transactions: Page 39

43 Set oresponse = opaysys.payui.processpaymentrequest(orequest) In either case, the payment module returns a Payment Response object containing the results of the payment process. Any sensitive data collected by the Payment Module during this process, such as PAN, PIN data, magnetic stripe data, or card security code, is not made available to the calling application. Stone Edge implications Stone Edge uses the above methodology to call the Payment Module to process payments involving Credit Cards and Debit Cards. By using the Payment Module to collect the cardholder data, the Stone Edge application is removed from the scope of PA-DSS since it does not have to handle or store cardholder data in its raw form. While the Payment Request object can accept a PAN from an external source, Stone Edge does not collect or pass the PAN under any circumstances. For users of Stone Edge whose data file does contain PAN information (versions lower than ), a separate Data Migration Utility is provided by Monsoon Commerce which allows the user to migrate their transactional data to the Payment Module and to cleanse the PAN information from their Stone Edge data file prior to moving forward with the use of the two applications. The Monsoon Commerce Implementation Guide provides explicit detail on the data migration process. Stone Edge versions and higher do not permit the use of the Payment Module (Payment Terminal) until the migration process is completed successfully. Page 40

44 Network diagram of typical implementation Communication link Request Stone Edge Code in MS Access MDB Response MCPSPM01.DLL MCPSCL01.DLL chttp Class Internet APIs for Supported Gateways Red arrows indicate PAN movement between processes Third Party Drivers for Hardware Control of Magnetic Stripe Readers and PIN Entry Devices Gateway Provided COM Control or Stand-Alone Application Page 41

45 Flow of cardholder data The following diagrams illustrate the flow of cardholder data when the merchant processes sales from a 3 rd party shopping cart system and from Manual Orders or the Point of Sale interfaces, respectively. PCI Compliant Shopping Cart System Supporting Tokenization Card Processor Web API i.e. Miva Merchant, AbleCommerce, etc. Monsoon Stone Edge If card data found in downloaded order, user is notified and card number cleansed. Log entry sent to Payment Module Process Payment Request Monsoon Commerce Payment Module Store Order Data Retrieve Order Data Call For Orders Receive Order Data Send Request Receive Response Log Card Data Found Receive Payment Response Store Transaction Stone Edge Database Payment Module Database Page 42

46 Monsoon Commerce Stone Edge POS or Manual Orders for in store or phone/ fax purchases Send Request to Open Pay Terminal Receive Cleansed Response Monsoon Commerce Payment Module Collects Payment Information for Delivery to Gateway API Send Request Receive Response Card Processor Web API Store Order Data and Transaction Results Store Cleansed Transaction Results Stone Edge Database Payment Module Database End-to-end authentication The Payment Module s User Permissions system is independent of the Stone Edge application. Neither application uses Windows Authentication to control program access; both require unique User Ids created within the respective program. The ability to perform payment transactions through Stone Edge or directly via the Payment Module can be regulated by the privileges granted to a specific user or class of users defined in each application. The Payment Module s requests to various Web APIs of the processing banks are authenticated based on the bank s rules of communication, which range from simple username/password to a more complex process using client based SSL certificates. Credentials utilized for API Access are stored in an encrypted format within the Payment Module s data file. Page 43

47 Software dependencies Monsoon Commerce Monsoon Stone Edge Optional dependency. User must be running version or higher of the Stone Edge application to use the Payment Module. The payment module s API is utilized by Monsoon Stone Edge for payment processing actions. Microsoft.Net Framework 4.0 Microsoft Development Platform Provides a managed execution environment when building Windows Visual Basic applications ADVAPI. DLL Microsoft COM Component Used to create cryptographic contexts for client SSL certificate management CAPICOM.DLL Microsoft COM component v2.1 - used for data encryption/decryption while data retained in memory and for payment processor s access credentials stored in the Payment Module s database. CRYPT32. DLL Microsoft COM Component Used for client SSL certificate management for processor authentication COMDLG32.DLL Microsoft COM Component Used for common dialog box operations such as File Open/Save GDI32.DLL Microsoft Com Component Used for drawing on screen controls HID. DLL Microsoft COM Component Used to access USB device drivers for information pertaining to Magnetic Stripe Readers (MSR) and PIN Entry Devices (PED). KERNEL32. DLL Microsoft COM Component Used to communicate with USB/Serial devices attached to the local machine, for memory management tasks and for registry operations. MSADO##. DLL Microsoft COM Component Used for Payment Module database access. The ## represents the ADO installed version on the client s PC. MSXML6. DLL Microsoft COM Component used to build XML documents for use with the payment processor s Web APIs. NETAPI32.DLL Microsoft COM Component Used for SQL server instance identification on local network ODBC32.DLL Microsoft COM Component Used for database configuration ODBCCP32.DLL Microsoft COM Component Used for database configuration OLE32.DLL Microsoft COM Component Used for generating unique IDs SETUPAPI. DLL Microsoft COM Component Used to locate USB Devices on the USB bus of the local machine. SHELL32.DLL Microsoft COM Component Used for executing external processes that include the Payment module s Windows Event Logging System Page 44

48 USER32.DLL Microsoft COM Component Used for window control and user interaction with the PC VB6 SP6 Runtime Engine Microsoft Visual Basic in which the application is written WININET. DLL Microsoft COM Component Used for all internet communications using HTTP/HTTPS protocols. WINMM.DLL Microsoft COM Component Used for playing sound files WINSPOOL.DRV Microsoft Hardware Driver Used for access to printers SQLOLEDB Microsoft API for SQL Database Communications part of the Microsoft Data Access Components (MDAC) stack Other third-party control dependencies and applications: CYBERSOURCEWS.DLL CyberSource COM Component v5.0.0 Used for communications between the Payment Module and the CyberSource Web API. IMPORTANT: User must install v5.0.0 or higher to maintain PCI Compliance C1SIZER.OCX Component One ActiveX Control User Interface Control used throughout the Payment Module VSFLEX8L.OCX Component One ActiveX Control User Interface Control used throughout the Payment Module Service dependencies SQL Server Service Service must be running on the computer housing the SQL Database for the Payment Module to enable database communications SQL Server Browser Service Optional Dependency Database Setup provides automated search for SQL Servers available on the User s network. This service provides feedback to the search system when running on the computer where SQL Server is installed. HTTP SSL Service This service implements the secure hypertext transfer protocol (HTTPS) for the HTTP service, using the Secure Socket Layer (SSL). Microsoft.Net Framework NGEN v4 Service utilized by the Microsoft.Net Framework Windows Installer Service Utilized by Payment Module s Installer Package Cherry Device Interface Optional Dependency depending on the use of a Cherry Keyboard for Card Swipe capabilities. Protocols and drivers HTTPS Secure Hypertext Transport Protocol using SSL is utilized for some payment gateway communications. TCP/IP Transmission Control Protocol/Internet Protocol Used for Database and Internet communications SQL Server Driver Used for database communications via default SQL port 1433 default protocol is via TCP/IP Page 45

49 Named Pipes Optional communication protocol used for database communications Page 46

50 Page 47 Appendix A Obsolete Parameters AuthNetDeveloperMode AuthNetPassword AuthNetPOSAcctIsCardPresent AuthNetPOSAcctSend AuthNetPOSPassword AuthNetPOSTestMode AuthNetPOSTransactionKey AuthNetPOSUser AuthNetSend AuthNetTestMode AuthNetTransactionKey AuthNetUser CCLoadPartial CCReaderPrefixTrack1 CCReaderPrefixTrack2 CCReaderPrefixTrack3 CCReaderSuffixTrack1 CCReaderSuffixTrack2 CCReaderSuffixTrack3 CreditCardProcessor CreditCardProcessorPOS CustomCreditCardButtonCall CustomCreditCardButtonLabel CyberSourceAlternateKeyFileName CyberSourceAlternateNamespaceURI CyberSourceAlternateServerURL CyberSourceMerchantID CyberSourcePOSAlternateKeyFileName CyberSourcePOSAlternateNamespaceURI CyberSourcePOSAlternateServerURL CyberSourcePOSMerchantID CyberSourcePOSSecurityKeyLocation CyberSourcePOSTestMode CyberSourceProxyPassword CyberSourceProxyServer CyberSourceProxyUserName CyberSourceSecurityKeyLocation CyberSourceTestMode EchoID EchoPIN EchoPOSID EchoPOSPIN EchoPOSTestMode EchoTestMode HideAccountNumbers JetPayMerchantID JetPayPassword JetPayPOSMerchantID JetPayPOSPassword JetPayPOSTestMode JetPayTestMode LinkPointCertFilePath LinkPointCertName LinkPointPortNumber LinkPointPOSCertFilePath LinkPointPOSCertName LinkPointPOSPortNumber LinkPointPOSServer LinkPointPOSStoreID LinkPointPOSTestMode LinkPointServer LinkPointStoreID LinkPointTestMode PayPalCertificateName PayPalCertificateNamePOS PayPalPassword PayPalPasswordPOS PayPalSignature PayPalSignaturePOS PayPalTestMode PayPalTestModePOS PayPalUseCertificate PayPalUseCertificatePOS PayPalUserName PayPalUserNamePOS PCChargeCommunicationMethod PCChargeDirectoryLocation PCChargeMerchantIDPOS PCChargeMerchantIDWEB PCChargePOSIsMailOrderAcct PCChargeProcessorPOS PCChargeProcessorWEB PCChargeUnlimitedUsers PinPadBaudRate PinPadComPort PinPadDataBits PinPadEnable

51 Page 48 PinPadFlowControl PinPadKeyManagementType PinPadModel PinPadParity PinPadStopBits PinPadWorkingKey PromptWhenCreditSetToVoid ProtxAccountType ProtxPOSAccountType ProtxPOSTestMode ProtxPOSVendorName ProtxTestMode ProtxVendorName QBMSConnectionTicket QBMSPOSConnectionTicket QBMSPOSTestMode QBMSTestMode SecureAccountNumbers SkipjackAllowBlindCredits SkipjackDevKey SkipjackPOSAllowBlindCredits SkipjackPOSDevKey SkipJackPOSSerialNumber SkipjackPOSTestMode SkipJackSerialNumber SkipjackTestMode USAEPayKey USAEPayPOSKey USAEPayPOSSend USAEPayPOSTestMode USAEPaySend USAEPayTestMode VerisignPartner VerisignPassword VerisignPOSPartner VerisignPOSPassword VerisignPOSSendCVV2 VerisignPOSTestMode VerisignPOSUser VerisignPOSVendor VerisignSendCVV2 VerisignTestMode VerisignUseHTTPSInterface VerisignUser VerisignVendor WellsFargoDefault YahooAPIGatewayStoreID YahooAPIGatewayToken YahooGatewayPassword YahooGatewayPOSPassword YahooGatewayPOSSecurityKey YahooGatewayPOSShowBrowser YahooGatewayPOSStoreID YahooGatewayPOSUserID YahooGatewaySecurityKey YahooGatewayShowBrowser YahooGatewayStoreID YahooGatewayUserID