I've been using PayPal Website Payments Standard for many years - I use both IPN and PDT. Recently I discovered that although IPN is still working fine, the customer is no longer returned to my website at the end of a purchase, so the PDT is not called, and the customer never makes it back to my website (this is new - it has been working fine for years).
I do have Auto Return turned on in my PayPal settings. The page it's supposed to go to exists and is working fine. That landing page is never hit in the logs.
This is broken on the live PayPal site and in the PayPal Sandbox. The page that I land on says "Your payment was completed. To continue shopping, please return to the merchant." There is no "Return to Merchant" button. The URL for this page is https://www.sandbox.paypal.com/webapps/hermes?flow=1-P&ulReturn=true&token=2GX255130M045604B&mfid=1540506852194_f375a853a7234&useraction=commit&country.x=US&locale.x=en_US&country.x=US&locale.x=en_US#/checkout/genericError?code=PAYMENT_ALREADY_DONE. This page used to automatically redirect back to my website.
On a related note (not sure if it's the same problem) the "Continue Shopping" button on the PayPal Cart page doesn't work anymore either. I am sending the URL for the page in a hidden field of the form I send to PayPal for my Add to Cart button as shopping_url, but when I click "Continue Shopping" it appears to be taking me Back (like a browser back) to the page that submitted the form rather than going to the page I specified in shopping_url. Again, this has worked for years, but now is no longer working.
Any help will be much appreciated!
[not an answer, but I can't post comments]
This broke a few months ago for us (Paypal button "return" parameter doesn't seem to work). In the new checkout flow, Paypal ignores the "return" value passed in the button/form, it redirects the customer to the URL configured in website settings (https://www.paypal.com/businessmanage/preferences/website).
I'm not sure if Paypal developers read this forum for bug reports or not, but this definitely looks like a regression.
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
I am using ExpressCheckout in several shops. Since a couple of weeks there is a problem with the landingpage. Instead of a landingpage with guest payment options or even price-information a stupid login page is shown.
Please take look at the image I made.
It worked before and with my sandbox I still get the old Landingpage. Because there are no price-information many customers cancel the checkout process now.
You can't avoid the new version of the landing page, but if you have all of the parameters set in the request the way you say then you should see a button that says "Pay with Debit or Credit Card" instead of "Create an Account".
Here's a screenshot of what I get. You'll notice the pricing has been moved into a drop-down.
I have integrated Express Checkout with my application it works fine but sometimes paypal payment pages behaves very oddly. When user is directed to payment page, the page it shows is not same all the time. sometimes it shows saying "Login or Checkout as a Guest" and sometimes user see a page saying "Login as paypal or Create an account"
I have attached the image url Please see the following links.
First Layout
http://oi60.tinypic.com/149rpcn.jpg
http://oi60.tinypic.com/2r43ms2.jpg
Second Layout
http://oi58.tinypic.com/vxcl04.jpg
http://oi62.tinypic.com/v3j3hc.jpg
First layout makes sense. but second layout creating confusion when it says "create an account"? is that means creating paypal account or what? when i click on the option it simply shows me credit card details to enter. i dont know if that is related to the payment or asking to create new paypal account?
PayPal has been split testing the old EC pages with the new ones that you're seeing sometimes. In order to work with both sets of pages nicely, you'll need to make sure to add an additional parameter into your SetExpressCheckout request.
It looks like you're already using the following (and if you're not, you need to add them)
SOLUTIONTYPE=Sole
LANDINGPAGE=Billing
You need to also include the following to work well with the new pages.
USERSELECTEDFUNDINGSOURCE=CreditCard
We're developing an application that uses Paypal Express Checkout, and we're finding that we get two different landing pages. We're actually finding a problem that seems superficially similar to Can you force PayPal Payments Standard API to show credit card fields first?, but with a few differences:
Everything is fine with the sandbox, and we get exactly the appearance (credit card first) we want.
On the live site, about 50% of the time we get exactly the appearance (credit card first) we want.
Sometimes, we get a more "mobile-like" landing page, with the credit card stuff totally hidden in a "Check out as a guest" button, as shown.
This feels like a failing A/B test to me. We're sending exactly the variables in the question linked above, and as I said, all works fine with the older landing pages. I know there are also cookie issues, but in this case, we're seeing it even when Paypal is not able to identify an account and when cookies are cleared.
Does anybody know if there is anything we can do to work around this?
I can add code if needed, but the problem appears to be more data than logic.
I had the same question after I started to see users coming in from the 'new style' page.
I found the answer here:
Paypal express "order summary" page
I added the "force_sa=true" parameter to my Paypal URL:
https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&force_sa=true&token=…
The new page is definitely weighted to appear more often on mobile devices. Without the parameter I get the new style page on a iPad after about 5 refreshes, with the parameter I can refresh as much as I like and never see the new page.
Obviously, PayPal will roll out the new page to everyone in the end, but this technique allows us a stop gap while we get ready for it ;-)
The screen pictured is PayPal's new checkout. It is only partially deployed at this point, you can think of it as A/B testing.
Regarding whether the customer sees "credit cards first", this mostly depends on whether they have a PayPal email stored in their browser cookie. If they do, the top "Log in to PayPal" section will be expanded, the email filled out, and they just need to type in their password and do about 3 clicks to complete the checkout..
If they do not have a PayPal email stored in their cookies, the bottom Create an Account or Pay as Guest section will be expanded. (If you want guest checkout, pass SOLUTIONTYPE=Sole in your initial SetExpressCheckout request).
The customer can always switch between the two expanded sections, it's just a "smart default" of sorts.
Try doing all your "credit cards first" testing in an incognito / private browsing window.
I have PayPal PDT (Payment Data Transfer) enabled on my PayPal account, and I have auto-return turned on, pointing to a "Complete_Paypal_Order" page on my site.
When a customer makes a purchase, and they pay using PayPal's site, they are sent to a page which will redirect them back to my site within 10 seconds. If the customer waits for the redirect, the GET request to my site contains the transaction id, just as it is supposed to.
If, however, the customer clicks the link on PayPal's redirect page that says "If you are not redirected within 10 seconds, click here," the transaction id is not passed to my site. Instead, the get request looks like: "http://.../Complete_Paypal_Order?merchant_return_link=click+here&form_charset=UTF-8", no matter what the customer ordered. This happens in both sandbox and live PayPal sites.
Has anyone run across this before, and if so, do you know of a solution?
Also, just to be clear, I am aware of some of the drawbacks of PDT, but suffice to say that, for various reasons, changing to IPN or API calls is not an option for the site at this time. So, please don't suggest "just use IPN" or "just use ExpressCheckout API calls."
Related questions (as yet unanswered):
Paypal PDT - unable to get transaction ID.
Paypal PDT AutoReturn