“Just Pennies” could develop into large sums of cash with multiple projects. At what carry-over threshold are we legally considered to be money-handleing and no longer just a payment coordinator?
I don’t think there’s any scenario in which Snowdrift succeeds in its mission of changing the landscape of FLO funding and the pennies lost are of any consequence.
I’m neither a lawyer nor the person who researched this issue, but as I understand it, we would not have to worry about it here, since “carried over” here is talking about the pending donation, not something we charged patrons but didn’t give projects.
Excellent point. However, I’m still leaning more towards using just pennies. It’s simpler, easier to understand, easier to explain/sell/market, and easier to program.
However, if we were to switch to pennies instead of 1/10 of pennies as the starting unit, what are the dis-advantages? What is lost by having a higher base unit?
It quickly becomes unaffordable, especially for people of modest means. I don’t know anybody who’d donate $100/mo to a single project. $10/mo from 10 000 patrons is a lot more money than the same amount from 1000 patrons.
1 Appreciation
Vaguely related anecdote: Even megacorp banking websites do rounding wrong. 
(Actual amount: $0.99)
I’m returning to this post as I drill through some of my todo items.
I think this post opened up the “multiple projects” can of worms, which we are explicitly ignoring right now until we get the rest of the site in a sensible state (operationally, design-wise, and so forth). I.e. this post combines a real, current, actual problem (the inaccurate dollar amounts) with some other topics that we should avoid spending time on until we are ready to fully tackle supporting multiple projects. I suggest we solve the former and let the latter rest for now.
For solving the inaccurate dollar amounts, having heard all arguments, I simply think it is best to show tenths of a cent. It is the easiest fix, and creates no new tradeoffs. It obviously won’t be the final solution, but it is sufficient to solve the immediate problem.
I’ve opened https://git.snowdrift.coop/sd/snowdrift/issues/113.
3 Appreciations
Do you mean show tenths of a cent for the actual crowdmatch amounts, but just cents for the charge transactions? So we’d defer rounding until an actual charge? I don’t think it would be OK to show tenths of a cent on the actual charges. Also, when showing them, maybe we could display the third decimal place in gray or something to minimize confusion? (@mray what do you think?)
We are not technically able to charge a 10th of a cent, as our current payment processor, stripe, only allows amounts in the smallest currency unit for whatever currency unit we are charging.
Source.
The more ethical approach would be to round down, to the nearest cent, and then carry over the amount above the nearest cent to the next payment event. What @chreekat is suggesting is that for maximum transparency, the tenths of a cent will be shown on your transaction page, so it’s clear what is happening with your money.
I think we should go with the solution that creates the least problems (whatever devs prefer) and have a good idea how we want it in the end. I can imagine a solution like always rounding down and showing the precise amount on mouseover.
I share @msiep s interest in what the context here is: would this solution be applied anywhere?
As I posted above with image of gas station prices, it is a good idea to make the 3rd decimal visually distinct so it doesn’t confuse people who rarely see dollars with 3 decimals. But indeed, there are ways to do it. I think the fraction like the gas station is better than just grey.
I agree, if we can do that. I’m not sure it would be feasible though since although I know character sets can include a few fractions like ½ and ¼ I don’t suppose there are characters available for 0/10 through 9/10?
1 Appreciation
Sorry for not being clear. The immediate, accurate, and simple-to-implement solution is to show tenths of a cent for crowdmatches and full cents for donations. (Except that we don’t even show donation amounts anywhere yet, so it’s only crowdmatch amounts that matter today.)
In other words: to fix the bug, we show tenths of a cent for crowdmatches today. Making the site easier to grasp – whether with visual cues, changed calculations, or whatever – is still out of scope for this bug.
3 Appreciations
Thinking about this again since I just opened #939 - Store Crowdmatch amounts as cents - snowdrift/tasks - Codeberg.org to track the rounding-at-crowdmatch-time that I proposed several years ago.
I agree this is a significant concern. It’s a much more rewarding experience when your pledge is matched immediately, instead of delayed in 10-patron increments.
Here’s a compromise idea: **
- Crowdmatch time: Store exact fractions of a cent
- Charging patrons: Always round up from their total
- Payout to projects: Sum the (exact) crowdmatches then round down[1] the total.
- Will always be less than the total charged to patrons.
- The extra goes to Snowdrift.coop.
- Perhaps into a dedicated fund, as discussed at #701 - Strategy for matching payment-declined patrons and below-minimum-charge patrons - snowdrift/tasks - Codeberg.org
Benefits:
- We can still truthfully show matching happening for each patron that pledges
- We can zero out a patron’s balance every time they are charged
- We have another source of income into the fund besides “someone generous donates to it” or out of Snowdrift’s own patronage.
Problems:
- Is it actually possible? #940 - Does Stripe support many-to-many charges? - snowdrift/tasks - Codeberg.org
- How to represent this on the receipt?
- With a single project, it’s easy enough. Round the total sent to the project down to the nearest cent and then add a 1 cent fee for Snowdrift. With multiple projects, it depends on whether we can actually do many-to-many charges.
It needs to be down for the unlikely scenario where there are more projects than patrons. In that case, the total charged to patrons can be less than the amount owed to projects. ↩︎
We discussed in meeting that any sort of strangeness with adding up fractions of a cent will lead to people thinking about Office Space (the movie which includes a fraud of siphoning off rounding errors of cents from transactions) or various cryptocurrency or Wall Street sorts of financial shenanigans.
I do want to avoid anything that leads to people getting suspicious about anything, even if there’s no real basis, it just reminds them of things shifty people do.
Yeah, as discussed in the meeting, it’s probably not the best place to insert a snowdrift fee.
Fun fact, that tactic is apparently Salami Slicing.
Electricity prices, like $0.124 per kWh.
Researching the rounding methods, we definitely can and should use minimally-biased rounding methods as chreekat mentioned.
Assuming we want it to be deterministic (meaning we can’t use the otherwise-awesome-for-our-use-case Stochastic Rounding) and we don’t want to store an extra boolean about the last rounding event (meaning we can’t use the zero-bias Alternating Tie-breaker) the best is to round half to even, which (negligibly) biases rounding towards even numbers rather than to one party or the other in a transaction. Round half to even (convergent rounding) seems the clear winner for us.[1]
Convergent rounding is used by statisticians etc. but conveniently is also is the one built in to every computer’s arithmetic processing unit.
The view I shared in the meeting, is that we should keep storing the full amount, and round only at the last second when a charge is needed. One can think of it like a currency conversion.
This doesn’t block a patron’s ability to zero out their balance.
On the frontend, we can do the subcent values in a small lowered font, or low-opacity, or as a fraction, or just show it rounded unless hovered.
(“Banker’s rounding” is a misnomer, banks actually tend to round half away from zero (commercial rounding) which only makes sense if you deal with negative numbers just as often as positive ones. Not us.) ↩︎
I did some paper napkin math, and the lost income from fractions of a cent is negligible compared to the effect of just a few more patrons (less than 0.5% of the total crowd, worst case).
Today: The pledge rate is 0.1 cents per patron. Even if we always rounded down, that’s at most 0.9 cents per patron, which would be offset by just 9 additional patrons.
A lower match rate would make things worse, but not by much.
-
Second Wind[1] has around 18k patrons giving a bit over $3 apiece. If they were matching, the average rate would be 1 cent per 57 patrons, 0.3% of the crowd.
-
Even at $100k@50k patrons, dropping fractional cents would be offset by 250 patrons, which is still only 0.5% of the total crowd.
-
Anything more than that is too far in the future to care about now.
…and that’s the worst case of always dropping almost the full cent. On average it’ll be about half of those numbers.
So, the competing considerations are complication of calculations/presentation vs the experience of pledging/matching, and I am back to thinking rounding at crowdmatch time is the best solution.
With further research: Many-to-many charges are not a thing.
That means: if we wait to round fractions of a cent at charge time, then we need to sum the pending donations per project, then round, then sum the projects.
That means: in the dashboard, if we want everything to add up, we would not be able to show the total given to projects is a given month, because the sum of the monthly totals would not be what’s actually paid out.
By this standard, even our gas station example fails. Like shops setting prices at $X.99, they want to be able to advertise a smaller headline price while charging effectively 1 cent more.
By the way, I mentioned this thread to my partner, who I consider a reasonable proxy for the average person. Her (heavily paraphrased) reaction was, “Decimals are way too confusing, couldn’t you use a separate unit for them instead?” And then searched and found Mill (currency) - Wikipedia. Point being, I think fractions of a cent will be offputting strictly on complexity, without any thought given to shiftiness.
That’s a good one. But aren’t they still rounded each pay period (usually monthly)? They’re tracked exactly in kWh, then converted to dollars and immediately rounded at billing time. No fractions of a cent are ever carried over; if I don’t pay my bill one month, the next bill just adds the unpaid month’s rounded total to my balance.
If we were using some other units (crypto comes to mind) and then just converting to dollars at payout time, this would make more sense to me. But we’re trying to stay familiar to what people know and trust, so that’s ruled out for now.
Agreed. Or, if we decided to go the per-patron approach, later, maybe rounding down (maps better to "1 cent per 10 patrons).
Irrelevant part since I'm not proposing the solution above any more
There’s a less strange presentation:
Each charge, any fractions of a cent are dropped. Additionally, Snowdrift takes a flat fee of 1 cent per project. [Optional: We donate the money from this fee to projects, to ‘cover’ the dropped fractions of a cent and ensure all patrons are fully matched].
The big benefit is that the we would take a larger % of fee for lower-patron-count projects. That is a benefit because those same projects are more likely to experience patrons who don’t pay off their pending balance. So we have a source of income into the non-payment fund that comes out of the same for covering those non-payments for projects, which matches up with
But given the downsides above, I am do not think it is worth the optics of going from “no fees” to “minimal fees”, even if the typical case will be under 1%.
Off the cuff, my educated guess is that most of their patrons just want them to keep making content, not for the extremely minor exclusive benefits. I could talk more about them elsewhere. ↩︎