Shipping the Payment Request API over the last two years helped us better understand the challenges in building payment flows on the web. We learned that UX is critical for building user trust with a payment app, and new technology such as tokenization has made great strides in protecting users from online fraud by never exposing a user’s credit card number to a website. Unfortunately, Chrome’s built-in payment handler for “basic-card” falls short on both regards. As we considered solutions, we realized that the best way to enable more seamless and secure payments on the web is to enable an interoperable ecosystem, where digital wallets can bring their best experience to the web. This means shifting focus to the Payment Handler API, which is an emerging W3C standard that allows 3rd party payment handlers, which can be either native mobile apps or progressive web apps, to integrate with the browser to handle Payment Requests. This enables users to complete one-click payments anywhere on the web using their wallet of choice.
This shift in focus means that we will eventually sunset Chrome’s built-in “basic-card” payment handler. We will start by removing “basic-card” support from iOS Chrome, where this feature has the least usage. This change is coming in M81. In its place, we are investigating how to enable native apps on iOS to integrate with Payment Request API in Chrome. The “basic-card” payment method remains a W3C standard and developers can build compatible payment handlers using the Payment Handler API by setting method to “basic-card”when registering a payment handler with the browser.
This M81 change will deactivate Payment Request API on iOS Chrome because “basic-card” is the only supported payment method and because payment handlers are unavailable due to the lack of Payment Handler API support in WKWebView. If you’re a developer that uses Payment Request API, please make sure you use feature detection and provide a suitable fallback to ensure iOS users continue to have a working alternative. This is also needed to ensure your website works as expected in browsers that don’t yet support Payment Request API.
The quieter UI is available in both Desktop and Mobile. The first time the UI is presented to the user, it will be accompanied by a dismissable in-product help dialog that explains the new feature.
Enrollment & opt out
Users can be enrolled in the quieter UI in three ways.
Manual enrollment (and opt-out)
Manually enroll on Desktop or Mobile via Notifications Settings
Users can enroll for quieter prompts manually, or disable it completely. To enroll, the toggle ‘Sites can ask to send notifications’ must be enabled in Settings > Site Settings > Notifications, then the checkbox ‘Use quieter messaging’ must be checked.
Automatic enrollment for users who infrequently accept notifications
Users who repeatedly deny notifications across websites will be automatically enrolled in the quieter notifications UI.
Automatic enrollment on sites with low permission acceptance rates
Sites with very low acceptance rates will be automatically enrolled in quieter prompts. They will be unenrolled once acceptance rates improve, for example, if the developer of the site improves the notification permission request user experience. Per-site information about notification permission acceptance rates will be made available via the Chrome User Experience Report in Q1 2020 and automatic enrollment is based on Chrome usage statistics.
Developer recommendations
First, we recommend that web developers test their site’s permission request flow with the quieter notification permission UI, by enabling it manually in chrome://settings/content/notifications. At the time of writing, the feature is being rolled out gradually to Canary, Dev, and Beta channels, and can be force-enabled in chrome://flags/#quiet-notification-prompts in Chrome 80 and later.
Second, we recommend that developers follow best practices for requesting the notification permission from users. Websites that ask users to sign up for web notifications when they first arrive often have very low accept rates. Instead, we recommend that websites wait until users understand the context and see benefit in receiving notifications before prompting for the permission. Some websites display a pre-prompt in the content area before triggering the native permission prompt. This approach is also not recommended if it interrupts the user journey: sites that request the permission at contextually relevant moments enjoy lower bounce and higher conversion rates.
For help with user permission UX, you can refer to this 5 minute video on improving your user permission acceptance rates, and read about best practices when requesting permissions.
