4 ms·

I use Stripe and PayPal currently but on the next platform I'm currently building I'm strongly (and very seriously) considering Braintree. With PayPal, the fra

by nickjj 7y ago

I use Stripe and PayPal currently but on the next platform I'm currently building I'm strongly (and very seriously) considering Braintree. With PayPal, the fraud experience has been nothing short of amazing. Out of many many thousands of transactions, I've only had about 3 or 4 transactions get flagged as high risk by PayPal. What this means is PayPal will hold the funds, review the transaction and then either give you the funds if it's legit or do something else if it's not legit. I've had 0 cases on PayPal where fraud / disputes actually took place. Of those 3-4 transactions, they were all released. None of this required any intervention by me. I just got notified by email from PayPal when a high risk transaction occurred. 100% of the funds were put back into my account a few days later (short of the normal 2.9% + 30c fees). On Stripe, I've also had many many thousands of transactions. I've had a number of fraud transactions in the process which ended up as disputes. Stripe sends out an email letting you know, but then it's now on you to decide if you want to contest the dispute. This dispute typically happens when someone who got their credit card stolen sees an unknown charge in their records. Now you need to fill out like 8 form fields and supply screenshots and server logs of proof that someone was accessing the material they've stolen (I sell digital courses so there's no physical item). The screenshots need to be sized perfectly to be displayed in portrait mode on a sheet of paper that gets faxed over to the person reviewing it from the bank, otherwise it'll be unreadable from their perspective and you'll auto-lose the case. Stripe doesn't let you see a real preview of these screenshots and they even alter the uploaded image size in your preview which makes it hard to preview what it will look like from the reviewer's POV even though that's the only thing that matters. After doing that, it takes about 2-3 months to get a resolution. You get charged a $15 bank dispute fee (on top of the full amount of the product of course) which is non-refundable unless you happen to win the dispute, but if someone got their card stolen then you're not going to win the case. You also don't get any information from Stripe about the review, other than you won or lost. Stripe says it's because banks don't give them any info beyond that. Fine, that's ok, but yeah the overall experience is very very bad. Then on top of that, Stripe sells a Radar service that you need to pay extra on top of for each transaction to get better tools to help prevent fraud before it takes place. They choose not to give it to everyone because I guess they profit from dispute fees and fraudulent transactions. The kick in the teeth is that the data Stripe uses to train their Radar / anti-fraud service is data provided by business owners who have trusted Stripe with their business. Now they are selling that data back to us in the form of insurance fees on each transaction (the Radar service you need to pay for). I haven't personally used Braintree yet but from what I read in their docs, you get that type of anti-fraud service baked into the normal 2.9% + 30c (don't quote me on that, but it very much reads that way on their site). Whatever PayPal is doing (and in turn Braintree since it's a PayPal service), they're doing a fantastic job at combating fraud and disputes, especially compared to Stripe. > Would you please describe what is sketchy? Their docs seem pretty good... but I am now just hearing about SCA. Their docs are typically good, but the SCA / Payment Intents docs are not really at the same standards as the rest of their documentation yet. Come back in a few weeks when you've implemented it. What's interesting is I run a podcast about running web apps in production and I've had a bunch of folks come on the show who use Stripe to accept payments. All of them have said the experience with implementing SCA with Stripe was pretty rough. These are seasoned developers running successful platforms too. They've all done it in the last couple of months as well.

pc 7y ago
Hi Nick -- I'd love to have us dig in more here to understand this better. Could you email me? patrick@stripe.com. [In brief, chargebacks/disputes work differently for PayPal payments as compared to credit card payments... I suspect that much of this is mostly a PayPal vs credit card difference. But I want to understand the details.]
- csdreamer7 7y ago
  Hi Patrick. I am the person who asked the question that Nick responded to. I understand PayPal has stronger network effects that may give it more leeway in handling the banks that a smaller competitor may not have. I do agree with Nick that Radar should be a free service for all users. It reduces headaches for everyone involved. Why charge for it? (Post to my above post if you reach HN's post limit.)
olivierrg 7y ago
> Their docs are typically good, but the SCA / Payment Intents docs are not really at the same standards as the rest of their documentation yet. Stripe PM on the Payment Intents API here. You're right that there were some rough edges when we started rolling out this new API last year. SCA is complex and we want to help make it easy to navigate this regulation: we designed the new APIs to abstract away as much of the complexity as we can. In addition, thanks to a lot of feedback from users, we made important changes to our docs architecture, guides, API reference, and Dashboard in November 2019, and are continuing to iterate on it. I would love feedback on how we can further improve our documentation. I’m olivier@stripe.com.
- Silhouette 7y ago
  FWIW, one thing you could usefully do is have someone double-check the code snippets in the online guides. They looked very helpful (and much needed) when I was reading them recently, but I remember almost immediately running into examples where something just didn't make sense. Then if I followed through to the corresponding code in the samples repo, it really was slightly different to what was shown in the guide on your docs site. The guide to setting up a new subscription using the new API definitely had some instances of that problem. The more recent guides would also benefit from more explanation of why the sequence of actions shown was what it was and what each API or webhook used was actually for. Either that or some concise, big picture overview would be good (or ideally both).

by nickjj 7y ago

pc 7y ago

Hi Nick -- I'd love to have us dig in more here to understand this better. Could you email me? patrick@stripe.com. [In brief, chargebacks/disputes work differently for PayPal payments as compared to credit card payments... I suspect that much of this is mostly a PayPal vs credit card difference. But I want to understand the details.]

csdreamer7 7y ago
Hi Patrick. I am the person who asked the question that Nick responded to. I understand PayPal has stronger network effects that may give it more leeway in handling the banks that a smaller competitor may not have. I do agree with Nick that Radar should be a free service for all users. It reduces headaches for everyone involved. Why charge for it? (Post to my above post if you reach HN's post limit.)

olivierrg 7y ago

> Their docs are typically good, but the SCA / Payment Intents docs are not really at the same standards as the rest of their documentation yet. Stripe PM on the Payment Intents API here. You're right that there were some rough edges when we started rolling out this new API last year. SCA is complex and we want to help make it easy to navigate this regulation: we designed the new APIs to abstract away as much of the complexity as we can. In addition, thanks to a lot of feedback from users, we made important changes to our docs architecture, guides, API reference, and Dashboard in November 2019, and are continuing to iterate on it. I would love feedback on how we can further improve our documentation. I’m olivier@stripe.com.

Silhouette 7y ago
FWIW, one thing you could usefully do is have someone double-check the code snippets in the online guides. They looked very helpful (and much needed) when I was reading them recently, but I remember almost immediately running into examples where something just didn't make sense. Then if I followed through to the corresponding code in the samples repo, it really was slightly different to what was shown in the guide on your docs site. The guide to setting up a new subscription using the new API definitely had some instances of that problem. The more recent guides would also benefit from more explanation of why the sequence of actions shown was what it was and what each API or webhook used was actually for. Either that or some concise, big picture overview would be good (or ideally both).