The module stores the complete state at the time of processing. So, all the post variables, all the session variables, all the server variables, and all the request variables. I think this is just someone in the past thinking one of two things. Either that some of this stuff may be useful for compliance. Or that they don't really know so they are going to store it anyway.

The code block looks like this (so would be easy enough to change to disable the storage of this data).

Code:
		$str['POST'] = base64_encode(serialize($_POST));
		$str['SESSION'] = base64_encode(serialize($_SESSION));
		$str['SERVER'] = base64_encode(serialize($_SERVER));
		$str['REQUEST'] = base64_encode(serialize($_REQUEST));
		
		if($_REQUEST['transStatus'] == 'C'){
				$_POST['transId'] = 'Cancelled';
				$_REQUEST['transId'] = 'Cancelled';
		}

		$db->Execute("INSERT INTO `".TABLE_WORLDPAY_PAYMENTS."` (cartId, worldpay_transaction_id, POST, SESSION, SERVER, REQUEST) VALUES ('".zen_db_input($_POST['cartId'])."', '".zen_db_input($_POST['transId'])."', '". $str['POST'] ."', '". $str['SESSION'] ."', '". $str['SERVER'] ."', '". $str['REQUEST'] ."')");
As I say, I do not want to get into the nitty-gritty of this, and yes I have read my way through the PCI guidance notes. I don't think that this is a compliance issue but I am not an expert.

My solution would always be to use another gateway. This is because the underlying methods of Worldpay are just horrible. I understand that Worldpay is slightly cheaper but as a programmer and not a business owner I don't think the savings are worth it. Different perspectives.