I posted earlier about a functional bug fix that has taken about the last week to work out. The end result has been tested by Lyle on myself on clean installs, and update, and the Livetest. It is working as expected in all the areas changed, but it never hurts to have a few extra eyes. Furthermore, there have been a few other minor bug fixes since the RC 4 that could use some testing.

So, I'm looking for folks to test out the current code in Bazaar so I can put out the RC 5 release tomorrow. It's long overdue and barring any further major bug revelations will be the last RC before a 1.0 release. I feel like I jinx us every time I say that, but I'm going to say it. It's still our stated intention even if it doesn't conform to reality.

To help make this possible, please test the code if you are able. If you're running a live site and using the credit card module, I'd advise against testing on your live site. However, if you have a development version of your site that the changes can be tested on, that would be awesome. A summary of changes related to the credit card module may be found below. The main thing to know is that our default settings have been adjusted and I've added a little bit of Forms API wrangling so that we are fully PCI compliant out of the box. There is still a debug mode which allows you to store encrypted CC data in the order and wipe it either after the card has been run or on a delay, but this will only be recommended for testing. What you do in your production environment is ultimately up to you.

So, if you're able, grab the Bazaar code and give it a shot. Please post here if there are any bugs or unexpected "Whoa! :("'s. Thanks a million!

(Also, please use the development thread to log complaints about a major feature change in a release candidate... version numbers aside, these changes had to be made.)

-------------------------------------------------------

Credit card security changes:

Please pay attention, as your credit card options have changed. Features pertaining to credit card processing and data storage have been rearranged so that Ubercart by default is now as secure as it can be when handling your customers' credit card information. Alternate configurations are still supported, but we are making our settings recommendations apparent.

The first major change is that configuring credit card encryption is required before you can use the credit card payment method. This even goes for testing and the new debug mode. The need for this will become apparent as you read more of the changes below. Setting up encryption simply requires two steps:

1. Create a folder outside of your document root (for most users, not in your Drupal directory anywhere) where an encryption key may be stored.
2. Enter the path to this folder in the credit card section of the payment methods settings form.

Ubercart will setup the encryption key and detect it from here on out.

The second major change is that during checkout, the only credit card information that will ever be stored is the last four digits of the credit card number. Between the checkout, review, and order completion pages, data will be transmitted via hidden form elements. Because this data will be in the HTML, it must be encrypted (hence the need for mandatory encryption!). The security benefit here is that the data can only be decrypted with the encryption key located on your server and not accessible to the public.

Internally, because of the nature of Drupal's Forms API, we must store the encrypted data in a persistent variable between a single internal page load in Drupal (from the form submission to the loading of the next page). This data is wiped from as soon as it's retrieved, and it is never kept after an authorization or a charge to a credit card in compliance with PCI security standards for handling credit card information.

The default settings tell Ubercart to attempt to process credit card payments during checkout. This happens when a user submits the order at the review order page. Ubercart will attempt to process the payment using your specified payment gateway and halt checkout if an error occurs. If the payment fails, the customer can go back and adjust their settings. If it passes, the payment is logged and no CC data besides the last four digits of the card number will be saved post-checkout. To help customers, credit card number validation on the checkout form itself (prior to the review order page) is enabled by default.

A summary of the default settings then is:

1. Any credit card info, even temporary, on-page data is encrypted.
2. No credit card info except the last 4 digits gets saved post-checkout.
3. Credit cards are processed as part of checkout.

The third major change is the combination of a few old features into a single setting called "debug mode." The name should make it apparent that this mode is not recommended for normal site use. When debug mode is on, a few changes occur to the normal credit card processing workflow.

First, if you change the settings so that cards are not processed at checkout, then credit card information will be kept encrypted with the order until it meets the criteria for clearing out stored data. This is only recommended for testing checkout prior to setting up a payment gateway. However, as long as you keep the setting on so that cards are processed at checkout, the card details will be wiped like normal in compliance with the PCI security standards.

Second, you can enter credit card information on the order edit page that will persist until the card is processed. In normal mode, you cannot save new CC data to an order like this. It will automatically truncate itself to just store the last 4 digits of the card number. This lets you do things in debug mode like make sure checkout is working how you want and process test transactions with your payment gateway after the fact. It should be noted that the CC terminal has been changed so that you can enter card details here to process manual payments.

The settings to clear stored credit card data are mostly obsolete once these changes go in, but I will be leaving the functions in for debug mode. Just so it's clear, though, since it's only possible to keep data around in debug mode, I've changed the name of the settings to "Debug mode data clearing." You can specify a time-out and order status from which to wipe credit card information save the last 4 digits of the card number.