Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Not getting Order Process mail if Total Mismatch of $0.01


mattsc

Recommended Posts

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?

Edited by mattsc
Link to comment
Share on other sites

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.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

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. :(

Link to comment
Share on other sites

Well dammit!!! The very next transaction came through and had another rounding error which kicked it outside of my range of accepted payments. So, I widened up the criteria to be +- $0.50 and will see if that does it. This module confused the ever living ******** out of me! {sigh}

Link to comment
Share on other sites

and what does the log say for that order?

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

I am sorry but I too can't see how your change could affect the processing. That section of code does not change the order status at all! It might be called verifyTransaction but all it actually does is write an order status history record.

In the log, you should get a _notify-validate [IPN] and if the customer returns, a _notify-sync too. Check the responses of these - my money is on their not being VERIFIED.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Depending on the exact order of addition, multiplication by non-integer amounts, and rounding of intermediate results, it's easy to get a penny or two of difference in totals when using different computation methods. If you're getting close to .50 difference, though, something is badly wrong. Generally, most differences end up canceling out (plus and minus), and should not keep adding in one direction. Have you checked that PayPal isn't handling shipping amounts (or tax on it) differently from osC?

Edited by MrPhil
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...