Gateway Error when using Authorize.Net

[Ricardo S Yasuda]

Hi,

I'm implementing a shop using Spree that uses an Authorize.Net account. I put the account under Test Mode though their control panel, and also set 'test' to 'true' in ActiveMerchant options. Here's the migration I used:

http://gist.github.com/26523

And configured API login, Transaction Key and test in Configuration -> Gateways

Credit Card payment work (I used the 411... Visa test card), the e-mail is sent, and appear in admin as 'Authorized'. But when I click 'capture', it gives me 'Gateway Error ...' without any other info, logs included.

Do you have any idea why this is happening? Is it an Authorize.Net config, a Spree config, an ActiveMerchant config?

[]s
Shadow
blog.shadowmaru.org
amoodeiosp.com.br
twitter.com/shadow11

[Sean Schofield]

I haven't used Authorize.net with ActiveMerchant (or Spree) yet but I
assume it works fine. I'll try testing it later today with your AM
migration (I think I have a test account laying around somewhere.)

I'm assuming you are running with -e test (or production.) Spree will
use the BogusGateway automatically in development mode (perhaps we
should change that default?) Are you sure the charge is being
authorized at AM? Please verify that the authorization is going
through.

If the authorization is going through then its possible there is a bug
in the Spree capture logic. It may also be possible that we are not
storing/sending the correct information to complete the capture. Keep
digging and let me know what you find.

If I don't hear back from you I will assume you are still stuck and
will try to look at it later today.

Regards,

Sean

[Ricardo S Yasuda]

Hi Sean,

yes, I'm using in production environment, in a staging site, using test mode in Authorize.net. How can I know that a credit card payment was really authorized? Is there a special message in the logs? I dug the source code but haven't seen exactly how it communicates with the gateway. All I know is that when I submit the fake CC number, the 'thank you' message is shown, the e-mail is sent and the order appears as 'Authorized' in the Orders index page in admin.

Here's the log message when I try to capture:

http://gist.github.com/26552

[]s
Shadow
blog.shadowmaru.org
amoodeiosp.com.br
twitter.com/shadow11

[Sean Schofield]

OK I stepped through the process and I noticed one problem right
away. The Authorize.net response message was not being added to the
flash error message properly. I'm not sure if this is a change in how
a_m does things or if each gateway is different in how they name this
parameter (you would think a_m would handle the translation of the
message to a standard variable.)

Anyways, I made a local fix (which I'll commit later) and was able to
see the error coming back from Authorize.net

"Authorization Error: Gateway Error ... (TESTMODE) This account has
not been given the permission(s) required for this request."

I soon realized that I had the wrong value for the login. I was using
the account login instead of the API login. You must make sure that
your gateway is configured in the Spree admin interface to use the API
login and transaction id (not the same as your developer login and
password.) You can find this under Account | Settings on https://test.authorize.net
.

So after I made sure to use the correct api parameters I was able to
successfully authorize. Were you able to get this far? I seem to
remember at one point you had a problem capturing.

After the successful authorization I took a look at the transaction
information from the admin order details page. It shows a response
code of 0. I was pretty sure that was going to be a problem and sure
enough when I try to capture I get:

"Gateway Error ... (TESTMODE) A valid referenced transaction ID is
required."

I also noticed that the authorization is not listed in my "reports" on
the Authorize.net test account. Perhaps because this is test mode
they don't show up? I think that is the most likely reason. So I'll
do a little more digging and see what the deal is with the response
code, etc.

Regards,

Sean

[MWesty]

Sean, Ricardo

I've been meaning to set up Authorize.net for a while so this is
timely.

I was able to reproduce everything you did above. I stepped through
and saw a lot of useful information coming back in the response, but
not making it to the creditcard_txns object. I think that is the fix
you are referencing above. I haven't made that change yet, but I did
notice that the raw Authorize.net transaction ID was '0'. I believe
that is the second issue you reference above. So the error makes
sense as there is no valid transaction code to match to.

One thing I did notice, was that I got a gateway error for this order,
but the order had changed state from capture to ship. I think this
should fail gracefully and remain in capture mode, so it can be
submitted again. I don't think I'm up to speed yet on the states, so
I'm not sure I can fix this, but if I do come up with anything I'll
try my hand at a patch.

Thanks.

On Nov 19, 2:25 pm, Sean Schofield <s...@endpoint.com> wrote:
> OK I stepped through the process and I noticed one problem right  
> away.  The Authorize.net response message was not being added to the  
> flash error message properly. I'm not sure if this is a change in how  
> a_m does things or if each gateway is different in how they name this  
> parameter (you would think a_m would handle the translation of the  
> message to a standard variable.)
>
> Anyways, I made a local fix (which I'll commit later) and was able to  
> see the error coming back from Authorize.net
>
> "Authorization Error: Gateway Error ... (TESTMODE) This account has  
> not been given the permission(s) required for this request."
>
> I soon realized that I had the wrong value for the login.  I was using  
> the account login instead of the API login.  You must make sure that  
> your gateway is configured in the Spree admin interface to use the API  
> login and transaction id (not the same as your developer login and  

> password.)  You can find this under Account | Settings onhttps://test.authorize.net

[MWesty]

I found some further info on this.

Evidently, when you are submitting to the Authorize.net Test server in
Test mode it will not issue a transaction ID. However, if you submit
to the Test Server in Live mode it will issue the transaction ID. As
long as you are submitting to the Test server (https://
test.authorize.net/gateway/transact.dll) it will not charge any cards.

I still haven't got it working, but at least there is hope. (and
confusion.)


Related posts in Active Merchant group-

http://groups.google.com/group/activemerchant/browse_thread/thread/f38c09bcf1d72d38/6b9a06c005b2c0aa?lnk=gst&q=Authorize.net+test+server#6b9a06c005b2c0aa
http://groups.google.com/group/activemerchant/browse_thread/thread/76a3edaad929039f/8b45073aa5d311ad?lnk=gst&q=Authorize.net+test+server#8b45073aa5d311ad

[MWesty]

OK,

Here is what I found-

There are two things that need to be set when using Authorize.net with
ActiveMerchant:

ActiveMerchant::Billing::Base.gateway_mode- This is set to
either :test or :production and determines what Authorize.net server
you are hitting. It appears to be set by Spree depending on what
environment you are using. Development = Bogus Gateway, Test =
Authorize.net test server, Production = Authorize.net production
server. This setting is unaffected by any values entered in for the
"test" option in Ricardo's migration above.

gateway_option :test - This determines whether the gateway (Production
or Dev) is hit in "test" mode. I have not hit the production URL yet,
so I can't say what happens there, but the Dev gateway will not return
a transaction ID in "test" mode. This means that an AUTH can't be
captured later because there is nothing to match it to. Hitting the
Dev URL without the "test" option will return a transaction ID and the
full cycle can be tested.

I did discover one quirk while testing this. ActiveMerchant appears
to be testing whether the :test option exists or not and uses that to
determine whether the test mode is used. No matter what value I put
in for :test, ActiveMerchant used TRUE for test mode. I had to delete
the gateway_option_value for :test in order to get it out of dev mode
and into live mode.

gateway_mode :test option Result

:test exists No transaction ID, fake
transaction
:test does not exist Returns transaction ID, fake
transaction
:production exists ???
:production does not exist Returns transaction ID, card
charged


I hope this makes sense.

Mike

[Sean Schofield]

> One thing I did notice, was that I got a gateway error for this order,
> but the order had changed state from capture to ship. I think this
> should fail gracefully and remain in capture mode, so it can be
> submitted again. I don't think I'm up to speed yet on the states, so
> I'm not sure I can fix this, but if I do come up with anything I'll
> try my hand at a patch.

Please file this as a bug (including the steps to reproduce.) If you
are still looking at fixing it, please indicate that in the comments.
Otherwise I'll take a look later this week.

Sean

[Sean Schofield]

> There are two things that need to be set when using Authorize.net with
> ActiveMerchant:
>
> ActiveMerchant::Billing::Base.gateway_mode- This is set to
> either :test or :production and determines what Authorize.net server
> you are hitting. It appears to be set by Spree depending on what
> environment you are using. Development = Bogus Gateway, Test =
> Authorize.net test server, Production = Authorize.net production
> server. This setting is unaffected by any values entered in for the
> "test" option in Ricardo's migration above.

Yes this part seems correct already. FYI, you can also force Spree to
run your configured gateway in development mode (instead of the bogus
one) by adding Spree::Gateway::Config.set(:use_bogus => false) in your
migrations.

> gateway_option :test - This determines whether the gateway (Production
> or Dev) is hit in "test" mode. I have not hit the production URL yet,
> so I can't say what happens there, but the Dev gateway will not return
> a transaction ID in "test" mode. This means that an AUTH can't be
> captured later because there is nothing to match it to. Hitting the
> Dev URL without the "test" option will return a transaction ID and the
> full cycle can be tested.

I fixed this (locally) in the manner you suggested. Are you sure you
are getting an actual transaction id? I stepped through with the
debugger and looked at the parsing logic. This is what I get in the
local fields array after parsing the response (http://gist.github.com/27081
)

transaction id is supposedly fields[6] which is 0. Don't confuse with
fields[7] which is the invoice number. Its a little frustrating that
this array is zero based but the lookup table on AIM starts at one.
In any event, the mapping in the a_m implementation for authorize.net
appears correct.

So it doesn't look like you get a transaction id at all under the
scenario you described.

> Mike

Sean

[MWesty]

Sean,

I do get a transaction ID in position 6 and I am also able to see the
transaction on the Authorize.net site in the reports.

The one thing I may do differently than you, is I installed the latest
AM plugin from Github. Although, I would be surprised if it didn't
work with the latest gem.

Two things to check-

1) Are you running the Test environment. Dev uses bogus by default.
(I just did this accidentally myself.)
2) Is the "test" gateway_option_value ROW deleted from the
gateway_option_values table?

If those two items are correct, set a breakpoint on Line 232 of the
authorize_net.rb file in the Active Merchant plug-in.

Step over this line and then check the value of parameters
[:test_request] if it is TRUE then you will not get a transaction
ID. I had to delete the entire row in the gateway_option_values table
to get this to read FALSE due to the logic in line 232.

[MWesty]

I ended up adding two Authorize.net gateways.

One I called Authorize.net Live Mode and it only has a login (API
login) and a password (transaction key) as gateway_options

The other I called Authorize.net Test Mode and it has a login,
password, and test as gateway_options. It doesn't appear to matter if
there is a value for the test option, it will run in test mode
regardless.

When hitting the test url in live mode the Authorize.net test card
number (4222222222222), did not generate the expected response codes.
It only generates the expected response codes when in "test mode".
But, as we know, in test mode the transaction IDs are not returned, so
both are necessary.

I imagine I will be hitting the test server in live mode the majority
of the time. The response code error handling appears solid.

Mike

[MWesty]

I ended up adding two Authorize.net gateways.

One I called Authorize.net Live Mode and it only has a login (API
login) and a password (transaction key) as gateway_options

The other I called Authorize.net Test Mode and it has a login,
password, and test as gateway_options. It doesn't appear to matter if
there is a value for the test option, it will run in test mode
regardless.

When hitting the test url in live mode the Authorize.net test card
number (4222222222222), did not generate the expected response codes.
It only generates the expected response codes when in "test mode".
But, as we know, in test mode the transaction IDs are not returned, so
both are necessary.

I imagine I will be hitting the test server in live mode the majority
of the time. The response code error handling appears solid.

Mike

On Nov 20, 9:51 am, MWesty <michael.westo...@gmail.com> wrote:

[MWesty]

I ended up adding two Authorize.net gateways.

One I called Authorize.net Live Mode and it only has a login (API
login) and a password (transaction key) as gateway_options

The other I called Authorize.net Test Mode and it has a login,
password, and test as gateway_options. It doesn't appear to matter if
there is a value for the test option, it will run in test mode
regardless.

When hitting the test url in live mode the Authorize.net test card
number (4222222222222), did not generate the expected response codes.
It only generates the expected response codes when in "test mode".
But, as we know, in test mode the transaction IDs are not returned, so
both are necessary.

I imagine I will be hitting the test server in live mode the majority
of the time. The response code error handling appears solid.

Mike

On Nov 20, 9:51 am, MWesty <michael.westo...@gmail.com> wrote:

[Sean Schofield]

> I do get a transaction ID in position 6 and I am also able to see the
> transaction on the Authorize.net site in the reports.

This is killing me. Still not seeing the transaction id.

> The one thing I may do differently than you, is I installed the latest
> AM plugin from Github. Although, I would be surprised if it didn't
> work with the latest gem.

I'll have to try this next. I checked the github source though and
there were no changes to the authorize.net file since January (and I'm
pretty sure the gem we're using was released after that point.)

> Two things to check-
>
> 1) Are you running the Test environment. Dev uses bogus by default.
> (I just did this accidentally myself.)

Yes. HINT: You can type 'Spree::Gateway::Config.set(:use_bogus =>
false)' in the console and this will disable as a preference and store
the setting in your db. I'm thinking we should add a checkbox to the
gateway configuration screen to allow this setting to be changed (and
easily viewed) in the admin interface.

> 2) Is the "test" gateway_option_value ROW deleted from the
> gateway_option_values table?

Yup. Did that already based on your earlier post.

> If those two items are correct, set a breakpoint on Line 232 of the
> authorize_net.rb file in the Active Merchant plug-in.
>
> Step over this line and then check the value of parameters
> [:test_request] if it is TRUE then you will not get a transaction
> ID. I had to delete the entire row in the gateway_option_values table
> to get this to read FALSE due to the logic in line 232.

Currently reading "FALSE"

[Sean Schofield]

> The other I called Authorize.net Test Mode and it has a login,
> password, and test as gateway_options. It doesn't appear to matter if
> there is a value for the test option, it will run in test mode
> regardless.

Just curious but why would you want to run in test mode? Are you
trying to test your production account API stuff? That's about the
only (and very limited) use I can think of this mode.

> When hitting the test url in live mode the Authorize.net test card
> number (4222222222222), did not generate the expected response codes.
> It only generates the expected response codes when in "test mode".
> But, as we know, in test mode the transaction IDs are not returned, so
> both are necessary.

I think you want 4111111111111111. I'm not sure if your number is
valid (which would explain the response codes.)

> I imagine I will be hitting the test server in live mode the majority
> of the time. The response code error handling appears solid.

So you are still confirming that the response code works with the test
URL, test API credentials and no "test" gateway option? This is what
I am still trying to reproduce (will try the latest plugin code now.)

> Mike

Sean

[MWesty]

Hmmm...if parameters[:test_request] is reading "FALSE" then you should
be getting a transaction ID.

I did mess up above, and it is the gateway_option row that needs to be
deleted, not just the value. But if you are gettting FALSE then it
should be working correctly.

I'm going to clone the repo and see if it works for me here.

Regarding the need to put it in test mode on the test url. The 13
digit card number 4222222222222 can be used to generate specific
response codes when in test mode. For example, using that card and a
$27.00 transaction will generate a response code of "27". A $28.00
transaction will generate a "28", etc. This only works in test mode.
I tested it with quite a few and they all worked so I won't be using
it much.

Mike

[Sean Schofield]

OK it turns out there is yet another "test mode" setting to concern
yourself with. This time at the *account* level. When logged into
Authorize.net there was this big red banner warning about how I was in
"Test" mode. Well, I just assumed this was because I was using the
test URL with my test account.

Turns out there is the test URL, test mode (at the account level) as
well as test parameters that you can POST via the active_merchant
plugin/gem. Seems a little redundant if you ask me. I mean, I'm
already posting to the Test URL, isn't that enough? I guess the test
mode at the account level is useful for testing that the production
credentials are set up properly and they are just mirroring that in
the test account.

So now everything works fine. Transaction ID is received and order is
posted to Authorize.net test account.

Sean