News for hackers. Stuff that matters.
Re:Introducing PayPal’s open-source cross-domain JavaScript ... by samwillis on Monday October 16, 2017 @04:23AM (#15481676)
One of the things they touch on in this post is the impact of deciding to use a popup window for the javascript implementation of express checkout, and the fact it needs to be triggered directly and immediately by the user clicking the PayPal button. I understand the motivation for going the popup window route, it ensures that the customer can see the full URL and the security of the PayPal connection. However, I do think they have made both their own lives and the lives of customers like me adding express checkout more complicated.

Due to the popup decision, there is no way to do any form of asynchronous validation on the page that the PayPal button is installed on (your cart or in our case the checkout page). The official recommendation is to perform any asynchronous validation in the background continuously while the form is being filled and then display the results when the PayPal button is clicked. For many people this can work, however, the minute you have to do anything on the server side such as calculating shipping costs or an address validation (using a service that costs real money) this cannot work.

The only other way around it for us is to completely redesign our checkout flow from a single page (from the users perspective) to a multi-stage process where we can do all the validation we need on a ‘delivery’ page before moving onto a ‘payment’ page that requires no validation as you just click the payment method needed. This takes a maybe one day project to add PayPal to at least a weeks worth of work and the added risk of a new checkout flow and the impact on the dropout rate.

Please PayPal, give us an iframe option, like stripe checkout!

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by vim_wannabe on Monday October 16, 2017 @04:40AM (#15481725)
I love Paypal because it redirects me to the lovely paypal.com, so I don't have to input my credit card details in whateversite.com.

I very rarely subscribe to or buy anything from Stripe-only sites, and others like it, because who really knows if my credit card number and secret will get stored in yet another database or stolen by some javascript.

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by osrec on Monday October 16, 2017 @07:44AM (#15482515)
Having A/B tested both on-site and Paypal payments, customer opinion appears to be divided on this (almost 50/50 according to my tests). Some prefer going directly to Paypal, others seem to like checking out on-site.

I know from a UX perspective I prefer checking out on-site as it feels more seamless. Privacy and security are definite concerns which the Paypal brand does alleviate, however checking out with Paypal was a clunky process (it has improved in recent years, especially on mobile).

My reason for not choosing Paypal (as a vendor) is that their API doesn't feel as well thought out as stripe's and I've had my Paypal funds frozen without any clear explanation as to why!

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by bluepnume on Monday October 16, 2017 @04:28AM (#15481690)
Thanks for the comment, I'll definitely pass along your thoughts. Right now, the sentiment over here is that collecting data in an iframe creates too much of a vector for phishing attacks, so that was the main driver in the decision to use a popup. But I'd love to find a way to mitigate that.
Re:Introducing PayPal’s open-source cross-domain JavaScript ... by icebraining on Monday October 16, 2017 @10:12AM (#15483296)
For many people this can work, however, the minute you have to do anything on the server side such as calculating shipping costs or an address validation (using a service that costs real money) this cannot work.

Why? Can't you push the results back to your server when you get them?

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by jameskegel on Monday October 16, 2017 @10:42AM (#15483498)
I'm somewhat out of my wheelhouse on this topic, but one thing that came to mind was "can we trust the results of this calculation if it is done on the client computer?". Tampering could be problematic.
Re:Introducing PayPal’s open-source cross-domain JavaScript ... by user5994461 on Monday October 16, 2017 @08:20AM (#15482662)
A popup plan is the worst decision ever.

The popups will be blocked by all major browsers most of the time because of the aggressive popup blocking. Remember the 2000's when pop up were abused by all sort of evil ads and notifications. They've been blocked ever since.

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by icebraining on Monday October 16, 2017 @10:11AM (#15483286)
Popups in direct response to clicks still mostly work, as far as I know.
Re:Introducing PayPal’s open-source cross-domain JavaScript ... by adventured on Monday October 16, 2017 @10:33AM (#15483433)
> The popups will be blocked by all major browsers most of the time

That's incorrect. They default to blocking site instigated pop-ups, not user instigated pop-ups. Some versions of the Facebook & Twitter login systems for example rely on user instigated pop-ups.

PayPal wouldn't use this approach if you were right. They'd have a 0% use result. They have billions of dollars in transaction volume at stake, they're not going with an approach that guarantees a 0% outcome.

Re:Introducing PayPal’s open-source cross-domain JavaScript ... by user5994461 on Monday October 16, 2017 @01:47PM (#15485152)
>>> PayPal wouldn't use this approach if you were right. They'd have a 0% use result. They have billions of dollars in transaction volume at stake, they're not going with an approach that guarantees a 0% outcome.

Doesn't mean anything. They could have not thought of it at all, or tested it on some platforms were it worked while some others don't.

Billions dollars companies are not immune to bugs and typo. I have seen some by my own eyes.