As many of us did, I am implementing PayPal solution. Reading through the developer documentations, I understand that IPN is the asynchronous message protocol, that triggers payment fulfillments.
PayPal has a official way how to respond to these messages and how to verify the origin of the IPN messages on your IPN listener. Every IPN message the listener receives from PayPal includes a User-Agent HTTPS request header whose value is PayPal IPN ( https://www.paypal.com/ipn ) They highlight that do not use this header to verify that an IPN really came from PayPal and has not been tampered with. Rather, to verify these things, you must use the IPN authentication protocol outlined below, which consists four steps.
- PayPal HTTPS POSTs an IPN message to your listener that notifies it of an event.
- Your listener returns an empty HTTP 200 response to PayPal.
- Your listener HTTPS POSTs the complete, unaltered message back to PayPal; the message must contain the same fields (in the same order) as the original message and be encoded in the same way as the original message.
- PayPal sends a single word back - either VERIFIED (if the message matches the original) or INVALID (if the message does not match the original).
Steps 2, 3, 4, and 5 in the diagram below show this protocol.
As you can see above, they recommend something, that responds with a single [VERIFIED] of [INVALID] message, to prevent fraud.
My thought is that any fake IPN simulator can post back the "VERIFIED" status message to the listener, so it makes no sense. Therefor, my questions are:
- Is that solution really safe?
- if not, what approach could really prevent fraud and make sure payment fulfilment?
I wonder, if we could exchange a secret-key, it would be more reliable.
Every thoughts are welcome. Thanks.