Intent to Ship: Secure Payment Confirmation: UX Refresh

[Chromestatus]

Contact emails

darwi...@chromium.org, slob...@chromium.org, smcg...@chromium.org

Explainer

https://github.com/w3c/secure-payment-confirmation/issues/197
https://github.com/w3c/secure-payment-confirmation/issues/275

Specification

https://w3c.github.io/secure-payment-confirmation

Design docs

https://github.com/w3c/secure-payment-confirmation/issues/197
https://github.com/w3c/secure-payment-confirmation/issues/275
https://github.com/w3c/secure-payment-confirmation/pull/292
https://github.com/w3c/secure-payment-confirmation/pull/294
https://github.com/w3c/secure-payment-confirmation/pull/298

Summary

Updates the UX elements for the SPC dialog on Android Chrome. Other than just UX presentation the following are being added: - Allowing merchants to provide an optional list of payment entity logos related to the payment that will be displayed in the UX (https://github.com/w3c/secure-payment-confirmation/pull/294). - Returning different output states back to the merchant depending on whether the user wants to continue the transaction without SPC or to cancel the transaction (https://github.com/w3c/secure-payment-confirmation/pull/292). Currently, we only send a single output state back for both cases. - A new payment detail label field will be added to the payment instrument so the text be presented across 2 lines in SPC (https://github.com/w3c/secure-payment-confirmation/pull/298)

Blink component

Blink>Payments

TAG review

N/A (minor additive features)

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Low risk. The SPC UX Refresh changes are only purely additive API shapes that are all backwards compatible. The risk is that other browser do not implement it.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/570) Firefox has never finalized their view on SPC, so we updated the original SPC issue with a note on this additional capability.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/30) Safari has never finalized their view on SPC, so we updated the original SPC issue with a note on this additional capability.

Web developers: Positive Responding to requests/feedback from web developers in the WPWG.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

Web developers should be able to try the new SPC UX Refresh through a Chrome flag, thus no changes are needed in devtools.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

SPC UX Refresh is added to Secure Payment Confirmation which is supported only on Android, Windows, and Mac.

Is this feature fully tested by web-platform-tests?

No

DevTrial instructions

https://docs.google.com/document/d/1w3RfvmoQqCvJkio4rxl0QR4BL1AzgHdv9a0qJhfCzpg

Flag name on about://flags

enable-secure-payment-confirmation-ux-refresh

Finch feature name

SecurePaymentConfirmationUxRefresh

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://g-issues.chromium.org/issues/405173922

Launch bug

https://launch.corp.google.com/launch/4397413

Measurement

SPC UX Refresh is only additive to Secure Payment Confirmation: The Secure Payment Confirmation UseCounter will be used.

Availability expectation

Secure Payment Confirmation is only in Chromium browsers for the foreseeable future.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

None

Sample links

https://rsolomakhin.github.io/pr/spc-payment-entities-logos
https://rsolomakhin.github.io/pr/spc-opt-out

Estimated milestones

Shipping on Android	139
DevTrial on Android	139

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5206050462236672?gate=5106969593249792

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/683f5e54.170a0220.31427f.1558.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Stephen Mcgruer]

Quick clarification here:

> Is this feature fully tested by web-platform-tests?

> No

We are working on adding tests, but since the SPC WPTs rely on WebAuthn virtual authenticators, and those are not available on Chrome Android, we are having to test them manually as we develop. When these features are implemented for Desktop then things should start working better!

• https://github.com/web-platform-tests/wpt/pull/53358 (paymentEntityLogos)
• https://github.com/web-platform-tests/wpt/pull/53333 (instrument.details)
• https://github.com/web-platform-tests/wpt/pull/53386 (new output states)

[Stephen Mcgruer]

(Also, -chrome-payments-eng@ as that is an internal group that will not accept email from @chromium.org or other external accounts :))

[Philip Jägenstedt]

Hey Stephen,

Is WebAuthn virtual authenticators the DevTools feature mentioned in https://developer.chrome.com/docs/devtools/webauthn?

If you need powerful test automation for WebAuthn, have you had a look at what's currently possible with WebDriver BiDi and testdriver.js? Recently a lot of previously "too hard" features have been added to testdriver.js, and there might be a pattern you can follow there.

Best regards,

Philip

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com.

[Vladimir Levin]

Hey, with regards to providing logos. My understanding is that this would be displayed in a trusted content. Is there some affordances to clearly indicate that these logos are provided by the merchants? I'm a little concerned for cases like displaying arbitrary content in trusted UI because of things like hate symbols, among other things.

Thanks,

Vlad

[Philip Jägenstedt]

Sorry, I didn't read the WPT PRs you linked. I see that the tests already depend on test_driver.add_virtual_authenticator(). Is there anything blocking testing here, or is it OK if shipping this is conditional on the tests being landed?

[Stephen Mcgruer]

> Sorry, I didn't read the WPT PRs you linked. I see that the tests already depend on test_driver.add_virtual_authenticator(). Is there anything blocking testing here, or is it OK if shipping this is conditional on the tests being landed?

The main issue is that WebAuthn virtual authenticators are not supported on Chrome Android (as far as I know, cc @Nina Satragno ), whilst this feature is shipping first for SPC in Chrome Android (with Desktop to follow in a few milestones). So they're not going to pass when initially landed (and indeed will regress SPC's wpt.fyi status in Chrome), however we discussed this internally yesterday and decided its still better to have tests that reflect the specification even if they now fail due to lack of test support. So our plan is to land them in the coming days (once reviewed).

[Stephen Mcgruer]

> Hey, with regards to providing logos. My understanding is that this would be displayed in a trusted content. Is there some affordances to clearly indicate that these logos are provided by the merchants? I'm a little concerned for cases like displaying arbitrary content in trusted UI because of things like hate symbols, among other things.

Hi Vlad; you're completely right to be concerned in this regard - it is a general concern with SPC. Whilst we do care about this issue, our counter-argument is that there is no incentive to display misleading or offensive logos using SPC.

Firstly, if we examine the 'offensive' case - what is the value of SPC here for someone who wants to offend? If I'm the website, I can render offensive iconography in an HTML 'bottomsheet' UX, with a Chrome logo at the top of it, and write whatever I want. Users will generally not know the difference, and many will just attribute that to being from Chrome anyway. We're actually not looking to present SPC as being "from Chrome" - there's no logo, for example. We've historically discussed this with security, and we have offered to remove the 'line of death/full screen scrim' to further divorce SPC from being 'browser UX' - but so far they haven't asked us to do that.

Secondly, if we examine the 'misleading' case, we cover that in the spec (here and here), but broadly the answer is that even if you trick the user into creating an SPC cryptogram, it has no value unless you are literally processing a transaction with the underlying payment providers (and they are able to examine the output signed cryptogram to know exactly what data you provided to the user). So as a misleading attacker, you at best end up with an SPC cryptogram with no use for it.

[Nina Satragno]

El mié, 9 jul 2025 a la(s) 12:11 p.m., Stephen Mcgruer (smcg...@chromium.org) escribió:

> Hey, with regards to providing logos. My understanding is that this would be displayed in a trusted content. Is there some affordances to clearly indicate that these logos are provided by the merchants? I'm a little concerned for cases like displaying arbitrary content in trusted UI because of things like hate symbols, among other things.

Hi Vlad; you're completely right to be concerned in this regard - it is a general concern with SPC. Whilst we do care about this issue, our counter-argument is that there is no incentive to display misleading or offensive logos using SPC.

Firstly, if we examine the 'offensive' case - what is the value of SPC here for someone who wants to offend? If I'm the website, I can render offensive iconography in an HTML 'bottomsheet' UX, with a Chrome logo at the top of it, and write whatever I want. Users will generally not know the difference, and many will just attribute that to being from Chrome anyway. We're actually not looking to present SPC as being "from Chrome" - there's no logo, for example. We've historically discussed this with security, and we have offered to remove the 'line of death/full screen scrim' to further divorce SPC from being 'browser UX' - but so far they haven't asked us to do that.

Secondly, if we examine the 'misleading' case, we cover that in the spec (here and here), but broadly the answer is that even if you trick the user into creating an SPC cryptogram, it has no value unless you are literally processing a transaction with the underlying payment providers (and they are able to examine the output signed cryptogram to know exactly what data you provided to the user). So as a misleading attacker, you at best end up with an SPC cryptogram with no use for it.

On Wed, 9 Jul 2025 at 12:01, Stephen Mcgruer <smcg...@chromium.org> wrote:

> Sorry, I didn't read the WPT PRs you linked. I see that the tests already depend on test_driver.add_virtual_authenticator(). Is there anything blocking testing here, or is it OK if shipping this is conditional on the tests being landed?

The main issue is that WebAuthn virtual authenticators are not supported on Chrome Android (as far as I know, cc @Nina Satragno ), whilst this feature is shipping first for SPC in Chrome Android (with Desktop to follow in a few milestones). So they're not going to pass when initially landed (and indeed will regress SPC's wpt.fyi status in Chrome), however we discussed this internally yesterday and decided its still better to have tests that reflect the specification even if they now fail due to lack of test support. So our plan is to land them in the coming days (once reviewed).

This is correct, there's no virtual authenticator support for Android. From a WPT perspective this also seems like a reasonable approach to me.

--

Nina Satragno

[Alex Russell]

LGTM1; my view is that each browser team is managing risk about browser-presented UI and that nothing about this forces anyone to display anything.

Best,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com.

--

Nina Satragno

[Domenic Denicola]

This generally looks good, but there's a bit of a hole in the spec which makes it unclear whether CSP, etc. apply to these image fetches: see https://github.com/w3c/image-resource/issues/48 . (The SPC spec calls "Fetch an image resource" with no request supplied, but the Image Resource spec is broken in that case.)

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com.

--

Nina Satragno

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bbcefa96-47c5-4ad2-8f38-d735fd94e63an%40chromium.org.

[Slobodan Pejic]

Thanks Domenic, I have filed an issue to address this problem with the secure-payment-confirmation specification (#307).

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com.

--

Nina Satragno

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Vladimir Levin]

Thanks Stephen, that makes sense.

LGTM2

[Rick Byers]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafTfsu-e69p_8ixAyLvfj0VnVuxs%3DT95w55UbeDSKKr5g%40mail.gmail.com.

--

Nina Satragno

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Daniel Bratell]

LGTM3

/Daniel