Remove "instrument" concept from PaymentManager

[danyao]

The PaymentInstruments [1] concept was originally designed to support multiple credit cards. It adds confusion to payment handlers that are not fundamentally about credit cards. Since Payment Request API is moving towards payment apps being the atomic building blocks instead of instruments, I think it will be more clear to change payment handler registration interface to something like this:

registration.paymentManager.setPaymentMethods([
    'https://bobpay.xyz/pay',
    'https://alicepay.com'
]);

Today many parts of PaymentInstruments are not used:

• Web-based payment handlers usually sets a single instrument with their supported payment methods
• Chrome always fetches the icon from the payment handler's web app manifest instead of using the ones provided in PaymentInstruments.set()
• capabilities only has well-defined meaning for basic-card payment method

With the proposed change to remove the PaymentInstrument concept, the web app manifest can become the authoritative source of information about the payment handler, such as name, icons, capabilities. This will also better unify just-in-time installation and explicit installation of payment handlers.

[1] https://w3c.github.io/payment-handler/#paymentinstruments-interface

[tblachowicz]

If we look from the perspective of the wallet, in the generic meaning, it actually makes a lot of sense to have PaymentInstrument concept. I think most of the Payment Apps allow selection of some soft of the instrument, and the payment is facilitated using the specific payment instrument. To me, the concept is much more generic than only credit cards. For wallets such as xPays the payment instrument is the payment card (credit, debit or other), for Open Banking aggregators it would be specific bank account to pay with and so on.

[rsolomakhin]

Is it possible for the user to consider the user agent as the wallet and all of the individual payment apps as "instruments"?

[danyao]

I think most of the Payment Apps allow selection of some soft of the instrument, and the payment is facilitated using the specific payment instrument. To me, the concept is much more generic than only credit cards. For wallets such as xPays the payment instrument is the payment card (credit, debit or other), for Open Banking aggregators it would be specific bank account to pay with and so on.

Yes "payment instrument" is a real-world concept and won't go away. This bug is about the technical question of whether "payment instrument" should be exposed to the browser in the web payments architecture. Framed from the user's perspective, the question is: should the browser offer users choices of payment apps or choices of payment instruments from within the apps?

So far, there is no payment handler that actually leverages the capability of exposing instruments to the browser. So I'm taking this as a signal that this capability is not useful. Removing it would simplify browser's implementation. But if a developer demonstrates a real use case for this capability, we would definitely consider keeping it.

[tblachowicz]

Yes "payment instrument" is a real-world concept and won't go away. This bug is about the technical question of whether "payment instrument" should be exposed to the browser in the web payments architecture. Framed from the user's perspective, the question is: should the browser offer users choices of payment apps or choices of payment instruments from within the apps?

It's one of the fundamental questions for Web Payments. As a user, I personally would prefer a selection of the payment apps, but I guess there might be good arguments for the alternative approach.

So far, there is no payment handler that actually leverages the capability of exposing instruments to the browser. So I'm taking this as a signal that this capability is not useful. Removing it would simplify browser's implementation. But if a developer demonstrates a real use case for this capability, we would definitely consider keeping it.

At the moment there are very little payment handlers in general, so I doubt the conclusion that the capability of exposing instruments is not useful. We've tried in one of the early prototypes to expose multiple instruments from single payment handler and it didn't work as expected in Chrome, because the instruments weren't displayed on the list.

[tblachowicz]

As per my understanding currently, the payment instrument is the only way to specify which payment method given payment handler supports. Payment manager sets the payment instrument with the method specifying the payment method identifier.

In case of payment instrument is removed from the specification there must be the other way to specify the supported methods, preferably in the manifest as the delegation can be specified.

[danyao]

As per my understanding currently, the payment instrument is the only way to specify which payment method given payment handler supports. Payment manager sets the payment instrument with the method specifying the payment method identifier.

The PaymentInstruments is only used when a payment handler is installed explicitly. Today it is involved in the setting of a payment handler's supported payment methods, but it doesn't need to be. The original post at the top has a proposal for how this functionality can still be supported in a world without PaymentInstruments.

So far, there is no payment handler that actually leverages the capability of exposing instruments to the browser. So I'm taking this as a signal that this capability is not useful. Removing it would simplify browser's implementation. But if a developer demonstrates a real use case for this capability, we would definitely consider keeping it.

At the moment there are very little payment handlers in general, so I doubt the conclusion that the capability of exposing instruments is not useful.

Fair enough.

We've tried in one of the early prototypes to expose multiple instruments from single payment handler and it didn't work as expected in Chrome, because the instruments weren't displayed on the list.

Can you elaborate a bit more how it didn't work as expected? What's the ideal user flow you'd like to achieve?

[jcayzac]

Hello,

Also, that the spec is called Payment Handler API but the main concept it introduces is called Payment Instrument adds unnecessary complexity. It could be just handler or just instrument.

[jcayzac]

In case of payment instrument is removed from the specification there must be the other way to specify the supported methods, preferably in the manifest as the delegation can be specified.

Personally I find a web manifest approach inconsistent with the design of Web APIs in general and would very much prefer keeping the current API-based approach.

[ianbjacobs]

See updates to Chromium to remove instruments:
https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/VenSGqBIoKI?pli=1