Thirtybees V1.1.x and Mollie 4.0.7 INCOMPATIBILITY

[Pedalman]

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

Edited August 12, 2020 by Pedalman

[Pedalman]

I am still hoping that I can get help on this topic. The module runs fine with PS1.6 but not with TB 1.1. bleeding edge.

 

[Kleijn36]

Sorry to say but there will be no solution. We have the same problem with the API's for Mollie and Sendcloud with TB.

see post:

We where verry happy with TB but have to move forward to an other platform because we are depending on mollie.

[Pedalman]

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

 

Edited October 29, 2020 by Pedalman

[datakick]

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:

round($value, _TB_PRICE_DATABASE_PRECISION_);

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 

[30knees]

{Posted to wrong thread}

Edited November 3, 2020 by 30knees

[30knees]

I confirm that datakick's fix also works for the latest mollie 4.1.1. 🙂

[30knees]

And the new 4.2.1 incorporates datakick's fix. 🙂

[datakick]

On 1/27/2021 at 5:24 PM, 30knees said:

And the new 4.2.1 incorporates datakick's fix. 🙂

That's great