This relates to the question of the network identifier list. If we do not need to approve string values because there is a general-purpose matching algorithm for basic card then we don't need the list.
Privacy consideration regarding line items; see issue 446 and proposal from AdrianHB that we proactively "discourage using this for shopping cart lists. As soon as this list goes beyond 5 - 10 items the UI challenges, especially on mobile, will become nasty."
Payment Apps
State of support for payment apps/handlers in browsers for use in demos at f2f
Testing update
Stan to tell us about his progress
What information do we need about test suites in order to inform a discussion at the FTF meeting about PR API advancing to CR?
Addition of "cb" to list of approved networks
Proposed:
We adopt a procedure for validating requests to be added to the list (cf proposal to add cb). Validation will consist of avoiding duplication.
We update the explanation in the network id list to make clear that approval does not imply interoperable implementation in browsers.
We add a statement that merchants may use Payment Request API for a card network that is not yet in the list; the list is only used for further filtering.