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

31–40 of 120 posts

Re: Why we ditched PayPal for Stripe

#31

Post by moses1400 »

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 checkout requires a google account 2. the "go off and pay" somewhere else and come back to the main site is messy

I have no real complaints with paypal over the years we used them so I can't bash them but I found that over time, we lost sales because people were confused. Now there is no more confusion - fill in a few fields and instantly you are done.

We also considered Braintree which I was also impressed with but decided on Stripe because of the non-need for a merchant account.

I am happy to answer any questions here or privately if needed.

Re: Why we ditched PayPal for Stripe

#32

Post by boucher »

LeBlanc wrote: post #26
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?

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the…

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.

Re: Why we ditched PayPal for Stripe

#33

Post by pazimzadeh »

saurik wrote: post #22
michaelschade wrote: post #16

The post is spot on. My initial attraction to Stripe was because of a reason mentioned in the post: 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. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API ( shu…

You almost always get amazing customer support from early stage companies. I'm certain people got amazing customer support from people high up at PayPal when it was just starting. You cannot judge a company on whether a co-founder responds to you on Twitter in a short period of time, and if you did, you should probably judge it negatively: I would wonder what was wrong with PayPal if someone that high up had enough t…

Either way, Stripe is the best solution at this moment. If Stripe ever ever becomes big and bloated like PayPal, hopefully a new startup pop up to compete with them.

Re: Why we ditched PayPal for Stripe

#34

Post by saurik »

michaelschade wrote: post #30
saurik wrote: post #22

Earlier quoted context omitted.

You almost always get amazing customer support from early stage companies. I'm certain people got amazing customer support from people high up at PayPal when it was just starting. You cannot judge a company on whether a co-founder responds to you on Twitter in a short period of time, and if you did, you should probably judge it negatively: I would wonder what was wrong with PayPal if someone that high up had enough t…

That's somewhat a fair point, but I'll disagree. In that instance, the co-founder replied, but I've heard from a number of Stripe's other employees since then, and in every case the customer support has been wonderful. Perhaps that's solely because they are still a startup, but given what I know now about the people themselves, I don't believe that to be the case. I don't mean my original comment to suggest that the…

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 often get responses back at 12:30). If you are even reasonably sized you can also ask for a dedicated account manager: I have the cell phone number of someone at PayPal whose job it is to find me answers to problems I have.

Though, I cannot say PayPal is perfect. I have run into a bunch of annoying issues correlating settlements (bugs filed recently, will be curious to see if they get fixed), and their pricing is not the best that is out there (although is still better than Stripe). I am curious if you've looked into any alternatives. I've spent the last few days talking to Litle & Co, and I must say that the people there /love/ talking to you about payments... their booth at ad:tech was the most enjoyable conversation I've had about payments in a while, and I got to spend another half hour on the phone with them yesterday learning more about how bank ACH settlement works.

Edit to reflect your edit ;P

That is the page I just had gone and reviewed now. It still seems incredibly manual. I would not feel comfortable running a site at scale where I'm dealing with receiving e-mails in an undocumented (probably designed-for-humans) format as my only source of notifications for chargebacks. :(

It is often these "at scale" issues that are seemingly not handled by them; example: per their API page, Stripe does not resend webhooks if there is an error in the response... doesn't this make them useless to rely on? Am I required to sit around and poll my transactions to feel 100% certain that I didn't miss something because my load balancer accidentally gave them a 503 during some traffic spike? :(

Re: Why we ditched PayPal for Stripe

#35

Post by powertower »

michaelschade wrote: post #16

The post is spot on. My initial attraction to Stripe was because of a reason mentioned in the post: 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. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API ( shu…

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

Re: Why we ditched PayPal for Stripe

#36

Post by tptacek »

boucher wrote: post #32
LeBlanc wrote: post #26

Earlier quoted context omitted.

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the…

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.

We don't do PCI assessments (I have a generally low opinion of the process), but we do the "real" appsec work for lots of companies that do, and the impression I have is that --- counter to what you'd expect --- 'boucher is right, and you can self-assess using their interface, despite the fact that anyone doing so is in fact an XSS flaw away from giving up cards.

In particular, while I have no idea whether Stripe's implementation is letter-of-the-law PCI compliant, I do know that 'LeBlanc's reasoning is not PCI reasoning (particularly: you can't draw a line from architectural susceptibility to "liable to audit") --- even though it's the reasoning I myself would use.

Re: Why we ditched PayPal for Stripe

#38

Post by LeBlanc »

boucher wrote: post #32
LeBlanc wrote: post #26

Earlier quoted context omitted.

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the…

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.

Sorry, I should have made it more clear that with stripe you aren't liable for all of the PCI spec (I edited my comment to reflect that).

Either way, I think Stripe is doing awesome work and I hope you keep kicking ass!

Re: Why we ditched PayPal for Stripe

#39

Post by michaelschade »

powertower wrote: post #35
michaelschade wrote: post #16

The post is spot on. My initial attraction to Stripe was because of a reason mentioned in the post: 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. The other reason for initial attraction was of course their elegant API, which was very refreshing to see after having dealt with Intuit's QBMS API ( shu…

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

Thanks, I wasn't aware of that.

Edit: I was looking at it more and, as MichaelGG pointed out, I think it still means that you have to handle the credit card on your server and be PCI compliant.

Re: Why we ditched PayPal for Stripe

#40

Post by lsh123 »

boucher wrote: post #32
LeBlanc wrote: post #26

Earlier quoted context omitted.

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the…

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 avoid dealing with these issues. However, many other sections of PCI spec discuss other potential vectors of attacks. For example, if you don't follow security coding guidelines then an attacker can embed a malicious JS on your website (through XSS or other attacks) and steal credit cards information. Obviously, the suggestion to serve your pages from SSL don't help you to avoid these problems.

I think Stripe's model is great. But I don't believe that it allows one to completely avoid PCI compliance. I believe that you correctly phrased it on the stripe's home page: "Stripe.js lets you build your own payment forms while still avoiding most PCI requirements."

Post reply on HN