Browser as Aggregator of Card Metadata is bad idea about src HOT 4 OPEN

Hi @adrianhopebailie,

It is my expectation that any payment method that we will design will be implementable by any ("authorized") payment handler. Whether a browser vendor makes a business decision to implement the payment method natively is up to them.

I think we should close this issue.

Ian

from src.

Aggregation of payment instruments could be generalized beyond SRC. This is merely showing how, a user must have a choice to select the list of instruments (across all payment methods, and all payment handlers). The choice of how to consolidate the instruments can be defined at a standard level (in one of two ways):

1. Let user agent define the aggregation rules and ordering rules (e.g. group instruments by payment handlers, sort by timestamps, etc).
2. Define payment instrument ordering rules

I think based on past precedence in this group, I'd think #1 is ok where UA defines what the rules are. Also, this flow was optional as I understood for UAs to support.

from src.

@jalpeshatvisa said:

Aggregation of payment instruments could be generalized beyond SRC.

This suggest that the answer to my question:

Will the interface between the browser and the SRC Systems be standardized by the WG?

is yes but not just for SRC? Is that a correct interpretation? This sounds like what we have already defined (in the past) during the payment handler enrolment flow.

from src.

from src.