Re: Thanks to all and next steps

Is the following coherent or confused?

1. e-Commerce application (IS0 19845 conformant) dispatches the contracting
parties' mutually authorized payment message (ISO 20022-conformant) to the
initiating Depository (Payer's for "push"; Payee's for "pull".) Choice of
payment system is part of the message, since this matter must be
established between the contracting parties before payment initiation. The
signal issued upon this event contains this info: "Payment message with
such and such attributes sent to digital account belonging to ABC, for
settlement via PQR Payment System, with digital account belonging to XYZ.")

2. The initiating Depository receives the payment message, validates it
against some rules, and dispatches a payment message to the identified
Payment System. The signal issued upon this event contains this info:
"Payment message received by account belonging to ABC, and dispatched to
PQR Payment System. (Or: Payment message rejected by account belonging to
ABC. Error code 12345)

3. PQR Payment System receives the payment message, validates it against
some rules, and dispatches a payment message to the identified Depository.
(Several steps occur within any Payment System's settlement process, but
their internal details need not be tracked by Payees and Payers.) The
signal issued upon this event contains this info: Payment message received
by PQR Payment System, and settled with account belonging to XYZ. (Or:
Payment message rejected by PQR Payment System. Error code 67890)

4. The transaction terminating Depository (Payee's for "push"; Payer's for
"pull") dispatches a message to the e-Commerce application to confirm that
the payment is completed. The signal issued upon this event contains this
info: "Payment confirmed to digital account belonging to XYZ, settled via
PQR Payment System, originating with digital account belonging to ABC.")

Such a cycle would run twice when payment is held in escrow.

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 Wed, Jun 24, 2015 at 10:11 AM, David Jackson <david.dj.jackson@oracle.com
> wrote:

> We only run off the rails because you are thinking that the “end” has to
> be success – that is not the point here. The “end” is the end of the
> payment. If that simply means – payment sent without error code – fine.
> Just a definitive “end” is what I’m seeking. What is amiss with several
> payments schemes is that the “payment sent” occurs and then logic is
> transferred to the eCommerce function and the payer thinks it closed and
> then has an argument with the merchant when they come back because there
> was ANY error code. So the thing I’m trying to get to is the normal
> condition of “sent without error code”. We don’t have to interpret the
> error, just no error occurred = end. Error occurred – return to eCommerce
> site for processing.
>
>
>
> Make sense? Just don’t like orphaned processes without a defined end.
>
>
>
> --
> [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:* Wednesday, June 24, 2015 9:53 AM
> *To:* David Jackson
> *Cc:* Joseph Potvin; Web Payments IG
> *Subject:* Re: Thanks to all and next steps
>
>
>
> The challenge with defining the end is that I think there are more than
> one ways to end :)
> We will need to define what those are but they could be different for push
> and pull payments and whether or not the scheme in use performs some kind
> of out-of-band confirmation of payment.
>
> To handle all of these I think we'll end up with two different API
> methods, something like "requestPayment" and another for "completePayment".
>
> The payee will call both and the response to complete payment should be
> the final signal that the payment is complete.
>
> I don't want to get into too much design detail here as this is the job of
> the WG but suffice it to say I expect they will define an interface and
> flow that makes sense and caters for all of the use cases in scope (i.e.
> both push and pull)
>
>
>
> On 24 June 2015 at 14:47, David Jackson <david.dj.jackson@oracle.com>
> wrote:
>
> Yes – agreed. With the only caveat that there is a clear “end” of the
> payments standard – that was why I keep focusing on whatever we call that
> end <signal of some kind> that is the clear end of the payments process –
> whether or not it is satisfactory! Even if we say that <payment sent> is
> the end – fine, as long as the feedback is available. Then we can pick up
> the process for the eCommerce process either to create standards or allow
> the implementations.
>
>
>
> I knew we really did agree Adrian – just a matter of getting to
> definitions!  J
>
>
>
> --
> [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:* Wednesday, June 24, 2015 7:44 AM
> *To:* David Jackson
> *Cc:* Joseph Potvin; Web Payments IG
>
>
> *Subject:* Re: Thanks to all and next steps
>
>
>
> +1 That was the consensus at the F2F and that is what I have been trying
> to say. Thanks for putting it so succinctly.
>
> The payment provides a flow that can be piggy-backed or built upon in
> future for the "commerce" requirements of e-commerce and the intention will
> be to define a payments flow that is open to this but to explicitly exclude
> "commerce" requirements from the v1 scope.
>
>
>
> On 24 June 2015 at 00:42, David Jackson <david.dj.jackson@oracle.com>
> wrote:
>
> 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.
>
>
>
> --
> [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:* 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
> 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/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>