Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Paul_w

Pioneers
  • Posts

    119
  • Joined

  • Last visited

Everything posted by Paul_w

  1. OK, a suggestion here, make sure you do not have .htaccess password protection running when testing the functionality of SagePay server as this will cause the problem described above. All is fine now that I have removed .htacess password protection from my site :)
  2. Just to provide a little more information to my earlier post, the problem occurs after having entered the card details, then filling out the 3D secure screen, it is after submitting the 3D data that the problem happens. The page that I am left stuck on with the error message shown above is https://www.xxxxxxxxxxxx.co.uk/ext/modules/payment/sage_pay/checkout.php?osCsid=b002d7a9b80ded64c4785c0c61922029
  3. Has anyone managed to find a solution to this problem? I have osC 2.3.3.4 which runs the older version of the SagePay server add-on (v1.2 )just fine, I have today tried to upgrade to the current version of this add-on (v2.1) mainly due to the fact that this uses the later Protocol v3.00 of the SagePay API, SagePay has announced that they will be dropping support for older Protocol versions later this year, so this means that anyone using SagePay needs to upgrade to the later add-on. However I have the same problem as mentioned by earlier posters 'Error Code 5006' - Unable to redirect to Vendors website. The vendor failed to provide a redirection URL' I don't know if it makes any difference but I am using the 'low' method, i.e. I have my payment pages in an iframe. Any help would be a gratefully received! Thanks - Paul
  4. I have just added this to my v2.3.3.4 store - A great add-on indeed! However I am having a minor problem with url encoding in emails sent from the edit_orders_ajax.php file. The order update email that is sent out includes a link back to the order as below: Detailed Invoice: https://www.mydomain.co.uk/account_history_info.phpEURorder_id=16743 As you can see the parameters are preceded by 'EUR' instead of '?' which obviously results in a broken link. I think this probably has something to do with UTF8 encoding, but this is something I really know nothing about, can anybody make any suggestions as to how I could go about trying to fix this? Thanks - Paul
  5. I have just installed the latest version of this on a copy of v2.3.3.4 and there seems to be a few minor problems 'straight out of the box' I have followed all install instructions, but when running for the first time googlefeeder.php throws 3 error messages regarding call to undefined function tep_db_fetch_object, so I have changed these 3 references in googlefeeder.php to mysqli_fetch_object and the script runs without error. The installation instructions state: a) FIND: function mysqli_fetch_field($query) { return mysql_fetch_field($query); } ADD BELOW: //BOF additional features function mysqli_fetch_object($result,$class_name='stdClass') { return mysql_fetch_object($result,$class_name); } //EOF additional features B) FIND: function mysqli_fetch_field($query) { return mysql_fetch_field($query); } ADD BELOW: //BOF additional features function mysqli_fetch_object($result,$class_name='stdClass') { return mysql_fetch_object($result,$class_name); } //EOF additional features Surely there should be a reference to tep_db_fetch_object here somewhere? Anyway, now to spend some time actually getting my configuration working as it needs to... :)
  6. Have you done as per the post linked below? The most current version of osC uses MySQLi, so you have to update all references to mysql_ as explained in the link below...... http://www.oscommerce.com/forums/topic/370902-contribtion-yearmakemodel-for-osc-v23x/page__st__200#entry1677588
  7. Happy to report that I found a simple solution to this problem :) So for the benefit of anybody else who may have the same issue, solution is as per below. After reading around the Sage Pay support forums, I found out that the Sagepay 'Vendor log-in Name' MUST be entered in lower case, whereas I had entered it in Upper case. Having put the Vendor log-in name into lower case in osC admin, all seems to work as it should do, and I have a sucessful test transaction.
  8. I have version 2.3.3.4 of osC installed that has pretty much zero modifications made to it as of yet, just a few configuration changes to tax zones and shipping methods etc. My plan is to try and get pretty much most of the functionality working before transferring the contents of my old DB from an 2.2 MS1 install that has been running successfully for several years now. So right now I am trying to get the payment systems working, the standard install of paypal has been tested and is working just fine. I have downloaded and updated the Sage Pay Server module to version 1.2 and have installed this into v2.3.3.4. I have an account with Sage Pay as this is what I use with my old live installation of osC MS1, so have been able to enter all of the correct account settings in Sage Pay Server 1.2 I am using the 'Normal' setting so as to transfer my customers over the to the Sage Pay website to enter their card data rather than doing this on my website. Now, when I make a test transaction I am transferred to the Sage Pay website, I enter my card details, I go through 3D secure authentication, all looks well until I am returned to the checkout_payment.php page with an error as below ------------------------------------- "Please try again and if problems persist, please try another payment method." ------------------------------------- So I log in to 'My Sage Pay' to see what has happened according to Sage Pay. What I see here is a failed transaction with the following message: ------------------------------------- "Transaction Summary Transaction completed but Vendor systems returned INVALID or ERROR in response to notification POST. Transaction CANCELLED by the Vendor." ------------------------------------- When I google the above error message from Sage Pay, I have read the following information on a forum from Sage Pay support: ------------------------------------- "Once a transaction has been for successfully authorised using Server integration we will then send a notification of these results to your Notification URL which must be able to generate the same VPSSignature that we have provided within this post. Whenever we receive an INVALID or ERROR response it indicates that your server is not generating the same MD5 Signature (which incorporates the Security Key that we provided at the initial transaction registration) that we are providing as the VPSSignature. As this is the final stage of the transaction it will never be registered as a successful payment within My Sage Pay unless we receive a Status of "OK" and a Redirect URL which we will use to pass the customer over to your successful order confirmation page. Your MD5 Signature should be built up of the following values: VPSTxId + VendorTxCode + Status + TxAuthNo + VendorName + AVSCV2 + SecurityKey + AddressResult + PostCodeResult + CV2Result + GiftAid + 3DSecureStatus + CAVV + AddressStatus + PayerStatus + CardType + Last4Digits Even though the transaction has been authorised by the customers card-issuing bank you should never release an order unless the transaction is registered as a successful payment within My Sage Pay and that your server has generated the same MD5 Signature as Sage Pay. By doing this it will confirm that the transaction process has not been tampered with at any stage." ------------------------------------- As I have a bog standard install of osC, I guess I was hoping that this module would work 'straight out of the box', but unfortunately it appears not. I would be very grateful indeed if anybody is able to offer any advice as to where to start with trying to rectify this problem? Thanks - Paul
  9. Paul_w

    Protx Direct v2.22

    Great work with this contribution, well done! Hopefully I can help with a little input of my own...... I too have a problem with 'Error 500 Internal Server Error' as soon as you reach what should be the entry screen for 3D password, though funnily enough it works fine with the Protx Simulator, the problem only occurs when switching over to 'live' I think the reason for the problem is that the script is trying to pass far too much variable information via GET in the src URL for the iframe.... I have changed this to use sessions to store the required information. // Redirect to card issuing bank for 3D-Secure authorisation if ($use_iframe === true) { session_start(); session_register("pw_PAReq"); $pw_PAReq = $responses['PAReq']; session_register("pw_MD"); $pw_MD = $responses['MD']; session_register("pw_acsurl"); $pw_acsurl = $responses['ACSURL']; ?> <!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"> and for the call to the bank page: elseif ($_GET['action'] == 'iframe') { session_start(); echo'<html> <head> <title>3D-Secure Validation</title> <script LANGUAGE="Javascript"> function OnLoadEvent() { document.form.submit(); } </SCRIPT> </head> <body OnLoad="OnLoadEvent();"> <form name="form" action="'.$_SESSION['pw_acsurl'].'" method="POST" /> <input type="hidden" name="PaReq" value="'.$_SESSION['pw_PAReq'].'" /> <input type="hidden" name="TermUrl" value="'.urldecode($_GET['termurl']).'" /> <input type="hidden" name="MD" value="'.$_SESSION['pw_MD'].'" /> <NOSCRIPT> Obviously you should now remove the MD, PAReq & ACSURL variables from the iframe src link. This works great for me :thumbsup:
  10. It works fine for me.... I would say to check that you have installed the mod properly.
  11. There is a session variable created to prevent recounting the same search terms from the same person, so this behaviour is normal. If you shut down your browser window to end the session and then open a new browser window and search on the same search term it will be counted again.
  12. Try using this contribution.... http://www.oscommerce.com/community/contributions,1266
  13. I had this problem too, to fix it replace with the code below: <?php //added for cross -sell if ( (USE_CACHE == 'true') && !SID) { echo tep_cache_also_purchased(3600); } else { include(DIR_WS_MODULES . FILENAME_XSELL_PRODUCTS); include(DIR_WS_MODULES . FILENAME_ALSO_PURCHASED_PRODUCTS); } } ?> On a different note, I have to say this contribution is good, BUT for someone with a large catalogue like me with over 1000 products the admin section is an absolute nightmare to use..... I'll have to look into improving it I guess!
  14. Do you mind posting a link to this, I am interested in this contribution and I can't find an updated version, only the old one.... Thanks.
  15. I know I've seen a contribution to switch the buy-now buttons to use post method instead of get. I've spent ages looking for it in the contributions section and I can't find it as I don't know what it's called or what section it's in. Can anybody help please? Thanks - Paul
  16. I did ask Protx, and the answer was that you only get charged for the actual final transaction itself. The mod I wrote processes the payments only and stores all the related transaction information in the DB. You will need to write a separate script to process any further transactions using this information including processing refunds. Perhaps somebody else will release a separate contribution to provide this additional functionality for Protx direct. The scripts I'm using are not portable at all as they are written/hard-coded to my specific requirements.
  17. That's well spotted, I'm using this contribution and I missed the incorrect tax calculation completely.... I think I have found the problem, at least it seems to be working ok for me now. At approx line 298 of shipping_estimator.php: FIND if (DISPLAY_PRICE_WITH_TAX == 'true') { $tax_val = ($products[$i]['final_price']-(($products[$i]['final_price']*100)/(100+$products_tax)))*$products[$i]['quantity']; } else { REPLACE WITH if (DISPLAY_PRICE_WITH_TAX == 'true') { $tax_val = (($products[$i]['final_price']/100)*$products_tax)*$products[$i]['quantity']; } else { Watch for line wrap above. If you do this along with the previous bug fix I posted all should be well. Please post back if you find any more bugs with the tax calculations as I am using this contribution with 'Show prices with tax' set as well ....
  18. Thanks for this excellent contribution! However I also found the same bug as werner, with the tax being added to the total twice for non-logged in users if you have 'Show prices with tax' turned on. I found that the solution was simply to comment out 1 line in shipping_estimator.php at approx line 303 $order->info['tax'] += $tax_val; $order->info['tax_groups']["$products_tax_description"] += $tax_val; $order->info['total']+=$tax_val; like so: $order->info['tax'] += $tax_val; $order->info['tax_groups']["$products_tax_description"] += $tax_val; //$order->info['total']+=$tax_val; Thanks again for this great contribution. Paul
  19. I've just uploaded a small update to this contribution as I realised there was a broken pop-up window help link for the CVV number on the checkout_payment.php page, this is now fixed.
  20. You're welcome! One important point concerning the contribution though, I realise now that I have uploaded the contribution with it set up to make transactions using the Protx test server, as opposed to the live server. I will not be switching over to the Protx live server myself until sometime early/middle of next week, so until then I have no idea what the protx live server url is. If someone knows the live server url I will update the contribution to use that and/or provide instructions on the one line to change in the module to switch between test/live protx server. Failing anybody providing the url I'll have to leave it until next week before updating the contribution.
  21. A Preauth doesn't place any 'shadow' at all on the users card account, basically it authorises the card, charges the amount and then immediately reverses the transaction. You can use a 'Deferred' payment type to hold the amount for 24 hours though. There are pros & cons to both methods: With deferred payments, when you actually process/authorise the charge, no further authorisation is made on the card, so if the 24 hr period has expired and the cardholder has spent up to their credit limit you would not receive any money! With Preauth, when you follow up the transaction with a 'Repeat' payment the card is re-validated/Authorised via the information stored from the original Preauth, so if there is no money available the transaction would fail. Protx recommend using the Preath method for merchants who want to take payment upon shipping goods rather than at the time of sale. I have also decided to use this method myself. I don't yet know whether there are 2 charges or a single charge, I shall be in touch with Protx on the phone again in the next day or so, so will pass the info on when I know. Whatever the case, you are only talking an extra 5p anyway!
  22. This is exactly the way that I'm using Protx, you can use the contribution to take 'PREAUTH' Transactions which don't actually remove any money from the customers account, the transaction is authorised, then later using the Protx details received and stored in the DB by the original preauth transaction you can make a further 'REPEAT' payment when shipping the goods, this will then remove the money from the customers account. This added functionality would need to be scripted separately from the contribution I have written. With Protx you need to be able to demonstrate an ability to make refunds also, so added functionality is needed for this. However all this functionality is beyond the scope of the contribution, which simply takes and processes single payments but does allow you to set which type of payment request you want to make.
  23. From the php manual: "libcurl, a library created by Daniel Stenberg, that allows you to connect and communicate to many different types of servers with many different types of protocols. libcurl currently supports the http, https, ftp, gopher, telnet, dict, file, and ldap protocols. libcurl also supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading......." Best way to check for cURL is to run phpinfo() on your site/server, if you see cURL listed than you have it available, however it seems to be the case that cURL is sometimes built without SSL support, I'm not sure if there is an easy way of testing for SSL support. The way I did this was to write a short php/cURL script to connect to an https page and use the curl_error() function to find out that it didn't support https (SSL not supported) this meant a recompile of PHP and cURL on my server (I have my own dedicated server). With luck most people would have this available already..... Youre right in that Protx direct means that the transaction is completed entirely on your own server, and of course this means that the customer has to enter all CC info on your site which you then pass through to Protx, it is entirely possible to store CC details in the DB however I am not going to be doing this and personally I would rather not take the risk, in the the readme.txt I wrote, there are instructions on 1 line to change to prevent the CC number from being entered into the DB. Once the Protx transaction is completed all the return info from Protx is stored in the DB and these authorisation/security numbers can be used again to repeat or release deferred payments, so there really is no need to run the risk of holding all customers CC info in the database. Sorry no, I don't think there is a simple way to disable just the protx payment part. If you know a little php you could go into the code and comment out certain lines that would stop the Protx request/response part from functioning. HTH Paul
  24. I've just uploaded this. Get it here: http://www.oscommerce.com/community/contributions,1163
×
×
  • Create New...