WooCommerce Authorize.Net DPM Error: This transaction cannot be accepted. (Check your server’s UTC Time!)

If you’re using WooCommerce’s Authorize.net DPM (Direct Post Method) plug-in for handing off credit card transactions to Authorize.net’s payment gateway you may run into the following error:

Error: This transaction cannot be accepted.

Error: This transaction cannot be accepted.

The first test is to check that your API Login ID and Transaction key are correct. (Follow the setup instruction here.)

Unfortunately, the documentation on the above-linked page says that if you’re receiving the above error, “Your API login or transaction key is incorrect. Check them.”

Well, I DID, and it still ain’t working, thank you very much!

Update: The plug-in documentation now includes a note about Error Code 97.

This plug-in would be MUCH improved if it actually returned error codes when something goes wrong. Authorize.Net has a nice list of Error codes and what they mean.

Update: The plug-in authors have told me they will include error codes in a future release.

Long story short, after many hours down the rabbit hole, I discovered that my server’s clock was the cause of the problem.

I chanced upon Authorize.Net’s “Response Code 97 Tool” and discovered that the difference in time between my server and Authorize.net’s servers was 26136 seconds off. That’s  7.26 hours off!

Per the Response Code 97 Tool documentation:

Response Code 97 indicates that the transaction fingerprint created to authenticate a Simple Integration Method (SIM) transaction has expired. This error is received when the timestamp value submitted in x_fp_timestamp is either 15 minutes ahead, or 15 minutes behind in Greenwich Mean Time (GMT) (this is the equivalent of 900 seconds ahead or 900 seconds behind in Coordinated Universal Time, or UTC).

The Response Code 97 troubleshooting tool validates whether the value you submitted to Authorize.Net for x_fp_timestamp is a valid timestamp. Valid timestamps must be formatted in UTC, which is the number of seconds since 12 AM, January 1, 1970.

To troubleshoot a Response Code 97, check the following:

  • Verify that the time on the Web server that hosts the SIM script is configured correctly to the GMT time zone. You can also modify the SIM script to format UTC.
  • If you are having consistent problems with your timestamp, make sure that the Web server that hosts your SIM script employs a Network Time Protocol (NTP) to regularly update the time.
  • Be sure to account for daylight savings time.

In order to check the value of x_fp_timestamp being sent from your checkout page to Authorize.Net, view the source code on the last checkout screen (the screen which displays the credit card fields).

WooCommerce Authorize.Net Credit Card Info

View the page source on the Credit Card info step.

Search for the string “x_fp_timestamp” and copy the value.

x_fp_timestamp value

Copy the “x_fp_timestamp” value.

Copy this value (which is in Unix time) and paste it into the Response Code 97 Tool.

Response Code 97 Tool

Response Code 97 Tool

If the difference is more than (+ or -) 900 seconds, then your transaction will be rejected.

Sure enough, as soon as I adjusted my server’s time the problem was solved. No more errors!

I hope this helps someone else. Let me know in the comments!

This entry was posted in Resources, Techno-babble, WordPress. Bookmark the permalink.
  • http://www.formfunctionform.com shawn

    hey man….I’m getting this error also. where did you go to update the server time? I tried using the ‘setenv’ variable in my htaccess file, and while it’s in there, it does not seem to have fixed my issue.

    is the authorize plugin pulling time from somewhere else, more of a ‘core’ location? I don’t know whether to look at my server host/admin panel somewhere, or within wordpress files.

    hopefully if you respond, this will notify me…if not, shawn at formfunctionform and then a dot and then a com–I’d love to figure out how you resolved the issue, so I can get back to…you know…actually making money.

    • Alex Williams

      Hi Shawn, I was able to update the serve time using the “date” command at the Linux command line (using terminal for shell access). Here’s a good tutorial on using the date command:

      The authorize.net plug-in is pulling the date variable from the system. The date is stored in UTC time, so if your servers time is wrong, and you don’t have access to the shell, you should contact your server admin or hosting company to get this fixed.

      • http://www.formfunctionform.com shawn

        alex; thanks man.

        yeah, there was a little confusion here (for me, a very-much novice).

        there’s your TIME ZONE setting, which, when looking online for issues, is what I came up against. that can be set a variety of ways, including a setenv variable in the .htaccess file. I’d THOUGHT that this was the issue, but it isn’t.

        for me, it took finally realizing that the time was not off by whole-number hour increments, but minutes. for me, it was 20 minutes off. when i went to wordpress control panel/settings/general, I noticed that the time shown was about 20 minutes off…I then divided the second-differential returned at your authorize.net link, and got the same minute-differential (19 and change) as the disparity between actual time and wordpress-settings-displayed time. that let me know that it wasn’t a time zone issue, but an actual clock that was wrong somewhere.

        as you said, since I don’t have access to my actual server b/c I’m hosted w/ dreamhost (at least, I don’t think I do; if I do, I don’t know how to use it, and it’s probably not good for me to touch it anyway), I just sent a support request to dreamhost; they updated it and got back to me within 30 minutes.


        of course, I spent WAY TOO DAMN MUCH TIME fixing this myself. I gotta learn to just send problems to tech support immediately…but I always figure “oh, it will take 10 minutes!”…and before I know it, I’m reading wikipedia articles about feathered dinosaurs.

        regardless….your blog post was invaluable in figuring out my issue. Thanks a lot.

        • Alex Williams

          Awesome! Glad to help. I spent hours on this myself (hence the blog post). Anyway, I did reach out to the authors of the Authorize.Net plug-in and they said they will include error codes in their next release. Meanwhile, they have revised the documentation after I wrote this article to include a troubleshooting note about the Error Code 97 issue. Hooray!

  • shannon

    That’s solved my problem! Thanks!