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

81–90 of 120 posts

Re: Why we ditched PayPal for Stripe

#81

Post by saurik »

stickfigure wrote: post #78
saurik wrote: post #62

Earlier quoted context omitted.

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

If you are the kind of person who cares about whether the validation closes the IPN retry so you can come up with a reasonable strategy for handling your database transaction policy (which is a good thing: people should care this much about everything they do), then Stripe's documented policy should be a non-starter, as it seems to indicate there is not going to be any retry at all if the request in any way hits your server: "Stripe ensures that webhooks are sent successfully but does not attempt to re-send webhooks that return errors in the response."

WePay's retry policy at least exists, but only retrying three times total, with those three times only spanning a single hour of attempts, is kind of bothersome... I have totally had outages that affected some random load balancer for an hour in the middle of the night: PayPal will retry for something like four days, and has a mechanism to "force flush" the notifications as your infrastructure comes back online.

Honestly, all of these APIs are not that great. Amazon's API, for example, does not let you get the shipping address. They return it as part of the co-branded UI return, but that request to your server, at scale, will sometimes be lost in transit. When the user goes back through the payment process, you are encouraged to look up the existing token the user succeeded in authorizing by CallerReference and then continuing the payment, but that means the shipping address is not sent, and you can't query for it. You can, however, get it via IPN, but if you find some silly bug in your code that drops an IPN's incoming shipping address (but returns a successful result), you are simply screwed and have to talk to the customer to recover the shipping address for that transaction.

Looking more at WePay, I again see the same thing I keep harping about regarding Stripe: I see no mentions of chargebacks. Doing a "site:wepay.com chargeback" search using Google I find their terms of service, but nothing in their API documentation; and omg: their terms of service regarding chargebacks is the worst I have so far seen... $35 ding and your account seems to immediately be put on hold and goes into account review? For a single chargeback? WTF.

Re: Why we ditched PayPal for Stripe

#82

Post by ericd »

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…

What about a script injection to rewrite the DOM and create a mock WePay iframe that's actually loaded from a third party server?

Re: Why we ditched PayPal for Stripe

#83

Post by pbreit »

I hear you. However I would like to point out that the two PayPal services I designed 10 years ago, Web Accept and IPN, continue to work in the same way they did a decade ago. I was fanatical about not breaking and not needing to version.

Re: Why we ditched PayPal for Stripe

#84

Post by pbreit »

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…

Agreed. You have a low bar if you are impressed with co-founders helping you out. That is obviously only a figment of the service being tiny.

Re: Why we ditched PayPal for Stripe

#85

Post by pbreit »

stickfigure wrote: post #78
saurik wrote: post #62

Earlier quoted context omitted.

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

I don't understand your PayPal IPN rant at all (I designed IPN; it's not perfect but it works pretty well). PayPal POSTs payment details to you. You capture those details, post them back to PayPal as-is and PayPal tells you if they are valid or not. Pretty simple. Of course there is a unique identifier: the txn_id. And because the validation step is a simple hash that doesn't hit the DB, it's very performant.

Re: Why we ditched PayPal for Stripe

#87

Post by pbreit »

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!).

This is a good point. PayPal has moved beyond being a mere payment processor. There are a lot of shoppers (10s of millions at least) who actively prefer paying with PayPal.

Re: Why we ditched PayPal for Stripe

#89

Post by saurik »

pbreit wrote: post #85
stickfigure wrote: post #78

Earlier quoted context omitted.

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

I don't understand your PayPal IPN rant at all (I designed IPN; it's not perfect but it works pretty well). PayPal POSTs payment details to you. You capture those details, post them back to PayPal as-is and PayPal tells you if they are valid or not. Pretty simple. Of course there is a unique identifier: the txn_id. And because the validation step is a simple hash that doesn't hit the DB, it's very performant.

The rant was about the retry algorithm, which (from reasonable interpretations of the documentation) seems to "clear" (for lack of a better term) the IPN during a successful "response" (the term used in the PDF), but where a "response" seems to be defined as the verification step, not the HTTP request returning a successful status code.

If this were the case (and it seems from other responses to the rant that it is not, but honestly the documentation seems to read as if it is), then it would not be possible to both verify the validity of IPN requests /and/ guarantee that the information is safely committed to one's database.

In essence, and to explain, there are really only two options: either my server commits to my database before or after I perform the verification.

If I do it after, then I might fail (for whatever reason, let's say out of disk space), but will not get a retry of the IPN as I already cleared it.

If I do it before, and the verification returns "invalid", then I have to attempt to undo what I did to the database, which might not be possible, or itself might fail.

Instead, IPN needs to (and I am under the impression from the responses to the rant that it does) clear the IPN retry if the entire request succeeds, allowing for verification to be separate: you first verify, then commit, and finally return a successful HTTP status code to clear retries; here, if your commit fails, you will get another attempt.

Re: Why we ditched PayPal for Stripe

#90

Post by decadentcactus »

ra wrote: post #80
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!

Doubleplusupvote on this one. Although I'm wondering if I can still use it if incorporated in the US.
Post reply on HN