Open haszari opened 2 years ago
Assigning this to @james-allan as follow up from the PR - let me know if you have bandwidth, can reassign if needed.
Marking as low priority, because there's no merchant impact of this. i.e. this is a code refactor / preventative task.
IMO it's worth getting tidied up though :)
@haszari how do you handle those low prio issues? Is there a chance it will be handled during cooldown? Despite it's a small task its consequences might be large x100 charges for zero-decimal currencies, so I'd rather fix it sooner than later.
Thanks for the reminder about this @vbelolapotkov . In Helix we don't have a defined process for handling maintenance tasks – this is something I need to look at. For this issue I'll see if someone can pick it up during cooldown or if not will include it in next cycle to get it sorted.
Bumping up the priority so we can get this tidied up. I agree there's risk here and it should be quick to tidy up.
Describe the bug
WC_Payments_Utils::prepare_amount()
is our standard utility for converting a (user facing) currency value into a value suitable for passing to Stripe APIs. It includes logic to multiply by 100 for decimal currencies (e.g. USD).In #4321 we added an inline
* 100
calculation to cover a subscription calculation which required a floating point value.https://github.com/Automattic/woocommerce-payments/blob/0b67331b41cf087751961e9a1b2bbc6366806bce/includes/subscriptions/class-wc-payments-subscription-service.php#L276-L279
Ideally we'd use a single code path to cover all use cases for
prepare_amount
so we don't have multiple places to patch if something changes or we discover a bug. As a fallback, we could implement two functions closely located in source code, so it's easy for future devs to apply fixes to both.Suggestion from @vbelolapotkov on the PR:
Also this comment:
To Reproduce
TBC - please check #4321 for details and add info here when this is picked up 🙇