Jump to content

mattsc

Members
  • Content count

    51
  • Joined

  • Last visited

Posts posted by mattsc


  1. I searched around and didn't see an answer to the question of how to get the packing slip to automatically pull up the print dialog when the page opens. I realize this isn't an OSC specific issue, and I tried to figure this out on my own, but couldn't figure out how to make it happen...

    Basically, when I click on the Orders "Packing Slip" button, and the page loads, I want to automatically have the system print dialog open so i can just hit Print. I know it's a bit trivial as it's just a few keystorkes of mouse clicks to make happen, but it would be a time saver that irritates me every time I have to do it. what do I need to add to packingslip.php to make the page open the system print dialog for me?


  2. 10 hours ago, BrockleyJohn said:

    Your new transaction sample shows the same pattern; the HI customer comes back to the store before the IPN, the Dieg customer is slower - there's an IPN with the same logged time as the sync and then an extra one afterwards.

    Does the IPN history at the paypal end show any further info? You can find it by going to https://www.paypal.com/cgi-bin/customerprofileweb?cmd=%5fprofile%2dipn%2dnotify and then clicking the link in the first paragraph.

    Does that offer any clue as to why another gets sent? Does the second also show as 'original'? Logic suggests that the problem should lie in the first that arrives at more or less the same time as the customer... the processing that's not happening should happen then. I take it that the order gets changed to the proper status but the subsequent stock and email processing doesn't happen.

    I'm still clinging to the theory that there's something up with your code in standard_ipn.php and that doesn't work properly when it has to complete the order. You could try replacing it with the original file from the addon version 4.039 if you don't want to update.

    If, for example, you hit a mysql query error in the download query after updating the order, you would still get the green transaction log in admin, the HTTP 200 return to paypal and the order changing status but without the rest.

    A successful update of the paypal app takes seconds; it is completely automated from the osc admin section. I have run it on 6 live sites and lots of test ones without a failure so I can't comment on how long it would take to unravel if it does go wrong. They've all been BS sites though.

    Unfortunately I don't have access to the paypal account or logs. He reports he rarely (1 or 2 a month) would see a transaction not send the Order Process email with the PayPal Pro HS module. I recently enabled the PayPal Standard module for him, but I've been using it on my site for the last year and have never noticed a transaction not post the Order Process emails. They have duplicate code and the only difference in the stores is the catalog SKUs, and I have a different shipping module (a UPS mod) where as their store is all zones based to calculate shipping costs.

    I'm going to take an hour and see if I can manage to get the PayPal app migrated on my store, and if that works then I'll migrate the other two sites. wish me luck!


  3. 2 hours ago, BrockleyJohn said:

    You only get _notify-synch when the customer comes back to the site.

    It looks to me like paypal  is sending multiple IPNs (they have different ipn_track_id values) ... but actually that shouldn't matter to the order completion and email sending.

    On the double IPN transaction, the first is recorded at the same time as the customer comes back. On the single IPN, it is afterwards.

    It is possible that the order completion processing in ext/modules/payment/standard_ipn.php isn't working properly but that in includes/modules/payment/paypal_standard.php is ok.

     

    My post might have been confusing. I was trying to provide as much info for the transactions which didn't have a problem vs the ones that do. That's why you are seeing the two different IPNs. In both orders, the results came back with "VERIFIED" to the was all. The double IPN records are exactly the same. The ext/modules/payment/standard_ipn.php script is OK. I've verified that with PayPal as well with making sure their callback was successful. The scripts are OK as well because MOST of the time, I don't get the duplicate IPN 10-15 seconds later. The only correlation I've found between the orders that have a problem and those that go through correctly is when there is this duplicated record. Earlier I had an issue where if the order totals differed, I also had the problem (see Not getting Order Process mail if Total Mismatch of $0.01) but I've since put in a variance check so when that issue is encountered, those orders are succeeding now. 

     

    So I've just been working through one issue after another here. I considered adding to the prior post, but this seemed like it was different enough to justify a separate thread.

    I am getting multiple IPN from PayPal, but I don't know why. I would think that would be caused by something on the host failing but the PayPal integration tech guy tells me they are getting a success 200 reply so I'm a bit at a loss to explain why they are making the second attempt. 

    I have other instances where the success happens at different times, so it's not always that _notify-sync and _notify-validate [IPN] occur at the same time or at different times... so that's not it either.

    image.thumb.png.daf301ac1f99942fed1341f627b06153.png

     

    1 hour ago, BrockleyJohn said:

    Digging through some old code, I think that early versions of the  app had no order completion processing in standard_ipn.php

    I think your best approach is to update the app and sort out any issues that arise. There is a lot of change between your version and the current (see attached)

    paypal-app-versions.png

    No I -=AM=- getting Order Process email notifications for MOST of the PayPal Standard transactions. Just not all. I'm unsure at this point how to even attempt to debug this further as I'm not seeing any semblance of a pattern. Maybe I need to tell my client I need to take the website offline so I can update the PayPal module. They won't be happy about that in the least, but if that's really down to my last option to try and fix this then maybe that's what will need to be done.  I am seeing a note in there about 2.3.4  BS compatibility. The timestamp is right around the time when I was doing the coding for the site, so maybe those changes not being there was why my attempt at updating failed the last time I tried to update the PayPal app code. That "lot of change" is what is making me nervous tho. I'm not sure how much effort or time it'll take to update the PayPal app, or how much time it'll take to "sort out any issues" once the changes and complete. I'll just have to present it as an option to them and let them make the call as to if it's a big enough of a deal to them or not.


  4. 15 minutes ago, 241 said:

    may be a setting in your actual paypal account or an issue with the PayPal App version 4.

    Have you tried updating the App to above version 5 as the App is at v5.0.18

    I would expect a setting on the paypal account would cause ALL orders to fail if something were set wrong... and with duplicate entries a I would think it would have to be something on the server, tho what, I do not know. There doesn't seem to be ANY commonality between the orders that "fail" with 3 IPN records and thus emails not being sent and inventory not being updated, and the ones that "succeed" with only getting the 2 records in the log.

    I have not updated the PayPal app. I don't remember what the problem was that I ran into when I tried to do it, as it was a while ago (about a year) when I attempted updating the PayPal app portion of OSC. Part of my problem is I no longer have an good means of creating an exact copy of the site in a development environment. So, any changes are made on a live system. I know, it's horrible, but it is what it is... so I'm VERY careful about the changes made, and considering more than half of all sales go through PayPal, I'm VERY pensive about making another go at doing the update.


  5. Running on 2.3.4BS PayPal App v4.039 here and I'm running into a problem with the PayPal Standard IPN module. For whatever reason I can not determine, occasionally I'm getting 3 messages logged to an order. Whenever I only get 2 updates, everything works as expected. All the emails are sent, stock is deducted from inventory, all is good. When I get 3 messages logged to the order from PayPal things go downhill. None of the emails are generated and stock isn't removed from inventory. I'm at a loss as to what the cause of the 3 messages being logged is, or why some of the PayPal Standard IPN orders only get "_notify-validate [IPN]" entries logged. Here is an example of where I get the problematic 3 entries in the order status, 12 seconds apart:
    image.png.0e008106098be469c6edec008ee094e8.png

    Verses a "normal" transaction where I only get 2 log entries from PayPal which are all being processed 1 second apart:

    image.png.24154a57f5d8dd4aedef25a9b4639f78.png

    I'm not seeing anything weird in the PayPal log content wise other than it showing either the 2 or 3 entries in the log:

    image.thumb.png.595b4089c7b090404d84ec1618ecd19d.png

    The response code every time however is successful with a "VERIFIED" reply:

    image.png.e7f080984669b965739fe573e5e99fe4.png

    and the duplicate _notify-validate [IPN] entries being exactly identical and also "VERIFIED" as the reply:

    image.png.67b69585429c7c1dfc61d4ecc72ebcc6.png

    I tried asking a PayPal integration engineer to look at their logs to see if there was anything odd, and he said there was not. His only thought was "maybe your system is timing out" but if it is, I'm unsure what I could change other than possible the php.ini default_socket_timeout value, which is current set to 60 seconds.

    I'm just running into one problem after another after another with the PayPal Standard IPN module here and can't figure out why it's working fine most of the time, but occasionally I get these three logged IPN entries, and the order somehow isn't completing with Order Process emails not going out and the stock not being updated.

    I am TOTALLY stumped here and have no idea where else to look. I've eat, slept, breathed, and died in the /include/modules/payment/paypal_standard.php/order_process.php, and /ext/modules/payment/paypal/standard_ipn.php files.

     

     

     


  6. Running into an issue where the weight of a bundled product sku is using the sum of the individual components for the weight. This is resulting in a weight which is too high and is messing with the shipping module calculations. Looking through the code tho, I don't see where I might be able to use an override for the bundled product given weight.

    Example product 1234 has three bundled products of X, Y and Z. The weights for each is given as say 10lbs each. In fact, the bundled products all combined are say 24lbs.  In the products record there is a given weight of 24lbs, but this is being ignored, and it's taking the XYZ weights and adding them all up for the total 30#... The result is that the shipping calculation is then trying to use too heavy of a weight so the shipping calculation is off. My expectation is that given the bundle has a specified weight, it should be using that instead of adding everything in the bundle up.

    The only area in the code I think this might be coming from is in the shopping_cart.php class, where in the calculate() function, in the main while loop there is this on line 417:

    $this->weight += ($qty * $products_weight);

    where, what I would LIKE for it to do instead would be in the product is a bundle, to not sum up ever product weight for the bundle, but just use the specified weight. I'm not seeing anything anywhere else that looks like it might be causing what we are seeing in the shipping module for the shipments total weight of the cart.
     


  7. So far, the change is working flawlessly. I'm going to rewrite it somewhat to use a variable which can be set in the admin panel for how wide of a +- margin to allow. I'm still not sure why when I was testing for a variance of $0.02 it was occasionally still failing. All of the mismatch amounts seem to only be off by a rounding error of $0.01, so the $0.02 window SHOULD have worked. I'm going to at the very lease narrow it down to testing for only a $0.05 variance... but seems like this change resolves the problem.


  8. My uber ugly hack just to test if I'm in the IF loop at all or OSC Error is coming from somewhere else outside of paypal_standard.php looks like this now, to try and get it to be similar to paypal_pro_hs.php

              $invoice_amount = $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']);
              if (    $pptx_params['mc_gross'] != $invoice_amount ) {
                if ( ($pptx_params['mc_gross'] >= $invoice_amount - .50) &&
                     ($pptx_params['mc_gross'] <= $invoice_amount + .50) ) {
                    $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' .
                            tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' .
                            $invoice_amount .
                            ') but is within 0.50 of expected total, so still approving order to completed order status';
                } else {
                    $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' .
                            tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' .
                            $invoice_amount
                            . ') and is NOT within acceptable +- acceptable total difference.';
                }
              }

    I know, I know... It's ugly!!! Adding the "and is NOT" bit there, is to at least verify if the log says totals mismatch, and I don't see that text, then somehow I'm getting it someplace else... not that I can FIND where, but after I made the last change to the $0.50 I still had one kick out which made me doubt my IF block logic.


  9. Phil: I am getting a rounding error yes, and it's only showing as $0.01 in the emitted text, but I'm also dealing with 8 different currencies so I'm playing it safe for now with increasing it to $0.50 just as a method of testing to see if I'm having problems with that IF block, or if the OSC Error is coming from somewhere else that I can't find. We hand PayPal an amount with the total is all, and calculate shipping ourselves. No tax, as the company and factory are both offshore and product ships from overseas... Nobody is stressing out about the order being off by $0.01. That's not a big deal. What's a PROBLEM is the factory relies on the email to start the orders, and the packers and shippers then get the packing slips from the gals in the office who use email as the trigger to start an order and verify inventory levels and order replacement inventory or start production on parts based on sales.  Believe me, it is NOT ideal, but it's how they work... I can't dictate workflow. I'm just the bits pusher here. ;)

    John: The response is coming back as VERIFIED for these rounding error transactions. Every time.

    Response
    VERIFIED

    So... that's not it. Like I said, I used to have this also happening with the Pro Hosted Solution code.  I changed the OSC Error to OSC Warning in my test for the rounding error, and the problem stopped. Leaving it as an OSC Error, and for whatever reason, the email Order Process messages never go off inside of checkout_process.php. Because it's not making it into the before_process function, I'm thinking it ALSO means that inventory isn't being deducted when that happens. Plus the Low Stock emails don't get sent to the gals in the office. So, this is a bit of a big deal with trying to get fixed. I guess I don't even really CARE as to why having that OSC Error text in there is causing it to not function so much as just trying to make sure that the change to OSC Warning actually occurs inside of the IF block and the rounding error is successfully ignored.

    It's also not like this IF block  in paypal_standard.php is all that different from paypal_pro_hs.php. So while my solution wasn't a direct copy/paste, it ain't THAT different! My solution of changing the "OSC Error" to "OSC Warning" seems to be working, so long as it's not -=SOMEHOW=- getting that text block from somewhere else in the code. I failed to restart the webserver after my changes so I thought maybe, somehow, one of the apache worker threads was using a cached version of the old PHP... I dunno. I'm sorta grasping at straws here. Waiting for another transaction to come through with the rounding error is the painful process for me here as I can't force it to happen. The cached thread is a stretch, I know! I can't figure out how the order manged to use the old code however as it came in 30 minutes after I'd made the change. I haven't had any orders come in with the rounding error since the apache service restart however. The office never told me that they were "sometimes not getting the emails" before, so I suspect the same issue has been happening a while now, but now that I DO know about it, I have to fix it.


  10. 7 minutes ago, BrockleyJohn said:

    You're changing the comment here depending on the order value discrepancy size but I don't think it's going to make any difference to the email - this verify method doesn't return anything.

    I think you're always going to get an order status change and email if Paypal sends through a VERIFIED result.

    Have a look in the log in admin and see what happened for the order with the discrepancy.

    I made the change, and while I can't explain WHY it works, it did. I very luckily had an order come in about 20 minutes after my change, and the Order Process email DID go out successfully, and had my change showing in the result:

    Quote
    06/19/2018 08:55:34 PayPal [Transactions] Transaction ID: 0G05504364773760M
    Payer Status: verified
    Address Status: confirmed
    Payment Status: Completed
    Payment Type: instant
    Pending Reason: 
    OSCOM Warning Total Mismatch: PayPal transaction value (102.10) does not match order value (102.09) but is within 0.02 of expected total, so still approving order to completed order status
    Source: IPN 

    I REALLY don't understand why changing the "OSCOM Error" test to "OSCOM Warning" makes a difference, but for whatever reason it did. The payment modules are a bit perplexing to me with how they actually work. The rest of the OSC codebase largely make sense (or OK, can understand it about as well as any other huge open source project) with how it all works... I completely agree that the change doesn't make any sense. I've dug around through:
    /ext/modules/payment/paypal
    /includes/modules/payment/paypal_pro_hs.php
    /includes/modules/payment/paypal_standard.php
    /includes/classes/payment.php
    /checkout_process.php
    as well as general greping my way through the whole codebase... to no avail! I do have to make a status change in the paypal_pro_hs.php as you recommend:
     

    // BOF Bug: 143 - approve orders even if amounts only slightly differ
              $invoice_amount = $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']);
              if ($tx_payment_status == 'Completed') {
                if ($tx_amount == $invoice_amount) {
                  $new_order_status = (OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID > 0 ? OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID : $new_order_status);
                } elseif ( ($tx_amount >= ($invoice_amount - 0.02)) && ($tx_amount <= ($invoice_amount + 0.02)) ) {
                  $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' .
                    tep_output_string_protected($tx_amount) . ') does not match order value (' .
                    $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) .
                    ') but is within 0.02 of expected total, so still approving order to completed order status.';
                  $new_order_status = (OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID > 0 ? OSCOM_APP_PAYPAL_HS_ORDER_STATUS_ID : $new_order_status);
                } else {
                  $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' .
                    tep_output_string_protected($tx_amount) . ') does not match order value (' .
                    $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')';
                }
              }
    // EOF Bug: 143 - approve orders even if amounts only slightly differ

    where I am setting $new_order_status to be the same as if the amounts are equal, but there's nothing like that in the paypal_standard.php module. Becasuse the verifyTransaction function is a void with no return, I'm mystified how it's working at all!!! Clearly something -=IS=- working, I lliterally just don't grok ******* how! I admit, it's a fugly fix, and I hang my head in shame as a dev! I've spent months of my life in the OSC codebase, and have practically committed to memory how it all works, but the PayPal methods are beyond my grasp at understanding. :(


  11. 23 hours ago, mattsc said:

    I'm running 2.3.4BS here, and I'm trying to figure out something with how Bundles and the PayPal payment methods interact, in particular the function reduce_bundle_stock which is added into checkout_process.php

    The reduce_bundle_stock function declaration, as I understand it, would be needed in the PayPal payment methods as well, I would think. Wouldn't it make more sense to add this function into the include/functions/general.php location? Or is there some inheritance I'm not seeing here where the function declaration (and code) is somehow accessible in the other checkout methods and so I don't need to move it into general.php to still be successfully called in the paypal payment? I know there's some interesting ways that the alternate payment methods interact with checkout_process.php but this one has me confused.

    The concern I have is if I add the new reduce_bundle_stock function into each payment method, wouldn't I then get get a function conflict between checkout_process.php and the two paypal_standard.php and paypal_pro_hs.php payment methods?

    I tried putting the function into general.php as a a new function called tep_reduce_bundle_stock, and modified the function to call the function by this new name. With this change however, my customer is saying they are no longer receiving the confirmation email, but the orders table is being successfully updated by PayPal when the checkout process completes. I know that general.php is being loaded as there are other tep_* functions in paypal_standard.php which are successfully being called. I can't see why my change of moving the reduce_bundle_stock function from checkout_process.php into general.php would cause the confirmation emails to not go out tho.

    Checkout via standard methods are working and the bundle stock is being reduced in inventory correctly with the function moved to general.php, but for some reason things aren't working correctly when paypal_standard.php checkout method is being used. I'm a bit at a loss as to why the order process email isn't going out. I've attached the relevant changed files here, in case anyone might be able to see if I'm doing something stupid and just need another set of eyes on it to tell me where things are going off the rails.

     

    Well, I've got a little bit more information now. It seems that they ARE receiving SOME of the Order Confirmation emails. It looks like the ones they aren't receiving are when the order comes in via PayPal Standard and there is an order mismatch of $0.01, so this may not be related to the Bundled Products mod after all. I started a thread on that specific issue here:

    I'm still not sure if that's the reason why they aren't receiving all of the Order Process emails, but that's my best guess as to why currently... I'm not seeing any other difference between orders that come in and the Order Process message does go out, and the ones where it doesn't.


  12. With the PayPal Standard payment processing, if I get an Order Total mismatch of 0.01 I'm not getting the Order Process email notice. I'd like to disregard this error condition if the order total is within 0.02, and still get the Order Process email notice. With reading through the code tho, I can't see why this mismatch isn't allowing the emails to go out. This appears to be the only difference between orders where I receive an order process message, and those which I do not.

    I've made the following code changes, but because these Order Total mismatch differences happen so infrequently, I'm not sure if my change will work or not. Here's what I changed in paypal_standard.php:
    Before:

    if ( $pptx_params['mc_gross'] != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) ) {
      $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' . tep_output_string_protected($pptx_params['mc_gross']) . '
      ) does not match order value (' . $this->_app-formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')';
    }
    

    After:

    if ( $pptx_params['mc_gross'] != $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) ) {
      if ( ($pptx_params['mc_gross'] >= $total['value'] - .02) && ($pptx_params['mc_gross'] <= $total['value'] + .02) ) {
        $comment_status .= "\n" . 'OSCOM Warning Total Mismatch: PayPal transaction value (' .
          tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' .
          $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) .
          ') but is within 0.02 of expected total, so still approving order to completed order status';
    } else {
        $comment_status .= "\n" . 'OSCOM Error Total Mismatch: PayPal transaction value (' .
          tep_output_string_protected($pptx_params['mc_gross']) . ') does not match order value (' .
          $this->_app->formatCurrencyRaw($total['value'], $order['currency'], $order['currency_value']) . ')';
      }
    }

    I made a similar change to the paypal_pro_hs.php code a LONG time ago, but don't remember if I made any other changes to get the Order Process messages to send. I can't seem to find anything anywhere that would otherwise prevent the email to go out however. Does this change look reasonable, or am I missing something else I would need to modify to get the messages to send on payment completion?


  13. I'm running 2.3.4BS here, and I'm trying to figure out something with how Bundles and the PayPal payment methods interact, in particular the function reduce_bundle_stock which is added into checkout_process.php

    The reduce_bundle_stock function declaration, as I understand it, would be needed in the PayPal payment methods as well, I would think. Wouldn't it make more sense to add this function into the include/functions/general.php location? Or is there some inheritance I'm not seeing here where the function declaration (and code) is somehow accessible in the other checkout methods and so I don't need to move it into general.php to still be successfully called in the paypal payment? I know there's some interesting ways that the alternate payment methods interact with checkout_process.php but this one has me confused.

    The concern I have is if I add the new reduce_bundle_stock function into each payment method, wouldn't I then get get a function conflict between checkout_process.php and the two paypal_standard.php and paypal_pro_hs.php payment methods?

    I tried putting the function into general.php as a a new function called tep_reduce_bundle_stock, and modified the function to call the function by this new name. With this change however, my customer is saying they are no longer receiving the confirmation email, but the orders table is being successfully updated by PayPal when the checkout process completes. I know that general.php is being loaded as there are other tep_* functions in paypal_standard.php which are successfully being called. I can't see why my change of moving the reduce_bundle_stock function from checkout_process.php into general.php would cause the confirmation emails to not go out tho.

    Checkout via standard methods are working and the bundle stock is being reduced in inventory correctly with the function moved to general.php, but for some reason things aren't working correctly when paypal_standard.php checkout method is being used. I'm a bit at a loss as to why the order process email isn't going out. I've attached the relevant changed files here, in case anyone might be able to see if I'm doing something stupid and just need another set of eyes on it to tell me where things are going off the rails.

    There is also a function added for LowStockCheck, where if inventory falls below a threshold, then an email goes out to alert that inventory may need to be re-ordered.

    Unfortunately I'm working with a live system that I'm modifying, so I can't really experiment TOO much here. I've not found a way to (at least without great efforts) replicate the entire store locally for debugging and testing which would FAR rather be my preference, so I have to just make a best effort to making sure I don't knock the store offline or do anything that would confuse customers and/or block checkout.

    general.php.new

    paypal_standard.php.new

    checkout_process.php.new


  14. OK so, a bit of a *********** but I've got things mostly sorted out on the site now.

    Pro Hosted Solution will never be covered by Seller Protection. Don't ask me why, but that's their policy.

    So, I had them disable the PayPal account payment method in the hosted solution, and that now only has the hosted credit card payment method. I spun up "Payments Standard" to accept payment via a PayPal account, and that is (as expected) being covered by Seller Protection. The screwy thing being, we can still accept a credit card payment via that payment method even if the person doesn't have a PayPal account, but PP doesn't seem to recognize a distinction there... Plus, paying via that method is a PITA and tends to end up with the funds locked up in escrow for a few weeks. Bleagh!

    It seems that you can also not have Pro Hosted enabled and Direct Payment both enabled at the same time. Also, Direct Payment then gives the site direct access to the customers credit card information, and pushes all of the PCI compliance onto us, and is ALSO not covered by Seller Protection. So, Pro Hosted it is, and we just have to manage our fraud settings and fraud exposure level ourselves. That ******* sucks, and totally baffles me, as it SEEMS like the payment processor and the credit card agency would have fraud prevention services there. There are 3D Secure settings, but that seems to be about as much control as we have over potential fraud, and our exposure is 100%... so a lot that the 3% payment processing charge gets us there! {rolls eyes}

    I also understand how and why the hosted connection is done inside of an iFrame. This is so we never have access to the credit card information as it's all encapsulated in the iFrame... and it just hands us the result code of the transaction. Makes perfect sense after I thought about it a bit.

    So, at least the PayPal account checkout flow is covered by Seller Protection. Thinking I might try to wrap some sort of "PayPal Buyer Protected" language around the PayPal checkout path to try and direct people over to it, but that's a business decision above my paygrade. :) LOL


  15. Howdy John,

    The marketing / business development droid I've been having to deal with at PayPal has finally put me in touch with one of their Merchant Integrations team members. His initial suggestion was to enable "Payments Standard" which I've done, so checkouts via that method will indeed be covered by Seller Protection now.

    They just made a change on the backend for our PayPal account, such that the PayPal account info is no longer showing inside of the iFrame. The frame that PayPal returns now only offers the credit card payment method. So on the payment elections page I now can have a paypal payment election, and a separate credit card payment election. Previously, the Hosted Solution payment method returned both, which was confusing customers... which is why we initially moved away from Payment Standard, not aware that doing so meant that even payments made through a PayPal account were STILL not being covered by Seller Protection. The change to Hosted Solution not showing in the paypal account method any more should resolve this finally.

    Any means of payment not contained inside of an iFrame, would mean that we would have access to the credit card info. That would push a much higher level of PCI compliance onto us, which isn't desired.

    There is also the "Direct Payment" module for the PayPal v4.039, but installing and configuring it, doesn't seem to have any impact. No additional payment election is showing on the checkout payment page, and I'm not seeing any errors in any of the log files, so I'm confused as to what it's doing.

     

    As to Express, when I enabled this early on in our implementation testing, we were getting a checkout button in the cart, and it jumped straight from the Cart to the Order Confirmation page, bypassing the payment method elections (makes sense) but also bypassed our Shipping Method election page, and allowed checkout without having elected (or had added to your payment) the charges for shipping. Could be we have something misconfiguration here, but for whatever reason, we were not getting Shipping Method election.


  16. Digging through the HTML, it turns out that the site is getting an iframe from PayPal in the Hosted Solution checkout app. I'm guessing this is coming in from the sourced javascript and is why I wasn't seeing it when I searched through all of my OSC sourcecode. So, looks like I can't tell PayPal to disable iframe support for my account. I don't know if updating to the PayPal 5.018 app would be safe with my 2.3.4BS install and would be the way to go with trying to get Seller Protection enabled, while still forcing customers through the shipping method selection so that shipping charged wouldn't be bypassed by Express Checkout in the cart. This is so frustrating! :(

    PayPal-iframe.png


  17. Running a customesed OSC install of 2.3.4 BS, and I'm having a problem with PayPal transactions not being covered with Seller Protection. I'm  using the Hosted Solution module in the PayPal App v4.039 so that I can accept both PayPal and Credit Cards. Trying to find a resolution to this, the Business Development agent assigned to my account has informed me with the following:
    "I reviewed your account and see you are unfortunately not getting seller protection on the PayPal orders as PayPal is hosted via the PayPal pro hosted iFrame. This is not caused by anything you are doing wrong, it’s an issue when PayPal is hosted via the iFrame."

    I did a grep through all of the source, and I'm not seeing any frames or frame tags. Perhaps I'm not understanding what the issue is however and that the PayPal 4.039 version of the app/plugin is using frames in a means I'm not seeing here. His recommended solution is that I switch over to Express Checkout. I've looked into this in the past, but when I did this the shipping module was being bypassed. My shipping calculations are rather complex as the business is based out of Thailand and I have 4 different shipping methods and ship world wide. I've attached a screenshot of my PayPal configuration pages for the Hosted Solution and Express Checkout tabs, as well as my checkout screen where it shows the PayPal app loaded and offering both checkout via PayPal, or a provided Credit Card.

    I am getting Seller Protection when I use the Payments Standard module, so this seems to be solely related to Hosted Solution. I don't know how to use PayPal Express which won't also bypass the shipping methods. I've been experiencing some fraud lately and this problem with Seller Protection not being covered is no longer acceptable. I have no idea what to do at this point to get Seller Protection, and switching to Standard only isn't a viable option either as I have too many customers who want to pay by credit card and don't want to (knowingly) use PayPal for their transaction.

    I'm not really sure what path to take to go forward and could really use some advise or help here!

    Screenshot from 2018-06-01 08-47-59.png

    checkout.png

    Screenshot from 2018-06-01 09-03-04.png


  18. @@mattsc

     

     

    That is the one.... each product_id in your store will be associated with a customers_group_id

     

    To over simplify....

     

    Product id 1 group id 1 = customers_group_price $1.00

    product id 2 group id 1 = customers_group_price $2.00

     

    product id 1 group id 2 = customers_group_price $0.99

    product id 2 group id 2 = customers_group_price $1.99

     

    Make sense?

     

    Mostly. I still don't know what to ake of the _cg_1 and _cg_2 tables. The products_groups table is straight forward enough... I just can't quite figure out the interaction(s) with the other two tables of pricing mystery. :)


  19. I'm running the greasemonkey version of SPPC with the BOOTSTRAP - SPPC 2.3.4 BS GOLD - v1.1b release. I'm doing a bulk price update of 5% across the board. For updating my pricing for my standard retail price, this is easy... just a quick db query of:

    update products set products_price=products_price * 1.05

    However, for updating my pricing for all my customer groups (I have 6) I'm a little bewildered as to what to update!

    I have three tables here:

    products_group_prices_cg_1
    products_group_prices_cg_2
    products_groups
     
    All of them SEEM to have pricing info in them. I have no idea what needs to be updated tho. I'm unsure if the cg_ tables are still in use, to be honest. It might just be a holdover from prior work... but I have to say after grepping through the code I am still seeing references to the cg tables. The products_groups table SEEMS like it's the table I need to update:
    select * from products_groups order by products_id limit 12;
    +--------------------+-----------------------+-------------+
    | customers_group_id | customers_group_price | products_id |
    +--------------------+-----------------------+-------------+
    |                  1 |             2058.0000 |          39 |
    |                  2 |             1958.0000 |          39 |
    |                  3 |             1858.0000 |          39 |
    |                  4 |             1850.0000 |          39 |
    |                  5 |             1900.0000 |          39 |
    |                  6 |             1921.0000 |          39 |
    |                  1 |             1675.5000 |          40 |
    |                  2 |             2000.5000 |          40 |
    |                  3 |             1950.5000 |          40 |
    |                  4 |             1900.5000 |          40 |
    |                  5 |             1850.5000 |          40 |
    |                  6 |             1564.0000 |          40 |
    I THINK I would just need to do a similar update of products_groups of:
    update products_groups set customers_group_price = customers_group_price * 1.05; 
    but, I'm TOTALLY not clear on what to make of, or what to do with, those mystifying products_group_prices_cg_1 and products_group_prices_cg_2 tables???

  20. @@kymation: To answer your first question, yes I patched the admin/modules.php. I don't have the compatibility addon installed. Not sure what that is. I'm running Gold not Edge, so that may be related to that. From what I can tell at this point with further debugging, which is basically me stepping through the whole chain of function calls, I seem to be having a problem with the XML Class. The call into XML_unserialize is returning an empty array (verified with print_r and var_dump). Debugging into the xml.php in the XML_unserialize function, the call into $xml_parser->parse($xml) returns empty. 

     

    The problem from what I can tell is coming up here:

            function parse($data){
                    $this->document = array();
                    $this->stack    = array();
                    $this->parent   = $this->document;
                    return xml_parse($this->parser, $data, true) ? $this->document : NULL;
            }
    
    

    The function is fed in good XML which is what I've gotten back from UPS. This data is the XML stream received from the call to UPS, or by using the dummy xml test file, both call into _parseResult($xmlResult), which then calls XML_unserialize, and that's where the wheels come off. $xmlResult is valid, but XML_unserialize returns with the empty array.

     

    I did strip the & reference chars from the class due to the fatal "Call-time pass-by-reference has been removed" errors. Maybe I stripped one too many. Ah HAAAAA!

     

    Looks like that was the issue. I got over eager on my nuking of & characters. I'm getting quotes back now, finally! I've got a currency conversion issue to deal with, but THAT I can sort out.


  21. I have the 1.5.1 version installed, and it's pulling up correct rates in the return XML which I can see in the log file. I'm not getting rates / options to select to show up on the checkout_shipping.php page however. By all accounts it looks like the module is running and working, just not showing up as a selection for the shipping method selection.

     

    Anyone??? This remaining issue is the final part of taking my store live. I'm getting valid XML back with a number of shipping quotes. The selections just aren't making it to the UI. I'm totally at a loss as to how to further figure out what's wrong. I've poured through the code and am apparently just being daft or something.


  22. I have the 1.5.1 version installed, and it's pulling up correct rates in the return XML which I can see in the log file. I'm not getting rates / options to select to show up on the checkout_shipping.php page however. By all accounts it looks like the module is running and working, just not showing up as a selection for the shipping method selection.

     

    I'm running v2.3.4BS GOLD so I'm not certain if that would have anything to do with it or not... but I've been racking my brain on this one for a few days and have to admit I'm somewhat baffled as to why it's not working completely to the UI.

     

    OB debugging checks:

    • Yes, the module is enabled, thus the correctly formatted XML query in the log
    • Yes, all my ups creds are correct, thus the correctly formatted XML response in the log
    • Yes, the shipping method option sort and display options are enabled (from a SPPC interaction)
    • My other two shipping methods are showing up and working correctly, it's just the UPSXML shipping module results which aren't showing up (see attached screenshot)
    • I've tried using the example_response.xml file also, just to see if there might be something with the returned XML that's causing my problems, no joy there either. Still not getting a result to the user selection in checkout_shipping.php

    Any insights into how to further debug or what could possibly be wrong here as to why I'm getting good rates back but it's not making it to the checkout_shipping.php selections would be greatly appreciated!

    post-341041-0-84060100-1485721984_thumb.jpg


  23.  

    I'm running into an issue with SPPC and the tep_db_check_age_specials_retail_table function. When a special is created, on the first time the category that product exists in is is visited it generates a 1062 Duplicate Entry SQL error.

     

    1062 - Duplicate entry '1600' for key 'PRIMARY'

     

    insert into specials_retail_prices select s.products_id, s.specials_new_products_price, s.status, s.customers_group_id from specials s where s.customers_group_id = '0'

     

     

    Found the problem. Somehow I ended up with a duplicate product_id in my specials table. I wiped the specials table, and now when adding specials I don't have a duplicate anymore, so it's resolved now.

×