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
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?
I just received an email from Paypal as follows:
Per our conversation use the "shopping_url" variable to hard-code the continue shopping page.
e.g.
<input type="hidden" name="shopping_url" value="http://www.yoursite.com/shoppingpage.html">
or
...&shopping_url=http://www.yoursite.com/shoppingpage.html&...
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
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.
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
Searched for this problem and this is the most current thread I could find that addresses my issue. Sorry to open such an old thread and it makes me think I've missed something very obvious since there have been no issues (at least discussed on forum) since then.
:/
I am having this same problem (continue shopping goes back to cart and the other issues with updating amounts, etc) - does it on IE and Firefox and Seamonkey. This is the code I am using:
https://www.e-junkie.com/ecom/gb.php?c=cart&i=974357&cl=179005
I have no clue whether this is e-junkie button code or paypal button code.
Can someone help or point me to the right thread? TIA
That URL would be the deprecated "PayPal Cart" version of our button code. Those buttons no longer work properly in many regards (including the Continue Shopping button's behavior) due to recent changes at PayPal's end that we have been unable to work around, so we are removing that version of button codes from the next version of Seller Admin.
We recommend using the standard E-junkie Shopping Cart button codes from your Seller Admin, which provides full support for all our features and will show buyers a PayPal checkout button in the E-junkie cart. You may be able to convert E-junkie's old PayPal Cart button codes into E-junkie Cart buttons by adding &ejc=2 to your buttons' href= URLs, like so:
https://www.e-junkie.com/ecom/gb.php?c=cart&i=974357&cl=179005&ejc=2
However, that would not give you our nice, overlay-style cart display "inside" your page, which you would get by using the complete E-junkie Add to Cart and View Cart button code from Seller Admin (you'd only need one View Cart per page):
1http://www.e-junkie.com/ej/help.buttons.cart.htm1
Suggested Topics
Topic | Category | Replies | Views | Activity |
---|---|---|---|---|
PayPal is not working properly | E-junkie Discussions | 2 | 407 | Apr '24 |
Alt Texts in Buttons? | E-junkie Discussions | 2 | 276 | Jul '24 |
Reddit Link Click Tracking | E-junkie Discussions | 2 | 261 | Aug '24 |
Issue with CC processing | E-junkie Discussions | 3 | 228 | Aug '24 |
Credit card payments not accepted | E-junkie Discussions | 2 | 213 | Sep '24 |