> Oh, the business teams found the approach puzzling---but what do they know, right? If they were smart, they would be software engineers.
Well in this case the business teams selected the 3rd party payments gateway that the company would work with, negotiated the contracts with them, and worked with the 3rd party to set up how the customers would be charged. They and/or the product team determined that we'd use the 3rd party system to handle the billing because building it in house wouldn't generate any new revenue. They weren't stupid, but they choose an approach to payments processing that was pretty low level (because it generated more revenue, of course), without anyone at the company having a good understanding of low level payment processing details. The engineers learned because we kind of had to, but three years into the project (when I left) business/product would still routinely struggle with the details.
So anyway, WRT to billing, the task handed to engineering was: pull the billing detail from the 3rd party's API and assemble it into a statement that can be handed to a client. We had zero control over how the charges were generated or applying any rounding to the total.
If someone had a gun to my head saying, don't hide the sub-penny slices from the billing, I would just do the billing in thousandths of a cent, rather than make "leap cents" appear every couple of bills:
Amount owing: $123.45678
Please pay one of: $123.46 (a credit of $0.00322 will be applied)
$123.45 (a balance of $0.00678 will carry forward)
On the next statement, if they paid $123.46:
Previous balance: ( $0.00322) [credit]
New charges: 123.45678 { here we have a detailed breakdown }
Amount owing: 123.45356
Please pay one of: $123.46 (a credit of $0.00644 will be applied)
$123.45 (a balance of $0.00356 will carry forward)
etc.
That's literally "put the billing detail from the 3rd party API and assemble it into a statement". Since the billing detail from the 3rd party API is in thousandths of a cent, then that implies the statement must have thousandths of a cent.
If the two payment options were determined to be too confusing, one of the two could be dropped.
Well in this case the business teams selected the 3rd party payments gateway that the company would work with, negotiated the contracts with them, and worked with the 3rd party to set up how the customers would be charged. They and/or the product team determined that we'd use the 3rd party system to handle the billing because building it in house wouldn't generate any new revenue. They weren't stupid, but they choose an approach to payments processing that was pretty low level (because it generated more revenue, of course), without anyone at the company having a good understanding of low level payment processing details. The engineers learned because we kind of had to, but three years into the project (when I left) business/product would still routinely struggle with the details.
So anyway, WRT to billing, the task handed to engineering was: pull the billing detail from the 3rd party's API and assemble it into a statement that can be handed to a client. We had zero control over how the charges were generated or applying any rounding to the total.