title: IPN verification returns INVALID as PayPal is sending incorrect charset in POST to IPN Listener
body: <p>All of the following is in the PayPal sandbox:</p>
  
  <p>I have a PayPal subscription/recurring payment setup which uses a IPN listener as the last step to create or update a user's subscription in my website DB. However, when I received the POST data from paypal and send it back for verification, the only response I receive is "INVALID".</p>
  
  <p>I know that my code sends the POST data back to PayPal correctly, because I get a "VERIFIED" response when I mimic a correct POST to my listener by hardcoding the POST data string with the "IPN Message" value as seen on the PayPal's IPN History page.</p>
  
  <p>So my code that sends the POST data back to PayPal for final verification works, and my IPN listener is receiving the POST variables for the transaction. There is just a difference the POST-data string my IPN listener creates to send back to PayPal and the POST-data string that PayPal expects to receive.</p>
  
  <p>PayPal states that the IPN listener must send back the POST data it receives with the same values, order, and encoding that PayPal sent it in.</p>
  
  <p>I think the problem is an encoding issue because in the PayPal POST to my listener, "charset" has the value "windows-1252" which should be "UTF-8". However, "form_charset" has the correct value of "UTF-8".</p>
  
  <p>I have set the encoding to UTF-8 on both input fields on my seller PayPal profile, and have a hidden input in the initial PayPal form/button with the name "charset" and value "UTF-8". Please tell me if there is another way to set the encoding that I have missed.</p>
  
  <p>Part of the POST data string that PayPal claims to be sending includes "&amp;notify_version=3.8" followed by more variables. When I manually insert this string to test my code, the "&amp;not" gets converted to "¬" when printed to the page which to my understanding means that the character encoding being used is "windows-1252" because "¬" is in the windows-1252 character set, but "¬" is not in the UTF-8 character set, so if UTF-8 was being used, the "&amp;not" would not be converted like this.</p>
  
  <p>How can I get PayPal to actually POST data to my IPN listener with UTF-8 character encoding? Keep in mind that this is a recurring payment so some aspects may be different.</p>
  
  <p>I don't think the issue is on my end, as I have tried different methods, different ways of encoding/decoding the posted data, external libraries, cUrl/sockets, SSL on with different versions, different headers, restarting the server, recreating the purchase, etc.
  So Paypal is sending me the wrong POST data or I am forming the post string incorrectly. The latter is possible, but I have tried every method I could find for forming the post string and none worked.</p>
  
  <p>I have been working on this problem for days to no avail, so any help or pointers would be very appreciated.</p>
  
  <p>PS:
  a few notes which may or may not be relevant:</p>
  
  <ul>
  <li><p>This subscription system was created a few months ago and only stopped working inexplicably at some point in the last few weeks. No relevant code was changed around that time AFAIK.</p></li>
  <li><p>The first day I started debugging this issue, the seller account for the sandbox had completely incorrect data, it was listed as a personal account when it should have been a business account, which meant none of the IPN settings were available. The next day the same account inexplicably worked and showed up as a business account as it should have in the the first place. I'm not aware of any action on my part causing this change. Maybe PayPal sending the wrong character encoding is a similar issue? Some caching system on a cron job? I'm just speculating at this point, I really have no clue.</p></li>
  <li><p>Relating to my last point, logging into the seller sandbox account has been very unreliable. Sometimes I attempt to log back in after a session timeout and receive an error code which would only make sense in the context of registering a new account. Other times logging in just doesn't work, the result being that a fraction of the times I try logging in after a session timeout, I have to clear my cookies for logging back in to work.</p></li>
  </ul>