Alex: New from Airbnb
... Previously did some work on payment request API demo at
Money 20/20 a couple of years ago
[Ian reviews the use cases draft.]
IJ: Anybody look this over?
<Zakim> rouslan, you wanted to talk about the loneliness of the guest checkout use case.
rouslan: Some use cases are bullets, others titles.
IJ: I expect to become more consistent as we get more data; also useful to compare with the use cases document created by the Web Payments IG.
<dannywp> the doc looks great
IJ: What would you add?
rouslan: Guest check out would
jump out at me as primary use case.
... but from my experience, web sites want to connect to
payment handlers
... when you go to EBay, you have to click on PayPal button
every time
... it's the same if you are using Google Pay to pay for uber
or lyft
... it shows the google pay payment sheet even though those
apps probably can save and reuse tokens
<dannywp> +1
dannywp: +1 that this is a use
case
... I think a key use cases is to help sites not have to use
card-on-file
... I think a key use cases is streamlining checkout for a
known customer
benoit: I'd like to echo that
sentiment as well. Would be valuable to make the checkout
process for a guest or someone who does not want to share info
with a merchant
... as seamless and as easy as someone who has a long-term
relationship with a merchant
IJ: Got a concrete use case?
<dannywp> +q
benoit: there's a privacy
story
... e.g., due to GDPR, someone may not want information stored
forever.
... there is a merchant story as well, but need to balance with
consumers and regulatory frameworks
dannywp: Where you might get more
traction is a merchant privacy/compliance story
... we've heard from merchants about owning the experience and
branding, but through some of the new payment methods merchants
can offload PCI burden
... so not just a consumer issue but lowers merchant
burden
... as soon as you go to card on file, there are new
liabilities, encryption requirements, etc.
... so there's a benefit of streamlining without the merchant
burden
lte: I would agree with
everything that's been said from both merchant and consumer
perspective
... another use case: if I am going to a one-time merchant I
have no desire to continue to have my personal info stored at a
1-time merchant
<benoit> +1
lte: the merchant story is a good one..the merchant can still have relationship with consumer through PAR or other mechanism (if tokens used)
mweksler: +1 to guest checkout,
but I'm also curious about some of the concrete use cases like
Uber + google pay
... I think there it's a case where there is some relationship
between the user and the merchant
... what is your goal, rouslan for this use case?
rouslan: I'd like to leave this
choice to the merchant
... maybe they want to store the token or maybe they want to
see whether the consumer will trust interactions with merchant
if the sheet comes up multiple times + SCA
... I want to enable the merchant to experience
mweksler: I hear two options:
a) Merchant can do things seamlessly (card on file)
b) Merchant can double check with the user where may be "less seamless" but maybe more trust
scribe: but in both cases, seems
merchant needs to keep something on file.
... how is that different from what we have today
rouslan: I'm trying to capture what we have today
<scribe> ACTION: Rouslan to write up use case he has in mind
ACTION: David Benoit to craft a use case<scribe> ACTION: Danny to add a use case / review use cases.
IJ: Seems out of scope since no UX
<Zakim> rouslan, you wanted to talk about recurring and UI
rouslan: I think it's not 100%
out of scope. One of the other items on the list is customized
buttons. Today it's just "PAY" but maybe we want to give the
merchant the ability to say "SUBSCRIBE."
... same flow but slightly different UI to accommodate this use
case.
<scribe> ACTION: Rouslan to add that note to the wiki
lte: I think the comment about
not having to get consent for recurring payments is not
entirely correct.
... there is a point in time when consent expires.
IJ: Would PR API be a good fit for that additional consent?
lte: I don't have a good sense.
<Zakim> rouslan, you wanted to talk about PR
rouslan: I think PR API COULD
work here. Essentially, the payment handler would provide, say,
a 3-month token
... and after 3 months, the site would ask the user to return
to the payment handler.
... and perhaps the payment handler would reauthorize the
token
lte: That SEEMS logical.
... the merchant would prompt the user to do something.
mweksler: I'm curious about rouslan's point. Are you talking about a proposal or this how tokens work?
<dannywp> +q
mweksler: the reason I ask is
that there are plenty of merchants (including Airbnb) that rely
on card-on-file
... one premise is that there's a nice UI; you include
authorization in UI you have already
... in some countries, people like the UX to authorize every
payment.
... in other reasons, people are fine with COF
... with SCA there is potentially more work to authorize a
transaction
<dannywp> can i answer how it works in the existing card world
rouslan: Good question. I think PR API can be used to refresh a token
dannywp: There are two ways. If you have an existing COF transaction on a recurring payment, you have a way to ensure there's not been a stop on a payment
[michel discusses "recurring" v "card on file"]
dannywp: I think you can still
account updater for COF
... The SCA mandate will affect the UX
... open banking is explicitly limiting how frequently you can
charge, amounts, etc.
... so rouslan's suggestion is a good one
lte: The use case I was thinking
of : I have a period of time when you can try out something,
and when that period ends, I want to be sure the user is
comfortable continuing
... end of a trial period; needs to reauthorize
https://w3c.github.io/webpayments-methods-tokenization/index.html#token-cryptogram
<Zakim> rouslan, you wanted to ask whether this could be used when the card on file is about to expire?
rouslan: Credit cards expire. When a card is about to expire, could we do something?
dannywp: Merchants can send in old card number and get new one without user interaction
mweksler: It is very
effective
... I think tokenization in the future provides a better form
of abstraction
<scribe> ACTION: Ian to add to the wiki the general topic of returning to a payment handler after PR API complete()
<mweksler> +1 on more details about returning to payments handler
benoit: You mentioned an "ideal
state" related to updater. I have never understood where: when
I have a relationship with the merchant to "bill me"...the
relationships today are between merchant and "my card."
... I would rather have the merchant "bill me" or "bill my
account"
... and the account reference should not matter to the
merchant
<dannywp> I can answer that one
<matt_d> That would be ACH.
benoit: I want a "credit card
transaction" but to abstract so that the relationship is not
'with the card'
... I want an identity that is related to me authorizing uber
to bill me and they can bill me forever until I revoke.
<Tony> Comment. RTP request for payment
mweksler: I think the ideal state
is interesting, but would abstract beyond credit cards
... this is a personal identity topic
... there are general patterns in this direction
... going from payment to identity
... and other people want the opposite (anonymity in
interactions)
... common tension between convenience and
security/privacy
... we need to provide some options / flexibility
... for different customer experiences
[Adrian arrives]
dannywp: I think the EMVCo PAR
intends to address some of this
... the original intent of network tokens was to have a token
be domain-controlled per merchant
tony: When we talk about identity
v. card, real time payments (RTP) ... the consumer owns this
and we should try to flesh this out
... we'd like to get a working RTP prototype in the payment
handler
... PAR is another interesting topic for omni-channel use
cases
https://w3c.github.io/webpayments-methods-tokenization/index.html#tokenizedcardresponse-dictionary
(includes PAR)
IJ: Should we explore identity across payment methods?
<Tony> https://developer.visa.com/capabilities/visa-par-inquiry
David: I think it would be interesting to discuss this
IJ: Might be good for WPSIG discussion
rouslan: I'd like to hear more about this; but don't think part of PR API
<Zakim> AdrianHB, you wanted to ask if recurring payments and identity are necessarily linked (i.e. PAR is identity but tokens, used of recurring payments, are not) if we have time
AdrianHB: Are we talking about PAR for recurring payments only?
<mweksler> +1 on exploring identity across payment methods, agreed with Rouslan that it might not be part of PR API
Tony: PAR is not a financial instrument
<AdrianHB> +1 on identity thing (maybe not in WG)
<AdrianHB> (also notes that identity is a key part of SRC)
<rouslan> +1 to suggest to the other group
<mweksler> +1
<scribe> ACTION: Ian to discuss with the WPSIG chairs moving identity topic to that agenda
30 May