Ugh, php float -> int seems to be busted for that number:

php > $a = 36.8;
php > $b = $a * 100;
php > echo $b;
3680
php > echo (int) $b;
3679
php > echo intval($b);
3679
php > echo round($b);
3680
php > echo (int)round($b);
3680

So... let's use round, i guess

Change 977784 had a related patch set uploaded (by Ejegg; author: Ejegg):

[wikimedia/fundraising/SmashPig@master] Fix float->int bug in Adyen API

https://gerrit.wikimedia.org/r/977784

Change 977784 merged by jenkins-bot:

[wikimedia/fundraising/SmashPig@master] Fix float->int bug in Adyen API

https://gerrit.wikimedia.org/r/977784

Hi @MBeat33 we found the bug and I think we've fixed it.

So it looks like the donor had initially chosen 36.80, but the code to send the payment request to Adyen was actually (un)rounding DOWN to 36.79. Computers do really weird things with base 10 numbers if you're not careful, since their natural counting system is base 2 - and worse, the problem will only show up with a few oddly specific amounts.

The rest of the system was still working with the 36.80 that was originally supplied, so that was the number that made it into Civi. We made a slight tweak to the code to send the payment request to Adyen that should stop it trying to shave a penny off here and there.

Many thanks for the context and the patch, @Ejegg

the problem will only show up with a few oddly specific amounts

that might make for an interesting blog post! like, ask strings to avoid :)