I'm trying to test using the IPN Simulator and can't get it to work with anything other than first level .com domain
Anything like
domain.co.uk or
subdomain.domain.com
is giving me errors. (We could not send an IPN due to an HTTP error.)
This makes it more difficult, as I'm obviously not going to be testing on my live domain.
Am I missing something?
Thanks,
Stevo
My website did not respond 200 on the POST request.
Only responded 200 on a GET request, which is all I tested. After fixing my web server, all seems fine
Related
My IPN scripts have been working for many years now and I have made no changes. Starting last week the PayPal server seems to think that I am not getting the messages. I have checked my server logs and all calls from paypal return 200 ok. The calls also do the database entries and mods as if everything is working, but PP server thinks I did not receive them, so they keep re sending. Any advice on how to diagnose would be greatly appreciated as you know how PP deals with these things.
IPN php scripts that have been working for years
they add entries into my database and return 200 ok from my server logs but paypal thinks I did not recieve them so they keep re-sending
Review your account's IPN history at: https://www.paypal.com/merchantnotification/ipn/history
This will show the HTTP status you are actually returning to PayPal. If PayPal is retrying the sending of IPNs, it is either receiving no response or an HTTP status other than 200.
Cross check with your web server's logs to confirm, and assuming you are sending something other than 200 proceed with debugging that issue.
yes off course I checked IPN history. Most of them show no response code, My server logs show it responded 200 ok
I have just begun working with an account that had been set up by someone else using Auth0 and Sendgrid to handle email verification.
Ever since the 11th of December, the whole thing just stopped sending emails out of the blue. We thought it had to do with payment plan but even after the upgrade it didn't change anything.
But here's the weird part: When we send a test email the whole thing works perfectly, but when we try to re-send authentication email it doesn't.
Does anyone have any clue as to what might be going on? We've checked settings and price plan and neither are any different to other accounts with the same set-up, yet it hasn't been working since the 11th.
I work with the Auth0 Community team. Are you seeing anything in the logs about emails failing to send? Are verification emails turned on for your tenant? We also have a step by step setup doc for setting up Send Grid which you could use for confirming your current setup which I've shared below. I hope this helps you in the path forward.
https://auth0.com/docs/email/providers#configure-sendgrid
I have an Ionic 3 app that has some code that fires an email to a recipient once a certain action is triggered. When I test this in the browser, I get the preflight issue and so I get around this using a Google Chrome plugin that allows me to enable CORS and when I actually execute the function, I get a success that looks like:
Headers {
ok:true,
status:200,
statusText:"OK",
type:2,
url:"https://api.mailgun.net/v3/https://api.mailgun.net/v3/<my-domain>/messages",
_body:"Mailgun Magnificent API"
}
However, an email is never sent to the address provided. It's not in spam or anything either. Does anyone know what might be causing this?
Check these three things :
1) Your URL seems very strange, with nested https://. It should be simply https://api.mailgun.net/v3/<my-domain>/messages
2) Make sure you validated your Mailgun account before trying to use it
3) Are you in sandbox mode ? If yes, did you add authorized recipients ? If not, you can't send any email.
Does it make a difference at all whether I serve the images in an email campaign from an encrypted domain? Will this make emails less likely to end up in a client's spam folder?
Using http insteadt of https will most likely not affect the spam/ham classification.
However, it could throw warnings in older browsers, which may confuse your recipients. The reason is because most webmail services - like Gmail, Outlook.com (former Hotmail), or Yahoo! Mail - default to SSL when the user logs in. Loading images from non-secure sources now is a possible security leak. This blogpost and the screenshot below illustrate the problem and the resulting browser behaviour.
Furthermore, you'll miss referrer information of a recipient who opened an email on https, when the tracking pixel is located just on http.
Finally, if you use https, make sure the certificate is valid and up-to-date. Otherwise email clients like Thunderbird throw warnings.
It doesn't make a difference. Almost everyone uses http:// without any spam hit, so there is nowhere for https:// to improve on that, even though spam filters are an accumulative score.
If there was something in either your content or reputation flagging you as spam, having https:// linked images wouldn't award you any 'bonus points' to save the day.
I second #lukeA's answer and would like to stress that the impact of using images served over http:// connections has certainly increased, even in web-based email clients.
See for example Google Inbox in Chrome (48.0.2564.109), before and after looking at an email which includes an image served over http:// (in that case, a spam email). Note the green lock is gone until you refresh the page!
Gmail's image proxy serves all images over https:// - however, it is unclear (to me) for which images the proxy is really used. For that particular spam mail that I opened to create the below snapshots, it certainly isn't.
I'm getting this answer when trying to use PayPal's IPN Simulator ("We're sorry, we could not send an IPN").
I know there are all kinds of ways I could be doing something wrong on my end, but I think I have covered all of them by now. My callback works when I send a POST request with dummy transaction data myself, from a computer in a different network than my server is in. There appears to be no firewall/proxy/connectivity/topology issues, server is there, port is open, and yet the simulator does not send IPNs.
I'm NOT using HTTPS and my server is NOT listening on port 80, does the IPN service has any restrictions on either protocol or port? If not I really have no idea what might be wrong.
Thanks, any help will be greatly appreciated.
It looks like that the IPN simulator does not want to work on ports different than 80.
Also, you should check if you need to add additional headers like host (http 1.1) and connection close. I'm saying this because they are missing from the example script from paypal (PHP impl)