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

Hey Matt,

I think all of these are good discussion points for the WG:


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

Can you add them to the thread Manu started:
https://github.com/w3c/webpayments/issues/89 ?

Thanks,
Adrian

On 16 February 2016 at 21:16, Matt Saxon <matt.saxon@gmail.com> wrote:

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