This seems to be a common problem but I can't seem to find any solutions for it. I have used the Ipn simulator testing and it works fine, but when I test out a transation by going through the payment process Paypal never hits my Ipn Listener. I am currently testing in the sandbox
I am using the Express Checkout API and setting the NotifyUrl in the DoExpressCheckoutPayment method. Why is paypal not hitting the url specified in there?
Problem was the documentation and version I were using didn't match up, so I was using deprecated parameters. For some reason using deprecated commands does not throw any errors, so it is hard to debug.
Paypal does a real good job of hiding their documentation and making it difficult to match API version with documentation version.
To take a stab, are you sure the URL is accessible by paypal? Paypal is calling it so urls like localhost will not work. If it is https and you're using a development certificate that might explain it as well. Is your firewall possibly blocking it?
Related
I'm in the process of developing a feature to accept payments in my website, and I already did it using a paypal button and IPN (a PHP listener to process data to a DB once the payment is completed, this one actually https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.php, properly customized).
I never touched PayPal API and I wonder if I am missing something... I'm kind of new to this kind of development and I want to be sure I'm doing it right and not missing any obvious thing which might compromise the security of the payment or whatever... I already tested things in Sandbox and everything works as expected, but I am concerned about the API and I see many people using it...
So, am I missing anything?
Thanks!
What you've done is accurate and will work just fine so long as it's suiting your needs.
One potential security risk would be if you are not using a hosted button. Did you choose to "Save this button at PayPal" when you created the button? If so, you should see a hosted_button_id included in the HTML for the button. In this case it's protected.
If the button code includes individual parameters for things like item_name, amount, etc. then that code could be adjusted by people in their browser and then the button could be submitted with different pricing, for example.
You could check for this sort of thing in your IPN script and setup an automatic refund if the price doesn't match your database, but I generally try to avoid that sort of thing.
I prefer using the Express Checkout API instead. If you were comfortable getting IPN working with PHP then you should be plenty comfortable using this PayPal PHP SDK to integrate Express Checkout.
The three calls you'll need to work with are SetExpressCheckout, GetExpressCheckoutDetails, and DoExpressCheckoutPayment.
This documentation will cover the general steps and where those calls come into play, and that library will make each of those calls very simple for you.
Express Checkout will eliminate any potential adjustments users could make to code (because they won't be able get to the code at all unlike HTML) and it also has more advanced features and options that PayPal Standard does not have. Most importantly, the ability to force the "guest checkout" experience so that non-PayPal account holders can easily checkout using a credit card without any confusion.
They can do it with PayPal Standard, too, but depending on cookies set in their browser it may make the guest checkout option tough to find. Express Checkout makes it very prominent at all times, and generally results in increased checkout conversion rates.
I set up the RESTful API for PayPal in .NET, using their sample. It kinda works... I did manage to create a payment, but when I use the approval URL, it always says: dispatch error.
What could be the problem?
As I found out, the problem was: I was logged in with my paypal account. I used the same browser instance for reading documents, checking my PayPal account AND testing. Bad idea. PayPal assumes, that you want to pay with your merchant account.
Solution: use a different browser, or turn on your private mode in the browser. (You can also clear your cache, but as soon as you log in to PayPal to check the payment, you are back to square one.)
I'm using NopCommerce 3.0 system with PayPal Express plugin (http://noppaypalexpress.codeplex.com/). It used to work without HTTPS, but not it doesn't. I know that in Magento there is an option called "Transfer Shipping Options", after disabling it PayPal doesn't require SSL. Can anyone explain me what does this option actually do? What does it set in the PayPal API? I could not find anything in the PayPal documentation or in the plugin source code. Unfortunately installing SSL certificate is not an option.
Transfer shipping options uses a CALLBACKURL, which must be HTTPS. I don't have specific knowledge of NopCommerce, but most likely they haven't even implemented this functionality.
Express Checkout w/o a CALLBACK should work fine from an HTTP site, with a RETURNURL/CANCELURL that also happens to be HTTP. It is up to the cart module to pass the correct URL to PayPal so the buyer may return to the site and complete the checkout.
We are having some problems with paypal:
Notify url and status appears empty in the message details page.
The retry date on the ipn message appears in 1985:
What can we do to fix this, besides get back in time to catch that retry?
Overview:
We use basic payments
We use the notify_url param from a php redirection
it worked perfectly on sandbox and live, until you updated
The paypal ipn transaction shows the correct custom parameter
Server side:
Php + custom framework.
There are currently some issues with IPN, that are being addressed that should resolve this issue once they are fixed. If you would like to be notified once the issue is resolved, you can open up a ticket with PayPal Merchant Technical Support.
user1214454: I have the same problem which I have described here:
https://stackoverflow.com/questions/16174275/why-paypal-does-not-call-my-notify-url-but-on-sandbox-everything-works
I have contacted with PayPal but they said that paypal are sending the IPN messages to my IPN, but they are not being accepted by my IPN, what I think is not true, because when request hit my server e-mail is generated by my script and I know if something hit my server. Besides, as I said in my post in sandbox everything works as expected. I am really frustrated too because my bussiness depends on this.
I'm using the codeigniter library from angelleye's library (http://www.angelleye.com/download-codeigniter-php-library-for-paypal-payments-pro/).
For a few days, it worked smoothly without any errors. Today when I tested it I got no response from paypal.
I contacted the author(Andrew), and he said that the paypal sandbox server is timing out with the do direct payment.
My question is, how do I fix this?
The PayPal sandbox does that at times, and unfortunately there's nothing we can do about it but wait on PayPal to get things working smoothly.
The sandbox has been running great for awhile now, but it seems that with many of the recent changes they're making (they're working on a new sandbox, and they're pushing PayFlow more than DirectPayment now) the DirectPayment API on the sandbox has been suffering.
In fact, just now I was about to respond and let you know that last time I tried it was working fine. I went to test it and sure enough, it timed out again. I tried again, though, and it worked fine. So unfortunately, the sandbox is just pretty hit and miss these days with DirectPayment.
You could always switch to PayFlow, which is what they're pushing these days, and my library supports it now if you have the latest version.