Intent to Ship: Get Secure Payment Confirmation Capabilities

[Chromestatus]

Contact emails

darwi...@chromium.org

Explainer

https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419

Specification

https://w3c.github.io/secure-payment-confirmation/#sctn-secure-payment-confirmation-capabilities

Design docs

https://www.w3.org/wbs/83744/spc-mvp-2025/results
https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419
https://www.w3.org/2026/01/29-wpwg-minutes.html#3919
https://www.w3.org/2026/02/26-wpwg-minutes.html#bbkdetect

Summary

Adds a new static method to the Payment Request that allows web developers to get the capabilities of the browser's implementation of Secure Payment Confirmation. This helps web developers to easily know what capabilities are available for Secure Payment Confirmation so they can decide whether or not they want to use Secure Payment Confirmation with those capabilities.

Blink component

Blink>Payments

Web Feature ID

secure-payment-confirmation

Motivation

This feature allows web developers to check for which capabilities are supported in the browser's implementation of Secure Payment Confirmation. Web developers want an easy way to check whether hardware browser bound keys are available with the Secure Payment Confirmation API and only use the API if if they are available. Without this method, web developers would need to initiate the Secure Payment Confirmation flow and force users to go through the dialog and authenticate just to ignore the data returned if it did not contain the browser bound key (in cases where browser bound keys are not available).

Initial public proposal

https://github.com/w3c/secure-payment-confirmation/issues/290#issuecomment-3806454419

Search tags

spc, bbk

TAG review

No information provided

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The GetSecurePaymentConfirmationCapabilities method is new and the only risk is if other browser do not implement it.

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/570) Firefox haven't implemented SPC yet so this new method is not relevant.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/30) Safari haven't implemented SPC yet so this new method is not relevant.

Web developers: Positive (https://www.w3.org/2026/01/29-wpwg-minutes.html#3919) Discussed the GetSecurePaymentConfirmationCapabilities method during the WPWG when proposing a solution to Browser Bound Key Feature Detection and did not receive any comments opposed to this feature.

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?

No information provided

Debuggability

Web developers should be able to inspect the output of the new method which is defined in WebIDL, 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
The GetSecurePaymentConfirmationCapabilities method will only be added to platforms that support Secure Payment Confirmation which are currently only Android, macOS, and Windows.

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

No
Web platform tests are in development. We can only test if the method is available and can be called as user agents have the ability to omit capabilities (for privacy reasons).

Flag name on about://flags

No information provided

Finch feature name

SecurePaymentConfirmationCapabilities

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://crbug.com/484043990

Launch bug

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

Measurement

A new GetSecurePaymentConfirmationCapabilities UseCounter will be created and used.

Availability expectation

The GetSecurePaymentConfirmationCapabilities method will only be available in Chromium browsers for the foreseeable future.

Estimated milestones

Shipping on desktop	147
Shipping on Android	147

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).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4727235745546240?gate=4769560794365952

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69a0a6a7.050a0220.3c921b.02ae.GAE%40google.com

This intent message was generated by Chrome Platform Status.

[Alex Russell]

Just to confirm, access to this API is gated behind a user-initiated flow? That is, we don't create any additional fingerprinting risk until such time as the user is attempting a transaction?

Best,

Alex

[Yoav Weiss (@Shopify)]

Given that this is a new capability we're shipping first, why isn't a TAG review applicable?

 

--
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/69b02941.710a0220.50957.0104.GAE%40google.com.

[Darwin Yang]

Just to confirm, access to this API is gated behind a user-initiated flow? That is, we don't create any additional fingerprinting risk until such time as the user is attempting a transaction?

No, it is not gated behind a user-initiated flow but as mentioned in the privacy review, the TPM detection as a fingerprinting vector is already possible without this ne API.

Given that this is a new capability we're shipping first, why isn't a TAG review applicable?

Although this is a new API, the ability to get this information (BBK availability) is not new and can be obtained through the SPC payment request show method. This would be similar to the SPC availability API.

[Darwin Yang]

Given that this is a new capability we're shipping first, why isn't a TAG review applicable?

Looking at the Webauthn GetClientCapabilities API which is similar to this, they were able to FYI their TAG review. If I were to get one, I was wondering if I could do the same.

[Alex Russell]

The API (as I understand it from the comment that's linked in lieu of an Explainer) is gated by a Promise, so that gives us a chance to retrofit with other checks in the future.

I'd be happier with an FYI to the TAG if there were a real Explainer that describes the value of the problem being solved and the alternatives that were considered. Is it possible to get one of those?

Best,

Alex

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

[Darwin Yang]

The API Proposal linked as the explainer includes background on the problem, the value of solving it, and alternative APIs that were considered. Was there something specific that you were looking for in a separate explainer that wouldn't just paraphrase the API proposal?

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

[Darwin Yang]

FYI I decided to write the explainer and linked it in the feature. Here is a link to it as well: https://github.com/w3c/secure-payment-confirmation/blob/main/explainer-capabilities.md.

[Alex Russell]

Thanks for doing that, Darwin. LGTM1

Some feedback on the Explainer to consider for future efforts:

 - it's great to see the considered alternatives; thank you!

 - Explainers are "speaking design docs"; that is, part of their job is to explain to developers, not just browser engineers, what the value of a feature and the tradeoffs in the design space. As a result, we heavily prefer to see designs described in JS (particularly example code) rather than IDL. If you have to keep the IDL (e.g., because there isn't a spec draft yet in which to deposit it), an appendix is a good place for it.

 - In the privacy considerations section, I don't see a discussion of user activation. Perhaps worth adding?

Best,

Alex

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

[Rick Byers]

LGTM2

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/69b02941.710a0220.50957.0104.GAE%40google.com.

--

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/79711c2d-5f0d-44c3-a506-21cfbe11bba3n%40chromium.org.

[Yoav Weiss (@Shopify)]

LGTM3

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/69b02941.710a0220.50957.0104.GAE%40google.com.

--
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.