Re: sketching out HTTP 402 workflow

Yes, there was a diagram included in a previous version of the charter
which has been moved to an FAQ (under development) which will be referenced
by the charter (to keep it from being too verbose).

It's still in GitHub though here:
https://raw.githubusercontent.com/w3c/webpayments-ig/master/latest/charters/images/WebPaymentsBasicPaymentFlow.png

I think there are a number of ways to deal with the 402 use case under this
flow, I'd be interested to hear from others how they'd approach the problem.

Example (feels wrong because requests are being sent in responses but I
think it works well nonetheless):

GET - https://example.com/someresource

402 - Payment Required
Location: https://example.com/payment/processing/endpoint
<response body contains payment initiation request document per standard>

POST - https://example.com/payment/processing/endpoint
<request body contains payment initiation response document per standard>

200 - Success
<response body contains payment completion request document per standard>

POST - https://example.com/payment/processing/endpoint
<request body contains payment completion response document per standard>

302 - Found
Location: https://example.com/someresource

GET - https://example.com/someresource

200 - Success

On 27 July 2015 at 13:30, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 27 July 2015 at 13:15, Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> Melvin,
>>
>> Have a look at the flow that's been proposed in the Web Payments WG draft
>> charter[1]. It consists of two request response pairs to establish the
>> terms of the payment and complete it's execution. The primary use case
>> (motivated by the browser vendors who are all participating) is to exchange
>> these messages via a browser API but the 402 use case for web services is
>> not out of scope.
>>
>> The intention is for the standard to be sufficiently general that both
>> push and pull payments will be supported. The whole flow is initiated by
>> the payee sending a payment initiation request document to the payer which
>> contains the terms of payment and a list of supported payment methods. This
>> could be passed as the body of the 402 response from the API as well as a
>> location (or other) header indicating where to POST the initiation response?
>>
>
> Looks good!
>
> So Alice wants to view an article, but it requires payment.
>
> Pre Payment / Registration -- she will require a balance in a wallet to
> pay (this is done out of band)
>
> Negotiation of terms / Payment Initiation Request -- the 402 will tell
> alice she needs to pay, and give her the terms that are acceptable to
> unlock the article, and how
>
> Negotiation of payment instruments / Discovery -- this is quite easy in my
> system at the moment because wallets only use one currency (later versions
> may have more).  Alice will discover how to securely initiate a payment.
> Normally this will be to send the correct data structure to an access
> controlled inbox that only she can access.
>
> Payment processing and completion -- after sending the payment, it is
> verified, and either accepted or rejected.  A notification is sent back to
> alice of the status and where to find more details.  The browser can then
> proceed to view the article, which will have been unlocked to Alice.
>
>
>>
>> I'd be interested to see how the 402 use case could be solved using the
>> same set of messages and flow as the WG is planning to standardise. This
>> would be valuable input into the WGs work.
>>
>> Adrian
>>
>> [1] http://www.w3.org/2015/06/payments-wg-charter
>>
>> On 27 July 2015 at 10:11, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 27 July 2015 at 04:31, Steven Rowat <steven_rowat@sunshine.net>
>>> wrote:
>>>
>>>> On 7/26/15 2:56 PM, Melvin Carvalho wrote:
>>>>
>>>>> You can see a demo partly completed at:
>>>>>
>>>>>
>>>>> http://inartes.com/?contentURI=https:%2F%2Finartes.databox.me%2FPublic%2Fdante%2Finferno-02%23139
>>>>>
>>>>> Click on "Next Verse"
>>>>>
>>>>
>>>> Awesome!
>>>>
>>>> Just the kind of demo I've been hoping could happen for the last, oh,
>>>> ten years?
>>>>
>>>> I'm not Dante, but I certainly have lots of material I could set up
>>>> with something like this if/when it's operational (and/or beta).
>>>>
>>>
>>> Sure, actually it can already point to any text so long as it's split
>>> into chapters and verses.
>>>
>>> I'd like to add some more texts e.g. from
>>>
>>> http://www.poetryintranslation.com/
>>>
>>> And maybe finnegans wake (my favourite!) :)
>>>
>>>
>>>>
>>>> Is pseudo-anonymity possible (for the payee)?
>>>>
>>>
>>> Great question.  I havent really thought this through.  But possibly
>>> yes.  How would you imagine pseudo-anonymity to work?
>>>
>>>
>>>> Will accepting Bitcoin be possible? Paypal?
>>>>
>>>
>>> As it's decentralized, I dont decide.  Merchants and users will decide
>>> on the currency.  But bitcoin is the default, so far :)
>>>
>>>
>>>>
>>>> O what fun. :-)
>>>>
>>>> SR
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>     I'll be using the SoLiD framework for this.
>>>>>
>>>>>     Anyone see any obvious flaws in the workflow?
>>>>>
>>>>>     [1] https://linkeddata.github.io/SoLiD/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> Sent from a mobile device, please excuse any typos
>>
>
>