Hacker News Reader

Comment by gomox | Hacker News Reader

> 6. Many users prefer Paypal to credit cards:

I've had the same experience with my customers. I think Stripe is leaving a lot of money on the table by not promoting their brand to end users more. As an informed technical person, I would much rather hand my CC to Stripe than to PayPal, but Joe Sixpack doesn't feel the same way. Their impression is that they're giving randome websites their CC information, when actually Stripe's architecture is very reasonable.

If this affected conversions in a meaningful way for my business, I would have a hard time justifying not using PayPal instead of Stripe.

View on HN

Having done both, multiple times, at scale: Implementing Paypal is about an order of magnitude harder than Stripe.

Paypal's documentation is horrid; they have several competing APIs (the most obvious choice - the REST API - has been silently abandoned); there are many active bugs; their support is slow and unreliable; the admin UX is horrid (finding transactions can be very hard); you will find yourself discovering the hard way how the system behaves on error; and oh there will be lots of errors.

Stripe is stupid simple by comparison, and impeccably reliable.

I pushed thousands of transactions per day through each. Paypal practically required a dedicated engineer to follow up on all the chaos. They periodically lost transactions (and fessed up to it after hours of debugging and support). They lost support tickets too. It's maddening.

If you aren't in a high volume business, Paypal is NOT worth the development headache. You can probably get 20% more users by spending the time building features your users care about.

That's one reason we chose Braintree over Stripe. They both take about the same amount of work to implement, but Braintree gives you the ability to accept PayPal in addition to credit cards with almost no extra effort.

[This is Julia, the OC]: We started integrating with Paypal and basically gave up because of the engineering effort required. Vs Stripe, which has a great web and iOS app and has been seamless from day 1.

Congratulations on dodging a bullet!

Paypal is one of the hidden mines that await startups - you could have had your smartest engineers working on it for months, possibly sinking the whole endeavor as other (actually important) things fail to get done. Unless you have engineering assets to burn, Paypal is absolutely toxic.

The actual bullet dodged is PayPal's tendency to freeze your account and the funds within for six months without warning, explanation or appeal. That'll kill a startup real quick.

We never had problems with PayPal freezing account, but I agree with stickfigure that PayPal API is bad (high maintenance).

I really hate when I see "Payments by Stripe" yet I have to type in my CC details. Stripe has them already, many times over.

Also, I don't necessarily see Stripe as more secure. I see Stripe as the same as handing my CC details to the one-off site. Because, while my info is in their DOM, their JS can do whatever it wants with it. It should just send it off to Stripe and get the callback. But how do I know that? For that reason, I do feel more secure when I get redirected off to a paypal.com site. I know Stripe offers this, but I never see it implemented that way. I always see the use of Stripe.js which allows my info to be in their page/DOM.

As a programmer AND a Joe Sixpack, I already have Paypal. They already have my bank/cc. I'm not going to get rid of it. By going to Stripe, now my attack vector has doubled.

That said, if there was an alternative that stored my CC info and let me do one-click buying (does Stripe do this??) that was integrated into 60%+ of payment systems, I'd gladly use it instead of Paypal, who I've grown to abhor.

With stripe checkout, you can click "remember me".

https://stripe.com/checkout/info

You could also look at the new W3 Payment Request API [1] that stores card details securely in modern browsers.

Stripe has a Payment Request Button that enables one-click buying with Apple Pay, Google Pay, or the Payment Request API. [2] The button will choose whichever method is best and available for your specific browser.

[1]: https://www.w3.org/TR/payment-request/

[2]: https://stripe.com/docs/stripe-js/elements/payment-request-b...

Thanks, Mike! I'll check these out.

Why are you worried about unauthorized use of your credit card number? Under US law, you are liable for $0 of the charges. If you lost your physical card or had it stolen, you're liable for up to $50 of charges made before you reported it as such.

Legally and financially, if a malicious website uses my card number poorly, the consequences for me are "I notice an issue and Chase mails me a new credit card".

Debit card numbers, sure, that's a whole other ball game. But a credit card number? IDGAF if it gets stolen. It's not my problem, and I like it that way.

> Why are you worried about unauthorized use of your credit card number? Under US law, you are liable for $0 of the charges.

While you're correct, it's a huge PITA replacing a CC. I have almost all my bills going through my CC for points. Then there are places like my crap gym that charges a fee if the CC is ever denied for any reason.

Some (most) CCs will allow prior recurring charges to continue with an old/lost/stolen CC number for some period of time (potentially until the expiration date) so you can avoid that headache.

In the case of my AmEx, I have some monthly charges still using an old number from 3 years and 2 stolen cards ago. Discover used to offer this too, though I don't know if they currently do.

Except I think the vendor has to do something? I know some vendors immediately start failing and others seemingly work fine. Regardless of whose problem it is, it becomes a PITA for me.

I don't see why the merchant would have to do anything. If the card/bank allows the transaction, because they recognize the merchant using the "old" card info it'll go through.

I think the concern of losing money over a stolen credit card is very low. The concern of identity theft, OTOH, is very high and very costly. Suddenly being denied a loan to buy a house, and then having difficulty finding any place to rent - pretty bad. Took someone I know over a year to rectify.

The sticking point for me was card expiry. Paypal consolidates my payments, so I don't have to chase around two dozen websites to update my card details every time my debit card is replaced. This issue has caused me to drop domain names in the past, so I have a strong preference for Paypal.

I only just learned that Stripe use some sort of voodoo to continue recurring payments after a card is replaced, which overcomes one of my main objections. If I were Stripe, I'd be shouting this from the rooftops.

Not Voodoo, just a service offered by the card brands. Banks notify the card brand of a new card, the card brand notifies the processor who then updates their database.

Generally processors charge $1/card updated, but stripe is pricey enough to include it for everyone.

We used to only use Stripe, but some users preferred PayPal and now it's 20% of our revenue.

As an informed technical person, aren't you bothered by Stripe insecurity? They have no separate domain and live entirely within vendor-controller DOM. It just takes one bad javascript include on vendor's site, and your CC details are stolen.

Yes, Paypal is pretty bad and I avoid using it on the websites I trust -- but if a random small store asks for the credit card, I start searching for alternatives.

Has anyone tried offering PayPal and Stripe to accept payments, but charge an additional x% for using PayPal or discount x% for using Stripe?

Just thinking about how some gas stations in the US do so to encourage cash/debit sales vs. credit card where they have to pay transaction fees.

In this use case the point would not be to avoid fees, because that's not possible here, but to avoid becoming a PayPal merchant horror story.

Reply on news.ycombinator.com