Jump to content

devosc

♥Ambassador
  • Content count

    1,212
  • Joined

  • Last visited

Everything posted by devosc

  1. devosc

    PayPal_Shopping_Cart_IPN

    Hi John, There are two ways to solve this, [1] Change 'SSL' to '' (or 'NONSSL') in tep_href_link() on lines 180 and 181 in /catalog/includes/modules/payment/paypal.php, OR [2] in catalog/includes/configure.php I presume ENABLE_SSL is set to false and that there is no URL set in the line above HTTPS_SERVER, set that to be the same as HTTP_SERVER also ensure that DIR_WS_HTTPS_CATALOG is set to the same as DIR_WS_HTTP_CATALOG. Greg.
  2. Hi there, I have just submitted a lengthy post in my support thread which may cover your issues, if not let me know. http://forums.oscommerce.com/index.php?showtopic=72942 Cheers, Greg
  3. devosc

    PayPal_Shopping_Cart_IPN

    Hi Bill, I'm glad you like it. When developing this contrib I adhered strictly to osC's methodology for processing PayPal payments.This is why it is more secure than IPN_v0.981, because PayPal receives the transaction information via the POST method, where as IPN_v0.981 uses the GET method which places the transaction details in the URL (address bar) of the customers browser (thus potentially allowing them to change the price etc...). The reason why IPN_v0.981 'had' to redirect the customer via the GET method was, for example, to enable storing the customers order, which consequently generated a new 'order_id' that could then be passed to PayPal to show on their site/invoice. But, as said, in order to safely transfer the transaction details to PayPal the POST method must be used, but (to my knowledge) this can only occur when the customer hits 'your' checkout confirmation button which immediately directs the customer to PayPal with all of the information available at that point in time. Now, a possible solution, would be to have a seperate paypal_orders table (the current table of that name is used in a different context) where a potential transaction number could then be generated from, or indeed an order (as such) could be generated such that it would enable the generation of an 'order_id' and when the transaction is actually 'Completed' (etc) the pertaining information is inserted into that reserved spot. Thinking, quickly, now, it probably wouldn't be a good idea to directly use the 'orders' table to do this otherwise you could end up with blank orders showing in osC admin, thus a work around would be required using the 'paypal_orders' table. So at present it is not possible to pass the order number to PayPal as the item_number. I will look into changing the item_name to list the items being pruchased instead of the the item_number. However given the above what would you suggest to be placed into item_number (which is an optional parameter and could be left out altogether). It is also possible to specify your own 'invoice' number, which the customer will not see or be able to edit, but must be unique per transaction. You'd might like to look over the IPN parameter options available which can be found in the PayPal IPN Manual, in relation to the nature of your business, which includes auctions and subscriptions. There is also available PayPal's Shopping Cart Manual. This is a reminiscent feature of PayPalIPN_v0.981.As noted above I strictly adhered to osC's default methodology. And at present this contribution will only accept an IPN from PayPal when the transactions payment_status is 'Completed'. However should the customer click the last PayPal continue button and return to your site the order is completed as per default osC, however you will get an email if the at that moment in time, upon the customer's return, their transaction could not be verified by PayPal - which may be due to a communications error (unlikely) or if the person is trying to fool with the payment system (i.e. hack/hijack it) - you will receive an email with the customers id, first and last name, to that effect. So at present, I have not made any changes to osC as to how it regards reciept of a PayPal payment, i.e. it will just say pending, but when looking at the customers order and pertaining PayPal transaction information you will be able to see the payment_status - which will be 'Completed' if recieved via the independent PayPal - osC IPN, and whatever the payment status is if the customer returned to the site, i.e it might well be 'Pending', 'Failed', or 'Denied', there are two other types in this category 'Refunded', and 'Cancelled', which may occur but, quickly thinking, I cannot envisage a customer returning to your site in either of those two states. This might now suggest that a 'Pending' status should also be allowed to be registered via the PayPal - osC IPN (i.e. the one PayPal sends independently to your site - which I suspect is always sent prior to PayPal showing the customer their last PayPal page - where the customer would click the contiue button to return to your site). These instances can be easily accommodated but requires a little more scripting to potentially find and update the corresponding PayPal transaction. Thus at present it is left up to you the store owner to manually determine and update an osC order from 'pending' to 'processing'. If you are happy that the contribution is operating to your satisfaction - set the email notification level in osC/Modules/Payment/PayPal to level 1, this will reduce the number of emails received per transaction. Thanks, I hadn't noticed this, this is ocurring because the independent PayPal - osC IPN is being recieved prior to the customers arrival, and although the independent case uses exactly the same script as checkout_process.php but located elsewhere (in /catalog/includes/classes/paypal/cart.php) the conditional statement that printed the payment method was not being evaluated as true, to fix this at the bottom of cart.php the bit where it says: if (is_object($$payment)) { $email_order .= EMAIL_TEXT_PAYMENT_METHOD . "\n" . EMAIL_SEPARATOR . "\n"; $payment_class = $$payment; $email_order .= $payment_class->title . "\n\n"; if ($payment_class->email_footer) { $email_order .= $payment_class->email_footer . "\n\n"; } } can be replaced with: $email_order .= EMAIL_TEXT_PAYMENT_METHOD . "\n" . EMAIL_SEPARATOR . "\n"; include(DIR_WS_LANGUAGES . $language . '/modules/payment/paypal.php'); $email_order .= MODULE_PAYMENT_PAYPAL_TEXT_TITLE . "\n\n"; Incidently, in the Contributions Announcement thread I mentioned the possibility to have a third option in osC admin which would assign Method 2 (Itemized cart) to be used as the default method of transferring the osC cart information to PayPal however if that particular transaction required tax to be be charged it would automatically use Method 1 (Aggregate), see the Contributions Announcement thread for details about the current problems with tax and PayPal (basically it is due to the way PayPal rounds up to 2 decimal places whilst calculating the tax for individual items - which for Method 2 must be specified individually per item). As noted above it is now possible to strictly enforce the verification and validation of a PayPal payment prior informing the customer that the order has been completed, this may be particularly important for those who offer downloads to occur once the customer has successfully (or supposedly) completed the order process However, at the time of developing this contribution, I allocated the Christmas period to do this work, and I must now start focusing on finding an income, my wife will soon be refusing to feed me <_< and so further development of this contribution is not as much of a priority right now, that is unless somebody would like to contribute a donation B).
  4. devosc

    PayPal_Shopping_Cart_IPN

    Hi dmaci, try the example on php.net http://us2.php.net/manual/en/function.file.php If that works on your system, it should, then we'll see what we can come up with later today maybe.
  5. Hi there, If I were you I'd uninstall that contribution, I had a quick look at the code to see what might be happening with respect to the order total, basically in the original version osC version a call is made to a class called order_totals. require(DIR_WS_CLASSES . 'order_total.php'); $order_total_modules = new order_total; $order_totals = $order_total_modules->process(); And in that contribution it only seems to use the 'order' class which is different, I would have to look further to see what that would do, but because the 'order' class hasn't been included in contribution files, suggests there has not been any change, if so, then why wouldn't the original osC version just do that (i.e use 'order' instead of 'order_total')? I think if you run the test suggested above you'd understand the point I was trying to make earlier also. If you look for PayPal_Shopping_Cart_IPN you will find that this contribution has not really made any radical changes to the osC default version, so it should function as normal. I sort of know this, because I wrote it, but didn't want to give the wrong impression. All the best.
  6. As a test for this 'particular' contribution, Purchase a full price product on your site, when you click the confirmation order button (on your website), you will then be taken to PayPal's website. When PayPal displays their intial page look in the url and you will the parameters pertaining to your order, key across until you see item_price, now change the price to 0.01, now hit enter, PayPal will now reload itself, now look at the amount that PayPal is now requesting you pay for the item you are purchasing. Login and and pay the 0.01, follow the PayPal proccess through and click the continue button, which then returns you to your site. You will be greeted with a thank you msg, now check your account history, according to your website you have paid the full asking price. Now check the order in osC admin, again it would seem that the customer has paid the full asking price. But you know that you only paid 0.01 via PayPal. There is a solution.
  7. devosc

    PayPal_Shopping_Cart_IPN

    Hi susie, to upgrade from v1.4, if possible just copy everything again to the catalog folder with the exception of checkout_process.php, filenames.php, database_tables.php, any of the language files, and admin/boxes/customers.php. v1.5 removed the possibility of a 'Completed' order being stored in the paypal_ipn database table even though it may not actually satisfy the check to see whether it is a vaild payment, i.e do the cart totals match, are the currencies the same, and are the gross totals the same. That revision now enables the ease of further development and/or constraints prior to storing the 'ipn' transaction in the database. Previously in v1.4 when checking to see wether the ipn transaction is unique, it was being automatically stored if it did not already exists. I am not sure why you're not receiving emails, you should get at least one or two, but if you set the notification level to 2 should definately get a DEBUG email. Let me know if you are still not receiving any emails. You could set to Test Mode = 1 in osC admin, and try posting to the ipn.php file using ipn_test.html found in the samples directory, that should at least generate some info, but, if I can recall, it will also populate database tables but you should then be able to delete it as a normal order (just put something in the memo field so you can identify it).
  8. devosc

    PayPal_Shopping_Cart_IPN

    Hi Radders, In /catalog/admin/orders.php the main addition made was to insert an if statement to check whether the payment is via PayPal, this occurs where the ENTRY_PAYMENT_METHOD title is displayed and if it is a PayPal payment then the file, paypal_ipn_order.php is included. The only other two changes made to the admin/orders.php file were for the 'back' button links, which checks if the payment method is paypal and that the $HTTP_GET_VARS['refer'] is equal to 'ipn' this enabled redirecting back to the list of PayPal IPN's rather than the list of orders which is the default case. A search for 'paypal' in the common osC files affected by this contribution will show the insertions made, if that helps any :). If I can recall correctly, apart from admin/orders.php and catalog/checkout_process.php (which has a single line insertion), the rest are just english text, filename and database table names definitions.
  9. devosc

    Automated Auction Process

    Hi Smitty, It is a good module. However there are bits of the symantics that puzzle me. Say if you have a single item for auction and it is displayed on both your site and ebays, I appreciate the bid link back to ebay but I also noticed that one can just purchase the item on your site and just check out - which leaves me puzzled as to how ebay will know that the bidding for this item has ended? Also, not wanting to sound like a sourpot, but it may be prudent if some documentation, rules or notice is mildly made as to how it utilizes and or conforms to ebay's listing policies. Just a thought; but as they say the proof is in the pudding.
  10. Would it be possible to have a html template for each respective php file, for example, index.html, contact_us.html etc?
  11. Sir, it's very smart. Thanks, Greg.
  12. Hi Brian, Thanks for the contribution. I downloaded the STS-1_5 zip file and read the readme file which seemed ok but what I couldn't see was how the html_template actually begins to interact with php and oscommerce. For example in the default index.php file one is required to include the application_top and bottom files. Would it be possible to see how from creating the template, in which I assume one expects to see the $declaration - knowing that that in php the correct reference is displayed, it is then actually implemented as a php file via a sample php file? Thanks, Greg.
×