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

61–70 of 120 posts

Re: Why we ditched PayPal for Stripe

#61

Post by yangez »

lsh123 wrote: post #54
dangrossman wrote: post #53

Earlier quoted context omitted.

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.

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

Re: Why we ditched PayPal for Stripe

#62

Post by saurik »

stickfigure wrote: post #58
ytadesse wrote: post #45

Earlier quoted context omitted.

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.

In this thread I provided a few specific areas where Stripe's API seems downright primitive: no way to do chargeback reconciliation ("chargeback" isn't even in their documentation anywhere, which should be an immediate red flag), and a "webhooks" model that does not retry on server failure (meaning you cannot trust you will actually receive the notifications, and will have to rely on polling them for updates). Is there something in specific you did not like about PayPal's API?

I will be the first to say there are warts, but the warts are really far down in the trenches (I only noticed them after using them for years; I did my initial PayPal integration in less than a day): Stripe seems to be missing important things upfront.

Also, I am confused what you mean by "electronic forums"; do you mean like an online ticket site? I have filed numerous tickets against PayPal, and they have always been answered within a few hours during the day; they even have people available to respond to integration issues in the middle of the night.

Re: Why we ditched PayPal for Stripe

#63

Post by kamaal »

michaelschade wrote: post #43
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 have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does. I'm not holding that against them though: it's only one mediocre experience, and I have not used them much because of the whole payment redirection thing (I did not know about their Pro account then). To be clear: I'm not actually saying that PayPal is bad. I don't have enough experience with them…

I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does.

Well, talking of facts small companies with a small customer base will always deliver better customer service than the larger ones. True test of these companies will come when their subscriber and customers run into millions(In paypal's case hundreds of millions).

Imagine a situation where where 283 million registered customers and probably more unregistered buyers. Ensuring operations related to that magnitude of people work fine for 99.99% of the people, 99.99% of the times. And then ensuring the remaining get appropriate customer support is not just difficult but requires a lot of work to maintain and run.

At that scale the founders will have a lot more different work to do. And addressing one user out of those hundreds of millions by communicating them on twitter might not scale properly. And the customer support employees are working in call center shifts. They are not going to be any more enthusiastic any more than other general call center employees.

Coming to arcane policies, Now for all those millions of users. There are definitely going to some x% of crooks out there gaming the system. Frankly speaking if you don't have such policies you may actually end up putting a lot of your other buyers and other customers in trouble and expose them to fraud. The problem is in programmatically handling hundreds of millions of users and their problems is not easy. You can build a system to do payments et al, but that's only beginning. So any good payment gateway etc will ultimately end up looking like PayPal.

PayPal works at a scale, Whether a new competitor will work at scale is question of time.

But don't write PayPal off, It actually works well for those hundreds of millions of registered and more unregistered users.

Re: Why we ditched PayPal for Stripe

#64

Post by powertower »

MichaelGG wrote: post #41
powertower wrote: post #35

Earlier quoted context omitted.

> not wanting to redirect or otherwise interrupt the normal order process of my site with another company's (branded) checkout form just to handle credit card payments. That's a restriction only for the free accounts. With the Pro account ($30/month) you use the API and your customers never leave your site.

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?

Require? No.

Unless you do more than 20k CC transactions/year, OR store CC numbers directly on your server, no one is going to require much of anything from you except one of those fake website scans.

Re: Why we ditched PayPal for Stripe

#65

Post by dminor »

tptacek wrote: post #29
mrkurt wrote: post #23

Earlier quoted context omitted.

Out of curiosity, how does an embedded iframe let you avoid PCI completely and an external javascript lib not?

There is no good reason for any of these backdoors around PCI, except for the fact that everyone knows it's not going to be feasible to "test"† every website anywhere that does any commerce. It's probably best not to ask too many questions. It'll only hurt your brain. † (If that's what you want to call PCI assessments)

Another thing to keep in mind is that PCI scope and PCI requirements expand with every iteration, so today's backdoor may be gone tomorrow.

PCI compliance is ridiculous enough that it's still worth avoiding though, even if only for the short term.

Re: Why we ditched PayPal for Stripe

#66

Post by saurik »

yangez wrote: post #61
lsh123 wrote: post #54

Earlier quoted context omitted.

I think the better description would be: You are on the hook as soon as your code touches credit card data.

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

Some discussion:

http://stackoverflow.com/questions/4219636/pci-compliance-an...

Re: Why we ditched PayPal for Stripe

#67

Post by lsh123 »

yangez wrote: post #61
lsh123 wrote: post #54

Earlier quoted context omitted.

I think the better description would be: You are on the hook as soon as your code touches credit card data.

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

You might want to talk to your PCI QSA to get a professional opinion. My views are explained here:

http://news.ycombinator.com/item?id=3332001

Said that, you might want to think beyond PCI. Security is as strong as your weakest link and you might want to "play" in your mind a few scenarios: what if there is an XSS attack? what if your employee goes "rogue"? what if your server is hacked? Then you will need to decide what is important for you and how much risk you are willing to tolerate. Different solutions (Stripe + javascript, WePay + iFrame or redirect, PayPal, traditional payment gateway, etc.) will give you different upsides and downsides in usability, security, international support, price, customer support experience, ... There is no silver bullet :)

Re: Why we ditched PayPal for Stripe

#68

Post by lsh123 »

gtaylor wrote: post #56
lsh123 wrote: post #40

Earlier quoted context omitted.

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.

Someone already said in this discussion that PCI compliance is a legal term :) To some degree, it is a deal between you and your QSA (or you again if you are doing self-assessment). I heard about a few businesses that accept credit card numbers w/o bothering to do anything about security at all. You will need to decide for yourself the acceptable risk for your business in various "things gone bad" scenarios and how much you want to invest in protecting against scenarios that are bad for your business.

We've designed WePay solution to make it "out-of-the-box" as secure as possible for both our partners and WePay. We plan to offer more customization options in the future to improve usability while keeping it simple and secure to use. Doing security right is hard. We believe that WePay can help with it and make our partners life easier.

Re: Why we ditched PayPal for Stripe

#69

Post by airlocksoftware »

yangez wrote: post #61
lsh123 wrote: post #54

Earlier quoted context omitted.

I think the better description would be: You are on the hook as soon as your code touches credit card data.

Is this true? I was under the impression that if we used Stripe's javascript function to tokenize credit cards, we get to skip a lot of PCI compliance stuff we would otherwise be responsible for.

I used to work as a low-level tech for one of the largest PCI compliance providers. For smaller merchants (I think less than 20k? transaction per year) there's 4 levels of compliance: A, B, C, and D.

A is for merchants who redirect to another site or use an iframe (like paypal). B is for merchants who use a dial up terminal. C is for any merchant who accepts credit card information electronically (i.e. an internet connected terminal or a website with no redirect / iframe). D is for anyone who stores credit card information.

A & B just require you to fill out a self-assessment indicating you're aware of the rules and following them. C & D both require "scans", probably of your website or server (at least a couple hundred dollars, if not more).

Post reply on HN