UserPoints wallet deduction issue when balance exactly matches file price

[ibrahim]

Hello,

I found an issue in jDownloads when UserPoints is enabled and the user wallet balance is exactly the same as the file price.

Example:

Wallet balance: 4.00
File price: 4.00
User tries to renew an expired download
The file may download, but the wallet deduction can fail or the user may incorrectly receive a not-enough-points message.

If I add 0.10 extra credit, the same download works correctly and leaves 0.10 in the wallet.

The relevant file is:

/components/com_jdownloads/src/Helper/JDHelper.php

The current comparisons use floating-point values directly, for example:

$sum_aup_points <= $profil->points

and:

$profile->points >= $price

Using rounded values fixes the issue:

round((float) $sum_aup_points, 2) <= round((float) $profil->points, 2)

and:

round((float) $profile->points, 2) >= round((float) $price, 2)

There is also another point worth checking. After calling:

\UserPointsHelper::newpoints(...)

the code returns true directly.

If UserPoints rejects the deduction, jDownloads may still allow the download without reducing the wallet balance.

It may be safer to verify that the deduction was successful before returning true.

I tested the rounded comparisons locally together with a small fix in UserPoints, and the exact-balance case worked correctly.

Best regards,

[Arno]

Hi Ibrahim,
thanks for the detailed report, this was a valid edge case.

We have now hardened the UserPoints flow:

• wallet/price comparisons are now handled with 2-decimal precision to avoid floating-point boundary issues (for example balance 4.00 vs price 4.00)
• deduction handling now includes a defensive failure check so explicit deduction failures do not pass silently
  

This fix is already implemented and will be included in the upcoming jDownloads 4.1.5.

Edit:
I'll send you a preview version via PM for you to test. I don't currently have UserPoints set up to test it.