cancel
Showing results for 
Search instead for 
Did you mean: 

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!

boutell
Member
7 REPLIES 7

This has some other interesting side effects as well.

 

For example, there's a bug in the XML API related to ampersands: <refId>12&amp;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&amp;34" becomes "refId": "12&34" in the response, even though ampersands have no special meaning in JSON.

dhammond
Member

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.

 

 

hobbsd
Member

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 :/

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

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.

 

pajamian
Member

Still a problem in 2018.

-------------------------------------------------
Ron
Linvio, Inc.
Salesforce.com/Authnet Integration
linvio
Contributor
Contributor

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...

mikecegroup
Member