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. At this moment in time this contribtuion is designed for MS2 2.2, it may work for previous versions but that would be just by chance. I would not really recommended using a CVS version for a live site since CVS versions each have different states of change during the development cycle for the next release and if for example you discover a problem you could have problems getting suport for it or correcting it.
  2. Ryan, In catalog/includes/modules/payment/paypal.php find the function _getPayPalFields() and where it retruns the $paypal_fields string the code should now look like this: $paypal_fields .= tep_draw_hidden_field('notify_url', tep_href_link('ipn.php', '', 'SSL')); return $paypal_fields; This will overide the url specified in your PayPal profile.
  3. Yeah I know exactly what you mean, but I suppose we get what we pay for. http://www.oscommerce.com/community/contributions,769 (there may be others)
  4. Bill, Have you commented out the check_valid_payment if statement in catalog/ipn.php. I think this will resolve the problem, (the COULD NOT PROCCESS one anyway), why the customer's paypal details did not show is a mystery right now. Quickly thinking the IPN that PayPal sent to you independently was not registered, hence the above email, thus (I suspect) it was only when the customer came back to the store that the order was processed, why their details did not end up in the order page is the weird part. PoZel, Try out the test decribed at the bottom of page 5 of this thread. You will also need to make a trial purchase yourself. There should be sufficient info around that section of the thread to let you know how to sufficiently test a PayPal transaction.
  5. Dude, I was being sarcastic, unless you try to explain more about your environment and the steps that you have taken in your preliminary tests, there is not much help anybody can give. Unfortunately you must go through the previous posts which contains all of the information that you might need, once you start asking the right questions you can then get a better response.
  6. The quickest method to fix it, is to uninstall it.
  7. Hi Frank, At this moment in time I am unsure as to PayPal's exact policies in regards to payments from customers with and unconfirmed address. When you receive an IPN, PayPal includes this information about the customer, eg. if they have a verified address it will shown on the order page in osC admin that their address status is '1' and presumably '0' if not verified (really it should say this rather than displaying a numeric value). If the customer checks out via your store and you're offering the customer the choice of payment methods, eg. credit card, paypal etc and the customer decides to go for PayPal and then decides that they don't want to use PayPal then the cleanest way for them to get pack to your site so as to choose a different payment option (apart from beating them with a stick) is for them to click PayPal's cancel button. If still installing (at least you will be able to have your logo on the PayPal site etc), there are a few posts earlier in this thread that will help fix any issues (one on the first page mentions how to get the payment method back in the customers order email).
  8. Richard, If you have commented out the check_valid_payment as mentioned in a previous post. Then you could 'try' doing a global replacement of $currencies to $osC_Currencies in: /catalog/includes/classes/paypal/cart.php /catalog/includes/modules/payment/paypal.php
  9. Cornelius, :D, sorry if it sounded a bit brash.
  10. Cornelius, 'right!' Does not answer my question, I have now taken the time to test it, and it seems that 'you' 'are' in 'Test Mode'? Because in 'Live Mode' i.e Test Mode =0, the 'Refunded' IPN does not register. In test mode, i,e Test Mode = 1, the 'Refunded' IPN is registered.
  11. Cornelius, Ok, I now see what you mean by in reference to. However, in osC admin, are you in 'Test Mode', because in 'Live Mode' a transaction is only supposed to stored when the payment_status is 'Completed' and not 'Refunded'. In osC admin when you view the 'Refunded' order, what does it say the payment status is?
  12. Sorry Radders, I just read your msg properly.
  13. Suggests that 'table' has not been defined in either catalog/includes/database_tables.php or catalog/admin/includes/database_tables.php, because it is showing the constant name, rather than the actual name, e.g:define('TABLE_PAYPAL_IPN' , 'paypal_ipn');
  14. In PayPal's case there is! You get sent two IPNs, one independently from PayPal, which I classify as PayPal - osC, the second IPN is actually received when your customer (Customer - osC) returns to your site upon clicking the continue button, which ever is received last is considered to be the duplicate transaction. I'm a little intrigued by this, are you saying that a refunded 'is' being stored as an order in osC, I had thought that a 'Refund' uses the same transaction ID (txn_id) as the original transaction, hence you should of just got another duplicate transaction email msg.At this time I am not in the position to further develop the contrib to handle refund requests, which should probably be an osC admin configurable option, i.e. everybody might not want to have their orders automatically re-instated. Please check, that refund should of had the same transaction id, so in theory it currently should not of been registered.
  15. C, $payment->after_process(); is 'called' in checkout_process.php and for this contribution it is 'defined' in catalog/includes/modules/payment/paypal.php.
  16. Cornelius, Please read the last few pages of the thread a suggested solution has been previously posted. the after_process() is in catalog/modules/payment/paypal.php Hint: you will also need to define $cart global in the function, see the before_process() in that file for an example.
  17. OK, Ithink I now know what is causing the blank screen, in catalog/includes/classes/paypal/ipn.php the class constructor has some 'exit' terms which is causing the the application to terminate. So if you remove the 'exits;' form that section of code you will be allowed to checkout. However! It should be noted that those exit statements occur, when [A] The transaction type is not one in PayPals verification version 1.5 list, i.e web_accept, cart, send_money and reversal, and if 'A' is ok but the 'txn_id' is not of the same length as PayPal specifys in their version 1.5 verfication scheme. I haven't gone through all the precautionary tests, but if you remove those exits you should now be ok, maybe somebody could check this by first renaming catalog/ipn.php to ipn.phpX so that PayPal cannot send their IPN prior to the customer returning to the site. Another trial transaction should then be made, and before clicking the continue button have a look in osC admin for the IPN, hopefully it should be there, then click the continue button and see what happens. Incidently when noticing this, I also received an email with the subject 'unkown transaction type' for . Out of interest if you did recieve a valid PayPal payment could you please check that trnsaction details and let me know if the number of characters in the transaction ID (# .....) is not 17 characters in length. Please do keep us inform whether or not this resolves the issue. When I have the time and mind I will look to see what risks this might have to a transactions authenticity, more importantly why it is occuring. Didn't any you get the unkown 'transaction type' or 'unkown post' ?, the latter only really occurs when there is absolutely no information at all. Sorry JimJam, when I set up the install module side I used Business Name instead it should of read Business ID which is what PayPal meant. function paypal_ipn($email,$post_vars='',$session_id,$debug='0') { $this->_debug_email = $email; $this->_debug = $debug; $transaction_list = array('web_accept','cart','send_money','reversal'); //accepted transactions if ( !$this->_valid_trans_type($post_vars['txn_type'],$transaction_list) ) { if ($this->_debug) $this->send_email('unkown transaction type',"I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?"); exit; } else if(strlen($post_vars['txn_id']) == 17) { //Looks like a PayPal transaction $this->_init($post_vars,$session_id); } else { if ($this->_debug) $this->send_email("unkown post","I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?"); exit; } } the above should now be function paypal_ipn($email,$post_vars='',$session_id,$debug='0') { $this->_debug_email = $email; $this->_debug = $debug; $transaction_list = array('web_accept','cart','send_money','reversal'); //accepted transactions if ( !$this->_valid_trans_type($post_vars['txn_type'],$transaction_list) ) { if ($this->_debug) $this->send_email('unkown transaction type',"I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?"); } else if(strlen($post_vars['txn_id']) == 17) { //Looks like a PayPal transaction $this->_init($post_vars,$session_id); } else { if ($this->_debug) $this->send_email("unkown post","I received an unkown post from {$_SERVER['REMOTE_ADDR']}\r\nAre you running any tests?"); } }
  18. Hi MS, No I don't think paypal has such a feature. The best I think we could could do is to try an replicate the transaction by amending the ipn_test.html file to suit, i.e at present I think that it only has fields for one item, maybe two. You could try, or if you post here the IPN info, specifically the numerics etc, the id's aren't important, I could try too. Basically you just amend the ipn_test.html file to suit, get it to point to catalog/ipn.php, in osC admin set it to Test Mode. submit the ipn_test.html form. This will store the transaction irrespectively, but you will get emails of the failed test results etc. In particular, for check valid payment the emails are: Incorrect Cart Contents => No of items in cart did not match when the transaction was a 'cart' method, i.e you are itemizing your cart contents on PayPal as well Incorrect Cart Currency => the currency chosen at checkout time does not match the currency the customer paid in. Incorrect Cart Total => The shopping cart's total does not match the 'mc_gross' figure provided by PayPal. ----------------------------------- Now to look into checkout_process.php, you could spoof / hijack the checkout process, basically go through and checkout, but do not click 'your' confirmation button which would take you to PayPal, instead, look in your URL for the osCsid, i.e. if the customers shopping cart session id, if it is not there, view the source of the page, scroll down and find the hidden custom variable, it's value is the osCsid. (You will also see the list of items that are specified in the cart) Copy the osCsid, open another browser window. In that url address bar type catalog/checkout_process.php?osCsid=*************** Replace the ***** with the value of the osCsid you just copied. Now hit the return key. Should now be then redirected to checkout_success.php. You will also get email warning you that you have just hijacked the checkout proceedure. This might not be the right test, but it might give an idea of whats happening, because really there should be no reason for it too show a blank screen, something is casuing it to die/exit prior to the checkout_success.php redirect. Out of interest what other contributions do you have installed? In fact I think it should be possible to combine both of the above to really mimick a 'real' transaction if you see what I mean. Since the ipn_test.html is supposed to be the fields that PayPal would post back to your site in their IPN. So just get the form to post to catalog/ipn.php and for that form's action append the osCsid in the url specified as discussed above.
  19. If you are able to make a real test PayPal transaction, another test that you try, is to temporarily rename catalog/ipn.php to say 'catalog/ipn.phpX' that way PayPal will not be able to send the IPN, now when you click PayPal's continue button you will then see what would happen if the Customer returned and the PayPal - osC IPN had not already been received, i.e checkout_proccess will then actually be used to generate the order, and you will be redirected to checkout_success.php as usual (in this case you will not see 'paypal=authorized in the url'). Now check osC admin, the IPN should be there. Remember to rename the ipn.phpX back to its original name afterwards! Radders I have just seen your msg, until such time this can be fully resolved it might be easier to do as suggested and just reomove the check_vaild_payment clause form catalog/ipn.php, this way you will get the transaction, and upon your personal verfication, you can always complete the order as usual or just delete if neccessary. Guys (and Gals), I can't give much more of my time for free!
  20. Hi, Can anyone tell me which contribution they have to work reasonably that allows the admin to authurize customer accounts prior to their ability to login/checkout. I have seen a few, and will have to find and install each one, so I'm just trying to save some time in asking. Cheers.
  21. I just made another trial purchase, I have a local server where all my products are $0.01, I chose one product and checked out using the Method 1 (aggregate). Upon confirmation I was directed to the PayPal site, I logged in and payed the $0.01, before clicking the continue button I went to osC admin to see if the IPN had arrived, it had. I then clicked continue and was redirected to /catalog/checkout_process.php which determined that I had a qualified transaction and that it had already been processed, I was then redirected to checkout_success.php and the contents of my shopping cart was cleared. In my PayPal account I have the IPN url specified to use SSL, i.e. httpS:// At present in osC admin / Sessions all of the settings are currently flaged to false. Whether changes in these default settings, for example recreate session, are causing these unkown results to occur I am not sure at present. May be I need to try and mimick a real purchase, but right now I still have to find out where all my pennies are going in developing this contrib, PayPal says they have been refunded but they haven't appeared in back in the originating accont. checkout_proccess.php is the correct file to be returing to. Ah, ok, I now see that the email regarding 'Incorrect Cart Contents' is actually an occurance of when the number of items in the shopping cart does not match the number specified by PayPal which is their 'num_cart_items' variable which only tested/compared when the store owner is using the Method 2 (itemized) PayPal shopping cart. I now just test a purchase of 2 products each @ $0.01 and the whole process was successful, as in the same above Method 1 case. At this moment in time it is unclear as to whether integrating this contrib/module into your existing site that may have contribs may be causing a conflicts. You should always be redirected to checkout_process upon clicking the PayPal continue button. To confirm this, prior to clicking 'your' checkout confirmation button, view the source of that page, and find the hidden field called 'return'. As said the code in the paypal payment module allways allows the checkout_process.php file to continue processing if the PayPal - osC IPN has not already been received, which if you look at the bottom of checkout_process.php you will see $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, '', 'SSL')); So the customer's cart is always reset (cleared) and they are redirected to checkout_success.php That same snip of code is what is used when the PayPal - osC IPN has already been received (which creates implicitly creates the order). So when the customer returns to the site the above snippet of code (which can also be found in the paypal payment modules before_process function) simply clears the cart and redirects the customer to checkout_success.php and there will be 'paypal=authorized' appended to the URL. Earlier in this thread I outlined a procedure on how to Test your IPNs. As you can see PayPal passes back via the IPN a good few parameters, each has their own purpose and to that end it has not been possible to fully cover the each aspect of the transactions IPN info. So when you recieve payments via the 'web_accept' and 'cart' methods provided that the IPN is authentic from PayPal, the last set of checks made of the transaction is whether it is a valid payment which is called in catalog/ipn.php and the code for this function, valid_payment(&$ipn,&$cart,$currency), is in classes/cart.php. If you would like you could easily just remove the conditional statement in catalog/ipn.php if ($ipn_cart->valid_payment($ipn,$cart,$currency) ) { //needs work $description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart"; if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n"); unset($description); $ipn->insert_ipn_txn(); $ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id()); } else { if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"COULD NOT PROCESS: You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n"); } and change it to $description = "This payment was sent by customer {$ipn->key['first_name']} {$ipn->key['last_name']} via the osCommerce / PayPal Shopping Cart"; if (MODULE_PAYMENT_PAYPAL_IPN_DEBUG) $ipn->send_email('cart',"You have received a payment of ".number_format($ipn->key['mc_gross'],2)." ".$ipn->key['mc_currency']."\r\n\r\n$description\r\n\r\n"); unset($description); $ipn->insert_ipn_txn(); $ipn_cart->process_transaction($order,$language,$ipn->get_paypal_ipn_id()); It would be nice to of been able to better determine the cause for this particular problem, but I am unable to quickly replicate it, maybe you could try and edit the email that is sent to you to provide you with the values of the variable s that the test is failing on, anf the type of transaction ('web_accept','cart'). The problem about returning to a blank screen is unkown to me at this time. According my trial purchases I do not have this problem at all.
  22. A thought has just come across my mind about how PayPal might calculating the gross total, for example suppose in the osC you had the following sub total = 0.007 shipping = 0.007 osC total = 0.014 BUT I suspect that our friend PayPal will actually calculate it as follows sub total = 0.01 shipping = 0.01 PayPal total = 0.02 Hence PayPal's 2 decimal rounding plagues again. Untill this can be further confirmed, tested, etc, you might want to just comment out that particular if statement in the cart.php file. At least this way the order is stored, and since you should always verify the payment in your PayPal account anyway, you should be ok (maybe as long as your terms and conditions forces them to agree that you the store owner are allowed to refuse any transactions etc). What those checks in cart.php do is to try to ensure that the IPN it recieves pertains to relevant data (i.e. what is in that customer's shopping cart), because anyone could make/post a PayPal payment to your account, which via the IPN could register it as an order. Hence these checks are supposed to throw out spoof/hoax transactions.
  23. The above should be $cart->show_total() to number_format($cart->show_total(),2) Which occurs in the function valid_payment in catalog/includes/classes/paypal/cart.php.
  24. Hi there, I saw a question about COULD NOT PROCESS email in another thread, which in that case occred becasue of the cart total did not match, I think Radders tried to point this out before, but I was thinking of it being due to something else, below is what I suggest is the cause and solution: Please let us know if you have any further thoughts on this issue.
×
×
  • Create New...