My notification script is launched twice first is VERIFIED and second INVALID.
I've tried different ipn validation scripts and always get it twice.
I'm using sandbox maybe seller account settings are not right? I've set IPN on with notify url and auto return. Also in form there is return and notify_url set
I remember in the documentation it states that duplicates are possible -- that's just the nature of the internet. That's why it gives you a unique transaction ID. You're supposed to use that to prevent bad things from happening if you get notified twice.
A better question might be: why does it say Verified and then Invalid? Or is that ok?
EDIT
The docs say "PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent". I'm going to guess that YOUR code accidentally sends the "echo" back to PayPak twice and one of them is malformed. Maybe they're both identical but PayPal responds with INVALID if it gets it twice. But no matter, for a particular transaction Id, once you get VERIFIED, you're good. Simply ignore all subsequent responses.
EDIT 2
The return url is simply used by PayPal to redirect the user back to your site. Use this page to thank them for their purchase and inform them they will be notified once processing is complete. You can even set this to an empty string if you don't want this feature. When Payment is actually complete (or some problem was identified), PayPal will invoke the script referenced by the notify url. This is where you make sure everything looks right, handle duplicate notifications, update your database, send an email to the user saying their payment was processed, etc.
before inserting or updating your mysql query Check if the returned Transaction id '$_POST['txn_id']' already exists in your db table, if it doesnt exists so insert it with other $_POST data, because paypal calls the notify url many times.
Related
I read that I need to send a confirmation to paypal with the fields in the same order plus the cmd=_notify-validate field. I know that for certains event the fields will be different, but for example for a notification of paid using paypal buttons, will the params will always be in the same order?
Due some limitations I can't get the whole POST fields array (I can only get them by explicitely calling the key) so an option is to set each field in the confirmation request to paypal.
Whether it's always the same order is irrelevant. You're supposed to send them back in the same order they arrived in, whatever that was.
BUT I don't believe that observing the same order in the validation request is necessary, and in some languages, e.g. Java, it isn't even possible, as the order isn't preserved. I've been running IPN for several years without observing this constraint, and I've only ever had one validation failure, from Turkey, which remains unexplained but could have been say a character set issue.
Note that PayPal provide sample code for Java somewhere which therefore doesn't observe the constraint either. One assumes it was tested and passed a review ...
I have just created my first PayPal button and it is working correctly within sand box. I would like to know the best way (if possible) to issue a unique activation code on my return url ensuring that the user has definitely paid before they receive the code. I could manually email the code but wondered if the was any way of automating this using some sort of return value? Possibly returning to an aspx page which then reads from my database to get the next activation key and displays it?
Thanks
Garry
As you already know that PayPal doesn't provide such facility for delivering activation instantly but it does offer the Instant Payment Notification API (PayPal IPN) which can be used to build such a platform.
Here is a great article for that purpose only. https://www.codeproject.com/Articles/383207/Selling-software-using-PayPal-IPN-as-an-eCommerceenter link description here
The best way to handle that would be to use Instant Payment Notification (IPN).
Any time a transaction happens on your site (whether it's a payment, refund, cleared pending payment, dispute, etc.) the PayPal server will POST details about that transaction to a script you have sitting on your server.
This script can receive the data and process it accordingly allowing you to automate things like updating a database, generating email notifications, hitting 3rd party web services, delivering e-goods, etc.
If you want the activation code to be visible on the return URL you can look at Payment Data Transfer (PDT), which is just like IPN except that it's made for use with the return URL. It is not recommended to use this, though, for post-transaction processing because there is no guarantee the user will make it back to the return URL, for one, and also it wouldn't handle things like e-checks correctly.
As all we know there is a custom param that allow us to retrieve custom data when an ipn notification come from paypal.
But also, I am using a couple of params in the notify_url, and those params sometimes get lost, and when paypal send to me the ipn notification, it comes without one of those params. The strange thing is that one of the param come correctly.
So, first question is: Can I use custom params in the notify_url like:
notify_url = "www.mydomain.com/paypal/ipn/?param1=one¶m2=two"
I suppose that I can do it, because it fails 1 in 20 times on my application, so I do not know if it is because it is not supported by some browsers or something like that, or maybe it is a bad habit I should quit.
And sometimes paypal send the ipn notification to:
notify_url = "www.mydomain.com/paypal/ipn/?param1=one"
Without the second param...
And if I can do it, do you have any clue about what it is happening here...
Thanks!
I always avoid sending data to IPN as URL parameters. There are various reasons it may not come through, which means there's no guarantee it'll work correctly every single time.
Instead, use the CUSTOM parameter like you said. If you need to pass more than a single value you can send it as an NVP string just like you would on your URL. Then just parse those values back out of the CUSTOM value within your IPN script.
Alternatively, you could save all of the data you're going to need in your database and then send the record ID in the CUSTOM parameter over to PayPal. Or you could use the INVNUM parameter if that makes sense for you.
Then in your IPN script you pull that data back out of the database based on that record ID. This way you're always sure you'll have it available and won't have to worry about losing URL params along the way.
I'm using the callback API to prevent someone selecting a non-UK shipping address. I've supplied a callback url, I've set CALLBACKVERSION to 61.0.
When I go into the sandbox and choose an address I know the callback page is being called as I've added code to email me the values submitted to it and the value returned to PayPal. For anything with a SHIPTOCOUNTRY that isn't GB the response is
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1
I've also tried setting a fuller response in case it doesn't like some required field to be missing
METHOD=CallbackResponse&CURRENCYCODE=GBP&L_SHIPPINGOPTIONNAME0=Standard&L_SHIPPINGALABEL0=Standard&L_SHIPPINGAMOUNT0=2.95&L_SHIPPINGOPTIONISDEFAULT0=true&L_SHIPPINGOPTIONNAME1=Express&L_SHIPPINGALABEL1=Express&L_SHIPPINGAMOUNT1=5.95&L_SHIPPINGOPTIONISDEFAULT1=false&NO_SHIPPING_OPTION_DETAILS=1
But it's still allowing non-UK addresses and just using the shipping options set during the initial set up request.
Any suggestions on where I'm going wrong?
After opening a ticket as suggested by PayPal_Patrick the problem was that I was adding the callbackversion in the wrong place. The full response to reject a shipping address on callback is:
METHOD=CallbackResponse&NO_SHIPPING_OPTION_DETAILS=1&CALLBACKVERSION=61
There are different transaction ID's for Buyer and Seller accounts.
I think this might be an issue caused by the country associated with the buyer account being used. I'm going to reach out to the product team for Express Checkout and see if it is intended functionality or not - I don't believe it would be.
If you want to stay updated on the issue I would recommend creating a ticket to PayPal.com/mts, give me the ticket number, I'll grab it and keep you involved.
I'm developing a site for a client, and he wants people to be able to buy licenses/support contracts via PayPal. What I'm stumped on is how I can make the payments secure. My current idea is to generate a random string using MD5 or whatever, plug this into a database, and send it along with the rest of the PayPal button code. When the payment is completed, the user is redirected to a PHP page where there is code to update their information in the database. The only thing stopping a hacker giving themselves a license/whatever without paying is the random hash, which can be found out using a sniffer of some sort, and plugged into the POST data returned by the PayPal code.
So. My question is this: How do I execute custom PHP code only on a successful PayPal payment, without leaving any loopholes open for the more evil users of the interwebs?
I think you should use a Payment Gateway such as PayFlow
if you're on the website ready to pay, there maybe a session already with your user logged in?
in this scenario, when the user returns back to the website, you can check you have a particular session variable and if it exists, you do the following
1) check your session, do you have a user logged in? should still be logged in if you just visited paypal a few minutes ago.
2) does the session contain your sale_id?
3) if no, dump the user on the home page, remember to header("Location..."); die("DEAD"). the die() part is important
4) if yes, check the sale_id was paid, the notify url should have caught the POSTED payment data, if valid, allow them to update the data
5) if yes, but not valid, allow them to repay using another method, this means to redirect them to another page to attempt to pay again, but don't let them access the "change details" page, the only way you get there, is by strictly validating the payment was successful.
how does that work for you ?