https://github.com/w3c/payment-request/wiki/PushPayments
https://github.com/w3c/payment-handler/issues/314
<Danny_WP> I can speak to this as well
Danny_WP: I have worked in the
clearing system at Worldpay, so working out card types was part
of the job description
... let's consider Mastercard as an example
... Maestro has three entries: "maestro", "debit", and
"credit"
... so this means a card could be used in a variety of
contexts, and might be processed on different rails
... we have a brand priority type
... that's how we manage it
... I agree it's difficult. Visa and MC publish BIN tables,
updated daily
... the fall-through approach can potentially create
issues.
stpeter: That's helpful.
Jonathan: We publish daily the list of BIN tables so you can determine whether a range belongs to debit/credit
nicktr: What Danny is talking
about, that complex process does not happen in real time
... there's an accepting up front, and then another card
qualification process during clearing
... so there's a mismatch between the existing system and being
able to qualify the product in real-time
jonathan: I think it corresponds
to the frequency of the BIN update
... merchants access the APIs typically through their
acquirers
IJ: So are network and type the right vocabulary?
stpeter: Two reasons to have
this: (1) matching (2) modifiers
... that is different information in different scenarios
... In terms of next steps, it seems to me that we may need to
look at the use cases. Are our expectations still appropriate
given the data we have?
... maybe we don't make deterministic promises and move on.
<AdrianHB> +1 - not sure expectations are realistic given that info is not available to reliably provide consistent behaviour
nickTR: The point I was trying to
make on GitHub is that this is a problem that exists today,
even with information that exists today
... it might be accepted in real-time and then spat out in
clearing
... I think in 80-90% of cases you're in a reasonable good
place.
stpeter: If we are going to do
modifier things based on card type...that has implications for
the total
... that is a bigger issue
<Zakim> AdrianHB, you wanted to ask about modifiers (apologies for background noise)
AdrianHB: With regards to
modifiers, I wonder if the onus lies with the merchant for
cards
... if they use modifiers
... if as a merchant I provide different pricing based on card
type, if I'm doing that in the knowledge that the information
from the payment handler may not be complete, I would say I
would be unlikely to use modifiers based on that
characteristic
... as a merchant, the last thing I want is for the user to be
shown one price, but when I get the card I think it's a
different type and therefore say "no, the price is X+10"
... so my inclination is that if this doesn't work
consistently, merchants won't use it.
IJ: What is the scale of inaccuracy?
Danny: the overwhelming majority
of merchants accept credit and debit
... the overwhelming majority that accepts both gets it right
all the time
... the number that accept one type but not the other is a
fraction of a fraction
<AdrianHB> What is our experience wrt merchants charging differently? Is this done a lot?
Danny: Different totals for different types is now banned in Europe
<nicktr> Answer varies by market
<AdrianHB> Do merchants explicitly submit the transaction with different amounts in this case?
<AdrianHB> Or leave to acquirer?
<AdrianHB> I assume the former
<Danny_WP> They would submit a different amount
<scribe> ACTION: Ian to follow up with Stripe on questions from this call
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
<scribe> ACTION: Krystian to look into how different totals are managed
<trackbot> Created ACTION-103 - Look into how different totals are managed [on Krystian Czesak - due 2018-08-30].
<nicktr> As Danny says, card surcharging regulated in EUmarket now
https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
<krystian> +1 on a global requestBillingAddress
<AdrianHB> +1 on making it top-level
nickTR: +1 to global option
<Danny_WP> +1
<AdrianHB> Some work to do on interactions with payment handlers though
<stpeter> +1 to global (despite lingering concerns about address verification scenarios)
<stpeter> link to Adam Solove's comment: https://github.com/w3c/payment-request/pull/749#issuecomment-415198844
https://github.com/w3c/webpayments/wiki/FTF-Oct2018#agenda
https://github.com/w3c/webpayments/wiki/FTF-Oct2018#objectives
nickTR: Objectives are in five buckets
1. Advance core payment request, payment method identifiers specifications to PR
scribe: thanks to those working
to resolve issues before TPAC
... we'll do this early on day 1
... ideally we leave TPAc with a short timeline to a call for
consensus to get to PR
2. Payment handler spec
3. Assess and promote group health
scribe: should we have a primer
session in advance?
... opportunity to raise issues (technical or process)
... I'm conscious that we have a large number of orgs in the
group but load is being carried by a small group
... how do we broaden participation
4. Card network security
scribe: tokenization and 3DS
5. Fostering industry adoption
https://www.w3.org/2018/08/worldpay.html
<nicktr> Ian: please sign up to help us organise sessions
<nicktr> Ian: Adam Powers (formerly CTO at FIDO) now w3 staff
<nicktr> ...I asked if he'd help on the authentication session
<nicktr> ...we may have to rearrange to get the web Auth working group to be able to join
<nicktr> ...and trying to get update from browser vendors on authentication
<nicktr> Ian: any other topics?
https://github.com/w3c/webpayments/wiki/Web-Payments-API:-Brand-Analysis
<nicktr> ...as fyi we have brand analysis in development by Heath, who is Facebook's contractor
<nicktr> ...goal is to have something to review at TPAC
<nicktr> Ian: typically things in the browser have a consistent look and feel. When you hit 'buy' , the experience need to synthesise both merchant and browser brands
<nicktr> ...this seems to be highly unusual
<nicktr> ...more to come at TPAC
<nicktr> Who is registered https://www.w3.org/2002/09/wbs/35125/TPAC2018/registrants#WebPay
6 September