LGTM3 On Wed, Apr 29, 2026 at 8:40 AM 'Stephen McGruer' via blink-dev < [email protected]> wrote:
> > 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. > > Done, > https://github.com/mozilla/standards-positions/issues/23#issuecomment-4345224553 > > > Can we file an official request? > > Done, https://github.com/WebKit/standards-positions/issues/655 . I'm not > sure they'll thank us for the overhead, though... > > 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 > > -- > 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/CADY3MafXpO5Vgb-J4ZnkAKeSVEkoNnV%2B-naMBGO4G%3D8Ficku3A%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MafXpO5Vgb-J4ZnkAKeSVEkoNnV%2B-naMBGO4G%3D8Ficku3A%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/CAOMQ%2Bw_ajo16SATZq_t1kYXX0xgzcQ-RFJ2xoCj82XqBa9y5yw%40mail.gmail.com.
