Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

tobybailey

Pioneers
  • Posts

    64
  • Joined

  • Last visited

Profile Information

  • Real Name
    Toby Bailey

Recent Profile Visitors

6,504 profile views

tobybailey's Achievements

  1. Have just upgraded to 2.3.4.1 mainstream (BS edition next step probably). Using the paypal payment modules bundled with that (not the possibly different "paypal App"). Have "pro hosted" running but Express turned off. On the checkout conformation page two Paypal options appear: a "Pay with paypal" button that I think is implementing Express checkout in some sense and another pay with CC box. Everything works except that for some mobile devices, if the pay with Paypal option is taken the order is registered and the payment is taken and the sale reported by IPN, but a GET call to checkout_process.php is made by paypal with no parameters. This leads to the confused shopper being returned to their (still full) Cart. (In the card payment option a POST call is made and from a Windows desktop a GET call is made with appropriate patrameters which works fine.) I have an identical "secret" copy of the shop running on the Paypal sandbox. There I have turned Paypal Express on. (I have in mind a long term solution is to turn Express on if it helps but hide the option on the Basket and Checkout payment pages to avoid confusing our not very techy customers with multiple versions of Paypal checkout.) On the Sandbox version for some reason the Paypal button sometimes demonstrates the same error as above but often fails completely, reporting an "error" from Paypal. However, on the Sandbox, if the pay with Express option is selected on Checkout Payment it seems to work completely fine. So it seems likely the problem is some difference in what happens between the two cases: (a) customer opts for Express on checkout_payment and presses continue and (b) customer opts for Hosted on checkout_payment but then hits the paypal button rather than giving CC details. I'd be grateful for any ideas! Toby
  2. It's a long time after this thread closed, but I just had this problem. A solution is to change a line in the relevant file in /includes/modules/payment (in my case paypal_pro_hs.php but I have seen this before in other paypal modules). A large array called $params is built at some point. Find the line that reads 'subtotal' => $this->format_raw($order->info['total'] - $order->info['shipping_cost'] - $order->info['tax']), and change it to 'subtotal' => $this->format_raw($order->info['total']) - $order->info['shipping_cost'] - $this->format_raw($order->info['tax']), That forces the rounded value of subtotal reported to Paypal to be consistent with the total value and tax. (If your shipping charge might have decimal places that need rounding, make the corresponding change to that is probably necessary.)
  3. Possibly this has been pointed out already. Installing using the Install_Admin.txt instructions for 2.3 and on, categories.php failed. The reason I discovered is that a modification for that file labeled as "around line 771" instructs one to find a piece of code beginning <?php and replace it with code without such an opening php. I am hoping to install this in a an upgrade to oscommerce 2.3.4.1 which I hope should be functional. Am I right to expect this to work OK? (And yes, I am aware of the community edition but for several reasons I want to do this upgrade first.)
  4. Raiwa, Thanks. That looks as though it will work. Jack, Customers see the option to pay with their paypal account when presented with the pay box at the end of the Pro Hosted process. I think your analysis of the pros and cons is a bit oversimplified. Yes, I guess customers who want to by by Paypal may get discouraged if they do not see it at the payment stage having missed the spearate button on the cart. But also they may get discouraged if they are confused when presented with options. Anyway, we'll have a look at it (with some sensible labels as you suggest) and decide. Thanks both.
  5. Many thanks. That's not really the answer I was hoping for. We have a very non-techy customer base and facing them with a choice a high proportion will not understand is probably not a great idea. I'm a bit confused too. I thought the whole point of paypal express was that it pops up a window direct from the shopping basket by which you could pay and circumvent the payment and shipping pages. So why list two options on the payment page - I would have thought that once you were on that page you have chosen not to go down the "express" route?
  6. I have exactly this problem too. Did you manage to solve it? I'd be grateful for any info.
  7. Thanks both. Turns out to have been nss that had been updated. Server restart fixed it. Will consider upgrading. Toby
  8. Have been using a version of this labeled some time ago as official Paypal (not the current version in the add-ons section) on osCommerce 2.3 Suddenly this morning customers clicking to confirm order got a blank page (and a security warning in some browsers - but I think that is a mistake). It turns out that a call to curl_exec in includes/modules/payment/paypal_hss.php causes the failure. This looks like a standard call to establish iframe credentials and something like it appears in other paypal payment modules. Does anyone have any ideas as to why this should suddenly be failing after several years of more or less reliable functioning? Or how to debug this? I'd be amazingly grateful for any suggestions. Toby
  9. IIRC Paypal's documentation says very clearly that the response contains only the word VERIFIED or INVALID. But I'd not be surprised if that was wrong. Most of our customers are not very techy, so I doubt they disable iframes. And sometimes they try again and it works - and I doubt even more that that can be due to their working out how to enable them. Possibly we should look at the solution where the customer gets taken transparently to paypal hosted (but branded by us) pages. But maybe it is just paypal unreliability - they do seem to have s surprising amount of down time. Cheers, Toby
  10. Angus, thanks. In fact I tracked this down myself this morning just before seeing your post and arrived at a similar solution. I was logging the paypal response to the verification and it sends something around the important bit I record as -------------- Content-Type: text/html; charset=UTF-8 -blank line- 8 VERIFIED 0 ------------ I wonder what the "8" and the "0" are about? On a separate note, we are using the "official" website payments pro i-framed payment solution. It works but we do get a lot of problems with customers not managing to check out due often it would seem to the iframe not appearing. I can't quite decide whether this is caused by Paypal down times, crankyness of the i-frame solution or something subtle we are doing wrong. I'd be interested to know if you are using something similar and what its reliability is like. Toby
  11. About 36 hours ago something changed and orders started being successfully paid for via Papal (Website Payments Pro Hosted Official on oSC 2.3) but IPN notifications stopped being processed and so the orders were never being updated to paid in the database. Weblogs our end show the IPNs arriving and on Paypal we see them appear in our IPN History as acknowledged. Some part of the verification procedure whereby we have to send back a copy of the IPN and Paypal returns "Verified" or "Invalid" is presumably failing. We get an email generated by our IPN handler saying the IPN was invalid, but a look at the code suggests that would also happen if for some reason we were not getting a response from the Paypal verification server. A week or two ago we had a period of a few hours where the same thing happened but it magically fixed itself and started working again. Does anybody have any ideas/experience on this? If so, I'd be very grateful for suggestions. Toby
  12. We now have this running (with problems) under 2.3.3 Is anybody else using it? It would be good to share experience and exchange ideas/fixes. Toby
  13. I just had problems clearing the cache for this add-on under 2.3.3. The culprit seems to be the odd coding (probably there's a reason) of tep_reset_cache_data_usu5 which uses lots of ../ and so on to locate the catalog/includes/modules directory. This breaks if the admin is located outside of and at the same level as the catalog. Replacing the second line of the function with the more usual $usu5_path = DIR_FS_DOCUMENT_ROOT . DIR_WS_MODULES . 'ultimate_seo_urls5/'; seems to cure the problem.
  14. Superfish categories works fine with my lightly modified 2.3.3. But upgrading jquery has killed my jquery-created buttons (like Cart Contents at the top-right). I see passing references to the problem but no soolution. I think all my jquery refs are now to 1.10 versions and that seems to be the only thing wrong. I'd be grateful for a hint. Toby
  15. I have just installed this in 2.3.3 with the only other add-ons being a paypal payment module, KISSer and KISSit. It seems to be working fine but is throwing one error as below. None of our products have a model which is not the trivial string. But models are working - I tried adding one and they show beneath the product on the product page. There is some discussion about this earlier concerning corrupt databases: I don't think that is our problem since the SQL query that FWR Media gave previously works fine and returns products_model as the empty string (or something that lokos like that). Has anybody actually fixed this? Toby Error: Undefined index: products_model File: includes/modules/ultimate_seo_urls5/page_modules/product_info.php Line: 189
×
×
  • Create New...