CiviCRM Community Forums (archive)

We are using CiviEvent with CiviCRM 4.2.8+Drupal6 and have found that while live transactions are correctly posted to our Authorize.net merchant account, "test-drive" transactions are not being correctly posted to our Authorize.net developer test account. Specifically, although Authorize.net sends out their own confirmation email, the transaction never appears in A-net's "Unsettled Transactions" (in either the developer test account (nor, of course, the merchant account)).

To verify the behavior, on our sandbox site, we changed the CiviCRM Authorize.net payment processor settings to use the developer test account (test.authorize.net) for BOTH "live" and "test-drive" transactions (i.e, using the test URL and our test login/pass combo for both). Under these circumstances, both "live" and "test-drive" registrations should behave the same. But they don't. "live" transactions behave properly, with A-net sending out emails and showing the transaction in "Unsettled Transactions". "Test-drive" transactions send out the A-net emails, but don't show any unsettled transaction in Authorize.net.

(In both cases, CiviCRM sends out its own receipt emails.)

We observed this first in CiviCRM 4.2.6, just upgraded to 4.2.8, and still see this behavior.

Any suggestions appreciated.

Robert

so seems more like an issue with a.net in this case (IMO)

Except that the only way for a.net to know to treat the two cases differently would be for CiviCRM to somehow send something different for test-drive versus live transactions. On a.net's end of things, it's the same URL, same login, same password.

Seems like somewhere in CiviCRM there must be the equivalent of
if {this is live}
  then {send info to live payment processor one way}
else
  {send info to test payment processor another way}

So if the payment processor settings are the same for both live and test-drive, something else must be different.

I'd go code-spelunking, but would appreciate any tips on what to be looking for (like the name of the conditional variable or something like that).

Robert

OK, I've figured out what's happening. It's all taking place in file civicrm/CRM/Core/Payment/AuthorizeNet.php.

For test-drive registrations, the AuthorizeNet.php processor is setting the field 'x_test_request' to TRUE, and it's being left unset for live transactions. This happens in function _getAuthorizeNetFields(), line 372. When x_test_request = TRUE, that tells Auth.net to not record the charge in the merchant interface.

But I think that's counter to the developer guidelines from Auth.net. According to their developer guide (http://developer.authorize.net/guides/DPM/Test_transactions.html), they describe three stages of development. In the first stage, one uses a "developer test account" (which is what we're using). When you're using the developer test account, they do NOT instruct use of the x_test_request field.

In the next section, they say that one can test against the merchant account (the live account), and in that phase, they say you can do testing by including the x_test_request field with a value of TRUE in the form posted to secure.authorize.net.

Note that they say explicitly, "Transactions [using this method] are not stored in the Merchant Interface."

So, it seems like if one follows Auth.net's instructions, x_test_request should NOT be set when one is submitting a test-drive registration to a developer test account, but should only be set if one is submitting a test registration to the merchant account that you don't want recorded.

I guess that the bottom line is, I now know what's going on, and if I comment out that line of code in AuthorizeNet.php, I'll get  the test-drive registrations to be recorded in the developer test account along with the live registrations recorded in the merchant account. So my issue is solved, but it would be nice to know if that was the intended behavior.

Robert