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

21–30 of 120 posts

Re: Why we ditched PayPal for Stripe

#21

Post by LeBlanc »

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for most of the PCI spec (our iframe checkout gets around this). We made a bet that there are a lot of developers out there that who are willing to give up a little on the customization side to not have to deal with the headache of PCI compliance (we've gone through that process ourselves and it is complicated and expensive).

Re: Why we ditched PayPal for Stripe

#22

Post by saurik »

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 time to be sitting around checking Twitter.

(edit: I typed this over too long a period of time, and some of this post appeared after I had already submitted a draft with the above paragraph that received some upvotes, so I've now edited again to add this edit paragraph to explain that everything after this point was added after I received said upvotes. ;P)

Also, I'm very curious about their API... I didn't see much information on chargebacks. Processors like Litle & Co make it very easy to fully automate the chargeback representment flow. PayPal, incidentally, does /not/ provide this either, but they do have APIs that let you (with only some hoops to get through bugs that I've filed with them, and we may see fixed fairly soon) correlate and track all of the chargebacks and how they relate to your transactions.

Yet, when Stripe first started appearing on Hacker News, their website seemed to have almost no information on chargebacks. I asked after this, and the page "appeared" with an apology that it was supposedly there but not linked, but it then had very little information on it. I still (checking again now) see no information on how I'd determine /which/ transactions had chargebacks automatically: they seem to seriously rely on sending an e-mail? Why does their API page never once mention the word "chargeback"?

Re: Why we ditched PayPal for Stripe

#23

Post by mrkurt »

LeBlanc wrote: post #21

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service. The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account base…

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

Re: Why we ditched PayPal for Stripe

#25

Post by gtaylor »

angryasian wrote: post #20
james33 wrote: post #2

I don't really consider Stripe a replacement for PayPal. You don't accept PayPal because it can process credit cards, you accept PayPal because millions of people want to pay with it. Don't get me wrong, I hate PayPal just as much as the next guy, but unfortunately it isn't a viable option to stop using it in favor of simply accepting credit cards right now (though Stripe is an awesome product!).

agree, I'd like to know conversion numbers after the switch.

It's still really early going, but we've seen some new patterns. For example, we had a customer enroll in four different courses (we help schools offer online courses) in under five minutes. This -never- happened when we only offered PayPal.

Our current enrollment process is so fast and simple with Stripe that we're curious to see if our conversion rate is -better-, for our current audience (older, non-technical users at this point). While a $30-$90 course isn't an impulse buy, lowering the barrier to enrolling in more than one may leave us better off.

But we'll be able to discuss that better after we have more data.

Re: Why we ditched PayPal for Stripe

#26

Post by LeBlanc »

mrkurt wrote: post #23
LeBlanc wrote: post #21

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service. The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account base…

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 PCI spec (just part), which is one of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so javascript on your page can't directly access elements on the checkout form. There are still potential vulnerabilities such as clickjacking (we do some things to protect against this), but since the CC form is served from our domain, only we are liable for PCI compliance.

Re: Why we ditched PayPal for Stripe

#29

Post by tptacek »

mrkurt wrote: post #23
LeBlanc wrote: post #21

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service. The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account base…

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)

Re: Why we ditched PayPal for Stripe

#30

Post by michaelschade »

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…

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 co-founder will always be the one to respond to a tweet as Stripe grows, but I do suspect that their standards for customer service will remain high, and someone in the company will give a quick and quality response. That said, with Stripe, I believe that–even if they aren't the ones responding to every tweet, which is admittedly much to ask–the co-founders will continue to have an eye on what people are saying about them and interact appropriately, not wall themselves off.

Edit to reflect your edit:

I remember that HN thread where you brought up chargebacks. For anyone interested, they discuss how they handle chargebacks here: https://stripe.com/help/chargebacks

I can't attest as to why they manage chargebacks that way, and will not speculate beyond the note that they are still new and seem to be developing their service in response to customer feedback and perceived needs.

For you, or anyone else who might be interested in requesting features regarding chargebacks or any other aspect of their service, I highly recommend writing in: support@stripe.com or https://stripe.com/help/contact. As I mentioned, they're very responsive, and seem to love the feedback.

Post reply on HN