Showing results for 
Search instead for 
Did you mean: Gateway Errors without Message


Re: Gateway Errors without Message

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.

Re: Gateway Errors without Message

8:34pm ET - I spoke to 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 which does state that the delimiter and encapsulation variable should only be 1 character.


Hello, 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 to revert this change in my opinion.


const RESPONSE_DELIM_CHAR = '(~)'; //Add


// Add these lines above $client->setParameterPost($request->getData()); about line #1285


//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.




Re: Gateway Errors without Message

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

Re: Gateway Errors without Message

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:



Re: Gateway Errors without Message

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/ on line 1441

Can someone help me to resolve this issue.


@AbleCanyon wrote:

Hi Everyone,


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


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








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



Re: Gateway Errors without Message

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

Re: Gateway Errors without Message

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

Re: Gateway Errors without Message

We created an extension to patch this issue.


Hope this helps others.

Re: Gateway Errors without Message

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

Re: Gateway Errors without Message

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 '|'



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.



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.