vykochko@chromium.org smcgruer@google.com payments-autofill-team@google.com Android specific metric. Recorded every time the address editor is opened from the Payment Request UI for either adding a new address or editing existing. smcgruer@chromium.org chrome-payments-eng@google.com Whether or not a call to the PaymentRequest.canMakePayment() API was allowed by the kCanMakePaymentEnabled user preference. This histogram does not reflect what the outcome of the canMakePayment call would have been, only if it was allowed or blocked by the preference. It is recorded once per PaymentRequest.canMakePayment call. smcgruer@chromium.org chrome-payments-eng@google.com Counts the number of Payment Requests (PR) that go through each checkout step. A single PR may be counted in multiple buckets depending on its final status. e.g. A completed PR will be counted in all of the following buckets 1- Initiated, 2- show() called 3- Payment request triggered 4- Payment handler invoked, 5- Completed. smcgruer@chromium.org chrome-payments-eng@google.com The 2.0 version of Events. A bitfield representing the different events that happened during the Payment Request. darwinyang@google.com chrome-payments-eng@google.com Whether a hardware backed browser bound key is available for use when getSecurePaymentConfirmationCapabilities() is called. Recorded at the end of IsBrowserBoundKeyHardwareSupported() before it is returned and collected into a map of capabilities that is returned to the caller. Note that this does not record how often developers want to know if hardware backed browser bound keys are available as this will always be called when getSecurePaymentConfirmationCapabilities() is called. In addition, the results of this metric can also be biased as this may be called multiple times on the same client/device. smcgruer@chromium.org chrome-payments-eng@google.com Whether or not a call to the PaymentRequest.hasEnrolledInstrument() API was allowed by the kCanMakePaymentEnabled user preference. This histogram does not reflect what the outcome of the hasEnrolledInstrument call would have been, only if it was allowed or blocked by the preference. It is recorded once per PaymentRequest.hasEnrolledInstrument call. smcgruer@chromium.org chrome-payments-eng@google.com Records whether an internal app was found to be available when a Payment Request is created for a URL that is expected to have an internal app. Recorded once per 'new PaymentRequest(..)' call, albeit asychronously (as Payment Request creation is async). Only the first-encountered failure reason is recorded for a given Payment Request construction, which may hide other failure reasons that could occur later in the flow. Note that the "Not Applicable" case of the InternalPaymentAppAvailability enum is not recorded in practice, as it is not relevant to record. It exists only for completeness in the internal code. This histogram is not recorded if the internal app factory is disabled or is not available for a given platform (WebView, all other non-Android platforms). smcgruer@chromium.org chrome-payments-eng@google.com Whether or not the 'payments.can_make_payment_enabled' pref is enabled when a PaymentRequest object is constructed. Recorded only when a PaymentRequest object is first constructed, and approximately once per startup (specifically, once per BrowserContext). The difference between this histogram and PaymentRequest.IsCanMakePaymentAllowedByPref.Startup is that this histogram is only recorded if/when the user visits a page that constructs a PaymentRequest object, which means that it sub-selects for users who are likely to be in a payment context. smcgruer@chromium.org chrome-payments-eng@google.com When the 'payments.can_make_payment_enabled' pref is disabled, this records the reason why (e.g., by the user, an extension, etc). Recorded only when a PaymentRequest object is first constructed, and approximately once per startup (specifically, once per BrowserContext). The difference between this histogram and PaymentRequest.IsCanMakePaymentAllowedByPref.Startup.DisabledReason is that this histogram is only recorded if/when the user visits a page that constructs a PaymentRequest object, which means that it sub-selects for users who are likely to be in a payment context. smcgruer@chromium.org chrome-payments-eng@google.com Whether or not the 'payments.can_make_payment_enabled' pref is enabled. Recorded once per profile load/creation (approximately once per start-up for a normal browsing session). smcgruer@chromium.org chrome-payments-eng@google.com When the 'payments.can_make_payment_enabled' pref is disabled, this records the reason why (e.g., by the user, an extension, etc). Recorded once per profile load/creation (approximately once per start-up for a normal browsing session). xuehuichen@google.com chrome-payments-eng@google.com Records the duration in milliseconds that the payment app loading view is shown during payment handler invocation when {Outcome}. When the payment app loads normally, RemoveLoadingView() is called upon completion and records Completed. If the payment app loading takes too long and the user manually closes the dialog window, or if the request is aborted, the dialog is destructed without calling RemoveLoadingView(), which records Aborted. Separating these variants prevents cancellation/abort latencies from impacting normal loading view shown latencies. xuehuichen@google.com chrome-payments-eng@google.com Records the outcome when a payment handler's respondWith() promise resolution was paused due to missing user gesture. Recorded when the paused state resolves, either because the user interacted with the payment handler window (provided a gesture) or because the user closed the window (by clicking 'x' or pressing ESC). xuehuichen@google.com chrome-payments-eng@google.com Records whether the promise passed to PaymentRequestEvent.respondWith() was rejected before a call to PaymentRequestEvent.openWindow(). Recorded when the respondWith() promise is rejected in a payment handler. xuehuichen@google.com chrome-payments-eng@google.com Records whether the promise passed to PaymentRequestEvent.respondWith() was rejected before a user gesture was captured in the payment app window. Recorded when the respondWith() promise is rejected in a payment handler. xuehuichen@google.com chrome-payments-eng@google.com Records whether the promise passed to PaymentRequestEvent.respondWith() was resolved before a call to PaymentRequestEvent.openWindow(). Recorded when the respondWith() promise is resolved in a payment handler. xuehuichen@google.com chrome-payments-eng@google.com Records whether the promise passed to PaymentRequestEvent.respondWith() was resolved before a user gesture was captured in the payment app window. Recorded when the respondWith() promise is resolved in a payment handler. smcgruer@chromium.org chrome-payments-eng@google.com The number of suggestions shown to the user during a payment request. darwinyang@chromium.org chrome-payments-eng@google.com Tracks the final outcome of every Payment Request call. This includes all successful calls, all cases where the Payment Request could not be shown, and all cases where the Payment Request was aborted with detailed abort reasons. Recorded exactly once per Payment Request lifetime when a terminal state is reached. smcgruer@chromium.org chrome-payments-eng@google.com Recorded when an invoked Android payment app sends updated payment method details to the merchant website that invoked the PaymentRequest API for this app. Only authorized service calls are recorded. If an app that is not being invoked for payment invokes this service, the metric is not recorded. The metric is recorded even if the invoked Android payment app sends an invalid payment method data bundle. Warning: this histogram was expired from 2025-03-03 to ~2025-04-11; data may be missing. smcgruer@chromium.org chrome-payments-eng@google.com Recorded when an Android payment app sends updated shipping address to the merchant website that invoked the PaymentRequest API for this app. Only authorized service calls are recorded. If an app that is not being invoked for payment invokes this service, the metric is not recorded. The metric is recorded even if the invoked Android payment app sends an invalid shipping address. Warning: this histogram was expired from 2025-03-03 to ~2025-04-11; data may be missing. smcgruer@chromium.org chrome-payments-eng@google.com Recorded when an Android payment app sends updated shipping option (e.g., "standard" or "express") to the merchant website that invoked the PaymentRequest API for this app. Only authorized service calls are recorded. If an app that is not being invoked for payment invokes this service, the metric is not recorded. The metric is recorded even if the invoked Android payment app sends an invalid shipping option. Warning: this histogram was expired from 2025-03-03 to ~2025-04-11; data may be missing. smcgruer@chromium.org chrome-payments-eng@google.com Whether an attempted just-in-time payment handler installation was successful. Recorded when the attempted installation is finished. darwinyang@chromium.org chrome-payments-eng@google.com Records the latency of signing data with the browser bound key. This latency is measured from the moment a key is about to sign data to when the key is done signing. slobodan@chromium.org darwinyang@chromium.org chrome-payments-eng@google.com Whether and how browser bound key will be included in a secure payment confirmation response once the authenticator succeeds. Recorded before the browser bound public key is provided to the authenticator. I.e., recorded after the user has clicked [Verify], but before the user has scanned their biometric. darwinyang@chromium.org chrome-payments-eng@google.com Whether updating the browser bound key metadata was successful or not. Recorded after a browser bound key metadata update is attempted. darwinyang@chromium.org chrome-payments-eng@google.com Records the latency of creating the browser bound key. This latency is measured from the moment a key is about to be created to when the key is returned. darwinyang@google.com chrome-payments-eng@google.com Records the latency of fetching whether the device has support for hardware backed browser bound keys. This latency is measured from the moment the check is started in the browser bound key store to when the result is returned. Note that this is only recorded when the value is not cached, which means that it is only recorded on the first check and is not recorded at all if the value was already cached by the time the check is made. darwinyang@chromium.org chrome-payments-eng@google.com Records the latency of getting the browser bound key. This latency is measured from the moment a key is about to be retrieved to when the key is returned. slobodan@chromium.org darwinyang@chromium.org chrome-payments-eng@google.com Whether the creation of a browser bound key succeeded or failed and whether hardware storage of key pairs is available on the device. Recorded after a browser bound key creation is attempted. slobodan@chromium.org darwinyang@chromium.org chrome-payments-eng@google.com Whether the retrieval of a browser bound key succeeded or failed and whether hardware storage of key pairs is available on the device. Recorded after a browser bound key retrieval is attempted. darwinyang@google.com chrome-payments-eng@google.com Records whether the SPC fallback UX was triggered by a missing authenticator. Recorded right before the SPC app is created with `is_error_dialog` set to true. darwinyang@google.com chrome-payments-eng@google.com Records whether the SPC fallback UX was triggered by a missing credential. Recorded right before the SPC app is created with `is_error_dialog` set to true. nikifork@google.com chrome-payments-eng@google.com Records whether a website is passed a locale array when invoking Secure Payment Confirmation, and whether it matched the application locale. Recorded once upon initialization of a PaymentRequest object whose payment method is SPC when the feature flag is enabled. Precisely, right before IsValidSecurePaymentConfirmationRequest is called. darwinyang@google.com chrome-payments-eng@google.com Records whether a user verifying platform authenticator is available for SPC. If the UVPA is not available, the SPC fallback UX will be triggered. Recorded in the callback after checking if the authenticator is a UVPA. Note that this does NOT get recorded if the internal authenticator could not be created. smcgruer@chromium.org chrome-payments-eng@google.com The outcome of trying to show the PaymentRequest UI in response to PaymentRequest.show(), with regards only to whether the call is blocked due to an existing PaymentRequest.show() call being underway either in the same or another tab. Recorded per 'valid' call to PaymentRequest.show() - that is, does not include calls where show() was called twice on the same object, or the PaymentRequest wasn't initialized first, etc. Whether this metric records the show being allowed or not, it is important to note that there are subsequent steps in actually showing the PaymentRequest that may or could still fail. For example, the request could be being made from a background tab, which is checked later after this metric is recorded. As such, interpret this metric with care - it cannot be read as "these calls succeed and these calls do not"! xuehuichen@google.com chrome-payments-eng@google.com Duration from PaymentRequest.Init() to successful transaction completion. Recorded when a payment transaction completes successfully. Note that this metrics is foucs on the happy path, failed transaction are not counted. xuehuichen@google.com chrome-payments-eng@google.com Duration from PaymentRequest.show() to successful transaction completion. Recorded when a payment transaction completes successfully. Note that this metrics is foucs on the happy path, failed transaction are not counted. smcgruer@chromium.org chrome-payments-eng@google.com Records the reason why a Payment Request or Payment Handler dialog was rejected or closed due to the browser window being too small. This is only recorded on desktop platforms. darwinyang@google.com chrome-payments-eng@google.com The outcome of showing the SecurePaymentRequest "Fallback" UX and how the user interacts with it. Recorded when the SecurePaymentRequest fallback dialog is closed. Note that this is only for the SPC fallback dialog (when matching credentials are not found) and does not include the SPC transaction dialog or the OS-level web authentication dialog. darwinyang@google.com chrome-payments-eng@google.com The outcome of showing the SecurePaymentRequest "Transaction" UX and how the user interacts with it. Recorded when the SecurePaymentRequest transaction dialog is closed. Note that this is only for the SPC transaction dialog and does not include the OS-level web authentication dialog that comes after this dialog or the fallback dialog when matching credentials are not found.