Accept.js - Exceptions regarding failure to load from CDN and bad CORS headers

[describeit]

I'm getting two errors when loading the library:

1)  XMLHttpRequest cannot load https://jstest.authorize.net/v1/AcceptCore.js. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://[mydomain]' is therefore not allowed access.

2) Library is not coming from Accept CDN.

based on some posts from a previous thread here back in August (https://community.developer.authorize.net/t5/Integration-and-Testing/Accept-js-error-E-WC-14-Accept-...)

I've tried not only loading the script as listed in the official documentation:

<script type="text/javascript" src="https://jstest.authorize.net/v1/Accept.js" charset="utf-8"></script>

This generates error #1 above related to the CORS origin headers.

I've also tried loading the script dynamically as recommended by the moderator on the thread by doing this:

$(document).ready(function () {
        $.getScript(jsUrl, function (data, textStatus, jqxhr) {
            dispatchEvent(new Event('load'));
            GetScriptCallback();
        });
    });

and this generates both of the errors listed above.

Since both errors appear to be blocking issues, I can't seem to get past it, so at the moment I'm dead in the water.

From the thread I cited above, it seems these errors just magically stopped happening for some folks and then came back randomly and then stopped again and so on.  It seems I'm at a point where they are reappearing.

I'm not sure what the status of the Accept.js library but based on the open threads and the errors I'm stills seeing 2 months later it seems like somebody shipped it before it was ready for primetime.

Nonetheless, I've now got a client who is looking to get up and running with it next week and I'm stuck sorting out these errors so I'd appreciate some assistance.

Any updates on what the latest code or documentation is for this library?

[jhoffman20]

Brian,

FYI:  we are trying this with a sandbox account.  Is that the issue?  I am not sure how Auth.net routes requests through the back end, but I wonder if perhaps a different server is handling the request when a sandbox account is referenced?

Thanks

Jeff

[describeit]

Hi Brian,

  In reviewing your code again, I just realized that instead of passing the actual callback method into dispatchData() your only passing in the name of the callback method and forcing your code to go find it in the window array.

  This seems like a really convoluted way to accomplish this and in my situation where I have a non-trivial js architecture somewhat impossible to actually implement.  Is there plans to allow dispatchData() to accept the actual function instead of a string to the function name?

[describeit · Accepted solution]

Kris and Jeff, make sure your passing in a string for the second parameter for dispatchData and not the actual responseHandler method.

I'm coming from the Stripe world where you just pass in the responseHandler method and your done, but this requires you to pass in the name of the method as a string and then define the responseHandler as a global function that can then be found by window[c].

Kind of unorthodox and a pain to deal with, but once i adjusted for that I got it to work.

Invoking Call:

Accept.dispatchData(secureData, 'handleAuthnetResponse');

Note the second parameter is a string, not a variable.

ResponseHandler:

  window.handleAuthnetResponse = function(response) {
    var error_messages = '';
    var error_container = '';

    if (response.messages.resultCode === 'Error') {
      for (var i = 0; i < response.messages.message.length; i++) {
        error_messages = error_messages + response.messages.message[i].code + ':';
        error_messages = error_messages + response.messages.message[i].text + '<br/>';
      }

      error_container = '<div class="alert alert-danger"><a class="close" data-dismiss="alert">×</a>' + error_messages + '</div>';

      $authnetRoot.find('#processor_error').html(error_container).show();
      $authnetRoot.find('button[type=submit]').prop('disabled', false);
      $authnetRoot = null;
      return false;
    }
    else {
      console.log(response.opaqueData.dataDescriptor);
      console.log(response.opaqueData.dataValue);

      $authnetRoot.find('.authnet-card-token').val(response.opaqueData.dataValue);
      $authnetRoot.find('form.authnet-on')[0].submit();
      return true;
    }
  }

[brianmc]

I'm afraid lazy loading does not work in this release of Accept.js.   This is our number one request for the next version and we hope to get it out soon.  Can you try without using require?

Brian

[describeit]

Brian,

  I'm using the ruby-sdk version of the Authorize.Net API and I'm a bit unsure how to build the CreateTransactionRequest that you list in your sample application that you linked to above.

    transaction = Transaction.new(params[:api_login_id] , params[:transaction_key] , :gateway=>:sandbox)

    request = CreateTransactionRequest.new

    request.transactionRequest = TransactionRequestType.new()
    request.transactionRequest.transactionType = TransactionTypeEnum::AuthCaptureTransaction
    request.transactionRequest.amount = params[:amount]
    request.transactionRequest.payment = PaymentType.new

    request.transactionRequest.payment.creditCard = CreditCardType.new(params[:card_number] , params[:exp_date] , card_code)

What do I replace the CreditCardType.new command with to generate the opaqueData structure that you have laid out.

Its unclear in the source code in github how that is being handled.  Any advice on that would be much appreciated.

[brianmc]

We have a sample in our Ruby Sample code repo:  https://github.com/AuthorizeNet/sample-code-ruby/blob/master/MobileInappTransactions/create-an-accep...

I have just updated it as the data descriptor was incorrect.  I'm still testing with a live token but I wanted to get you the sample at least.

Brian

[krisajenkins]

Brilliant, thanks describeit! I was passing a string, but the callback function I'd defined wasn't in window scope, so their callback hack couldn't find it. When I put the callback at the top-level (yuck!) it works.

Brianmc, is there a reason for the callback parameter being a globally-scoped string-name-of-a-function? I've never seen anyone else handle callbacks in this way, and it seems like a real hack from here. It's just cost us 3 days progress, so it would be nice to know there's some method in the madness...

[firebird]

Thanks @describeit!

For me, the crucial part to get Accept.js working was the terrible practice of declaring the function on the window object:

window.handleAuthnetResponse = function(response) {

[dustin1]

Although this thread is marked with a solution, it sounds like the CORS issue was not resolved?

[Aaron]

Hi @dustin1,

As of today, the CORS issue is resolved in sandbox.

For anyone else watching this thread, we've released code in sandbox that fixes these issues, 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!