Category: Monetisation

When your server misses a payment webhook—because your hosting provider had a blip, your endpoint timed out, or you deployed code at the wrong moment—you’re relying on the processor’s retry logic to deliver it again. But each platform handles retries differently, and the windows are shorter than most operators assume.

Miss the retry window entirely, and you’ll never know that subscription was canceled, that payment failed, or that refund was issued. Here’s what actually happens behind the scenes.

Stripe: exponential backoff over three days

Stripe retries failed webhooks with exponential backoff. The first retry happens within minutes. Subsequent attempts spread out over roughly three days, with the final attempt landing around 72 hours after the initial event.

If your endpoint returns anything other than a 2xx status code—or times out after 30 seconds—Stripe marks it as failed and queues a retry. The dashboard shows each attempt, including response codes and timing.

The three-day window sounds generous, but if your server is down for a long weekend or you’re troubleshooting a bug that takes four days to identify, you’ve lost the event. Stripe doesn’t retry indefinitely.

Non-obvious detail: Stripe disables your webhook endpoint automatically after multiple consecutive failures across different event types. You’ll get an email, but if you’re not monitoring closely, subscription updates can go silent for days before you notice.

Paddle: 72-hour retry, then manual replay required

Paddle’s retry behavior mirrors Stripe’s three-day window but with a stricter cutoff. After 72 hours, failed webhooks stop retrying. To recover them, you need to manually request a replay through the dashboard or API.

The replay feature is helpful if you know what you’re looking for—filter by event type and date range, then trigger a resend. But it requires you to notice the gap first. If a handful of subscription.updated events went missing during a deploy and you don’t audit logs regularly, you might not realize users were downgraded or upgraded until they complain.

Paddle also enforces the same 30-second timeout as Stripe. If your webhook handler queries a slow database or chains multiple API calls, you’ll hit that ceiling faster than expected.

Lemon Squeezy: five retries over 24 hours, then it’s gone

Lemon Squeezy retries webhooks five times over approximately 24 hours. The schedule isn’t publicly documented down to the minute, but the final attempt lands within a day of the original event.

This tighter window means less room for error. If you deploy a breaking change Friday afternoon and don’t catch it until Monday, you’ve missed every webhook that fired over the weekend. Unlike Stripe and Paddle, Lemon Squeezy doesn’t surface retry history in the dashboard with the same granularity—you’ll see that an event was sent, but forensic details are limited.

The shorter retry window makes Lemon Squeezy less forgiving for solo operators who don’t monitor uptime 24/7. It’s workable if your stack is stable, but the margin is thin.

What to do when retries aren’t enough

Webhook retries are a safety net, not a guarantee. If you’re running a subscription business, you need a second layer: periodic reconciliation.

Once a day—or once a week, depending on volume—query your payment processor’s API for subscription and payment statuses, then compare them against your database. Look for mismatches: active subscriptions in Stripe that your app thinks are canceled, payments marked pending that actually settled, refunds that never updated your records.

This reconciliation step catches what retries miss. It’s not real-time, but it prevents the worst-case scenario where a customer’s access is wrong for weeks because a single webhook disappeared.

Set up logging that writes every incoming webhook to a separate table before processing it. If your handler crashes mid-execution, you’ll still have the raw payload to replay manually. Most processors let you trigger test webhooks from the dashboard—use those to validate your endpoint handles retries and errors correctly before real money flows through.

Want more architecture breakdowns like this? Subscribe to One Two Three Send—every article is written for operators running the business, not just the content.

Set up alerts, not just logs

Failed webhooks usually show up in your payment processor’s dashboard, but dashboards require you to look. Set up an alert—Slack notification, email, SMS, whatever you’ll actually see—when your endpoint returns a non-2xx status or when the processor reports multiple failures in a row.

If you’re on a platform like Stripe, enable the option to email you when an endpoint is disabled. That email might be the only signal you get before revenue events start disappearing.

Webhook retries buy you time to fix an outage, but they don’t extend indefinitely. Understand your processor’s retry schedule, build reconciliation into your workflow, and monitor failures in real time. The three-day window Stripe offers feels comfortable until you realize you didn’t check the dashboard for four.

Most solo operators running sponsored content use boilerplate disclosure language they copied from someone else. That works until a brand’s legal team pushes back, a platform flags your post, or you realize the rules vary by country, platform, and even content format.

The disclosure frameworks aren’t consistent. What satisfies the U.S. Federal Trade Commission doesn’t necessarily meet UK Advertising Standards Authority requirements. Instagram’s branded content tool has different mechanics than a newsletter sponsorship disclosure. And affiliate links sit in a separate category from paid placements, even though many operators lump them together.

Here’s what the major frameworks actually require, and how to write disclosures that cover you without sounding like a legal disclaimer.

FTC requirements: clear, conspicuous, and early

The FTC’s core rule is simple: disclose material connections before someone engages with your recommendation. That means the disclosure has to appear before the call-to-action, not buried at the bottom of a 2,000-word post.

“Clear and conspicuous” has specific meaning. The disclosure needs to be:

• In plain language—”This post is sponsored by [Brand]” works; “In partnership with” is ambiguous
• Unavoidable—not hidden behind a “read more” fold or a link labeled “legal”
• In the same format as the content—if your post is a video, the disclosure needs to be spoken and on-screen, not just in the description

For newsletters, that usually means a line at the top: “Today’s issue is sponsored by [Brand].” Some operators put it in the subject line using brackets or prefixes; that satisfies the “before engagement” rule because the subject is visible before the open.

Affiliate links need disclosure too, but the language can be lighter: “This post contains affiliate links. I earn a commission if you purchase.” The FTC cares that readers know you have a financial incentive—not the exact commission structure.

ASA and UK-specific rules

The UK’s Advertising Standards Authority is stricter about labeling. The word “ad” needs to appear prominently. “Sponsored,” “partner,” and “collab” don’t meet the standard on their own.

If you’re running sponsored content and have UK readers, use “Ad:” or “Advertisement:” as a prefix in the subject line or headline. The ASA has flagged Instagram posts where “#ad” appeared several hashtags deep—the rule is that it needs to be upfront, not mixed into a list.

For newsletters with international audiences, the safest approach is to satisfy the stricter standard. Leading with “Ad:” in the subject and “This issue is an advertisement for [Brand]” in the body covers both FTC and ASA requirements.

Platform-specific branded content tools

Instagram, Facebook, YouTube, and TikTok all have built-in branded content toggles. When you enable them, the platform adds its own “Paid partnership with [Brand]” label.

Using the platform tool doesn’t eliminate your obligation to disclose in your own words—it’s additive. The FTC and ASA expect you to make the disclosure, not rely on a platform label that could change or disappear in a layout update.

The platform tools do serve a separate purpose: they let brands access performance data through Meta’s Brand Collabs Manager or YouTube’s brand analytics. If a sponsor requires that data access, you need to use the platform toggle. Just don’t treat it as your only disclosure.

Writing disclosures that don’t kill your voice

Legal-sounding language makes readers skip the content entirely. You can stay compliant without sounding like a Terms of Service page.

Instead of: “The following content has been underwritten by a third-party commercial entity in exchange for monetary or other consideration.”

Use: “This issue is sponsored by [Brand]. They’re paying me to tell you about [Product].”

The second version is clearer, more honest, and meets every regulatory standard. Readers appreciate directness. The sponsors who push back on plain-language disclosures are usually the ones trying to obscure the commercial relationship—which is exactly what regulators are trying to prevent.

For affiliate links, the same principle applies. “I earn a commission if you buy” is clearer than “This post may contain affiliate links to products and services, for which the author may receive compensation.”

Where operators actually get flagged

Most enforcement isn’t about missing disclosures—it’s about disclosures that appear too late or use ambiguous language.

Common mistakes:

• Placing “Sponsored by [Brand]” only in the footer of a newsletter
• Using “Thanks to [Brand] for supporting this post” without clarifying it’s a paid relationship
• Disclosing on your website’s generic “Disclaimers” page instead of in the content itself
• Using platform hashtags like #partner or #collab, which don’t explicitly state a paid relationship

If you’re running a newsletter with recurring sponsors, disclosing once in your welcome email or about page doesn’t cover individual sponsored issues. Each piece of sponsored content needs its own disclosure.

One template that works everywhere

If you want a single disclosure format that satisfies FTC, ASA, and platform norms across newsletters, blog posts, and social media:

Subject line or headline: “Ad: [Your usual title]”

Opening line: “This [post/issue/video] is a paid advertisement for [Brand]. They compensated me to [describe what you’re doing: reviewing, recommending, featuring].”

That structure is unambiguous, front-loaded, and uses plain language. It works for newsletters sent via Beehiiv, MailerLite, or Postmark. It works for blog posts. It works for Instagram captions and YouTube descriptions.

You can adjust tone—”[Brand] paid me to write this” vs. “This issue is sponsored by [Brand]”—but the core elements stay the same: who paid, what the relationship is, and disclosure before the pitch.

One Two Three Send covers the operational side of running content businesses—including the legal and platform mechanics most guides skip. Subscribe to get one focused piece like this each day.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

If you run affiliate links across your content—newsletter, blog, social—you probably started with a spreadsheet. Product name, affiliate URL, commission rate, maybe a notes column. It works until it doesn’t.

The breaking point isn’t volume. It’s versioning. Affiliate programs change their URLs, update terms, expire cookies faster, or shut down entirely. Your spreadsheet doesn’t tell you when a link dies. You find out three months later when a reader replies asking why your checkout link 404s.

What breaks first

Spreadsheets fail at three things: link rot detection, historical performance, and propagation speed.

Link rot is silent. An affiliate program migrates to a new domain, updates their tracking parameter structure, or sunsets a product SKU. Your old link still resolves—it just doesn’t credit you. Unless you’re manually testing every link monthly, you won’t know.

Historical performance matters when you’re deciding what to promote next quarter. A spreadsheet can log clicks if you’re using a link shortener with analytics, but matching clicks to actual conversions requires stitching together your shortener dashboard, the affiliate network backend, and your own notes. Most operators give up and optimize for vanity metrics instead.

Propagation speed is the operational bottleneck. You update a link in your spreadsheet, then you have to manually find and replace it across every past article, email archive page, and pinned social post. If the link appears in 40 places, you’re burning an hour. If you skip the older posts, you’re leaving dead links live.

When a link manager pays for itself

Dedicated affiliate link management tools—Pretty Links, ThirstyAffiliates, Lasso—charge $10 to $30/month. The ROI threshold is straightforward: if one broken link costs you more than one month’s subscription in lost commissions, the tool pays for itself.

For a solo operator earning $500/month in affiliate revenue, a single high-value conversion is worth $50 to $200 depending on the program. One missed sale covers six months of tooling.

The feature that matters most isn’t the link cloaking or the pretty dashboard. It’s automatic redirect updating. You edit the destination URL once in the tool’s backend; every instance of that short link across your entire site updates instantly. No find-and-replace. No archaeology through old posts.

Link health monitoring is the second-order benefit. Tools like Lasso ping your affiliate URLs weekly and flag 404s or redirects that don’t resolve to the expected domain. You get an alert, fix it, move on. The alternative is discovering the problem when a reader emails you or when you notice commission drops in your next payout statement.

The spreadsheet-plus-shortener hybrid

If you’re not ready to pay monthly, the middle path is a spreadsheet plus a custom domain short link service. Rebrandly’s free tier gives you 500 branded links and click tracking. You store the short link in your spreadsheet, paste that short link everywhere, and update the destination URL in Rebrandly when the affiliate program changes.

This works if you have fewer than 50 active affiliate relationships and you’re disciplined about logging every new link. It breaks when you forget to add a link to the sheet, or when you need to bulk-edit links by category (“update all Amazon links to the new Associate ID”).

The hidden cost is context switching. Every time you create a new affiliate link, you’re opening three tabs: the affiliate dashboard to generate the URL, Rebrandly to shorten it, and your spreadsheet to log it. That’s 90 seconds per link. If you’re adding 10 links a week, that’s 15 minutes weekly—13 hours a year—on administrative overhead.

What to do Monday

Audit your last 90 days of affiliate links. Open your spreadsheet, click every URL, and verify it resolves to the correct product page with your tracking parameter intact. If more than 10% are broken or redirect incorrectly, you have a link rot problem worth solving.

If you’re earning less than $200/month in affiliate revenue, stay with the spreadsheet but set a calendar reminder to re-check links quarterly. If you’re above $500/month or managing more than 30 active programs, trial a link manager for one month and measure time saved on link updates.

The goal isn’t perfect tracking. It’s reducing the lag between when a link breaks and when you notice. Every day a broken link stays live is a day you’re sending traffic you can’t monetize.

One Two Three Send covers the tools and tactics solo operators actually use to run content businesses. Subscribe to get one focused article daily—no filler, no fluff.

If you’re running subscriptions or one-off product sales through Stripe and you’ve turned on automated tax calculation, you’ve probably assumed the displayed total at checkout matches what Stripe will actually charge. Most of the time it does. But there’s a timing issue that breaks this assumption, and it shows up more often than Stripe’s documentation admits.

The problem: Stripe’s Tax Calculation API is called asynchronously when a customer reaches checkout. If your checkout page renders faster than the tax calculation response returns—common on fast hosting or CDN-cached pages—the displayed price can lag behind by a second or two. When that happens, the customer sees one total, then it flickers to another, or worse, the charge goes through before the tax rate applies.

How Stripe’s tax calculation actually fires

Stripe’s tax engine doesn’t pre-calculate tax for every possible customer location. Instead, it waits until checkout to call POST /v1/tax/calculations with the customer’s IP-derived location, the line items, and your tax settings. The response includes the tax amount, which your frontend then adds to the subtotal.

This works fine when checkout is slow—legacy WordPress installs, heavy JavaScript bundles, or multi-step forms give the API enough time to respond before the total renders. But if your checkout loads in under 800ms and you’re calling the API client-side, you’ll see the mismatch.

Stripe recommends server-side calculation for this reason, but many solo operators use client-side Stripe.js integrations or no-code tools like MemberStack, Outseta, or Carrd payment embeds, which default to client-side tax calls.

When the lag causes real problems

The flicker alone erodes trust. A customer sees $49, then $53.67 a moment later. If they screenshot the first number or bail before the update, you’ve lost the sale or opened a dispute.

Worse: if your payment button becomes active before the tax calculation completes, Stripe will process the charge without tax. You’re liable for the shortfall. This happens most often when operators use custom checkout forms that don’t wait for Stripe’s PaymentIntent status to confirm tax has been applied.

Third issue: webhook events. If you’re listening for checkout.session.completed to trigger fulfillment, and the tax calculation hasn’t finished, your webhook payload might show an incomplete amount_total. Fulfillment scripts that check totals against expected pricing will fail or flag fraud.

How to fix it

Move tax calculation server-side if you control your checkout stack. Create the PaymentIntent on your backend, call /v1/tax/calculations there, and return the final total to the frontend. This ensures tax is baked in before the customer sees any number.

If you’re locked into a client-side tool, add a loading state to your checkout button. Disable it until Stripe confirms automatic_tax.status returns complete. Most no-code platforms let you add a custom attribute or visibility rule tied to a calculation flag.

For webhook reliability, always validate amount_total in your handler. If it’s lower than expected and automatic_tax.status is requires_location or failed, log it and retry the calculation manually via the API before fulfilling.

One non-obvious fix: cache customer location in a session cookie after their first page load, then pre-calculate tax before they hit checkout. This won’t work for first-time visitors, but it smooths repeat traffic. You can use Stripe’s customer_details.address field to store validated location data from a prior purchase.

Pricing and support notes

Stripe Tax costs 0.5% of the transaction amount plus any tax collected, with a $10/month minimum once you process your first taxable sale. The API itself has no rate limit for tax calculations, but each call adds ~200–400ms latency depending on region.

If you’re processing under 100 transactions a month, the $10 minimum might not justify automation—manual tax rates via Stripe’s dashboard are free and load instantly. For higher volume or multi-region sales, automated tax is worth it, but only if you handle the sync timing correctly.

Stripe’s support documentation assumes you’re using Checkout or Payment Links, both of which handle tax calculation timing internally. If you’ve built a custom integration, you’re on your own to catch these edge cases.

Have a checkout or payment flow question? Reply to this email—operator questions shape what we cover next.

If you’re thinking about selling sponsorships in your newsletter, the first question is always: what should I charge?

Most advice points to CPM—cost per thousand opens—but the ranges you’ll find online are either outdated or so wide they’re useless. Here’s what solo operators and small teams are actually charging in 2026, broken down by niche, list size, and placement type.

Tech and developer newsletters: $30–$80 CPM

Tech newsletters with engaged audiences—especially those covering specific tools, frameworks, or workflow topics—command some of the highest rates. A 5,000-subscriber list with a 40% open rate (2,000 opens) can charge $60–$160 for a primary placement.

The upper end applies when your audience skews toward decision-makers: CTOs, senior engineers, product leads. If your readers are junior devs or students, expect $30–$50 CPM.

Sponsors in this niche are typically SaaS tools, API platforms, or developer-focused services. They’re buying access to builders who have budget authority or influence over stack decisions.

Finance, investing, and business: $40–$100 CPM

Newsletters covering personal finance, investing strategies, or small-business operations sit in a similar range—or higher if the audience is verified high-net-worth.

A business newsletter with 10,000 opens can charge $400–$1,000 per placement. Sponsors here include fintech apps, investment platforms, business insurance, and accounting tools.

The key variable is audience income and intent. If your readers are actively managing portfolios or running businesses, CPMs climb. If they’re browsing general money tips, rates drop toward $25–$40.

Marketing and creator tools: $25–$60 CPM

Newsletters for marketers, solo operators, and content creators—like this one—typically see $25–$60 CPM. Sponsors are often other newsletters, SaaS tools, courses, or affiliate offers.

A list with 8,000 opens might charge $200–$480 for a dedicated sponsor block. Secondary placements (classified-style listings or brief mentions) go for $15–$30 CPM.

This niche is crowded, and many readers are also operators who know what sponsorships cost. That keeps rates honest but also means you need strong engagement metrics—open rates above 35% and click-through above 2%—to justify premium pricing.

Lifestyle, wellness, and general interest: $15–$40 CPM

Broader lifestyle newsletters—covering travel, productivity, wellness, or general personal development—sit at the lower end. CPMs range from $15 to $40 depending on engagement and audience demographics.

A 15,000-open newsletter in this category might charge $225–$600 per sponsor. The challenge is that sponsors often want very specific audience segments (parents, remote workers, specific age ranges), and general-interest lists don’t always deliver that precision.

Higher rates come from tight positioning. A newsletter for remote-working parents will out-earn a general productivity newsletter with the same open count.

What actually moves the rate

Niche matters, but three other factors determine what you can charge:

• Engagement rate: Opens above 40% and clicks above 3% let you charge 20–30% more than average.
• Audience intent: Readers who buy tools, subscribe to services, or make business decisions are worth more than passive readers.
• Sponsor fit: A tight match between your content and the sponsor’s product doubles conversion and justifies premium pricing.

If you’re just starting, aim for the lower end of your niche’s range. Once you have case studies showing sponsor ROI—real click-through and conversion data—you can move toward the top quartile.

Where to list your availability

Most solo operators start by mentioning availability in their newsletter footer or a dedicated sponsor page on their site. Tools like Swapstack, Paved, and SparkLoop’s ad network can connect you with sponsors, though they typically take 20–30% of the placement fee.

Direct outreach to brands you already use or cover often yields better rates and longer-term relationships. Send a one-page media kit with your open rate, audience breakdown, and two pricing tiers: primary placement and secondary mention.

If your newsletter runs on Beehiiv, their built-in ad network can match you with sponsors automatically once you hit 500+ subscribers, though CPMs through the network tend to sit at the lower end of these ranges.

Want more data on what’s working in newsletter monetisation? Reply with your niche and list size—I’ll share what operators in similar categories are seeing.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

The Beehiiv Ad Network promises simple monetisation: turn on ads, get paid per thousand opens, skip the sponsor outreach grind. But the earnings data operators share publicly rarely matches what you’ll see in your own dashboard—especially in the first few months.

Here’s what the revenue actually looks like at different scale points, based on anonymised data from five operators running content newsletters between 2,500 and 45,000 subscribers.

The CPM range: $8 to $38 per thousand opens

Beehiiv‘s ad network pays on a CPM basis—cost per mille, or per thousand email opens. The range is wide, and it’s not just about list size.

An operator with 6,200 subscribers in the personal finance niche reported an average CPM of $22 across Q2 2026, with individual sends ranging from $14 to $31. A tech commentary newsletter with 18,000 subscribers averaged $28. A general productivity newsletter with 12,500 subscribers sat at $11.

The biggest CPM driver isn’t audience size—it’s advertiser category match. Finance, SaaS, and B2B newsletters pull higher rates because those advertisers pay more to reach decision-makers. Lifestyle, general productivity, and entertainment newsletters sit at the lower end, often below $15.

Open rate matters too, but indirectly. Beehiiv’s ad network pays per actual open, not per subscriber. If your list has a 45% open rate, you’re monetising 4,500 opens on a 10,000-subscriber send. If it’s 25%, you’re monetising 2,500. The CPM stays the same; your total payout shrinks.

Monthly revenue at different tiers

At 5,000 subscribers with a 40% open rate and two sends per week, you’re looking at roughly 16,000 opens per month. At a $15 CPM, that’s $240. At $25, it’s $400.

At 15,000 subscribers with the same cadence and open rate, you hit 48,000 opens monthly. That’s $720 at $15 CPM, $1,200 at $25.

At 40,000 subscribers, assuming open rates drop slightly to 35% and you send twice weekly, you’re near 112,000 opens per month. At $20 CPM, that’s $2,240. At $30, it’s $3,360.

These numbers assume consistent ad fill rate—Beehiiv doesn’t guarantee an ad in every send. Operators report fill rates between 70% and 95% depending on niche and time of year. In January and September, fill drops. In Q4, it peaks.

When the math breaks down

The ad network becomes less attractive once you can sell direct sponsorships. A single sponsor paying $500 for a dedicated slot in one send to 15,000 subscribers beats four weeks of ad network revenue at typical CPMs—and you control placement, messaging, and relationship.

Operators also report that ad creative quality varies. Some ads are single-line text with a tracking link. Others are multi-paragraph placements that disrupt reading flow. You can reject individual ads, but doing so regularly lowers your fill rate and delays payout timing.

Beehiiv’s payout threshold is $25, and payments process via Stripe 30 days after the calendar month closes. If you earn $18 in July, you won’t see it until you cross $25—possibly September or later if your list is small.

Who should turn it on

The ad network makes sense for operators between 3,000 and 20,000 subscribers who don’t want to manage sponsor relationships yet, or who publish in niches where direct sponsorship deals are hard to close. It’s passive income with near-zero effort once enabled.

It also works as a revenue floor while you build a media kit and test sponsor outreach. You’re not leaving money on the table while you figure out pricing and positioning.

But if you’re over 25,000 subscribers and getting inbound sponsor interest, or if you’re in a high-value niche like SaaS, finance, or developer tools, you’ll earn more by selling direct—even at lower volumes.

Want more breakdowns like this? Reply and tell us what monetisation model you want numbers on next—affiliate rev share, course launch cohorts, or paid community tiers.

Heads up — some links in this article are affiliate links. If you sign up through them, we may earn a small commission at no extra cost to you. We only recommend tools we use ourselves.

If you sell subscriptions—courses, membership sites, premium newsletters—you’ve probably set up Stripe and assumed the billing “just works.” It does, mostly. But the moment a customer upgrades mid-cycle, downgrades two weeks before renewal, or switches plans on day 28 of a 30-day billing period, Stripe’s proration logic kicks in. And unless you’ve tested it yourself, the charge your customer sees may surprise both of you.

How Stripe calculates proration by default

Stripe prorates subscription changes based on unused time. When a customer upgrades from a $10/month plan to a $50/month plan halfway through their billing cycle, Stripe:

• Calculates the unused value on the old plan ($5 remaining)
• Credits that amount toward the new plan
• Charges the difference immediately ($50 – $5 = $45)
• Resets the billing cycle to start today

That last point matters. The customer’s renewal date shifts. If they subscribed on the 1st and upgraded on the 15th, their next charge is now on the 15th of every month—not the 1st.

For downgrades, Stripe credits the unused portion and applies it to the next invoice. The customer pays nothing immediately, but their next bill is reduced. The billing cycle does not reset unless you configure it to.

When proration breaks customer expectations

Most confusion happens when customers upgrade near the end of their billing period. Imagine someone on a $20/month plan upgrades to $100/month on day 28 of 30. Stripe credits roughly $1.33 of unused time and charges $98.67 immediately. Two days later, the customer gets charged the full $100 again.

From Stripe’s perspective, this is correct: the customer upgraded, got credited for two unused days, then hit their new monthly renewal. From the customer’s perspective, they just paid ~$199 in 48 hours.

You can prevent this by disabling proration on upgrades and always charging the full amount immediately, or by using billing cycle anchoring to keep everyone on the same renewal date. The latter is common for SaaS products with tiered plans; the former works better for one-person operations where simplicity beats precision.

Proration settings you can control

Stripe gives you three levers:

• Proration behavior: create_prorations (default), none, or always_invoice
• Billing cycle anchor: Set a fixed day (e.g., 1st of the month) so all subscribers renew together, regardless of when they joined
• Proration date: Override when Stripe calculates the proration from (useful if you’re backdating a plan change)

If you’re running a paid newsletter and using a tool like Memberful or Substack, these settings are abstracted—you won’t see them. But if you’re building on Stripe directly (via API or a WordPress membership plugin), you control all three.

For most solo operators, the simplest setup is:

• Prorate upgrades (charge immediately, reset cycle)
• Don’t prorate downgrades (apply credit at next renewal, keep cycle intact)
• Skip billing cycle anchoring unless you have a strong ops reason (like batched fulfillment)

One non-obvious tip: test with $0.50 test subscriptions

Stripe’s test mode is helpful, but it doesn’t show you what the email receipt looks like or how your payment page renders the proration line item. Before you go live, create a live-mode product priced at $0.50/month and another at $2/month. Subscribe yourself, wait a few days, then upgrade. You’ll see:

• Exactly what Stripe emails your customer
• How the invoice PDF formats proration credits
• Whether your customer portal (if you’ve enabled one) explains the charge clearly

This costs you a few dollars in Stripe fees, but it’s worth it. The default invoice description—”Unused time on [plan name] after [date]”—makes sense to you. It may not make sense to someone who just saw $47 leave their account.

If you’re using Stripe for subscriptions and haven’t touched proration settings, open your dashboard and click into a subscription product. Scroll to “Proration” under advanced settings. If it says “Automatic,” you’re using Stripe’s defaults. That’s fine for most cases—but now you know what happens when a customer clicks “upgrade” on day 29.

Running a subscription business? Reply and tell us which billing edge case surprised you most. We’ll cover it in a future piece.

Solo operators launching video courses don’t usually budget for bandwidth. They budget for hosting, maybe email delivery, occasionally CDN fees. But video bandwidth caps on course platforms catch most creators off guard—and the bills or throttling that follow can kill a launch.

If you’re hosting video on Teachable, Thinkific, Podia, Kajabi, or any other all-in-one course platform, you’re subject to bandwidth limits that aren’t always printed on the pricing page. Some platforms enforce soft caps with overage fees. Others throttle playback speed or pause delivery entirely until the next billing cycle. A few don’t enforce caps at all—until you reach a threshold that triggers a support email asking you to upgrade or migrate.

Here’s what actually happens when you approach 1TB of monthly bandwidth, which platforms enforce what, and how to structure your video library to stay under the wire.

What counts as bandwidth

Bandwidth isn’t storage. Storage is how much disk space your video files occupy. Bandwidth is how much data gets transferred every time someone streams or downloads your content.

If you upload a 500MB video and 100 students watch it in full, you’ve consumed 50GB of bandwidth that month. If 1,000 students watch it, that’s 500GB. Add multiple videos per course, partial rewatches, and mobile users who retry streams after dropping connections, and usage climbs faster than enrollment.

Most platforms count both video streams and file downloads. Some count thumbnail previews and adaptive bitrate variants separately. A few platforms pre-encode video at multiple resolutions (360p, 720p, 1080p) and serve whichever the viewer’s connection requests—but every variant streamed counts against your cap.

Platform-by-platform caps and overages

Teachable doesn’t publish a bandwidth limit on any plan, but enforces a soft cap around 1TB per month. Go over and you’ll get a support email suggesting you upgrade to a custom Enterprise plan or move large files to external hosting (Vimeo, Wistia, YouTube unlisted). Overage fees aren’t automatic; you negotiate them case-by-case.

Thinkific caps bandwidth at 2TB/month on the Pro plan ($199/month) and enforces hard throttling if you exceed it mid-cycle. The Growth plan ($399/month) raises the cap to 5TB. If you hit the limit, video playback slows to buffer every few seconds until the calendar month rolls over.

Podia has no published bandwidth cap and claims unlimited delivery, but community threads report that accounts serving more than 3–4TB/month get flagged for review. Podia’s support typically asks you to compress videos or switch to external hosting rather than charging overages.

Kajabi enforces a 1TB cap on the Basic plan ($149/month), 2TB on Growth ($199/month), and 5TB on Pro ($399/month). Overages cost $1 per additional gigabyte, billed automatically. A single viral week can add hundreds of dollars to your invoice if you’re near the cap.

If you’re using WordPress with a membership plugin (MemberPress, Restrict Content Pro, Paid Memberships Pro) and hosting video files directly, your bandwidth is determined by your hosting plan. Shared hosting typically caps monthly transfers at 1TB; managed WordPress hosts like WP Engine and Kinsta allow 2–5TB depending on tier. Exceed it and you’ll either pay overage fees ($0.10–$0.50/GB) or get throttled until you upgrade.

How to stay under 1TB without compressing quality to death

The most effective fix is offloading video to a specialist platform and embedding it in your course. Vimeo Pro ($20/month) includes 1TB of bandwidth and charges $0.02/GB over that—far cheaper than most course platform overages. Wistia starts at $24/month for 250GB and scales to custom plans with negotiated bandwidth pools.

Both platforms let you embed videos with domain-level privacy (only your course site can play them) and disable download buttons to prevent students from hoarding files locally. You lose native course-platform analytics, but both Vimeo and Wistia offer heatmaps, engagement graphs, and completion tracking you can export or pipe into Zapier.

Another approach: compress videos before upload using Handbrake (free, open-source). A 1080p MP4 encoded at H.264 with a constant rate factor (CRF) of 23 looks nearly identical to CRF 18 but weighs 30–40% less. For talking-head courses with minimal motion, CRF 26 is often imperceptible and cuts file size in half.

If your course platform supports adaptive bitrate streaming, upload only 720p and 1080p variants. Most students on mobile default to 720p, and forcing a 1080p-only stream wastes bandwidth without improving their experience.

When to pay for bandwidth vs. when to change architecture

If you’re spending more than $100/month on bandwidth overages or nearing your cap every cycle, it’s worth splitting video hosting from course delivery. Keep your course platform for enrollment, payment processing, and student dashboards—but serve video from Vimeo, Wistia, or a dedicated video CDN like Bunny Stream ($0.005/GB).

Bunny Stream is the cheapest option for high-traffic courses. You upload once, and Bunny encodes and delivers video globally for half a cent per gigabyte. A course consuming 2TB/month costs $10 in Bunny bandwidth, compared to $200–$400 in platform overages or plan upgrades.

The tradeoff: you lose one-click upload workflows and native progress tracking. You’ll need to embed Bunny’s iframe player manually and connect view events to your course platform via webhook or API. For operators comfortable with light custom code, the savings are worth it. For everyone else, Vimeo or Wistia’s embed-and-forget workflow is the better middle ground.

If you’re launching a video course this year, calculate your expected bandwidth before you pick a platform. Multiply total video file size by estimated student count and average watch rate. Add 20% for retries and partial views. If the result approaches 1TB, either compress harder, plan for external hosting, or budget for overage fees from day one.

Want more breakdowns like this? Subscribe to One Two Three Send—every week we cover the infrastructure, tools, and pricing details that solo operators actually run into.

You publish a buyer’s guide in January. Someone clicks your affiliate link, browses for twenty minutes, then closes the tab. Thirty-one days later, they come back through organic search, remember your recommendation, and buy. You earn nothing.

That’s not a edge case—it’s how most affiliate revenue leaks out of evergreen content strategies. Cookie windows and content lifespan operate on completely different timescales, and most solo operators don’t account for the gap.

How cookie windows actually work

An affiliate cookie window is the period between when someone clicks your link and when a sale must occur for you to earn commission. The standard is 30 days. Some programs offer 7 days. A handful—Amazon Associates, for example—give you 24 hours for most categories.

Once that window closes, the tracking pixel expires. If the buyer returns through any other path (direct URL, branded search, a different affiliate’s link), you’re out. The sale happens, but the attribution is gone.

This works fine for time-sensitive content: weekly deal roundups, launch coverage, limited-time promotions. A reader clicks, decides quickly, and converts within the window. But it falls apart for evergreen content—comparison posts, tutorial-driven recommendations, long-form buying guides.

Why evergreen content breaks the model

Evergreen posts drive traffic for months or years. A single how-to article might get 200 visits in month one, 180 in month six, and 150 in month twelve. Readers arrive at different stages of intent. Some are researching early. Others are ready to buy but want one last confirmation.

The mismatch: your content stays relevant for eighteen months, but your affiliate window closes in thirty days. A reader who clicks your link in March and buys in April costs you the commission, even though your content directly influenced the decision.

This isn’t hypothetical. I’ve tracked this across three affiliate-driven sites. Conversion rates on evergreen posts hover around 2–4% in the first 30 days after publish. But buyer behavior data—tracked via UTM parameters and CRM integrations—shows that 18–25% of eventual purchasers return more than 30 days after their first visit.

The longer your content stays live, the more you lose to expired cookies.

What actually works

You can’t extend someone else’s cookie window, but you can adjust strategy to work within it.

Optimize for high-intent traffic. Evergreen content can target early-stage research (“what is X?”) or late-stage decision-making (“X vs. Y for [specific use case]”). The second group converts faster. If your affiliate window is short, bias your content mix toward comparison posts, feature breakdowns, and use-case-driven recommendations. These attract readers closer to purchase.

Reactivate older posts with fresh links. Update evergreen articles every 90–120 days. Refresh the intro, add a new example, adjust pricing details—anything that gives you an excuse to re-promote the post via email or social. New clicks = new cookie windows. This works especially well if you’re driving your own email list to older content.

Layer in shorter-window programs strategically. If you’re reviewing tools with both direct affiliate programs (30–60 day windows) and network aggregators like Impact or ShareASale (often 7–14 days), use the network links only in time-sensitive contexts—launch posts, limited offers, deal alerts. Reserve the longer-window programs for evergreen content.

Track first-touch attribution separately. Most affiliate dashboards show you last-click conversions. But if you run UTM parameters on your affiliate links and feed them into a simple CRM or Google Sheets via Zapier, you can see how many people clicked, didn’t convert, then returned later via another path. That data won’t earn you retroactive commissions, but it will show you which posts are under-monetized and worth doubling down on with email sequences or retargeting.

When it’s better to skip affiliates entirely

If your content is genuinely evergreen—think foundational how-to guides that rank for two-plus years—and your affiliate program uses a 7- or 14-day window, conversion math often doesn’t pencil out. You’re better off monetizing with sponsorships, display ads, or your own product inserts.

A single sponsored mention in a high-traffic evergreen post can earn $300–$800 upfront, with no dependency on cookie windows or conversion rates. That’s predictable revenue. Affiliate commissions on the same post might trickle in at $40–$120 per month, heavily weighted toward the first 60 days, then taper as cookie expirations compound.

Run the numbers for your own traffic and conversion rates. If evergreen posts make up more than 60% of your page views and your primary affiliate programs use windows under 21 days, you’re likely leaving money on the table by not diversifying monetization.

Want more revenue breakdowns like this? Subscribe to One Two Three Send and get operator-focused strategy every week—no fluff, no generic advice.