We're working in a 1.9 & php7; detected this issue with paypal suspect fraud (due the difference amount).

All correct in frontend (apply taxes); but in checkout and calculation, magento uses the grand total without taxes.

Actual wrong order calculation:

Product price without taxes + shipping with taxes = total amount to payment

Switch to php5 and calculation is correct.

Some idea?



3 Answers 3



I've created a magento module to solve magento issues with totals calculation for php7. The issues I've experienced in particular were that taxes have been added twice to the grand total for pay with amazon module on the amazonpayments checkout page.


The answer provided by archigrafix in this post (https://magento.stackexchange.com/a/97107/35665) solved my issues - so this is simply the fix packed into a module.



  • it works !!! recommend solution
    – jruzafa
    Jun 2, 2016 at 15:37

I really don't know if this will help in any way, but something to look into.

It is possible that your collecttotals model order is ordering differently, and that tax is being ordered/applied after grand_total

You can test if this is the issue as follows. (note this involves adjusting a core file to get some debug info, please do not try this on a live site!)

Edit the method located in:


and add one line to the method, which will allow you to output the models as they are processed.

public function collectTotals()
        Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_before', array($this->_eventObject => $this));
        foreach ($this->getTotalCollector()->getCollectors() as $model) {
            mage::log($model->getCode()); // <===== ADD THIS LINE
        Mage::dispatchEvent($this->_eventPrefix . '_collect_totals_after', array($this->_eventObject => $this));
        return $this;

ensure logging is enabled.

tail the log file via the console: tail -f system.log

Reproduce the issue via the frontend.

You will get entries as follows in your log (this from a vanilla - you may have other entries)

2015-12-21T05:54:12+00:00 DEBUG (7): nominal
2015-12-21T05:54:12+00:00 DEBUG (7): subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): msrp
2015-12-21T05:54:12+00:00 DEBUG (7): freeshipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_subtotal
2015-12-21T05:54:12+00:00 DEBUG (7): weee
2015-12-21T05:54:12+00:00 DEBUG (7): shipping
2015-12-21T05:54:12+00:00 DEBUG (7): tax_shipping
2015-12-21T05:54:12+00:00 DEBUG (7): discount
2015-12-21T05:54:12+00:00 DEBUG (7): tax
2015-12-21T05:54:12+00:00 DEBUG (7): grand_total

You will see it repeat, so just see where it starts, and ends, should be easy to see the pattern

Note the last two entries above: Tax comes before grand_total. It may be possible this ordering is out of whack, and tax is appearing after grand_total, so grand_total will not have taxes applied.


Ok, so I did not see the referred question actually points to the sorting of the collectotals to be the issue. I suspected that may be the issue, but have not tested this myself in PHP7

There is a solution, but it is not a very nice. Any new extension placed in the store, which inserts models into the collector, would need to be noted, and additionally added to the sorting, else things could go even more wrong. Can be a bit of a maintenance issue going forward.

Simply force the sort order by placing a specific <sort_order> into the totals configuration. You can do this via your own extension, which would only have a config.xml, where you specify the order for each collector.

in the config.xml, have directive as such:


        insert each collector model with a sort directive


Use large gaps between each sorting directive, to allow space to insert additional going forward.

As mentioned, not very elegant, but can solve your immediate problem.

Also note that there are other collector directives in the system, so they may also be wrong/needing adjustment

Check the core sales extension config.xml, and seach for <totals>

There you will find:


There may be others in other extensions, be it core/3rd party

Hope that helps.

PS: I have not tested any of this in PHP7. I know the placing of the sort_order directive works under php5.x

  • Sorting has changed in PHP7, you will have to explicitly define unique sort orders as having multiple identical sort orders (ie level 5 on three different items) can have oddball results. stackoverflow.com/questions/34281113/… Dec 21, 2015 at 7:34
  • I have added an edit to the answer.
    – ProxiBlue
    Dec 21, 2015 at 13:18
  • Thanks ProxiBlue; we will check. We detect some issue with the reindex; in some cases, it reproduces this problem. Go to TAX configuration, save some "no change" and TAX returns.
    – Joan M
    Dec 22, 2015 at 7:39

On Magento 1.6.2 and PHP 7.0.2 I solved it this way:

1 - Created first a local config.xml: Copied /app/code/core/Mage/Sales/etc/config.xml into /app/code/local/Mage/Sales/etc/config.xml

2 - Changed it like this enter image description here

Now it calculates correctly:

enter image description here

  • 1
    You cannot override XML files in the local code pool (only autoloaded PHP classes), so this must be part of the config.xml of an actual custom module. Jan 13, 2016 at 22:12
  • 1
    As explained this was done using a local config.xml. Jan 25, 2016 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.