Re: Payment Initiation - platform integration

IF the subject line of this thread is "payment initiation";
AND IF "invoice" is described in the UBL (an OASIS & ISO standard) as "a
document used to request payment";
THEN invoices and UBL as addressed in that established standard are
relevant.


RE: "The WG will likely use JSON as it's preferred message encoding"

No problem. Perhaps keep in mind:
https://en.wikipedia.org/wiki/Multichannel_retailing


Joseph Potvin
Project Coordinator, DataKinetics
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983
LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>

On Wed, Sep 16, 2015 at 2:54 PM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> Two personal comments on UBL and XML vs JSON *specifically with regard to
> the proposed WG*.
>
> 1. Invoices, and therefore UBL, are out of scope for what is being dealt
> with in this WG. They form part of the larger scope of the IG and may be
> part of the scope of a future WG. At most, I expect that accommodation may
> be made in the logical message designs to reference the invoice triggered
> the payment.
>
> 2. The WG will likely use JSON as it's preferred message encoding as this
> is the accepted practice today for W3C recommendations. That is not to say
> that the logical messages we define could not be encoded in other forms or
> that informative examples, test cases etc may not be produced using other
> encodings.
>
> *With regard to the work of the IG*, my hope is that, with Kris and
> Vincent's help, we will vastly improve our understanding of ISO20022 and
> see where the IG and the ISO20022 RA may work together to close the gap
> between what is being done in the two groups. This MAY include such things
> as collaborating to produce a recommendation for JSON encoding ISO20022
> messages or some standards for exposing Web APIs that exchange ISO20022
> messages.
>
> UBL is most likely to come into context when the group takes on the
> broader scope we have called "commerce" at which time it will likely be an
> important input to the work.
>
> On 16 September 2015 at 18:29, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> Hope the following is useful. I asked UBL TC Co-Chair Ken Holman for his
>> comments...
>>
>> At 2015-09-16 11:20 -0400, you wrote:
>>
>>    "Ken, Got a suggested reply?"
>>
>>
>> Well, I can make a few observations that you can do with as you like.
>>
>>     On 2015-09-16 16:49, Adrian Hope-Bailie wrote:
>>     RE: "invoice" is described as *"a document used to request payment"*
>>     [Anders Rundgren <anders.rundgren.net@gmail.com>]   I hope that UBL
>> won't be used for payment requests. UBL was designed for B2B and payment
>> operations usually only refer to invoice numbers.
>>
>> The only seven mandatory items in the UBL Invoice are an identification
>> string, an issue date, the party responsible to make payment, the party
>> responsible to receive payment, a legal monetary total, and an item
>> identification string and an item amount for each item.
>>
>> Ref:
>> http://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AllDocuments-2.1.html#Table_Invoice
>>
>> This satisfies a legal request for payment in any context, not just B2B
>> or B2G, and so is not encumbered by any business semantic of "invoice".
>> All of the other semantics available in UBL are handy for business
>> applications, but are not necessary to make UBL useful in any situation
>> where a request for payment is being made.  Using the noun "invoice" is a
>> convenient abbreviation.
>>
>>
>> RE: Aren't you BTW rather planning to use JSON rather than XML, ISO,
>> ASN.1 etc?
>>
>> JSON is used to convey an internal memory structure of information from
>> one application to another application, obliging both applications to begin
>> working from the same internal memory structure.
>>
>> XML is used to convey information in an arbitrary document format so that
>> applications can map their internal memory structures to and from the
>> document format, with the added benefit of the document format being
>> independently inspected, for example, for auditing purposes.
>>
>> JSON is ideal between two applications that have identical memory and
>> implementation representations, and a tight binding, and foreknowledge of
>> the order and makeup of every information item.  Tight binding is not
>> convenient for representing optionally-present information.
>>
>> XML is ideal between two applications that have independent memory and
>> implementation representations and a loose binding.  Loose binding is
>> convenient for representing optionally-present information.  It is focused
>> on conveying intent in a way that allows the information to be used in
>> multiple ways.  XML is also self-documenting in the judicious use of labels
>> for the information items, providing for independent inspection.
>>
>> Loose application bindings and self-documenting labels are the better
>> choices for open standards where participants have varied implementations,
>> varied platforms and varied contexts of use of the information.
>>
>> RE:   <https://yourlogicalfallacyis.com/false-cause>
>> https://yourlogicalfallacyis.com/false-cause
>> An invoice may be defined as a means to request a payment but that does
>> not mean that a payment must always be requested by an invoice.
>>
>>
>> True, but if a request for payment is needed and the invoice is an
>> available and satisfactory document for legal and practical purposes, then
>> there is nothing that prevents the invoice from being used for this purpose:
>> https://yourlogicalfallacyis.com/the-fallacy-fallacy
>>
>> . . . . . . . Ken
>>
>>
>> Joseph Potvin
>> Project Coordinator, DataKinetics
>> Operations Manager | Gestionnaire des opérations
>> The Opman Company | La compagnie Opman
>> jpotvin@opman.ca
>> Mobile: 819-593-5983
>> LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>>
>> On Wed, Sep 16, 2015 at 10:57 AM, Anders Rundgren <
>> anders.rundgren.net@gmail.com> wrote:
>>
>>> On 2015-09-16 16:49, Adrian Hope-Bailie wrote:
>>>
>>>> RE: "invoice" is described as *"a document used to request payment"*
>>>>
>>>
>>> I hope that UBL won't be used for payment requests.
>>>
>>> UBL was designed for B2B and payment operations usually only refer to
>>> invoice numbers.
>>> Aren't you BTW rather planning to use JSON rather than XML, ISO, ASN.1
>>> etc?
>>>
>>> Anders
>>>
>>>
>>>> https://yourlogicalfallacyis.com/false-cause
>>>>
>>>> An invoice may be defined as a means to request a payment but that does
>>>> not mean that a payment must always be requested by an invoice.
>>>>
>>>> On 16 September 2015 at 16:08, Joseph Potvin <jpotvin@opman.ca <mailto:
>>>> jpotvin@opman.ca>> wrote:
>>>>
>>>>     RE: "Is “invoice” synonymous with “authorization request” or is it
>>>> something different?"
>>>>
>>>>
>>>>     This is from the site of UBL Technical Cttee Co-Chair Ken Holman's
>>>> site, where "invoice" is described as *"a document used to request payment"*
>>>>
>>>> http://www.cranesoftwrights.com/resources/Crane-UBL-Skeleton/Crane-UBL-Invoice-2.1.html
>>>>
>>>>     The specs: http://ubl.xml.org/wiki/ubl-specifications
>>>>
>>>>     Here are a couple of general views of what UBL contributes to
>>>> electronic invoicing:
>>>>     http://eeiplatform.com/about/
>>>>     http://www.faces-online.nl/ubl-breakthrough-electronic-invoicing/
>>>>
>>>>     RE: [Dan S.] "I could be splitting a bill and that is my share, I
>>>> could be giving someone a gift or donation - there is not always an
>>>> invoice. Furthermore if you want to handle payments pull then there is no
>>>> invoice, such an authorization to allow a company to debit your account."
>>>>
>>>>     Call it what you wish in whatever context you like. In UBL, that's
>>>> all specified in a document called "invoice", across any context.  I'm not
>>>> aware of any better generic document type for this purpose, in any other
>>>> existing open standard.
>>>>
>>>>     Joseph Potvin
>>>>     Project Coordinator, DataKinetics
>>>>     Operations Manager | Gestionnaire des opérations
>>>>     The Opman Company | La compagnie Opman
>>>>     jpotvin@opman.ca <mailto:jpotvin@opman.ca>
>>>>     Mobile: 819-593-5983 <tel:819-593-5983>
>>>>     LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423>
>>>>
>>>>     On Wed, Sep 16, 2015 at 8:49 AM, Matt Howarter <
>>>> Matthew.Howarter@walmart.com <mailto:Matthew.Howarter@walmart.com>>
>>>> wrote:
>>>>
>>>>         Is “invoice” synonymous with “authorization request” or is it
>>>> something different?____
>>>>
>>>>         __ __
>>>>
>>>>         *Matt Howarter****Director - Payment Services*
>>>>         Phone: 479.204.9922 <tel:479.204.9922> Fax: 479.277.9796 <tel:
>>>> 479.277.9796>
>>>>         Matthew.Howarter@wal-mart.com <mailto:
>>>> Matthew.Howarter@wal-mart.com>
>>>>         Walmart
>>>>         702 SW 8th St.
>>>>         Bentonville, AR 72716-0100
>>>>         *Saving people money so they can live better.*____
>>>>
>>>>         __ __
>>>>
>>>>         *From:*Joseph Potvin [mailto:jpotvin@opman.ca <mailto:
>>>> jpotvin@opman.ca>]
>>>>         *Sent:* Wednesday, September 16, 2015 5:41 AM
>>>>         *To:* Web Payments IG; Web Payments CG
>>>>         *Subject:* Re: Payment Initiation - platform integration____
>>>>
>>>>         __ __
>>>>
>>>>         Is there agreement that:____
>>>>
>>>>
>>>>         1. Payment is always specified and initiated from an
>>>> invoice?____
>>>>
>>>>         2. UBL 2.1 provides the relevant global standard for an
>>>> invoice? http://ubl.xml.org/ ____
>>>>
>>>>
>>>>         ____
>>>>
>>>>         Joseph Potvin
>>>>         Project Coordinator, DataKinetics
>>>>         Operations Manager | Gestionnaire des opérations
>>>>         The Opman Company | La compagnie Opman
>>>>         jpotvin@opman.ca <mailto:jpotvin@opman.ca>
>>>>         Mobile: 819-593-5983 <tel:819-593-5983>____
>>>>
>>>>         LinkedIn <https://www.linkedin.com/pub/joseph-potvin/2/148/423
>>>> >____
>>>>
>>>>         __ __
>>>>
>>>>         On Wed, Sep 16, 2015 at 5:45 AM, Adrian Hope-Bailie <
>>>> adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:____
>>>>
>>>>         Looking at the draft spec from Digital Bazaar for the CG and
>>>> considering both, our language in the charter, and also some of the
>>>> comments from the charter AC review I wondered what precedent there may be
>>>> in defining how a browser should process an API call that requires
>>>> interaction with the platform (host OS).____
>>>>
>>>>         The best example I could find is in the Web Notifications PR
>>>> published earlier this month:
>>>> http://www.w3.org/TR/2015/PR-notifications-20150910/#displaying-notifications____
>>>>
>>>>         I would like to get the groups' (both IG and CG) views on the
>>>> parallels here between the action "Displaying Notifications" from the Web
>>>> Notifications recommendation and a potential "Initiating Payments" section
>>>> we'd put in a recommendation from our WG.____
>>>>
>>>>         The pertinent line from the Web Notifications rec is:
>>>>         "Display notification on the device (*e.g. by making the
>>>> appropriate notification platform API call*)." - emphasis mine.____
>>>>
>>>>         While I know not all platforms upon which browser's run today
>>>> have mature "payment APIs" in the same way that they have relativley mature
>>>> "notifications APIs" this open-ended approach seems appealing in that it
>>>> avoids the browser needing to become complex payment processing
>>>> applications.____
>>>>
>>>>         Rather, the messages passed to the navigator.payments API in
>>>> the browser should simply be passed directly to the platform's payment API
>>>> (following any security or privacy scrutiny or permissions checks we
>>>> define).
>>>>
>>>>         The timing seems right for us to work with the platform vendors
>>>> (many of whom are also browser vendors that have expressed interest in
>>>> working on this problem) to define a common vocabulary and logical messages
>>>> for this flow.____
>>>>
>>>>         *Example:
>>>>         *
>>>>         On a mobile platform I see this working similarly to the way
>>>> Android intents may function. The browser passes the payment initiatiation
>>>> request to the platform and the user is prompted with the app selection
>>>> dialogue they are accustomed to for selecting the app they want to use for
>>>> that action (the same way you select which app to use when sharing a photo
>>>> for example). ____
>>>>
>>>>         __ __
>>>>
>>>>         Thoughts?____
>>>>
>>>>         __ __
>>>>
>>>>         This email and any files transmitted with it are confidential
>>>> and intended solely for the individual or entity to whom they are
>>>> addressed. If you have received this email in error destroy it immediately.
>>>> *** Walmart Confidential ***
>>>>
>>>>
>>>>
>>>>
>>>
>>
>