What surprised me (last night as I wrote my paypal integration) is that Paypal's API is broken by design. Horribly.
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.
This is wrong. All you have to do is return a "200 OK" and PayPal will stop sending IPNs. You don't even need to perform the validation postback at all. It's completely optional.
As bpreit pointed out, sending the "200 OK" response is what stops the IPN retries. The verification postback is a red herring; you can do it zero times, one time, or a hundred times, and if you don't send a "200 OK" response to the IPN, it will be retried.
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.
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.
Technology FAIL.