PayPal sucks

PayPal are supposed to be the be-all and end-all of payment systems, at least they'd like you to think so. And their feature set is fairly compelling and relatively easy to use... until you decide to integrate an ecommerce application into their system.

PayPal's biggest value is that they make it easy for any random person to implement a basic web store without needing a merchant account for credit-card processing. This, plus the fact that they are the "trusted third party" makes them attractive to every Mom-and-Pop Internet T-Shirt shop out there.

However when you try to use PayPal's system to do any real ecommerce work using your own pre-existing ecommerce solution, you find the limitations in their system fast.

First, they have a multitude of slightly different products and offerings, each with slightly different features and slightly different names. Then they have lots of different ways to accomplish things: for one thing they have two different ways to make your ecom system talk to theirs: SOAP and NVP (name value pair) API. Why two? Who knows!

Then they pay lip-service to important things like testing: they have a "Sandbox" where you can create fake merchants and clients and process fake transactions, but the Sandbox is broken as often as it is working, and lots of things about it are dumb. For one thing it requires a valid-looking phone number for the merchant account setup, and other valid-looking data, even though the data is useless and doesn't factor into the testing at all. But on the other hand, important things like chargebacks can't be simulated through the Sandbox because... well, nobody knows why not.

Then there are lots of other weird glitches; parts of their system accept all character sets and other parts don't, leading to problems when dealing with foreign languages. In this day and age they should be able to use the character-set that the other end of the connection reports, but for some reason they can't. Luckily there is a workaround: you configure your PayPal account to ALWAYS use one character set (the user-interface for this is terrible) and then it works, as long as you never need any OTHER character set. If you don't know what a character set is, you're either lucky or you've never dealt with anything other than English/Spanish/French and you get away with the "Default" character set.

Another problem I had was that, when my code wasn't including the flag to indicate "partial" or "full" refund their system told me the amount was wrong. Well, the amount was right but it turns out something else was wrong... as a programmer I can guarantee you that it's trivial to get these kinds of error messages right, yet somehow they manage to screw it up; this cost me several hours of time trying to figure out what was wrong.

Also I found that there is a bug in their software (exposed through their mis-handling of character sets). I am using the PayPal SDK (software development kit) to interface my system with theirs; but when THEIR server crashes, THEIR sdk ignores the error and does something nonsensical. So I filed a bug, and their response was "use the SDK". I replied that I WAS using it, and eventually they admitted that their system was dumb and that the SDK was broken, but they didn't fix the SDK nor did they fix their system. In the end I had to fix the SDK myself. Not much point in using and SDK if it can't even get these simple basic things right.

Most vexingly is their inability to grasp that other development teams have processes and standards to maintain. My team, for example, works on an isolated test environment that isn't reachable from the outside. One of PayPal's features is that their system will contact your system whenever you have a transaction (this is called Instant Payment Notification or IPN). However for this to work (in testing) I have to have my IT guy open the firewall so that their system can reach my test system. PayPal doesn't seem to understand this and they are reluctant to publish the addresses that their test servers use; we need these addresses so that the firwall can allow them through. PayPal says "use the DNS to find the address". A better solution is to use DNS and reverse-DNS so that you can validate that the address and name match, however, PayPal fails on both of these. Their documentation states that the Sandbox IPN server uses one address (something .110), and their DNS also says this, however in reality it's something.33. And the reverse-DNS for something.33 fails, so there's no way to verify that this is the Sandbox IPN server. When my IT guy opened the firewall for something.110 the IPN failed, naturally, because it was blocked. I didn't know what address it should be so I contacted PayPal. They gave me the run-around, saying, essentially, "your system is wrong" and "don't use a firewall". They refused to admit that they had a problem and wouldn't tell me the true address of their server. I eventually discovered it through another means, then TOLD them their own address, and asked why the documentation didn't match. Their response was to close my support ticket, because now that I had the real address everything worked. Thanks for nothing, PayPal!

Anyway, it's frightening that such a poorly run company is in charge of so much money. Yet people (regular customers) trust them, so vendors need to support them to make sales. I guess in the end it's irrelevant because banks are no better.