Do you have Authorize.net working in production

[mcsg]

We're consolidating our platform on IPS and trying to get our Authorize.net account working with it.
We have had Authorize account for many years and working successfully with our non-IPS software.

We've set up sandbox API keys on Authorize that let's us see processed transactions through the gateway, without actually processing them.

We are able to use the keys in various software platforms, including using curl from local machines and the server.
But in IPS Commerce, it does not work. It gives back a generic error on the front end: "There was an error processing the payment. Please try a different payment method or contact us for assistance."

It never touches Authorize servers for a response, it doesn't register any errors in the AdminCP.

There is another oddity, in the setup for Authorize.net, the Payment Processor does not save with the settings. 
In Commerce > Payments > Settings > Payment Methods > Authorize.net > Payment Processor is will save the setting we give it. We have tried in several 4.4x installations and all behave the same.

If you have Authorize.net working, or have insight, I would appreciate you sharing. Thanks.

[mcsg]

Bump. Does anyone have any experience with Authorize.net?

Is anyone using it?

[bfarber]

If you're having trouble getting Authorize.net working, my recommendation would be to submit a ticket. I seem to recall they made some recent API changes and it's possible we need to tweak our integration, but unfortunately I'm not intimately familiar with that integration.

[mcsg]

The current implementation in IPS is deprecated process at Authorize.net and for whatever reason does not work with IPS. The deprecated process still works when I send it credentials via curl, but not when I use IPS at all. In fact, there is no error reporting in IPS and no one in support was ever able to tell me why it might not work or to see where the process might be failing in IPS. I asked multiple times about the payment processor not saving (as described above) and no one in support even acknowledged the issue or verified that it was supposed to work. There was no verification that Authorize.net has *ever* worked and given the IPS implementation has been deprecated for several years, it is obviously not a priority and is unknown within IPS support. No one stepped up to assert that it ever worked or how to help me determine why it does not work now.

The support ticket was eventually escalated and Lindy responded saying he was sorry but since it was not being used by a significant user base they could not justify doing any work on it.

[Lindy]

Hi @mcsg - I apologize for your frustration. A ticket search reveals you are among the first to bring up authorize.net this year (I was surprised too;) it's unfortunately just not something everyone is familiar with internally and in rare use by the customer base.

Were you able to get it working in production? If I recall, you were using sandbox mode and I believe authorize.net turned that API off in sandbox mode. Your test script was utilizing the new API which is what you were seeing working. If you've established that you can get your script to work with the old / deprecated API outside of the software, we will be happy to take another cursory look. I can confirm there are a few active customers still using the gateway (mostly as a secondary source) and we used to use it as well. A quick test shows it still works in production mode. 

The gateway will be deprecated in the software in v4.5 (it will not be available for configuration to new setups) and we have decided not to update or support it for the foreseeable future. We of course develop based on demand and the vast majority of our customers use Commerce to sell and manage subscriptions vs one off purchases. While authorize.net offers CIM to provide recurring payment capabilities, Stripe and PayPal are the leaders in subscription payments (from our experience) and it's simply what most have opted to use. Naturally, if circumstances change and demand increases for traditional merchant accounts, we will be happy to revisit - there has never been any issue with auth.net, it's just wildly unpopular in our arena. 

Once again, I'm really sorry we let you down in this area. 

[mcsg]

@Lindy I was never able to get it to work in IPS production.

I was able to get it to work with a script (not the one I sent you) that was pulled from their AIM documentation on Internet Archive: 
http://web.archive.org/web/20150428053006/http://developer.authorize.net/resources/files/samplecode/php_aim.zip

The above scripts work with production and sandbox.
Authorize did not turn off sandbox in AIM and deprecated systems according to several of their support staff.

I should have known there would be issues when the Authorize settings could not be reliably saved in IPS.

We understand the business case for IPS no longer using Authorize, but not the roadmap of it's demise. Why couldn't this have been communicated earlier? Why not publish an open roadmap of plans that does not tip the competition, but gives users an idea of whether features will be supported in the future? Similar to a sunset policy of saying: "This extension of the software has been deprecated by the publisher, and will no longer be supported as of X date."
Shame on me for not diving deeper into the use of Authorize in IPS as we were making the decision to move our member subscriptions to it. I should not have assumed it was a functional, supported part of the software.

We will be switching to Stripe, I agree it is better supported (by Stripe and community), and a better process than Authorize.