This is great! I've implemented the PaymentRequest API on a couple of my apps, and customers have really liked the user experience on mobile chrome. This is another positive step towards PWAs becoming more ubiquitous (I strongly believe PWAs will play a bigger part in the app ecosystem in the near future). I can imagine Apple will feel a bit more comfortable with web apps if they could conduit payments via apple pay more seamlessly - I hope things like this help remove some of the dev inertia on their side and make safari more suited to web apps.
Payment Request API
101–110 of 128 posts
Re: Payment Request API
#102Earlier quoted context omitted.
Mozilla Persona suffered from the problem that its developers abandoned it shortly after releasing it, rather than making any attempt to get it into browsers. The pop-up dialog wasn't how it was supposed to work, that was a fallback (and apparently a slightly confusing one) - there was supposed to be a little login widget in your address bar that you'd interact with, and it'd be fully integrated into your browser's U…
I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona: https://www.youtube.com/watch?v=3dDGkLHOldw In it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further: Persona had a "…
The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given browser in localstorage.
Being able to click "log in" and have logged in, and having functional single logout, with a decent UX over the whole thing, is the holy grail. Facebook has the current solution, and browsers don't. Portier does not even attempt to solve the same problem as Persona did, and by being a "self-hosted" application, it can't.
Re: Payment Request API
#103Wonder how this impacts Stripe
I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
Like browser auto-fill for CC fields, which is already supported by most browsers?
Re: Payment Request API
#104Earlier quoted context omitted.
I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona: https://www.youtube.com/watch?v=3dDGkLHOldw In it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further: Persona had a "…
The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given…
I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example.
And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/).
Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non...
At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.
Re: Payment Request API
#105So currently, users are often redirected to the 3rd party payment service or interact with an embedded form offered by the 3rd party service and the user either has to register/login. Does this mean, in the case of PayPal, users will have to install the PayPal Payment API App on their browsers?
[deleted]
Re: Payment Request API
#106Earlier quoted context omitted.
Alright "run" wasn't the right word, "heavily influenced by" is probably better. They just seem to continuously standardize things that are very user hostile and only serve content distributors.
> continuously standardize things that are very user hostile and only serve content distributors. Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?
Web workers are pretty bad if you're looking for another one.
Re: Payment Request API
#107Earlier quoted context omitted.
The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given…
I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example. And the use case…
Portier basically uses WebFinger and OIDC under the hood, with some UX tweaks to make it easier on users to fall back on email auth.
One of the best-case scenarios for Portier is if WebFinger/OIDC were to become widespread and Portier itself somehow obsolete.
I am affiliated with the project but have been putting in much less time than I'd like, admittedly.
Re: Payment Request API
#108Earlier quoted context omitted.
The API doesn't have any additional fraud exposure. The fraud exposure is due to identifying information, or access therein, being stored on and/or directly provided by the client in this model. Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted. Also, all major card networks - Visa, MasterCard, AmEx - and many payment processors - Stripe, Worldpay, etc…
> Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted. Except this is exactly how Android Pay and Apple Pay work: they store the billing information on the client side. A large part of the impetus behind Payment Requests is to open up Android Pay and Apple Pay to the web. And all(?) major browsers support autofilling card details already, which means sto…
Except this is exactly how Android Pay and
Apple Pay work: they store the billing
information on the client side.
The PAN and related data is stored securely on Apple's servers (or, more likely, PCI compliant servers provided by Paymentech). This is why merchants have to accept these payment methods specifically and not treat them as "regular" card-not-present transactions.
Re: Payment Request API
#109Earlier quoted context omitted.
I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
Like browser auto-fill for CC fields, which is already supported by most browsers?
I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example).
Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce).
So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
Re: Payment Request API
#110Earlier quoted context omitted.
> continuously standardize things that are very user hostile and only serve content distributors. Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?
Web workers are pretty bad if you're looking for another one.
[deleted]