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

Manu,

1. The scaling seems to work in this document http://opencreds.org/specs/source/use-cases/  - is there a difference in the way it is linked?

2. I suspect this may be a difference between the specification and the reference implementations, though I do note that the optional deliverables section in the Charter https://www.w3.org/Payments/WG/charter-201510.html suggests we could define the flows, perhaps I'm reading too much into this, but defining the flows implies to me that the specification will define them and this might form part of conformance?

I think we really need to work on the registration model to see how this all hangs together. My concern is around adoption and what happens when a user goes to make their 1st payment. The exception of 'no payment methods' is going to be so prevalent we need to carefully consider this and how we deal with;

 a. Finding the relevant payment application
 b. If merchant can prefer one payment app over another if there are multiple apps that can perform the same method 
 b. Fall-back methods when no such app exists (or the shopper doesn't want to sign-up to the terms & conditions)
 c. What our expectation is for situations where the merchant wants to override the 1.0 implementations to better control the flow

 Without considering these issues, the abandoned basket issue is going to get worse before it gets better.

I think this conversation would be useful to have at the face to face and note that some of your technical issues here https://github.com/w3c/webpayments/issues/89 would suggest we will be discussing such things, however I'd like to have a specific sections both on Registration and Adoption. Ian, Adrian, Nick can we (should we) add to the agenda?

3. I think we should be defining certain common responses from the apps, with perhaps some sort of extensibility approach to define additional states. It seems to me that the 'statuses' of Authorised, Cleared, Settled etc. have meaning across many types of payment. Also a 'pending' property showing the next state transition which has been requested for the payment when there are asynchronous operations that have been requested.

Regards,
Matt




-----Original Message-----
From: Manu Sporny [mailto:msporny@digitalbazaar.com] 
Sent: 14 February 2016 20:30
To: Matt Saxon; 'Web Payments WG'
Subject: Re: Sanity check on API using flows from Flows Task Force

On 02/14/2016 12:35 PM, Matt Saxon wrote:
> 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.

Yeah, we need to fix this (somehow), not quite clear what the best approach is right now. Here's why this is happening:

The image width has been set to 100% of the browser width, if we don't do that, some of the larger flows images are larger than the width of the browser (even on a 1920+ pixel widescreen display). The image width doesn't seem to be set correctly on the PlantUML side of things (and the SVG import seems to be failing and falling back to a regular PNG image).
Because of all of this, zooming won't work correctly.

The images are being rendered in real-time based on whatever is in the flows repository by the plantuml website. Since the flows are changing, I didn't want to snapshot something that would be immediately outdated.
Since we're depending on plantuml's website, they don't seem to have configured their content negotiation correctly (or the browser isn't sending the proper Accept header). I haven't tried digging into this yet, but we'll definitely do this before FPWD.

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

Interesting, that may be another point of miscommunication in the group.
I was under the impression that the payment apps take care of the bulk of the "special processing" done by the payment scheme. I think we were planning on possibly defining what standard credit card responses look like, but not what a credit card app looks like.

I think we can specify everything up to the point at which the payment scheme takes over, and then it's up to the payment app to do it's thing and return a payment acknowledgement that is semi-standard, but mostly scheme specific. This is demonstrated in the Web Payments CG Browser API polyfill here:

https://web-payments.io/

For example, the way that you tell a successful credit card transaction happened is different from the way you detect that a Bitcoin payment was successful, which is different from the way you detect if a SEPA payment was successful.

If we were going to specify what a credit card payment app looks like (along with standard responses), that's news to me. :) I would think that Visa, Discover, Mastercard, and American Express (for starters) might want to have a say in what that response looks like (to the point that we shouldn't define it w/o them at the table). You're the expert on this, do you think there could be a standard credit card payment app?

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

I'm not sure that's possible, but very happy to be proven wrong. I think we're headed toward a switch statement that switches on the payment method.

Keep in mind that even in the "simple" credit card case - you can have multiple types of "success" events depending on your PSP - things like pre-auth, auth, capture, tokenized card number, etc., so you have to switch on those at least. If you accept Bitcoin, there is going to be a different process than for SEPA Credit Transfer, so that's going to have to be switched on... and so on.

Do you think it's possible to have a common credit card payment acknowledgement message?

> 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, as is clear from the example, I have almost no knowledge about how SEPA works. :)

Fixed by noting in the acknowledgement that payment has been initiated (not completed):

https://github.com/WICG/web-payments-browser-api/commit/b2f4d03181310aa87a37e0bc58e6288792f6e3d5

We could also add an HTTP endpoint (in the payment request) that could be called by the PSP when the SEPA transfer has completed. Is there an "automated" HTTP-based flow for SEPA like this?

Finally, is this how you were expecting the flows to be used by the API documents?

-- 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 Tuesday, 16 February 2016 19:17:24 UTC