Re: FYI: First Public Working Draft of Web Payments Use Cases

Manu Sporny wrote:
> This is an official response to your comments on the Web Payments Use
> Cases document from one of the document editors.

>>> payment scheme
> This is a term of art in the banking / payments industry:
> https://en.wikipedia.org/wiki/Card_scheme

No, it isn't. That's a Wikipedia article written by random people.
It's missing the "warning this article has no citations", but it does
have "this is a stub" -- and it has no citations.

> Would you prefer something like 'payment network rules'?

MasterCard Payment Card FAQs [1] says:
>> Q: What are “three-party” and “four-party” payment systems?

So, that's apparently the right terminology (I was hoping you'd do
that research for me...).

> There is now a Boleto use case here:
> https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#uc-invoices

:)

> Pay-later use cases are covered via the "Invoices" use case, IMHO.

As a North American, I'd agree. But, not being someone from South
America, it's hard for me to know if people there would agree /
recognize it. There are all sorts of weird properties to Boletos.

> Is there specific language that you'd like to see in the spec?

I didn't have any in mind. I'm just regurgitating an odd system that I
learned about and which seemed like something worth noting.

> I added a link to Wikipedia to anchor it as I imagine that'll be
> around as long as archive.org.
>
> https://github.com/w3c/webpayments-ig/commit/8426cc75570bd628a9813a77780c2db3575ea1ed

The problem with Wikipedia is that it evolves/gets reorganized/has
people decide "not actually notable", deletes things, moves things,
and people don't care about external references (they barely care
about internal references), which is why I prefer web.archive.org
links.

This isn't a "formal objection", but it is why I find them to be a
poor choice -- something to consider.

>>> 3.1 Negotiation of Payment Terms Application of Marketing
>>> Elements. The payer discovers and applies any loyalty programs,
>>> coupons, and other special offers to the payment terms.
>>
>>> 4.1 Negotiation of Purchase Terms Application of Marketing
>>> Elements: As Jill prepares to check out, PayToParty offers her a
>>> discount of 10% if she uses the store's loyalty card to pay.
>>
>> There's a mismatch here. In 3.1 you used the word `applies`. Here,
>> you use the word `offers`.
>
> The payee is offering a discount if a loyalty card is used.
>
> The payer chooses to take advantage of the discount offer by applying
> her loyalty card to the payment terms, thus lowering the final price.
>
> I think it's right, does the above make sense to you?

I'd claim that the card is either a (House) Charge Card (referenced
elsewhere), or a (Branded) Reloadable Prepaid Card, that happens to
have rewards. The key is that it's first and foremost a Credit or
Prepaid Card and secondarily a Branded Card with some Rewards system.

>>> Seth participates in a loyalty program with his local grocery
>>> store and can apply a variety of digital coupons when he visits
>>> the store. Is a loyalty card a payment instrument, or a
>>> credential?
>>
>> A loyalty card is the wrong payment instrument. This is a store
>> Charge Card...
>
> Some organizations bundle the store charge card with the loyalty
> features (it's a two-in-one card). The question is more of a technical
> ask: Do we want to model non-payment instrument cards as credentials? If
> we do, how do we model cards that are both payment instruments and
> things that contain other information (like stored coupons)?
>
> I don't think the answer can be as simple as what you express above
> because there are store charge cards that are also loyalty cards. The
> problem may be with the terminology "loyalty card", as I expect most
> everyone has slightly different definitions of what that is and isn't.

Yeah, as with the previous complaint, my issue is that they're not
loyalty cards first and foremost if they have a Balance.

The Sears house card (now Discover) was not seen as a "loyalty card",
it was a Charge card. The same applies to a Jewelry store credit card
(I know people who have such cards, you have to apply to get *credit*
for them), or a Car Sales card, they're credit cards that happen to
include incentives.

>>> David wants to be able to manually arrange available payment
>>> instruments when they are presented to him. Why does this need to
>>> be standardized? Isn't this just a part of the wallet UI?
>>
>> If I need to split a payment across three payment instruments...
>
> That's not what this question is asking. The statement has to do with a
> UI that allows the person to put their preferred card "on the top of the
> stack" of cards that show up when they go to pay for something.
>
> Splitting a payment across three payment instruments is something that
> may require 3 round trips with the current architecture (as it's a
> corner case based on the sheer number of transactions that clear using a
> single payment instrument).

OK, so, I'd suggest you add splitting as a UC.

If that isn't what's being suggested, then I think I agree w/ you that
it's a QoI UX detail, as with the one below

>> This should be done by the UA using frecency [7].
>
> Agreed, but this document is about use cases, not solutions to use cases.

> Yes, and yet we have Apple Pay and an increasing number of fingerprint
> scanners going into many of the new high-end mobile phones.

And an insane credit card network encouraging facial scans using
twitter or something.
Sometimes we need to actively discourage insanity.

> Biometric two-factor is a thing, so we have to mention it in the use
> cases document, even if some of us don't think it's a good idea.

>> Defeating scanners is a fairly standard thing, which has been done
>> for decades. Roughly, any technology that encodes based on something
>> that is measurably you makes it fairly easy for someone to measure,
>> record, and reproduce for the purposes of claiming to be you.
>
> True, but it cuts down on opportunistic fraud, which is primarily what
> this sort of technology is intended to do.

Increasing risk to life and limb isn't the way to go.
Chip+Signature + tokenized transactions should cut down fraud significantly.
The biggest problem left is that users need a way to chip+signature
their online payments. I'm hoping Square or similar will save us by
offering readers to everyone :).

> Yes, but the fingerprint for a low-value transaction is better at
> protecting against opportunistic fraud than say, swiping a plastic card
> that doesn't belong to you (credit cards in the USA).

No. It really isn't. Because that fingerprint will be stolen just like
the magstripe.
Plastic swiping will be mostly gone by the end of the year in the USA
(credit liability shift [2]).

> Counterpoint, randomly generated text that must be recited, analyzed by
> a deep learning / neural feedback network:
>
> http://www.ted.com/talks/jeremy_howard_the_wonderful_and_terrifying_implications_of_computers_that_can_learn?language=en

Response: one of the Mission Impossible movies where they generate an
actual voice system.
Or just look at how Dragon Dictate and friends work classically.

> This use case is about accessibility. I don't expect there will be many
> payment instruments with biometric two-factor that will be effective
> against kidnapping, face transplants, or decapitation. Those aren't the
> attacks biometric two-factor are intended to solve.

Law of unintended consequences. Exploding ATMs [3] [4].

> Is there a specific spec text change that you'd like to see here?

Ask me about this in response and I'll think about it later (not for a
week I'd imagine).

> "Standardized, machine-readable electronic receipts could make it easier
> to track expenses, prove that certain purchases were made, file tax
> returns, and simplify management of unnecessary paper."
>
> https://github.com/w3c/webpayments-ig/commit/8be538745b5891cfc3071491dd45f1a9220f7976

I'd drop "could"

>>> Bongani reserves a bus ticket online using his mobile phone. At
>>> the bus terminal he taps his phone to a kiosk and receives a
>>> printed physical receipt that he can use on the bus.
> This is a use case from South Africa, where some buses still rely on
> physical tickets, but you can buy them electronically.

OK, I'm only objecting to the idea that these are `new` things.

> apologies for the delay in getting to your comments.

no worries (en-au)

> It took a while to go through your extensive set of suggestions and apply
> the ones that I could.

> Let me know if you disagree with any of the changes of you see any more issues
> that you'd like to have corrected.

[1] http://www.mastercard.com/us/company/en/docs/Payment_Card_FAQs.pdf
[2] http://blogs.wsj.com/corporate-intelligence/2014/02/06/october-2015-the-end-of-the-swipe-and-sign-credit-card/
[3] https://www.schneier.com/blog/archives/2006/03/blowing_up_atm.html
[4] http://krebsonsecurity.com/2014/12/more-on-wiretapping-atm-skimmers/

Received on Saturday, 4 July 2015 00:06:47 UTC