Comments on the Use Cases Draft

General comment.  Some terms in the document are linked back to their
definitions, and some are not.  Or rather, they are, but maybe not by
relying upon the automatic linking that ReSpec provides.  This means that
the terms are not “underlined” when they are formal terms.  When printing
the spec, that made it somewhat less clear.  Please use the standard
<a>term</a> convention so that ReSpec does its magic.

Introduction:

Both real and perceived has emdashes around it.  That’s fine, but I would
separate them from the text with spaces.

Paragraph 3 I would rewrite as:

The W3C Web Payments Interest Group is developing a roadmap for standards
to improve the interoperability of payments on the Web.  This will help achieve
greater interoperability among merchants and their customers, payment
providers, software vendors, mobile operators, and payment networks.  The
roadmap will include payment schemes
<https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html#dfn-payment_scheme>
in use today (such as electronic cheques, credit cards, direct debit, and
cryptocurrencies) and those of the future. The roadmap will be derived from
the use cases listed below.

Or something like that.

Section 1.2:

“Section 6 lists the use cases, short scenarios…”

Change to “Section 6 lists the use cases - short scenarios…”

Section 2:

Payment processor needs a noun.  Change to “Entity that submits and
processes payments using a…”

Section 3.2:

Discover of Accepted Schemes.  Content is duplicated.  Rewrite as “The
payer discovers the payments instruments that are accepted by the payee.”
 The second sentence is redundant.

Section 4.2:

Discover of Accepted Schemes:  Change “the PayToParty loyalty card and
PayPal” to “the PayToParty loyalty card, and PayPal”.

Section 4.3:

Completion of transfer.  Remove the last sentence.  It isn’t relevant.

Section 6:

Throughout the section.  The printed version of the use cases is formatted
completely differently than the online version.  The printed version is
REALLY hard to read.  Please try to use the same stylesheet.

Section 6.1.1.1

Hold Funds:

Exceptions: Is the software acting on the behalf of the Payer or the Payee?

In-vehicle:

Sexy, but maybe add a risks section about distracted driving?

Section 6.1.3:

Loyalty Cards:

Motivation:  Change “augment” to “effect” or something.  Augment means
increase or supplement.  We are talking about discounts.


Section 6.2.2:

Manual Selection:

Change Claire’s story to “Claire has multiple credit cards from the same
bank, as well as one debit card from another bank.” if that is what was
meant.

Change David’s story  - use the word arrange instead of order.  Order is
confusing in this context.

Section 6.2.3:

KYC / AML - expand abbreviation in title.


Section 6.2.3.1:

Rico’s story needs a period at the end.

Motivation:  Change “authentication can be used to instead of” to
“authentication can be used instead of”.

Section 6.3.1. <http://6.3.0.1/>:

Payee-initiated:

Removed “sort of broken security model” in favor of “risky security model”.

6.3.2:

Hold Verification:

Motivation:  extra comma.

6.3.4:

Motivation:

Change to “vary according to the payment scheme.”

6.3.4.1:

Notifications:  Change to “Gavin sends an electronic check…”

6.4.2:

Electronic Receipts:

Motivation:  Change to read “file tax returns”.

Physical Receipts:

Accessibility: change “along-side” to “alongside”.

7.2:

Delivery of Product/Receipt

Change “massage” to “message”.

-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.