Yep - I just noticed them now - sorry for the question.
And thanks for introducing me to DecodeURLComponent - I originally thought that was one of your own methods.
Great discussion - thanks All!
Here’s what I think the answer to the original question is.
[quote=314244:@Michel Bujardet]Before the code I posted, I have
Request.Status = 200 // An HTTP Response code of 200 means everything is OKand at the end of HandleURL
Return True[quote=314213:@Tim Parnell]It’s the start of a race condition. Your web app will begin the process of the third step before it returns the HTTP status code of 200. Chances are it will complete HandleURL (and return the status) before being able to send out the request for verification, but who knows, the race is on!
Remember! New Framework sockets are always aysnc.
Edit for clarification.[/quote]
In the world of async, you never worry about the order of things.
Except, you need to. PayPal wants that 200 code before you verify.
Not really. In my listener which has been running now for a couple years, the HTTPSocket post back is started before the Return true validates the 200 status.
In fact, I suspect Paypal does not really need a status 200 if it receives the post back within, say, a second or so.
YAY!
After updating my Xojo Cloud server (for the needed HTTPSocket support) per this thread: https://forum.xojo.com/38798-xojo-net-httpsocket-on-xojo-cloud I have now successfully completed an operational proof of a Paypal Listener!
Thanks to all in the forum and at Xojo that contributed to help!