Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
09-21-2016 03:18 PM
Please excuse if this becomes a long post.
I work for a small web development company that provides custom solutions (often involving e-commerce) to other small-to-medium sized businesses. In the past, I have created my share of solutions using Authorize.Net as the payment gateway.
However, it has been a few year since I last worked with Authorize.Net. Now we have had a company approach us for an online payment solution, and they want to use Authorize.Net as the gateway. They want a silent submit to a payment gateway, with a real-time response (approved, denied, etc.) I think, no problem, I've done that with Authorize.Net before. I thought I might even be able to dredge up some previous code and be most of the way there.
Now I am not so sure. Wow, have things changed since the last time I used Authorize.Net. Previously, I seem to remember that I had the AIM or SIM methods to choose from. My needs were usually simple, so I would use SIM, which has morphed into something which is now called “Payment Form,” and appears to be a means to call up a payment form like PayPal. The documentation I have managed to find mentions SIM as supported, but not recommended, because it is not the latest, greatest thing that will be maintained from now on. And a payment form is not what I want anyway.
Then I look around for AIM documentation. It appears to be gone, being replaced by something referred to as “Payment Transactions.” Previously, I would populate a web form with “x_-type” name-value pairs to submit to the Authorize.Net gateway endpoint URL. The current “Payment Transactions” documentation covers a lot of field names, but no x_-type fields at all. And I have been unable to find any mention of how, in principle, the data should be set up for sending to the Authorize.Net gateway, where it should be sent, or how it should be sent.
So then I look for sample code. PHP is obviously the more popular coding option for web sites nowadays, but what puzzles me is that I can find code samples for things like Ruby, Python, Node, Java, C#, etc., but nothing for Perl, which is what I am using. When did Perl become the red-headed **edited** step-child, never to be mentioned? Last time I checked, Perl is still being used 10 times more than all of those other off-brand languages, combined.
I previously used a Perl module (I believe it was provided by Authorize.Net) called SimLib, which I could use to create MD5 hashes for enhanced transaction security verification. Would I still use that? If not, what is the current equivalent?
Once upon a time, I used to be able to call Authorize.Net for support – difficult, technical support, and be able to get past the first tier to speak directly to one of the “developers.” This provided me with very timely technical help, especially when I was under a deadline.
Well, I'm under a deadline now, and I find that Authorize.Net has followed the unfortunate habit of some other companies and hidden their developers, the ones who really know their stuff, in some dungeon basement somewhere, never to be accessible by the general public again. I have to submit a silly and questionably relevant email form to them. I did that, and I've been waiting two days to hear back. Still nothing.
So, long story short – if Authorize.Net has changed things so much that I need to start over from scratch, so be it. But where on earth do I find documentation that will explain clearly everything I need to know to create a Perl-based solution, using their currently recommended system, for our customer? I have spent two days crawling around all the many Authorize.Net subdomains (support, developer, community, etc.), searching high and low, and I have yet to find the definitive start-to-finish, here's-all-you-need-to-know-to-do-it type documentation. When I call the first tier people, they can't help me, and sometimes don't even know what I'm talking about.
So, in desperation, I leave this long post on a community blog, hoping that some helpful, kind, in-the-know person can direct me to the definitive source of all information I need to achieve my development goals, and create a solution that uses all of the current Authorize.Net recommended methods and systems. Or disclose to me the secret method for directly contacting any of the “developers,” so I can just ask directly, like I used to be able to do, once upon a time.
09-21-2016 03:42 PM
Yes, we are soon replacing SIM with a more modern solution that uses the Authorize.Net API as found in the API Reference. You have the option to use our XML/JSON request response. Unfortunately, we do not currently offer a Perl SDK but you'll find our old SIM sample code attached to this post. You can even take a walk down memory lane perusing our AIM NVP documentation.
It sounds like your client is looking to minimize their PCI scope using a hosted form and don't need control over the user experience. Am I understanding your requirements correctly?
09-21-2016 05:23 PM
I am very pleased to hear from someone. In response:
I appreciate your offering of old Perl code samples. It looks like what I used to do, submitting to the gateway endpoint of "https://test.authorize.net/gateway/transact.dll". Would I even use that URL any longer? Or use the POST method to send to it? If not, what is the new URL and method?
I also see "x_"-type fields in the old sample code - would I still use those fields? Or are those part of the obsolete methods? If would not use them, I need to be sure what the new field references really are, and know if they have explicitly replaced the "x_"-type field references?
I already have my own samples (that worked on earlier versions of Authorize.Net systems). What I could actually use are some Perl code samples that work on your current, recommended methods. I would probably use the XML option.
You are correct about our client's desires concerning PCI. I specifically discussed it with them, and they are fine having the senstive data (such as, obviously, card number), sent securely to the Authorize.Net gateway, and not storing it on their server.
So... In addition to responses to the above, I would like to know if I would need to come up with a Perl-based method of XML communication to the Authorize.Net gateway. There are generic Perl modules that can help with XML, but I feel like I would need some more specifics on how I would need to format and communicate the data than what I have currently come across.
09-23-2016 02:56 PM
Well, I was initially pleased to get a fairly timely response. However, that has turned again to disappointment.
I appreciated the offer of old code, but I explained that I already have old code. I need some guidance on the currently recommended methods.
When I replied with some specific technical needs that I believe should actually help me move forward, I got no further replies.
I have called the normal tier 1 support multiple times, and they tell me the only way I can reach any developers is to use some email form. Well I used that, and I never got a response.
Then they told me to use this forum. Well I used this forum, and so far, I've gotten no useful information.
Is it really that difficult to provide truly complete and detailed A-Z implementation guidelines? Absent that, isn't there anyone who can answer my technical questions?
09-23-2016 05:01 PM
From your questions here, and the note you sent to the developer mailbox, it appears you're familiar with DPM and are looking for something similar. Let me suggest you begin exploring Accept.js.
With Accept.js, you create your own form so you have control over the user experience. You then use the Accept.js library to obtain a payment nonce, or one-time token that you then submit along with other items in your form using createTransactionRequest using the payment nonce.
You also mention SIM which offers less UI flexibility but can help merchants potentially reduce their PCI scope. I don't recommend that option because we are soon to offer a replacement that leverages the same Authorize.Net API using XML or JSON but uses a responsive, fully hosted payment form.
Unfortunately, we cannot assist you with how to use Perl to communicate with our gateway. Instead, you'll need to discover how to send/receive either XML or JSON to our API or use one of our other language SDKs.
09-24-2016 06:54 PM
I appreciate the response. It helped me to realize some important things. Especially toward the end of your post, where you said, "... you'll need to discover how to send/receive either XML or JSON to our API..."
That's what made it finally click for me. In searching for a solution, I've been asking what I thought were AuthorizeNet support questions, when really I was asking Perl support questions. And AuthorizeNet does not support Perl any longer, like they did once upon a time. So I finally realized that I was truly on my own.
So I messed around with some Perl solutions for getting data into an XML format (XML::MyXML, XML::Dumper, and similar modules provide a reasonably simple solution), then LWP::UserAgent and HTTP::Request to send the results to the AuthorizeNet gateway endpoint (for my testing, I used https://apitest.authorize.net/xml/v1/request.api.)
And I have been able to send a successful test transaction! I still need to work on parsing the return data, but once again, that is a Perl issue.
As far as the Perl support issue... I don't know why AuthorizeNet thought it prudent to drop support for Perl, but maintain support for other languages, most of which are still not even used as much as Perl, depending on which stats you believe.
Ruby and Python seem to be more "fashionable" among kids fresh out of college. It looks like most programmers who are on Facebook will follow the current fashion and go with Ruby or Python. But the question of whether a language is “popular,” or perceived as shinier or sexier or newer is not the same as the question of whether it is better.
I neither know nor care whether Perl is "popular" in a Facebook world. The important thing is, I believe it is probably the most widely used scripting language among people who accomplish a lot, which is a very different thing.
AuthorizeNet used to provide support for Perl, and I think it was a mistake to drop that support. I think someone there should seriously reconsider that decision, and resume support for Perl. Even without touting itself in the popular circles like Ruby or Python, it still has at least the same level of usage on web sites worldwide as those other two languages.
So bring back support for Perl!