If you look at the $_SESSION data for how drupal commerce tracks orders you see the session data has
[commerce_cart_orders] => Array (  => 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
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
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.
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.