Web Payments WG

16 May 2019



Ian Jacobs (W3C), Rouslan Solomakhin (Google), Fawad Nisar (Discover), David Benoit (Reach), Dean Ezra (Barclays), Laura Townsend (MAG), Matt Detert (MAG), Michel Weksler (Airbnb), Tony England (Bank of America), Ken Mealey (American Express), Alex Liu (Airbnb), Florent Lambert (Lyra Networks), Danny Russell (Worldpay), Adrian Hope-Bailie (Coil)



Alex: New from Airbnb
... Previously did some work on payment request API demo at Money 20/20 a couple of years ago

Review of use cases draft

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

Recurring payments

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


<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

Identity across payment methods

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


(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

Next meeting

30 May

Summary of Action Items

[NEW] ACTION: Danny to add a use case / review use cases.
[NEW] ACTION: David Benoit to craft a use case
[NEW] ACTION: Ian to add to the wiki the general topic of returning to a payment handler after PR API complete()
[NEW] ACTION: Ian to discuss with the WPSIG chairs moving identity topic to that agenda
[NEW] ACTION: Rouslan to add that note to the wiki
[NEW] ACTION: Rouslan to write up use case he has in mind

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/05/16 16:21:39 $