RE: [use cases] Re: Use Cases - editorial observations.

On 2015-03-31 you wrote:
>I'd argue that it's vague from a payment professional perspective in the same way that "If you want to stop the car,
>slam on the brakes" is vague to a mechanical engineer.

I'd counter argue that it's vague in the same way that "if you want to stop the car, slam your foot onto one of those things on the floor."

My problem is that I'm not sure what the difference between "immediately credited" and "funds will be swept" is.

I think "credited" means that they have (essentially) a receivable on the books which is reconciled later in the week.  I'm afraid that if it it's not clear to me it will be unclear to others.  Maybe stay away from the "two step" process and "accounts" entirely, since we're not really describing those.  So...

Completion of Transfer. Since Jill's PayToParty loyalty card operates as a credit card, PayToParty will receive the funds in their normal end of week settlement.

Best regards,
David

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com]
Sent: Tuesday, March 31, 2015 12:10 AM
To: public-webpayments-ig@w3.org
Subject: [use cases] Re: Use Cases - editorial observations.

On 03/29/2015 06:13 PM, David Ezell wrote:
> One overall comment (see a specific instance below) is that we should
> indicate where we think we need further review from external parties.
> This kind of tagging gives the clearest indication that we don't think
> we're finished yet.

I tried to sprinkle a couple of issues in the document to indicate some areas where we'd like further external review and comments:

https://github.com/w3c/webpayments-ig/commit/62eecafe430ca1a77f02d9885a65445938dd8b77

> _Section 3_
>
> "person, organization, or software agent)" - no need for the closing
> parenthesis.

Fixed through another review comment.

> "ACH and SEPA" - would add "For instance," before the sentence.

Used "In addition", as "For instance" sounds strange due to the use of "For example" in the previous sentence. The language is still a bit awkward.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> "regulatory block" - sounds like a useful term for "runtime exception
> caused by a regulatory infraction"

Are you requesting that we add this to the glossary?

> I'm not really comfortable with the implied ordinality of "first,
> second, third..." with regard to phases.

While I agree with the notion that we don't necessarily want to require that one phase must be performed before another phase, there aren't any flows that we have currently that don't fit into the "first, second third..." layout we have right now. We should discuss this on the use cases TF call.

In order to get rid of the "first, second, third..." ordinality, a payment flow that doesn't fit into that model should be presented. If we can't find one, that would be a pretty powerful statement in support of the current simplified model.

> _Section 3.1_
>
> "payer will be authenticated by the payee" I'm not sure the payee need
> directly to authenticate.

You're right, that bit has been reworded to:

"The payee may require the payer to authenticate themselves."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.2_
>
> "*Discovery of Accepted Schemes" -**I believe there is also a
> dependency on the "marketing elements" from 3.1: coupons or loyalty
> may or may not partially define the accepted schemes.*

Added something to the effect of "...which loyalty programs are acceptable".

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> *String "*The payee selects one or more payment instruments)/tref>"
> appears in FireFox.

Fixed in a previous review edit cycle.

> "The issuer of the payment instrument authenticates the payer" - this
> statement shows more or less what I was talking about in Section 3.1.
> I think someone else pointed out that "issuer" doesn't appear in the
> list under "Terminology".

We only mention "issuer" in the document once. Rather than add a term to the glossary for issuer, in the name of simplifying the document, I removed the instance where we used "issuer" in the document.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> "This authentication with the payment processor is distinct from any
> authentication required by the payee (e.g., a merchant verifying a
> password on a payer's user account)." - when do merchants do this?
> I'm not familiar with any public (as opposed to bespoke) payment
> systems that do this kind of thing.

I updated the text to remove the potential for misunderstanding what this statement was trying to say:

"a merchant verifying a password on a payer's user account when they login to the merchant website."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.3_
>
> Authorization of Transfer - it seems that the payee is the one that
> needs to be notified.

Fixed.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> Completion of Transfer - doesn't mention who gets notified.  I think
> it's payer and payee.  It seems that Completion of Transfer may be
> underspecified with regard to the mechanics.

Added some text to say who gets notified. I tried to specify the mechanics a bit more.

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> _Section 3.4_
>
> "Fouth phase" should be "fourth phase"

Fixed in a previous set of review comment edits.

> Delivery of Product - for some reason this doesn't seem as though it
> belongs.  Once processing has completed, the payee has an obligation
> to deliver goods, but it's not a process that we care about.

We care when a digital proof of payment may be required to access a digital good. Added this sentence to make it more clear why we're including this particular item:

"A digital proof of payment may be required to access the product."

https://github.com/w3c/webpayments-ig/commit/7a94bdafdc538875cbb659f5c7e84422e1ee4b1e

> *_Section 4.3_*
>
> I'm sure the team must have discussed the fact that there is no
> indication of "regulated agencies" in this example.  For instance,
> completion of transfer with such an addition would read:
>
> *Completion of Transfer*. Since Jill's PayToParty loyalty card
> operates as a credit card, the PayToParty */acquirer/* immediately
> credits PayToParty with the purchase amount and the funds will be
> moved from */the issuer bank/* into PayToParty's bank account at the
> end of the week. Jill will pay off the credit line */at her issuer
> bank/* at the end of the month.
>
> I'm not insisting that we use these terms, simply that without the
> entities clarified it seems very, very vague.

I'd argue that it's vague from a payment professional perspective in the same way that "If you want to stop the car, slam on the brakes" is vague to a mechanical engineer.

Most readers of the use case won't necessarily care about those details yet. To come at it another way - adding terms like 'acquirer' and 'issuer' will add heft to the document and will be difficult for non-payment professionals to grasp.

> (Note: it might be helpful in FPWD to have a way to say (like
> Wikipedia) "needs clarification", etc.)

Review comments usually say stuff like this when something needs clarification?

> _Section 6.2.2_
>
> Q: Is a loyalty card a payment instrument or a credential?
>
> A: Neither - it is an account identifier, closely related to a
> credential, but much more specific.  Payment instruments (normally)
> refer to more general things backed by regulation.

An account identifier can be a credential (per the Credential CG's definition of "credential"). Agreed that a payment instrument is probably a different beast than a loyalty card.

What about an "Amazon Visa Card"? Is that a loyalty card? You get discounts on Amazon when you use it, right? It's also a payment instrument.

> "David wants to be able to manually order available payment
> instruments when they are presented to him."  I agree this is part of
> the wallet UI, but I think we need to make statements about the UI
> with regard to Accessibility.

+1 - do you think we need to remove the question from the document?

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/

________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

Received on Tuesday, 31 March 2015 14:47:39 UTC