Should the payment mediator pass all payment method data to the payment app or just relevant data?

[adrianhopebailie]

Picked up from #154 where @ianbjacobs made the following assertion:

Once the user has chosen an app, the browser/mediator MUST NOT send more information than is necessary to the payment app for processing. The browser/mediator MUST NOT send the merchant's
full list of supported payment methods, or the optional data for irrelevant payment
methods.

[dlongley]

I think all data should be passed. For example, if a browser is acting as a mediator, a user may want to install a Payment App that, itself, acts as a mediator for other Payment Apps. In this scenario, a user wants to use a Web-based payment mediator for some set of payment methods, that provides them with some benefits.

In another scenario, a Payment App may provide N ways to pay -- and only once that Payment App has launched will the user actually decide which method to pay with, based on some other kinds of information (eg: budgeting/whatever) that the app provides for them.

[dlongley]

In another scenario (likely a future case), a Payment App may allow a user to pay with more than one payment method at a time for a single request.

[ianbjacobs]

@dlongley,

My expectation is that through the dialog between mediator and user, the user's selected payment app will receive all the information that it needs. In the case (which I expect to be common at least initially) of a payment app that supports a small number of payment methods, the payment will will receive less information...but still all the information that it needs. In the case you describe, it sounds like the payment app would receive more information as a result of the dialog.

So I still think that amounts to the payment app receiving "necessary" information but no more.

Ian

[dlongley]

@ianbjacobs,

My expectation is that through the dialog between mediator and user, the user's selected payment app will receive all the information that it needs. In the case (which I expect to be common at least initially) of a payment app that supports a small number of payment methods, the payment will will receive less information...but still all the information that it needs. In the case you describe, it sounds like the payment app would receive more information as a result of the dialog.

I don't think the mediator necessarily knows all of the information that the Payment App needs. I think the mediator's only purpose is to help a user pick the Payment App to send the payment request message to.

What about the case that you don't know you want to use two payment methods until you've gotten to your Payment App and found out that an account for a particular payment method has insufficient funds ... but another method could supplement to fulfill the request? And so on.

I think the mediator role should just be considered a router -- it shouldn't get more invasive/controlling than that.

[adrianhopebailie]

Raised priority as this has relevance to #15 and #154

i.e. if the mediator is going to alter the input data anyway then there is not a strong argument to pass a complete payment request into the API as a single parameter

[adrianhopebailie]

Discussed during call on 12 May awaiting proposals to demonstrate both cases

[ianbjacobs]

Migrated:
w3c/payment-handler#2