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

71–80 of 120 posts

Re: Why we ditched PayPal for Stripe

#71

Post by saurik »

lsh123 wrote: post #42
tptacek wrote: post #36

Earlier quoted context omitted.

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 i…

Interestingly, PayPal actually offers (or offered?) an iFrame checkout for some customers and it was confirmed to be PCI-compliant. But again, another PCI auditor might have another opinion on it :)

(PayPal Digital Goods for Express Checkout in fact uses an iframe.)

Re: Why we ditched PayPal for Stripe

#72

Post by _exec »

I cannot recommend Stripe enough. We will be posting a blog post about our (seamless, instant) transition very soon. Kudos!

EDIT: By seamless, I mean "Sign up and get an API key", and by instant, I mean "Read this article, sign up, instant activation, plug in API keys, start charging, switch complete!"

Re: Why we ditched PayPal for Stripe

#73

Post by saurik »

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…

With this same argument, could I not use the JavaScript I inject into the site (via XSS or whatever) to replace your entire iframe with a different iframe (hosted off my corrupt and evil server) that looked identical to yours? I don't need to access elements of the checkout form: the key problem with an iframe is that the user cannot tell what the URL of the iframe is to do basic verification of where the page is being served from.

Re: Why we ditched PayPal for Stripe

#74

Post by shivang »

lsh123 wrote: post #42
tptacek wrote: post #36

Earlier quoted context omitted.

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 i…

Interestingly, PayPal actually offers (or offered?) an iFrame checkout for some customers and it was confirmed to be PCI-compliant. But again, another PCI auditor might have another opinion on it :)

Paypal actually offer a Embedded payment experience which in no sense gives the feeling of embedded payments on the website. https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c...

On this link you can find the experience of Embedded payments, i implemented it on our site but the docs on the api are not complete on paypal, rather complete they are not present at one place.

Re: Why we ditched PayPal for Stripe

#75

Post by lsh123 »

airlocksoftware wrote: post #69
yangez wrote: post #61

Earlier quoted context omitted.

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 co…

I am not familiar with A/B/C/D levels but PCI spec clearly defines PCI 1-4 levels based on volume/number of payments:

http://www.pcicomplianceguide.org/pcifaqs.php#5

Re: Why we ditched PayPal for Stripe

#76

Post by ytadesse »

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.

Never said it was. I've complained about PayPal's API documentation just as much as the next guy.

I'm simply referring to the fact that most arguments over the past week have revolved around PayPal's technical support teams and the service that they provide.

Should they simplify their API and provide documentation that's 1000x better than what they have today? Yes. Am I going to act like the other 1,000,000 on the web right now screaming about how shitty they are? No. It's a brilliantly run company that needs to improve on somethings.

People need to grow up these days. Not you specifically stickfigure, but people of the web. No one is constructive anymore. People just want to vent and vent and spew rhetoric.

Re: Why we ditched PayPal for Stripe

#77

Post by alapshah »

I feel like I am becoming a ridiculous Samurai supporter in a world of Stripe supporters on HN (odd because we know they have many large customers), but my large (seasonal business, 8-figures a month for 5 months a year) contract employer chose Samurai last month and we've been very pleased. We still are splitting our transactions between them and another provider but we've been very satisfied w/ Samurai thus far and will probably migrate all of our transactions to them over the next couple of months. They have an amazing API - can do the stuff referenced in the above article... See: https://samurai.feefighters.com/developers/samurai-js and were fantastic to work with. They also have a campfire room that is usually staffed and helpful

I ended up choosing them for my non-day-job gig as well (saas business) and am very happy. Happy that both of these services exist, really.

Re: Why we ditched PayPal for Stripe

#78

Post by stickfigure »

saurik wrote: post #62
stickfigure wrote: post #58

Earlier quoted context omitted.

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 the…

I haven't integrated Stripe, but I have integrated WePay, PayPal, Google Checkout, and Amazon Payments into various applications.

WePay's API is very well designed and easy to understand. The documentation is blissfully short and effective. When I had technical questions, a post to their email list got me a detailed response within hours (and usually within minutes). Honestly it's the best developer support experience I have ever had with any product in my 16 years of professional software development. I hope it lasts.

All three of PayPal, Google, and Amazon suck, but I will honestly say that PayPal is probably the worst developer experience I've had in that same time period. And this was for a very simple implementation of a single product one-time purchase.

1) It took hours to figure out what product I wanted. PayPal's product assortment is a trainwreck. What the hell is the difference between Web Payments and Web Payments Pro and Adaptive Payments and about a dozen other things with idiotic names that all sound the same. The chart that tries to help you pick a product is useless.

2) The layout of paypal's website is labyrinthine. Even after I figured out what product I needed, assembling all the relevant documentation was hard.

3) The documentation is flat-out wrong in several (rather important) places. For example, the IPN guide (naturally, a PDF https://cms.paypal.com/cms_content/US/en_US/files/developer/...) on page 9 clearly states that you must explicitly post back messages to paypal to get them to stop sending (which is retarded and screws up transactions), but HN says that this is not the case. You can see my venting about this almost a year ago here: http://news.ycombinator.com/item?id=2341119

4) Posting a technical question to PayPal's forum gave me an unhelpful response from a clearly first-level "read the flowchart" technical support rep. Pointless exercise.

5) PayPal's APIs all feel like they were designed in the 1990s. Seriously, I would be horribly embarrassed to publish an API like that. I put more thought into (and produce better documentation for) my opensource projects. Useless crap websites like Foursquare can come up with solid APIs, there's no excuse for a company that handles actual money to be this janky.

It's vogue to hate PayPal because they really horribly suck. And now there are good alternatives. So I say, let them rot. WePay costs a little bit more but it is worth it not to have bit scary parts of my codebase that I dread going into.

Re: Why we ditched PayPal for Stripe

#79

Post by airlocksoftware »

lsh123 wrote: post #75
airlocksoftware wrote: post #69

Earlier quoted context omitted.

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 co…

I am not familiar with A/B/C/D levels but PCI spec clearly defines PCI 1-4 levels based on volume/number of payments: http://www.pcicomplianceguide.org/pcifaqs.php#5

Ah, yes. What I'm talking about above applies to level 4 merchants, (less than 20k ecommerce transactions), who can get away with lower level compliance. The ABCD levels refer to the self assessment questionnaires (SAQ) these level 4 merchants are required to completed.

https://www.pcisecuritystandards.org/security_standards/docu...

Re: Why we ditched PayPal for Stripe

#80

Post by ra »

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…

If only Stripe were available in other jurisdictions.

Stripe, please come to Australia!

Post reply on HN