- From: Joseph Potvin <jpotvin@opman.ca>
- Date: Wed, 16 Sep 2015 06:40:47 -0400
- To: Web Payments IG <public-webpayments-ig@w3.org>, Web Payments CG <public-webpayments@w3.org>
- Message-ID: <CAKcXiSq0jMu69nvs0e3FJhibf3BNqS1eKPktN2+5q=hyFXfbgA@mail.gmail.com>
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 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 10:41:35 UTC