As I receive an IPN from PayPal, I would not like to process it immediately, but, instead, queue the message and then process it with a scheduler.
Therefore, there's a point that worries me - if I queue a message and only process it (including the '_notify-validate' verification), let's say, 12 hours later, will I be able to do it?
Thanks in advance.
You can't schedule a delay with PayPal for when we send out the IPN post and if you don't reply back to PayPal within a few seconds we'll reattempt to send the post later.
It is possible to not reply to, like, the first six IPN posts for a payment but doing that will eventually start to trigger an e-mail telling you that the posts are not being replied to right away. It may possibly lead to IPN being disabled on your account.
Related
I'm using paypal adaptive payments to make transaction via paypal. Although few of transactions are taking more than 6 hours too receive IPN.
I've gone through forum posts and their documentation, I came through - https://developer.paypal.com/webapps/developer/docs/classic/products/instant-payment-notification/
"Because IPN is not a real-time service, your checkout flow should not wait for the IPN message before it is allowed to complete. If the checkout flow is dependent on receiving an IPN message, processing can be delayed by system load or other reasons. You should configure your checkout flow to handle a possible delay."
The callback is taking more than 6 hours is way too much. any suggestions ?
I've built several custom carts. On average, I see the PayPal IPN come back within 2 minutes at the longest, and usually recurring payments take longer than single payments because they send two IPN messages, not just one, on the initial setup. I usually take the 'custom' property and put a unique identifier that I have permanently cookied. So, even though I may see an initial IPN come in on a recurring payment, I wait for the one that says that txn_type is subscr_payment and also that payment_status is Completed. You can't really trust a subscription payment as being paid unless you see that second message. And if it's a single payment, then I look for txn_type to be web_accept and payment_status to Completed.
The way I handle things is to redirect the customer to PayPal to purchase using the form button technique. The customer pays and then gets redirected (thanks to the form hidden vars I created initially) back to my own custom cart URL that I specify. I call that URL the payment-confirmation script. I display a message with a progress bar to please wait while their payment is being confirmed with PayPal. I hold them there 10 seconds and then redirect to the receipt. It is on the receipt where I check the database to see if my IPN script has already processed this order. If not, then I redirect them back to the payment-confirmation script again for another 10 second progress bar delay. My receipt uses a session cookie to ensure I never send them into a loop more than one time to the payment-confirmation script. So, the customer waits another 10 seconds and then comes back to the receipt page, where I test again, reading my permanent cookie on the 'custom' property that I saved, versus the 'custom' property that comes in from the IPN that I use as the order key in the database. Usually within the first or second 10 second delay, the IPN has come in and I can proceed. However, if the IPN has still not come in, then I redirect to a friendly error message saying that their payment cannot be confirmed and to call our call center to remedy the issue. Our call center techs then see the delay problem in PayPal, back the other transaction out, and sell to the customer over the phone manually, instead.
I am applying PayPal Direct Payment on my website. My question is how much time is needed from when a Direct Payment is committed until I receive IPN message that the payment is Completed or for example Denied, Failed or something else?
Some important notes depending on how/why you are asking about "time":
IPN is an asynchronous message service, meaning that IPNs are not synchronized with actions on your website. Thus, listening for an IPN message does not increase the time required to complete a transaction on your website.
...
The IPN message service is not a real-time service. As a result, your listener may not receive an IPN message for many seconds after an event occurs. As a result, your checkout flow should not depend upon receiving an IPN message to complete. If it does, your checkout flow will be slow during periods of heavy system load and complicated, since it must handle retries.
REF: Introducing IPN
Hth...
That should be instantaneous and will certainly be no more than a couple of seconds. As soon as PayPal receives a Payment to your account it will send this Instant Payment Notification. I think the name says it all.
More information: https://developer.paypal.com/docs/classic/products/instant-payment-notification/
I've built a listener to capture PayPal transactions using IPN into Salesforce. However, it's only receiving a small percentage of our PayPal transactions.
I've determined that they're not always being sent by:
I manually send (url-hack) a never before seen IPN string on the listener page. It processes immediately and perfectly.
I go to PayPal and instruct the site to resubmit the same IPN
Since it's a known transaction my system will send an error message. I've verified this
by repeating step 1.
The message that should be produced by step 2 never arrives. The other IPNs that were also resubmitted during step 2 also never appeared in Salesforce.
Your insights are greatly appreciated as this is amazingly frustrating!
Steve
Addendum
Based on advice in a comment from #Andrew Angell below, here's more information...
All of the IPN histories look like the following. Notice the Notification URL. Could my problem be that it doesn't contain my listener page or even match my IPN Notifier setting (which I just double checked)?
Also all of the transactions have a response code of 200 and zero retries.
Sometimes it happens that my server can't receive the ipn (various reasons) and I wonder if there is a way to ask for it again.
I know you can use the ipn tool from your paypal account to resend but I have hundreds of transaction every day and it will be very annoying to do this manually.
Thank you
If your IPN fails then PayPal's system will automatically resend it again until it gets a good response back. It'll typically wait something like 1 min, then 2 min, then 4, etc. and keep resending until it gets a 200 OK response back from your script, so this should be happening for you already.
If you end up with enough failures PayPal will eventually send you warnings and then if it still continues after that they'll disable your IPN so it doesn't waste their resources sending data to it.
I am adding subscriptions to a site using Paypal IPN which works very well, I can successfully create a new subscription and verify it. The subscription has a two week free trial. The guide was unfortunately a little vague on subscription statuses.
At the moment, the users account gets subscribed status once subscr_signup or subscr_payment is received and gets removed when either subscr_cancel or subscr_failed is received. I believe this is correct but it's best to make sure.
Also what is subscr_eot? the IPN guide describes it as "subscription’s end-of-term." Does this get triggered after the trial period is over?
subscr_eot is sent when a user's last paid interval has expired. subscr_cancel is sent as soon as the use cancels the subscription - for example:
User signs up on day 1 for a subscription which is billed once a month.
subscr_signup is sent immediately, subscr_payment is sent as soon as payment goes through (usually immediately as well).
On day 13, the user cancels. subscr_cancel is immediately sent, although the user has technically paid through to day 30. Cancelling at this point is up to you.
On day 30, subscr_eot is sent - the user has cancelled, and this is the day which his last payment paid until.
Not much changes with trial subscriptions - if a user cancels before a trial subscription is up, subscr_cancel is sent immediately, and subscr_eot is sent at the end of the trial.
Also, one interesting detail is how subscr_eot works with subscr_failed.
It looks like subscr_eot comes after the FINAL subscr_failed. So if in your account you set it to automatically retry failed payments 3 times, then it should go like this:
first failed payment => subscr_failed
second failed payment => subscr_failed
third failed payment => subscr_failed and subscr_eot
so basically in your code you can set subscr_failed to trigger an email like
hi user,
please take moment to check
your payment info, you may need to
update the credit card expiration
date, etc. You still have access,
we'll try again in a few days.
And setup subscr_eot to actually turn their subscription off and trigger an email like
Sorry, we still havent' gotten payment
and have taken your profile down. You
can still reactivate it by logging in and updating your payment info
Basically this is the "nice" way of doing it so customers have a grace period, and their account isn't shut off unexpectedly just because of an expired credit card or something like that.
The thread posted by Chris has been updated recently.
Sometime in 2010, PayPal stopped using subscr_eot when a user cancelled their account. After a number of complaints, they reinstated this, but took 6 months to do so. All this means is that you can once again handle your subscription notifications as described by Peter in the accepted answer.
From a PayPal representative:
subscr_cancel means the profile is
canceled and there will not be future
payments. However, if the buyer has
already paid for the current billing
cycle as they are charged up-front,
then you can use the subscr_eot to
terminate the profile.
Still unsure what happens in the event of multiple failed payment attempts, however. PayPal documentation at the moment is terrible.
It depends on the account if it is new or not whether subscr_eot gets sent, which is kinda beyond me?
I haven't found the proper way to manage subscriptions yet. Calculating the dates on the server could go wrong very fast if there is a delay in payment.