Four separate categories of error states return AbortError with vendor-specific error messages. Each of these categories requires a separate response from the merchant.

1. User closed the UI intentionally, .e.g, by clicking on the "Cancel Payment" button. Merchant may want to count this against their completion rate metrics. The user should remain on the checkout page.
2. User closed the UI, but it may have been unintentional. For example, switching tabs on Android will close the UI, although cancelling payment may not have been user's intention. Merchants may want to not count this against their completion rate metrics. The user should remain on the checkout page.
3. The browser UI or the payment app failed to launch. For example, the payment handler threw an exception when beginning to handle the paymentrequest event. Merchants may want to provide a fallback checkout experience, e.g., autofill form fields for credit card input. Merchants may want to let the payment app provider know about a bug in their code.
4. The browser UI or the payment app launched and user interacted with it, but the payment app failed to return a valid result, e.g., payment app did not specify any data in their response. Merchants may want to let the payment app provider know about a bug in their code. I'm not sure what kind of mitigation is the most appropriate in this case.

Chrome returns different message strings with these categories of messages, but requiring the merchant to distinguish errors by message strings is brittle and flaky. I propose that PR 1.1+ should standardize some error codes that the browser should return when rejecting PaymentRequest.show(). For example:

1. Error code 1 for intentional UI closing.
2. Error code 2 for unintentional UI closing.
3. Error code 3 for failure to launch a payment flow.
4. Error code 4 for failure during payment flow.

Error messages themselves can remain vendor specific, as long as they follow the format:

Error <X>: <Vendor-specific message here>