Re: Web Payments API

Hey Adrian,

Apologies for the very delayed response - travels got in the way of spec
work.

On 09/13/2015 05:42 PM, Adrian Hope-Bailie wrote:
> 1) the API scans the list of registered payment instruments
> 
> What is "the API" in this case? Is it the browser?

Yes, it's the browser (or a polyfill).

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

I'm wondering if that's necessary. Don't we want the messages to be
declarative? If we do, then why wouldn't the information provided by the
merchant in the payment request be all that is necessary for the payment
agent to execute payment initiation?

I think I remember you saying that you notify the merchant in order to
lock in the final price, but you don't necessarily need that step if
pricing information for all payment methods is provided up front in the
payment request. The caveat with this being that some payment
instruments may not allow this to happen? Is this why you send the final
selection back to the merchant?

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

Yes, that's better (I think). Based on your feedback and Dave Longley's
feedback, I've reworked the API to do this via a callback (but it really
should probably be via the returned promise (see step 6)):

https://web-payments.org/specs/source/web-payments-api/#payment-flow-overview

The spec text is not completely there yet. I'll try to create an example
tonight of a flow where the Promise resolves to the credit card info.

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

In one case, the push payment requires navigation to a 3rd party
website. In the other case, the push payment requires navigation to a
"native wallet" or installed application.

Since this spec text was written, we've changed our position a bit on
what the browser API should look like. The result should probably always
be resolved in the Promise if you're executing the messages through the
browser API (so it doesn't matter if you have to go to a 3rd party or
not, the promise resolves the same way in all instances).

This raises the question of how you do server-to-server payment message
routing, but we have a separate spec in the works that can do that (with
the same payment messages).

So, we're probably going to end up cleaning up the Web Payments API to
focus solely on browser-mediated payments. We may have a Web Payments
REST API to focus solely on server-to-server mediated payments. Both
protocols would end up using the exact same messages, but the way the
messages are routed would be different. This helps us dogfood the
messages for other protocol flows (like payment initiation via NFC, etc.).

> 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).

There are a variety of message flows that need to be supported:

payee web page -> local app (bitcoin/tokenized card) -> payee web page
payee web page -> payee payment processor (PayPal) -> payee web page
payee web page -> payer payment processor (PAN Card) -> payee web page

What I mean by "transfers the flow" is the point at which control is
handed over from the payee web page to the next interface (which is not
the payee web page).

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

Agreed that POST data is problematic /in the browser scenario/. Our
(Digital Bazaar's) thinking has evolved since this last email and here's
where we are now:

1. There are a set of payment messages.
2. These payment messages are passed via a Promise-based API in the
   browser that does not require POST'ing data. This functionality is
   natively implementable (via native calls) or polyfillable (via
   postMessage()).
3. There is another REST-based API that can pass the same payment
   messages in #1 without the requirement of there being a browser
   orchestrating the flow of messages.

> +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.

We're testing some of these ideas out in the Credentials CG
implementations and seem to be making good progress there. We believe
the same strategy can be used for the payments work.

I'll try to send another email in a bit to try and introduce that line
of thinking.

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

Received on Thursday, 1 October 2015 01:36:00 UTC