I have an ipn listener that update my transactions (from pending to completed) and my contracts payments from finished to paid. This is perfect! I has also a return page... From PayPal to my site... This page show "thanks" and "button to allow download their last paid online contract" (paid with PayPal). My problem is that.... Ipn listener sometimes comes 3 seconds after my return page is shown to the the user....
In my return page in this case. Has the transaction and contract unpaid... And when ipn listener catch the results... Then this transaction and contract change to paid status. But ipn listener is executed at back-end. In my server. And my return page was shown 3 o 2 seconds before to my user. What can I do?
Should I add a timer (a delay) in my return page waiting until ipn updates my transaction and contract status? And then, show to the user a button "you can download your last paid contract!". Or better I should forget this step. And in my return page always without wait show to user "thanks for your payment". "you can download your last paid contract!"
You should not regard or show the transaction as complete, or allow any further business action to occur, until you have actually received the money, and only the IPN tells you that.
You need to adjust what you show on your return page accordingly.
All you should really do here is thank the customer for his business and tell him that the download or the delivery or whatever it is will become available immediately PayPal has notified you of the actual transfer.
And note that it can take a lot longer than three seconds. If they chose to fund the payment from their bank account, it can take 3-5 days: and there is always the possibility of that process failing altogether due to insufficient funds.
So don't be too optimistic in designing your return page. The deal isn't done until the money is in the bank.
This page show "thanks"
Good.
and "button to allow download their last paid online contract"
Bad. That should be somewhere in 'My Account'.
I also have my return page wait for the IPN notification to come into my server, and you can definitely make that work if you do it right.
Initially, the return page polls on a field in my back-end database that the IPN handler updates. Then, when the return page sees that field update, the customer gets his 'here are the items you paid for' button.
I also have a one minute timeout on this process. When that expires (although I can't remember the last time that actually happened), I display a catch-all error message ('There was a problem processing your transaction') and invite the customer to contact me for help.
I also tell them that their license key (which is what they are buying, in my case) might be on its way by email, since, usually, it is. IPN notifications can sometimes take a little while to arrive for some reason but my IPN handler sends out a confirmation email as a backup so they will get that in due course. That usually sorts things out, I rarely need to get directly involved.
If PayPal puts the transaction on hold, it doesn't seem to ever forward the customer to the return page (I have certainly never seen that happen). Instead, I assume it lets the customer know that he must wait for the funds to clear and leaves it at that.
An IPN notification does get sent however when the transaction eventually clears, and then you can have your handler send that email.
Lest this sounds like a lot of work, you should be sending an email from your IPN handler anyway since customers like to have a record of their purchases. Once you put that mechanism in place, the rest is easy.
Note: Watch out for IPN transactions flagged as 'echeque'. The funds haven't cleared yet, you will get another notification when they do. Then you can send them their contract by email. If memory serves,this does forward them to your return page so you have to handle that by letting them know that they must wait. In practise, this doesn't seem to happen very often.
Suggestion: have your scripts send you an email when something unexpected happens. This has saved my bacon more than once when PayPal have changed the names of the fields passed to the IPN handler for no obvious reason.
Summary: This is a practical, experience-based write-up of the way my website works, and it works well. I hope readers of this post find it helpful, despite the mysterious downvotes.
Related
I maintain a PayPal integration which uses PayPal HTML Buttons and confirms payment using IPNs. This system has been in production for more than 5 years.
The system sets the cancel_return variable to a unique URL for each order. If this URL gets hit (i.e. if the customer cancels at paypal and gets sent to this URL), it first checks the session, to ensure the user hitting the URL is the same one who initiated the order, then cancels the order.
I noticed that several recent transactions have been cancelled even though the transactions at PayPal were successful.
The logs showed that customers are hitting the cancel_return URL - in some cases just after the IPN has been received, and in one case just before the IPN was received.
I found at least one way to reproduce this behaviour:
initiate the order on my site
complete the payment at paypal
return to merchant
use the back button to return to paypal
I then get a message that says "Your payment was completed. To continue shopping, please return to the merchant." One button is provided: "Return to merchant name".
Clicking this button takes the user to the cancel_return URL!!
PayPal's documentation for cancel_return says
A URL to which PayPal redirects the buyers' browsers if they cancel checkout before completing their payments. For example, specify a URL on your website that displays a "Payment Canceled" page.
Default — PayPal redirects the browser to a PayPal webpage.
My question is whether this is an intentional change by PayPal -- if so I expect it will break many sites -- or if this is a bug. I couldn't find a bug report at PayPal.
Yes, they changed the meaning of cancel_url, though they are not acknowledging this as a bug or an intentional change. This is definitely a bug in my opinion (as documented in the question above).
In addition to the steps above (reproducing using the back button), I found a customer click-trail in my server logs where the customer was sent to the cancel_url, without using the back button, soon after PayPal sent the IPN confirming their successful payment. I confirmed that the customer did not want to cancel and did nothing to intentionally cancel their order. Unfortunately I could not find a way to reproduce.
I registered at www.paypal-techsupport.com and submitted a ticket about this issue. After several exchanges, the end result I got was:
This is the information that I received from our engineer.
Its an expected behavior when the customer click on the back button, it will bring back to the cancel_url.
We would suggest you to do some modification so that the order is not being cancel when the customer go to the cancel_url.
With poor customer support like this, I will not be recommending PayPal to any of my clients in the future.
You can post it here and the PayPal folks can pick it up.....
https://www.paypal-community.com/t5/Merchant-Technical-Support/ct-p/mts
With PayPal billing, with Auto Return and PDT enabled, when a user is returned to one's Return URL after a successful charge event, several parameters are appended by PayPal to the URL (e.g. "tx" for transaction id), which can then be used to identify the user.
However, if the user has just joined subscription with a free trial, no such information is appended and so the user is not identifiable at that point in time.
Since IPN is asynchronous, the IPN notification may arrive too late so one cannot rely on this.
Is there any way of identifying a user via the Return URL after they have entered a subscription with a free trial?
Similar Que: Implementation of free trial period with PayPal doesn't return any custom parameter
"If you are using PDT, then nothing will be sent back as no payment is taking place. Information will only be sent back if you are making a payment. I would recommend using IPN. Both the rm variable and PDT are dependent on the buyer returning back to your site. If the buyer does not return, such as their browser window unexpectedly crashes and closes, or they simply shut it no information will be sent back and it will be lost. This is why the rm variable and PDT are used more for creating dynamic receipts. IPN is more used for updating your system as it does not rely on the buyer returning back to your site. "
"Also with IPN you can resend the data to your system if you need to, and you can also view your IPN history from within your account. IPN usually takes place right after the payment is completed."
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.
Hey guys was hoping you could help me out.
I am integrating paypal (for the first time) in a website using PHP. From what I have read, there are two methods for confirming a successful transaction, PDT and IPN.
Now the thing is, the item's being sold can have a limited stock. So if suppose a person reserves an item and is taken to the PAYPAL site for final payment, I have to stop all other people from making a purchase since the last piece of the item will be "reserved".
But suppose the person (who has reserved the final piece of the item) goes to the paypal page, and then simply closes it. Will this result in a "fail" ipn coming to me (so I should un-reserve the item so others can buy)?
If so, how long will it take for the failed IPN to come?
If not, how exactly should I handle this.
And is there any scenario where an IPN does not come?
You could use the Express Checkout API.
With EC, the payment is a two step process. In the first step, you make an API call (SetExpressCheckout) where you set up the transaction, and redirect the buyer to PayPal. Once there, the buyer authorizes the payment, and returns to your site.
At this point no money has changed hands. You need to make a second API call in order to capture the funds (DoExpressCheckout).
You can hold the item for a specific period, and if the buyer abandons the transaction, or is very slow to approve the payment, you can release the item back to the public. If he eventually approves it, and does come back to your site, you would simply skip the second step, and inform the user that his transaction timed out. No money changes hands, no items are double sold.
For my membership site, I've got the IPN handler done. My question is one of site "flow".
Here's how it goes:
User -> Landing -> SignUp -> Verify -> PayPal -> ThankYou
So here's the problem (which could just all be in my head). Let's say you've signed up and verified your account. Then you click the "Subscribe!" link and are sent to paypal - where you complete payment and get sent to the "Thank You" page.
What if the IPN doesn't arrive back to my site quickly? The subscribe link will still be there, and users may click it again thinking they've not subscribed (even though they have, it's just taking time).
If I combat this by updating their profile to say... "Activating..." when they click the "Subscribe" link, and they don't complete the PayPal process... it could be forever saying "Activating...".
Just curious, as this is my first time integrating PayPal:
How do you handle the state between the time the user clicks the subscribe link and it takes for the IPN process to complete?
Have you ever had any issues with IPN's not arriving quickly?
Your question suggests that the connection to the remote server is asynchronous (ajax)?
It's probably easier to write it in a synchronous manner, so the IPN is guaranteed to return. If it doesn't, it means that:
a) The user closed the browser after being redirected to the remote server;
b) The remote server did not respond.
Good payment gateways will redirect the user back to your site if they click maybe the "Cancel" button, but a return is never guaranteed, so you need to handle it correctly.
I would have a separate table to log the transactions for a given user; that is:
one user, many transactions
Some payment gateways allow you to define as callback to your server when a transaction is completed. That is, the connection is initiated by the gateway -- it does not run the browser, as the user can close the tab/window -- where it does a post to your callback URL, and then you update the status of the transaction.
I'm not sure if PayPal does allow for such things, but so far, I've never had issues with PayPal because I've always written it in a synchronous manner.
Of course, if asynchronous is required, then your ajax function has to have a timeout/error handler -- I recommend jQuery, of course.
I've never had any issue with IPN not arriving quickly, but then again I have never really had a huge website with a lot of users. I also didn't make any significant changes to a user account until I received the IPN.
I made a paid registration for one of my websites using the paypal API. A user would fill out their username, password, etc. and I would pass the variables to the paypal API. The data wouldn't be acted on until I did receive the IPN.
You could always associate a timestamp with a pending payment if you feel the status "Activating..." is important within a user profile. A pending payment could timeout after 10 minutes.