Authorize.net Gateway Errors without Message

[colinodell]

We're seeing that the Auth.Net gateway no longer respects multiple-character delimiters passed via the x_delim_char field - if you pass in multiple chars, it'll only use the first character in the response!  This is why you see '(' in the raw HTTP responses and why changing the Magento constant to '(' works.  (You can use any other character you want - we ended up going with the pipe char '|' instead).

It seems this breaking change was deployed today along with their other character changes.

[zoeyurifoox · Accepted solution]

8:34pm ET - I spoke to Authorize.net and they confirmed (finally!) that they are going to roll this change back. As to whether or not you want to implement this patch, it is up to you. Zoey plans on keeping this patch in its codebase as it provides no downsides and more accurately follows the implementation documentation from Authorize.net which does state that the delimiter and encapsulation variable should only be 1 character.

Hello,

Authorize.net made an unannounced change in their support of the delimiter character from any string to only one character. The fix provided above is incomplete and will cause errors because parsing the delimited on ( means that any user input containing ( will also break.

Here is a more complete fix, although the most proper fix is for Authorize.net to revert this change in my opinion.

//Remove
const RESPONSE_DELIM_CHAR = '(~)';
//Add
const RESPONSE_DELIM_CHAR = '~';
const RESPONSE_ENCAP_CHAR = '|';

// Add these lines above $client->setParameterPost($request->getData()); about line #1285
$request->setXDelimChar(self::RESPONSE_DELIM_CHAR);
$request->setXEncapChar(self::RESPONSE_ENCAP_CHAR);

//Remove this line
$r = explode(self::RESPONSE_DELIM_CHAR, $responseBody);

//Replace with
$r = explode(self::RESPONSE_ENCAP_CHAR . self::RESPONSE_DELIM_CHAR . self::RESPONSE_ENCAP_CHAR, $responseBody);

if(isset($r[0]) && $r[0]{0} === self::RESPONSE_ENCAP_CHAR) {
   $r[0] = substr($r[0], 1);
}

$rCount = count($r);

if(strpos($r[($rCount-1)], self::RESPONSE_ENCAP_CHAR) !== false) {
    $r[($rCount-1)] = str_replace(self::RESPONSE_ENCAP_CHAR, '', $r[($rCount-1)]);
}

We are unaffiliated with Magento and this fix is hopefully able to help others.

Uri

Zoey

www.zoey.com

[enyceedanny]

Just got word today from a client on this issue as well. And Zoey's fix works as a temporary measure.

[jhillppwd]

This is also going to end up being an issue for those on Magento 2, as it also uses the deprecated SIM/DirectPost methods.  Reference:

/app/code/Magento/Authorizenet/Model/AuthorizeNet.php:37

[raviteja_bhaskarabhatla]

This fix is not working for us we are still seeing this error 

Fatal error: Call to a member function setMessage() on a non-object in /chroot/home/tiffanys/tiffanysbakeryphilly.com/html/app/code/local/Mage/Paygate/Model/Authorizenet.php on line 1441

Can someone help me to resolve this issue.

Thanks

---

@AbleCanyon wrote:

Hi Everyone,

We just released an emergency fix to several client sites.  The delimitating character that Authorize.net was using changed to a "(".  As a quick/temporary fix we changed the 

const RESPONSE_DELIM_CHAR

in  the following class (app/code/core/Mage/Paygate/Model/Authorize.netphp)

Mage_Paygate_Model_Authorizenet

from 

'(~)'

 to 

'('

I hope this helps as a temporary solution.  If Magento doesn't release an official fix we'll package this as a proper override.

---

[xkamronx]

Just an FYI - I just got off the phone with Authorize.net and the support agent stated that the delimiter change was being rolled back.

[creatingdigital]

Anyone know if we can convert the orders from quotes to orders since they are paid on auth.net's side?

[marklehm]

We created an extension to patch this issue.

Hope this helps others.

https://github.com/Vonnda/Vonnda_AuthorizePatch

[dealercost]

When authorize.net reverts back, will this fix continue working or do we have to then revert our fix? Thanks guys.

[fuzzyjared]

The fix created by Zoey should make the solution solid regardless of Authnet role back of their change.

From what I have read and understood the issue is with multiple characters being used by Magento for a delimiter.

The original delimiter is set on the Magento end was '(~)'.

According to Authnet docs this should be a single character. I am guessing the "undocumented" change that they are going to roll back was basically ONLY handling the first character and ignoring everything else.

The fix by Zoey updated single character delimiter '~' and a new property for the request an end cap character '|'

RESPONSE_ENCAP_CHAR = '|'

When creating the request object to send to Authnet we are telling Authnet what that delimeter and endcap are. Authnet will then use these characters within their response.

$request->setXDelimChar(self::RESPONSE_DELIM_CHAR);
$request->setXEncapChar(self::RESPONSE_ENCAP_CHAR);

The parsing of the response, also provided by Zoey handles exploding the string response into the appropriate array.

So long story short, if authnet roles back your changes or they keep them this fix should be in good working order.