Stripe Dynamic Payments records slightly incorrect payment amounts with currency conversion

[Juanzo]

Hi everyone,

After switching from the legacy Stripe module to Stripe Dynamic Payments, we started noticing small differences between the amount customers actually pay and the payment amount recorded in WHMCS. This did not happen with the previous module.

Environment:

• WHMCS 9.1.0

• PHP 8.4

• Official Stripe Dynamic Payments module

• “Convert To For Processing” set to “None”

• Stripe settlement currency: EUR

Here is one example:

• Invoice total: 520.00 MXN

• Amount successfully charged in Stripe: 520.00 MXN

• Stripe exchange rate: 1 MXN = 0.0476752 EUR

• Gross settlement amount in Stripe: 24.79 EUR

• Payment amount recorded in WHMCS: 519.98 MXN

• Transaction fee recorded in WHMCS: 32.09 MXN (1.53 EUR in Stripe)

The discrepancy can be reproduced by converting the rounded EUR settlement amount back to MXN:

24.79 / 0.0476752 = 519.976843… → 519.98 MXN

The fee calculation matches too:

1.53 / 0.0476752 = 32.092156… → 32.09 MXN

This suggests that the module may be reconstructing the payment amount from the rounded settlement amount instead of using the original amount charged in the invoice currency. However, we have not confirmed this in the module’s implementation.

In this particular example, the invoice shows as Paid with a zero balance, despite the ledger recording 519.98 MXN against a 520.00 MXN invoice. We have also noticed small outstanding balances on other payments since switching modules.

Has anyone experienced this with Stripe Dynamic Payments?

Is this a known issue, and is there a hotfix or configuration change to prevent it? When the charge currency matches the invoice currency, should WHMCS record the original gross charge amount and convert only the transaction fee?

We would prefer to keep Dynamic Payments enabled, so any guidance would be appreciated.

[Waqas Ahmed Waseer]

Your maths checks out. 520.00 x 0.0476752 = 24.7911, Stripe rounds that to 24.79 EUR, and 24.79 / 0.0476752 gives exactly the 519.98 you're seeing, so the recorded amount looks like it's being rebuilt from the rounded settlement figure rather than taken from the charge itself. A few things I'd do to pin it down and stop it piling up:

 

1. Check Billing > Gateway Log for that payment. It shows the data the module actually received and processed, so you can see whether the amount it recorded came from the charge or from the balance transaction (the settlement side). That's the evidence WHMCS support will want.

 

2. Open a ticket with WHMCS and include the invoice ID, the Stripe PaymentIntent ID, the gateway log entry and your example above. Since the charge currency equals the invoice currency, the expected behaviour is to record the gross charge (520.00) and only convert the fee, so it's worth getting it logged as a bug against 9.1.0 rather than waiting for a hotfix to appear.

 

3. If your Stripe account supports it, add an MXN settlement currency (a payout bank account in MXN). When the charge and settlement currencies match, there's no conversion round trip, so the recorded amount and fee come through without the rounding drift. Availability depends on your Stripe account country, so check Settings > Payouts in Stripe.

 

4. To find the ones already affected, filter Billing > Transactions List by the Stripe gateway since your switch date and compare against invoice totals, or run a quick query on tblaccounts joined to tblinvoices for Stripe payments where amountin differs from the invoice total by less than 1. The small leftover balances can be cleared by adding a manual payment for the difference or crediting it, so the invoices stop sitting as Unpaid or triggering overdue reminders.

 

Also keep in mind that the fee being converted back the same way means your fee reporting in MXN is slightly off too, which matters if you reconcile against Stripe payouts in EUR.