Incorrect response code. about omnipay-authorizenet HOT 18 CLOSED

Ignore this post - I'm talking rubbish. Read the next post instead.

The status code is the first code returned from the gateway, so getCode() should return that. This is according to the December 2015 AIM spec.

However, this $data array has 1.0 prepended, which shifts the indexes all up one. The remaining fields seem to match okay, such as getMessage() (index 3), which implies the version number is expected. How this version number is getting in, is a mystery, because I can't find it in the AIM docs, BUT the example transaction responses in those docs do put a "1" (not 1.0) at the start of the response fields, without any mention as to what it is!

I am happy to fix this, but I would like to tie it up to documentation, just in case there are some additional surprises in store further down the line.

from omnipay-authorizenet.

Here is what the docs say:

Field 1 Response Code
Value: The overall status of the transaction
Format:
 1 = Approved
 2 = Declined
 3 = Error
 4 = Held for review

Field 2 Response Subcode
Value: A code used by the payment gateway for internal
transaction tracking

Field 3 Response Reason Code
Value: A code that represents more details about the result of
the transaction
Format: Numeric
Notes: See "Response Code Details," page 58, for a listing of
response reason codes.

Field 4 Response Reason Text
Value: A brief description of the result that corresponds with the
response reason code
Format: Text
Notes: You can generally use this text to display a transaction
result or error to the customer. However, review "Response
Code Details," page 58, to identify any specific texts you do not
want to pass to the customer.

An example transaction response from the docs looks like this:

1,1,1,This transaction has been approved.,iKUUAm,Y,2149207036,,,1.00,CC,auth_
capture,,,,,,,,,,,,,,,,,,,,,,,,,,433AF62576BFC33D0B7B8A75FB229220,merchant defined field 1,merchant defined field 2

For OmniPay, different terminators are used, so it should look more like this:

|1|,|1|,|1|,|This transaction has been approved.|,|iKUUAm,Y,2149207036|,|...

Converting this to the data array, we have:

$data[0] = 1; // Response code
$data[1] = 1; // Response subcode
$data[2] = 1; // Response reason code
$data[3] = "This transaction has been approved."; // Response reason text

This is actually consistent with the way OmniPay inspects those fields.

What it looks like to me, is that your data array is getting corrupted. Maybe something is simply overwriting $data[0]? 1.0 is not a version of Authorize.net - it would be 3.0 or 3.1. Is it the amount you are using for testing?

To help analyse this, is there any way you could dump $data and $this->data here:

https://github.com/thephpleague/omnipay-authorizenet/blob/master/src/Message/AIMResponse.php#L18

Then we can look at the raw data that is coming back from Authorize.Net and how it is being exploded.

from omnipay-authorizenet.

Docs I'm looking at are here:

http://www.authorize.net/content/dam/authorize/documents/AIM_guide.pdf

tl;dr: I believe OmniPay is looking at the correct element, but the response code element is being overwritten by something. That may be in your application, or it may be in OmniPay - either way it needs to be found, because your fix/workaround is likely to lead you into deep water. Alternatively, it could be something funny coming from Authorize.Net.

from omnipay-authorizenet.

Hi, thanks for you the prompt response.

I've dumped $data and $this->data per your request. Here's what I'm getting:

array:22 [▼
0 => "1.0"
1 => "3"
2 => "8"
3 => "The credit card has expired."
4 => ""
5 => "P"
6 => ""
7 => "0"
8 => "3560A14A2C92A50D0569B33C33433DDD"
9 => ""
10 => ""
11 => ""
12 => ""
13 => ""
14 => ""
15 => ""
16 => ""
17 => ""
18 => ""
19 => ""
20 => "XXXX1001"
21 => "American Express"
]

EntityBody {#488 ▼
#contentEncoding: false
#rewindFunction: null
#stream: stream resource @13 ▼
wrapper_type: "PHP"
stream_type: "TEMP"
mode: "w+b"
unread_bytes: 0
seekable: true
uri: "php://temp"
options: []
}
#size: null
#cache: array:9 [▼
"wrapper_type" => "PHP"
"stream_type" => "TEMP"
"mode" => "w+b"
"unread_bytes" => 0
"seekable" => true
"uri" => "php://temp"
"is_local" => true
"is_readable" => true
"is_writable" => true
]
#customData: array:1 [▼
"default" => true
]
}

from omnipay-authorizenet.

Hmm, $data before it is exploded, should be a string. Are you not getting a string?

Could you try casting it to a string dump((string)$data);? I'm wondering if this is a Guzzle thing, providing a stream for the body instead of the raw string. Do you know what version of Guzzle you have installed (composer.lock should have the details, or the composer command line should be able to tell you)?

Thanks for this. What is happening is not quite as straight forward as it looks, and could possibly be affecting other gateways.

from omnipay-authorizenet.

Just found this in the Guzzle docs:

The entity body object of a response can be retrieved by calling $response->getBody(). The response EntityBody can be cast to a string, or you can pass true to this method to retrieve the body as a string.

http://guzzle3.readthedocs.org/http-client/response.html#response-body

As an experiment, if you change this line:

to add true in the getBody() method call, does that make a difference to the way this gateway works?

return $this->response = new AIMResponse($this, $httpResponse->getBody(true));

Also that should change your dump of $data to a string, without the need to cast it.

from omnipay-authorizenet.

This documentation link does not mention the true parameter, so maybe that has been removed in later versions, so casting to (string) is the way to do it:

http://docs.guzzlephp.org/en/5.3/http-messages.html#id2

In theory, the explode() should cast to a string anyway, since it expects a string to be passed in, but we need to do that before dumping the value, otherwise we just don't see the response body content.

from omnipay-authorizenet.

I think you're correct. It might be affecting other gateways as well. Any plans you guys can update the common library to use Guzzle 5?

from omnipay-authorizenet.

I'ved added
return $this->response = new AIMResponse($this, $httpResponse->getBody(true));

Now the result is returning false, even though the response has been approved. Here are my results:

"This transaction has been approved."

AIMResponse {#467 ▼
#request: AIMPurchaseRequestCustom {#463 ▶}
#data: array:22 [▶]
}

false

"1.0"

from omnipay-authorizenet.

Thanks. That must be really old documentation then - the "readthedocs" website always catches me unawares with aging docs :-(

Just try the casting then, when dumping $data:

dump((string)$data);

If that doesn't give us the raw response body string, then I think I'll need a holiday to get my sanity back.

from omnipay-authorizenet.

No, trust me, I understand. :-)

Here is the dump result:

"|1.0|,|3|,|8|,|The credit card has expired.|,||,|P|,||,|0|,|5761CCB21FC6E7EF3E30A21D685600DE|,||,||,||,||,||,||,||,||,||,||,||,|XXXX6781|,|MasterCard|"

from omnipay-authorizenet.

Oh lovely :-(

I'll follow it up on the Authorize.Net forums.

from omnipay-authorizenet.

I've asked the question here:

https://community.developer.authorize.net/t5/Integration-and-Testing/AIM-Transaction-Response-has-invalid-Response-Code/td-p/53434

I really haven't missed something obvious here, have I? Can you find any reference in any of the documentation that indicates why "1.0" could be in that first field instead of "3"? Just meed to make sure I'm not going nutty.

from omnipay-authorizenet.

It looks like you are doing a credit-card-present transaction (a POS), which has a different response format from the card-not-present transactions (traditional e-commerce). Do you know how you are triggering this?

from omnipay-authorizenet.

@cueyouwhy if you want to send me details of your transaction, you can send to [email protected] or paste it here with personal details removed or hashed out.

It looks like you are somehow triggering the CP (Card Present) API, which I suspect is deprecated now - it's being used and supported, but not pushed by Authorize.Net. This AIM gateway driver needs to be coded to make sure that cannot happen. If CP is needed, then that would be an additional gateway driver, extending AIM (it is probably 90% the same) which some tweaks to the fields both sent and received.

So, what'ya sendin'?

from omnipay-authorizenet.

Hi Jason. Yes you are correct--I was testing the transaction with a swiper (CP), that's when I started noticing the error. No worries though, I've extended the class and made some changes. I just glad to know that it's not a gateway/omnipay issue.

from omnipay-authorizenet.

Do you fancy filling us in on how this card swiper was connected to OmniPay gateway? I'm curious about what this setup is.

from omnipay-authorizenet.

I used a USB card reader and then had to create a class to parse the incoming data before sending it to Authorize.net

from omnipay-authorizenet.