Re: Web Payments API

On 11 September 2015 at 18:31, Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 09/11/2015 04:44 AM, Adrian Hope-Bailie wrote:
> > 1. What happens after the request is received by the browser/wallet?
>
> In both the polyfill case and the native-browser case, there are
> multiple flows that all start out like this:
>
> 1) the API scans the list of registered payment instruments
>

What is "the API" in this case? Is it the browser?


> 2) matches the registered instruments against the acceptedSchemes in the
>    request, and then
> 2.1) selects an instrument automatically if there is only one, or
> 2.2) makes a decision based on some pre-existing preferences
>      if there are more than one valid selection, or
> 2.3) asks the payer which instrument they'd like to use if an
>      automatic selection cannot be made
>
> then:
>
> If the instrument is a PayPal/Google Wallet-like instrument,
> tokenized credit card, ACH, ISO20022 style instrument (push payment*):
> 3) forwards the request on via a POST/postMessage to the
>    paymentRequestService in the payment instrument for approval
>

In the flow we discussed for the WG charter this payment execution doesn't
happen yet.
The first request/response exchange is simply to confirm the terms
(selection of instrument) between both parties.


> If the instrument is a non-EMV mag-stripe card with embossed PAN and
> CVV2 (pull payment*):
> 3) forwards the request on via a POST/postMessage to the
>    paymentRequestService in the acceptedScheme (note that the merchant
>    sets this, not the payment instrument)
>

Why not simply return the data required to process the payment in the
response from the API?


>
> If the instrument is a cryptocurrency like Bitcoin and the wallet is a
> browser extension or built into the browser:
> 3) Uses the crypto key material to generate a payment acknowledgement
>    or, redirects the payer to paymentRequestService if there is no
>    local key material.
>

Why is this different to the first push payment case?


>
> then:
> 4) transfers the flow over to whatever entity is going to generate the
>    payment acknowledgment (payer-PSP, browser extension/wallet, or
>    merchant-PSP).
>

I'm not sure what "transfers the flow" means. In the high level flow we
simply distinguish between push and pull.
Push: Following confirmation of terms (payment initiation request/response)
the payee sends a payment completion request, the payer makes the payment
and sends back a confirmation in the response.
Pull: Following confirmation of terms (payment initiation request/response)
the payee executes the payment and  sends a payment notification to the
payer (who ACKs this by responding).

>
> * Note that not all push payments will be forwarded to the
>   paymentRequestService and not all pull payments will use the merchant-
>   provided paymentRequestService. The details are not worked out here,
>   we need to break down how each payment instrument will be processed
>   in the overarching flow. This area needs work to align w/ the
>   work that Adrian did on the high-level flow.
>
> > It's not clear who actually processes the payment in the card
> > example?
>
> It depends on the type of card being used, push vs. pull, and if a PSP
> operating on behalf of the payer will process the card (PayPal) or if a
> merchant PSP will process the card (non-chip and pin card / some
> tokenized card solutions). We need to put more work into categorizing
> all the possible flows to make sure what we've presented actually works
> for all known flows we want to support. This area needs work.
>
> > Are you suggesting that the payer must process the card payment and
> > then the promise resolves to a proof of payment?
>
> Not suggesting that, but it's definitely not clear from the current spec
> text. I'll try to work some of the stuff written above into the
> document. Would love your help to point out where the flow breaks down
> with what we want to support.
>

I think the idea of passing around end-point URLs that the payer must call
or POST data to is problematic. The reason the flow is defined as it is in
the charter is that even if we ignore that there is a browser in the middle
it still works. It's a simple request/response flow that can still
accommodate push and pull.

Keen to discuss this further.

>
> > 2. The flow is not exactly what we've proposed in the charter where
> > we propose an inititation request/response to select the scheme and
> > instrument followed then by either a completion request/response (if
> > the completion is done by the payer) or a notification
> > request/response if the completion is done by the payee (this seems
> > similar to your acknowledgement step). What needs to change, the
> > spec or the charter?
>
> The spec needs to change, it's a bit late in the game to change the
> charter. Wwe need to iterate more on this document to see how to
> accomplish what the charter wants in the most efficient way. Ideally,
> this would've been done weeks ago, but hey - not enough time in the day
> :). If we find that we can't match the flow you put together in an
> elegant way (and I don't see anything yet that wouldn't allow us to
> accomplish that), WGs tend to have enough flexibility (especially as
> written in the Web Payments WG charter) to still do The Right Thing
> (tm), whatever that ends up being.
>

+1 - I like the flow we put in the charter but keen to hear any good
reasons why it may not be enough. I find that actual implementations help
to expose the errors so thanks for the effort on this.


>
> I'm not suggesting the spec above is the right thing to do, it's merely
> a starting point for the technical discussion and the more input like
> yours we get on it, the further we can refine it and have it match what
> we want to accomplish in Phase 1 and beyond.
>
> So, thanks for the input, and I'll try to clarify the questions you
> asked above in the spec over the next week or so.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
>
>