getHostedPaymentPageRequest request seems currently useless

[lucasmgreen1984]

I have not yet discovered a reliable way to associate a transaction to an order, if that transaction is initiated with 'getHostedPaymentPageRequest'. The response includes a token but no transaction identifier.

When initiating the request with almost any parameter that could be used to associate an order a response similar to this occurs:

Error [E00003] : The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'refTransId' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'shipTo, customerIP, cardholderAuthentication, retail, employeeId, transactionSettings, userFields' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd

Anyone else have a similar problem?

[lucasmgreen1984]

Ok, Authorize.Net, your JSON validator is broken, it considers JSON keys that do not match the order of your xsd to be invalid.

I'm sorry to say this does not inspire confidence.

[Aaron]

The JSON validator works fine. It doesn't care about the order of the parameters. That's just a small part of the process, though. The problem is after the request gets through JSON validation and gets handed off to the process that acts on the API request. That process expects its input to be in a certain order, whether the input is coming from the JSON endpoint or the XML endpoint. There's no middleware on our end between the JSON validator and the API processor that will reorder the parameters into the order expected by the API processor.

The JSON format defined in RFC 7159 (http://www.rfc-editor.org/rfc/rfc7159.txt) doesn’t require implementations to accept input in any arbitrary order of the content of objects. However, there’s nothing in the RFC requiring any implementation to preserve a certain order either (except in the case of arrays). There’s enough ambiguity there in the spec that an implementation like ours that does require the objects to be ordered can still be considered compliant, as could an implementation that outputs JSON in a random order. However, the two implementations would not be interoperable. See section 4.

Despite that ambiguity, or perhaps because of it, usage of JSON in practice has evolved where virtually everyone expects the order of the information within objects to not matter. Developers expect that their implementation should be able to output the pairs in any order, and the receiving implementation consuming their JSON should be able to decode those pairs in any order. By that standard, our implementation is definitely wrong and frustrating, and for that, I apologize. However, that’s the way it works right now. For our implementation, order matters.

Please be assured that we’re well aware of this, we all understand that this isn’t a good developer experience, and whether or not it’s compliant with any standards it’s definitely not an example of a “proper” JSON implementation. Please stay tuned, though, as we have lots of API enhancements planned this year, touching on this particular issue and much more.

[lucasmgreen1984]

I would suggest that far more people are familiar with and operate on the original 'spec' than the IETF spec.

http://json.org/

http://imgur.com/s39SK6x

Considering I solved the issue on my end by loading up the XSD and making sure my JSON object is assembled in the order found there I don't understand why you can't put in a piece of middleware that simply reorders it from the incoming order to the XSD order instead of trying to rework that bit to be order neutral?

Maybe your system is more complicated than I am imagining.

[Aaron]

Complicated? Yes. Very much so. That by itself isn't an excuse for a bad experience, though. Trust me, we're working to solve this, but probably not by making the existing API work better. Developers are clamoring for a REST API, and that's where our efforts are focused. The JSON payload sent as part of any requests to a future REST API would indeed be order dependent.

I wish I had that to give to you today, but I don't. Please stay tuned for more announcements along those lines, though.