I just got bit by a nasty bug and I'm trying to figure out how this error snuck through my checks. The top-level call:

my $respCodes = $processor->delayedCapture( 
           CCTYPE => $row->{debitacct},                               
+                          
           ORIGID => $row->{auth_code},
           CURRENCY_TYPE_ID => $row->{currency_type_id} );

croak "Failed authorization for TXID $row->{txid} " 
   unless ( $respCodes->{SUCCESS} == 1 );
[download]

I'm performing an equality test, so I would think that if  $responseCode doesn't equal 1, this routine would  croak

But it gets slightly more complicated. The called routine ( processPayment() ) performs a similar hashref key comparison when building up its return value.

   return { SUCCESS => $response->{RESULT} == 0,
            MESSAGE => $response->{RESPMSG},
           AUTHCODE => $response->{AUTHCODE},
            PNREF   => $response->{PNREF},
            CC_TYPE => $params{CCTYPE},
      TOTAL_PAYMENT => $params{AMOUNT},
      CHECK_DETAILS => $checkInfo,
            };
[download]

If $response is still a scalar (meaning that nothing happened to it after declaring it in the subroutine), shouldn't the value of $response->{SUCCESS} be  undef (due to autovivification) rather than having  $response->{SUCCESS} == 0 evaluate to true?

I see where the caller ( the first calls listed in this entry ) would make the mistake with the hashkey comparison since the error was introduced in  $processor->delayedCapture(). But how can  $foo->{bar} == 0 evaluate to true?

I don't know if my solution is the best one, but I've added a  defined check in the creation of the return value of  delayedCapture():

   return { SUCCESS => ( defined $response->{RESULT} && $response->{RE
+SULT} == 0 ),
 ....
[download]