Browser as Aggregator of Card Metadata is bad idea

[adrianhopebailie]

The flow diagrams show 3 possible implementations of SRC using PR an PH API.

The 2nd flow titled "Flow Diagram with Browser as Aggregator of Card Metadata" is a poor approach and would lead to endless interoperability issues if implemented.

The requirement for browsers to bind themselves to a closed and proprietary ecosystem so tightly is unprecedented and makes then forever beholden on changes to that ecosystem over which they have no control.

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

If so, can other systems use the same interfaces to register their non-card instruments with the browser?

Or, will cards always be surfaced on the payment sheet as a priority over other instruments which must be aggregated behind a payment handler?

We have agonized in the group over issues related to prioritization and ordering of payment methods and display of payment instruments. This approach appears to segregate things into non-SRC payments which are subject to the user-centric rules the WG has defined, and SRC payments where the ordering and priority is imposed on the browser by SRC Systems or, at best, defined outside the WG.

I would advise those working on this integration to abandon this option asap.

If there is a desire to surface instrument level detail on the payment sheet this can be done via PH registration as had been discussed in the PH task force previously.

[ianbjacobs]

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

[jalpeshatvisa]

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.

[adrianhopebailie]

@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.

[jalpeshatvisa]

Browser interfaces with payment handlers, which in turn has payment instruments. The proposal is to aggregation payment instruments for SRC, but there is no reason to limit this to SRC. That leads to a UX where, on consumer selection of instrument-X, browser redirects the user to corresponding payment handler.

From: Adrian Hope-Bailie notifications@github.com Reply-To: w3c/src reply@reply.github.com Date: Friday, May 10, 2019 at 11:34 AM To: w3c/src src@noreply.github.com Cc: "Chitalia, Jalpesh" jchitali@visa.com, Mention mention@noreply.github.com Subject: Re: [w3c/src] Browser as Aggregator of Card Metadata is bad idea (#1)

@jalpeshatvisahttps://github.com/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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/src/issues/1#issuecomment-491389257, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALJLC3UIG5XNEKUGSXYU5FTPUW5Z3ANCNFSM4GKGIKVA.