Indicate to the payment handler whether the user agent showed payment sheet?

[rsolomakhin]

Some background: On the one hand, In Chrome we sometimes skip the payment sheet and go directly to the payment app when a number of conditions are met, some of which are, for example:

1. Not requesting shipping or contact info.
2. A single payment method name.
3. URL-based payment method name.

On the other hand, I've seen PayPal skip their flow for one of my purchases today, because I explicitly enabled this option in my settings. I stayed on the merchant website throughout the purchase.

Now, the interesting point: a payment handler may want to either skip or show their own flow based in part on whether the user agent showed or skipped its payment sheet.

Therefore, my question: Would it be useful for the user agent to indicate to the payment handler whether the payment sheet was skipped?

cc: @anthonyvd @gogerald @DurgaTheHutt

[ianbjacobs]

Hi @rsolomakhin,

I think that might be useful information. For example, suppose I could configure my payment app so that payments under a certain amount happen automatically. Furthermore, the payment app is launched automatically without showing the sheet. This means that I make a payment simply by clicking on the Buy button. On the one hand, this might be useful for streamlining some types of payments. On the other hand, a payment app may need to enforce a user consent model where there is at least one explicit user action. Perhaps selection of the payment app in the sheet suffices as an explicit user action, so the payment handler does not need to prompt the user further. But if the sheet does not include a user action, the perhaps the payment handler needs to require it. So it might be helpful for the payment handler to know whether a user action has already taken place.

Ian

[stpeter]

@rsolomakhin First, two preliminary questions:

1. With respect to skipping the sheet if there is "a single payment method name", are those the old payment method identifiers ("visa", "mastercard", etc.) or the new PMIs (e.g., "basic-card").

2. With respect to skipping the sheet if there is a "URL-based payment method name", does that mean (a) there is only a single PMI and it is a URL-based PMI, or (b) the list of PMIs includes a URL-based PMI?

As to your "interesting point", do you envision that the precedence order is one-way (i.e., the browser is in control but can cede control to the payment app under certain conditions) and therefore that the user's browser preferences take precedence over the user's per-app preferences? If not, it seems that we'd need more robust communication between the browser and the payment apps to handle various scenarios of the kind that @ianbjacobs has outlined (e.g., configure a payment app "so that payments under a certain amount happen automatically" - the browser would need to know this and potentially also adjudicate among competing "claims" from multiple payment apps, which seems like a recipe for code complexity and user confusion).

[adrianhopebailie]

This feels like we will cover a lot of the same ground as when we discussed https://github.com/w3c/payment-handler/issues/173 so may be worth reading over that too

[rsolomakhin]

@stpeter:

With respect to skipping the sheet if there is "a single payment method name", are those the old payment method identifiers ("visa", "mastercard", etc.) or the new PMIs (e.g., "basic-card").

Neither. It's URL-based payment method identifiers, such as "https://google.com/pay".

With respect to skipping the sheet if there is a "URL-based payment method name", does that mean (a) there is only a single PMI and it is a URL-based PMI, or (b) the list of PMIs includes a URL-based PMI?

It's a single PMI and it's URL-based.

As to your "interesting point", do you envision that the precedence order is one-way (i.e., the browser is in control but can cede control to the payment app under certain conditions) and therefore that the user's browser preferences take precedence over the user's per-app preferences?

Correct. The browser is in control. The payment app can decide whether to open its own HTML page via PaymentRequestEvent.openWindow(url), but it cannot direct the browser to skip the payment sheet.

the browser would need to [...] potentially also adjudicate among competing "claims" from multiple payment apps

Chrome does not skip the payment sheet if multiple payment apps are installed for the PMI. Then the user would be given the choice of payment apps in the browser payment sheet in every PaymentRequest.

[ianbjacobs]

Hi @adrianhopebailie,

I also thought of the #173 discussion but I don't think it's the same set of issues. I think 173 is about the display and communication of default instruments, whereas the current proposal implies there is no display (and thus no user selection). The payment handler is launched automatically.

Ian