#DaanVDH
1 messages · Page 1 of 1 (latest)
Hi I recommend reading: https://support.stripe.com/questions/rounding-rules-for-stripe-fees
Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
for example:
mul := bi.Mul(bi, big.NewInt(14))
div := bi.Div(mul, big.NewInt(1000))
sum := div.Add(div, big.NewInt(25))
yeah i found that, but there's no example for when the fixed part is added,
for example you have a .25c fixed fee with a 1.4% percentual fee
you first calculate an amount lets say: 100 * 0.014 = 101.4
but do you round then or after adding the 25 cents to that amount
Gotcha. I'm not sure offhand. I recommend going to support as the question will get escalated to someone who knows: https://support.stripe.com
Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
Thanks, will do!
does it matter, though? the fixed fee is never a fractional number of cents, so it shouldn't have any bearing on how the overall fee is rounded
Yeah that's true, hadn't thought about it like that!
this should work right:
func (s service) calculateTransactionFees(sub primitive.Decimal128, method string) (int64, error) {
bi, _, err := sub.BigInt()
if err != nil {
return 0, fmt.Errorf("could not calculate transaction fees")
}
switch method {
case Card:
mul := bi.Mul(bi, big.NewInt(14))
div := bi.Div(mul, big.NewInt(1000))
sum := div.Add(div, big.NewInt(25))
return sum.Int64(), nil
case iDeal:
return 29, nil
case BankContact:
return 34, nil
case GiroPay:
mul := bi.Mul(bi, big.NewInt(14))
div := bi.Div(mul, big.NewInt(1000))
sum := div.Add(div, big.NewInt(25))
return sum.Int64(), nil
default:
return 0, fmt.Errorf("missing payment method")
}
}
I think the division there will round down, not round to nearest
separately, I don't think you actually need to use the big package for this; the amounts involved here are always going to be << int64 max val
anyhow - I don't think either the big or math packages supports quite exactly what you want re: rounding an integer to the nearest thousand
you could implement it by hand, I guess? it's not hard, though it feels wrong somehow
No, also looked for it but couldn't find anything
I'll probably just use int64
👍
Thanks!