PayPal IPN sends multiple notifications hours after payment completed - paypal

In the IPN docs there is this line:
To handle the possibility of transmission and receipt delays or failures, the IPN
message service implements a retry mechanism that resends messages at various intervals
until you acknowledge that the message has successfully been received.
IPN is sending the same notification 9 times... What do I need to send back? There are no errors in my script. If I use the IPN simulator I get the following message:
IPN sent successfully
It would seem then that the simulator can tell the message is being sent correctly but the real notifier can't?
I am using sandbox if that makes any difference?
Do I need to print anything upon receipt of the notification?

No need to worry about the multiple notification. First send back the IPN message then process it. While processing check the check that txn_id has not been previously processed. If it is already processed, it is a duplicate IPN message from the Paypal and you can ignore the processing.
For more info refer the pdf file:
IPNGuide.pdf
EDIT:
Do I need to print anything upon receipt of the notification?
No need to print anything but if you want to log the details you can log them.
From the pdf file I mentioned above(Page number 10)
Your listener must respond to each message, whether or not you intend
to do anything with it. If you do not respond, PayPal assumes that
the message was not received and resends the message. PayPal
continues to resend the message periodically until your listener sends
the correct message back, although the interval between resent
messages increases each time. The message can be resent for up to
four days. This resend algorithm can lead to situations in which
PayPal resends the IPN message while you are sending back the
original message. In this case, you should send your response again,
to cover the possibility that PayPal did not actually receive your
response the first time. You should also ensure that you do not
process the transaction associated with the message twice. IMPORTANT:
PayPal expects to receive a response to an IPN message within 30
seconds. Your listener should not perform time-consuming operations,
such as creating a process, before responding to the IPN message
See page number 19-20
Your listener software must
Wait for an HTTP post from PayPal.
Create a request that contains exactly the same IPN variables and values in the same order,
preceded with cmd=_notify-validate.
Post the request to paypal.com or sandbox.paypal.com, depending on whether you
are going live or testing your listener in the Sandbox.
Wait for a response from PayPal, which is either VERIFIED or INVALID.
If the response is VERIFIED, perform the following checks:
Confirm that the payment status is Completed. PayPal sends IPN messages for pending and denied payments as well; do not ship until the payment has cleared.
Use the transaction ID to verify that the transaction has not already been processed, which prevents duplicate transactions from being processed.
Typically, you store transaction IDs in a database so that you know you are only processing unique transactions.
Validate that the receiver’s email address is registered to you. This check provides additional protection against fraud.
Verify that the price, item description, and so on, match the transaction on your website. This check provides additional protection against fraud.
If the verified response passes the checks, take action based on the value of the txn_type
variable if it exists; otherwise, take action based on the value of the reason_code
variable.
If the response is INVALID, save the message for further investigation

You've got something going on with your IPN script that's causing it to fail a lot. This could be happening at the very bottom of the script so everything you expect to see happen does happen, but then a 500 error gets sent back to PayPal.
Have you checked your PayPal IPN History to see what it's showing there? You'll probably see lots of errors. Also, you'll want to check your web server logs to see the error that's happening when that script is hit.
It could be something that only happens with certain orders. For example, I often see people doing database updates or something similar and a name like O'Reilly breaks their script because they didn't handle the apostrophe correctly.
Looking at your web server logs should show you where the error occurred and then you can run some tests to help figure out the problem. I like to create a basic HTML form, set the action to my IPN listener, and then add hidden fields that match what I expect to get in an IPN. That way you can load it up in a browser and post various values to it directly which allows you to see the result on screen. Just keep in mind that if you're testing this way the IPN won't be verified since it didn't come from PayPal, so you'll need to make sure your code is setup to handle that accordingly.

You have to reply with an empty 200 response to indicate to PayPal the IPN was received correctly after processing the response data as
public function yourIpnHandler(){
//response verification and processing goes here
header("HTTP/1.1 200 OK");
}
After getting an empty 200 response, PayPal will not send more responses as it understand that response is delivered successfully to ipn-handler.

Related

IPN call coming through but Paypal server keeps resending them

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

How to process read receipt vs delivery receipt vs bounceback (JavaMail)

We have a requirement coming in to try to, as best we can, determine the progress an email made to the user. We know it's not 100%, and the solution I'm advising is to use an image/watermark in the email that is loaded from a URL that would record that the image was read...BUT there's a fair chance that they're going to rely on read/delivery receipts and bouncebacks. So I wanted to learn more about it, both to be ready and so I can argue against it in the meeting.
If we were to set up an email mailbox to receive bouncebacks, read receipts, and delivery receipts and then write a java program to poll said mailbox, get the messages and inspect them. How could I tell the bounces from the read receipts from the delivery receipts from the spam? I know that the read and delivery receipt REQUESTS are SMTP headers. Do the returning messages have a header that tells which they are? And do the bouncebacks? And if so, what are they? If not, am I parsing the message body? Does that differ from server to server? Is there any standard (or close to standard) thing in it? Like the word 'undeliverable' is always there?
I tried to google, but all the hits I could get were about REQUESTING the receipts.
How could I tell the bounces from the read receipts from the delivery receipts from the spam?
Jakarta Mail and JavaMail have com.sun.mail:dsn artifact that have support for parsing and creating messages containing Delivery Status Notifications.
Those classes have constructors that can parse the delivery notifications but it may not be able to parse any read receipt.

Ensure at-most-once semantic with SendGrid Mail API

I have an [Azure Storage] queue where I put e-mail messages to be sent. Then, there is a separate service which monitors that queue and send e-mails using some service. In this particular case I'm using SendGrid.
So, theoretically, if the sender crashes right after a successful call to SendGrid Mail Send API (https://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/index.html), the message will be returned to the queue and retried later. This may result in the same e-mail being delivered more than once, which could be really annoying for some type of e-mail.
The normal way to avoid this situation would be to provide some sort of idempotency key to Send API. Then the side being called can make sure the operation is performed at most once.
After careful reading of SendGrid documentation and googling, I could not find any way to achieve what I'm looking for here (at most once semantic). Any ideas?
Without support for an idempotency key in the API itself your options are limited I think.
You could modify your email sending service to dequeue and commit before calling the Send API. That way if the service fails to send the message will not be retried as it has already been removed from the queue, it will be sent at most once.
Additionally, you could implement some limited retries on particular http responses (e.g. 429 & 5xx) from SendGrid where you are certain the message was not sent and retrying might be useful - this would maintain "at most once" whilst lowering the failure rate. Probably this should include some backoff time between each attempt.

IBM Sterling order management - Email Server

I'm trying to send the mail to the store (Node), on the onsucess event of createOrder api.
So for this, I've created 2 new services.
The first service receives the information from the onsucess event of the createOrder api and passes it on to the queue.
The second service receives the information from that queue and passes it on to the email server.
This sends the email. The problem is that for some of the orders the email is not sending, but we are not getting any exceptions for these.
In the logs for those orders it shows the "Successful Acknowledgement from the email server".
I don't know where the exact problem is. I have checked the email server, but cannot find anything related to the missing order information.
What steps can I take to further debug this problem?
You are saying, only some orders have this problem . Then it will be something related with the order details like the email id associated with it. And also if the successful message in logs shows message has been sent. But if it is a customized log please check it once again. If its Ok then please check the Email Server logs directly.

Sending emails in web applications

I'm looking for some opinions here, I'm building a web application which has the fairly standard functionality of:
Register for an account by filling out a form and submitting it.
Receive an email with a confirmation code link
Click the link to confirm the new account and log in
When you send emails from your web application, it's often (usually) the case that there will be some change to the persistence layer. For example:
A new user registers for an account on your site - the new user is created in the database and an email is sent to them with a confirmation link
A user assigns a bug or issue to someone else - the issue is updated and email notifications are sent.
How you send these emails can be critical to the success of your application. How you send them depends on how important it is that the intended recipient receives the email.
We'll look at the following four strategies in relation to the case where the mail server is down, using example 1.
TRANSACTIONAL & SYNCHRONOUS
The sending of the email fails and the user is shown an error message saying that their account could not be created. The application will appear to be slow and unresponsive as the application waits for the connection timeout. The account is not created in the database because the transaction is rolled back.
TRANSACTIONAL & ASYNCHRONOUS
The transactional definition here refers to sending the email to a JMS queue or saving it in a database table for another background process to pick up and send.
The user account is created in the database, the email is sent to a JMS queue for processing later. The transaction is successful and committed. The user is shown a message saying that their account was created and to check their email for a confirmation link. It's possible in this case that the email is never sent due to some other error, however the user is told that the email has been sent to them. There may be some delay in getting the email sent to the user if application support has to be called in to diagnose the email problem.
NON-TRANSACTIONAL & SYNCHRONOUS
The user is created in the database, but the application gets a timeout error when it tries to send the email with the confirmation link. The user is shown an error message saying that there was an error. The application is slow and unresponsive as it waits for the connection timeout
When the mail server comes back to life and the user tries to register again, they are told their account already exists but has not been confirmed and are given the option of having the email re-sent to them.
NON-TRANSACTIONAL & ASYNCHRONOUS
The only difference between this and transactional & asynchronous is that if there is an error sending the email to the JMS queue or saving it in the database, the user account is still created but the email is never sent until the user attempts to register again.
What I'd like to know is what have other people done here? Can you recommend any other solutions other than the 4 I've mentioned above? What's a reasonable way of approaching this problem? I don't want to over-engineer a system that's dealing with the (hopefully) rare situation where my mail server goes down!
The simplest thing to do is to code it synchronously, but are there any other pitfalls to this approach? I guess I'm wondering if there's a best practice, I couldn't find much out there by googling.
My 2 cents:
Once you have a user sign up, never roll back the registration if sending the E-Mail fails. For simple business reasons: They may not come back or re-register if it doesn't work out at the first try. Rather tolerate an incomplete registration and nag the user to confirm their E-Mail address as soon as possible.
In most cases when sending an E-Mail goes wrong, your app will not get immediate feedback anyway - non-existent E-Mail addresses on valid servers will send back a "undeliverable" message with some delay; if the mail gets eaten by a spam filter, you'll get no feedback at all; in other scenarios, it may take several minutes (greylisting) to several days (mail server temporarily down) for an E-Mail to get delivered. A synchronous approach waiting for the delivery of the mail is therefore doomed IMO. Even an immediate failure (because the user entered a obviously fake address) should never result in the registration getting rolled back.
What I would do is, make account creation as easy as possible, allow the user access to the account before it is confirmed, and then nag the hell out of them to confirm their E-Mail (if necessary, limit access to certain areas until confirmation). I would prevent the creation of a second account with the same E-Mail, though, to prevent clutter.
Make sure you allow changing the E-Mail address even if the previous address hasn't been confirmed yet, and enable the user to re-request the confirmation message to a different address.