Authorize.net failing after upgrade to uc1.5

13 replies [Last post]

Sun, 10/19/2008 - 22:49

setfree

Offline

Joined: 12/16/2007

Juice: 436

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.

Sun, 10/19/2008 - 23:07

#1 View page

setfree

Offline

Joined: 12/16/2007

Juice: 436

more info...

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?

Mon, 10/20/2008 - 10:49

#2 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: more info...

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. Did you run update.php when you made this update?

Mon, 10/20/2008 - 11:22

#3 View page

setfree

Offline

Joined: 12/16/2007

Juice: 436

Yes...

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?

Mon, 10/20/2008 - 11:30

#4 View page

torgosPizza

Offline

Joined: 08/14/2007

Juice: 4110

Re: Yes...

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?

--
Help directly fund development: Donate via PayPal!

Mon, 10/20/2008 - 23:27

#5 View page

setfree

Offline

Joined: 12/16/2007

Juice: 436

Re: Re: Yes...

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?

Tue, 10/21/2008 - 11:39

#6 View page

torgosPizza

Offline

Joined: 08/14/2007

Juice: 4110

Re: Re: Re: Yes...

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)?

--
Help directly fund development: Donate via PayPal!

Tue, 10/21/2008 - 15:18

#7 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Re: Re: Re: Yes...

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.

Tue, 10/21/2008 - 20:09

#8 View page

setfree

Offline

Joined: 12/16/2007

Juice: 436

Ryan, You are correct, I had

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!

Tue, 10/28/2008 - 17:27

#9 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Ryan, You are correct, I had

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.

Tue, 10/28/2008 - 17:28

#10 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Re: Re: Ryan, You are correct, I had

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.

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

Mon, 11/17/2008 - 22:53

#11 View page

setfree

Offline

Joined: 12/16/2007

Juice: 436

Works great now!

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

Tue, 11/18/2008 - 00:18

#12 View page

Ryan

Offline

Joined: 08/07/2007

Juice: 15438

Awesome. I'm glad it's

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

Fri, 07/24/2009 - 13:57

#13 View page

jamesialford

Offline

Joined: 04/10/2009

Juice: 172

Same error message

Hi all, I think I am getting the same error message. I do not know much about PHP, so this puts me behind a brick wall.

Here is what I am getting from WatchDog

Type uc_payment
Date Friday, July 24, 2009 - 16:33
User James
Location http://instrumentsandgear.com/iag/cart/checkout/review
Referrer http://instrumentsandgear.com/iag/cart/checkout/review
Message Payment failed: Credit card payment declined: his transaction has been approved
Severity warning
Hostname 173.171.115.193
Operations

I do not know what an encapsulation character is. I will look for anything to help me out.

I have been trying for 3 months to get Ubercart to work for my needs and starting to pull me hair out.

Can anyone help me?

James

James Alford
www.alfordwebsolutions.com

	User login
	Log in using OpenID: What is OpenID? Username or e-mail: * Password: * Remember me Log in using OpenID Cancel OpenID login Create new account Request new password

Ubercart

Navigation

User login