RE: Sanity check on API using flows from Flows Task Force

Manu, 

Many thanks to you and the team for starting to look at these.

Here are my comments;

1. General, the flows are rendering from me (Chrome) in the dull width of the browser, zoom doesn't function for them, whereas is does change the rest of the sizes.

2. Credit Card Flows: The notes state that steps #3 - #12 are executed by the payment application, where has this specific payment application come from, I was under the impression that we were going to provide the payment application for these sorts of interactions in the base specification and implementation?

3. There is subtly different processing for each of the payment types in the promise response, how would this work when there are multiple payment methods supported, ideally we don’t want to get into a switch statement for each of the different payment methods, shouldn't we have standard responses from the different payment applications for success, fail etc.?

4. In the SEPA credit transfer, it looks like you are expecting the payment to occur in real time, that is not the way SEPA works, clearing can take a number of days. The most likely result is going to be a 'payment pending' type response. The merchant will need to hold the good until such a time as the cleared message is received.

Thanks,
Matt.

-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: 12 February 2016 22:51
To: Web Payments WG
Subject: Sanity check on API using flows from Flows Task Force

Hi Matt and the rest of the Flows Task Force,

In order to get a sanity check on the Web Payments CG Browser API proposal, we've started checking the API against the flows that the Flows Task Force has been working on. We're doing this by writing code that uses the payments API to match the flows. The result can be found here:

http://wicg.github.io/web-payments-browser-api/#flows-addendum

We've integrated the legacy card, tokenized card, SEPA Credit Transfer, and basic Bitcoin flows for now. The good news is that there is very little variation between each payment scheme so far (which demonstrates that the API is fairly generic, which is a good thing).

We'd be interested in your feedback. For example, we think we've made a mistake in the PSP-mediated SEPA Credit Transfer use case, but can't quite figure out where.

In any case, just a heads up that we've started integrating the flows and apologies for taking so long to get around to this.

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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Received on Sunday, 14 February 2016 17:36:07 UTC