1 / 23
Jul 2009

Someone has just drawn my attention to the fact that when an item is placed in our shopping cart and one then clicks on Continue Shopping, that instead of going back to the page the item is added a second time to the shopping cart and one is still in the shopping cart.



I've verified that this happens in Firefox but apparently not in IE.



I discovered that the e-junkie code on our site is different to your current code but when I changed one of the buttons over to the current code, I got the same problem.



The page with the majority of our site's e-junkie buttons is the following: 11http://www.christopherushomeschool.org/bookstore-for-waldorf-homeschooling/audio-downloads.html11



Any help much appreciated!



-- Paul

P.S. I did have a look at past forum posts that seemed related to this and saw that there were similar issues reported but not quite the same. I wasn't able to work out what I should do!



-- Paul

You appear to be using the "PayPal Cart" version of button codes we make available for merchants who may have a very specific need to use PayPal's shopping cart system instead of using the standard E-junkie cart. Note this is unrelated to accepting PayPal checkout payments; you do not need to use our "PayPal Cart" button codes merely to accept payments via PayPal.



The problem you described recently cropped up due to a change in the way PayPal's cart system works, and we have yet to identify the cause or devise a solution, if one is even possible. We recommend using the standard E-junkie cart button codes, which will show buyers a PayPal checkout option in the E-junkie cart and provide full support for our other cart-based features.

Many thanks for your reply, Tyson.



At this stage I'd rather avoid changing over our whole website to the e-junkie cart. In addition to the downloads that we sell through e-junkie we use PayPal for tangible goods (books) and, though I see that the e-junkie cart can handle tangible goods, that's a lot of code to change.



So, what you are saying is that without changing over to the E-junkie cart we will have this problem until such time as you are able to work out a solution, and you're not even sure that is possible. Hm...



Do you have any other suggestions for a work-around with this? At worst, I guess I can put a warning for our customers on our site to let them know there's an issue, but if you have any other thoughts, I'm all ears.



Thanks again,



-- Paul

Hi Tyson,



Here is the coding difference on the "Continue Shopping" button:



When we add a non-e-Junkie item to our shopping cart the code on the button works fine:



<input id="continue_shopping" class="button" type="button" onclick="continueShopping('2http://www.christopherushomeschool.org/bookstore-for-waldorf-homeschooling.html2',noWinAlert,closeWinAlert);" value="Continue shopping" name="continueshopping"/>

<input class="button primary" type="submit" value="Proceed to checkout" name="checkout"/>



But when we add an e-Junkie item, the code below keeps us in the shopping cart and increments the audio download items quantity. If we remove the audio item and click the button it adds it back in to the shopping cart. The only way to get out of the shopping cart is to click the Proceed to Checkout button.



<input id="continue_shopping" class="button" type="button" onclick="continueShopping('https://www.e-junkie.com/ecom/gb.php?i=268461&c=cart&cl=1576&shipping=0&shipping2=0&handling=0',noWinAlert,closeWinAlert);" value="Continue shopping" name="continueshopping"/>

<input class="button primary" type="submit" value="Proceed to checkout" name="checkout"/>



Which system is generating this code - yours or Paypal's? Which part of the URL is causing the problem. I have found that when you give Paypal's merchant services tech support enough very specific details they can usually help pinpoint the problem.



Can you provide us with any server log data for us that would help with the troubleshooting?



Thanks,



~kj

Apparently, PayPal's cart system seems to be taking the last URL visited (referrer URL) before the cart page itself, and then making that the URL of their Continue Shopping button. This is a recent change to the way PayPal's cart behaves, which is causing all the problems reported with the "PayPal Cart" version of E-junkie's button codes lately.



If you're using PayPal's own cart buttons (without involving E-junkie), then all of the product specs are configured in the button code on your own page, so the buyer goes directly from your page into PayPal's cart when they click a purchase button, and thus your page would be the "last URL" that their Continue Shopping button links back to.



If you're using E-junkie's "PayPal Cart" version of button codes, then our button code only contains a reference to the product record stored in our database, so clicking the button invokes a script on our server that looks up the product specs and then translates those into a format that PayPal's cart system can recognize, and then redirects the buyer along with those product specs into PayPal's cart. Since the buyer is not going directly from your page to PayPal's cart -- they are actually going from your page, to our script first, and then into PayPal's cart -- the last-visited URL that PayPal's cart can see is not your page, but our script's URL. Thus, clicking PayPal's Continue Shopping button takes the buyer back to the last URL visited, which in this case is actually our script URL, which simply forwards the buyer and product data back into PayPal's cart.



Again, I will stress here that you do NOT need to use our "PayPal Cart" button codes merely to accept payments via PayPal. The standard E-junkie cart and button codes will show buyers a PayPal checkout option in their E-junkie cart, and this also provides full support for our other cart-based features.

Thanks for this info, I now know what to talk with Paypal about.



Regarding your last comment, I have encountered this with numerous providers of website services, which is a lack of awareness that businesses may have other interfaces tied to the Paypal Database, so that changing where the cart data resides means changing other interfaces as well so that what may seem to be a simple change at your end becomes much too involved at the customers end.



Again thanks for identifying where the problem with the current code lies.



~kj

A further question:



Since Paypal made its changes, did you make ANY changes to our custom coding that you provided to us when we first signed up with you or is your coding identical to when the whole set up worked previously before Paypal made any changes?



Thanks



~kj

I just spoke with Paypal Merchant Services Technical Support and they were familiar with the problem and have created a workaround variable named shopping_url to pass where we want the continue button to return to. I am new to administering this website and Paul has asked me to step in and troubleshoot this issue but I am not up to speed on how the e-junkie coding works. Is there a place for me to edit the coding or do you need to do that to add the variable? I can do some coding but am not sure what is needed for your system interface with paypal.



We would like the continue button to return to

shopping_url="http://www.christopherushomeschool.org/bookstore-for-waldorf-homeschooling.html"



Can you assist with this?

Could someone please answer my posts above? I still need assistance.



Paypal has instructed what to do with the coding to make it work. but I do not know how to implement it. If I add the query string to the add to cart buttons will e-junkie pass the value on to Paypal automatically? Or is some modification needed in e-Junkie? Can just a modification in the e-Junkie code solve the issue or does it require both changing the cart button code and the e-Junkie code?



Please help asap as this problem is probably causing us lost sales as it occurs before payment so customers will tend to just leave and go elsewhere if they encounter it and get frustrated.



Thank you very much.



~kj

The instructions you passed along from PayPal would only be relevant if you are using PayPal's own shopping cart buttons, not if you are using E-junkie buttons. We cannot simply use the "shopping_url" variable because that URL would be different for every merchant using our service, and some merchants may not want the buyer always returning to the same page to continue shopping, etc., so trying to accommodate that workaround for thousands of merchants opens up a huge can of worms.



We have not changed any of the button codes we issue; PayPal just decided to change the way their own cart system works one day without warning or explanation. This is something we have to fix in our backend system, if it even can be fixed, depending on what PayPal has changed about their cart and how, so we're still looking into it. We thought we had a fix today, but testing revealed it didn't always work, so it's back to the drawing board.



If you're only using E-junkie for our automated download fulfillment and have a need to use PayPal's cart system, you might consider just using PayPal's own cart button codes on your site, and then adapt our eBay instructions to have PayPal still inform our system of every completed order payment so we can still fulfill digital sales for you:

http://www.e-junkie.com/ej/help.ebay.htm

Dear Tyson,



Thank you for your informative response. Unfortunately the IPN solution you proposed will not work for us because we already are using the Paypal IPN feature for another purpose and cannot have more than one IPN setting. So we are back to square one.



What is your prognosis on a fix?



Some of this points you made lead me to further questions:



You wrote:

>>We cannot simply use the "shopping_url" variable because that URL would be different for

>>every merchant using our service, and some merchants may not want the buyer always

>>returning to the same page to continue shopping ...



Certainly those of us affected by this problem do not want our customers stuck in an endless add audio download shopping cart loop.



How difficult would it be to add a field in your database for the shopping_url variable? E-Junkie users could enter the URL they wanted and you could pass that along as a value for the shopping_url variable IF that field is populated with a value. As it is now, where are the customers returning to with the change Paypal has made? I am assuming this only affects customers that are using the PayPal cart and not your e-Junkie cart. My understanding is that it only is a problem if the customer's browser provides a value for the server's REFERRER field.



A more cumbersome solution for us but maybe easier at your end would be to change your code to pass along the name/value pair if and only if it exists in the query string in the add to cart button coding. This should not be that difficult for your programmer to modify. Just do a workaround in the website text and notify customers to add the shopping_url query string to their generated button code ONLY if they are having this problem. Just include the instructions in the website text. It may not be a glamorous solution but it would help out those of us who are losing customers who get stuck in the continue shopping loop for their audio downloads. Have your code only pass the shopping_url to paypal if the query string is passed to you through the cart button.



Please let us know what you plan to do and if you have an ETA on a solution.



Thank you very much.



~kj

KJ Jakobson for christopherushomeschool.org

The issue with E-junkie's PayPal cart buttons in Firefox has now been repaired.

NEED HELP AGAIN....



Sorry to reopen this issue but apparently your fix works great in Firefox but now in IE if you add an audio download to the Paypal shopping cart you get stuck in the same continue shopping loop only this time it doesn't increment beyond quantity of 1.



If you empty the cart and hit continue shopping it puts the audio download back in the cart.



If you have the download in the cart and you hit continue shopping then it reloads the cart but does not add an additional quantity as it was previously doing in Firefox. However as in Firefox previously you cannot get off the shopping cart page without hitting proceed to checkout.



Previously the comments had indicated that folks thought the problem was only in Firefox but all along I had the problem occurring the same in Firefox and IE.



Please keep us posted as you address this pesty issue. Thank you. ~kj

Which version of IE are you using? I was able to get some slightly odd behavior in IE8 by altering some standard settings, but nothing as disruptive as you described.



BTW, since we're on the topic of IE versions, Microsoft no longer supports IE6 and is trying to get as many people as possible, as quickly as possible, upgraded to IE8 via Windows Update, and most major sites like YouTube have dropped dedicating any special effort to supporting IE6 as well. As an 8-year-old browser with numerous stability and security holes, and with free and easy upgrades to newer versions available, IE6 should now be considered as dead and obsolete as Netscape 4 (remember that one? :^). I don't reckon we even have a machine with IE6 handy for testing around here anymore...

Thanks for looking into this again.



My issues are not IE6. I have 3 machines which all have IE7 on them. I am getting inconsistent behaviour on all machines where sometimes the continue shopping button works and sometimes it gets stuck in a loop.



It seems to almost always get stuck after removing an item from the cart and then hitting the continue shopping button. But on the same machine I have had it work fine. And then the next time get stuck in the loop right away even before removing an item. Each test I make sure to clear all cookies, history, etc before starting.



Please keep us posted.

13 days later

I have not heard from you since my last post, but I have just tested our downloads and the Paypal shopping cart and everything seems to be working well in both IE and Firefox. Did you in fact make further changes at your end after my last post? It appears that way but I would like confirmation so I know that I can put this issue to rest.



Thank you very much.



~kj