Accept Fraud Review Result Codes as Success

This is extremely helpful--thanks. Result 126 was in fact what I was seeing returned. I will probably attempt to patch locally. (Although I'm definitely eager for this to possibly show up as a feature!) I could easily create a new logic block to return a different message on 126 (fraud review) transactions--however, I'm still a bit unsure about the easiest way to change the order status to Pending from this point in the code. Thought maybe a Conditional Action could do it, but I don't see a relevant condition (maybe I need to create one). Or perhaps some other code adjustment in the module is the easiest way. If anyone is more familiar with this code, I'd sure appreciate any pointers. Thanks so much.

I think I've got a temporary fix, and it seems much simpler than I thought.

For the code starting at line 216 of uc_payflowpro.module, I switched the existing if blocks and added one more. So now the first block deals specifically with actions if $txn_result_code == 0, the second (see below) triggers if $txn_result_code == 126, and the third is for everything else.

Here is the one I added:

  } elseif ((int)$txn_result_code == 126) {
    $x_approval_code = $response->AuthCode;
    $pnref = $response->PNRef;
    $message = t('Credit card payment flagged for fraud review; approval code !code and pnref !pnref.', array(
      '!code' => $x_approval_code,
      '!pnref' => $pnref,
    ));
    $data = array();
    $data['pnref'] = (string)$response->PNRef;
    $data['authcode'] = (string)$response->AuthCode;
    $data['result'] = (string)$response->Result;
    $result = array(
      'success' => TRUE,
      'comment' => t('Credit card payment flagged for fraud review; approval code !code and pnref !pnref.', array('!code' => $x_approval_code, '!pnref' => $pnref)),
      'message' => t('Credit card payment flagged for fraud review; approval code !code and pnref !pnref.', array('!code' => $x_approval_code, '!pnref' => $pnref)),
      'uid' => $user->uid,
      'data' => $data,
      'log_payment' => FALSE,
    );
  }

Very similar to the plain "approved" block, but note the different comment text and the 'log_payment' key for the payment gateway callback. Set it to FALSE and this appears to make all the difference. The customer now gets their "confirmation" and the appearance that everything is fine, no conditional action is triggered to update order status (since no actual payment was logged). Now we just have to go into PayPal manager to approve or deny the transaction, and return to Ubercart order administration to move the order to "Payment received" or "Cancelled" status.

Hopefully I'm not missing any unforeseen problems with this method, but it seems OK to me. (What a relief, we're supposed to go live in a week!) Thanks again.

This has worked so far, but I neglected the 127 error you mentioned earlier and it actually did arise today. So I added another condition for $txn_result_code == 127 with the only change being an order comment that reads something like "Credit card payment pending resolution of temporary gateway fraud module error".

That's great news. Hmm. I think (and I'm still pretty new to the process) that what we do is (strictly in this order):

1.) Login to manager.paypal.com
2.) Check the report on submitted transactions marked potentially fraudulent or 127
3.) Approve or reject each of those transactions (and make a note of Ubercart order # on each approval)
4.) Do a delayed capture of funds for all outstanding authorizations (including those just approved from fraud queue)
5.) Return to Ubercart order administration
6.) Find orders by order # which were approved from fraud queue and mark each of them "Payment Received" (since 126s and 127s will otherwise stay in Pending)

The "Accept Payment" button from within Ubercart order admin sounds like a good idea. At the least, better synchronization of the PayPal & Drupal sides would be nice, in whatever form that comes. Is it actually possible to take advantage of the Payflow API to the extent that all the steps above can be performed in one fell swoop, with perhaps one confirmation screen shown on the Drupal side (displaying all the data from the fraud report in step 2?)

I'm also trying to decide if it makes sense to treat 126 and 127 differently or not. Right now I'm leaning towards yes, since for some people it might be better to default to Completed when the fraud service goes down rather than have to approve tons of orders by hand.

I suppose this would be a nice as an option (as you just mentioned), but I think from my perspective running our store (getting relatively few transactions per week), I would be fine with just treating 127s in the same way as potentially fraudulents and manually approving them before fulfilling the order with a status "Complete". But that's my preference--again, as a store with few transactions (at this point anyway ;)