Category: Monetisation

Most newsletter operators publish a sponsorship rate card somewhere: a media kit PDF, a “work with me” page, a Passionfroot profile. The numbers look clean. $500 for 5,000 subscribers. $2,000 for 25,000. CPM of $40.

Almost nobody pays those rates.

After reviewing anonymized deal data from 47 newsletter operators who closed at least one sponsor in the last six months, the median discount from published rates sits at 22%. One in five deals closed at half the card rate or lower. Only 11% of sponsors paid the published number without negotiation.

The gap isn’t a problem—it’s how sponsorship markets work. But if you’re building a rate card or fielding inbound sponsor requests, knowing where the floor actually sits changes how you price and negotiate.

Why published rates run high

Rate cards serve as anchors, not contracts. Sponsors expect to negotiate. If you publish $1,000 and accept $800, you’ve left room to move while protecting margin. If you publish $600 and get talked down to $400, you’ve priced yourself into a corner.

Operators also use tiered pricing to reward frequency. A one-time sponsor at $1,200 becomes $950 per insertion for a four-week buy. The card shows the high end; the deal sheet shows volume discounts.

But the bigger reason is segmentation. A B2B SaaS sponsor with a $15,000/month ad budget will pay your card rate—or close to it. A bootstrapped indie founder selling a $40 info product will ask for 60% off. If you publish only one number, you either lose the high-end deal or alienate the small operator.

What sponsors actually pay

Here’s the breakdown from the 47-operator sample, segmented by list size:

• Under 2,500 subscribers: Median deal value $150. Published rate cards averaged $300. Effective discount: 50%.
• 2,500–10,000 subscribers: Median deal value $520. Published rates averaged $750. Effective discount: 31%.
• 10,000–50,000 subscribers: Median deal value $1,400. Published rates averaged $1,850. Effective discount: 24%.
• Above 50,000 subscribers: Median deal value $3,200. Published rates averaged $3,800. Effective discount: 16%.

The discount narrows as list size grows. Larger lists attract professional media buyers who treat sponsorships as line items, not favors. Smaller lists draw peer operators, affiliates, and early-stage founders who negotiate harder and expect discounts as relationship currency.

When to hold the line

Some operators never discount. They close fewer deals, but margin stays high and negotiation overhead drops to zero. This works if:

• Your audience is specific and hard to reach elsewhere (e.g., CFOs at venture-backed startups, WordPress plugin developers).
• You have strong sponsor demand and can afford to turn down 40% of inbound requests.
• You’re positioning as premium and discount signals weaken brand equity.

If you’re below 5,000 subscribers and still building sponsor pipeline, holding rate-card pricing will cost you deals. Most early sponsors come from your network, cross-promotions, and affiliate offers—all of which expect negotiated rates or rev-share instead of flat fees.

How to price your card

Start with the number you’d accept without flinching, then add 30%. If $400 feels fair for a single sponsor slot, publish $520–550. When someone asks for a discount, you can move to $450 and both parties feel like they negotiated.

Separate your card into tiers: one-time rate, four-week package, and annual partnership. Publish only the one-time rate on your site. Save package pricing for the proposal stage, where you control context and can frame discounts as volume incentives rather than concessions.

If you’re using a sponsor network (Passionfroot, Swapstack, Paved), remember they show your rate publicly and take 10–30% of each deal. Price those cards higher than your direct inbound rate to preserve margin after the platform cut.

One last thing: Track every deal you close—rate offered, rate accepted, sponsor type, and whether they renewed. After ten sponsors, you’ll see your real pricing floor. Ignore the card. Price to that floor, then raise it when demand outpaces inventory.

If you’re running sponsorships and want to compare notes on deal structure or pricing models, reply to this email—I’m collecting operator data for a follow-up piece on rev-share vs. flat-fee sponsor deals.

Stripe gives you two ways to collect one-time payments without building a checkout page: invoices and payment links. Both generate a URL you can send to a customer. Both accept cards and wallets. Both land money in your account.

But they’re built for different workflows, and if you pick the wrong one, you’ll wait longer to get paid—or spend unnecessary time on support tickets.

What each tool actually does

A Stripe invoice is a billing document with a due date. You create it in the dashboard or via API, add line items, set payment terms (due on receipt, net 7, net 30), and send it to a customer email. Stripe emails a branded invoice with a “View and pay” button. The customer opens it, enters payment info, and Stripe marks it paid.

A payment link is a one-click checkout page. You create it once, get a URL like buy.stripe.com/test_abc123, and reuse it indefinitely. Anyone with the link can pay immediately. No due date, no recipient email required upfront. You can embed it in an email, a tweet, or a landing page.

Invoices assume you know who owes you money. Payment links assume you’re distributing a link and collecting from whoever shows up.

Speed: when the money actually moves

Payment links charge cards instantly. A customer clicks, enters their details, and the transaction processes in under 10 seconds. Stripe’s standard payout schedule applies—two business days for US accounts, longer elsewhere—but the clock starts the moment the customer hits “Pay.”

Invoices introduce lag. Stripe sends the email, but the customer has to open it, decide to pay, and click through. If you set a net-7 or net-30 term, Stripe won’t even attempt to charge until that date. Even “due on receipt” invoices sit in inboxes. In practice, invoice payments arrive 24 to 72 hours later than payment-link transactions for the same customer, simply because of the extra step.

If you’re a solo operator sending a client a bill for a $2,000 project, that delay might not matter. If you’re running a workshop with 40 seats and you need to confirm headcount by Friday, payment links close sales faster.

Disputes and partial payments

Invoices support partial payments out of the box. A customer can pay $500 now and $500 next week on the same invoice. Stripe tracks the balance and marks it paid when it hits zero. Payment links don’t support this—they’re all-or-nothing transactions.

For chargebacks, both tools handle them identically. Stripe debits your account, you upload evidence, and the card network decides. The invoice vs. payment-link distinction doesn’t affect dispute outcomes.

But invoices generate a PDF receipt automatically, with your business details, line-item descriptions, and tax breakdowns. Payment links generate a Stripe receipt email, which is fine for consumers but looks less formal if you’re billing another business. If your client needs a PDF to submit to accounting, you’ll end up generating one manually anyway.

Invoices also support attaching files—contracts, scope docs, terms. Payment links don’t.

Customer data and repeat billing

Invoices require a customer email before you send them. Stripe creates a customer record automatically and ties the payment to it. That makes follow-up billing trivial—you have their card on file (if you enabled “save payment method”), and you can issue another invoice or start a subscription without asking for details again.

Payment links create a customer record only if you enable “Collect customer addresses” or “Collect phone numbers” in the link settings. If you don’t, Stripe processes the payment but doesn’t store the email in a structured customer object. You get a transaction, but not a contact you can bill again without manual setup.

For one-off sales to strangers, that’s fine. For repeat clients, it’s friction you don’t want.

When to use which

Use payment links when:

• You’re sharing a link publicly or embedding it in content
• You want the fastest time-to-payment
• You’re selling to people you don’t know yet
• You don’t need partial payments or formal invoicing language

Use invoices when:

• You’re billing a known client or business
• You need a paper trail with line items and tax details
• You want to offer net terms or partial payments
• You plan to bill this customer again and want their details saved

Pricing and limits

Both tools use the same Stripe transaction fee: 2.9% + $0.30 per successful charge in the US. No extra cost for choosing one over the other.

Payment links have no monthly limit. Invoices are capped at 100 sent per hour via the API (effectively unlimited for solo operators), but Stripe can flag your account if you send thousands of invoices in a day without prior volume history.

Both tools work on Stripe’s free tier. No subscription required.

If you’re handling client work and workshops in the same business, keep both in rotation. Payment links for fast, public sales. Invoices for repeat clients and anything that needs to look like a real bill.

Want more breakdowns like this? Subscribe to One Two Three Send for tool comparisons, workflow fixes, and operator-to-operator notes every week.

You sold $5,000 worth of courses last month. Stripe’s dashboard confirms it. Your bank account shows $4,200. The difference isn’t a mystery—it’s just that nobody walks you through the cascade of fees, holds, and timing gaps that sit between a customer’s payment and your actual cash.

Here’s what actually happens to your money, in order, and what you’ll see at each stage.

The payment arrives—minus processing fees

When a customer pays $100, the payment processor takes its cut immediately. Stripe charges 2.9% + $0.30 per transaction for most U.S. cards. That’s $3.20 gone before the money even enters your account balance.

PayPal is 3.49% + $0.49 for standard transactions—$3.98 on that same $100. If you’re using Gumroad, they take 10% on the free plan, which includes processing fees. On a $100 sale, you’re down to $90 before anything else happens.

These fees show up as line items in your dashboard, but they never touch your bank. The net amount—what’s left after processing—is what gets queued for payout.

Payout schedules and rolling reserves

Most processors don’t pay you instantly. Stripe’s default payout schedule is two business days in the U.S. If you sell something on Monday, you’ll see the money in your bank on Wednesday—assuming no holds.

New accounts, accounts with sudden revenue spikes, or high-risk categories (digital products, coaching, info products) often trigger rolling reserves. Stripe might hold 10–30% of each transaction for 30–90 days. If you made $5,000 but 20% is in reserve, only $4,000 moves toward your bank. The rest sits in limbo.

You won’t always get notified when a reserve is applied. Check your payout report in the dashboard—if “Reserved funds” has a balance, that’s money you’ve earned but can’t access yet.

Refunds, chargebacks, and clawbacks

If a customer requests a refund, the processor reverses the transaction and pulls the money back from your next payout. You don’t just lose the sale—you also lose the processing fee. Stripe doesn’t refund their 2.9% + $0.30 when you issue a refund. You’re out the fee twice: once when the customer paid, once when they didn’t.

Chargebacks are worse. The customer disputes the charge with their bank, and the processor pulls the money back immediately—even if the dispute is weeks old. Stripe charges a $15 chargeback fee on top of the lost sale. PayPal charges $20.

If you’re running a subscription product and a customer’s card expires, some platforms will retry the charge multiple times. Failed retries don’t cost you fees, but successful retries after a gap can reset your payout schedule.

Platform fees on top of payment fees

If you’re selling through a course platform, membership site, or marketplace, they take a cut too. Teachable takes 10% of each sale on the Pro plan ($159/month). Kajabi doesn’t take a transaction fee, but you’re paying $149–$399/month in platform costs.

Gumroad’s 10% includes payment processing, but that’s still double what you’d pay with Stripe + a standalone site. On $5,000 in sales, that’s $500 to Gumroad vs. ~$150 in Stripe fees if you handle fulfillment yourself.

These platform fees usually come out before the money reaches the payment processor, so your Stripe dashboard will only show the net revenue after the platform’s cut. If Gumroad shows $5,000 in sales, Stripe sees $4,500, and you get $4,500 minus processing fees.

What you actually see in your bank

Let’s say you sold $5,000 in a month. Here’s the realistic breakdown:

• Payment processing fees (2.9% + $0.30 average): ~$150
• Platform fee (if applicable, e.g., 10%): $500
• Rolling reserve (20%, held for 60 days): $870 (on the net $4,350)
• One refund ($100 sale): -$103.20 (includes lost processing fee)
• One chargeback ($50 sale): -$66.45 (sale + original fee + $15 chargeback fee)

Your bank sees roughly $2,810 in the first payout cycle. The reserved $870 trickles in over the next two months. The refund and chargeback are just gone.

This isn’t a complaint about processors—it’s just how the system works. But if you’re forecasting cash flow or trying to figure out why your revenue and bank balance don’t match, this is the gap.

Track net revenue, not gross

Most operators track gross sales because that’s the number platforms show you first. It feels good to say you made $5,000. But your actual operating cash is 15–30% lower, depending on fees, holds, and disputes.

Build a simple spreadsheet that logs gross sales, processing fees, platform fees, refunds, chargebacks, and reserved amounts. Update it weekly. Your accountant will thank you, and you’ll stop wondering where the money went.

If you want a cleaner view, connect your payment processor to a tool like QuickBooks Self-Employed or Wave. Both pull transaction data automatically and separate fees from revenue. You’ll see exactly what hit your bank and what didn’t.

What’s one payment fee or hold that surprised you the first time you saw it? Reply and let me know—I’m curious what trips up operators most.

You upload a 2GB video file to your course platform. The progress bar hits 100%. You refresh the page—and the video still isn’t playable. Instead, you see “Processing” or “Encoding in progress.”

What’s happening isn’t a bug. It’s transcoding: the platform is converting your uploaded file into multiple formats and resolutions so learners on different devices and bandwidths can stream it smoothly. But most operators don’t know what’s actually being created, how long it takes, or when pre-encoding on your own machine saves hours of waiting.

What transcoding creates

When you upload a single .mp4 file, the platform generates:

• Multiple resolutions: 1080p, 720p, 480p, and sometimes 360p. Adaptive bitrate streaming (ABR) lets the player switch resolutions mid-playback based on the viewer’s connection speed.
• Audio-only streams: A separate audio track for mobile users on metered data.
• Thumbnail images: Usually extracted at the 5-second mark or generated from the first keyframe.
• Closed-caption tracks (if enabled): Some platforms auto-generate .vtt or .srt subtitle files using speech-to-text.

Platforms like Teachable, Thinkific, and Kajabi handle this server-side. You upload once; they generate four to six derivative files. For a 60-minute 1080p video at 30fps, expect transcoding to take 15–45 minutes depending on platform load.

When transcoding stalls

Three scenarios slow or break the process:

Variable frame rate (VFR) source files. Screen recordings from tools like OBS or Loom sometimes use VFR to save file size. Transcoders expect constant frame rate (CFR). If your upload takes longer than expected or fails silently, re-encode to CFR using Handbrake (preset: “Fast 1080p30”) before uploading.

Non-standard codecs. Most platforms expect H.264 video and AAC audio. If you shot in ProRes, HEVC, or VP9, the transcoder may reject the file or produce a low-quality output. Check your export settings: H.264, AAC, .mp4 container, and progressive scan (not interlaced).

Peak-hour congestion. Transcoding is compute-intensive. Platforms batch-process uploads. If you upload at 9 a.m. EST on a Tuesday when everyone else is launching courses, your video joins a queue. Mid-afternoon or evening uploads often finish faster.

When to pre-encode locally

If you’re uploading more than five videos in a session, pre-encoding saves platform processing time and gives you control over quality.

Use Handbrake (free, cross-platform) with these settings:

• Preset: “Fast 1080p30” or “HQ 1080p30 Surround” if you have multichannel audio
• Format: MP4
• Video codec: H.264, constant quality RF 20–22 (lower number = higher quality)
• Audio codec: AAC, 128 kbps stereo
• Framerate: Constant, 30fps (or 25fps for PAL regions)

A 60-minute talking-head video at RF 22 outputs around 800MB–1.2GB. The platform still transcodes it, but processing time drops by 30–50% because the source is already optimized.

What you lose with platform transcoding

Most platforms cap output at 1080p even if you upload 4K. Kajabi, Teachable, and Thinkific all downsample. If you want to deliver 4K to learners, you’ll need to self-host with a video CDN like Bunny.net or Mux—but that adds $20–$200/month depending on bandwidth.

Platform transcoders also strip metadata. Chapter markers, embedded subtitles, and custom thumbnails uploaded in your video file are ignored. You’ll need to add those through the platform’s interface after transcoding finishes.

If you’re launching a course in the next 48 hours and uploading a dozen videos, start three days early. Transcoding delay is the most common reason course launches miss their scheduled time.

Want more operator tactics like this? Subscribe to One Two Three Send—one article every morning on the tools, infrastructure, and strategy behind online businesses.

If you’ve ever uploaded a 2.1 GB course video to a platform with a 2 GB file limit, you know the frustration: some platforms reject it instantly, some let it upload for 45 minutes before failing, and some accept it but never process it.

The boundary behavior—what happens when you hit or exceed a platform’s stated limit—varies wildly across course hosting tools. And because most operators don’t test edge cases until launch week, these differences cost time, bandwidth, and occasionally subscriber trust.

Here’s what actually happens when you push the limits on three major platforms, and how to plan around their quirks.

Teachable: hard stop at upload start

Teachable enforces a 3 GB per-file limit for video uploads on all plans. If your file is 3.01 GB, the upload dialog won’t start. You’ll see an error message immediately: “File exceeds maximum size.”

This is the cleanest failure mode. You know right away, before burning bandwidth or time. The downside: Teachable doesn’t compress or transcode client-side, so if your raw export is 3.2 GB, you need to re-encode it before upload. There’s no “let the platform handle it” option.

Workaround: use Handbrake or similar to target H.264 at a slightly lower bitrate. For most 1080p talking-head content, 4 Mbps video gets you under 2.5 GB for a 90-minute lesson without visible quality loss.

Kajabi: accepts upload, fails silently during processing

Kajabi’s stated limit is 5 GB per file, but the real ceiling depends on your plan and whether you’re uploading via browser or the bulk uploader. On the Basic plan, files over 4 GB often upload successfully—progress bar completes—but then sit in “Processing” indefinitely.

No error email. No dashboard alert. The file just never becomes available to students. If you don’t manually check back 12 hours later, you won’t know it failed.

This is the worst failure mode for operators. You’ve burned upload time, you think the content is live, and students see a blank lesson or a spinner.

Workaround: keep files under 3.5 GB even if your plan technically allows 5 GB. And always check the “Processed” timestamp in the library view before publishing a course.

Thinkific: queues large files, then downgrades quality

Thinkific’s limit is officially 5 GB, but files over 2 GB enter a slower processing queue. Upload completes normally, but transcoding can take 6–24 hours depending on platform load. During that window, students see a “Video is processing” message.

Once processed, Thinkific applies adaptive bitrate streaming. But if your source file is large and high-bitrate, the platform may serve a lower-quality version to students on slower connections—even if you uploaded 1080p.

This isn’t a failure, but it’s a surprise. Your 4K export might stream at 720p for 40% of viewers.

Workaround: upload a clean 1080p H.264 file at 5–8 Mbps. That’s high enough for quality, low enough that Thinkific won’t aggressively downgrade. And schedule uploads at least 48 hours before launch.

What about Vimeo or Wistia embeds?

If you host video externally and embed it in your course platform, you bypass the platform’s file limits entirely. Vimeo Pro allows 20 GB per file; Wistia has no hard cap but recommends under 8 GB for optimal processing.

The trade-off: you’re now managing two dashboards, two sets of analytics, and two potential points of failure. And some course platforms (Teachable included) don’t pass completion tracking reliably when you use third-party embeds. Students can watch the full video but the lesson won’t mark complete.

This works well for operators who already have a Vimeo or Wistia account for other content, but it’s not a universal fix.

One non-obvious tip: test with a disposable file first

Before uploading your final course content, create a test file at exactly your platform’s stated limit plus 10%. Use a screen recording tool or export a low-content video at high bitrate to hit the target size.

Upload it to a draft course. Wait 24 hours. Check if it processed, if quality degraded, if it triggered any backend errors.

This takes 20 minutes and saves you from discovering boundary behavior during a launch.

If you’re building a course business and want more operator-level breakdowns like this, subscribe to One Two Three Send—we cover the tooling details other newsletters skip.

Beehiiv‘s Ad Network promises to connect newsletter operators with premium sponsors without the cold-outreach grind. But between clicking “Apply” and seeing your first ad impression, there’s a review process that isn’t clearly documented anywhere in the dashboard.

If you’re planning to monetise through the network, here’s what actually happens during approval—and what slows it down.

What the review team checks

Beehiiv‘s Ad Network approval isn’t automated. A human editor reviews three things:

• Subscriber count and engagement. The official threshold is 2,500 subscribers, but approval rates climb significantly above 5,000. More importantly, they check recent open rates. If your last five sends averaged below 30%, expect a rejection or a request to reapply later.
• Content consistency. They’re looking for a defined niche and a regular publishing cadence. If your archive shows three posts in January and then nothing until August, that’s a red flag. Brands want predictable inventory.
• Brand safety. The editor skims your last 10–15 issues for anything that might spook advertisers: excessive profanity, polarising political content, or anything that violates Beehiiv’s acceptable-use policy. This isn’t about ideology—it’s about whether a SaaS company will feel comfortable placing a banner next to your prose.

One non-obvious detail: they also check whether you’re already running direct sponsorships. If you are, that’s actually a positive signal. It shows you understand ad placement and have an audience advertisers value.

The actual timeline

Beehiiv’s help docs say “up to five business days.” In practice, most approvals land within 48–72 hours. Rejections come faster—often within 24 hours.

But here’s where it gets slow: if your application is borderline, it gets escalated to a second reviewer. That adds another three to five days. And if you’re flagged for manual subscriber verification (usually because your list grew unusually fast or your domain is very new), expect a week or more.

If you haven’t heard back in seven business days, reply to your original application email. Don’t open a new support ticket—that resets the queue.

What happens after approval

Approval doesn’t mean ads start immediately. You’re added to the network’s inventory pool, and advertisers choose placements based on audience fit, niche, and available budget.

For newsletters under 10,000 subscribers, it’s common to wait two to four weeks before your first ad runs. Larger lists (25,000+) typically see their first placement within a week.

Once you’re live, Beehiiv’s system automatically inserts ads into your sends based on the placement settings you choose: top, middle, or bottom. You set a frequency cap (e.g., one ad per issue), and the network fills it when a match is available. If no advertiser is queued, the slot stays empty—your issue goes out ad-free.

Revenue is CPM-based, and Beehiiv takes a 25% platform fee. Rates vary widely by niche, but most operators report $8–$15 CPM after the split. Payments are net-60, processed through Stripe.

When to apply—and when to wait

If you’re sitting at 2,600 subscribers with a 28% open rate and inconsistent publishing, wait. You’ll likely get rejected, and reapplying within 90 days rarely changes the outcome unless your metrics improve significantly.

Better to hit 5,000 subscribers, lock in a weekly cadence for two months, and then apply. Your approval odds jump, and you’ll have enough volume to make the CPM model worthwhile.

If you’re already running direct sponsorships at $300–$500 per placement, do the math before switching. The Ad Network is lower-friction, but direct deals almost always pay better for lists above 10,000 subscribers.

Want more breakdowns like this? Subscribe to One Two Three Send for weekly deep-dives on the tools and tactics that power online businesses.

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.

Walk through the back end of most solo-operated businesses and you’ll find at least two payment processors wired up: Stripe for subscriptions and one-clicks, PayPal for the holdouts who won’t touch a credit card form, maybe a third regional option if you serve international customers hard.

The logic makes sense on paper. More payment options theoretically means fewer abandoned carts. But dual processor setups introduce reconciliation overhead, split your transaction history across dashboards, and double your compliance surface area. For a lot of operators, the second processor is dead weight.

Here’s how to figure out whether you actually need both—and what the math looks like when you don’t.

What dual processors actually cost you

The direct fees are visible: Stripe charges 2.9% + $0.30 per transaction in the U.S., PayPal runs similar rates but adds a fixed fee for certain cross-border transactions. If your average order is $47 and you process 120 transactions a month across both platforms, the percentage fees are roughly equivalent.

The hidden cost is operational. You’re logging into two dashboards to pull reports. Your accounting workflow imports two CSVs. Refunds, disputes, and chargebacks follow different processes. If you’re running a subscription model, you’re managing two sets of dunning logic, two retry schedules, two places where a customer’s card can fail.

One operator I spoke with last month was processing $11,400 monthly revenue—78% through Stripe, 22% through PayPal. She spent 90 minutes each month reconciling the two, manually matching PayPal transactions to her CRM because her automation tool couldn’t reliably handle both feeds. At $150/hour effective rate, that’s $225/month in reconciliation labor to preserve $2,508 in PayPal revenue. The margin was there, but barely.

When two processors make sense

There are clear cases where parallel processors pay off:

• Geographic coverage gaps. If you serve customers in regions where Stripe doesn’t operate or where PayPal has significantly better local currency support, the second processor isn’t optional—it’s infrastructure.
• Customer concentration risk. If one processor represents 95% of your revenue and that account gets frozen during a routine compliance review, you’re dead in the water. A second processor acts as insurance, especially if you’re in a higher-risk category like digital downloads, consulting, or anything with delayed delivery.
• Measurably different conversion rates. Some audiences simply won’t convert without PayPal. If A/B tests show that offering PayPal increases completed checkouts by 12% or more, and your average customer value justifies the added complexity, keep both.

But most operators I’ve reviewed don’t fit these profiles. They added PayPal three years ago because a handful of customers asked for it, and it’s been running on autopilot ever since.

How to audit your processor split

Pull the last 90 days of transaction data from both platforms. You’re looking for three numbers:

Volume distribution. What percentage of transactions flow through each processor? If one handles less than 10% of total volume, you’re maintaining an entire integration for edge cases.

Revenue per transaction. Calculate average order value by processor. If your PayPal transactions average $23 and your Stripe transactions average $68, you’re using PayPal for low-value impulse buyers and Stripe for your core customers. That’s fine if the volume justifies it, but if those $23 orders represent 6% of monthly revenue, you’re over-indexed on supporting them.

Dispute and refund rates. Pull your chargeback and refund rates by processor. If one consistently runs 3x the dispute rate of the other, you’re absorbing higher operational friction and potentially higher fees for that segment.

One operator dropped PayPal after discovering that 91% of their PayPal transactions were under $15, with a 9% refund rate compared to 2% on Stripe. The hassle of managing two systems wasn’t worth the $340/month in low-margin revenue.

What happens when you consolidate

Expect some falloff. When you remove a payment option, a small percentage of customers won’t convert. Industry benchmarks suggest 5–8% of buyers abandon checkout when their preferred payment method disappears.

But that’s gross abandonment, not net revenue loss. Many of those buyers come back and pay with the remaining option. Others were bottom-of-funnel browsers who weren’t going to convert anyway. The actual revenue loss tends to be 2–4% in the first month, then levels off.

The flip side: your reconciliation time drops to near zero, your dunning logic runs on one system, and your accounting close gets 40% faster. For most operators, that trade makes sense once one processor dips below 15% of total revenue.

If you’re still on the fence, try this: turn off the secondary processor for two weeks and measure what happens. Route 100% of traffic through your primary processor, track conversion rate and completed transactions daily, and see whether the drop is material. If you lose less than the cost of managing two systems, make the cut permanent.

One last thing: if you found this useful, you’ll want the next one. Subscribe to One Two Three Send and get operator-focused breakdowns like this in your inbox twice a week.

Affiliate link cloaking—redirecting yoursite.com/recommends/tool to partner.com/?ref=yourID—works until it doesn’t. And when it stops, you often won’t know until commissions disappear.

Platform redirect policy changes happen quietly. Amazon updated theirs in early 2025, requiring tag= parameters to appear in the original click, not after a 301. Pinterest changed how it crawls redirects in late 2024, treating multi-hop chains as suspicious. TikTok’s in-app browser now strips certain query parameters on the second redirect.

Most affiliate dashboards don’t tell you why a click didn’t convert. They show impressions, clicks, and sales—but the gap between click and sale stays opaque. If your cloaked link triggers a policy violation, the click registers, the redirect happens, but the attribution dies.

What redirect chains actually look like

A typical cloaked affiliate link creates at least two hops:

• Hop 1: Reader clicks yoursite.com/recommends/tool
• Hop 2: Your server issues a 301 or 302 to partner.com/?ref=yourID
• Hop 3 (sometimes): Partner platform redirects again to the actual product page

Each hop adds latency—30 to 150 milliseconds depending on server location and DNS lookup. More importantly, each hop is a point where attribution can break. If the affiliate network expects the referrer header to match your domain, but a browser extension or VPN strips it mid-chain, the sale won’t attribute.

Link management plugins like Pretty Links, ThirstyAffiliates, and Lasso handle the redirect, but they can’t control what happens after the hand-off. If Amazon decides your redirect pattern looks like a masked URL shortener, it won’t tell your plugin—it just stops crediting conversions.

When platforms change the rules

Three recent examples that broke established cloaking setups:

Amazon Associates began enforcing stricter referrer validation in Q1 2025. Links that redirect through a non-whitelisted domain now require the associate tag in the first URL, not the final destination. If your cloak is yoursite.com/amazon/product and it redirects to amazon.com/dp/B08XYZ?tag=yourID, Amazon may not credit it unless tag=yourID appears in the cloaked URL itself—which defeats the purpose of cloaking.

Impact Radius and ShareASale both tightened multi-hop detection in 2024. Links that pass through more than two redirects before landing on the merchant site trigger fraud flags. If you’re using a link shortener and a cloak and the merchant uses its own redirect layer, you’ve hit three hops—and the click may not count.

Social platform in-app browsers are the silent killer. TikTok, Instagram, and LinkedIn all use custom WebView browsers that strip or modify query parameters unpredictably. A cloaked link that works fine in Chrome may lose its affiliate ID when opened inside the TikTok app. You won’t see an error—the link just opens without attribution.

What to monitor and when to adapt

Most operators only notice redirect problems when monthly commissions drop without a corresponding traffic dip. By then, you’ve lost weeks of sales.

Set up a monthly check:

• Compare click-through rate to conversion rate in your affiliate dashboard. If CTR holds steady but conversions drop 20%+, suspect redirect breakage.
• Test your cloaked links in incognito mode across browsers and devices. Open them in the TikTok app, Instagram in-app browser, and LinkedIn mobile. Check the final URL in the address bar—does your affiliate ID survive?
• Run a redirect chain audit using a tool like Redirect Path (browser extension) or the command-line tool curl -I. Count the hops. Three or more is a red flag.

If you discover a broken chain, you have two options: simplify the redirect or switch to direct affiliate links with branded slugs (e.g., yoursite.com/go/tool that’s visible but still trackable). Some operators now use branded short domains—recs.yourname.com/tool—to keep links clean without full cloaking.

One more thing: if you’re driving significant affiliate revenue—over $2,000/month from a single program—ask your affiliate manager if your redirect setup is compliant. Most will tell you. Some will whitelist your domain to bypass restrictive filters. It’s worth the email.

Got a redirect mystery or a link setup that stopped working? Reply to this email—I’ll dig into it for a future piece.

If you’re running a content business on fan contributions, the three weeks between earning $500 and having it in your bank account can be the difference between making payroll and missing it.

Patreon, Ko-fi, and Buy Me a Coffee all let audiences send you money, but their payout schedules, fee structures, and hold policies differ enough that choosing the wrong one can cost you hundreds of dollars in delay or processing costs every month.

Here’s how each platform actually works when it comes to getting your money.

Patreon: monthly batching with a five-day hold

Patreon batches member payments on the first of every month (or on your custom billing date if you’re on their legacy per-creation model). Once those payments clear, Patreon holds the funds for five business days before initiating a payout to your bank account.

That means if you earn $1,200 from 40 patrons on October 1, you’ll see the money in your account around October 8–10, depending on your bank’s processing time.

Patreon takes 5% to 12% depending on your plan tier (Lite, Pro, or Premium), plus payment processing fees of roughly 2.9% + $0.30 per transaction. If you’re on the Lite plan at 5%, you’re netting about $1,026 from that $1,200—assuming all payments succeed.

Failed payments get retried automatically for up to a week, but if a patron’s card declines and doesn’t recover, you don’t get paid for that month. Patreon doesn’t front you the money.

Ko-fi: instant payout option, but only on Premium

Ko-fi offers two modes: free and Premium ($108/year as of September 2026).

On the free plan, Ko-fi holds payments for up to 30 days before releasing them to your PayPal or Stripe account. That’s a full billing cycle—longer than Patreon.

On the Premium plan, you unlock instant payouts. Supporters’ payments land in your connected Stripe or PayPal account within minutes, and you control when to transfer that balance to your bank. For most operators, that’s a 2-day ACH transfer via Stripe or a same-day PayPal withdraw (for a 1.5% fee).

Ko-fi takes 0% platform fee on Premium. You pay only Stripe or PayPal’s standard processing fees: roughly 2.9% + $0.30 per transaction. That same $1,200 month nets you about $1,161 after processing, assuming 40 × $30 one-time tips.

The catch: if you’re using Ko-fi’s monthly membership feature (their Patreon alternative), payouts are still monthly, not instant—even on Premium.

Buy Me a Coffee: weekly or monthly, depending on volume

Buy Me a Coffee operates on a hybrid schedule. Small accounts (under $1,000/month) get paid monthly, around the 10th of the following month. Larger accounts graduate to weekly payouts once you cross that threshold consistently.

There’s no platform fee—Buy Me a Coffee takes 5% only on tips sent through their iOS or Android apps (to cover Apple/Google’s 30% cut). Web-based tips are fee-free aside from payment processing at 2.9% + $0.30.

If you earn $1,200 in September via the web, you’ll receive roughly $1,161 around October 10. If you’ve crossed into weekly payouts, you’d get four transfers of ~$290 each, landing every Friday.

One quirk: Buy Me a Coffee holds payouts for 7 days on your first three transactions as a new account, regardless of volume. After that, the monthly or weekly schedule kicks in.

Which one to pick

If you need cash flow predictability and can absorb a five-day delay, Patreon works well for membership models with recurring monthly supporters. The fee structure is higher, but the audience expects to support creators there, and discovery features can drive new patrons.

If you want instant access to funds and you’re okay paying $108/year, Ko-fi Premium is the fastest route—especially for one-time tips or project-based funding. Monthly memberships still batch, though.

If you’re just starting out or you don’t want to pay an annual fee, Buy Me a Coffee splits the difference. You’ll wait longer initially, but once you hit weekly payouts, you’re getting money almost as fast as Ko-fi without the subscription cost.

All three platforms work. The one that fits depends on whether you value speed, cost, or audience expectations more. If you’re choosing between them, model out your monthly volume, multiply by each platform’s effective fee rate, and map your cash flow needs against their payout schedules. The right answer shows itself in a spreadsheet.

Which platform do you use, and has payout timing ever caused you a problem? Hit reply—I’d like to hear whether operators are switching platforms for cash flow reasons or sticking with what their audience already knows.

You wake up to find $4,800 of this month’s course sales sitting in a “reserved balance” instead of your bank account. Stripe didn’t warn you. The dashboard shows the money as “pending” with a 30-day hold. Your rent is due in six days.

Payment processor reserves aren’t rare. They’re automatic risk controls that lock a percentage of your revenue when transaction patterns change. For solo operators running subscription businesses, they can freeze 10–30% of incoming payments for weeks—sometimes longer.

How reserves work and when they trigger

Stripe, PayPal, and most payment processors use rolling reserves or fixed-percentage holds to cover potential chargebacks and refunds. The system monitors your account for pattern changes: a sudden revenue spike, a new product launch, a shift from one-time to recurring billing, or an uptick in dispute rates.

When a reserve triggers, the processor withholds a percentage of each transaction. That money sits in a segregated balance. After a set period—typically 30 to 90 days—the funds release on a rolling basis. If you process $10,000 in Week 1 with a 20% reserve, you’ll receive $8,000 immediately. The remaining $2,000 releases 30 days later, assuming no disputes.

Reserves don’t require your approval. They’re written into the merchant agreement. Stripe’s terms allow them to impose or adjust reserves at any time based on “risk assessment.” PayPal’s policy is nearly identical.

Common triggers include:

• Revenue increasing 200% or more month-over-month
• Launching a high-ticket product (above $500) for the first time
• Switching from physical goods to digital products or services
• Chargeback rates exceeding 0.5% of transaction volume
• Customer complaints or refund requests spiking above historical norms

What percentage gets held and for how long

Standard rolling reserves range from 10% to 30% of transaction volume, held for 30 to 120 days. Stripe’s default is 20% for 90 days when risk signals appear. PayPal’s can go as high as 30% for 180 days if your account is flagged for elevated dispute activity.

Fixed reserves are rarer but more severe. Instead of a percentage, the processor holds a flat dollar amount—say, $15,000—until they determine risk has subsided. This typically happens after multiple chargebacks on high-value transactions or if your business model changes dramatically (e.g., pivoting from consulting to software subscriptions).

Reserves aren’t interest-bearing. You don’t earn anything while the money sits. If your effective cost of capital is 8% annually, a $10,000 reserve held for 90 days costs you roughly $200 in opportunity cost—not counting cash-flow disruption.

How to check if a reserve is active

In Stripe, go to Balance → Overview. If a reserve is active, you’ll see a “Reserved funds” line with the held amount and release schedule. Click through for transaction-level detail showing which payments are affected.

PayPal buries it deeper: log in to Business Account → Reports → Reserved Funds. The interface shows pending releases by date, but won’t always explain why the reserve was imposed. You’ll need to contact support for specifics.

If you’re using Stripe Connect to process payments on behalf of sellers (e.g., a marketplace or platform business), reserves can cascade. Stripe may hold funds at the platform level and at the connected-account level, compounding cash-flow strain.

What you can do when a reserve hits

Contact processor support immediately. Explain your business model, provide transaction history, and ask for reserve terms in writing. If you can demonstrate stable operations—low refund rates, no dispute history, predictable revenue—you may negotiate a lower percentage or shorter hold period.

Provide documentation: churn reports, customer testimonials, refund policies, delivery confirmations. Processors care about risk mitigation. Evidence that you run a clean operation can reduce or lift a reserve within 5–10 business days.

If you’re launching a new offer or expect a revenue spike, email your processor before it happens. Proactive communication rarely prevents reserves, but it establishes context. When the algorithm flags your account, a support agent reviewing the case will see your heads-up and may approve a lighter hold.

Diversify payment rails. Run Stripe for subscriptions and PayPal for one-time course sales, or vice versa. If one processor imposes a reserve, the other remains unaffected. This doesn’t eliminate risk, but it reduces single-point-of-failure exposure.

Track reserve release schedules in your cash-flow forecast. Don’t budget reserved funds as liquid. They’re not available until the hold expires. If you’re running tight margins, a 20% reserve on $50,000 monthly revenue means planning around $40,000 actual receipts.

One non-obvious detail: Reserves don’t automatically lift when the hold period ends. Stripe and PayPal release funds on a rolling basis, but the reserve itself may stay active indefinitely if risk signals persist. You might receive October’s held funds in December, but November’s transactions are still subject to the same 20% hold. Always confirm whether the reserve is temporary or ongoing.

If cash flow is critical and a reserve would sink your operations, consider underwriting your own risk. Set aside 15–20% of monthly revenue in a separate account as a self-imposed buffer. It’s not ideal, but it beats scrambling when a processor locks your funds without warning.

Running into payment processor issues? Reply and tell me what happened—I’ll cover operator-reported problems in a future piece.