Authorize.net failing after upgrade to uc1.5

Support

Submitted by setfree on Sun, 10/19/2008 - 21:49

Posts: 73
Joined: 12/16/2007

I just upgraded from uc1.3 to 1.5 and our Authorize.net payments are now failing on checkout.

The transactions do get processed correctly on Authorize.net, however, UC is not properly parsing the response code.

The watchdog message sounds conflicted:

Payment failed: Credit card payment declined: "This transaction has been approved."

What's strange is that I modified the uc_authorizenet.module to display the response code in the watchdog log:

<?php
  if ($response[0] != '1') {
    // Fail the charge with the reason text in the decline message.
    $result = array(
      'success' => FALSE,
      'message' => t('Respose Code: ' . $response[0] . ' / Credit card payment declined: @message', array('@message' => $response[3])),
      'uid' => $user->uid,
    );
  }
?>

...and the watchdog message shows that it did receive the success code but appears to be ignoring it.

Payment failed: Respose Code: "1" / Credit card payment declined: "This transaction has been approved."

Any idea why the line:

if ($response[0] != '1')

isn't properly reading the variable as a '1'? I tried removing the quotes, but had the same result.

Complete Computer Care

permalink #1 Sun, 10/19/2008 - 22:07

setfree

Posts: 73
Joined: 12/16/2007

Okay, from my watchdog log, I noticed that the response code was actually "1" (with the quotes) instead of 1 -- that is why UC was failing the successful transactions.

When I changed the code to:

<?php
  if ($response[0] != '"1"') {
    // Fail the charge with the reason text in the decline message.
    $result = array(
      'success' => FALSE,
      'message' => t('Respose Code: ' . $response[0] . ' / Credit card payment declined: @message', array('@message' => $response[3])),
      'uid' => $user->uid,
    );
  }
?>

... all appears to be working correctly.

Some questions:

Will my little hack work, or are there any other issues related to the quotes in the response that I should be aware of?
What is causing these quotes? Is this something new with Authorize.net or UC?

Complete Computer Care

permalink #2 Mon, 10/20/2008 - 09:49

Ryan

Posts: 5625
Joined: 08/07/2007

Curious... I did make some changes to hard code how data should be sent and received from Auth.Net (i.e. not leaving the delimiter optional any more). I wonder if I needed to set the encapsulation character for values, too. Puzzled Did you run update.php when you made this update?

permalink #3 Mon, 10/20/2008 - 10:22

setfree

Posts: 73
Joined: 12/16/2007

Yes, I did run the update script. It does appear to be an issue with the encapsulation character, but it is strange that no one else seems to have reported having a problem.

In the short term, do you think my quick hack is okay to use?

Complete Computer Care

permalink #4 Mon, 10/20/2008 - 10:30

torgosPizza

Posts: 1377
Joined: 08/14/2007

We're using auth.net and haven't seen this issue. Can this be reproduced? Does it happen on every order or only on certain ones?

"Pain don't hurt." - Dalton

Mike Nelson's RiffTrax! www.rifftrax.com

permalink #5 Mon, 10/20/2008 - 22:27

setfree

Posts: 73
Joined: 12/16/2007

That's interesting that you (and apparently others) aren't experiencing the same problem. Since this is a live site I didn't do too much testing, I just wanted to get the order processing again.

After the 'patch' I made I submitted another order and all is still working with the hard coded quotes for encapsulation.

Anyone have any idea why I would have an issue and not others?

Complete Computer Care

permalink #6 Tue, 10/21/2008 - 10:39

torgosPizza

Posts: 1377
Joined: 08/14/2007

Well, to be honest, we have seen that issue in the past - but it seems to have lessened now. It seems that most people (99% maybe) are having no problems processing cards, but it would be nice to get it to 100%. Usually the issues end up being PEBKAC, but anything we can do to make things run more smoothly.

But yes, after re-reading your post, we have seen issues where the order in Ubercart gets declined, but authorize.net still captures funds, or sometimes puts an Authorization Hold charge on the card, which usually disappears within 48 hours. I thought this issue had been more or less nailed down with Ryan's update (which I think was around 1.3)?

"Pain don't hurt." - Dalton

Mike Nelson's RiffTrax! www.rifftrax.com

permalink #7 Tue, 10/21/2008 - 14:18

Ryan

Posts: 5625
Joined: 08/07/2007

Well, I think what's happening here for him is that somehow he's setup an encapsultion character in his merchant profile. The API docs say this can happen, but I can override it by submitting an alternate character. The problem is, I can't figure out where this setting should be so I can test it... Also, I don't know if I can just specify no encapsulation character.

@setfree, can I get you to try adding the following line and undoing your other change?

<?php
// Around line 282...

  // Extra Information
  'x_delim_data' => 'TRUE',
  'x_delim_char' => '|',
  'x_encap_char' => '',
?>

See if that last line solves it. If so, I'll add it in... otherwise I'll make it like a * or something. Silly APIs... they should all use XML. Sticking out tongue

permalink #8 Tue, 10/21/2008 - 19:09

setfree

Posts: 73
Joined: 12/16/2007

Ryan,

You are correct, I had forget that I had tried setting the encapsulation character in the merchant profile while trying to get auth.net to process when we initially set it up. So that is what is causing the problem.

I tried the change you suggested and removed my change but the transactions started failing again. The same way as before.

The code I used:

<?php
    // Extra Information
    'x_delim_data' => 'TRUE',
    'x_delim_char' => '|',
      'x_encap_char' => '',
    'x_relay_response' => 'FALSE',
    'x_email_customer' => variable_get('uc_authnet_aim_email_customer', FALSE) ? 'TRUE' : 'FALSE',
  );
?>

Any other ideas on how to get around the profile-set encapsulation character, or should I revert back to a hard-coded one?

Thanks for you help!

Complete Computer Care

permalink #9 Tue, 10/28/2008 - 16:27

Ryan

Posts: 5625
Joined: 08/07/2007

I just think it was failing because a NULL character isn't one of their stated encapsulating characters. Instead I'll just hard code the module to use an x_encap_char and expect that in the return. So stick with your hack for now unless you can find the place to unset that encapsulating character in your account settings.

permalink #10 Tue, 10/28/2008 - 16:28

Ryan

Posts: 5625
Joined: 08/07/2007

I just updated the module for 1.6 (it's still in Bazaar) to force an encapsulating character. I also updated it to support authorization only and prior authorization capture transactions based on the changes to the CC API. Cool

(This update will require update.php, but it's just to move the variable that specifies the default transaction type.)

permalink #11 Mon, 11/17/2008 - 21:53

setfree

Posts: 73
Joined: 12/16/2007

Ryan,

I just upgraded to uc1.6 and the Auth.net transactions are working for me now without the patch. So your changes worked and now auth.net transactions will process even with an encapsulation character set on the auth.net account.

Thanks a lot for all of your hard work on this excellent program! By the way, I was so pleased to read the blurb about you and your faith on the "Do It with Drupal" site! God bless Eye-wink

Complete Computer Care

permalink #12 Mon, 11/17/2008 - 23:18

Ryan

Posts: 5625
Joined: 08/07/2007

Awesome. Cool I'm glad it's working for you, and thank you for the kind words and encouragement.

	Ubercart Training

	User login
	Username: * Password: * Create new account Request new password

	Ubercart Affiliates
	Find payment and hosting services in our Affiliate Directory that support Ubercart development.

	Drupalcon DC
	Vote now to learn more about Ubercart in these sessions: Ubercart on Drupal 6 Advanced Ubercart Usage Starting Your Own Ubercart Store

Ubercart

Authorize.net failing after upgrade to uc1.5

Navigation

Ubercart Training

User login

Ubercart Affiliates

Drupalcon DC