6 ms·

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. Unfor

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.

stickfigure 15y ago
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.
- saurik 15y ago
  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.
  - stickfigure 15y ago
    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/IPNGuide.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 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.
    - saurik 15y ago
      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.
      - boucher 15y ago
        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)
- ytadesse 15y ago
  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.

stickfigure 15y ago

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.

saurik 15y ago
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.
- stickfigure 15y ago
  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/IPNGuide.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 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.
  - saurik 15y ago
    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.
    - boucher 15y ago
      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)
ytadesse 15y ago
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.