Accept.js error E_WC_14:Accept.js encryption failed.

[zamiksica123]

Hello

what this error means (E_WC_14:Accept.js encryption failed) and how to solve it?

Thank you

[ask_dev_sam]

I am also getting "E_WC_14:Accept.js encryption failed." I have processed a number of test transactions in the sandbox with the below code now I am getting the above error.

The elevent part of the code are:

function sendPaymentDataToAnet() {
    $('#errorMessage').hide();
    $('#spinner').show();
    var secureData = {}, authData = {}, cardData = {};
    
    cardData.cardNumber = $('#cardNumber').val();
    cardData.month = $('#expMonth').val();
    cardData.year = $('#expYear').val();
    cardData.cardCode = $('#cvv').val();
    cardData.zip = $('#cardZip').val();
    cardData.fullName = $('#cardName').val();
    
    secureData.cardData = cardData;
    authData.clientKey = '<?php echo $authKey?>';
    authData.apiLoginID = '<?php echo $authId?>';
    secureData.authData = authData;

    //console.log(secureData);
    
    Accept.dispatchData(secureData, 'responseHandler');
}
function responseHandler(response) {
    if (response.messages.resultCode === 'Error') {
        html='<ul>';
        for (var i = 0; i < response.messages.message.length; i++) {
            console.log(response.messages.message[i].code + ':' + response.messages.message[i].text);
            html+='<li>'+response.messages.message[i].text+'</li>';
        }
        html+='</ul>';
        $('#spinner').hide();
        $('#errorMessage').html(html).show();
    } else {
        useOpaqueData(response.opaqueData)
    }
}

Access.js is included in the head of the page with:

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

I would like to know why the error is happening.

[stephencarr]

There seems to be a bug in AcceptCore.js. When it loops over received API responses it's not processing the error response object correctly.

// The function in question (this is in AcceptCore)

function n(a, b) {
    try {
        var c = JSON.parse(a.responseText);
        if (void 0 !== c.messages.resultCode && void 0 !== c.messages.message && c.messages.message.length >= 1) {
            for (var d in c.messages.message)
                switch (c.messages.message[d].code) {
                    case "I00001":
                        c.messages.message[d].code = "I_WC_01";
                        break;
                    case "E00001":
                        c.messages.message[d].code = "E_WC_15";
                        break;
                    case "E00003":
                        c.messages.message[d].code = "E_WC_16";
                        break;
                    case "E00007":
                        c.messages.message[d].code = "E_WC_17";
                        break;
                    case "E00096":
                        c.messages.message[d].code = "E_WC_13"
                }
            window[b](c)
        } else
            r.messages.resultCode = "Error",
            h("E_WC_14", w.messageInfo.E_WC_14),
            window[b](r)
    } catch (e) {
        r.messages.resultCode = "Error",
            h("E_WC_14", w.messageInfo.E_WC_14),
            window[b](r)
    }
}


// Example of the problem


for (var d in c.messages.message) {
    console.log(d)
}

//2017 - 02 - 09 10: 36: 45.285 VM3811: 2 0
//2017 - 02 - 09 10: 36: 45.286 VM3811: 2 _super
//2017 - 02 - 09 10: 36: 45.286 VM3811: 2 nextObject
//2017 - 02 - 09 10: 36: 45.286 VM3811: 2 firstObject
//2017 - 02 - 09 10: 36: 45.287 VM3811: 2 lastObject
//2017 - 02 - 09 10: 36: 45.287 VM3811: 2 contains
//2017 - 02 - 09 10: 36: 45.288 VM3811: 2 getEach
//2017 - 02 - 09 10: 36: 45.288 VM3811: 2 setEach
//...


// To fix; the for loop needs to do the right thing


for (var i = c.messages.message.length - 1; i >= 0; i--)
    switch (c.messages.message[i].code) {
        case "I00001":
            c.messages.message[d].code = "I_WC_01";
            break;
        case "E00001":
            c.messages.message[d].code = "E_WC_15";
            break;
        case "E00003":
            c.messages.message[d].code = "E_WC_16";
            break;
        case "E00007":
            c.messages.message[d].code = "E_WC_17";
            break;
        case "E00096":
            c.messages.message[d].code = "E_WC_13"
    }

I've emailed dev support and they just pointed me at this forum thread which is of no help at all. Like others I've found sometimes the script works, sometimes it doesn't. I don't know if their CDN is serving good code sometimes, and then a broken version at other times, but I can't see how the code can work as it is.

[Aaron]

Just a heads up for 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!

[mbruxvoort]

Aaron,

I am not sure what is going on, but multiple cart implementations that we have using accept.js starting throwing an error in the past day. We are gettting an error described in this thread "Accept.js encryption failed.". 

Is there anything we can do to get this error resolved? We are currently unable to accept payments through this method. Do we need to revert back to the older apis?

I have multiple tickets into Authorize.net and I am looking for ANY help I can get.

Thanks,
Mike

[Aaron]

Hi @mbruxvoort,

Can you give me any more information? Any way you can post or send the actual code that's using the script?

Also, can you give me any ticket numbers so I can coordinate with whomever is working on those?

[mbruxvoort]

@Aaron

Thank you so much for responding.

We have had this code implemented for the past 6 months. The error is occuring in the client side. I have included a few snippets of the code from our implementation. This has been working fine up until the last 2 days or so.

Our code does work on our local dev machines when we have the sandbox flag set.

The error is coming from production where it is NOT in sandbox mode.

View Code below

    if (element.UseSandboxMode == true)
    {
        <script type="text/javascript" src="https://jstest.authorize.net/v1/Accept.js" charset="utf-8"></script>
    }
    else
    {
        <script type="text/javascript" src="https://js.authorize.net/v1/Accept.js" charset="utf-8"></script>
    }

Snippet from the button submit

var secureData = {}, authData = {}, cardData = {};

cardData.cardNumber = cardNumberField.val();
cardData.month = monthField.val();
cardData.year = yearField.val();
cardData.cardCode = cardCodeField.val();

secureData.cardData = cardData;

authData.clientKey = paymentInfoElement.data('client-key');
authData.apiLoginID = paymentInfoElement.data('api-login-id');
secureData.authData = authData;

Accept.dispatchData(secureData, '_authorizeNetResponseHandler');

Snippet from the handler

if (response.messages.resultCode === 'Error') {
       for (var i = 0; i < response.messages.message.length; i++) {
            var summaryErrors = $('.validation-summary-errors');

            if (summaryErrors.length <= 0) {
                summaryErrors = $('.validation-summary-valid');
                summaryErrors.addClass('validation-summary-errors').removeClass('validation-summary-valid');
            }

            summaryErrors.find('ul').append('<li class="authorizenet-error">' + response.messages.message[i].text + '</li>');
        }
    }

[douwinga]

After fixing this on our production site, it seems that "E_WC_14:Accept.js encryption failed" is a very misleading error message as it is what is the message that gets displayed for any javascript exception (shown in the try catch clause in the code above pasted by stephencarr).

The issue we actually had was an unhandled exception in our responseHandler implementation. It appears the Accept.js code "gobbles" up any exceptions thrown in there and tries to handle them. Thus giving the very misleading error message.

It seems this "gobbling" up of exceptions is possibly new, but I am not sure. The reason I say this, is that our implementation has been working in the past, and without changing anything, we started having issues recently.

The way we discovered the real issue was by stepping through our implementation code in the Chrome Dev Tools debugger. We put a break point down the success path and the failure path. The success path is where it would start until we reached an area in code where an unhandled exception was occuring which then triggered the failure path breakpoint. The fix was for us, was to just handle the issue before it could throw an exception.

That solved this issue for us, now we need to figure out why Accept.js is all of a sudden allowing invalid credit cards (4111111111111111) in non-sandbox accounts :(.

[andynu]

Thank you @douwinga! Over aggressive catch inside the library masking errors inside the responseHandler is exactly what I was experiencing too.

@Aaron Could the library be made a little more specific in its error catching?

[Aaron]

More specific? Yes. More accurate? Yes. More better all-around? Yes.

Error handling improvements are one of the big efforts in the next release.

[dustin1]

1) Thanks for allowing importing the script at any time.

2) Thanks! Thanks! For allowing passing in the response handler. So so much nicer and cleaner.

3) Ugh, I got the dreaded E_WC_14. Burned over an hour on it. Thinking it was my localhost environment SSL stuff had become corrupted.

It will be really nice if/when the trycatch returns a better message.

To reiterate. I spent over an hour mucking with SSL on my localhost because of the encryption failed error message. When it was actually just a missing id value on a form field in the use opaque callback function. Glad it's figured out but really think other devs will appreciate a better error message.