IE 11 first-party session cookies being lost in iframe

We have a site (www.example.com) which sends users off to a series of third party pages to verify payment details, which we do in an iframe. Initially, a local page from www.example.com is loaded in the iframe, and the user is redirected to the third party URL. Once the third party steps are completed by the user, they are 302 redirected back to a page on our site (www.example.com) within the iframe.

This works in all browsers we've tested except IE 11, where our cookies appear to be lost. We have checked this under both Windows 7 and 8.1, in both desktop and "Metro" modes, and the problem is across all versions.

When a user browses our site we set a session cookie, which is correctly sent to the first-party page that is initially loaded in the iframe. Once the user has gone through some third-party pages in this iframe however, the session cookie isn't sent with the next request.

If we set IE 11's privacy setting to the lowest value, this issue disappears and things work as expected.

All potential solutions I've turned up so far have related to P3P headers. We have a valid and correct P3P header and XML policy file set up, and this problem only occurs in IE 11.

Update: We have a few other cookies set using JS. These are all persisting as expected. The differences are the expiry date (1 year for JS cookies, 1 month for session cookie), the domain (explicitly "example.com" for JS cookies, empty for session cookie) and whether they are "HTTP only" (false for JS cookies, true for session cookie).

I have tried setting all of these options as per the JS cookies for the session cookie, but it made no difference.

Update 2: After more testing I have been unable to create a test case that recreates this problem. Any additional cookies I try testing with in the live code however also appear to be broken, even if they are set with exactly the same code as the JS cookies which work. In short; I've not yet found any pattern to the cookies which work and those which don't.

One potentially interesting thing to note is that the cookies aren't being deleted, they're just not being sent to the final request. If another page is loaded, the cookies magically reappear and are sent; which leads me to believe this is a bug surrounding iframes and P3P.

Update 3 (day 3): IE 11's handling of cookies continues to confound me. The further I travel into Microsoft's labyrinth the more lost I become amongst its shifting walls. And there are ghosts in here. Fragments of half-dreamt security policies that have woven themselves into some ethereal creature, which tracks and taunts me at every move. At first I was frozen, terrified, aghast at the barely fathomable form darting just out of sight, but with every passing hour I gather more comfort from the mere knowledge of its proximity. Could this be the very beast I have been sent here to confront? How could I slay my only companion in such times?

We encountered a similar problem with Internet Explorer 11 where the session cookie went missing after a redirect over https.

The request chain looked something like this:

initial request to / -> session cookie set -> redirect to an external URL -> redirect back (session cookie lost)

Our problem was due to an invalid host name according to RFC952, we had underscores in our test server URL. It seems that Internet Explorer silently drops the session cookie on redirect over https if the URL does not conform to RFC952. When using dashes instead of underscores, everything worked as expected.

The original solution was found in the Update 2 section of this asp.net blogpost from 2004. Related microsoft bug ticket here.

Hopefully this will help someone.

I have noticed session cookies are often lost when IE7 compatibility mode is engaged for a new page. I suppose the same could apply to the iframe. Is the iframe sending a X-UA-Compatible header value that is different than the parent page, or different than earlier in the session? Like maybe your session started with IE=edge, and the iframe page sets it to IE=7. If so, IE seems to spin up a new IE PID for the compatibility mode pages and session cookies often (but it seems don't get transferred.