+lgarron@, expert on URL display.
(FWIW, the repro here is a blob: URL; top-level navigation to data: URLs will be blocked in Chrome 60 ( Issue 684011 ). Do we allow the API in subframes?)
Having said that, is there a reason that we're showing a full URL here instead of the security origin?

Drive-by: IMO we should disable this API on anything other than https URLs. There is all sorts of weirdness with pseudo URLs that make their display a nightmare (e.g. blob URLs can have null origins if they are opened by data URL iframes).

We allow API in subframes that have "allowpaymentrequest" attribute.
We're showing the output of FormatURLForSecurityDisplay(webContents.getLastCommittedURL()). Let me check the code to see what's happening exactly.

> Any reason we can't use IsOriginSecure()?
We use IsOriginSecure() since http://crrev.com/6e3cf7c.
> Are we sure this bug is present only on Android?
Desktop UI does not show the origin. I'll work with iOS folks on getting this fixed as well. +mahmadi
> That would add only WSS. That seems unlikely to happen in the real world, but also harmless?
Also HTTPS-SO. I'm not sure what WSS and HTTPS-SO are, but they are all considered "cryptographic" in Chrome.

> Also HTTPS-SO. I'm not sure what WSS and HTTPS-SO are
Those are schemes to designate suborigins (https://w3c.github.io/webappsec-suborigins/). That whole suborigin-encoded-in-the-scheme thing might be going away soon anyway, but for now that seems fine; I don't see any reason to restrict payment requests on suborigins.

Re #24: URL Spoofing in contexts outside of the address box does not have a defined severity (https://www.chromium.org/developers/severity-guidelines).
Given that the UI here isn't a surface with which most users will be familiar, and because the spoofable string is immediately adjacent to a string which is deliberately attacker controlled, Low severity seems appropriate to me.