cancel
Showing results for 
Search instead for 
Did you mean: 

Accept.js E_WC_17:User authentication failed due to invalid authentication values.

I'm having a little trouble interpreting an error message i'm recieving while trying to implement Accept.js to replace our current Direct Post functionality on a Magento store.

 

E_WC_17:User authentication failed due to invalid authentication values.

 

Looking up this error on https://developer.authorize.net/api/reference/features/acceptjs.html

 

E_WC_17Please provide valid card holder name.

 

I've tried implementing the optional fields according to:

 

Property Type Description

cardNumberStringMust be a valid 13-16 digit card number. Required.
monthString2-digit month. Required.
yearString2-digit year. Required.
cardCodeString3 or 4-digit card validation value (CVV). Optional.
zipString20-character alphanumeric postal code. Optional.
fullNameString64-character alphanumeric cardholder name. Optional.

 

Still no luck, i've verified the Client Key, generated a new one as well. The API Login is correct as well. I'm also using the testing JS "https://jstest.authorize.net/v1/Accept.js"

 

Any idea what this error really means?

 

Thanks!

amazedchili
Member
21 REPLIES 21

Hi @Aaron,

 

Per your suggestion, I opened a ticket and their initial response is the same as the original post in this thread  - i.e, the wrong card holder name.

 

I replied with a link to this thread, so hopefully we can at least agree on the issue.

@Aaron Two weeks ago I submitted a ticket as advised.  (1-425378731)

 

Zero help ensued. After two weeks with no help I reverted back to the old system. I explained that:

 

I've discontinued use of Accept.js pending active engagement by your 'internal technicians'. 

 

But they closed the ticket.

 

I understand why you'd suggest handing off to 'real' support for production issues, but at least folks here are engaged.

 

 

I'm totally open to the likelihood that the failure is on me, but without any feedback from Anet, I don't have a way to debug it with the current error.

 

Hi @leehinde,

 

That's really unfortunate and I'm really sorry about that. I've escalated your feedback through the support department so that hopefully improvements can be made there.

 

Backing up a bit, here's what we know:

  • You coded a solution with Accept.js
  • This solution would work sometimes and fail sometimes, with no change on your side
  • When it did fail, you got the code E_WC_17, but text relating to authentication ("User authentication failed due to invalid authentication values")

In my experience, I can take a perfectly working Accept.js page, change the client key to something invalid, and get the same thing (E_WC_17, but with error text relating to authentication). There are known bugs with Accept.js and error handling, so Accept.js is likely throwing the authentication error, but not updating the error code correctly and reporting the wrong code.

 

This situation is 100% reproducible for me, and then 100% fixable by just providing the correct client key.

 

Now, in your case, you say it works some of the time and fails some of the time. That points to the client key not necessarily being wrong, but maybe not working or not being recognized some of the time. That's an issue that somebody would have to look at on the production side, and I'm sorry they dropped the ball on that.

 

I'm reaching out to try to reopen this ticket and get to the bottom of it so that we can see what's going on. It's important to me to at least understand all of the failure modes until we can roll out the error handling fixes. Would you be willing to do a little more testing and see if you're still experiencing this error? Additionally, would you be willing to send me your page code (with the client key and api login still embedded or included) so that I can try to run the same scripts from my end and just see if there's any difference? Please send to aawright@authorize.net.

I'm posting back to my system every use of credentials with each use of Accept.js. I tested for the possibility I wasn't loading correctly.

 

They come from one source and are the same (correct) for successful and unsuccessful transactions.

 

I'll make sure the ticket gets re-opened.

Is there somewhere we can see your code running in a browser? Can you either send your code to us, or point us to the website where your code is running so that we can see it ourselves? This may be crucial to troubleshoot this.

@Aaron, I'd be happy to do that. But, like I said, I switched back because there hadn't been any engaegment. They (those people over there. :-)) reopened the ticket, but there's been no activity since.

 

I've talkd to my client and once we know someone's looking he's ok with me switching back to the accept.js process and then I'd be happy to get you in.

 

It also occurred to me I'd seen reports here where posts using json (which I'm using) need to be in a certain order.   This is consistent with my experience. I was just thinking of switching to xml to see if that works better.

Hi @leehinde,

 

Since you're getting the error in the Accept.js step, JSON vs XML shouldn't even be an issue at that point. Your API request for the transaction doesn't even happen until the Accept payment nonce/token has been successfully received.

 

Getting us access to hit your system and to create our own failures will be crucial in troubleshooting for a few reasons.

  1. It's intermittent
  2. It's not widespread. We don't have any other merchants (that we know about) experiencing intermittent Accept.js authentication failures.
  3. Since it's an authentication failure, we're not logging it associated with a particular merchant (since authentication failed meaning we never correctly identified who the merchant was associated with that request)

We do log the failures on our end, but it will require us to know exactly when the failures occurred so that we can correlate a failure coming from you with a failure entry in our log. So, the sooner we can get access to bang on your implementation, the better. Let me know (directly by email if you want) whenever it's available, and I'll alert the (multiple) people who've been investigating this.

I've got an email ready. I'm waiting for my customer to create/provide a test account for you to log in with.

 

Thanks for your help.

Hi @Aaron,

 

In AcceptCore.js, both sandbox and production versions, E_WC_17 has the message text: "Please provide valid card holder name."

    var a = {
                E_WC_01: "Please include Accept.js library from cdn.",
                E_WC_02: "A HTTPS connection is required.",
                E_WC_03: "Accept.js is not loaded correctly.",
                E_WC_04: "Please provide mandatory field to library.",
                E_WC_05: "Please provide valid credit card number.",
                E_WC_06: "Please provide valid expiration month.",
                E_WC_07: "Please provide valid expiration year.",
                E_WC_08: "Expiration date must be in the future.",
                E_WC_09: "Fingerprint hash should not be blank.",
                E_WC_10: "Please provide valid apiloginid.",
                E_WC_11: "Please provide valid timestamp in utc.",
                E_WC_12: "Sequence attribute should not be blank.",
                E_WC_13: "Invalid Fingerprint.",
                E_WC_14: "Accept.js encryption failed.",
                E_WC_15: "Please provide valid CVV.",
                E_WC_16: "Please provide valid Zip code.",
                E_WC_17: "Please provide valid card holder name.",
                E_WC_18: "Client key is required."
            };
            return {
                messageInfo: a
            }

Because of the function below, E_WC_17 is returned in the case of API response error code E00007:

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"
                }

The following message is coming directly from the API and getting the wrong E_WC error code inserted from AcceptCore.js: 

User authentication failed due to invalid authentication values. 

By the way, it looks like the only API response case to E_WC error that is mapped correctly is Code: E00096, "Finger Print value is not valid".

Code: I00001
Successful.

Code: E00001
An error occurred during processing. Please try again.

Code: E00003
An error occurred while parsing the XML request.

Code: E00096
Finger Print value is not valid. // Yay, we have a match.

Oh, snap is right, I just read your comments about known error handling issues and rolling out some changes, and here I was thinking I made a discovery. Though, some of these modifications could made in minutes and would go a long way in terms of robustness and being able to diagnose issues in the interim.  

 

In practice, many of these issues may not be experienced, because they get trapped and return the correct message before processTransaction is called with the following:

 function responseHandler(response) {
        if (response.messages.resultCode === "Error") {
            for (var i = 0; i < response.messages.message.length; i++) {
                console.log(response.messages.message[i].code + ": " + response.messages.message[i].text);
document.getElementById("result").innerHTML = response.messages.message[i].text;
           }
           // alert("Error!")
                } else {
            console.log(response.opaqueData.dataDescriptor);
            console.log(response.opaqueData.dataValue);
            processTransaction(response.opaqueData);

        }
    }

However, AcceptCore is only doing limited error checking when it comes to Authentication values.

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

<sigh>

 

The error handling fixes, as simple as they may be, are still not yet released because they're tied up with another release. The good news is that the other release brings oft requested features, and is actually on track to show up soon. I don't want to make any more promises beyond that until we get closer, but I'm optimistic that this can finally get fixed.

 

But, you're right. Once you dig through the code and see the nature of the error, "Oh snap" is right. I'll gladly take any flogging here on behalf of the whole team.