Do these users have third party cookie blocking enabled?  Behavior there recently changed to match "samesite: strict" behavior, I believe.

Thanks very much for the quick response. I was able to reproduce this issue with third party cookie blocking enabled.

Is this getting triggered because a third-party is POSTing back to us or is there something else in the request response sequence that's causing this? More details about third-party cookie setting and this particular change will help.

Is there something that we can change in our application without wanting the users to change their setting, as they must have consciously checked this option for security reasons.

Please note that none of our cookies are marked samesite:strict.

Sounds similar to bug #663367, which also dealt with framed navigations from a third-party origin.

I'm not sure why that bug is locked down, but I'll copy/paste the explanation here for visibility:

```
I see. `a.com` frames `b.com` in order to collect credit card data. That frame posts to `a.com` (also in the frame) with a reference number that (I assume) can be used to verify transaction data.

Chrome doesn't currently consider this a "first-party" navigation, as `b.com` is responsible for it. Since that origin isn't "first-party", the "first-party for cookies" for the navigation request is `null`, so even though the eventual redirect endpoint is `a.com`, we don't treat it as a "first-party" navigation.

I can see arguments on both sides of the behavior: a cookie with a `SameSite` attribute wouldn't be sent for this request, and consistency with that behavior seems reasonable from a developer perspective. On the other hand, the "first-party" toggle in Chrome isn't really meant as CSRF protection, but as a privacy protection. Consistency with other browsers is also a reasonable argument (though I'm a bit surprised that this works in Firefox; I thought their implementation was similar to ours).

Theory aside, if we decide that this would be a good change to make, the requested behavior will practically be hard to change given the knowledge we have when processing redirects in the network stack. We don't have access to the frame tree there, so verifying that a given request is going to populate a frame and that all the ancestor frames are same-origin is non-trivial. I suppose we'd have to pipe up additional data from Blink.
```

Does that match the scenario you're seeing?

Yes. The scenario is similar. If the form on b.com which is being posted to a.com has target=_top, a.com gets the cookies since a.com initially framed b.com and the browser nav bar url changes with _top. However, b.com is out of our control so we can't influence 'target' attribute there and it may be c.com or d.com based on the card. So basically, we are looking for a solution on a.com. Is there any? Or is there a plan to make this consistent with other browsers?

It also appears that the decision whether to send back a.com's cookies to it also depends on which browsing context the navigation resulting from form post happens. It is not just the domain from which post happens. So, if the form has target=_top the navigation resulting from that form post happens in the main window (visible to user) and Chrome is sending a.com's cookies back.

 Issue 674950  has been merged into this issue.

Hi,

We can see similar this issue on Android version of Chrome 58.0.3029.83 with third party cookies disabled. Customers can go through the journey all the way to payment, but return value does not contain cookie details required for completing payment and the is failing. The same setup on Windows desktop Chrome 58 stops external iframe from loading (better customer expierience). When we tested the same scenarios on Firefox 53.0.2 and IE we were not able to replicate this issue. We are tracking these failures and we can see mostly Chrome cases (with small amount of Firefox and Edge however we cannot reproduce it yet)

Just to add we have tested this on Visa and MasterCard (both 3d secure enabled)

Issue 663367 has been merged into this issue.

Hello,

I can confirm that this bug affects our web site as well (our clients are not able to pay by credit cards in both mobile and desktop Chrome with blocked 3rd party cookies). 

Our web site has an iframe with credit card form (hosted by the payment service). POSTing the credit card form results in 302 redirect to our web site. GET request sent to our site fails because of NO FIRST-PARTY COOKIES in the request.

I can also confirm that the problem is not reproducible in other browsers.

ARE THERE ANY PLANS TO FIX THIS PROBLEM IN NEXT VERSIONS OF CHROME?

We are thinking about implementing a mechanism to notify our clients that they have 3rd party cookies blocked in their Chrome which can result in payment isses. Based on that:
https://stackoverflow.com/questions/3550790/check-if-third-party-cookies-are-enabled

IS THERE ANY BETTER WAY TO IMPLEMENT THE NOTIFICATIONS? 

COULD YOU RECOMMEND ANY WORKAROUNDS TO IMPLEMENT ON OUR SIDE?  

No changes to this behavior are currently planned.  There are a couple solutions, like passing data via posts or in URLs, or navigating the top level document.  There's also an API to communicate between cross-domain iframes, I believe.

Updating labels and removing from bisect bucket since TE cannot repro.

(Unassigning myself, marking untriaged in preparation to retriage with folks who will do a better job taking care of cookies than I've been able to)