stppbilling setAmount bug

[coedycode]

There's a strange rounding issue with php floats cast to integers.

The line:
$this->options["amount"]["value"] = (integer) ($amount * 100);

If the amount provided = 10.04, the final value becomes 1003

floor(10.04 * 100) also gives 1003

number_format((10.04 * 100), 0, '.', '') seems to be the only reliable solution.

[Westie]

Yes, PHP can be god awful when it comes to its representing floats and that sort of thing.

I'm allergic to number_format however (it just seems too unwieldy) so I'll change it to use sprintf.

14:13 <&Westie> @@ echo sprintf("%.0f", 10.04 * 100);
14:13 < Happycat> 1004

Thank you for pointing that out!

[coedycode]

Nice one, never thought of that solution. I was lucky to spot the problem, 10.04 just happened to be the amount required for forcing an acquireradvicecode 4 response when testing recurring payments. Thanks for the great library btw, really helped me get started with the stapi client, which I'd never used before. Kind Regards, Richard Creek

…

On 2 February 2017 at 14:17, David Weston ***@***.***> wrote: Yes, PHP can be god awful when it comes to its representing floats and that sort of thing. I'm allergic to number_format however (it just seems too unwieldy) so I'll change it to use sprintf. 14:13 <&Westie> @@ echo sprintf("%.0f", 10.04 * 100); 14:13 < Happycat> 1004 Thank you for pointing that out! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADyQ7MRpVLfQiyArEUZAE-txXiZ8AhORks5rYeWXgaJpZM4L1BbK> .

[Westie]

I should really look at the docs again for updates, I haven't looked at this since I was forced to create it as there wasn't any other solution out there for STPP.

I've always found Secure Trading's way of doing this (the Java proxy method) interesting, to say at the least!