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:

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

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

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

Received on Sunday, 14 February 2016 20:29:56 UTC