Hacker News Reader

That's somewhat a fair point, but I'll disagree.

In that instance, the co-founder replied, but I've heard from a number of Stripe's other employees since then, and in every case the customer support has been wonderful. Perhaps that's solely because they are still a startup, but given what I know now about the people themselves, I don't believe that to be the case.

I don't mean my original comment to suggest that the co-founder will always be the one to respond to a tweet as Stripe grows, but I do suspect that their standards for customer service will remain high, and someone in the company will give a quick and quality response. That said, with Stripe, I believe that–even if they aren't the ones responding to every tweet, which is admittedly much to ask–the co-founders will continue to have an eye on what people are saying about them and interact appropriately, not wall themselves off.

Edit to reflect your edit:

I remember that HN thread where you brought up chargebacks. For anyone interested, they discuss how they handle chargebacks here: https://stripe.com/help/chargebacks

I can't attest as to why they manage chargebacks that way, and will not speculate beyond the note that they are still new and seem to be developing their service in response to customer feedback and perceived needs.

For you, or anyone else who might be interested in requesting features regarding chargebacks or any other aspect of their service, I highly recommend writing in: support@stripe.com or https://stripe.com/help/contact. As I mentioned, they're very responsive, and seem to love the feedback.

I am curious if you've ever actually called PayPal. I have received nothing but high quality support from them. You can call them throughout most of the working day (until 8pm PST, I believe), and they seem to have somewhat knowledgable engineers available at that tech tier. They also have a merchant technical support site that seemingly no one knows about where you can often get answers in the middle of the night (I often get responses back at 12:30). If you are even reasonably sized you can also ask for a dedicated account manager: I have the cell phone number of someone at PayPal whose job it is to find me answers to problems I have.

Though, I cannot say PayPal is perfect. I have run into a bunch of annoying issues correlating settlements (bugs filed recently, will be curious to see if they get fixed), and their pricing is not the best that is out there (although is still better than Stripe). I am curious if you've looked into any alternatives. I've spent the last few days talking to Litle & Co, and I must say that the people there /love/ talking to you about payments... their booth at ad:tech was the most enjoyable conversation I've had about payments in a while, and I got to spend another half hour on the phone with them yesterday learning more about how bank ACH settlement works.

Edit to reflect your edit ;P

That is the page I just had gone and reviewed now. It still seems incredibly manual. I would not feel comfortable running a site at scale where I'm dealing with receiving e-mails in an undocumented (probably designed-for-humans) format as my only source of notifications for chargebacks. :(

It is often these "at scale" issues that are seemingly not handled by them; example: per their API page, Stripe does not resend webhooks if there is an error in the response... doesn't this make them useless to rely on? Am I required to sit around and poll my transactions to feel 100% certain that I didn't miss something because my load balancer accidentally gave them a 503 during some traffic spike? :(

I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does. I'm not holding that against them though: it's only one mediocre experience, and I have not used them much because of the whole payment redirection thing (I did not know about their Pro account then).

To be clear: I'm not actually saying that PayPal is bad. I don't have enough experience with them to weigh in one way or the other. I am merely saying that I do like Stripe.

I'm not sure of Stripe's reasoning behind not resending webhooks, but I don't know that I care for them not resending them either. Perhaps this is something they'll be addressing in the future or otherwise have a legitimate reason.

I have called PayPal once before. The experience wasn't horrible, but it didn't leave me enthusiastic like Stripe's does.

Well, talking of facts small companies with a small customer base will always deliver better customer service than the larger ones. True test of these companies will come when their subscriber and customers run into millions(In paypal's case hundreds of millions).

Imagine a situation where where 283 million registered customers and probably more unregistered buyers. Ensuring operations related to that magnitude of people work fine for 99.99% of the people, 99.99% of the times. And then ensuring the remaining get appropriate customer support is not just difficult but requires a lot of work to maintain and run.

At that scale the founders will have a lot more different work to do. And addressing one user out of those hundreds of millions by communicating them on twitter might not scale properly. And the customer support employees are working in call center shifts. They are not going to be any more enthusiastic any more than other general call center employees.

Coming to arcane policies, Now for all those millions of users. There are definitely going to some x% of crooks out there gaming the system. Frankly speaking if you don't have such policies you may actually end up putting a lot of your other buyers and other customers in trouble and expose them to fraud. The problem is in programmatically handling hundreds of millions of users and their problems is not easy. You can build a system to do payments et al, but that's only beginning. So any good payment gateway etc will ultimately end up looking like PayPal.

PayPal works at a scale, Whether a new competitor will work at scale is question of time.

But don't write PayPal off, It actually works well for those hundreds of millions of registered and more unregistered users.

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.

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 there something in specific you did not like about PayPal's API?

I will be the first to say there are warts, but the warts are really far down in the trenches (I only noticed them after using them for years; I did my initial PayPal integration in less than a day): Stripe seems to be missing important things upfront.

Also, I am confused what you mean by "electronic forums"; do you mean like an online ticket site? I have filed numerous tickets against PayPal, and they have always been answered within a few hours during the day; they even have people available to respond to integration issues in the middle of the night.

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.

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.

Hey Saurik, Just wanted to say that we're aware of the (significant) flaws in the webhook APIs. We're in the process of redesigning them now, so thanks for the feedback on what is important to you.

(Also, just FYI, you can see logs of all the webhooks in your Stripe account, including the response body and response status code, and they can be retried with a button click -- a manual process, yes, but it is at least possible)

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.

I still don't totally understand the issue. If your commit fails you can return a "500 error" which will cause the IPN to retry.

I can see how the validation step might be confusingly described. For what it's worth, the validation step merely compares a hash of the variables to confirm the authenticity of the IPN. It doesn't touch the DB at all.

The reason you don't understand the issue is because it is implemented correctly, which is why I kept pointing out the responses to the rant that indicated he was wrong about how it actually worked (to make clear I understood this, apparently failing ;P), and kept adding the parenthetical hedges about the documentation. Really: you nailed it, and the PayPal IPN mechanism works great (seriously: no sarcasm).

The rant really was just about how he perceived it working based on what I do feel is a reasonable reading of the documentation (and in fact I think I originally had that interpretation myself until I actually tried it in practice): that the documentation lists the "response" as the verification process, and does not seem to have any provisions for "500 error": again, though, the way it works is fine.

You are being far too generous regarding the documentation. Here's the relevant part:

---

The IPN protocol consists of three steps:

1. PayPal sends your IPN listener a message that notifies you of the event

2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message

3. PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.

---

This is clear, unambiguous, and - if what you say is correct - just flat out WRONG. My misunderstanding wasn't just "a reasonable interpretation", its the only reasonable interpretation. At the barest minimum, competent documentation should state "PayPal will attempt to resend messages until your handler returns a 200 OK http status code." It doesn't. Anywhere.

This is a perfect example of why working with PayPal is an unacceptable developer experience. And who doubts that one year from now this document won't have changed one bit?

It's not the best wording but doesn't necessarily imply that the payment is dependent on handling the IPN, just that the retrying is affected by the handling.

But it is unforgivable that there does not seem to be any mention of what response the PayPal server is expecting to indicate that the IPN has been successfully caught.

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.

Either way, Stripe is the best solution at this moment. If Stripe ever ever becomes big and bloated like PayPal, hopefully a new startup pop up to compete with them.

> I'm certain people got amazing customer support from people high up at PayPal when it was just starting.

Can you imagine what that could have been like?

Customer: yeah I've having trouble accessing the purchase history

Support (Elon Musk): you need to twiddle the such-and-such.

Customer: tried that. can you escale to your superior?

Manager (Peter Thiel): can I help? I want to make personally sure you have a great experience. Also, avoid college. I'll pay you.

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.