System Settings

Credit Card Numbers

Secure Socket Layer (SSL)

Payment Account Data Storage

Purging of Credit Card Data

File Upload Filters

Bot Detection and Prevention

Honey Pot

Minimum Time for form submission (in seconds)

Maximum number of emails per hour

Credit Card Numbers

In a default setup, AbleCommerce's security settings are typically the most secure. We do, however, give you control over these sensitive matters. If you are not using an automated payment gateway, then you may need to store credit card information to process payments after an order is placed.

All credit card data is encrypted before it is saved to the database, but only if you have set the encryption key. Under no circumstance should credit card numbers be collected without an encryption key set. As an additional security measure, the AbleCommerce code will never store the full credit card number or security code.

The available payment gateways included with AbleCommerce do not require full credit card details once a transaction has been successfully authorized. For enhanced security, you should consider disabling card storage all together. The benefit to this approach is that you gain the security of never recording a customer’s card information. However you should be aware of the following:

Be sure to check the setting for Account Data Lifespan if you do not disable credit card storage. The recommended value is 0, which means as soon as a payment is completed the encrypted account data will be wiped from the database. AbleCommerce will not allow you to retain the card data longer than 30 days after a payment is completed.

Secure Socket Layer (SSL)

Before accepting live transactions, you will need to make sure that you have an SSL certificate installed. SSL protects data that is transmitted between a browser and your web server. It is critical that you have SSL enabled on your web server, and this should be among the first steps taken after deployment. You will need to have a certificate issued for a domain that is included in your AbleCommerce license. Usually this is the same as the store domain.

AbleCommerce does not support any production installation that does not have SSL enabled. Additionally, our application will never display credit card details, even to super users, unless SSL is enabled.

In AbleCommerce, SSL is disabled by default. Before you enable SSL in AbleCommerce, make sure you have an SSL certificate installed and working for the domain that is running your AbleCommerce store. There are many companies that sell SSL certificates and provide support for installation.

When basic SSL is enabled in AbleCommerce, the secure pages are automatically used by the login forms, customer account and checkout processes, shipping quotes, and payment processors. All back-end administration is also using secure SSL pages. Additionally, you can secure all pages from the Configure > Security > SSL Settings page.

Payment Account Data Storage

It is not typically necessary to store payment details when using a live payment processing gateway.

Important: Sensitive account data is encrypted within the database using a secret key. When you deploy AbleCommerce, it does not have a key set. If you are storing credit card data, it is important that you set the encryption key after deployment.

Purging of Credit Card Data

The maintenance routine will automatically remove any stored card data that exceeds the number of days to save. Purging is a manual action and should be performed before manually backing up the database.

To purge all saved credit card data, press the Purge Now button located to the far right. A confirmation message will appear.

File Upload Filters

You can specify the types of files that are allowed for uploading through the AbleCommerce merchant administration pages.

Images: Specify the types of files that can be uploaded through the Catalog > Image and Asset manager.

Additional Extensions: For security, the following list of file types below will always be denied by the application for upload.

.aspx, .ashx, .asmx, .asp, .exe, .com, .bat, .cmd, .msi, .vb, .vbs, .vbe, .ws, .wsf, .scf, .scr, .pif, .shs, .hta, .jar, .lnk, .msp, .cpl, .msc, .ps1, .ps1xml, .ps2, .ps2xml, .psc1, .psc2

Bot Detection and Prevention

New, in AbleCommerce 9.0.11 versions and higher, we have implemented 3 levels of anti-bot protection on the Contact form.

All the above-listed protections are turned on/off from the Configure > Security > System Settings page.

Honey Pot

When the "Enable Bot Detection" feature is enabled, the Honey Pot feature is automatically turned on.

This feature introduces a honeypot mechanism by injecting a hidden input field into the HTML form. While the field remains invisible and inaccessible to human users via standard browsers and UI interactions, automated bots that indiscriminately scan and populate all input fields will likely interact with it. During form submission, the backend logic inspects this hidden field. If it contains any value, the request is flagged as likely non-human (bot activity) and is silently discarded or rejected. No validation errors or user-facing messages are displayed, as the mechanism is explicitly designed to trap bots without disrupting legitimate user interactions.

Minimum Time for form submission (in seconds)

This feature implements a time-based validation mechanism that measures the duration between the initial page load (e.g., the "Contact Us" form) and the form submission event. Upon loading the form, a timestamp is recorded (typically via JavaScript). When the user submits the form, the elapsed time is calculated and compared against a predefined minimum threshold (e.g., 10 seconds). Since bots typically complete and submit forms almost instantaneously—often within milliseconds—any submission occurring before the configured threshold is flagged as suspicious and is rejected. This check helps distinguish between legitimate human users and automated bots based on realistic human interaction time. No explicit error message is shown to avoid signaling the validation mechanism to malicious actors.

Maximum number of emails per hour

This feature enforces a rate-limiting mechanism based on the number of form submission attempts within a specified time window (e.g., per hour)The system tracks how many times the form is submitted within a rolling or fixed one-hour window. In normal user behavior, repeated submissions within a short timeframe are uncommon, whereas bots often perform high-frequency submission attempts. When the configured threshold is exceeded—e.g., 10 submissions per hour—the system automatically blocks further submissions from that source until either the time window resets or the rate limit is manually adjusted. This helps mitigate spam and automated abuse without affecting typical user interaction. No user-facing error messages are shown to avoid disclosing the existence of this control to potential attackers.

To trigger the rate-limiting mechanism, repeatedly submit the form until the predefined submission threshold is exceeded. Once the number of allowed submissions within the configured time window (e.g., hourly) is surpassed, the system will block any further form submissions from the same source. No additional messages can be sent until the rate limit window resets (e.g., one hour elapses) or the limit is programmatically increased. After this cooldown period, form submissions will be permitted again under the same rate-limiting rules.