Someone I know recently told me about her nightmare when she was collecting money for a class reunion via PayPal last month: she had to register as a non-profit, and PayPal wanted her water bill to prove that they were indeed a non-profit despite being recognized by the government as one. So much hassle; I wish I had known she was going to do that so I could have told her about WePay, especially with this kind of customer service:
A call to WePay's customer service department quickly
sorted out the problem. Plus, the company gave him $20
for the inconvenience.
Obviously I mean in the sense of a complement. And it is an accurate use of the word in that sense. WePay is the other half of online payments: PayPal is for businesses, and WePay is for people who need to collect money but aren't businesses.
i agree to some extent. our service is not directly competitive with paypal's core business. however - we consider ourselves very anti-paypal when it comes to our culture and the way we treat & market to customers
So my adult (beer league) hockey team is trying to start a slush fund so that we can pay for things like new jerseys, water bottles, shared resources type stuff. We are looking at trying to get a group account for this, and WePay looks like its exactly what we need.
But the accounts we talk to say that we would have to pay taxes on this account, if its in a bank account. Would WePay be a way to get around paying these taxes? Does anyone else have any insight to how we could set this up?
Is this question way to off topic for Hacker News?
I have long wondered why Facebook doesn't do this. Group birthday gifts, wedding registries, basically any social scenario where money needs to change hands, it seems like FB would be so well positioned to take an honest buck from.
Do you know why? Facebook acts as if it were completely incapable of knowing when far is too far. Whenever something new rolls out, it always comes off like outsourced peer-pressure. 'HEY LOOK AT WHAT EVERYONE ELSE IS DOING BUT YOU!!'
The question of whether FB as it exists now would abuse such a system (yes, of course they would, they're awful) is separate from the question of whether or not said system would make business sense for a gigantic social network.
If FB were the kind of company that could figure out how to make money without ads or taxing 3rd party devs, maybe they'd also be the kind of company that would treat its users as customers rather than products. Hypotheticals all around.
Sounds like a play from the book REWORK: Mobilize against an enemy (or something like that).
It's just words; WePay is not another competing product, it's basically a bunch of features that PayPal can implement and with >80M accounts, they can easily kill it.
Say what you want about PayPal, but each one of you should read PayPal Wars to learn the inside story of how PayPal worked and competed. They basically pioneered the person-to-person payment service and faced a myriad of issues before eventually selling to eBay.
I really hope WePay destroys PayPal. They have screwed myself and my friends too many times.
The homepage layout is all wrong though. Poor element placement, messy typography, and the color scheme is off. It looks amateur and unpolished. All those SEO'd subpages are worthless if they don't convert.
Also:
- Upgrade to Nginx 0.7.67, there was a lot of bug fixes in 0.7.65 and 0.7.66.
- Limit the number of login attempts to prevent brute forcing.
- Don't show "That email address was not found" when someone tries to recover a password. You are giving out too much info, which can be used maliciously.
- Block scraper/vuln scanner/curl scripts by user-agent to keep away the script kiddies and botnets.
- Don't host your Javascript on Google. This gives hackers another possible point of entry. It's probably safe, but you're better off limiting points of entry.
- Use mod_rewrite as an additional layer of security. You'll need to slightly modify it to make it work with Nginx.
- Remove "access info anytime" and "post to my wall anytime" when signing up with Facebook.
Thanks for catching that. We've spent the last week moving into a new office and it must have slipped by as we were getting everything reconfigured. It's been locked down again.
I must admit I didn't know the big domains disabled ssh. Naive/beginner's question: how do programmers work remotely at these companies (if it's allowed at all)? Do they ssh into other (safe) servers, from which a safe transfer is eventually made into the production servers?
You could set it up by allowing sshing to a server on a subdomain something like ssh.xyz.com or vpn.xyz.com and from there can ssh to production servers, which are set up to only allow ssh internally.
It's a matter of setting up VPNs and IP-restricting where you can SSH in from. You can also set up port knocking and other SSH-related security measures. It depends how much convenience you're willing to trade for security.
Practicality trumps everything, after 10+ years of using ssh and trying port knocking and everything else none of it works when you're 4000km away in another country with only a handheld to access the servers.
I think it should probably company policy at a financial institution not to allow someone in a different control on a handheld device to access the servers.
I use layered security (in the sense of servers) with a password lifetime of 10 days. I deal with servers daily and the issue of compromise has been twice in on firewall containers/servers which was fine as the systems in place found it, found the issue with the net facing software and I fixed it. Practicality doesn't mean no security.
Can you require keys AND passwords? I haven't been able to figure out how to get that to function - if passwords are allowed, it lets you in with or without a key, from what I can tell.
I'd be happy to be wrong though!
Generally you VPN in (using two-factor auth for PCI compliance) to a private network and can SSH in from there. Public facing SSH is generally a bad idea. Also it didn't seem like they had any firewall rules preventing brute forcing.
Don't necessarily turn it off. Make sure you've hardened SSH, only do key-based authentication and limit access to specific source IP addresses or use something like fail2ban.
Then spend the time to properly look at your information security requirements and develop a plan to comply with them.
If you just turn off SSH you're going to have a lot of pain with little gain or loss if it's properly configured.
Just out of interest, how many 0day pre-auth OpenSSH vulnerabilities are you aware of? The last publicly disclosed pre-auth OpenSSH vulnerability that if exploited would lead to arbitrary code execution came out in 2006.
I'm not saying that SSH 0day doesn't exist, but why SSH and not other 0day for say a VPN or the HTTP server? I think I see what you're saying, perhaps that SSH 0day is more valuable and less likely to be publicly disclosed but without any data on attacks in the wild, someone at wepay needs to make a risk decision.
My main point isn't that they shouldn't harden their platform, on the contrary I think they should, but they need to do so in a structured manner that doesn't leave them with a bigger mess to deal with. Hardening SSH isn't hard, hardening an IPSEC 2FA VPN is going to be a different story.
> but why SSH and not other 0day for say a VPN or the HTTP server
More hosts have SSH than VPN available. SSH is pretty much standardised in comparison to VPN. VPN touches mostly certificates and network interfaces, while SSH touches the whole authentication stack, so there's a possibility of exploiting whatever pam environment you're using. Also, you can drop root in most VPN solutions, but not in SSH (by design).
Sure - hardening SSH is enough and most likely thing to do in case of standard servers. But if you're providing some special services... why not add the special protection?
> - Don't show "That email address was not found" when someone tries to recover a password. You are giving out too much info, which can be used maliciously.
Does this really matter if a site only allows 1 registered user per email address? I can farm this information by trying to sign up a new account.
Even if this is true[1], it never hurts to consciously limit the places where information flows out of your system. The idea is that securing one point is easier than securing n points.
[1] I don't doubt the flow of information, but the rate at which that information can be leaked through a signup page can be severely limited compared to a password recovery page.
Most websites out there don't actually require a captcha for signup. Paypal certainly doesn't. (I'm not going to create a fake wepay account to check if/when they do email uniqueness validation.)
can you be more specific about how we can improve the home page? we're constantly trying to improve it, but our oldest (and admittedly ugliest) one always converts the best. tell me the dominant page color and i'll know which version you're looking at.
White and blue are good colors for your industry, but the current homepage has too much blue above the fold. The blue is slightly too vibrant also. You want to be careful about the saturation of your colors. Vibrant/Saturated colors are subconsciously distracting and unprofessional. The hurdle to trust a vibrant website is much higher.
"WePay helps you collect, manage, and spend money." should be displayed above the fold and have embedded screenshots or an embedded video nearby. I don't recommend popping it up in a lightbox.
Include a "create account" link near your "Sign in" link. The top right corner is prime real estate and needs a call-to-action for current users and potential users.
The site seems segmented because of the various different styles and content widths used. I found three different widths so far (1010px, 960px, and 770px).
The logo needs to go. It's really bad.
Move "featured in" to the bottom.
Move "What kinds of groups are using WePay?" up more. Remove the italics on the links.
Take a look at this: http://i.imgur.com/4zHX7.png - I threw it together in 5 minutes, so don't judge it too much. White is the primary color here and you'll notice that it is visually easy to follow. Looking at the current WePay is actually straining on the eyes.
The blue is slightly too vibrant also. You want to be careful about the saturation of your colors. Vibrant/Saturated colors are subconsciously distracting and unprofessional.
This is completely subjective though. To me, for instance, We Pay's current webpage looks like a site I might use for the scenarios described in the NYT article, like a way to collect payment among a group of friends. Your mock-up looks like the site of a bank or mutual fund, which is exactly not the sort of site that comes to mind for the purpose. Again, this is completely subjective - I just don't think there is any way to justify something as vague as 'vibrant is unprofessional'.
Don't host JS on Google? Do you mean libraries like jQuery? I'm curious because we use Google for jQuery and a few other libraries. I've never heard this to be a security issue, and I'm not entirely sure how it would be. Nonetheless, security is all about cost-benefit, it may be worth the security risk for the page load speed increase with Google.
It's a security issue because someone can compromise google's CDN, or cache poison, or DNS poison/hijack that, and can inject malicious JS code into a large number of websites with one attack. If you're running a payment related it pays to be paranoid.
One of the best pieces of advice I heard at Startup bootcamp came from Bill Clerico (WePay CEO) when he described building software as a community process. It seemed like an elegant way to say users are what really matter and it applies equally well to commercial, open source and personal projects.
