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/83184096-619c-4ec7-8e72-f0f5b0e5de24%40chromium.org.
