I followed the example shown on https://developer.authorize.net/api/reference/features/acceptjs.html into my php page form but when I process the form with
Accept.dispatchData(secureData, responseHandler);
It generates an OPTIONS error response of :
{ "messages": { "resultCode": "Error", "message": [ "code": "E00003", "text": "Root element is missing." ] } }
The secureData being submitted (in case it matters) is:
{ "cardData": { "cardNumber": "4111111111111111", "month": "02", "year": "2018", "zip": "83854", "fullname": "Lisa Smith �" }, "authData": { "clientKey": "2w77y4wpDGw89R8bM2VcRS4Bm69tQ6qLYT5ACbq9E2uBW9wgVqPAzXADfdC8kqLz", "apiLoginID": "72R9aMvP" } }
I checked and made sure the sandbox key and login id are correct.
I also get a POST response from apitest.authorize.net:
{ "opaqueData": { "dataDescriptor": "COMMON.ACCEPT.INAPP.PAYMENT", "dataValue": "9486742822834605004604" }, "messages": { "resultCode": "Ok", "message": [ "code": "I00001", "text": "Successful." ] } }
but since the OPTIONS returned an error it does not call the responseHandler() routine.
I hope I have included enough information for someone to see and help with a solution.
One other thing. The console also shows a message:
TypeError: window[b] is not a function AcceptCore.js:1:3956 n https://jstest.authorize.net/v1/AcceptCore.js:1:3956 o/c.onload/< https://jstest.authorize.net/v1/AcceptCore.js:1:4265
02-10-2017 08:50 AM - edited 02-10-2017 08:57 AM
I did a bit more fiddling and realized that the function being called in Accept.dispatchData() needed to be quoted - it isn't supposed to be a pointer. It now calls the response handler but I still get that OPTIONS error but I assume that it will not interfere with the process.
The OPTIONS error is something I will ignore for now.
02-10-2017 09:09 AM
Hi @wdbaker54,
Just a heads up for you and anyone watching this thread that we've released code in sandbox that fixes many of the issues brought up here, and this code should make it into the production environment within the next couple of days.
Specifically for Accept.js, there's no longer any "Access-Control-Allow-Origin" related error in the console, the accept.js script can now be loaded at any point in the workflow, and the response handler function can be passed directly in the function call instead of having to pass the name.
Of course, please let us know if anything's not working as expected!
03-07-2017 03:53 PM
I was also having this issue, and it seems to be related to the second function (processTransaction).
Wrapping the callback function in parenthesis did not work for me, in fact it caused the error:
TypeError: window[b] is not a function AcceptCore.js:1:3956 n https://jstest.authorize.net/v1/AcceptCore.js:1:3956 o/c.onload/< https://jstest.authorize.net/v1/AcceptCore.js:1:4265
So I'm guessing that was changed so it does indeed expect a literal reference, not a string.
Apparently, this callback is being wrapped in a try / catch block inside the Accept.js script, which is preventing any default javascript errors from appearing in the console, and it seems the example has some invalid javascript within it.
Commenting out the default form creation and submission not only allowed the function to execute all the way to the bottom, but eliminated the second call to 'OPTIONS'.
Further investigation led me to find the problem:
amount.value = document.getElementById('AMOUNT').value;
The example code contains an amount field, however the id is actually all lower case. This results in an
Uncaught TypeError: Cannot read property 'value' of null
That is caught but never passed to the user.
Basically, someone needs to change 'AMOUNT' to 'amount' in the docs.
04-03-2017 08:10 AM
Hi @dmeganoski,
Sorry about the error in the example. We've already fixed it on our end, and are just waiting for the next site update. Also addressed here.
04-03-2017 08:17 AM