in reply to How do you use Paypal IPN with Dancer2?

Have you tried getting the script to work the way they originally had it?
This may not be an issues but in your code you have. 

$return_query = "cmd=_notify-validate&" . $return_query;

[download]
But the way they had it. 
$query .= '&cmd=_notify-validate';

[download]
would be like this, if you wanted to wright it that way. Thats also guessing that string $return_query is formatted to support &Some=Thing;Like=That. 
$return_query = $return_query."&cmd=_notify-validate";

[download]

Update: $req->content_type('application/x-www-form-urlencoded; charset=UTF-8'); charset=UTF-8 may not work with PayPal.

Replies are listed 'Best First'.
Re^2: How do you use Paypal IPN with Dancer2?
by MorayJ (Beadle) on Jul 12, 2016 at 11:42 UTC

    Hi, thanks for looking

    You're right to notice that I've got that the other way round - I have tried it as the original.

    This is one of the reasons the script seems to be out of date as paypal docs now talk about prefixing rather than appending (though I have found one comment suggesting that either way now works). They even have an example showing the return content with it prefixed.

    As far as I can tell it is prefixing fine. I'm wondering about encoding and stuff. It's almost certainly something ridiculous that I'm overlooking.

    I'm going to investigate Dancer2's delayed, as might help to keep everything Dancer.

    Thanks again

[reply]

      In the trouble shooting tips they say to keep the same encoding.
      Receiving an INVALID message from PayPal in response to your listener's post back for validation "Ensure that you use the same character encoding for your response string as the encoding specified in the charset field of the original IPN message. When testing using the IPN Simulator, the character encoding will always be UTF-8."

      Update: But I use PDT because "So, use PDT if your site includes a feature that requires immediate payment notification." IPN vs. PDT

      Update 2: From what I can remember of IPN. It does not matter that much that it comes back "INVALID" because all that is saying is that you did not return the data back the way PayPal wanted. But the transaction still will go through and you should still receive the transaction info from the first IPN response.

      Update 3: You did mention encoding and that made me think that maybe the content your getting from request->body; could be encoded or maybe decoded. Or LWP could encode the data before sending it making it a double encoded string. Just a few more things to check for.

[reply]
[d/l]

        Update 2: From what I can remember of IPN. It does not matter that much that it comes back "INVALID" because all that is saying is that you did not return the data back the way PayPal wanted. But the transaction still will go through and you should still receive the transaction info from the first IPN response.

        I've temporarily moved on, but will be coming back to this...was a bit tired of tearning at my hair. Will report back here - but this is a really good point...I could probably live with an unvalidated for the time being as we're not talking about huge amount of sales attracting thousands of cheats

[reply]

In Section Seekers of Perl Wisdom