<scribe> Scribe: Ian
nicktr: We are not numerous today but I'm keen that we continue to check in on the group's priorities
[Nick's candidate list]
<nicktr> 1> Getting to recommendation
(PR API 1.0)
<nicktr> 2> working through merchant feedback and getting greater merchant adoption
<nicktr> 3> getting another browser to support handler (without which we can't get to CR, I believe)
<nicktr> 4> continuing to experiment with SRC
Ian: +1 to those, and I would add some improvements to Basic Card. But those are lower priority!
<Zakim> rouslan, you wanted to ask about Edge and (3)
rouslan: For browser support of PH API; what is expectation about Edge as a separate browser (even if they use chromium engine).
IJ: That's up to the Director; I imagine it depends on how much individual effort is required to make use of the API in their browser.
danyao: Our takeaway from the FTF
was that we want to work on payment handler adoption.
... so what do you see as barriers to adoption?
nicktr: I want to tease apart a
few topics: (1) what we heard about PR API/PH API and (2) what
we heard about specific payment methods such as SRC
... we need to continue to make clear that PR API is not just
an enabler for any single payment method.
... I think control of the payment experience is something that
is critical for larger merchants
... I think the basic card implementation in particular is
super useful for small merchants, but, for large merchants with
sophisticated checkouts and multiple payment methods, and where
things like ordering are important, ....
... ensuring that larger merchants have the control they need
for the payment experience
... I think that you are correct that "more payment handlers"
is part of the answer.
<nicktr> scribenick: nicktr
ij: previously, we learned UX is an issue (from the Shopify PoC)
<Ian> https://www.w3.org/2019/04/03-wpwg-minutes.html#item03
ij: merchants want lots of control over look and feel
<Ian> 1) user experience
<Ian> 2) payment methods
<Ian> 3) control over ux
<Ian> 4) flexibility in timing of gathering data
<Ian> 5) more sophisticated capabilities
danyao: difficult to integrate PR with existing payment experience, and
<Ian> Danyao: I hear 2 classes of feedback: (1) no easy fallback path integration (2) hard to compare conversion rate between PR API and fallback
<Ian> scribenick: Ian
Danyao: Walmart and BB mentioned they want more control over the UX...that sounds to me like they don't see a lot of value in the API...what they described can be accomplished through traditional forms.
(Ian largely agrees with that observation)
Danyao: Value of PR API goes down if focus is on card-on-file use cases
<Zakim> AdrianHB, you wanted to ask if we can easily cater for tier 1 merchants AND long tail or if we should focus on one or the other to start
AdrianHB: I agree with Danyao's
comments. We are getting interesting feedback from large
merchants, but I think our goals may not in the end lead us to
target large merchants.
... I think PR API is more well-suited to the long-table
... and we may not be able to design for both
... e.g., decomposable API might be more suited to large
merchants.
... so as a group we may want to determine more clearly our
target
rouslan: I think we should focus on the first principle of excellent UX and excellent security for users
<AdrianHB> +1
<AdrianHB> ian: I like Danyao's characterization on the flexibility on timing and gathering of data
<AdrianHB> ... Dee's statement to the effect of "we've solved these problems" surprised me
<AdrianHB> ... but the use of forms and auto-fill does seem to already give them what they need
<AdrianHB> ... perhaps where we can focus is on better fallback between PR API and other checkout
IJ: +1 to focus on connection between fallback and PR API experience.
<Zakim> nicktr, you wanted to ask about focus on long tail
<scribe> scribenick: Ian
nicktr: I am really torn between getting big merchant adoption (to get traction) and agreeing with the long-tail focus
danyao: I actually agree with
AHB's statement that maybe PR API provides more value to long
tail and +1 to make that our merchant adoption focus
... do we have consensus on that?
... and how does that affect the browser implementation
agenda?
<AdrianHB> If we do focus on long tail we accept that getting adoption will be harder
<Zakim> rouslan, you wanted to mention long tail priorities
rouslan: This is an excellent point, Danyao. If we look at the long tail we might change our priorities.
<AdrianHB> The flip side of that is, if we focus on tier 1 merchants then we have a lot of changes required in the API to get adoption
rouslan: We are seeing interest
from smaller merchants and smaller payment handler developers
and may need more ergonomic APIs
... so that's one area where we could prioritize
... if there were only 2 payment handlers, that would lead to
one type of support
... but if there are 1000, that means we need to put more care
into things like error messages
<danyao> +1 to all of that
<AdrianHB> I think the long tail of merchants could be serviced by a small set of handlers
IJ: Other possible driver of adoption - SRC
Danyao: I think our short-term
priorities are aligned. We are working with Google Pay re:
ergonomics and also looking to bring in more payment apps and
learn from that
... I would like to have some additional time to talk about an
SRC payment method
<Zakim> danyao, you wanted to talk about SRC
<scribe> scribenick: nicktr
<scribe> scribenick: nicktr
IJ: I think that SRC may be
several years to reach full adoption
... So I think Basic Card remains relevant and improvements
based on feedback
... would be a good thing
... as to the similarities between SRC and basic card
... I think that SRC has more complex contractual/financial
relationships
... so whereas basic card is just a data storage thing
<Ian> Danyao: I wasn't proposing to jettison basic card. I was surprised to see an SRC data model ... similar to basic card.
<scribe> scribenick: Ian
UNKNOWN_SPEAKER: I was especially
surprised to see supportedNetworks
... it sounds like SRC will have similar network "silos"
danyao: Merchants talk about a
"capabilities" idea; they want to mix and match capabilities
instead of bundling in a payment method.
... I understand the need to differentiate basic from src, but
does it need to be a different payment method?
<Zakim> rouslan, you wanted to ask whether gateway tokens should be standardized as a payment method
<AdrianHB> SRC should NOT have supportedNetworks. That is a wart on basic-card that is due to it's nature as an "open" payment method. The correct way to do this is for each network to have it's own payment method identifier. These can share a common data model and spec but they SHOULD be different
rouslan: Did any gateways talk about standardizing gateway tokens?
Ian: They said no.
nicktr: The SRC payload is very
different. There will not be a card number in SRC
... from an implementation perspective, keeping them separate
is the way I would go
<danyao> Thanks. Ack.
<AdrianHB> +1 to keeping them separate and deprecating basic card
<Zakim> AdrianHB, you wanted to comment on gateway tokens
AdrianHB: Something that occurred
to me re: gateway tokens; gateway token providers could just do
payment handlers and engage with merchants.
... I don't see a need for gateway token standardization
because of JIT registration
... and URL-based payment methods
nicktr: After this meeting, I will point people's attention to a candidate list
IJ: Could we spend a bit more time discussing / framing?
NickTR: Ok, let's return to this in the next call
<nicktr> https://github.com/w3c/src/wiki
<nicktr> scribenick:nicktr
ij: good demo at the F2F
... further discussion at the card security task force
... I took an action to write up
... URL, whitelist, blacklist, data model
... I tried to distinguish goals from from design
consideration
... Visa very keen to see default behavior to allow a
cardholder to pay
<Ian> Ian: I observe that browser offering a default when there is nothing else registered or specified is useful cross payment methods
<Ian> IJ: Brands said strongly they want a single payment method, but acceptance of different cards will still be the case (hence supportedNetworks)
<Ian> NickTR: I think I would still prefer one URI per SRC system
<AdrianHB> +1
<Zakim> AdrianHB, you wanted to comment on "single payment" method
<Ian> AdrianHB: I strongly support Nick's point
<Ian> ... SRC could be a single payment method, but the implementations are different (in different SRC systems)
<Ian> ...they need to have different identifiers
<Ian> ..they should use URLs for this
<AdrianHB> "Brands said strongly they want a single payment method" -> it is important that they can provide valid reasons for this
but the specification requires the registration of DCFs and SRCIs
(the SRC specification)
<Ian> AdrianHB: A card brand could still use a manifest and dynamically provide a default...to fulfill the "browser default role"
<Ian> nicktr: Next call..2 May