4

We are finally in the middle of launching authorize.net DPM as a payment method in magento and are having some strange issues.

Basically in some rare, unpredictable (to me) circumstances the customers browser fails to communicate with authorize.net and the order gets stuck in the ‘payment pending’ status. No record of the attempt shows up in the authorize.net control panel and (according to chrome://net-internals and fiddler) the browser doesn't even attempt to communicate with authnet. There are no errors in the javascript console, or any of the Magento logs.

The customer is just dumped back on the checkout page after hitting the order button.

It doesn't happen with every order. And we can see that when it does happen, the customers usually try to hit the submit button several minutes later and the order goes through fine.

As far as we can tell, this only happens in chrome 34.

Have you seen anything like this happen before? Any tips on where to start looking?

Improve this question

3 Answers 3

Reset to default
3

I have found other reports of this issue; you are not alone. We have also seen this issue on our site using DirectPost as well.

There appears to be no particular rhyme or reason for the issue. The browser simply never posts to Authorize.net, even though the form submission is called without error (in directPost.js, this.tmpForm.submit();). While it is true that most of the user agents belonged to Chrome 34, we saw a few other user agents as well including two versions of Firefox (26 and 28, IIRC).

The issue is almost impossibly non-reproducable and affects Magento versions 1.11 to 1.13 that I know of. It likely affects all Magento versions since the DirectPost implementation method (form submission with an iframe target) has not changed in quite some time if at all. For us, this issue affects 1-10% of DirectPost sales on any given day.

Additionally, the same customer may hit the order button again and it may or may not work. Some customers will try repeatedly and it will usually successfully submit the order the second time; other customers will attempt many times without success.

Magento support does not seem to be aware of this issue, having no patches or suggestions for resolution.

We have decided to move to another payment method (regular Authorize.net) instead of DirectPost which has resolved (avoided) the issue.

Improve this answer
3
  • Same experience here.
    – Ben Truby
    Commented May 27, 2014 at 17:08
  • do either of you happen to use the aitoc one page checkout module? I'm trying to find a common thread. @user7717 , could you point me towards some of the other reports of this issue (if they are publicly available)
    – Ben
    Commented Jun 9, 2014 at 17:20
  • @amishbot, I know this is 6 months late, but we have this same issue with DPM+Magento and we do not user aitoc one page checkout. Just the standard magento checkout. I would be interested in knowing if you found a resolution in the past months or if you just switched to regular auth.net aim integration
    – shaune
    Commented Jan 6, 2015 at 19:33
2

My team spent a few engineering weeks working on this problem and we haven't been able to fix it all-the-way, but we have made some progress and found out some information that I thought would be helpful to share.

Firstly, let me describe some of the things that happen when a user clicks Magento's Place Order button when Direct Post has been selected. (Feel free to skip this section and come back to it later)

  1. Browser does ajax request to Magento - the "place" request.
  2. Magento creates a new order and puts order into "Pending Payment" status. The response includes the newly created order number and some other details such as the appropriate authorize.net url where the payment information will be posted to.
  3. The browser submits a form to the authorize.net url. Request includes CC details and Magento order number.
  4. Authorize.net servers then send http request to Magento, order number and some other details are included like if payment was successful. Magento changes order status to Confirmed Payment.
  5. Magento's response back to Authorize.net servers is a very basic html page which essentially has a window.location=url-to-success-page-here
  6. Authorize.net servers then relay the HTML in Magento's response back to the browser. This response is loaded in a hidden iframe.
  7. (More boring details)
  8. Browser is redirected to success page

Okay even though I included a lot of nitty gritty details, I left a lot out too like error handling, I think that gives the main idea.

What we found is that the problem lies between step 3 and 6. The form that is submitted in step 3 gets loaded into the hidden iframe in step 6. When we added in a bunch of JS logging on our production environment and we found that when the orders failed that iframe was loading VERY quickly - too quickly.

While we haven't found the root cause for this in all cases, we have identified that users that have Kaspersky antivirus will get this problem every time. We were able to replicate on our developer machines as well! Kaspersky AV intercepts the https request because it has "authorize.net" listed in some type of "financial" category. Instead of letting the browser reach out to authorize.net, Kaspersky AV intercepts the request and returns http code "499" as well as some HTML that would be displayed like this:

Kaspersky AV Intercept

Well except that remember, the iframe is hidden. So the user can't see it (we did some coding changes to show the iframe and so that is how we got this screenshot). And so the user's experience is that they click "Place Order" and it is disabled/greyed out and then nothing happens ever - like it hangs. But hidden away in that iframe is Kaspersky AV asking the user to open this authorize.net url in a "Protected Browser." LAME! Disabling Kaspersky AV fixes the problem.

But we think it is doubtful that Kaspersky is the only culprit. There could be other AV software, or firewalls, etc that could be doing similar things. Heck it could be some type of DNS problem, or it could be that authorize.net is having some type of outage and they are responding with a 500 or other error code. It could be so many things, and since it is browser-based and browsers have cross-origin restrictions in place we may never figure it out fully.

Our solution:

We coded some changes to the JS (and more)

  • We changed the JS to retry the form submit to authorize.net. It tries 4 times. Lots of times it will fail on the first couple tries and succeed on the 3rd or 4th time
  • After the 4th try we make the hidden iframe visible, front and center so the user can see what is in there. And we also have a JS alert() that says some mumbo jumbo. Oh and we do some other stuff to put the items back in their cart so they can try again.

We still get some Pending Payment orders, but now most of those customers just try again and it works. Our solution is FAR from perfect, but it is a little better than it was before.

I am definitely interested in seeing if other people have been able to solve (or at least minimize) this problem.

Improve this answer
2
  • How did you detect if the form fails to submit? The form.submit() method doesn't have any sort of callback functionality. I could use content of the targeted hidden iframe but as you said cross-origin restrictions get in the way. Do you run the multiple attempts for every order (maybe with a delay between each attempt)?
    – Ben
    Commented Apr 15, 2015 at 18:24
  • Interestingly years later in 2019 our webstore was bit by Kaspersky again. Impact was on a different part of the checkout, this time Kaspersky blocked the beginning part of the checkout when user is saving their billing information - the user would get booted to the cart screen again. In this case Kaspersky intercepted the ajax call to /checkout/onepage/saveShippingMethod and returned a 499 status code to the browser. Solution was to contact Kaspersky and ask them to whitelist the url, which they did. Just mentioning because it only happened on browsers that had Kaspersky integration.
    – shaune
    Commented May 13, 2019 at 14:23
1

I encountered the same issue. After many lost sales with no leads as to a solution, we switched to the regular Authorize.net Solution.

My leading theory is a DNS lookup issue between the customer's browser and Auth.Net. As far as I could tell, everything was working 100% until the customer's browser posted to Auth.Net. I'd love to hear if someone finds a true solution, but mine for the time is to not use Direct Post.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.