Even their new APIs are based on the IPN "reliable messaging" notification system. But there's nothing reliable about it:
* You receive a message from Paypal
* You post it back to Paypal
* You get back "VERIFIED" or "INVALID"
* The burning stupid: This postback is also what acknowledges the message and stops the retries.
In other words, your code must either:
1) Commit transactions in your database based on unverified information, then figure out how to revert the changes if the message comes back invalid. Or:
2) Verify the message (stopping retries) and then try to commit your transaction, possibly failing and losing the IPN message entirely. Your customer may never get his product enabled.
Oh, and let me mention that the verification postback can happen only once. It's impossible to build an idempotent handler for IPN messages.
Paypal's documentation and sample code push you towards solution #2. This is just negligent. I've built porn-serving infrastructure that was a thousand times more robust. People trust this with real money?
And don't get me started on Paypal's near-useless morass of documentation. And the fact that IPN messages don't have any kind of unique identifier.
So the correct strategy is:
1. Receive an IPN from Paypal.
2. Post it back to Paypal.
3. Make sure the response is VERIFIED.
4. Idempotently handle the payment.
5. Send "200 OK" response.
Step 4 needs to be idempotent in case your server dies or times out before sending the 200 OK response, but there's no way to avoid this without potentially losing messages. (I can't remember what the theorem is called, but in a lossy system it's impossible to avoid both messages being lost and messages being duplicated.)
Paypal has 99 problems, but its IPN processing isn't one.