cancel
Showing results for 
Search instead for 
Did you mean: 

Integration Issues with Live Auth.Net Environment

All,

 

After several successful charge batteries moving through the AIM test transaction environment and both of our staging envirionments, we cannot push these same transactions through the live environment.

 

We continue to process "new sign-ups" that arrive directly to the site and subscribe to the service, however, any of the renewing charges that we are generating based on expiration date are not charged to the account.

 

LIkewise, we are not receiving any response from Authorize.Net for these transactions (not even the responses we do receive from the test environment).

 

We have verified:

 

- The account is not in Test Mode (obviously, with the active charges still arriving)

- The live environment is not utilizing the test URL (

https://test.authorize.net/gateway/transact.dll)

- Neither environment is utilizing the test data variable (

x_test_request)

 

What would be the next battery of tests that we can accomplish to troubeshoot this?

 

I read in the documentation that we can access test submissions to ensure all data is being passed correctly, but was told by Authorize.Net phone support that the person I was speaking to does not have access to this information. 

 

How can we coordinate a timed test in an attempt to identify whether transaction information is being received at all?

 

Any help would be much appreciated.

 

Tom

MoDeveloper
Member
6 REPLIES 6

When you say "renewing charges" do mean subscriptions? If so, that's a different thing then AIM. That would be ARB which means changing the URL from https://apitest.authorize.net/xml/v1/request.api to https://api.authorize.net/xml/v1/request.api.

 

When switching from the developer server to the production server you should need to change only three things:

 

  1. The API Login ID
  2. The Transaction Key
  3. The Server URL

If you changed anything else you probably broke something. I would go back and change your code so it is working with the development server again (and make sure the developer server is not in test mode, too). Then change just the three settings above. If that doesn't work make sure your Login and Transaction key are correct and your Authorize.Net account is set up properly.

 

If you still have problems let us know more about the code you are using and we can go from there.


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post
stymiee
Expert
Expert

Thanks for the post.

 

We are not utilizing the ARB for these charges, we are managing the "subscription" and "recurring billing" on our side.  As somone's expiration date arrives, we simply issue a new charge to their card.

 

I'll review the other items you noted as being required modifications and post an update . . .

 

Make sure you're PCI compliant if you're doing you're own recurring billing. To use AIM for recurring billing you must be storing the credit card numbers which definitely has big security implications. ARB and CIM take the bulk of PCI out of your hands and might be worth looking into.


-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post

I second stymiee. I've actually implemented credit card storage systems in the past - some of my clients still use them - but with the rules getting more and more strict (not supposed to store the security code at all now, as far as I know...), it makes good sense to switch to something like CIM, which stores it for you but still allows you total flexibility when it comes to charging.

Guys,


Thanks so much for your responses.  We're investigating the use of ARS moving forward.

 

In the mean time we've identified that the same code that is not running in our live environment as a scheduled task within the system runs without an error from a SSL-secured webform submission.

 

So we've narrowed our troubleshooting down to the number of transactions being transmitted in a single effort (though our velocity is set to open-ended within the account) or an issue with running the scheduled task versus having a webform submit (probably due to there not being an SSL referrer on the scheduled task) despite it being secure.

 

Has anyone experienced either of these issues in the past?

 

 

If you run as a scheduled task, your page will be intepreted as if it were run from the command line, which often means a different version of PHP with different settings (if using PHP, anyway - don't know about other languages). You need to SSH to your hosting command line and run your exact cron command from there to verify that it works. If there's an error, you'll know what needs to be fixed. In the case of PHP, the problem is usually either using file name instead of the base path, or in some cases, using the php command instead of the base path to the specific php version you want to run under.