Re: Thanks to all and next steps

Doesn't the ISO 20022 catalogue supply the necessary <signal of some type>
specs for each of the significant points along the payment sequence?
http://www.iso20022.org/full_catalogue.page

David, while "there is no need of a “receipt” or “invoice” to mark it’s end"
within the payment system itself, there certainly is such a requirement in
the broader e-commerce system. An attempt to explain the boundary between
the two domains is here:

https://www.w3.org/community/webpayments/wiki/A_Quick_Introduction_to_UBL_Oriented_to_Payment_Solutions_Designers#Relationship_with_ISO_20022
This explanation is currently being reviewed by a couple of people at
SWIFT, and if necessary I'll tweak it when I hear back from them.

Joseph Potvin
On behalf of DataKinetics http://www.dkl.com
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983

On Tue, Jun 23, 2015 at 4:09 PM, David Jackson <david.dj.jackson@oracle.com>
wrote:

> The issue of a finite <end> of the payments process is not contentious at
> all, it was the invoice / receipt that caused the issue. I still remain
> deeply committed that an end state of the payments process needs to be
> defined. This is why I represented it as a signal of some kind in which the
> process is known to be over. Otherwise, there is a transaction which goes
> without feedback and the user has no known end point while the seller has
> no definition of end state. So, no, this does not seem to be contentious at
> all, it is only the defining of the end state of the transaction.
>
>
>
> --
> [image: Oracle] <http://www.oracle.com/>
> David Jackson | Senior Director Financial Services
> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
> <+16144656654>
> Oracle Industry Solutions Group
> New York City | Columbus
>
> [image: Green Oracle] <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
>
>
> *From:* Adrian Hope-Bailie [mailto:adrian@hopebailie.com]
> *Sent:* Tuesday, June 23, 2015 2:33 PM
> *To:* Joseph Potvin
> *Cc:* Web Payments IG
> *Subject:* Re: Thanks to all and next steps
>
>
>
> Hi Joseph, Dave,
>
> My interpretation of the consensus at the F2F was that we will leave all
> of this contentious stuff to the payment scheme to define and will, in v1,
> simply define a high level flow and a message format that can be used as a
> container for scheme specific messaging.
>
> Adrian
>
>
>
>
>
> On 22 June 2015 at 16:40, Joseph Potvin <jpotvin@opman.ca> wrote:
>
> Thanks David,
>
> RE: "<signal of some type> to the payer that the transaction did, in fact,
> get submitted – better yet that it was “completed” to end the payments
> transaction"
>
>
>
> There was some interesting discussion amongst participants at a table
> during the US Fed's Faster Payments Task Force meeting last week about
> standardizing the various points along all payment systems sequences that
> should generate signals that are accessible to both payers and payees. (The
> analogy discussed had to do with how shipping and destination parties of a
> courier service can track any package online.)
>
> Discussants agreed that many of the points along the way of a financial
> transactioni would surely be unintelligible to most people. Also the table
> agreed that there are very many points that could potentially generate such
> signals. But these considerations support the idea that some generally
> understandable notional "status" commonalities across all payment systems
> might be usefully identified, which all payment system operators may be
> willing to accommodate.
>
> Does any existing standard describe a payment status request as minimalist
> as a ping echo?
>
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
>
>
> On Mon, Jun 22, 2015 at 10:05 AM, David Jackson <
> david.dj.jackson@oracle.com> wrote:
>
> Joseph and all,
>
> I think we are getting hung-up on this topic of “invoice” again … may I
> offer:
>
>
>
> V1 = we are NOT seeking to include a standard for invoice nor contents
> related to such. We COULD offer an optional call to include an invoice of a
> format used by both payee and payer should that be of interest in the
> implementation (highly likely to loyalty processing). However, we WOULD
> like to include a <signal of some kind> that the payment has been sent for
> processing as feedback to the payer/customer. The payee/merchant uses that
> (or other means NOT in this process flow) to effect fulfillment and other
> activities which occur around the timing of the payment. Please note from
> the F2F – the payment may be held from settlement until fulfillment is
> accomplished (in the case of physical goods) to accommodate standards (and
> some regulation) about when the payment may be accepted by the merchant.
>
>
>
> While I am a very big proponent of the use of “invoice” and “itemized
> receipts” – there are far too many standards and de facto standards to
> enable through a single payment flow. It would restrict the communications
> between buyer/seller and force too much compliance. The idea is that the
> feedback to the payer makes sense that the payment transaction has been
> “accepted” or is “in progress” – whatever term might be useful and
> productive here. It is not useful to “invoice” unless that is truly part of
> the process flow between buyer/seller.
>
>
>
> I would like to reiterate my support for a  <signal of some type> to the
> payer that the transaction did, in fact, get submitted – better yet that it
> was “completed” to end the payments transaction. I agree with the strong
> opinions that the “invoice” or “receipt” are not the intention of the
> payments process.
>
>
>
> --
> [image: Oracle] <http://www.oracle.com/>
> David Jackson | Senior Director Financial Services
> Mobile: +1.614.560.1237 <+16145601237> | VOIP: +1.614.465.6654
> <+16144656654>
> Oracle Industry Solutions Group
> New York City | Columbus
>
> [image: Green Oracle] <http://www.oracle.com/commitment>
>
> Oracle is committed to developing practices and products that help protect
> the environment
>
>
>
>
>
> *From:* Joseph Potvin [mailto:jpotvin@opman.ca]
> *Sent:* Monday, June 22, 2015 9:48 AM
> *To:* Web Payments IG
> *Subject:* Re: Thanks to all and next steps
>
>
>
> Thanks Adrian,
>
> RE: "no longer intend on defining either an electronic invoice or receipt
> but simply a payment request/response and confirmation"
>
> Based upon what Manu referred to as "the final list of use cases for
> version 1" (dated 20 June):
>
> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesForVersion1
> ...three of the use cases in the current selection, from the "Agreement on
> Terms" part, are each pre-payment functions involved in e-invoice
> development:
>
>    - Registration-less (Agreement on Terms)
>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>    - One Time Payment (Agreement on Terms)
>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>    - Subscription (Agreement on Terms)
>    <http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms>
>
> It seems to me that in the sequence: *Payer/Payee >> Invoice >>
> Wallet/Account >> Payment System*
>
> 1. Buyers & Sellers: W3C has a mandate to specify essential commonalities
> in how all browsers should handle any [*Payer/Payee >> Invoice*]
> sequence. This work should *take-as-given* any e-invoice documents and
> components established and maintained by the authoritative e-Commerce
> semantic and technical specifications. The most prominent of these is UBL,
> which can be expressed in XML or JSON;
>
> General Architectural Requirements:
> • United Nations Commission on International Trade Law (UNCITRAL): “Model
> Law on Electronic Commerce”; “Model Law on Electronic Signatures” and
> related UNCITRAL guidance
> http://www.uncitral.org/uncitral/en/uncitral_texts/electronic_commerce.html
> • International Institute for the Unification of Private Law (UNIDROIT):
> “Principles of International Commercial Contracts”.
> http://www.unidroit.org/publications/513-unidroit-principles-of-international-commercial-contracts
>
>
> 2. Financial Services:  W3C has a mandate to specify how any
> Wallet/Account and how any Payment System should accommodate any
> Web-originating/terminating [*Invoice >> Wallet/Account >> Payment System*]
> sequence. This work should *take-as-given* any financial messaging
> requirements and types established and maintainted by financial messaging
> specifications. The most prominent of these is UNIFI (better known as ISO
> 20022) which can be expressed in XML or JSON.
>
> General Architectural Requirements:
> • Bank for International Settlements: “Principles for Financial Market
> Infrastructures”
> https://www.bis.org/cpmi/publ/d101.htm?
> • International Organization of Securities Commissions (IOSCO):
> “Objectives and Principles of Securities Regulation”
> https://www.iosco.org/about/?subsection=key_regulatory_standards
>
> In the above, I use the word "Requirements" deliberately because even
> though their respective elements are only guidelines, neglect of any  of
> their elements is sure to cause lasting headaches.  (I accept that the
> challenge of trying to accommodating all those elements up front is itself
> quite a headache, but it's the short-term-pain-for-long-term-gain variety.)
>
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
>
>
> On Mon, Jun 22, 2015 at 6:35 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
> Hi Joseph,
>
> To add some clarity. The work we did at the face to face was mostly to
> narrow the scope of v1 to explicitly exclude anything not required to
> execute a payment. You'll notice that we no longer intend on defining
> either an electronic invoice or receipt but simply a payment
> request/response and confirmation.
>
> My feeling was that this was due to the acceptance by all that a lot of
> this is outside the scope of "payments" and more in the scope of "commerce"
> and therefor necessarily introduces the need to incorporate work from a far
> wider scope of liaison bodies.
>
> My perception of the v1 scope is to define standard messaging and a
> protocol to initiate and complete payments from the browser while leaving
> the bulk of the specifics to the payment scheme that is used. v2 of the
> group's work will be wider in scope and will be based around the liaison
> work done by the external reviews task force.
>
> Adrian
>
>
>
> On 21 June 2015 at 01:22, Joseph Potvin <jpotvin@opman.ca> wrote:
>
> Great to hear, except of the following...
>
> RE: I don't think we really spent too much time discussing ... external
> liaisons, ... Next steps may be to back burner this until..."
>
> It seems to me critically time-sensitive that the IG's specifications
> boundary (in scope / out of scope) be rendered operational in terms of
> defining and engaging working relationships with other primary entities
> that hold the official mandate for (a) Payment Systems Principles (eg BIS,
> UNIDROIT); (b) e-Commerce Model Laws (eg UNCITRAL); and (c) Payment
> Information Specifications (eg ISO-TCs; OASIS-TCs).
>
> The IG's official reply to the X9 review states: "As you rightly observe,
> several aspects of what we are working on (e.g., trust, credentials,
> digital signatures, loyalty programs, etc.) extend beyond a payment
> transaction and are applicable to other standards efforts that may not even
> involve payments."
>
> Several matters being worked on by this IG also extend beyond the W3C's
> specifications domain.
>
> It is not clear why a "hot front-burner" process is not established for
> this.
>
>
> Joseph Potvin
> On behalf of DataKinetics http://www.dkl.com
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca
> Mobile: 819-593-5983
>
>
>
> On Sat, Jun 20, 2015 at 6:19 PM, Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> Thanks to everyone that attended and participated in the 2015 W3C Web
> Payments face-to-face in NYC. I was particularly thrilled during the
> roundtable as the message the group members were delivering demonstrated
> an aligned vision. What's more impressive is the people that are
> participating and the short time that it took to put this new effort
> together and align our direction.
>
> There's still much more work to do, but my confidence that we can pull
> this Web Payments stuff off is the highest it has ever been.
>
> I was just reviewing the goals of the meeting and had a few thoughts for
> the coming weeks:
>
> > Prioritize payments use cases and the capabilities necessary to
> > fulfill them.
>
> We came out of the face-to-face with a solid list of use cases:
>
>
> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/UseCasesForVersion1
>
> I don't think we identified all the capabilities needed for V1, but with
> a well-defined list of use cases, I think we'll be able to do a good job
> with the capabilities over the next several weeks.
>
> I'm going to go through the use cases and update all the V1 use cases
> with the clarifications made throughout the face-to-face meetings. I'll
> also list the use cases in the Roadmap document.
>
> > Review draft charter(s) and plan for first round of standardization
>
> Quite a bit of work went into the Payment Architecture WG charter and I
> think we have enough feedback to draw up a draft charter that can get
> consensus from the group via the mailing list.
>
> I don't think we can say the same for the Authentication WG charters or
> the Credentials WG charter.
>
> Next steps for the PAWG charter seem to be for Ian to revise it and pass
> it by the group.
>
> Next steps for the Authentication WG charters seem to be for us to
> identify capabilities that we can put into those charters.
>
> Next steps for the Credentials WG charter seems to be to coordinate w/
> the Credentials CG and try to get more support from outside of this group.
>
> > Initiate discussion on other IG activities (to follow push towards
> > launch of standard(s) groups).
>
> I don't think we really spent too much time discussing this, other than
> "focus on V2, external liaisons, and supporting the WGs".
>
> Next steps may be to back burner this until after the PAWG is launched.
>
> > Solicit feedback from broader community on group's direction (via
> > the roundtable)
>
> The feedback that we heard during the roundtable was probably best
> summarized by what was not said; there didn't seem to be an objection
> for the current direction. There were concerns over privacy and level
> playing field. The cocktail reception discussions didn't reveal (to me)
> any concerns about the current scope of work around payments.
>
> The biggest criticism seemed to be a lack of near-term focus on identity
> and credentials, but that may be my bias kicking in.
>
> Next steps would probably be to establish deeper connections with the
> Roundtable attendees and ensure that they're involved in future reviews.
>
> All in all, I think we made excellent progress. Thank you for all the
> great comments, input, and discussion.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>
>
>
>
>
>
>
>
>
>