3 ms·

> PayPal's APIs are extremely difficult to use This is simply not true. It took us less than one man/day to custom-wrap their REST API via libcurl to add PayP

by eps 8y ago

> PayPal's APIs are extremely difficult to use This is simply not true. It took us less than one man/day to custom-wrap their REST API via libcurl to add PayPal as an alternative to Stripe. I don't know how else to put it, but it's just really dead simple. Their own libraries are complete junk though... or at least they used to be few years back.

archergod 8y ago
Agree, I have integrate lots of API and paypal is oldest of all and they know what to do. Yes since they introduce braintree they get lot more options and it get confusing when searching on internet. But if you follow their guide aka follow Composer based installation of API it will become relaitvely easy to find information.
tadzik_ 8y ago
The problem with their APIs is that they're broken and/or stupid in surprising ways the moment you look beyond the most basic things. An example: the REST API allows you to create a billing agreement. You can make the customer approve it by redirecting them to the appropriate place, and then execute it to start the cash flow. Obviously, it takes an agreement ID to do anything with it after creating it, so it would make sense if creating the agreement gave you an ID, right? Well, it doesn't. When I wrestled with it a few years ago, there was already a few-years-old bug on their github about it, and the workaround was to extract the part of the approval URL which contained the EC-token. If you sent that part of the URL later to /agreement-execute, it would set things in motion... and return you the actual ID you wanted in the first place. I just checked the docs and it still hasn't been fixed, but at least they're self aware now and the documentation actually tells you to use the EC-token as a temporary agreement ID until you get a proper one. I'm not sure if documenting a hack is something I prefer to fixing a bug; at this point I'm just happy I don't have to work with this pile of crap anymore. The issues with billing agreements just never stopped. Another one we faced had to do with the agreement start date – the documentation said that the datetime needs to be in the future, which makes sense. "5 minutes from now" worked in testing. But then every now and then there would be a customer for whom the error would come up again. After bringing the issue up with paypal support (let's just say that the level of their english matches the quality of the REST API), we eventually deduced that paypal takes the agreement start time and adjusts it according to the users's timezone – therefore sometimes it would "roll back the time" before the current datetime (which of course wasn't timezone-compensated). Where do they take this timezone data from? Who knows; not from the API call inputs, that's for sure – nice, functional design. There were more like these and I could go on and on; eventually we shut down all the paypal integrations except for the simpliest, one-time payments, and pushed the paypal payment option very far in the payment interface, hoping that most of our customers won't find it too easily and will just use Stripe instead.
mherrmann 8y ago
Have you seen the post I linked to in that sentence? https://fman.io/blog/paypal-for-saas-99-problems/ https://fman.io/blog/paypal-for-saas-99-problems/
- eps 8y ago
  Yes, I skimmed through it.
WillPostForFood 8y ago
I think it is more that the documentation is poor, and that they have multiple versions of things so Googling can bring back answers that don't apply. PayPal also lacks many features that are easy in Stripe like changing billing plans or prices. Of course the REST API is just a REST API, so calling it isn't any harder than calling Stripe's REST API. We did a SaaS subscription implementation in Stripe and PayPal, and while it ultimately took less code written to implement PayPal, it took at maybe 5 times as long to complete. The time wasn't the issue, it was that it was insanely unpleasant. It made me hate PayPal - I flip off their offices when I drive by.

by eps 8y ago

archergod 8y ago

Agree, I have integrate lots of API and paypal is oldest of all and they know what to do. Yes since they introduce braintree they get lot more options and it get confusing when searching on internet. But if you follow their guide aka follow Composer based installation of API it will become relaitvely easy to find information.

tadzik_ 8y ago

The problem with their APIs is that they're broken and/or stupid in surprising ways the moment you look beyond the most basic things. An example: the REST API allows you to create a billing agreement. You can make the customer approve it by redirecting them to the appropriate place, and then execute it to start the cash flow. Obviously, it takes an agreement ID to do anything with it after creating it, so it would make sense if creating the agreement gave you an ID, right? Well, it doesn't. When I wrestled with it a few years ago, there was already a few-years-old bug on their github about it, and the workaround was to extract the part of the approval URL which contained the EC-token. If you sent that part of the URL later to /agreement-execute, it would set things in motion... and return you the actual ID you wanted in the first place. I just checked the docs and it still hasn't been fixed, but at least they're self aware now and the documentation actually tells you to use the EC-token as a temporary agreement ID until you get a proper one. I'm not sure if documenting a hack is something I prefer to fixing a bug; at this point I'm just happy I don't have to work with this pile of crap anymore. The issues with billing agreements just never stopped. Another one we faced had to do with the agreement start date – the documentation said that the datetime needs to be in the future, which makes sense. "5 minutes from now" worked in testing. But then every now and then there would be a customer for whom the error would come up again. After bringing the issue up with paypal support (let's just say that the level of their english matches the quality of the REST API), we eventually deduced that paypal takes the agreement start time and adjusts it according to the users's timezone – therefore sometimes it would "roll back the time" before the current datetime (which of course wasn't timezone-compensated). Where do they take this timezone data from? Who knows; not from the API call inputs, that's for sure – nice, functional design. There were more like these and I could go on and on; eventually we shut down all the paypal integrations except for the simpliest, one-time payments, and pushed the paypal payment option very far in the payment interface, hoping that most of our customers won't find it too easily and will just use Stripe instead.

mherrmann 8y ago

Have you seen the post I linked to in that sentence? https://fman.io/blog/paypal-for-saas-99-problems/ https://fman.io/blog/paypal-for-saas-99-problems/

eps 8y ago
Yes, I skimmed through it.

WillPostForFood 8y ago

I think it is more that the documentation is poor, and that they have multiple versions of things so Googling can bring back answers that don't apply. PayPal also lacks many features that are easy in Stripe like changing billing plans or prices. Of course the REST API is just a REST API, so calling it isn't any harder than calling Stripe's REST API. We did a SaaS subscription implementation in Stripe and PayPal, and while it ultimately took less code written to implement PayPal, it took at maybe 5 times as long to complete. The time wasn't the issue, it was that it was insanely unpleasant. It made me hate PayPal - I flip off their offices when I drive by.