Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

devosc

Archived
  • Posts

    1,212
  • Joined

  • Last visited

Everything posted by devosc

  1. Hi, I've installed menuBarV1 but for some reason it will not, for example, show the top level categories. It looks to load ok, but I see where the top categories are defined. Can you point in the right direction please? Cheers, Greg.
  2. Slight mistake: Should really be'invoice.php' => 'customers.php', 'packingslip.php' => 'customers.php',
  3. waro, you are correct, there is a problem with the associated files. To rectify it go to admin/includes/functions/administrators.php find $aADMPages = array(......) now insert 'invoice.php' => 'catalog.php', 'packingslip.php' => 'catalog.php', just after where it says 'categories.php' => 'catalog.php', Now you can now see how to associate the files you want to their corresponding box.
  4. Davee, No, something is wrong. Do you see the relevant information of that order, i.e the osC info stuff? Did you do anything to the database tables? Try deleting all your previous IPN related orders. And making another another another trial purchase. If I'm not mistaken, even in test mode, when the transaction is stored, you should still see some IPN (test) info in the osC orders page, but I can't remember.
  5. Dave set it to Test Mode, see an earlier thread for how to do a test, basically jsut make sure the cart total is the same as the the mc_gross you specify in the ipn_test.html, that should allow the txn to be stored. You seem to still be having problems making a connection to PayPal. When successful you will have an email saying curl= socket=ssl domain=www.paypal.com port=443 or curl= socket=tcp domain=www.paypal.com port=80 or 'something' for that solution posted in here in this thread. Basically in Test Mode you will get an email saying INVALID, but the txn will still be stored. This is correct because PayPal did not verify it.
  6. Radders, As said this occurs when the shopping carts contents (total_gross) differ from what the total is that PayPal is saying has been paid. There are 3 tests: [1] If using Method 2 (Itemized); Are the number of items in the cart matching? [2] Is the transaction in the same currency. [3] Is the gross amount correct. These checks compare the transaction details sent from PayPal to the details of that particular shopping cart sesssion. It is assuming that the customer has not had the time to update the shopping cart, because in theory they're supposed to be busy paying you on PayPal's site. Doesn't mean to say that someone is not trying to mess around, i.e they have another browser open whilst on the PayPal site and in the other browser they go back and change the contents of the cart, they then finish paying PayPal and when returning to the site, if the [1, 2, and 3] do not match then there is something up and you get that email. As always PayPal will send you an email. Thinking further, it might now be clearer as to a better use for that invoice number you see in the orders section. What could happen is that it could contain the customers osC ID, that way if any hiccups do occur when PayPal sends you their own email it should then contain this invoice number, which could help you to identify that particular customer. But the invoice number has to be uniquely specified by you, and so more thinking and scripting is required.
  7. Hi Davee, I don't have too much time to look at the code again. But quickly though, You should of received a few more emails than just the one you showed. The email notification level is set to 2 by default. Did you have it in Test Mode? Probably so, ok that email occurs because the contents of your shopping cart was not the same as what you specified in the ipn_test.html. If in Test Mode (which you had to be in order to have that far) the order should of been stored in your database. So have a look in osC admin. Yes you're interpretation is correct. Was it absolutely nessecary to do this, doesn't feel like you had enough time to determine that you had to use this last result. But I'm being a bit slow this morning. Put it into live mode and make a real trial purchase.
  8. sky, The problem with automatically deristering the cart is that if the customer does return to the site then they don't get redirected to checkout_success. I haven't really looked into how long before a session expires, but I think the answer could be to set in osC admin to create a new session each time the customer logins in etc. Haven't tested it though. If you look at includes/modules/payment/paypal for the before process function you will see whats occuring in order to deregister the session.
  9. Dave, It will try and use curl, but so far I've only seen it supposedly working with an ssl connection at best, which it will automatically try if curl doesn't work, and if ssl doesn't it will then try tcp and if that doesn't work either the absolute fall back solution is posted earlier on in this thread.
  10. Cor, read through the thread you will find your answers.
  11. Cornelius, In /catalog/includes/classes/paypal/ipn.php find the function authenticate($domain) {}, You will have to make sure you get it correctly i.e find the last '}' which closes the the function. Delete it all and replace with the code shown previously.
  12. [1] How did you install the /catalog/includes/modules/payment/paypal.php module? Did you copy the file from the contribution files, or have you tried to cut and paste individual lines of code? Unistall/remove the PayPal module in osC admin. Copy over the file correctly. Now install the PayPal module. [2] Greg.
  13. :rolleyes: Well it's better than getting none at all! Ok you seem ok, you can set the email notification to 1. BUT DO WHAT I SAID IN THE EMAIL FIRST :P . before you get too :) It also wouldn't hurt to have read those emails, they are sent to help you!
  14. :) you seemed to have followed the email correctly. Look back in the thread I have explained step by step what to do. Why don't you make a 'real' trial purchase first. Create a $0.01 product and buy it, before hitting the continue button in PayPal, go to osC admin and look for the order/IPN. Put something in the memo fields so that you can identify it. Give it go. If you want to try the test go ahead but you have to explain which bit of my previous instructions you don't understand. I guarantee if you start step by step you'll figure it out. I just went to your site, check your email, you should have one saying saying unkown something or another - transaction?
  15. Mark, Firstly which configure file do you think is used by 'catalog/ipn.php', i.e in which directroy is it located? The problem is occuring, possibly to something in your catalog/includes/application_top.php file, but this might only be because of another contribution installed. But then again, why is this problem only occuring with ipn.php and not 'index.php', something is peculiar here. Look in the readme file and find my email address. Email me your catalog/includes/configure.php file and catalog/includes/application_top.php file. Please don't post here. I can not promise because I'm busy on other stuff, but I will quickly have a look, but the problem might not even be there, but we can try. Greg.
  16. In v1.5 (which everybody should upgrade to) The cart is reset in two places, due to PayPal sending two seperate IPNs [1] PayPal - osC [2] Customer - osC For [1], this involves catalog/includes/classes/paypal/cart.php, look for the function process_transaction() which is basically checkout_success.php all over again (i.e copied 'appropiately'). This is called when PayPal sends their independant IPN, which as far as I can tell occurs 'prior' to the customer being shown the last PayPal page where they would then click the continue button to return to the site (case [2]). For [2], this involves the usual checkout_process.php file, which calls the before_process in /catalog/includes/modules/payment/paypal.php, this is analogous to the default osC scenario of a customer retruning to osC when having clicked the last PayPal continue button. So catalog/checkout_process.php is now only ever used when [1] has never been received prior to the customers return. And the catalog/includes/module/payment/paypal.php before_proccess function now determines whether [1] has already been received and resets the cart if it has, i.e the order already exists. This is the before_process function: function before_process() { global $cart, $customer_id, $order; include_once DIR_WS_CLASSES.'/paypal/ipn.php'; if ( strcmp(phpversion(),'4.0.6') <= 0 ) $_POST = $HTTP_POST_VARS; $ipn = new paypal_ipn(MODULE_PAYMENT_PAYPAL_IPN_DEBUG_EMAIL,$_POST,tep_session_name(),MODULE_PAYMENT_PAYPAL_IPN_DEBUG); //post back to PayPal system to validate if($ipn->authenticate('www.paypal.com')) { //check to see whether the txn_id already exists if(!$ipn->unique_txn_id()) { //txn_id has already been stored, so reset shopping cart session $cart->reset(true); // unregister session variables used during checkout tep_session_unregister('sendto'); tep_session_unregister('billto'); tep_session_unregister('shipping'); tep_session_unregister('payment'); tep_session_unregister('comments'); tep_redirect(tep_href_link(FILENAME_CHECKOUT_SUCCESS, 'paypal=authorized', 'SSL')); } else { //PayPal hasn't notified us yet but the customer is here, so continue the transaction. //Really we could do further checks like checking for //a valid payment i.e. $ipn_cart->valid_payment($ipn,$cart,$currency) $ipn->insert_ipn_txn(); $order->paypal_ipn_id = $ipn->get_paypal_ipn_id(); return false; } } else { //PayPal did not authorize this transaction or there may have been problems //communicating with them, If there were no communication problems then someone is //trying a blatant hack, so send the store owner msg to that effect and let the //them continue as per default osC scenario $msg = "A transaction occured but PayPal did not verify it, this could be due to a " ."communications error, but it could also be an attempted hack.\r\n" ."Customer $customer_id, {$order->customer['firstname']} {$order->customer['lastname']} has been " ."allowed to continue their order.\r\n" ."Please Check Your PayPal account.\r\n\r\n"; $ipn->send_email('Invalid Customer Transaction',$msg); unset($msg); return false; } } So what could now be done is for the function $ipn->unique_txn_id() to return the 'order_id' if the transaction_id is not unique. This can then be put in as the required variable for $reset->cart(true,$order_id). i.e. $insert_id is $order_id. Haven't tested it and haven't looked at this auction contrib code, so quickly thinking, this seems roughly what needs to be done if also using PayPal_Shopping_Cart_IPN.
  17. If your site has SSL you can also set your PayPal IPN profile to use https://www.yourdomain.com/catalog/ipn.php
  18. Mark, When loading that page in the url, it seems to keep reloading and trying to insert/append a new osC session id. I thought it was a redirect but when I looked at the url after 3 or 4 reloads, there were about 4 different osC session ids, check it and see. I don't really know why that is occuring, maybe a osC admin config setting or module contribution?
  19. Hi Duncan, Sounds like you may have v1.4, which had a spurious print statement when recalling paypal_ipn_id. I would suggest that you upgrade to v1.5. You should be able to get away with just copying over the paypal related files (i.e not the language,filenames,database_tables files) - I would do this also in the osC admin side too. v1.5 is a slightly improved version but of the same functionality as v1.4, alternatively you could suggest remove that line: print "{$this->_paypal_ipn_id}<br>"; in function get_id(). I am presuming this to be the problem if not open /catalog/includes/classes/paypal/ipn.php and let me know whats occuring at line 235.
  20. C, If you want to receive emails when an order occurs put your email address in the send extra emails field in osC admin/My Store. If the above mail function doesn't work for you not sure what to suggest, maybe it is your PHP config settings. I suppose we could try and use the osC tep_mail function, I didn't need it at the time but it might solve your problem. But this would still leave the real issue of your not receiving PayPal's IPNs. Dunno at the moment, would have to think and/or test your system.
  21. Hi C, In that code: mail("[email protected]", "PHP TEST", "TESTING\r\n"); Is the in built PHP mail function, out of interest do you get any emails when an order is placed at your store?
  22. Mark, You could just set it to http://host86.ipowerweb.com/~yadyshop/catalog/ipn.php But I just checked it out and it seems that you have a redirect going on which is screwing up everything. Make things simple. Use your domain name. You only need SSL for customer login and purchase. I suspect now this why you might be having trouble with some of the other modules. Basically when you go to http://host86.ipowerweb.com/~yadyshop/catalog/ipn.php it should just load a blank page, but there something going on, i think, in application_top, that is causing a redirect, hence PayPal will never successfully be able to send an IPN.
  23. Hi C, That ipn.php file looks original :P Ok as a test, back up the original catalog/ipn.php file. Now copy and paste the code below and save it as /catalog/ipn.php (i.e to replace it). Now go to that file in your browser: http://crazearcade.com/catalog/ipn.php You will now see some stuff on the screen. You should also get 2 'TEST' emails saying 'TEST'. Make sure the email address in the code below is correct. Let me know whats happeing, i.e emails etc, maybe leave the file on your server, and I'll go and have a look. <?php if ( strcmp(phpversion(),'4.0.6') <= 0 ) { $_GET = $HTTP_GET_VARS; $_POST = $HTTP_POST_VARS; $_SERVER = $HTTP_SERVER_VARS; } unset($_GET,$HTTP_GET_VARS,$HTTP_POST_VARS); //Continue the session $HTTP_POST_VARS['osCsid'] = $_POST['custom']; //Start up osC require_once('includes/application_top.php'); require_once 'includes/classes/paypal/ipn.php'; $ipn = new paypal_ipn('[email protected]',$_POST,tep_session_name(),2); $ipn->send_email('TEST','TESTING EMAIL'); mail("[email protected]", "PHP TEST", "TESTING\r\n"); echo $ipn->debug_info(); phpinfo(); ?>
  24. Have you tried to run the ipn_test.html, as suggested? No-one else has had problems receiving emails, thats a basic feature of PHP? Seems like PayPal IPN v0.981 might be more suitable to you, but don't hold me responsible for that suggestion.
  25. C, Ok, first we have to sort out the no email problems. Upon installing the module in osC admin, I'm assuming that [email protected] is there in all the email fields Now go to: http://crazearcade.com/catalog/ipn.php In your browser, you will get a blank screen. Now check your email, you should get one saying something like: STORE_NAME PayPal IPN: unkown transaction type --------------------------------------------- I received an unkown post from {some i.p address} Are you running any tests? If not, there is something possible up with your server platform, are you using Apache with Windows? I've only tested this contrib on Apache/Linux. If you look in the previous posts in this thread you will see how to do a 'test'. Can't be of much more help right now, other than to specifically look at your system, which I don't have time to do this week.
×
×
  • Create New...