The implementation of hasEnrolledInstrument() in Chrome 78 and earlier is relaxed in terms of checking for autofill data completeness and validity. For example, if a user's only autofill data is a credit card that has a number and a name on card, then hasEnrolledInstrument() will return true for basic-card, even if the merchant specifies requestShipping: true and requestPayerEmail: true. This results in poor user experience, which may deter merchant adoption.
The goal of the project is to reduce the usage of the unhappy path for autofill data, so that users see the happy path more often. A happy path shold require only a couple of clicks to authorize a transaction.
const pr = new PaymentRequest(
[{supportedMethods: 'basic-card'}],
details,
{
requestShipping: true,
requestPayerEmail: true,
requestPayerPhone: true,
requestPayerName: true
});
// Chrome 78 and earlier requires only a card number and name on
// card for `hasEnrolledInstrument` to be true.
// Chrome 79+ will require that billing address, expiration data,
// shipping address, and contact information must all be valid
// for `hasEnrolledInstrument` to be true.
const hasEnrolledInstrument = await pr.hasEnrolledInstrument();This project does not affect 3rd party payment handlers, including those that provide basic-card instruments.
Because many websites call directly into pr.show() instead of checking pr.canMakePayment() or pr.hasEnrolledInstrument(), the next phase of the project should be rejecting show() with NotSupportedError for the cases where only autofill instruments are available, but the data is incomplete and invalid (i.e., pr.hasEnrolledInstrument() returns true).
The Payment Request specification is not affected by this project. This project is an implementation detail that is, nevertheless, important for web developers to keep in mind when using Payment Request in Chrome.