Re: Payment Initiation - platform integration

RE: "invoice" is described as *"a document used to request payment"*

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> 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
> Mobile: 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> wrote:
>
>> Is “invoice” synonymous with “authorization request” or is it something
>> different?
>>
>>
>>
>> *Matt Howarter* *Director - Payment Services*
>> Phone: 479.204.9922 Fax: 479.277.9796
>> 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]
>> *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
>> 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?
>>
>>
>> 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 ***
>>
>
>