Supertex

BTW...what protection do I as a merchant have if someone uses a stolen card here? If someone has a stolen card, all they need is a zip code and this transaction will pass, yes? Nothing authenticating a card's zip code with a site user's payment address? So no protection from charge back... or am I missing something?

TEXT -> CONTENT

@djmonkey1 Seems like I would be able to find more information about using this mod in a v2.3.1 store with SPPC and Quantity Discounts, but I'm not having great luck. The Quantity Discounts mod works great on the front side. In fact, I duplicated it, using one version for Category Discounts, and the other for Line Item discounts. This way, both or either can be toggled on a customer group or customer id basis. Again...works -great- as a visiting customer. The problem comes when I try to edit an order. Let's say I have an order for which neither discount (line or category) is toggled on, for either account or customer group. If I edit the order and add enough product that the criteria for the discount is met, the discount applies itself. Or...if they'd purchased enough to meet one or all of the criteria, once I open it in the editor and change anything, the discounts apply. I can't even adjust shipping without having this happen. I'm at a loss.

Any idea how to omit a method? As in...I have a heavy package that wants to return both Ground Home Delivery, and FedEx Ground. I want to omit FedEx Ground...as in remove it from the methods array completely. I want the methods array to contain ONLY Ground Home Delivery...but Im not sure how to do that.

Anyone else seeing a drastic reduction in price for FCP Intl?

My comments aren't regarding policy...but rather what I see in the code. Now, I may be a little fuzzy, but I do know that special accommodations with regard to the timing of order creation during the checkout process are altogether different for PayPal. There are vast sections of code that are duplicated and run 'a step sooner' just for PayPal. I've not experienced much in the way of payment modules, but that much I know for certain. I've installed (and used) authorize.net, PayPal, and the 'wire transfer' module. Wire transfer creates the order at completion, and the order is posted as "awaiting payment" in the admin list. Authorize.net does NOT create an order number. In their interface...there is only an amount...no correlating order. However, when you return to the store, you'll find an order number. When I dug deeper to see why, it was revealed just how simple the module is (there was no order number being sent because it didn't exist yet), and by comparison, just how complex the PayPal module is. But again...don't take my word for gospel here. @Harald Ponce de Leon is the guy that can answer these questions without conjecture. My main point is to address the stated concerns about why order numbers were changing - and it's because the customer is altering their cart AFTER having chosen PayPal as the payment method. Also...there will be a number of customers that don't ever actually place the order...and when they do that, that order number will be 'occupied' indefinitely...the site will skip over it and continue on generating new order numbers from there. The solve for me was simple: create an order status just for these "temporary" orders, and have your orders.php query exclude that status from displaying normally. You can always specify from the drop-down if you need to view them. There are other issues that you may find more problematic with the PayPal app...like inventory counts being off, for example, because there are 2 opportunities for the site/code to 'complete' the order - one when the customer returns to the site from PayPal, and again when the IPN lands on the site. I find that both MUST be used, because sometimes a customer will click 'pay' at paypal, but will close the browser before they ever return to the site. Can't really rely only on the IPN either, because there are times - fairly often - when the IPN is delayed. On occasion, it's been hours late showing up. And of course in this case, the customer returns to find an 'unpaid' order. Well, when both are used, it just so happens that they CAN land close enough to each other that BOTH try to complete the order (stock decrement, etc.). This happens pretty often. And the only tell-tale sign that you have, is that the site will have sent 2 order confirmation emails, which you can see in the status updates for the order in your store ("customer emailed - green checkmark"). This is a long thread, but go through and read up on it. I've posted numerous times in numerous threads about this...provided images of the backend, database content screenshots. And here's another kind of major issue with PayPal. OSC isn't set up to distinguish between payment statuses as returned by PayPal. Just because a customer completes the payment, doesn't mean that PayPal has approved the payment. I've seen it return 'Pending' payments...not pending order status....pending PAYMENT status. The site can't tell the difference. It processes the order just like PayPal approved the transaction. I've posted numerous details about this too. You can potentially ship what you think is a paid order, only to find out days later that the payment actually was never approved...good luck getting your product back. And now that they are no longer refunding fees ...you as the business owner will get stuck with paying fees based on what the original transaction amount was...not the total after you issue a partial refund. Maybe not a big deal if your average sale is $100, but wait till you have to refund $1500 of a $2000 sale...that'll get your attention. We're moving away from PayPal as fast as my fingers can type. In other news...the Square module seems to be working very nicely...

Yes, generally I believe the order number is created after the transaction is completed. However with PayPal it requires an order number to be generated prior to the transaction completion... As near as I can tell, and perhaps Ponce de Leon can weigh in here, but what you're seeing is entirely the result of dealing with PayPal. For instance, when using authorize.net, there is no order number transmitted to authorize.net. no actual order exists until the transaction is complete. At that time the customer basket becomes an order. When you see the order number skipping, it is because the customer is changing the contents of his cart after reaching either the payment module and choosing PayPal or the final confirmation page. In my case I have altered the code on the orders page not to show orders with the status assigned to PayPal pending orders. So my orders page only shows completed transactions, and there is always a gap in the numeric sequence.

Been a while since I've messed with payment modules, but doesn't entering a CC number this way change the PCI compliance scope for the site?

Sometime I'm going to get up to WA, and when I do, I'm buying you a steak dinner. Thank you.

@kymation Hey Jim, In chasing my need, I've duplicated the (outdated, I know) USPS module I've been using. It installs fine, including the defaults for package dimensions, so I've had partial success with it. However, it seems everytime I try to save settings in the admin, I get "Array" in 'package dimensions' and 'handling fees'. To clone it, I took the working USPS module files and duplicated them and renamed them. There were only 2 files: usps.php for the modules/shipping, and the same for the languages directory. Then I found every 'usps' and changed it to 'usps2'...constants, functions, variables, etc., along with filenames. I've put the old and new in WinMerge and ensured that the only differences are the aforementioned. Any idea what I might have missed? I think these are the functions associated with the problem: // Required configuration functions // USPS Methods. Added by Greg Deeth // Alias function for Store configuration values in the Administration Tool function usps2_cfg_select_multioption($select_array, $key_value, $key = '') { for ($i=0; $i<sizeof($select_array); $i++) { $name = (($key) ? 'configuration[' . $key . '][]' : 'configuration_value'); $string .= '<br /><input type="checkbox" name="' . $name . '" value="' . $select_array[$i] . '"'; $key_values = explode( ", ", $key_value); if ( in_array($select_array[$i], $key_values) ) $string .= ' CHECKED'; $string .= '> ' . $select_array[$i]; } $string .= '<input type="hidden" name="' . $name . '" value="--none--">'; return $string; } // Alias function for Store configuration values in the Administration Tool. function usps2_cfg_multiinput_list($select_array, $key_value, $key = '') { $key_values = explode( ", ", $key_value); for ($i=0; $i<sizeof($select_array); $i++) { $name = (($key) ? 'configuration[' . $key . '][]' : 'configuration_value'); $string .= '<br /><input type="text" name="' . $name . '" value="' . $key_values[$i] . '" size="7"> ' . $select_array[$i]; } $string .= '<input type="hidden" name="' . $name . '" value="--none--">'; return $string; } /** * displays a json string as a list * * @param (string) $cfg_value */ function usps2_cfg_display_json_as_list( $cfg_value ){ $array = json_decode($cfg_value, true); $string = '<ul>'; foreach( $array as $li ){ $string .= '<li><pre>' . $li . '</pre></li>'; } $string .= '</ul>'; return $string; }

Thank you Jim.

Heya Jim, Still working on this much at all, or kinda letting it go? I have kind of a special need that could be solved by having a second USPS module for per-zone application, and rather than trying to rename/duplicate an ancient module...

Well..for anyone else that needs something like this, in create_account_success.php add: $max_order_query = tep_db_query("SELECT max_order FROM " . TABLE_CUSTOMERS . " WHERE customers_id = '" . $_SESSION['customer_id'] ."'"); $max_order_result = tep_db_fetch_array($max_order_query); $max_order = $max_order_result['max_order']; tep_session_register('max_order'); Just below: require(DIR_WS_INCLUDES . 'template_top.php'); And in checkout_shipping.php, add: if (isset($_SESSION['max_order'])) { $max_order = $_SESSION['max_order']; } just above: if (!tep_session_is_registered('customer_id')) { $navigation->set_snapshot(); tep_redirect(tep_href_link(FILENAME_LOGIN, '', 'SSL')); } This fixed it for me...or some part of it did =P

@Johnson Old thread...and pretty simple mod, but I installed this yesterday and today, 2 out of 5 customers so far, have had issues with completing a transaction with far less than the max_value entry in the DB (I currently have it set to 2499.99). One customer's cart was only ~$150, but he was still directed from checkout_shipping to the max_order page. Both were new customers, and had just set up their accounts. But I tested new account functionality immediately after installation, with no issues whatsoever. In addition, other transactions went through just fine. I'm waiting to hear back from the customers on device type, OS, and browser, but I can't understand what might have happened...thoughts?

I have $pkg_val as a session variable. Can I use that in the class constructor, or do I have to make that a global somehow? - and thank you for the reply. I love this community!

Anyone happen to know where the test for whether the shipping module is enabled occurs, and if I can add a condition in that test that would disable the module if the subtotal is over a certain value?

With PayPal, I think we're missing a step with regard to the store's order status. The store is assigning "new order" status to orders that PayPal has not yet approved. To be clear - this has nothing to do with the osCommerce order status level of "Pending", but rather a PAYPAL status of 'pending.' I see it under order comments, and there are entries for both order completion by the customer, and for arrival of the IPN. In most cases this says "Complete," but in some cases shows up as "Pending" (those that show up as "under review" in the PayPal website's account summary, for example). This is later updated via IPN when the payment actually goes through. This has occurred more and more often as business picks up. Here's a screenshot of exactly what I'm talking about: Note the times - payment submitted (customer didnt return to the store, but IPN handled completing the order) at 17:39 on the 21'st...but Payment Status is "Pending." I read that as payment submitted but not yet approved. My site applies Then the next day, the 22nd at 4:36 am, payment approval notification arrives, and Payment Status now shows "Completed." The problem comes in when you have a list of orders in the admin that all appear to be paid orders per the status the store assigns, but one or more of them are apparently hanging in limbo. Is there something that I've missed, that details a way to apply a different status to such orders?

Yep, tried that. I don't think $subtotal exists at this point, and I didn't want to chance screwing something up down the line that might use it so I added this to shopping_cart.php: $pkg_val = $cart->show_total(); tep_session_register ('pkg_val'); and then used $pkg_val in place of $subtotal in the shipping class. Now it works. Thanks Jim :)

Problem was between the seat and the keyboard. function cheapest() { global $is_cont48, $shipping_weight... I never added the bold. Now it works. Just have to figure out what to use for the cart value. I thought maybe: (($is_cont48 != 1) && ($shipping_weight < 0.8125) && ($subtotal < 400.00)) but that's not worked so far.

I actually used 0.8125 first, and it didn't work. The '.8125' was kind of a hail Mary. Any other ideas?

@kymation I wonder if you might have a solution for a couple of things. I'm trying to choose the 'second' USPS quote as default if: 1) international 2) under 13 oz. 3) under $400 My code: $cheapest = false; for ($i=0, $n=sizeof($rates); $i<$n; $i++) { if (is_array($cheapest)) { if ($rates[$i]['cost'] < $cheapest['cost']) { $cheapest = $rates[$i]; } } else { $cheapest = $rates[$i]; } } if($is_cont48 == 1){ $cheapest = $rates[0]; } if(($is_cont48 != 1) && ($shipping_weight < '.8125')){ $cheapest = $rates[1]; //Set default USPS method to "2nd" in array. Add exception for orders with value over $400, or weight over 13oz } return $cheapest; First I added the $is_cont48 test. It works. Then I added the $shipping_weight (which is used elsewhere in the file) but it doesn't work. Regardless of whether the weight is over or under .8125, the test returns true, and I get $rates[1]. Not sure what I'm doing wrong. And what would I use to test cart value? I see $pkgvalue used in the usps module file, but don't I need to make that a global before the class file can use it in a test?

Still having issues with UPS dropping insurance, and this time it's not a customer playing around with navigation...at least not that I can find. I've combed over the UPSXML.log and at least part of this appears to be a hiccup at UPS. I've got log entries for the same customer, 9 seconds apart, that ONLY differ in the negotiated rates price for the various services. Everything else - account info, delivery address, cart value, service options charges, transportation charges, etc., is the exact same. It's just that one quote has insurance added, and one does not. Any thoughts on this?

Apologies...at first I thought this had to do with insurance, but now I'm not so sure. I tried to edit the title but can't, so... I've noticed a few lower than normal UPS quotes lately...one of which was about half what it should be - especially with insurance. So I started digging through the request/response log, located the actual response for the transaction, and I find this: <RatedPackage> <TransportationCharges> <CurrencyCode>USD</CurrencyCode> <MonetaryValue>10.49</MonetaryValue> </TransportationCharges> <ServiceOptionsCharges> <CurrencyCode>USD</CurrencyCode> <MonetaryValue>6.30</MonetaryValue> </ServiceOptionsCharges> <TotalCharges> <CurrencyCode>USD</CurrencyCode> <MonetaryValue>16.79</MonetaryValue> </TotalCharges> <Weight>1.0</Weight> <BillingWeight> <UnitOfMeasurement> <Code>LBS</Code> </UnitOfMeasurement> <Weight>1.0</Weight> </BillingWeight> </RatedPackage> <NegotiatedRates> <NetSummaryCharges> <GrandTotal> <CurrencyCode>USD</CurrencyCode> <MonetaryValue>13.61</MonetaryValue> </GrandTotal> </NetSummaryCharges> </NegotiatedRates> That says this quote "should" be $13.61 (per negotiated rate), and if I go to the site, and enter the customer's address info and weight, I do indeed see $13.61. However, this customer was only charged $7.55. $7.55 Does not show up anywhere in the entire response...I've no idea where it got this figure. I do know that this isn't the only time this has happened. I've caught this same type of thing a few times over the last month or so, and I have ZERO idea what's causing it. Any ideas where to start looking for this, or what it is I'm looking for?

Twice now, my store has had the customer's return from PP and the IPN both land at the exact same time. When this happens, stock is deducted twice. I'm no code whiz, but it -appears- that the catalog/ext/modules/payment/paypal/standard_ipn.php is missing the check that I find in catalog/includes/modules/payment/paypal_standard.php: // Before the stock quantity check is performed in checkout_process.php, detect if the quantity // has already beed deducated in the IPN to avoid a quantity == 0 redirect if ( $this->enabled === true ) { if ( defined('FILENAME_CHECKOUT_PROCESS') && (basename($PHP_SELF) == FILENAME_CHECKOUT_PROCESS) ) { if ( tep_session_is_registered('payment') && ($payment == $this->code) ) { $this->pre_before_check(); } } } I only noticed this because I happened to be watching when a customer purchased a quantity of 4 of one item. We had 7 in stock prior to his purchase. When his order completed, we had "-1". Then again yesterday, I looked at the orders section and found a large order (many line items) in which every line item's stock count was double decremented. I ended up having 4 products with negative quantities. I have the store set NOT to allow checkout while out of stock. And as I already mentioned, this ONLY happens when the customer's return and the IPN land at the exact same time. Also, I feel sure this is in the IPN file, as I have both catalog/includes/modules/payment/paypal_standard.php and catalog/checkout_process.php commented out in order to leave products "active" when stock reaches zero, instead of disabling them completely. I have not yet done this to the IPN file. Since I'm getting negative quantities, it seems the culprit must be the IPN file: //if ( ($stock_left < 1) && (STOCK_ALLOW_CHECKOUT == 'false') ) { //tep_db_query("update " . TABLE_PRODUCTS . " set products_status = '0' where products_id = '" . tep_get_prid($order->products[$i]['id']) . "'"); //} This has only happened twice so far, that I know of. But if it ever slips one past me, my inventory will be wrecked. I could sure use a hand here - I have no idea how this is happening.

Perhaps. However, I don't think I've ever gotten emails when an order is submitted...I wouldn't want any more emails than I'm getting already. So either I saw that option very early on, and turned it off, or 2.3.1 doesn't have that option.