Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.


  • Content count

  • Joined

  • Last visited

1 Follower

Profile Information

  • Real Name
  • Gender
  1. ''B''

    Product listing

    Hello... back after I installed KissIt in July 2014, I could have sworn that somewhere there was a button that I could click that would delete all thumbnails. If it did exist, I liked it because with our one-off product site we end up with thousands of thumbnail images persisting on the server for products that were sold long ago. I know I can go into the database and manually delete those thumbnails (which is what I've been doing for a while now), but I want someone else to be able to easily delete them and I don't trust anyone but myself in the database. Does this button to delete those thumbnails actually exist, or am I completely mis-remembering and there is no such thing? Could have sworn it was over at the website's OSCommerce Admin.
  2. ''B''

    Paypal Order Emails Not Being Sent

    These two threads might help you: http://forums.oscommerce.com/topic/397731-paypal-standard-could-not-verify-the-paypal-transaction-please-try-again/ http://forums.oscommerce.com/topic/397899-mobile-devices-paypal-standard-buyer-being-returned-to-shopping-cart-after-purchase/
  3. Look further up in one of my other replies to this thread and you will see I wrote: "I installed this add-on for osCommerce version"
  4. Craig, go to this thread: http://forums.oscommerce.com/topic/397899-mobile-devices-paypal-standard-buyer-being-returned-to-shopping-cart-after-purchase/#entry1704402 Bob Terveuren came up with a fix and it works great!! No more problems!!
  5. Here's what I did in the admin/categories.php file: Right after the following td... <td class="main"><?php echo TEXT_PRODUCTS_MANUFACTURER; ?></td> I placed a series of if statements that identifies the category selected in the admin panel. In order for this to work, you need to find out the category id of each product category. So do this: Right after the <td class="main"><?php echo TEXT_PRODUCTS_MANUFACTURER; ?></td>, input the following script: <?php echo "<script type='text/javascript'>alert('$current_category_id');</script>"; ?> Then go into your admin panel and choose each category one by one. An alert will pop up giving the category id. Write down the category name and the id that pops up in the alert. Once you have all the id's, replace the echo alert above with the following script: if($current_category_id==categoryNumber) $defaultFolder = 'folderName1'; } elseif($current_category_id==categoryNumber) { $defaultFolder = 'folderName2'; } elseif($current_category_id==categoryNumber) { $defaultFolder = 'folderName3'; } else { //default folder will be chosen } Make sure that you input the actual id number in place of the items above that say categoryNumber and the actual folder name where it says folderName.
  6. I have been meaning for a while now to come back to reply to this thread. Bob Terveuren, thank you so much for stepping up and offering a fix. Using your code, PayPal Standard now works fine with mobile devices and continues to work fine with desktop computers. For those of you having issues with stock decrements and order emails, Harald's code (which is supposed to trigger the stock decrement and order emails in the case where the buyer doesn't return to the store) doesn't work. The buyer MUST return to the merchant shop in order for the transaction to go to full completion. So if they don't, that's what causes the issue with stock not being adjusted and buyer's not receiving a store confirmation email. The only thing I could do was to force the buyer to return back to the shop through my friend's PayPal account settings. To do this, I enabled the Return URL feature in my friend's PayPal Website Payment Preferences with a return URL that sends the buyer back to the webAddress/checkout_process.php page. This works great as long as the buyer is paying direct through PayPal and not a credit card via PayPal. The buyer is forced back to the site and the order goes to full completion. However, if the buyer pays via PayPal using a credit card, then I believe at the end of the transaction they have to click a return button to go back to the merchant site. If they don't click that button, then the order does not complete fully because the buyer did not return back to the site. So I turned off the "PayPal Account Optional" feature in my friend's account. If you do this, that means that the buyer can't use a credit card through PayPal (bummer). But at least turning on the return URL feature, turning off the PayPal Account optional feature, and Bob's code has fixed it so that PayPal Standard works as it should. Thanks again Bob!! I appreciate that you took the time to help!!
  7. Hi Gergely... one of the browsers was Chrome v28 on an Adroid device. So it's not isolated to Safari browsers.
  8. Harald, not sure why I didn't hear back form you in regards to this thread. But after monitoring the raw access logs and speaking with a tech person over at PayPal, I think I possibly know what the issue is. Take a look at what is seen in the raw access logs for the response being returned back to the checkout_process.php page On a mobile device - - [22/Aug/2014:23:25:10 -0400] "GET /checkout_process.php HTTP/1.1" 302 - "https://mobile.paypal.com/us/cgi-bin/wapapp?cmd=_flow&CONTEXT=X3%2d7SZn2ExXucINxlliZ%5f05NdFsrIIpaV9TcRYNLL%5fGiOwm9XgEZzWKQeV0&SESSION=DnXm4ii8E3PzB9v4_YbCvebUD9TImECYZix78VW4s25x5AWm8gt1RYtkY7G&login_paypal=&jsEnabled=" "Mozilla/5.0 (Linux; U; Android 4.0.4; en-us; SGH-I927 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30" - - [24/Aug/2014:18:37:22 -0400] "GET /checkout_process.php HTTP/1.1" 302 - "https://mobile.paypal.com/uk/cgi-bin/webscr?cmd=_express-checkout-mobile&useraction=commit&token=EC-5DE47862P19792205" "Mozilla/5.0 (iPhone; CPU iPhone OS 7_1_2 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D257 Safari/9537.53" On a desktop - - [15/Aug/2014:16:53:35 -0400] "POST /checkout_process.php HTTP/1.1" 302 - "https://www.paypal.com/uk/cgi-bin/webscr?cmd=_flow&SESSION=jJuxGba1oHpENSyORRigfhMXwa8t0eDR7_3Ok5ZNh0YGEUiQOMwfC592hDi&dispatch=50a222a57771920b6a3d7b606239e4d529b525e0b7e69bf0224adecfb0124e9b61f737ba21b08198a0586321b47f5ae7b54ee269d9200b8b" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0" - - [17/Aug/2014:10:38:32 -0400] "POST /checkout_process.php HTTP/1.1" 302 - "https://www.paypal.com/fi/cgi-bin/webscr?cmd=_flow&SESSION=KUx-Sg4NozAndmMynjkPaZiDeQEHC7reOi0WxIDWJI4gZjst3PS57T7eoAC&dispatch=50a222a57771920b6a3d7b606239e4d529b525e0b7e69bf0224adecfb0124e9b61f737ba21b08198a0586321b47f5ae7b54ee269d9200b8b" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/6.1.3 Safari/537.75.14" Paypal is using the GET method for the response when the purchase is made from a mobile device. But they are using the POST method from the response when the purchase is made from a desktop/laptop. Based on what I've seen in the code in the paypal_standard.php and standard_ipn.php pages, it appears that it's set up only to process responses sent via POST. Specifically the code below in the paypal_standard.php page is what I believe is sending buyers back to the shopping cart, since there's no way a verified response can be handled when sent via GET since the code is looking for a POST response: if ( isset($HTTP_POST_VARS['receiver_email']) && (($HTTP_POST_VARS['receiver_email'] == MODULE_PAYMENT_PAYPAL_STANDARD_ID) || (defined('MODULE_PAYMENT_PAYPAL_STANDARD_PRIMARY_ID') && tep_not_null(MODULE_PAYMENT_PAYPAL_STANDARD_PRIMARY_ID) && ($HTTP_POST_VARS['receiver_email'] == MODULE_PAYMENT_PAYPAL_STANDARD_PRIMARY_ID))) ) { $parameters = 'cmd=_notify-validate'; foreach ($HTTP_POST_VARS as $key => $value) { $parameters .= '&' . $key . '=' . urlencode(stripslashes($value)); } $result = $this->sendTransactionToGateway($this->form_action_url, $parameters); } if ($result != 'VERIFIED') { if (defined('MODULE_PAYMENT_PAYPAL_STANDARD_TEXT_INVALID_TRANSACTION')) { $messageStack->add_session('header', MODULE_PAYMENT_PAYPAL_STANDARD_TEXT_INVALID_TRANSACTION); } $this->sendDebugEmail($result); tep_redirect(tep_href_link(FILENAME_SHOPPING_CART)); } Please let me know your thoughts and what can be done so that purchases made via mobile devices go to full completion.
  9. Paypal Standard 3.2 osCommerce I have found an issue that appears to be isolated to purchases made with mobile devices. To start, whenever a customer makes a purchase with a laptop/desktop computer, the transaction completes just fine with the buyer being returned to the success page after clicking the pay button over at PayPal. The PayPal purchases made via a laptop/desktop computer process all the way through to completion 100% of the time. However, whenever a purchase is made with a mobile device, the buyer is returned to the shopping cart after clicking the pay button over at PayPal. The item is still in the shopping cart, inventory is not reduced, the buyer does not receive a store receipt, and in the admin order details there is only the PayPal IPN verified line and not the other PayPal verified line. So far this has happened on an iPhone, an iPad, and two Android phones (one of which was my Android phone that I used to double check how the transaction progresses). On my Android phone, when I was returned back to the shopping cart, at the top of the page there was a message that said “Could not verify the PayPal transaction. Please try again.” FYI, the money was taken from my PayPal account. So the order did go through… it’s just that it didn’t process all the way at the merchant website. In looking at the mobile device transactions in the raw access logs, here is how these “semi-failed” transactions progress: checkout_shipping.php checkout_payment.php checkout_confirmation.php (go to Paypal, login to Paypal, click the Pay button) checkout_process.php shopping_cart.php standard_ipn.php This is very confusing to the customer as they think their purchase has not gone through. In addition, they don’t get a store acknowledgement receipt and inventory is not reduced. In the case where an item is a one off, this could create problems if someone else comes along and purchases the same item when it has already been sold. Any thoughts on this? Hopefully there is a fix for it. Thanks… Brenda
  10. Hi Harald... just wondering if you saw my recent post above. Has anyone else had the issue with being returned back to their shopping cart rather than the success page?
  11. Hi Harald... things have been going well with the Paypal payments since my last reply. Then yesterday, after a customer made a Paypal payment and was redirected back to the merchant website, instead of being returned to the checkout_success.php page, he was returned to his shopping cart and the item he purchased was still in his shopping cart. The item was not removed from the website and neither he nor my friend who owns the shop received a store receipt email. My friend verified that the money was indeed received in her PayPal account. After I looked through the raw access logs: I was able to verify that the files in bold ran successful, but the checkout_success.php page did not run, hence the failure of the order to go to full completion. checkout_shipping.php checkout_payment.php checkout_confirmation.php checkout_process.php checkout_success.php standard_ipn.php The only thing that was different about this particular order is that the customer completed the order on a Smart Phone browser. Could that be why he ended back up in the shopping cart rather than the success page? The other orders I've been monitoring have been purchased using regular desktop/laptop computer browsers. In the admin order details, only the Paypal IPN Verified line showed up. The Paypal Verified and the Processing line did not show up for his order. I'm just trying to figure out why this happened and if it can be fixed. Any thoughts?
  12. Harald, my friend called Paypal and the guy she spoke to said that, in cases where multiple IPN's fail, they disable the IPN feature that the account holder activated themselves. That's the one you told me not to enable or input the standard_ipn.php URL. So basically, the two emails Deb received from them about disabling the IPN feature only had to do with something I (or she) never enabled anyways. Somewhere there is a breakdown. And I'm not at all suggesting it's your code. Just something somewhere between my friend's website and Paypal is not jiving. At this point, I don't know if there's anything else that can be done. I went ahead and have now enabled the return URL feature as well as the IPN feature in my friend's Paypal account. It tests just fine and I am getting both the Paypal Verified and PayPal IPN Verified lines in the admin order history. I turned off something in her account (I don't remember what it was now), that makes it so that the buyer is returned back to the merchant site without having to click a button to go back. So this almost eliminates the issues caused by the buyer closing the browser. There is a brief 5-10 period where PayPal displays a thank you page during which time the buyer is being redirected to the website's success page, but I'm hopeful that because that page displays so briefly, that no one will close the browser. If they do, then the issue with only one Paypal line showing up in the order history will occur (and the problems that come with it... no store email, item not removed from shopping cart, item not removed from site, etcetera). But I think that will be a minimal issue if any at all since again, the Paypal redirect page is so brief. This is the best its worked during this entire testing period so I think I'll have to run with it. Thank you for all your help. I apologize if your time was wasted. But maybe some of the things we discussed in this thread will be helpful to other people, and that's a good thing, right? Thank you for your attention and swift replies. I really appreciate it!! Brenda
  13. Okay, I tried it out and at the top of the simulator page it said, "IPN sent successfully". Below are the Paypal entries from the cPanel access logs. I honestly don’t understand what the heck could possibly be wrong. As you can see, the standard_ipn.php gets and posts just fine in the sandbox. How is it possible that it won’t work on a live site? ***bangs head in frustration*** xx.xxx.xx.xxx - - [08/Aug/2014:16:33:27 -0400] "GET /ext/modules/payment/paypal/standard_ipn.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko" xx.xxx.xx.xxx - - [08/Aug/2014:16:34:06 -0400] "GET /ext/modules/payment/paypal/standard_ipn.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36" - - [08/Aug/2014:16:34:23 -0400] "POST /ext/modules/payment/paypal/standard_ipn.php HTTP/1.1" 200 - "-" "PayPal Sandbox" I'm not sure if you wanted to see my debug email, but here it is: $HTTP_POST_VARS: Array ( [residence_country] => US [invoice] => abc1234 [address_city] => San Jose [first_name] => John [payer_id] => TESTBUYERID01 [mc_fee] => 0.44 [txn_id] => 955906928 [receiver_email] => seller@paypalsandbox.com [custom] => xyz123 [payment_date] => 13:32:58 8 Aug 2014 PDT [address_country_code] => US [address_zip] => 95131 [item_name1] => something [mc_handling] => 2.06 [mc_handling1] => 1.67 [tax] => 2.02 [address_name] => John Smith [last_name] => Smith [receiver_id] => seller@paypalsandbox.com [verify_sign] => AFcWxV21C7fd0v3bYYYRCpSSRl31AobzmILiSL3iI17fizkVHoJ9qlAo [address_country] => United States [payment_status] => Completed [address_status] => confirmed [business] => seller@paypalsandbox.com [payer_email] => buyer@paypalsandbox.com [notify_version] => 2.4 [txn_type] => cart [test_ipn] => 1 [payer_status] => verified [mc_currency] => USD [mc_gross] => 15.34 [mc_shipping] => 3.02 [mc_shipping1] => 1.02 [item_number1] => AK-1234 [address_state] => CA [mc_gross1] => 12.34 [payment_type] => instant [address_street] => 123, any street )
  14. Okay. Thanks Harald. I'll try it. I contacted my friend and she said she has received no further emails from Paypal. The Paypal help files say that if IPN is to be disabled, they will send an email regarding deactivation. She's received no such email - only the two that said Paypal may disable the IPN feature.
  15. In all the test orders I've placed, IPN Verified has never shown up in the order history in the admin panel. There are no entries in either the SSL or non-SSL access logs regarding PayPal IPN. I can't imagine what this could be. If you have no other suggestions, then maybe I should go over to my friend's Paypal account and enter both a return URL and the IPN notification URL, then do a test order? I just don't know what else to do at this point. She does not have any other websites, but I think she does sell on Ebay. So will those settings affect Ebay - meaning, when someone makes an Ebay purchase, will they be returned to the success page at her website?