Errors E00003/E00117 with Accept JS

[felixschl]

I am using the sandbox.

When I run Accept.dispatchData, I see two network requests take place, both of which return error responses.

> OPTIONS /xml/v1/request.api HTTP/1.1
> Host: apitest.authorize.net
> Connection: keep-alive
> Access-Control-Request-Method: POST
> Origin: https://localhost:8000
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
> Access-Control-Request-Headers: content-type
> Accept: */*
> Referer: https://localhost:8000/donate/
> Accept-Encoding: gzip, deflate, br
> Accept-Language: en-US,en;q=0.8
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: application/json; charset=utf-8
< Server: Microsoft-IIS/7.5
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
< Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
< X-Cnection: close
< X-Powered-By: ASP.NET
< Content-Length: 102
< Date: Tue, 08 Aug 2017 18:17:15 GMT
< Connection: keep-alive
{"messages":{"resultCode":"Error","message":[{"code":"E00003","text":"Root element is missing."}]}}

And:

> POST /xml/v1/request.api HTTP/1.1
> Host: apitest.authorize.net
> Connection: keep-alive
> Content-Length: 313
> Origin: https://localhost:8000
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
> Content-Type: application/json; charset=UTF-8
> Accept: */*
> Referer: https://localhost:8000/donate/
> Accept-Encoding: gzip, deflate, br
> Accept-Language: en-US,en;q=0.8
{"securePaymentContainerRequest":{"merchantAuthentication":{"name":"...","clientKey":"..."},"data":{"type":"TOKEN","id":"...","token":{"cardNumber":"4007 0000 0002 7","expirationDate":"122033","cardCode":"123"}}}}
< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: application/json; charset=utf-8
< Server: Microsoft-IIS/7.5
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
< Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
< X-Powered-By: ASP.NET
< Content-Length: 121
< Date: Tue, 08 Aug 2017 18:17:16 GMT
< Connection: keep-alive
{"messages":{"resultCode":"Error","message":[{"code":"E00117","text":"OTS Service Error 'Field validation error.'"}]}}

That leaves me little to nothing to go on with as both error codes don't perform well in a google search.

The worst part of all of this is that the response handler passed to Accept.dispatchData is never even fired!

[felixschl]

I would also really love an answer to the artificial 2 second timeout? Why does it exist? Why not just call the callback?

[felixschl]

I have, quite accidentally actually, found the root cause for the "onload" callback not firing and it was NOT related to authorize.net in any way, but instead with a 3rd party module I am using in my django app: https://github.com/jorgebastida/django-dajaxice/blob/master/dajaxice/templates/dajaxice/dajaxice.cor....

So now the only issues remaining are:

• Every now and then requests fail immediately with E_WC_14, I'll dig into this one more
• The artificial 2 second wait
• Better error reporting for the catch all error (E_WC_14). Even a console.warn would do the trick.

[Aaron]

Hi @felixschl,

I'll address the other points shortly, but I first want to address the non-minified script. I've been pushing for such a thing. I can't just take the source .js out of our repository and post it somewhere because there's too much internal stuff in there. But, I can at least probably take the minified version, de-minify it, and give new function names and comments based on my knowledge of the internal workings.

Ultimately, though, what I'd really like to see is a version suitable for public consumption that's either linked to from our documentation and automatically updated with each release, or, an actual live usable non-minified version that a developer can optionally use in the development process for troubleshooting.

I'd encourage you to post this onto our Ideas Forum where others can take a look, contribute feedback, and vote for new features, as it would help us to track and build support internally.

As far as open source, I'd love it but that's tricky. Remember, we're Visa, and we're part of the machine that is responsible for good chunk of the whole world's commerce. Visa is naturally a little reluctant to do anything that could ever have a negative effect on that vast network.

Our core transaction processing system would never be open source for that reason, but we've got tools like our SDKs that exist to help developers use our core system which are open source. Accept.js sits in a middle ground between those. It's a tool to help you use our system, but it's a little closer to being a core feature of the system.

With a JavaScript, you can see the source (albeit in a minified form), so it's not as if closed source would protect against people seeing the inner workings of the script. One thing that works against open sourcing it is the fact that it would never be something that people would be able to fork their own versions of since our system would only give tokens to our version hosted on our site. Still, even knowing that, open sourcing the component would give people more view on the development process and the ability to possibly impact changes.

If we just want to meet the desire to see how things work, we can do that by getting a non-minified script out there. I'll keep working on that on my end.

These are my thoughts personally, though, and any decision to open source a component is made above my pay grade, but making more things open source is definitely something we consider all the time.

[Aaron]

As to these remaining issues:

---

@felixschl wrote:

• Every now and then requests fail immediately with E_WC_14, I'll dig into this one more
• The artificial 2 second wait
• Better error reporting for the catch all error (E_WC_14). Even a console.warn would do the trick.

---

Failing with an E_WC_14... Ugh. Since it's a broad case, it's hard to troubleshoot. Sorry about that, should get better. It's often issues of the scripts not loading properly or fully, which leads us to the next point:

Timeouts - From glancing through the code, my (perhaps erroneus) conclusions are: In Accept.js, there's two functions that wait for time to elapse before being called. One waits two seconds before loading AcceptCore.js. Purely speculation on my part, but my belief is that would be there to ensure everything's loaded right first. Shouldn't be an issue in normal practice because it should take someone more than 2 seconds to fill in their payment form. However, if you've got a case where it's interfering with something else or causing other problems, let us know.

The other timed function only fires when the hash of an AJAX load of AcceptCore.js doesn't match what Accept.js is expecting. After two seconds it looks like it's going through the dispatchData process but overwriting the result with an error code specifically so that error can be passed to your response handler, and also possibly overwriting some other variables. Don't know why it has to wait two seconds there, but I suspect it's for a fallback in case the error code doesn't make it to your callback another way?.

In AcceptCore.js, there's one timed function that fires two seconds after onload fires for the API request. But, it doesn't look like anything's actually waiting for that response. It looks like that's just overwriting the actual API response codes after another part of the code deals with it.

Again, just my conclusion after trying to step through the code served from our site. It seems like this would be a little easier if there was a version of the script that perhaps wasn't minified, and had some comments explaining what was going on...