Monsoon Commerce Implementation Guide
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 ... 10
The effect of tokenization ... 10
Best practices ... 11 All users ... 11 Third-party integrators ... 12 Deployment of software ... 13 Software updates ... 13 Distribution of hotfixes ... 13
Prepare the environment ... 13
Enable SSL 128-bit encryption ... 13
SQL Server setup requirements ... 13
Set access policies ... 15
Disable system restore ... 16
Protect encryption keys ... 16
Set up password-protected screensavers ... 17
Monitoring, auditing, and logging events ... 17
Product installation ... 24
Review the system requirements ... 24
Download the installer ... 24
Execute the Stone Edge installer ... 25
Configure the Payment Module ... 25
Execute a payment transaction ... 28
Data migration (previous users) ... 29
Launch and configure Stone Edge ... 32
Customer Support ... 32
Overview ... 32
Connecting to the customer’s desktop ... 32
Using the SDelete utility ... 33
Audit the secure location of customer data ... 34
Contact information ... 34
Technical product information ... 35
Product name and version ... 35
Supported operating systems ... 35
Supported databases ... 35
Supported hardware ... 35
Resellers/Integrators ... 35
Typical customer ... 35
Scope of PA-DSS assessment ... 35
Software dependencies ... 44
Service dependencies ... 45
Protocols ... 45
Appendix A Obsolete Parameters ... 47
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, 18 2013 – Updates for Cybersource Gateway
• 1.0 – December, 20 2012 - 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.
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 https://www.pcisecuritystandards.org.
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:
https://www.pcisecuritystandards.org/approved_companies_providers/payment_application_qsas.php
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 95008 US Contact Information: Phone: 408.228.0961 Fax: 408.340.5433 Email:[email protected] Website: http://www.paysw.com
For more information about PA-DSS, visit
https://www.pcisecuritystandards.org/documents/pa-dss_v2.pdf
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
https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php.
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).
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.
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,
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:
4111-1111-1111-1111 4012-8888-8888-1881
4222-2222-2222-2 (yes, valid card number)
MasterCard: 5555-5555-5555-4444 5105-1051-0510-5100 Discover: 6011-1111-1111-1117 6011-0009-9013-9424 American Express: 3782-8224-6310-005 3714-4963-5398-431
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.
• 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: http://www.sans.org/top25-software-errors/
Microsoft: Banned API calls for the Windows Operating System: http://www.microsoft.com/en-us/download/details.aspx?id=24817
OWASP: Open Web Application Security Project’s Top 10 web application vulnerabilities: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
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
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, email 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 http://www.gotoassist.com/remote_support/it_management_security
• 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 email 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.
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. http://technet.microsoft.com/en-us/sysinternals/bb897443
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:
• 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:
http://sourceforge.net/projects/eraser/
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.
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
• 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 https://www.pcisecuritystandards.org.
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
http://www.mssqltips.com/sqlservertip/2006/secure-and-disable-the-sql-server-sa-account/
2. Prevent the use of group, shared, and generic accounts in SQL Server/SQL Express. See PCI DSS Requirement 8.5.8 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 8.58-8.5.15.
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.
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 V2.0 10.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
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. (www.stoneedge.net/dlgateway)
• 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: http://www.microsoft.com/sqlserver/2008/en/us/compliance.aspx
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.
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.
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 8.5.9 through 8.5.14 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 Security setting
Enforce password history 4 passwords remembered
Maximum password age 90 days
Minimum password length 7 characters
Password must meet complexity requirements Enabled
Account lockout duration 30 minutes
Account lockout threshold 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
http://technet.microsoft.com/en-us/library/cc731212.aspx.
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.
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 failed login attempt)
30 minutes
Password Duration (expiration) 90 days
Password Reuse (number of previous passwords to track))
4
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.
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 8.5.15 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.
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 102400.
5. 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
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 and @@@@@@, 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 and @@@@@@ represents the named instance of the SQL Server (if the instance is named).
c. Default Install location for SQL Error Log File:
c:\Program Files\Microsoft SQL Server\MSSQL##.@@@@@@\MSSQL\Log\
where ## represents the SQL version number and @@@@@@ represents the named instance of the SQL Server (if the instance is named).
Monitor the event logs
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
• 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 cleared
1102
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 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 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 Search for statements (TextData) that begin with this text
DBA logins If(object_id(‘masterdbo.sp_MSSQLDM090_version’)
is not null)
Viewing the audit log table Select * from AuditLog
http://technet.microsoft.com/en-us/library/cc293615.aspx http://technet.microsoft.com/en-us/library/cc293616.aspx http://technet.microsoft.com/en-us/library/cc293614.aspx
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
• 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.
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 email 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:
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.
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