Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

1 Follower

About AngusD

Profile Information

  1. Hi, the solution would be: Yes, you only need the columns, but that's how foreach works. AD
  2. Hi, you probably have to alter the payment-modules. Not sure if you can do this outside with a header_tag-module. There's a function in the shoppingCart-class: function get_content_type() You let the payment-modules check, if there's a download in the cart and if yes, the payment-module get's disabled. global $cart; if($cart->get_content_type() != 'physical'){ $this->enabled = false; } // disable payment-module if there's a download in the order (function update_status()) Not sure if this would work, didn't test it. You'd have to add it to every payment-module you use, except the PayPal-module. AD
  3. Hi, did you install the "Payments Standard"-Module? "PayPal Admin Box" --> Configure; there should be three Buttons: "Payments Standard", "General", "+" (If you didn't install more modules) If the "Payments Standard" is missing, click the "+" and select the module. If the "Payments Standard" is present, check if you have set the mode to "Sandbox". Those are the only reasons I can think of, why the payment option isn't available on the payments page. AD
  4. @@thelrm: Hi, your "$HTTP_POST_VARS" is missing the "receiver_email" var. That's probably why the confirmation fails. Install the PayPal App and test the payment. If it works with that module, then you can still check what's wrong with the express module, but in the meantime, you still have a working payment module. AD
  5. @@gjpinzino I second @@Dan Cole 's advice. Install the responsive version of osC, if you're allowed to: This version has the PayPal App already installed, I believe, but the module needs an update because of a bug. The payment module updates itself automatically, you just need to click a button in the admin. AD
  6. This is all you received in the e-mail? You didn't remove a parameter? The list is missing the "receiver_email". That's probably why the confirmation fails. The "receiver_email" is the "Seller E-Mail Address" in the payment-module configuration. Stupid question(s) to make things clear: You downloaded the osCommerce 2.3.4 from this site? You use the PayPal Payments Standard payment-module of this version? You're not using the "PayPal App"? AD
  7. Hi, the payment-module expects an certain response from the PayPal-Server. The confirmation fails, if it doesn't get this response. We had this with the Sandbox, too. After we switched to live mode, the error went away. Maybe it's not your configuration, but the PayPal-Sandbox. AD
  8. @@trier Maybe they confused the return_URL with the after_process() redirect URL? You're right. I downloaded the responsive master and the paypal_standard.php has the wrong redirect URL. Edit: Is that even an issue? When you install the PayPal-Module, you're being notified of an update and the paypal_standard.php will be replaced by the correct file. I've made some changes in my paypal_standard.php (5.0.18) and then "updated" again. All changes I made were gone after the update. Are you sure you're looking at the right file? Not a cached version or an old version on your system? AD
  9. Hi, this is flagged as a bug in Chrome. Which Version do you use? Maybe an update of your browser fixes this. Workaround: Start your Chrome with the " -disable-xss-auditor"-Paramter: There are other workarounds, but they affect the security of your site. So they shouldn't really be used. Try updating your browser first, before you disable the XXS Auditor in your browser. Or switch to a different browser. AD
  10. Hi, the tep_redirect in the after_process-function is wrong. I just checked the line in my paypal_standard.php payment-module: tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, '', 'SSL')); It's, as far as I know, the most recent version: 5.018 AD
  11. Update: The vanishing order error has been resolved, too. In our case, it was caused by the "Order Status" setting in the "PayPal Payments Standard" config. The option "Store Default Order Status" caused the order to be deleted after checkout. There's no reason why it does this. There are no "delete"-queries anywhere near the checkout_process/checkout_success-scripts. We set the "Order Status" to "Delivered". This seemed to fix the issue. AD
  12. Hi, we had this, too. It seems, in our case, the culprit was the "Order Status" option in the "PayPal Payments Standard" Settings. It was set to "-- Store Default Order Status --". This setting caused the orders to be deleted after a successful checkout. We set it to "Delivered" (we're selling Downloads and our customers expect to download the items directly after payment). The order stays in the database after checkout and is set accordingly. Still, this setting shouldn't delete the order from the database and it shouldn't have a different behaviour in live- and sandbox-mode. The sandbox worked like it should with "-- Store Default Order Status --", the live-mode failed. It confuses the heck out of me. AD
  13. Hi, both. I tested it live and the order vanished. I had several windows, browsers and stuff running and maybe I got confused there. Then I closed the unnecessary windows and browsers and did a sandbox-test. Everything worked the way it should. So I'm not sure if everything is really ok or not. I'm monitoring the checkout and hope for the best... AD
  14. Addendum 2: Issue resolved; Removed some code that somehow caused now trouble. New issue: Order vanishes after checkout from the database. Head -> Desk Edit: New issue was probably between chair and keyboard. Keeping an eye on it.
  15. Addendum: Installed the most recent version: PayPal App v5.018 No changes. AD