We have listened closely to developer feedback about our API documentation and as a result, we have developed a new online guide for XML API reference information. This new guide is currently in a beta phase. This guide is designed to reduce the amount of time that you spend researching the API and enable you to start writing code as quickly as possible. The new format includes request and response information, as well as code samples and even a console that allows you to submit requests to our sandbox server in real-time. XML services include transaction processing, Automated Recurring Billing (ARB), Customer Information Manager (CIM), and transaction detail reporting.
We encourage you to experience this new guide. There is a feedback link where you can share with us your impression of the new format, or you can join the discussion below so that we can continue to improve it and provide you with the best experience possible.
I enjoy the tabbed layout and the customization of the samples with our own login and transaction codes. I assume the purpose is to help test our sandbox settings and if so where is guidance to help troubleshoot?
I felt like it easily showed me that my transaction was failing. Great, but I saw that with the application. Why is it failing is just as important.
I apologize if this is in the wrong location. But I'm not sure where to ask. I'm wondering if there is any reference that maps the name/value pairs to the XML tags? So to show that x_avs_code is now avsResultCode, for example. There are a few that I just can't seem to figure out.
While it's nice to see the XML examples here, It's truly unfortunate that the [url=https://github.com/AuthorizeNet/sdk-php]PHP library[/url] a) requires Composer which has a [url=https://github.com/composer/composer/issues/1074]big MITM vulnerability[/url] and b) is so poorly documented.
For instance, where can I find out the character encoding of the PHP SDK returns server responses?
Thanks for the feedback on the new API Reference.
As for new features, your best source is Ideas forum where you can see the status of similar requests. Once they move to accepted, the feature is on our roadmap. We also post updates if there are any updates like release dates, etc.
I would like to say its nice that you are trying to create an API documentation for your users. I went through some of it today and I have a few suggestions / questions:
1. The syntax you used for displaying what I think are properties to classes / objects is denoted by "."? There are several standard syntaxs that developers use for defining classes and I don't know of one that uses dots. Instead of re-inventing the wheel it might server your users better to use something more clear.
2. You use only a few properties in your "Request / Response" examples. It would serve you better IMHO if you used all of the properites and fields in your examples so there is a clear defintion usage for all of them.
3. In the create customer profile you list under the billto section that most of the values are only neccessary if they are "only when you use a European payment processor." But in your sample for Get Customer Profile your xml clearly displays the entire address with USA values for the customer. Does this mean that they are required for USA transactions? Its very unclear.
4. Also is there a correlation with the SDK with the XML? If so, you could also show corresponding samples in each of your supported developer languages that show the usage with the SDK. Raw xml is nice but the meat and potatoes is the code you write to support it.
Please do not take this is as critisim, it is not my intent I am asking questions / making suggestions. I think its great that you are attempting something like this, a lot of companies with integrations lack even basic documentation / samples.
Also, under create customer profile for shipping address:
|shipToList||Contains shipping address information for the customer profile.|
I did not know this is can contain many values until I looked at the request object. But on
|paymentProfiles||Contains payment profiles for the customer profile.|
Multiple instances of this element can be submitted to create multiple payment profiles for the customer profile.
it clearly states that it supports multiple values. Consistency is important in documentation.
Thanks for the feedback on our API Reference. We continue to work on this resource, a new version will release in just a few days.
For question 4 about sample code, the answer is yes. New sample code snippits are under development now on GitHub. You can see the latest progress at https://github.com/authorizenet