Revisiting Payment Method specific filter/capability matching

[ianbjacobs]

Hi all,

At yesterday's meeting [1] we returned to the question of whether matching of payment method specific filters/capabilities happens in the user agent or the payment app. There were two topics:

• How capabilities are identified (in data from the merchant)
• Where matching takes place.

This issue is (for now at least) about the latter.

I think there is consensus that Payment Request API should indicate in relevant algorithms THAT additional matching can take place according to payment method. I anticipate that PR API will not say WHERE matching takes place (user agent or payment app).

The current Payment Handler spec supports registration of payment app capabilities with the user agent with, I believe, the assumption that the user agent will do the matching. There are pros to this approach, including:

• Payment apps don't have to implement matching
• Payment apps do not learn about users transactions until selected by the user

There are also cons to this approach:

• Simple string matching may not be adequate to address some use cases
• Payment apps may not want to share user data with user agents
• There may be challenges to keeping registration data up-to-date, especially if there
  are multiple instances of the payment handler (on different devices) that need to be updated.

After FPWD, I would like the payment apps task force to revisit this question of matching
to see whether we still wish to put forward an approach where matching is implemented
by the user agent, or more of a canMakePayment() approach where the payment app
returns a boolean (and where we are sensitive to privacy issues).

Ian

P.S. I started a new issue but this is also a continuation of some parts of the
closed issue 96
#96

[1] https://www.w3.org/2017/05/11-wpwg-minutes.html#item02

[rsolomakhin]

After discussing this with @zkoch, I'm starting to lean toward the .canMakePayment() approach for the payment handler to perform the filtering. The user should have ability to avoid this call either via user agent setting or by entering private browsing mode. This alleviates the concern about leaking sensitive information to the payment handler before selection.

Note that the user must install the payment handler first before the handler is able to receive the .canMakePayment() call. This indicates elevated trust on the part of user, which also alleviates the privacy concern somewhat.

[ianbjacobs]

@rsolomakhin, thank you for the follow-up from yesterday's call. In terms of the spec, this suggests the following sorts of changes:

• In the PaymentInstrument dictionary, replace "capabilities" with a canMakePayment() method
  (and defining it).
• Including either a requirement or a strongly worded suggestion that the user agent provide
  a means for the user to disable the method. (Would the method definition include a "disabled"
  status, or would that status be determined through some other means?)
• Similarly, it could be useful to have an "undefined" state --no canMakePayment() method
  for the instrument-- which would mean "therefore matches any merchant-provided filters."
  Or perhaps something similar; we should discuss behavior in this case, as some payment
  apps may not wish or need to define this method.
• Updating explanatory text and examples accordingly

Anything else you would add to this list?

Ian

[rsolomakhin]

This sounds good with minor corrections of a few details.

• Dictionaries cannot have methods, so "canMakePayment" would be better as an event. This event would behave similar to the existing "paymentrequest" event.
• When the "canMakePayment" event is disabled, I expect it to be not fired at all. Therefore, the event handler itself does not have a notion of being "disabled", because that information is external to the event handler. Nevertheless, the spec should mention disabling the event through settings and/or private browsing mode.
• I agree that "canMakePayment" event handler should be optional. If the payment app does not have this event handler, then the browser should always show the payment app when its payment method is requested.

[ianbjacobs]

@rsolomakhin, you wrote "If the payment app does not have this event handler, then the browser should always show the payment app when its payment method is requested."

In summary (I hope):

• For each PMI in intersection of supportedMethods and all registered enabledMethods:
  • If there is no canMakePayment() event handler, return true.
    Note: This might be because it has been disabled, or because it has not been provided.
  • If there is a canMakePayment() event handler, run it to determine the result.

Does that sound right?

Ian

[rsolomakhin]

This sounds like a good algorithm for PaymentRequest.canMakePayment(). Let's start using the language of "canMakePayment event" for the registered payment handlers to avoid confusion with PaymentRequest API.

Edit: s/confusion with PaymentHandler API/confusion with PaymentRequest API/

[ianbjacobs]

My expectation is that Payment Handler API would say "You know that open-ended language about matching in PR API? Here's what it means for implementations of Payment Handler API...." That is: we would not modify PR API directly.

Ian

[rsolomakhin]

I will send a PR for this.

[rsolomakhin]

The proposal is in pull request #170.

[ianbjacobs]

Discussed on 29 August [1]. There are two threads at this point:

• Continue discussions about whether static registration v. canHandlePaymentEvent
• Continue discussion about whether payment app filtering is necessary at all
  Ian

[1] https://www.w3.org/2017/08/29-apps-minutes.html#item04

[ianbjacobs]

I am closing this issues in light of the merging of pull request #170 and documentation about matching in Payment Method Good Practice:
https://github.com/w3c/payment-request-info/wiki/PaymentMethodPractice#canmakepaymentevent-implementation

Ian