The pence decision: why Seedr stores every tip as an integer
Last month, a creator on Streamr sent me a message. She'd been tipping viewers for three weeks and wanted to know: could she see exactly what she'd earned, to the penny, in a format her accountant would trust? That question led me back to a decision we made six months ago that she'd never even notice.
The problem with decimal places
When you're building a payment system, rounding errors aren't abstract. They're real money, small enough to hide in the noise but large enough to compound.
Most creator platforms store tip amounts as decimal numbers (e.g., £5.47). That works fine on a spreadsheet. But the moment you're processing hundreds of tips across multiple payment processors, dealing with fees, and building toward something that might one day need to prove its integrity to a regulator, decimal arithmetic becomes a liability. Floating-point math in databases can introduce tiny discrepancies. A penny here, a fraction of a penny there. Perfectly innocent, but impossible to explain in an audit.
We decided early on that Seedr would store every tip as an integer, in whole pence. A £5 tip isn't 5.00; it's 500 pence. When a fan tips through the SeedrButton (embedded in Streamr, Giggl, or Foundr with just three lines of code), that amount travels as an integer from the app to our Supabase backend. It stays an integer. When we calculate the 5% platform fee, when we deduct it for a Foundr Free creator (1.5% instead) or a Foundr Pro creator (1%), when we prepare the weekly Monday payout, everything is integer math. No rounding. No ambiguity.
Why this matters now, not in 2028
You might think: why does this matter if MRVL Pay isn't FCA-authorised yet? Seedr runs on Stripe Connect, which is already authorised. We're good to go.
True. But we built Seedr as Phase 1 of something bigger. Every schema decision we make now has to hold up in 2028, when we apply for Payment Institution status. By that point, we'll have processed thousands of transactions. An FCA auditor won't care that our rounding errors are tiny. They'll care that we can't explain them. And more importantly, our creators will have grown to trust that Seedr keeps their books straight. Once you've told a creator accountant that the ledger is exact, you can't go back and say, 'Well, there's a bit of variance, but it's not material.'
INTEGER pence throughout means that every transaction, every fee calculation, every payout is provably correct. No excuses. No decimals to hide behind.
The single source of truth
We keep all fee logic in one place: supabase/functions/_shared/fees.ts. That file is the source of truth. When we calculate what a creator earns, we pull from that file. When we calculate what Seedr retains, same file. When a creator's accountant asks, 'Where did this fee come from?', we can point to a specific commit, a specific version of that file, and explain exactly what rule applied to that transaction on that date.
Because everything is an integer, there's no room for the system to silently round away precision. If a creator tips £20 and the fee is 5%, they're tipping 2000 pence and we take exactly 100 pence. The creator's weekly payout includes integer arithmetic, line by line. On Monday, when the payout lands in their Stripe Connect account, there are no surprises.
A faith creator on Streamr told us she appreciates this level of clarity. She knows exactly what she'll earn before she accepts a tip. Her community knows the money goes where it's meant to go. That's not a regulatory requirement; it's just good faith.
What creators actually see
None of this is visible in the creator dashboard, and that's by design. A creator logs into seedr.app/@handle and sees their earnings in pounds sterling, formatted like currency. A tip of 500 pence shows as £5.00. The analytics page shows weekly totals. The dashboard tells the story of their tipping income in human terms.
But underneath, the engine runs on integers. If a creator ever needs to export their transaction history for tax purposes, if their accountant ever wants the raw data, it's all there: every transaction recorded as whole pence, every fee calculated with perfect precision, every payout backed by integer math.
The minimum tip is £5 (500 pence) and the minimum payout is £20 (2000 pence) for practical reasons too. We're trying to keep friction low for audiences while keeping payouts meaningful for creators. But those minimums also sit perfectly on integer boundaries. No rounding. No edge cases.
The audit trail we're already building
One of the conversations I had this week was with a Foundr creator who asked if Seedr would ever integrate with their accounting software. The honest answer is, not yet. But the reason it's possible at all is because we built with this constraint from day one.
Most platforms bolt on audit readiness later, when they've already made a mess of their data. We did it backward. We assumed we'd need to prove every pound to someone external, and we designed the ledger accordingly. INTEGER pence is part of that design.
When a creator reaches the AML threshold (£10,000 in tips), we already know the exact amount, to the pence. Our manual review process has clean data to work with. No guessing. No reconstruction. Just facts.
Is precision in payment systems really worth the extra thought? Ask any creator whose accountant has ever questioned a payout, and you'll get your answer.