Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we ditched PayPal for Stripe

gc-taylor.com

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Why we ditched PayPal for Stripe

#51

Post by mattmillr »

"We investigated some traditional payment processors like Braintree and Authorize.net ... A lot of traditional gateways have long, complicated setup processes, often involving sales calls and working with banks. ... They also typically require you to send credit card data through your servers, which means obtaining a level of PCI Compliance (not that we aren't already security-conscious)."

I've used both of these. Braintree may not have been the right choice in their situation, but grouping them with Authorize.net for these reasons isn't really fair. Braintree's bundled merchant account and gateway services are much easier to set up, and their transparent redirect eliminates the need to handle card data on your own servers.

And in my experience, their "We (heart) developers" motto is, well, true. They have really great, friendly support. Braintree and Authorize.net are miles apart. At least as far apart as Stripe and PayPal.

Re: Why we ditched PayPal for Stripe

#52

Post by moses1400 »

moses1400 wrote: post #31

We switched to Stripe from Paypal and Google Checkout a month ago and so far I've been very, very pleased. I plan to do a writeup of why we switched soon - wanted a bit more results first. FYI, Stripe launched a new web interface 2 days ago. The net bottom line was this: 1. our customers (business people who are not super tech savvy) just don't understand that you can pay with a credit card on paypal and google check…

BTW - I made a post about the switch for us: "Moving to Stripe: Fixing the Biggest Mistake I’ve Made to Date"

http://www.centernetworks.com/stripe-from-paypal-google-chec...

Re: Why we ditched PayPal for Stripe

#53

Post by dangrossman »

aysar wrote: post #49
MichaelGG wrote: post #41

Earlier quoted context omitted.

But doesn't that API require you to submit the card number to them from your server and hence makes you have to do a ton of PCI compliance work?

Would like to know more about this- i thought the whole point of it was that you didn't have to deal with PCI... Edit: i just checked; https://www.paypal.com/pcicompliance It looks like Paypal takes care of PCI compliance only if you use; PayPal Website Payments Standard, Email Payments, or Payflow Link. Otherwise you're on your own.

It's common sense once you boil it down to this:

If someone's credit card number hits your server at any time, you are liable for a proper level of care for that information. The proper level of care in this case is set by the payment industry in the form of PCIDSS (the Payment Card Industry's Data Security Standards).

So setups where the data goes through you, you're on the hook.

Where you're sending someone to an external site to pay, in a frame or otherwise, then you're not.

A quick glance at the implementation guide for any payment system, present or future, is enough to know who's on the hook for PCIDSS just by seeing whether the card number's gonna get POSTed to your server or someone else's.

Re: Why we ditched PayPal for Stripe

#54

Post by lsh123 »

dangrossman wrote: post #53
aysar wrote: post #49

Earlier quoted context omitted.

Would like to know more about this- i thought the whole point of it was that you didn't have to deal with PCI... Edit: i just checked; https://www.paypal.com/pcicompliance It looks like Paypal takes care of PCI compliance only if you use; PayPal Website Payments Standard, Email Payments, or Payflow Link. Otherwise you're on your own.

It's common sense once you boil it down to this: If someone's credit card number hits your server at any time, you are liable for a proper level of care for that information. The proper level of care in this case is set by the payment industry in the form of PCIDSS (the Payment Card Industry's Data Security Standards). So setups where the data goes through you, you're on the hook. Where you're sending someone to an e…

I think the better description would be:

You are on the hook as soon as your code touches credit card data.

Re: Why we ditched PayPal for Stripe

#55

Post by aysar »

foxylad wrote: post #46

The usual gripe - my company is based in New Zealand, and it's well nigh impossible to open a US bank account so we can't use Stripe or Wepay. I'd love to know how many of PayPal's merchants are non-resident, it's the only reason we use them. In fact, if it wasn't for PayPal non-US websites selling to the US would be almost impossible. The US has a massive advantage in that the rest of the world is happy to pay in US…

Yup, i'd switch to either Stripe or WePay- tbh, being based in Canada... Stripe/WePay guys make it seem like we're foreigners o_O

Re: Why we ditched PayPal for Stripe

#56

Post by gtaylor »

lsh123 wrote: post #40
boucher wrote: post #32

Earlier quoted context omitted.

We at Stripe (and more importantly, our PCI auditors) don't agree with this assessment of how the chain of responsibility works. When you use Stripe.js, you need only serve your page over SSL and verify that you aren't collecting credit cards through other means to be PCI compliant.

Disclaimer: I work for WePay and I am directly responsible for WePay's PCI audit process I am sure everyone would agree that PCI spec is complex and not easy to understand :) Said that, its intention is pretty clear: protect credit card information from leaking to "bad" guys. A great deal of PCI spec is about protecting the stored credit card data. You are absolutely correct that Stripe's JS solution allows one to av…

I guess you could say Stripe gives you the shotgun, but you have to decide whether you want to use it properly, or blow your foot off.

So basically: Be smart about what goes on your sensitive, mission-critical payment-receiving pages, as you should be. It's not extremely difficult. A little bit more responsibility in turn for more flexibility.

Re: Why we ditched PayPal for Stripe

#58

Post by stickfigure »

ytadesse wrote: post #45
saurik wrote: post #34

Earlier quoted context omitted.

I am curious if you've ever actually called PayPal. I have received nothing but high quality support from them. You can call them throughout most of the working day (until 8pm PST, I believe), and they seem to have somewhat knowledgable engineers available at that tech tier. They also have a merchant technical support site that seemingly no one knows about where you can often get answers in the middle of the night (I…

I second that. I've had to call PayPal a few times due to integration issues and the people on the phone (all 4 I spoke to) were beyond kind and helpful. Unfortunately, everyone is coming out the woodwork now to get their two shots in while PayPal is down.

Telephone support is not an adequate substitute for sane API design and good documentation. Or, for that matter, electronic forums where I can write complicated questions and get complicated responses.

Re: Why we ditched PayPal for Stripe

#59

Post by _gd3l »

I'm not enough of a developer to integrate completely with stripe, but we've been making the change to Dwolla.

Anything is better than PayPal. I appreciate their contributions to epayment, but their time has passed.

Other great options out there include Square, MoneyBookers, and Dwolla (if anyone is looking to leave PayPal after this article and the recent Regretsy one).

Re: Why we ditched PayPal for Stripe

#60

Post by gtaylor »

80cols wrote: post #57

Sounds like one of the main advantages of stripe is the API. I wonder if anyone is working on making payments platform-independent so it's easy to switch between payment providers.

Most of the gateway-style services operate very similarly. We wrote some abstractions to allow us to eventually add Braintree or Authorize.net, since the payment cycles are much alike (from the API perspective). It only gets difficult when you try to mix-and-match something that uses redirects/iframes with services that deal directly with credit cards from your server to theirs.

We just don't want to get into PCI audits and scans just yet, but once we do, we'll probably use Stripe's direct server->server APIs like Braintree/Authorize.net do instead of stripe.js.

Post reply on HN