Change money/amount properties from int to decimal - #11
Merged
Merged
Conversation
Every monetary field across the request/response models (Amount, Fee, AppFee, MerchantFee, AvailableBalance, AmountRefunded, etc.) was typed as int, silently truncating fractional currency values returned by or sent to the API. Change them to decimal throughout, in both the external DTOs and the public domain models, and fix the one Fee field that was float for the same reason. Fields that only look money-shaped but aren't (pagination counts, retry-strategy config values, charge counters, IDs) were left as int. This surfaced a real bug: several *Validations.cs files only had an IsInvalid(double) overload for numeric checks, so once a validated field's static type became decimal, `IsInvalid(field)` silently rebound to IsInvalid(object) (decimal boxes to a non-null object) and stopped flagging non-positive amounts as invalid. Added matching IsInvalid(decimal) overloads (and IsInvalid(int) where needed to resolve now-ambiguous calls from plain int parameters) everywhere the double overload existed, restoring the original validation behavior. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Amount,Fee,AppFee,MerchantFee,AvailableBalance,AmountRefunded,ChargedAmount, settlement/statement amounts, transfer limits, bill-payment min/max, etc.) was typedint, silently truncating any fractional currency value. Changed todecimalin both the external DTOs and the public domain models. Also fixed the one field (InitiateTransferResponse.Fee) that wasfloatfor the same reason.int(pagination counts, IDs, retry-strategy config values, charge counters, card expiry, etc.) — only actual money fields moved.*Validations.csfiles only had anIsInvalid(double)overload for numeric checks. Once a validated field's static type becamedecimal,IsInvalid(field)silently rebound toIsInvalid(object)at compile time (a boxed decimal is never null), so non-positive amounts stopped being flagged as invalid. Added matchingIsInvalid(decimal)overloads (andIsInvalid(int)where needed to resolve now-ambiguous calls from plainintparameters) everywhere thedoubleoverload existed, restoring the original validation behavior. This was caught by the existing unit test suite (106 failures) before it could ship.Test plan
dotnet build FlutterWave.Core.sln— 0 warnings, 0 errorsdotnet test FlutterWave.Core.Tests.Unit— 1296/1296 passingdotnet test FlutterWave.Core.Tests.Acceptance— 102/102 passing🤖 Generated with Claude Code