AVS/CVV Enforcemement, US/Canada API compatibility

Applied to head - http://drupal.org/cvs?commit=229218

And to the DRUPAL-5 branch http://drupal.org/cvs?commit=229222

Alright. This patch is bad. This patch allows successfully processed transactions to get shown to the user and ubercart "AVS Failed", even though there transaction has been processed on their credit card.

Here's the use case:

Moneris returns with AVS 'W'. Which it has been on my account. AVS code 'W' is not in the $avs_access array, there for the AVS code marks the transaction as failed, even though the $response_code is less than 49 (a success).

The true way (which needs to superceed any other logic on success/failed) I believe needs to be the response_code. This tells us if we have charged the card or not. If we have charged the card, we need to allow ubercart to display a successful transaction. Otherwise the user will continue to process their card (sucessfully) but being displayed failed messages.

THIS IS BAD BAD BAD and does happen with this code.

Everything needs to be refactored to error on the side of caution.

It should work like this

IF success_code
THEN treat everything as a success and perhaps warn about CVV and AVS codes we dont understand in watchdog, so we can resolve them and improve the module
ELSE failed_code
THEN check to see why it failed including CVV and AVS

right now it works like this

IF success_code
THEN mark transaction as successs
IF FAILED CVV
THEN mark transaction as failed
IF FAILED AVS
THEN mark transaction as failed

this is poor logic and your clients are getting billed and ubercart is not showing successes.

Here's another bug:

if (($this_trans_type == 'us_preauth' && $txnType == 'us_purchase') && intval($response_code) < 49 || $completed == 'TRUE') {

$completed is equal to 'true'
$completed is never equal to 'TRUE'

Again, when you are dealing with credit card processor integrations you need to error in the side of caution and should do something like

str_tolower($completed) == 'true';

Unless for what ever reason PHP string comparisons are case insensitive, but I don't think they are.

Here's what responses look like

<?xml version="1.0" standalone="yes"?><response><receipt><ReceiptId>csDDDDDDDDDD</ReceiptId><ReferenceNum>66DDDDDDDDD</ReferenceNum><ResponseCode>027</ResponseCode><ISO>01</ISO><AuthCode>08DDDD</AuthCode><TransTime>21:36:10</TransTime><TransDate>2009-11-03</TransDate><TransType>01</TransType><Complete>true</Complete><Message>APPROVED * =</Message><TransAmount>28.22</TransAmount><CardType>V</CardType><TransID>3D-D_DD</TransID><TimedOut>false</TimedOut><BankTotals>null</BankTotals><Ticket>null</Ticket><AvsResultCode>Y</AvsResultCode><CvdResultCode>1M</CvdResultCode></receipt></response>

I've replaced numbers with D to hide the information.

Here's one with AVS response W

<ReceiptId>cs1DDDDDDDDDD</ReceiptId><ReferenceNum>661DDDDDDDDDD</ReferenceNum><ResponseCode>027</ResponseCode><ISO>01</ISO><AuthCode>1DDDDZ</AuthCode><TransTime>10:09:35</TransTime><TransDate>2009-11-11</TransDate><TransType>01</TransType><Complete>true</Complete><Message>APPROVED * =</Message><TransAmount>45.15</TransAmount><CardType>M</CardType><TransID>DD-0_DD</TransID><TimedOut>false</TimedOut><BankTotals>null</BankTotals><Ticket>null</Ticket><AvsResultCode>W</AvsResultCode><CvdResultCode>1M</CvdResultCode></receipt></response>

I've also noticed that successful transactions seem to have an AUTHCODE of non 0000000 . I assume this also means it was able to auth the card and charge it.

nevermind.