Showing results for 
Search instead for 
Did you mean: 

Accept.js error E_WC_14:Accept.js encryption failed

Starting a new thread on this, per Aaron's instructions from here...


We have customers reporting this error approximately once daily.  The other 1,500(ish) daily transactions go through no problem.  Due to the infrequency, I haven't been able to duplicate it on my end.  Here's some code from our implementation (PHP).  Let me know if there's anything else I can provide that might be helpful.  Thanks!



* On the billing info page...


<script language="javascript">

function sendPaymentDataToAnet() {
    if (validate_checkout_form(document.getElementById('checkout_form'))) {
        var secureData = {}, authData = {}, cardData = {};
        cardData.cardNumber = document.getElementById('cc_num').value;
        cardData.month = document.getElementById('cc_month').value;
        cardData.year = document.getElementById('cc_year').value;
        secureData.cardData = cardData;
        authData.clientKey = '<?php echo MERCHANT_CLIENT_KEY; ?>';
        authData.apiLoginID = '<?php echo MERCHANT_LOGIN_ID; ?>';
        secureData.authData = authData;
        Accept.dispatchData(secureData, 'responseHandler');

function responseHandler(response) {
    if (response.messages.resultCode === 'Error') {
        for (var i = 0; i < response.messages.message.length; i++) {
            alert("Error... "+response.messages.message[i].code + ':' + response.messages.message[i].text);
            console.log(response.messages.message[i].code + ':' + response.messages.message[i].text);
    } else {

function useOpaqueData(responseData) {
    // This is where you would set the data descriptor & data value to be posted back to your server


<script type="text/javascript" src="" charset="utf-8"></script>


* In the processing script...


require '/home/acct/vendor/autoload.php';
use net\authorize\api\contract\v1 as AnetAPI;
use net\authorize\api\controller as AnetController;

function chargeCreditCard($amount) {
    // variables defined in calling script
    global $auth_bill_fname, $auth_bill_lname, $auth_bill_address, $auth_bill_city, $auth_bill_state, $auth_bill_zip, $auth_bill_country;
    global $auth_bill_rdd, $auth_bill_rdv;
    // Common setup for API credentials
    $merchantAuthentication = new AnetAPI\MerchantAuthenticationType();
    $refId = 'ref' . time();
    // Create the payment data for a payment nonce
    $opaqueData = new AnetAPI\OpaqueDataType();
    $paymentOne = new AnetAPI\PaymentType();
    $order = new AnetAPI\OrderType();
    $order->setDescription("New Order");
    // Set the customer's Bill To address
    $customerAddress = new AnetAPI\CustomerAddressType();
    //create a transaction
    $transactionRequestType = new AnetAPI\TransactionRequestType();
    $request = new AnetAPI\CreateTransactionRequest();
    $controller = new AnetController\CreateTransactionController($request);
    $response = $controller->executeWithApiResponse(\net\authorize\api\constants\ANetEnvironment::PRODUCTION); // SANDBOX or PRODUCTION
    return $response;


$authorized = false;
$pending = false;

$auth_charge_response = chargeCreditCard( $cartTotal );
if ($auth_charge_response != null) {
    if($auth_charge_response->getMessages()->getResultCode() == "Ok") {
        $tresponse = $auth_charge_response->getTransactionResponse();
        if ($tresponse != null && $tresponse->getMessages() != null) {
            $tresponse_code = $tresponse->getResponseCode();
            if ($tresponse_code == 1) {
                $authorized = true;
            } elseif ($tresponse_code == 4) {
                $pending = true;
        } else {
            if($tresponse->getErrors() != null) {
                $auth_declined_reason_text = $tresponse->getErrors()[0]->getErrorText();
            } else {
                $auth_declined_reason_text = "unknown";
    } else {
        $tresponse = $auth_charge_response->getTransactionResponse();
        if($tresponse != null && $tresponse->getErrors() != null) {
            $auth_declined_reason_text = $tresponse->getErrors()[0]->getErrorText();
        } else {
            $auth_declined_reason_text = $auth_charge_response->getMessages()->getMessage()[0]->getText();

if( $authorized || $pending ){
    // order processing code goes here
} else {
    echo $auth_declined_reason_text;



Hi @danjo,


This one's not fun for you or for us, because you don't have something that's easily reproducible, it happens infrequently, and there's no obvious problem I can see in your code.


E_WC_14 is the general "something bad happened" error. Since it's not telling you specifically what bad thing happened, the only way to know what's going on is to see everything that happened leading up to the error. That may be impossible to do in your situation.


One thing I can do is tell you a few possible bad things that could happen in the process, and you can determine if you want to investigate any of them. In the future, Accept.js will be updated for better error handling, and you'll be given more specific errors about which part of the problem failed.


Things that could cause the Accept.js script to report the error code E_WC_14:


1. When the script makes a call to the Authorize.Net servers for a token but some part of the response is undefined. Some ways this could happen would be because the response was generated improperly at the Authorize.Net server, the response was garbled in transit, the response was never received by the browser, or the request was never received by Authorize.Net servers and the script times out waiting for response.

2. An error processing the request at the Authorize.Net server that throws an exception not already explicitly handled.

3. An error in the AJAX request to send the data to the Authorize.Net server that throws an exception not already explicitly handled.

4. When the dispatch() call happens before the library is loaded correctly. This used to be a greater problem when we required the script to load upon page load. Now, the script can be loaded any time, but there could possibly still be instances either due to bad coding in the site or browser problems where the script's dispatch() call gets called before the script is loaded and initialized.


5. Some other untrapped error in the merchant's script that sort of passes through into the data that's handed to Accept.js and makes the script fail. Make sure you're doing whatever field validation you feel is necessary to know that you're always sending the data in the formats the script accepts.




All Star

It's good to hear that there's a plan for Accept.js to be updated for better error handling.  Any chance we can get a rough ballpark estimate of when that might be?

Any updates?  Our client is (understandably) growing more impatient.



I am having this same issue. Happens only to a couple of people.  Only started happening when I upgraded our system to Accept.js.


What I'm finding to be the common thread among those people who are having problems is that they are running Internet Explorer on a really old machine.


In two documented cases they were running Windows 7.


Could it be something related to Accept.js not being compatible with really old systems?

There's not any specific documented limitation regarding Accept.js and an old browser, but there's a chance there's some incompatibilty there thatwe haven't uncovered in our testing. If you had a specific old configuration in mind, we could look at it.


Hopefully, though, we can rev it on our side first.

I have an old machine in my basement that is running Windows XP and Internet Explorer 8.  (Sorry I don't have exact specs handy).  


When I tried to run my software to process a transaction it failed and gave me the E_WC_14 error message.  Then on the same machine I loaded the latest version of Firefox and it processed it fine.


So in that case it appeared to be Windows XP and IE 8 that caused AcceptJS to fail.


If you have a site you want me to test on that machine to run thru a test transaction, let me know and I'll let you know if it goes thru.

I may be able to shed some light on this. I have just begun working on an implementation of Accept.js, and I immediately ran into this E_WC_14 error. The error message was being issued in my responseHandler function, which I had simply copied from the sample in the documentation. Moreover, I noticed that responseHandler was being called correctly once, and then the error was reported on a second call to responseHandler. But there was no place in my code where I made a second call to responseHandler. I concluded that somewhere within Accept.js there must be a call to some other responseHandler and there was a name conflict between that responseHandler and my responseHandler. Therefore I simply renamed my function to something else. Problem solved. I have not had another E_WC_14.


Hi @Fiala1904,


Sorry, but we've never seen anything like that in our testing. Whether the responseHandler is coded as an inline function or declared as a global function, we always call it "responseHandler" in our code with no problems at all. I've checked through the original source and there's no "responseHandler" in there, nor in the minified versions that are served from our site.


I'm really glad you got your problem fixed, though!

I seem to be experiencing the same pattern that @pkonstan and others reported, where identical code is working on Chrome, Firefox, and Safari, but failing on Internet Explorer 11. I've confirmed that the values sent to Accept.dispatchData() are identical in both instances, but in Chrome/Firefox/Safari I get a successful response, while in Explorer I get the E_WC_14 error.


This is dismaying and frustrating - we're hoping to launch a new credit card processing system this week, but the client's office is still running Windows 7 and IE11, so this error is going to be very prominent and problematic.


Do you have any insight into why this might be happening in IE, or any suggestions for workarounds?