When trying to pay for something with Amazon Pay, anti-tracking is blocking payments. The WebConsole shows:
"Request to access cookie or storage on ?https://payments.amazon.com/checkout/widgets/v2/wallet#/error? was blocked because it came from a tracker and content blocking is enabled"

Seen on two sites when trying to use Amazon Pay with Beta 67.0b8. I have not tried other versions.

https://sites.fastspring.com/mackiev/order/confirm (online payment supplier for mackiev.com)
https://lovepop.com

This is caused by our tracking cookie blocking. I added something to my cart on lovepop and started the checkout with amazon pay. Eventually I end up on the screen in Comment 1. The console contains the error messages:

Request to access cookie or storage on “https://payments.amazon.com/gp/apa/csm/jsonp?sellerId=undefined&data=%7B%27counters%27%3A%5B%5D%2C%27timings%27%3A%5B%7B%27name%27%3A%27addresswidget-pre-render%27%2C%27time%27%3A803%2C%27tags%27%3A%5B%5D%7D%5D%2C%27info%27%3A%5B%5D%2C%27entries%27%3A%5B%5D%7D” was blocked because it came from a tracker and content blocking is enabled.

and

Request to access cookie or storage on “https://payments.amazon.com/checkout/widgets/v2/addressBook” was blocked because it came from a tracker and content blocking is enabled. 3b6363c6f09691018a6a9d60477d56c4:1:149

If I click "Continue" in the iframe, I see the following error message: "User declined!". I also see more cookie warning messages. Digging into the code, the "Continue" button calls ajaxReloadWidget on click. I've pasted in the code snippet below [0], but this function attempts to call the Storage Access API and is presumably declined. I have my profile set to always prompt, so this is an automatic denial.

The iframe that contains the "Continue" button is loaded from https://payments.amazon.com/checkout/widgets/v2/addressBook#. The auto-denial is due to the fact that I have never interacted with the payments.amazon.com origin before (despite having used my amazon account) [1]. Unfortunately, navigating to payments.amazon.com redirects immediately to https://pay.amazon.com/us, so it's not clear to me that any user would ever interact the payments.amazon.com origin.

The solution here would either be for amazon to serve this embedded iframe from amazon.com or for us to allow storage access prompts (but perhaps not auto grants) when a user has interacted with the eTLD+1 of the requesting origin at some point in the past.

[0] In https://d35u8xwkxs8vpe.cloudfront.net/amazon-pay-checkout-widgets-assets/spa_widget_js.98a53e3cc5f59c1ce8ad.js we see the following code

}, e.ajaxReloadWidget = function() {
    $.post(m, {
        counter: "itp_continue_clicked"
      }), document.requestStorageAccess().then(function() {
          t.$apply(function() {
              t.showLoading = !0
          }), $.post(m, {
              counter: "itp_prompt_accept"
          }), $.post(window.location.pathname, window.originalRequestData, function(e) {
              var n = /<body.*>([\s\S]+)<\/body>/.exec(e);
              "undefined" != typeof errorDetails && (errorDetails = void 0), "undefined" != typeof commonWidgetParams && (commonWidgetParams = void 0), delete window.PYOP,
                  function() {
                      for (var e = t.$$childHead; e;) {
                          var n = e.$$nextSibling;
                          e.$destroy(), e = n
                      }
                      for (var i in t) t[i] && 0 != i.indexOf("$$") && "object" == typeof t[i] && (t[i] = null)
                  }(), $("body").html(n[1]), t.showLoading = !1
          })
      }, function() {
          $.post(m, {
              counter: "itp_prompt_decline"
          }), console.log("User declined!")
      })
  }

[1] https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#Concepts_and_usage

Thanks for digging in. Fixing this should be a high priority since having all Amazon Pay uses break is a big problem and will lead to people switching browsers. Unless we can get Amazon to make an immediate fix, we'll need to do something, even if it's only a bandaid or temporary special-case. (IMO) It also concerns me what other sites might break like this without us knowing; most users would never find what I did and report it; they'd just switch browsers (or complain to the site, which likely would have no idea and not link to firefox, at least for a while - and then they might put a "please use Chrome" tag on).

Mike: do we have contacts at Amazon Pay?

One thing to note: amazon.com is only on the "Strict" version of the cookie blocking list, which is only enabled in pre-release channels. Release users should not experience this breakage.

(we have an Amazon partner list, but I'm poking around to see if we have more direct Amazon Pay contacts before going that route. will leave ni?)

When running this page with the MOZ_LOG=AntiTracking:5 environment variable set, we have the following lines in the log:

[Child 9728: Main Thread]: D/AntiTracking Adding a first-party storage exception for https://payments.amazon.com...
[Child 9728: Main Thread]: D/AntiTracking The current resource is third-party
[Child 9728: Main Thread]: D/AntiTracking Tracking principal (https://payments.amazon.com/checkout/widgets/v2/addressBook) hasn't been interacted with before, refusing to add a first-party storage permission to access it

This is because the origin of the iframe calling the storage access API (https://payments.amazon.com) has not been interacted with as a first-party yet. This is a requirement for the API which we document in https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API but we should also perhaps document it in https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API/Using as well.

The fix for the website would be to call the storage access API from an origin which the user would have interacted with in the first-party context. Since the Amazon Pay interaction already requires a flow where the user interacts with Amazon as a first-party hopefully this will be possible for Amazon to implement.

Carter, do you have contacts at Amazon Pay?

Carter told me he doesn't have direct contacts. I'm following up.

(In reply to Steven Englehardt [:englehardt] from comment #2)

or for us to allow storage access prompts (but perhaps not auto grants) when a user has interacted with the eTLD+1 of the requesting origin at some point in the past.

FWIW this isn't super easy for us to do, because the user has probably interacted with www.amazon.com, and the way we store this data it's not easy to ask "has the user interacted with the eTLD+1 of the requesting origin in the past"?

But more importantly, for users outside of the US using Amazon's ccTLDs this wouldn't solve anything at all since those users would have been interacting with domains such as www.amazon.ca and so on...

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

See bug 1547409. Migrating whiteboard priority tags to program flags.

This works for me now on https://lovepop.com, closing the bug. Please reopen if you can reproduce on another site.