- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JSON API warning: properties are order-dependent
It took me a long time to figure this out. For the benefit of the next poor soul:
The order of the properties of transactionRequest is significant.
If you do not put the "amount" property into your object immediately following the "transactionType" property, you will get confusing errors claiming it is an invalid child element.
This happened to me because I was totaling up the lineItems and then inserting the total as the last property.
Normally in JSON APIs property order does not matter. Indeed, JavaScript does not guarantee a property order, period! But on the back end it's pretty clear authorize.net is translating this into XML and order dependent elements are a little less weird there. Although still weird and annoying and I suspect they could fix this.
But, the simplest workaround if, like me, you want to touch the total property last, is to add it with a dummy value early and then change that value. This works because the order of the properties has already been established.
Hope this is helpful!
08-19-2016 12:10 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This has some other interesting side effects as well.
For example, there's a bug in the XML API related to ampersands: <refId>12&34<refId> (or any other free-text element) becomes <refId>12&34</refId> in the response, which is malformed XML.
I checked the JSON API, and sure enough, the bug exists there, too. "refId": "12&34" becomes "refId": "12&34" in the response, even though ampersands have no special meaning in JSON.
08-19-2016 12:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems the properties in a JSON object are order-dependent for all requests, even a simple "authenticateTestRequest". This is really problematic as it doesn't make any sense for JSON, and it's not easy to figure out why the exact same request that works in the website sandbox doesn't work in your application -- you get an error message like:
"The element 'merchantAuthentication' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'name' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'mobileDeviceId' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'."
Which makes no sense, because the API reference says that "merchantAuthentication" has a "name" property, and it works on the API ref page. There should be a big warning at the top of the API ref page about this issue, or it should be fixed.
Very frustrating. What's the best way to make a JSON request with all the elements in the proper order? I ended up making a template.
02-06-2017 07:31 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm having this same issue it's pretty concerning that this bug exists. And I took a look into the Sample iOS SDK and noticed that it manualy builds out the JSON request as a string piece by piece. I've sent a ticket to support, but am going to have to find a temporary work around for this :/
04-07-2017 04:45 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's worth mentioning that our current JSON request and response format is not a RESTful implementation, instead it's a conversion from XML to JSON.
We DO have a REST API in development.
Richard
04-08-2017 07:30 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've noticed this in my development as well. It's worth noting that RFC 7159 which is the official document for the JSON spec explicitly states, "An object is an unordered collection of zero or more name/value pairs". Indeed many, if not most JSON libraries make it very difficult, if not impossible, to generate the pairs in any specific order (and I've had to jump through hoops to do so in my implementation). It is reasonable to say that AuthorizeNet errs in even calling their implementation "JSON" at all.
09-15-2017 08:33 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still a problem in 2018.
Ron
Linvio, Inc.
Salesforce.com/Authnet Integration
02-13-2018 04:36 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Still a problem in 2023 AND NO UPDATE TO API DOCUMENTATION. Very, very disappointing. I posted a case and had 5 different people from Authorize.net respond and no reply mentioned anything included in this posting...
03-28-2023 08:25 AM