The fee context system: how Seedr knows what to charge

Last month, a creator on Streamr asked us why her payout was different from her friend's, even though they'd both received the same tip amount. The answer was buried three functions deep in our Supabase backend. It shouldn't have been that hard to explain. That question forced us to think clearly about how fee context flows through Seedr, and why it matters.

The tipping moment needs to know who you are

When someone taps the SeedrButton in Streamr, a lot happens in milliseconds. The app sends a tip amount. A Stripe payment processes. But before any of that, there's a lookup: is this creator a Foundr Free user? Foundr Pro? Or are they standalone on Seedr with no Foundr subscription?

That lookup determines everything downstream. A Foundr Pro creator pays 1% platform fee. Foundr Free pays 1.5%. Standalone creators pay 5%. The difference isn't huge on a single £5 tip, but across weeks and hundreds of tips, it compounds. This is where the fee context system lives.

When we first built Seedr, we hardcoded the 5% fee into the transaction function. It worked. Then we added Foundr integrations, and suddenly we were maintaining fee logic in three places. A creator would change their Foundr subscription status, but Seedr wouldn't know for hours. We were creating data drift.

A single source of truth for fees

The fix was to centralise. We created a shared fee calculation function in supabase/functions/_shared/fees.ts. Every transaction, every payout calculation, every analytics report queries this one source. It takes three inputs: the tip amount, the creator's ID, and a timestamp. It returns the exact fee that applies, in pence (always integers, never floating point). No rounding errors. FCA-ready audit trails.

The function checks the creator's current Foundr subscription status at that moment. If they're Pro, it applies 1%. If they're Free, 1.5%. Otherwise, 5%. It's simple logic, but the centralisation is what matters. When a creator upgrades from Free to Pro mid-week, the next tip automatically reflects the lower fee. No manual intervention. No support tickets.

We also built in a backstop. If the context lookup fails for any reason, the system defaults to the highest fee (5%) and logs the error. This protects creators from overpaying, and it alerts us when something's wrong.

Why context matters more than pricing tiers

When people first hear about Seedr's fees, they focus on the numbers: 1%, 1.5%, 5%. But the real design challenge isn't those rates. It's making sure the right context is available at the right moment.

A creator might be Foundr Free one week and decide to upgrade to Foundr Pro the next. Their fans don't know this. They don't care. They just want to send a tip. The fee context system has to know instantly whether this creator's subscription changed, and apply the right rate from that moment forward.

We also built in context for AML thresholds. Any single tip above £10,000 triggers manual review. That's rare, but when it happens, the context system flags it for our team before the payout processes. We're not an FCA-authorised payment institution yet, so we're cautious. Everything flows through Stripe Connect (which is FCA-authorised), and we're building Seedr to be audit-ready for when we apply for our own Payment Institution licence by 2028.

The context system is how we stay compliant without slowing down creators. It's not exciting to talk about, but it's the infrastructure that keeps everything else working.

How the API layer sees it

For developers embedding SeedrButton in their app, none of this is visible. Three lines of code, and it's done. The SDK handles the fee context transparently.

Under the hood, when a tip is initiated, the SDK sends the creator's ID to our backend. Our functions check their Foundr subscription status in real time. If they're Pro, the response includes the 1% fee context. If they're Free, 1.5%. If they're standalone, 5%. The app calculates the exact amount to send to Stripe, including the fee, and the user sees what they're paying before they confirm.

The creator sees the net payout in their dashboard on Monday mornings. Every transaction is itemised. They can see exactly what the tip was, what the fee was, and what they received. Because we use integer pence throughout (never floating point), the maths is always exact. No rounding surprises.

This transparency is intentional. We wanted creators to trust Seedr, especially creators from faith communities who are tipping for the first time. If you can see the maths clearly, you trust the system.

The day we caught a context leak

Last month, during launch week, a Foundr Free creator reported that their payout looked lower than expected. We pulled the transaction logs. Everything looked right. Then we looked at the fee context. The lookup had succeeded, the 1.5% rate had applied. But one transaction from three weeks earlier, before they'd subscribed to Foundr Free, was still showing 1.5% instead of 5%.

The context function wasn't checking the subscription timestamp. It was checking whether the creator was Free at the lookup time, not at the transaction time. So when they upgraded, all their previous tips retroactively got the lower fee. We were paying them too much, and we didn't know it.

We fixed it immediately. The function now includes a timestamp check. It pulls the creator's subscription status at the exact moment the tip was sent, not at the moment of the lookup. It's the kind of bug that would break trust fast if we hadn't caught it. One creator would have paid the wrong fee, and everyone would have noticed.

Context is the interface between tipping and business

Seedr is a tipping platform, but it's also a business model. The fee context system is where those two things meet. It's how we fund Seedr while letting creators keep more when they invest in Foundr. It's how we stay compliant without being stiff. It's how we stay transparent without being complicated.

Every decision in the fee context system comes back to a principle: the system should know more than the user has to know. A creator shouldn't have to think about whether their fee changed because they upgraded their Foundr subscription. It just should. A fan shouldn't have to calculate what a tip costs. The app should show them the exact amount, including the fee, before they confirm.

The context sits between those two experiences. It's unsexy infrastructure. But it's the thing that lets Seedr stay simple on the surface while being rigorous underneath.

If you're building a tipping or payment system, ask yourself: where does your fee logic live, and does every part of the system see the same answer? That question will save you weeks of debugging.

Ready to try Seedr by MRVL?

One tap to download. No sign-up wall.

Visit the website

Want to try Seedr?

Visit Seedr →