
Introducing PayPal’s open-source cross-domain JavaScript suite - bluepnume
https://medium.com/@bluepnume/introducing-paypals-open-source-cross-domain-javascript-suite-95f991b2731d
======
samwillis
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!

~~~
user5994461
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.

~~~
adventured
> 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.

~~~
user5994461
>>> 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.

------
jarym
This is great, in enterprise software we often have to resort to a bunch of
front-end integration using iframes and this set really helps.

------
zengid
Just a general question but were there any unexpected vulnerabilities
discovered through developing these tools? I haven't taken a look into the
code but from the descriptions of the limitations with iframes and cross-
domain windows it seems like your having to hack around the barriers and
venture into unsettled territory.

~~~
bluepnume
We didn't discover any new real browser vulnerabilities, thankfully -- mainly
just browser's being overly protective in some cases.

Most of the hacks were just to get IE up-to-par with the other browsers. For
example, to send a postMessage between a popup and the parent page, the only
way is to place a hidden iframe on the parent page, with the same domain as
the popup. post-robot abstracts most of that away.

The line we had to walk in terms of security was, on top of not introducing
any new vulnerabilities ourselves, making sure we didn't make it too easy for
people to accidentally introduce any security loopholes using what we've
built.

For example -- the idea of passing a function over to a different window is a
fairly novel concept. The idea is, if you want to give the other window
control over something, say to log out a user, you can just pass a
`user.logout` function directly in a message to the target window. But then
there's a risk people will absentmindedly pass functions in messages that they
didn't expect to.

But then, on top of that, there's a lot we can do automatically to protect
users, that doesn't happen automatically with regular browser apis. For
example, if you render an xcomponent with a certain url, xcomponent will (by
default) ensure that only messages from that domain are allowed up from the
iframe. Which is something you'd need to remember to do manually if you were
just listening for post-messages.

------
ukulele
I want to be excited about this and plan to look into it... mostly I'm
sincerely hoping PayPal hasn't taken their standard pile-of-garbage approach
to documentation...

~~~
bluepnume
If you see anything that's less than clear, or missing from the docs, please
let me know! These tools only have a modest number of users right now, so we
appreciate all the feedback we can get.

------
themango
oh yea commonwealth!

------
chemmail
Paypal plus javascript? Pass.

~~~
dang
Please don't post snarky dismissals here. We're hoping for a higher quality of
discussion than that.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

