If you look at the $_SESSION data for how drupal commerce tracks orders you see the session data has
Array (
[commerce_cart_orders] => Array ( [0] => ORDERID )

where ORDERID is an integer.

But IE 8 and IE 9 have a security "feature" which prevents IE from sending session info when IE (what I think Microsoft calls) "crosses a boundary." Or in other words, when the response comes BACK from a payment gateway.

So normally in DC you'd get

GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1; SESSname=sessionID

But if you are coming back from a DIFFERENT domain (e.g. say a payment vendor) then you get with IE

GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1\r\n

NOTE the sudden LACK of a session passed from IE. Drupal then creates a NEW session. This BREAKS drupal commerce because the way DC is written is that a user CANNOT see their own orders unless they have a session associated with it. Drupal Commerce will return a "404 Not found" error when there is no session associated with this.

Note that if you are using IE and you hit the "refresh" button it suddenly now works.
If you sniff the tcp data you find that IE will now send the session. E.g.

GET /checkout/NNN/X_payment_verification_page?....
Accept: */*\r\n
[stuff deleted]
Cookie: has js=1; SESSname=ID

Note: Testing with Firefox, Chrome, and Safari show they are not affected. Only IE and only when coming back from a different domain to drupal commerce for payment confirmation. (e.g. exactly what you'd normally do in working with a payment gateway). So far I've been able to get this to repeat 100% of the time with IE 9.0.8112.16421 on Windows 7 64bit.

As DC exists now, requiring sessions to view the final payment confirmation, this prevents IE users from actually completing an order if they are being sent "back" from a foreign domain.

Note: I am not an IE expert, but it seems like there was some discussion along these lines here http://stackoverflow.com/questions/1324181/ie8-losing-session-cookies-in... even though in the discussion they were looking at pop-up windows and here we are staying within the same window and having an IE user return from a payment gateway.

Comments

LiveWire’s picture

LiveWire CreditAttribution: LiveWire commented

I had the same issue. Do you have a form e.g., cart form located elsewhere on the page? It seems as though IE would return an improper HTTP request and timeout. As soon as I altered the checkout process to have payment on a page by itself the checkout worked flawlessly.

noovocreative’s picture

noovocreative CreditAttribution: noovocreative commented

Had exactly the same issue.

Disable Shopping cart contents' from your content pane.

Then test again in IE 8 or 9. This worked for me, turns out I had added a 'remove' button in the view which was causing the issue.

Set the view to be the same as it was by default and activated the 'Shopping cart contents' and it worked fine.

Hope that is of some help.

rszrama’s picture

rszrama CreditAttribution: rszrama commented
Category: bug » support
Status: Active » Closed (fixed)

Sounds to me like we have a solution then. There are other issues / documents detailing this, but for reference you cannot use Views form functionality inside checkout panes. It effectively creates a form tag within a form tag, which neither IE nor Drupal itself can process.

Broader strategies related to IE and SSL sessions shouldn't be considered bugs in Commerce itself, but we can keep an eye out for anything we recommend that makes working in that context more difficult. Honestly, if the session is being completed wiped, then you'd be hosed even if a user was logged in and redirected away. They should be logged out when they come back, but since I hardly ever hear of this, I'm going to assume that what's happening is what's described in the two comments above.