8 ms·

As someone that selected stripe to process orders for a product were were launching somewhere around 2012, it was because of the APIs and developer sandbox. Pa

As someone that selected stripe to process orders for a product were were launching somewhere around 2012, it was because of the APIs and developer sandbox. Paypal was ugly to work with, felt crufty, etc. Stripe had pip installable modules, awesome documentation (live code samples in docs and sandbox), and was easy to integrate into our tests.

jacquesm 9y ago
And most importantly: Stripe does not randomly decide your funds are suddenly theirs for the next 6 months to a year.
- jameskegel 9y ago
  This is how PayPal lost my business initially; now that I'm a part of the payments industry, I use PayPal sparingly for much else.
- hwillis 9y ago
  That's the least of it. Paypal automatically puts you on a 21-60 day rolling reserve once you hit a certain level. Small businesses can and have had 30%+ of their revenue unavailable for two months. That's your entire profit margin gone. It makes it impossible to grow a small business. And of course they will not respond to anything for months if ever. And it never gets better! Companies with millions in revenue still get these problems. Paypal has no place being used by anyone trying to start a company. They are awful.
  - ErikAugust 9y ago
    Before Stripe - I had to take a loan out, and make the switch to Authorize.net so I could get my company off PayPal and its 60 day reserve - otherwise it would have folded. They were perpetually holding tens of thousands of dollars at all times.
- lmm 9y ago
  They'll do that sooner or later. Everyone in the money-handling industry has to randomly lock-up funds and not tell you why, because that's what anti-money-laundering laws require.
  - simonh 9y ago
    Ok, but there's a difference between doing that because you are required to by law, and doing it because you've chosen to adopt appalling business practices.
- j_s 9y ago
  Fraud and charge backs are worse [with Stripe] than with PayPal. https://news.ycombinator.com/item?id=14463971 https://news.ycombinator.com/item?id=14463971 (2 months ago) Stripe launched a fraud detection tool in October 2016; not sure if this comment took that into account. https://stripe.com/blog/radar https://stripe.com/blog/radar (2016) https://stripe.com/blog/better-dispute-management https://stripe.com/blog/better-dispute-management (2012)
dboreham 9y ago
PayPal had a developer sandbox back in 2010 when I wrote our client code. Honestly I don't remember it being difficult or tricky. The worst aspect was their confusing documentation which tended to mix up various different services and APIs such that it was hard to figure out which was the current, appropriate one. Perhaps that was the Stripe advantage: a single obvious course of action to take.
- hawflakes 9y ago
  The sandbox was a big hack. I worked there internally and it was a pain even inside. Maybe it's a bit different now, but I haven't looked back. :-D
  - stickfigure 9y ago
    It's actually gotten worse. PayPal tried to "modernize" their old crufty SOAP API with a REST-based API but ended up creating a separate half-functional, poorly documented, buggy layer on top of it that actually loses payments sometimes. I processed millions of payments through it and actually have their support people admitting the problems. Their only hope is a reverse-takeover from Braintree. I'm not holding my breath; I've done my last PayPal integration. Forget all the "paypal will hold your money" concerns - the real problem is that they will loose your money in the wonky Rube Goldberg machine they've created to process payments.
    - jeffasinger 9y ago
      In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement. The project just ended up getting scrapped.
- eterm 9y ago
  One of my best upvoted stackoverflow answers is about a paypal sandbox bug (or "undocumented feature") where it would disregard the port in the pingback url. Just generally the sandbox was horrible, it had a weird 'double login' system where it often got confused between whether you were 'inside' the sandbox logged in as a fake user or outside logged in as your paypal account. And you're right about their woefully confusing documentation, it was definitely hard to understand which payment flow you were trying to use and which was appropriate.
mullsork 9y ago
Ease of development was our number one reason to use Stripe for sure. We did end up adding Paypal after and it was a pain to work with. Stripe was so reliable that we had clickety-test that used their real sandbox API to make sure in our CI that payment kept working. Whenever someone brings up Stripe it always brings happy memories. I've never worked with a third party API that was as nice as theirs. Their Ruby SDK helped with that of course.

jacquesm 9y ago

And most importantly: Stripe does not randomly decide your funds are suddenly theirs for the next 6 months to a year.

jameskegel 9y ago
This is how PayPal lost my business initially; now that I'm a part of the payments industry, I use PayPal sparingly for much else.
hwillis 9y ago
That's the least of it. Paypal automatically puts you on a 21-60 day rolling reserve once you hit a certain level. Small businesses can and have had 30%+ of their revenue unavailable for two months. That's your entire profit margin gone. It makes it impossible to grow a small business. And of course they will not respond to anything for months if ever. And it never gets better! Companies with millions in revenue still get these problems. Paypal has no place being used by anyone trying to start a company. They are awful.
- ErikAugust 9y ago
  Before Stripe - I had to take a loan out, and make the switch to Authorize.net so I could get my company off PayPal and its 60 day reserve - otherwise it would have folded. They were perpetually holding tens of thousands of dollars at all times.
lmm 9y ago
They'll do that sooner or later. Everyone in the money-handling industry has to randomly lock-up funds and not tell you why, because that's what anti-money-laundering laws require.
- simonh 9y ago
  Ok, but there's a difference between doing that because you are required to by law, and doing it because you've chosen to adopt appalling business practices.
j_s 9y ago
Fraud and charge backs are worse [with Stripe] than with PayPal. https://news.ycombinator.com/item?id=14463971 https://news.ycombinator.com/item?id=14463971 (2 months ago) Stripe launched a fraud detection tool in October 2016; not sure if this comment took that into account. https://stripe.com/blog/radar https://stripe.com/blog/radar (2016) https://stripe.com/blog/better-dispute-management https://stripe.com/blog/better-dispute-management (2012)

dboreham 9y ago

PayPal had a developer sandbox back in 2010 when I wrote our client code. Honestly I don't remember it being difficult or tricky. The worst aspect was their confusing documentation which tended to mix up various different services and APIs such that it was hard to figure out which was the current, appropriate one. Perhaps that was the Stripe advantage: a single obvious course of action to take.

hawflakes 9y ago
The sandbox was a big hack. I worked there internally and it was a pain even inside. Maybe it's a bit different now, but I haven't looked back. :-D
- stickfigure 9y ago
  It's actually gotten worse. PayPal tried to "modernize" their old crufty SOAP API with a REST-based API but ended up creating a separate half-functional, poorly documented, buggy layer on top of it that actually loses payments sometimes. I processed millions of payments through it and actually have their support people admitting the problems. Their only hope is a reverse-takeover from Braintree. I'm not holding my breath; I've done my last PayPal integration. Forget all the "paypal will hold your money" concerns - the real problem is that they will loose your money in the wonky Rube Goldberg machine they've created to process payments.
  - jeffasinger 9y ago
    In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement. The project just ended up getting scrapped.
eterm 9y ago
One of my best upvoted stackoverflow answers is about a paypal sandbox bug (or "undocumented feature") where it would disregard the port in the pingback url. Just generally the sandbox was horrible, it had a weird 'double login' system where it often got confused between whether you were 'inside' the sandbox logged in as a fake user or outside logged in as your paypal account. And you're right about their woefully confusing documentation, it was definitely hard to understand which payment flow you were trying to use and which was appropriate.

mullsork 9y ago

Ease of development was our number one reason to use Stripe for sure. We did end up adding Paypal after and it was a pain to work with. Stripe was so reliable that we had clickety-test that used their real sandbox API to make sure in our CI that payment kept working. Whenever someone brings up Stripe it always brings happy memories. I've never worked with a third party API that was as nice as theirs. Their Ruby SDK helped with that of course.