W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: Call for reviews of HTTP API and Core Messages proposals

From: Jason Normore <jason.normore@shopify.com>
Date: Thu, 5 May 2016 12:15:41 -0500
Message-Id: <CA+3U0utTDj=-Q-iJhpLXkBZZdp893yEc6zGfWi_4Q1eBKZa1DA@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>, public-payments-wg@w3.org
Manu, here’s some high level feedback, I apologize last minute review.

1. Email any review comments you have back to the mailing list.

I mention in a comment below that I think we should strive for a common spec for the language of the checkout experience but with different mechanisms for communicating it on different platforms and mediums (this was also mentioned in other feedback I believe). My only real feedback is around this, and the following should be framed in that context.

I'm a little concerned that using there 402 response code is limiting the scope of where this could be used. It seems that 402 is great for a pay-wall experience: no access to this resource unless you pay, all or nothing. This is also a valid, and even common, use case for browser based commerce applications but not the only one, or at least not the one that allows for the best experience. When you break it down, merchants want to say "something here is for sale", then provide product and pricing information that the customer can use to determine whether they want to purchase or not, they purchase and the product is delivered in whatever mechanism is appropriate (physical shipment, digital delivery). The browser spec doesn’t use 402 right now because it doesn’t need to in order to provide the best experience, is this really the best approach for the HTTP API given that it’s meant to solve the same problem?

2. Let us know if you think the work should be taken up by the Working Group.

+1 for this. See comments in #3 for why.

3. Note how important the work is to your organization and mention what you think its priority should be.

We represent the merchant and PSP in most cases so our priorities are to provide the merchant with the best possible experience for their customers but also make it easy for any payment provider to integrate into our platform.

I think the case of providing the best possible customer experience is a given in the WG in terms of priority, we all know how important it is so I won't go into it much. The one point I do want to make regarding it is that merchants have a wide range of data and experience requirements that we should strive to provide them a facility to enhance, or at the very least not give them something that prevents them from meeting these requirements while still giving their customers a great experience across whatever sales channels they want to use.

When it comes to allowing payment providers easy integration (easy access to merchants, and merchants easy access to them), because we host the merchants commerce solution, including facilitating payments, it's important that we're able to provide a standardized path to integration for any of the many existing payment methods (each with many providers) as well as the many new payment methods we'll see in the future.

Although today most online commerce is in browsers, this may not be the case tomorrow, it's important for us to provide this standardized experience to connect merchants, customers, and PSPs across any platform or medium. In terms of priority, the majority of online commerce happens in browsers today so this would fall to the top of the list for us but the HTTP API is important for the future so we'd like to see the WG focus on this in parallel to see it actually built but also to ensure we have as much common components as possible, as common language for facilitating the checkout experience with different mechanisms for transporting the data would ensure adoption.

Jason

--
Jason Normore
Director of Engineering, Shopify


On Thu, May 5, 2016 at 10:40 AM Manu Sporny <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>> wrote:
On 05/03/2016 03:37 AM, Tommy Thorsen wrote:
>
> I'm a bit concerned about your "Accept: text/html;application/json"
> use case because it makes a number of assumptions that are not
> clearly spelled out in #128.
>
> For example, the HTTP API could most likely depend on standard
> authentication mechanisms like Digest, HTTP Signatures, Negotiate,
> OAuth, etc. This is what this demo will do in time:
>
> http://http-mediator-demo.web-payments.io/ <http://http-mediator-demo.web-payments.io/>
>
> I guess you're right, but does that mean it's not really feasible to
> unify the two payment app types?

It depends on what you mean by "unify". One could argue that the same
payment app can have two interfaces, but share the same messages, and
doing so would make much of the processing back-end of the payment app
identical (and that's a good thing).

That is, the only thing that changes is the protocol used to access the
payment app. The back-end logic remains the same.

> HTTP Payments and Web Payments already use different user-agents.

They don't have to. You can imagine a scenario where a payment mediator
(aka user-agent) can execute both HTTP API-based payments and Browser
API-based payments. I'm not saying that's the norm (I don't know what
will be), but we shouldn't rule some of these scenarios out.

> And the payee will need bespoke implementations for each of the two
> payment types. If the payment apps can't be shared either, what is
> common between the two systems?

The payment apps can be shared. For example, if you use the same login
credentials when registering, you get the same payment app.

> Only the format of the request and response messages? That's not a
> whole lot...

The request and response messages /and/ the business logic. Those are
pretty significant parts of a payment app. The only thing that is
different is the protocol used to access the payment app (and even that
isn't necessarily true). One could imagine a few scenarios where a
browser /could/ purely use an HTTP API to access a payment app if, for
example, it only requires Digest-based authentication to approve the
transaction and the browser knows the username and password for the
payment app website.

> If HTTP Payments and Web Payments do not share anything meaningful,
> then we are creating two entirely separate ecosystems, rather than a
>  single ecosystem which is accessible via both Web and HTTP.

I hope were creating the latter, and to modify your language a bit...
we're trying to make the ecosystem accessible via browser protocols and
the HTTP protocol... both of those things are considered by many to be
"the Web". :)

> Katie Haritos-Shea spoke earlier about how important the HTTP
> Payment specification is to accessibility. Now, increased
> accessibility is something I am very much in favor of, but I wonder:
> if HTTP Payments is not a method that lets users with disabilities
> interact with the grand ecosystem used by everyone to make payments
> -- but instead is a method that lets users with disabilities interact
> with a completely separate ecosystem from what everyone else is using
> -- does it still have value?

It does. Just because you don't use wheelchair ramps and handicap
accessible automatic doors doesn't mean that those things don't have
tremendous value to those that need to use those systems out of necessity.

> And who will create this separate ecosystem?

It's not a separate ecosystem just like a wheelchair ramp access isn't a
separate ecosystem from building access. We're talking about making it
easier to access the single Web Payments ecosystem using any device or
client. It's about choice in how you access the ecosystem.

As for who pays for it, society usually does (and thus government and
private industry) via ensuring that they are compliant with
accessibility regulations.

>> Also, does the browser load the text/html page into a secure
>> context without a URL (the user is not redirected to the payment
>> app website) or does it redirect the user to the payment app
>> website?
>
> All the details aren't clear here, but I think it will load it as a
> regular web page with a url and everything. However, the payment app
> will be loaded in a separate context (much like a webview overlaid on
> top of the regular browser).

+1

>> How do native payment apps work? How does the browser send the
>> payment request to the native payment app? Via native OS messaging,
>> or are we requiring native payment apps to open HTTP ports on
>> localhost? And if we do that, what are the security implications?
>
> I don't know how the native apps will work. I think for mobile
> platforms, it is completely up to those that own the platform to
> decide how this should work, and we couldn't dictate this to them
> even if we wanted to.

+1

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/ <https://manu.sporny.org/2016/json-ld-context-caching/>



Received on Thursday, 5 May 2016 17:17:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 May 2016 17:17:38 UTC