On Wed, 29 Apr 2026 at 11:28, Rick Byers <[email protected]> wrote:
LGTM2
On Wed, Apr 29, 2026 at 11:27 AM Alex Russell
<[email protected]> wrote:
LGTM1
On Wednesday, April 29, 2026 at 6:29:54 AM UTC-7 Mike Taylor
wrote:
On 4/28/26 7:49 a.m., 'Stephen McGruer' via blink-dev wrote:
*Note*: Sending before Privacy, WP Security, and Adoption
approvals, due to short timeline to M149. I do not expect
significant feedback from those channels as this is a
small change to an existing API that already has support
from WebKit where relevant (for the Payment Request API
part).
*
*
*Contact emails*
[email protected], [email protected]
*Explainer*
https://github.com/w3c/payment-request/issues/1040
*Specification*
https://w3c.github.io/payment-request/#payment-handler-indicates-an-internal-error-algorithm
*Summary*
Enables payment handlers that are accessed via the
Payment Request API to return distinct errors for "user
cancelled" vs "internal payment app error". This allows
web developers to build better flows for users, e.g. by
retrying or falling back to a different flow when an
internal app error occurs, whilst properly stopping the
flow if the user wants to cancel. The Web-based Payment
Handler API can indicate this difference based on what
error they use to reject the promised passed to
PaymentRequestEvent.respondWith. If the promise is
rejected with an OperationError, then "internal app
error" (OperationError) is returned to the merchant via
the PaymentRequest.show(), otherwise "user cancel"
(AbortError) is returned. Native app payment handler
infrastructure is similarly updated, but is out of scope
for web APIs.
*Blink component*
Blink>Payments
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EPayments%22>
*Web Feature ID*
payment-request
<https://webstatus.dev/features/payment-request>
*Motivation*
Currently, when PaymentRequest.show() is rejected due to
an error in the underlying payment handler app, the only
possible outcome is AbortError. This makes it difficult
for payment apps using Payment Request to build good user
flows, as it is difficult to differentiate between "call
failed because user cancelled out of the payment app" and
"call failed because the app had an internal error".
*Initial public proposal*
/No information provided/
*TAG review*
N/A - very minor API tweak (was briefly discussed with
TAG member at TPAC 2025, who showed no concern)
*TAG review status*
Not applicable
*Goals for experimentation*
None
*Risks*
*Interoperability and Compatibility*
/No information provided/
/Gecko/: N/A Firefox does not ship Payment Request or
Payment Handler.
Do we have any existing Payment Request or Payment Handler
positions? If so, it's probably fine to just add a comment
to them about this change, but if not, we should request one.
/WebKit/:
Positive (https://github.com/w3c/payment-request/pull/1050) Positive
for the Payment Request change, N/A for the Web-based
Payment Handler change as WebKit does not implement any
Payment Handler other than Apple Pay (PR was reviewed by
marcos @ webkit, who is doing their implementation)
Can we file an official request?
/Web developers/: Positive Requested by both current +
prospective payment handler adopters
/Other signals/:
*Ergonomics*
No expected ergonomic risks.
*Activation*
No expected activation risks - minor change adding a new
error outcome for PaymentRequest.show()
*Security*
No known security risks.
*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?
This adds a new potential (error) return value for the
PaymentRequest.show() API within WebView. This is
considered low risk, both because a new error type
shouldn't be a significant risk but also because
PaymentRequest in webview is **disabled by default** and
must be manually enabled by the webview embedder.
*Debuggability*
Standard devtools debugging; breakpoints + introspection
of error types.
*Will this feature be supported on all six Blink
platforms (Windows, Mac, Linux, ChromeOS, Android, and
Android WebView)?*
Yes
*Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
No
Manual WPTs added where possible -
https://github.com/web-platform-tests/wpt/pull/59002, but
Payment Request/Web-based Payment Handler do not have the
necessary chromedriver automation currently to write
fully fledged automated tests. Chrome source automated
tests added as well, of course.
*Flag name on about://flags*
/No information provided/
*Finch feature name*
PaymentRequestSupportReportingAppError
*Rollout plan*
Will ship enabled for all users
*Requires code in //chrome?*
Technically, a tiny bit (UX code for web-based payment
handlers, some browsertests are also in //chrome)
*Tracking bug*
https://crbug.com/473478138
*Availability expectation*
Payment Request level changes will be available in both
Chromium and Safari, but Safari only supports Apple Pay
as a payment method. Chromium browsers will also support
both the web-based Payment Handler and native app Payment
Handler support for it.
*Estimated milestones*
Shipping on desktop 149
Shipping on Android 149
Shipping on WebView 149
*Anticipated spec changes*
No open issues, although the general question of whether
a single new error type (vs something generic like
supporting arbitrary developer errors to be passed
through) was debated between us and Apple. Marcos is
following up with the TAG on the general principle
because it's also relevant to the DC API. This might
cause future changes, but they would likely be *mostly*
backward-compatible (since OperationError would remain a
valid error type to throw).
*Link to entry on the Chrome Platform Status*
https://chromestatus.com/feature/5942637229113344?gate=4777865385213952
This intent message was generated by Chrome Platform
Status <https://chromestatus.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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Macn-SYc8C%2BMBr06%3Df2%3Ds%3D8oGHHrhGoG9q1wV2oMP3ZuWg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Macn-SYc8C%2BMBr06%3Df2%3Ds%3D8oGHHrhGoG9q1wV2oMP3ZuWg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/815efbae-8db0-4e86-a90a-2b30401c6253n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/815efbae-8db0-4e86-a90a-2b30401c6253n%40chromium.org?utm_medium=email&utm_source=footer>.
--
smcgruer • he / him
