Jump to content
thirty bees forum

Thirtybees V1.1.x and Mollie 4.0.7 INCOMPATIBILITY


Recommended Posts

We use the payment provider Mollie. This is Prestashop V1.6.x compatible. But there is something wrong with Thirtybees. When we install the latest Mollie module V4.0.7 all order get the sum 1 EUR. total_order is wrong.


Our shop is dependent on the Mollie payment options. It runs since early 2020 with Mollie V3.5.5 but this is rather old and we need to update to the latest V4.0.7.

I tested the module on a clean Thirtybees install (after upgrading core to latest bleeding edge) and total_order is always wrong 😞

I did the same test with Prestashop 1.6.24 and all is fine!

I really hope that some one can have a look at it and dig what the problem causes.

Thank you

mollie total_order.png

Edited by Pedalman
Link to comment
Share on other sites

  • 2 weeks later...
  • 2 months later...

Ok ok

but that is a general answer. Fact is that Mollie V3.5.5 still works with Thirtybees V1.1.x bleeding edge. But the module has been under heavy development since then.

The latest version on Git is V4.0.9.

This I tested with old Prestashop 1.6.24 on my Hetzner hosting with PHP7.4 and all seemed fine.

I tested it under same conditions with latested Thirtybees 1.1.0 that I core updated to V1.1.x and the problem still exists. Orders are listed with a total sum of 1 Eur in orders list. Despite the fact that Mollie test orders showed the correct sum during checkout.

Both Prestashop and Thirtybees were vanilla installs with 1pagecheckout, legal terms off and phone number registration off.


I am with Thirtybees as long as we can but I can tell you that I do not have the nuts and mental power anymore to switch shopping system base. I am very very happy with Thirtybees.

However, I like to know what the culprit here is. Is it fixable?

than you very much


2020-10-29 16_32_01-Bestellungen • thirtybees - Firefox Developer Edition.png

2020-10-29 17_42_59-FA000001.pdf - Firefox Developer Edition.png

Edited by Pedalman
Link to comment
Share on other sites

Well, it's both bug in the module and compatibility issue.

After order is created, mollie updates its price to include fee:

        $order->total_paid_tax_excl = $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_excl));
        $order->total_paid_tax_incl = $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_incl));

The result of this operation is not a number, but object of type \PrestaShop\Decimal\Number

When $order is saved, thirtybees calls standard php function round:


Because the $value is object and not the number, this function return 1. Don't ask me why, it just does. PHP.

In prestashop 1.6 there was different code: 

(float) str_replace(',', '.', $value);

Because str_replace expects $value to be string, it calls $value->__toString() internally, which results in converting object to string.

And thats the reason why the module works on prestashop. Pure luck.

The fix should be done on both sides, I guess.

In module, the lines should be replaced with

        $order->total_paid_tax_excl = (string) $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_excl));
        $order->total_paid_tax_incl = (string) $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_incl));

Note the cast to string. This cast to string is enough to fix the issue. I have created a pull request for this change: https://github.com/mollie/PrestaShop/pull/232

Thirtybees core should be modified as well. Method ObjectModel::formatValue should check value and perform conversion if input it's not number or string 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...
  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...