AIM Transaction Response has invalid Response Code

[jasonjudge]

This is a strange one, happening with the AIM gateway. We have a site that is receiving "1.0" for the Response Code, which is consistent regardless of whether the card is authorised or not. We would expect any value from 1, 2, 3 or 4 only.

The site is using "," for the field separator, and enclosed in "|". It is using Guzzle 3.x as the http client. This is an example of a response it gets back from the AIM gateway (the raw response body):

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

Note that first field - "1.0". What is that about? It should be "3" for an expired card, like the second field which is the response sub-code.

I'm looking at the AIM User Guide (December 2015) and this response looks very, very wrong. There is some chance there is a new bug in Guzzle or somewhere else in the application, but I just need to check here in case there is something funny going on.

I'm not sure, but I assume this is the test gateway, but I'll check to confirm.

It was originally raised as an issue here:

https://github.com/thephpleague/omnipay-authorizenet/issues/30

[RaynorC1emen7 · Accepted solution]

Look like the using credit card present. For card present the first response field is the version, which is always 1.0

what are you passing for the request?

here is the CP test

https://github.com/AuthorizeNet/sdk-php/blob/master/tests/AuthorizeNetCP_Test.php

[jasonjudge]

I'm not sure - I'm the go-between for the user having this issue.

I noticed the documentation I'm looking at is the "Advanced Integration Method (AIM)
Card-Not-Present Transactions" guide, which explains why this format is not what I'm expecting. Thanks, this looks promising.

So what controls the card present/not present? It is just fields in the request?

[RaynorC1emen7]

Not sure about the new SDK, but yes, card present vs card not present is depend on the fields request. They are pushing to use their "API". but google give me this

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

[jasonjudge]

Thanks, just found that aging PDF on Google too. I can't think what is being posted in the request that could be triggering this card-present mode.

I'll get transaction details from the developer and see what I can work out. If CP is another API distinct from AIM, then we either need to extend our library to cater for that API, or code it to make sure that CP API cannot accidentally be triggered.

[RaynorC1emen7]

Yeah, unless there it a bug on the SDK. Make sure your code is not passing info that are for CP only.

Also on the SDK, when creating the AIM request object and connection object, there are 1 for CP and 1 for CNP, make sure it using the right one.

[RichardH]

@jasonjudge, when you submit your transaction, are you sending card data or track data?

Richard

[jasonjudge]

It should be standard card data. The SDK being used only supports card data fields. I don't even know what the "card present" fields would be. The fields being sent are seen here:

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

here:

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

and here:

https://github.com/thephpleague/omnipay-authorizenet/blob/master/src/Message/AIMAuthorizeRequest.php...

All the "x_*" fields are defined and set in those three methods, and there should not be any other fields added in. I'm waiting to hear back from the end developer with full details of the transaction he is sending, in case there is more I don't know about.

[jasonjudge]

That's annoying - I wrote a long explanation of what was going wrong and the fix, but the forum logged me out and threw away all the text. Thanks for your help all, but I'm not typing that all out again :-(

[jasonjudge]

The long and the short of it, is that the developer was not *just* using the OmniPay library for this, which just does card-not-present AIM and DPM. The developer also had a card reader plugged into a custom package, and *that* was generating the request, while OmniPay was trying to make sense of the reponse.

I will fix OmniPay Authorize.Net so it will at least catch this in the future (detecting the first field not containing "1", "2", "3" or "4"), just in case it happens again, albeit very unlikely.