You are being far too generous regarding the documentation. Here's the relevant part:
---
The IPN protocol consists of three steps:
1. PayPal sends your IPN listener a message that notifies you of the event
2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original
message
3. PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent
Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.
---
This is clear, unambiguous, and - if what you say is correct - just flat out WRONG. My misunderstanding wasn't just "a reasonable interpretation", its the only reasonable interpretation. At the barest minimum, competent documentation should state "PayPal will attempt to resend messages until your handler returns a 200 OK http status code." It doesn't. Anywhere.
This is a perfect example of why working with PayPal is an unacceptable developer experience. And who doubts that one year from now this document won't have changed one bit?
It's not the best wording but doesn't necessarily imply that the payment is dependent on handling the IPN, just that the retrying is affected by the handling.
But it is unforgivable that there does not seem to be any mention of what response the PayPal server is expecting to indicate that the IPN has been successfully caught.
---
The IPN protocol consists of three steps:
1. PayPal sends your IPN listener a message that notifies you of the event
2. Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3. PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent
Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.
---
This is clear, unambiguous, and - if what you say is correct - just flat out WRONG. My misunderstanding wasn't just "a reasonable interpretation", its the only reasonable interpretation. At the barest minimum, competent documentation should state "PayPal will attempt to resend messages until your handler returns a 200 OK http status code." It doesn't. Anywhere.
This is a perfect example of why working with PayPal is an unacceptable developer experience. And who doubts that one year from now this document won't have changed one bit?