RE: Thanks to all and next steps

Yes – agreed for eCommerce. In this case, we are doing the Web Payments so we just need to have a defined end for the payments function. Invoice / receipt can be the subject of other flows that are not the payment itself. In the invoice / receipt discussion there are several decades of discussion and standards work. So I agree that this subject (receipt / invoice) should be outside the scope of a web payment standard.

 

-- 
HYPERLINK "http://www.oracle.com/"Oracle
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+1.614.560.1237 | VOIP: HYPERLINK "tel:+16144656654"+1.614.465.6654 
Oracle Industry Solutions Group
New York City | Columbus 

HYPERLINK "http://www.oracle.com/commitment"Green Oracle

Oracle is committed to developing practices and products that help protect the environment

 

 

From: Joseph Potvin [mailto:jpotvin@opman.ca] 
Sent: Tuesday, June 23, 2015 4:46 PM
To: Web Payments IG
Subject: 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
HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca
Mobile: HYPERLINK "tel:819-593-5983"819-593-5983

 

On Tue, Jun 23, 2015 at 4:09 PM, David Jackson <HYPERLINK "mailto:david.dj.jackson@oracle.com"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. 

 

-- 
HYPERLINK "http://www.oracle.com/"Oracle
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+1.614.560.1237 | VOIP: HYPERLINK "tel:+16144656654"+1.614.465.6654 
Oracle Industry Solutions Group
New York City | Columbus 

HYPERLINK "http://www.oracle.com/commitment"Green Oracle

Oracle is committed to developing practices and products that help protect the environment

 

 

From: Adrian Hope-Bailie [mailto:HYPERLINK "mailto:adrian@hopebailie.com"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 <HYPERLINK "mailto:jpotvin@opman.ca"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
HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca
Mobile: HYPERLINK "tel:819-593-5983"819-593-5983

 

On Mon, Jun 22, 2015 at 10:05 AM, David Jackson <HYPERLINK "mailto:david.dj.jackson@oracle.com"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.

 

-- 
HYPERLINK "http://www.oracle.com/"Oracle
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+1.614.560.1237 | VOIP: HYPERLINK "tel:+16144656654"+1.614.465.6654 
Oracle Industry Solutions Group
New York City | Columbus 

HYPERLINK "http://www.oracle.com/commitment"Green Oracle

Oracle is committed to developing practices and products that help protect the environment

 

 

From: Joseph Potvin [mailto:HYPERLINK "mailto:jpotvin@opman.ca"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:

HYPERLINK "http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms"Registration-less (Agreement on Terms) 
HYPERLINK "http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms"One Time Payment (Agreement on Terms) 
HYPERLINK "http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/#agreement-on-terms"Subscription (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
HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca
Mobile: HYPERLINK "tel:819-593-5983"819-593-5983

 

On Mon, Jun 22, 2015 at 6:35 AM, Adrian Hope-Bailie <HYPERLINK "mailto:adrian@hopebailie.com"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 <HYPERLINK "mailto:jpotvin@opman.ca"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
HYPERLINK "mailto:jpotvin@opman.ca"jpotvin@opman.ca
Mobile: HYPERLINK "tel:819-593-5983"819-593-5983

 

On Sat, Jun 20, 2015 at 6:19 PM, Manu Sporny <HYPERLINK "mailto:msporny@digitalbazaar.com"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/