W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > September 2015

Re: Payment Initiation - platform integration

From: Joseph Potvin <jpotvin@opman.ca>
Date: Wed, 16 Sep 2015 09:11:49 -0400
Message-ID: <CAKcXiSpB7TGSEhWZvHzDtpRhTZG1F-CezAoNbc1=BFOh565FgQ@mail.gmail.com>
To: Web Payments IG <public-webpayments-ig@w3.org>, Web Payments CG <public-webpayments@w3.org>
If "payment initiation" were not to be described as always originating from
"an invoice", what would the WG identify as the class of business object to
specify and initiate any payment between a payer and a payee?

Joseph Potvin
Project Coordinator
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 8:58 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> On 16 September 2015 at 12:40, Joseph Potvin <jpotvin@opman.ca> wrote:
>
>> Is there agreement that:
>>
>> 1. Payment is always specified and initiated from an invoice?
>>
>
> No, I don't think that is always the case. Anyway, we have decided to
> focus purely on the payment in this WG so in future the payment initiation
> may reference an invoice but that's not a requirement.
>
>>
>> 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
>> Mobile: 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> 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?
>>>
>>
>>
>
Received on Wednesday, 16 September 2015 13:12:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:44 UTC