Re: Payment Initiation - platform integration

Could be any number of things - 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.

On Wed, Sep 16, 2015 at 9:11 AM, Joseph Potvin <jpotvin@opman.ca> wrote:

> 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?
>>>>
>>>
>>>
>>
>