Category: Monetisation

Lemon Squeezy’s fraud detection system killed three sales for me in April before I knew what was happening. The customers reached out directly—confused emails asking why their cards kept declining. All three had legitimate payment methods. All three were buying a $29 digital product. None triggered a chargeback or refund request afterward, because I manually invoiced them through PayPal.

The problem wasn’t their cards. It was Lemon Squeezy’s fraud filters doing exactly what they’re designed to do: err on the side of caution. For platforms processing payments on your behalf, that caution protects their merchant account more than your conversion rate.

What triggers Lemon Squeezy’s fraud blocks

Lemon Squeezy uses a combination of IP geolocation, payment method origin, purchase velocity, and device fingerprinting to assess fraud risk. The system runs automatically—no manual review, no appeals process during checkout.

The most common false positives come from:

• VPN usage. Customers routing through privacy tools often show mismatched IP and billing addresses. Lemon Squeezy’s system flags this as high-risk, especially if the VPN exit node is in a country with elevated fraud rates.
• Prepaid and virtual cards. Privacy.com cards, Revolut disposable numbers, and similar services trigger blocks more often than traditional bank-issued credit cards. The BIN (bank identification number) lookup tags them as higher risk.
• Cross-border purchases. A customer in the Philippines buying from a U.S.-based seller with a card issued in Singapore will hit multiple friction points. The system doesn’t distinguish between legitimate digital nomads and card testers.
• High cart values from new accounts. First-time buyers attempting purchases above $100 face stricter scrutiny. If you sell courses, bundles, or annual subscriptions, expect more declines than someone selling $9 templates.

You won’t see most of these blocks in your dashboard. Lemon Squeezy logs them as “payment failed” without distinguishing fraud declines from insufficient-funds errors. The customer sees a generic “transaction could not be completed” message and often assumes their card is the problem.

How this compares to Gumroad and Stripe

Gumroad uses a similar merchant-of-record model and faces the same false-positive tradeoff. Operators report roughly 2–4% of legitimate transactions blocked, with higher rates for international sales. Gumroad’s support will manually review and whitelist customers, but only after the sale fails and you open a ticket.

Stripe, when you’re using it as a direct integration (not through a platform), gives you more control. You can adjust Radar’s fraud threshold, whitelist specific countries or card types, and review flagged transactions before they’re declined. The tradeoff: you’re responsible for chargebacks. Platforms like Lemon Squeezy absorb that risk, which is why their filters are tighter.

For solo operators selling digital products under $50, Lemon Squeezy’s fraud protection saves more money than it costs—until your audience skews international or privacy-conscious. Then the math flips.

What you can do when a real customer gets blocked

Lemon Squeezy doesn’t offer a way to pre-approve customers or adjust fraud thresholds. Your options are reactive:

Manual invoicing. If a customer emails you after a decline, send a PayPal invoice or Stripe payment link directly. You’ll eat the higher transaction fee (PayPal charges 3.49% + $0.49 for invoices vs. Lemon Squeezy’s flat 5% + $0.50), but you’ll close the sale. I’ve done this eleven times in the past six months.

Alternative checkout links. Some operators set up a secondary Gumroad or Stripe Checkout flow for customers who can’t complete payment on Lemon Squeezy. You’ll maintain two product listings and reconcile sales across platforms, but it catches 60–70% of declined buyers who bother to ask for an alternative.

Support ticket on their behalf. Email Lemon Squeezy support with the customer’s email, approximate purchase time, and product. They’ll review the transaction log and can manually process the payment. Turnaround averages 12–24 hours, which means you’ve likely lost the impulse buyer.

None of these solutions scale if you’re processing hundreds of transactions per week. At that volume, 2% false positives means multiple support emails daily and manual invoicing overhead that cancels out the convenience of using a merchant-of-record platform.

When to switch platforms

If more than 5% of your inbound support is payment-decline related, and you’ve confirmed the customers have valid payment methods, Lemon Squeezy’s fraud filters are costing you more than they’re saving. Track this for 30 days—log every “my card was declined” email and compare it to total transactions.

For audiences in North America and Western Europe paying with standard credit cards, Lemon Squeezy works cleanly. For SaaS products, courses, or communities with global reach—especially if you’re attracting privacy-focused buyers or digital nomads—you’ll spend too much time recovering legitimate sales that should have converted automatically.

The alternative is taking on fraud risk yourself with a direct Stripe integration, which means dealing with chargebacks, sales tax collection, and VAT compliance. That’s not a trivial tradeoff for a solo operator, but it’s the only way to control your own fraud thresholds.

Hit reply if you’ve lost sales to fraud filters on any platform—I’m tracking patterns across Lemon Squeezy, Gumroad, and Paddle for a deeper comparison next month.

Sponsorship rate cards for newsletters typically lead with total subscriber count. It’s the biggest number you have, and brands shopping for placement want to see scale. The problem: that number is almost always misleading, and experienced media buyers know it.

If you’re pitching sponsors with a PDF that says “12,000 subscribers — $400 per placement,” you’re either underpricing engaged readers or overcharging for a list padded with inactive emails. Either way, you’re losing deals or leaving money on the table.

Here’s what works better, and what sponsors actually care about when they’re deciding whether to wire you money.

Lead with opens, not list size

A 10,000-subscriber list with a 45% open rate delivers more eyeballs than a 25,000-subscriber list with an 18% open rate. The math is simple: 4,500 opens versus 4,500 opens. But the first operator charges less because they think list size is the metric that matters.

Sponsors don’t pay for email addresses. They pay for attention. If your last six issues averaged 3,200 opens, say that upfront. Break it down by 30-day cohorts if your list has grown recently—showing that your May signups open at 52% while your January signups open at 38% proves you’re adding quality subscribers, not buying lists or running giveaway spam.

Include unique open rates, not total opens. If someone opens your email three times, that’s still one person. Most ESPs report both; sponsors want the unique number.

Show click-through on past sponsorships

If you’ve run sponsorships before, share anonymized click data. Not click-through rate as a percentage—absolute clicks. “Last sponsor placement generated 210 clicks to their landing page” tells a buyer exactly what they’re getting. Add context: was it a text link, a dedicated section, or a full takeover? Did you write the copy or did they?

If the sponsor converted 8% of those clicks into trial signups, and you know that because they told you, put it in the deck. Third-party validation is worth more than your own claims about engagement.

Don’t have sponsorship data yet? Show clicks on your own content. Pick your three most recent issues, pull the top-clicked link from each, and report the numbers. If your audience clicks through to your blog, affiliate links, or product pages at a 6–9% rate, they’ll click sponsor links too.

Segment pricing by placement type

A single rate card with one price assumes all placements are equal. They’re not. A dedicated email where you write a 400-word case study about the sponsor’s product is worth more than a three-line text link in your footer. A mid-email callout box with a headline, 100 words, and a button is somewhere in between.

Offer at least two tiers. Name them clearly: “Featured partner” and “Classified mention,” or “Primary sponsor” and “Supporting link.” Price them 3x to 5x apart. If your supporting link is $200, your featured placement should be $600–$1,000, depending on your open rate and niche.

Sponsors with bigger budgets will pick the expensive option because it’s clear what they’re getting. Sponsors testing your list for the first time will pick the cheap option, then upgrade after they see results.

Drop the subscriber count—or bury it

If your open rate is strong, lead with opens and clicks. Put total subscriber count in the third or fourth line, or leave it out entirely. It’s not a secret—sponsors can ask—but it’s not your strongest signal.

If your list is below 2,000 subscribers, don’t apologize for it. Instead, frame your pricing around cost per click or cost per open. “$300 gets you 180 clicks” is a clear value proposition. A brand spending $1.67 per click on Google Ads will happily pay you $300 for the same result with a warmer audience.

One operator I know runs a 1,400-subscriber list in the podcast production niche. She charges $250 per sponsor mention and delivers 80–100 clicks per placement. Her cost per click is under $3, and her sponsors re-book every quarter because her audience converts. She doesn’t mention list size in her pitch deck at all.

Update your rate card every quarter

Your open rate drifts. Your list grows. Sponsors who booked you six months ago paid a price based on old data. If your opens are up 15% since January, your rate card should reflect that.

Don’t freeze pricing just because a sponsor might complain. Grandfather existing sponsors at their original rate for one renewal, then move them to current pricing. New sponsors pay the current rate immediately.

If your engagement is falling, don’t raise rates. Fix your content first, then revisit sponsorship pricing once your numbers recover. Charging more for worse performance is how you lose sponsors permanently.

Want to compare how other operators price sponsorships? Reply with your open rate and niche—we’ll feature anonymized benchmarks in a future issue.

You run a sponsored issue, push an affiliate link on social, mention a product in your archive, and three weeks later someone buys. Your analytics platform credits the sale to “direct traffic” or the last click before checkout. You have no idea which channel actually worked.

This isn’t a tracking-pixel problem. It’s a structural flaw in how most solo operators measure revenue when the buyer journey spans email, social, organic search, and word-of-mouth over days or weeks.

Single-touch attribution—first click or last click—works when the path is short. It collapses when your funnel has five steps, three platforms, and a fourteen-day consideration window. And if you’re running a content business, that’s the norm, not the exception.

Why last-click attribution lies

Most analytics tools default to last-click: the final referrer before conversion gets full credit. If someone clicks your affiliate link in a newsletter, browses for ten minutes, leaves, then Googles the product name two days later and buys via organic search, Google gets the sale. Your newsletter sees nothing.

Stripe’s payment links don’t carry session history. Gumroad’s dashboard shows referrer data, but only for the session that completed checkout. ConvertKit and Beehiiv track link clicks, but those events live in separate databases from your revenue analytics. Unless you stitch them manually, the attribution breaks at the platform boundary.

First-click attribution has the opposite problem: it over-credits discovery and ignores the nurture work. If someone found you via a Reddit comment six months ago, subscribed, read forty emails, then bought after a single product mention, Reddit gets full credit. The forty emails that built trust? Invisible.

Multi-touch models operators actually use

Enterprise marketing teams run algorithmic attribution—machine learning models that weight every touchpoint. Solo operators don’t have the data volume or engineering budget for that. But three simpler models work without custom code:

Linear attribution: Split credit equally across all known touchpoints. If someone clicked three emails, visited your site twice via organic search, and converted via a social link, each touchpoint gets 20%. This assumes every step mattered equally, which is wrong, but it’s better than crediting one channel with 100%.

Time-decay attribution: Give more weight to recent interactions. Touchpoints closer to conversion get higher percentages. A click seven days before purchase counts less than a click seven hours before. This mirrors how buying intent escalates, but it still undervalues early discovery.

Position-based (U-shaped) attribution: Credit 40% to first touch, 40% to last touch, and split the remaining 20% across middle interactions. This rewards both discovery and conversion while acknowledging the nurture steps. It’s the model I see most operators settle on after trying the others.

How to track multi-touch revenue without enterprise tools

You don’t need Segment or a six-figure contract with HubSpot. You need three things: consistent UTM tagging, a spreadsheet or lightweight database, and a workflow that logs touchpoints before checkout.

Tag every outbound link with UTM parameters that include source, medium, and campaign. Your newsletter links get ?utm_source=newsletter&utm_medium=email&utm_campaign=2026-06-06. Social posts get ?utm_source=twitter&utm_medium=social. Affiliate mentions get a unique campaign slug. Apply this everywhere, every time.

Use a tool that logs those UTM parameters at the session level. Google Analytics 4 can do this if you set up custom dimensions for first and last UTM source. Plausible Analytics stores referrer data in its event stream. Fathom Analytics offers custom event properties. All three let you export CSVs with timestamp, session ID, and UTM values.

At checkout, append a hidden field or order note that captures the customer’s email or a hashed session ID. In Stripe, use metadata fields. In Gumroad, add a custom field to the checkout form. In WooCommerce, log UTM data to the order meta table with a lightweight plugin or custom function.

Once a week, export your revenue data and your session logs. Match customer email or session ID across both. Map out the sequence of touchpoints that led to each purchase. Assign attribution percentages using whichever model you chose. Update a running tally of channel performance.

This workflow takes about ninety minutes a week for a business doing twenty to fifty transactions a month. It’s manual, but it’s accurate enough to shift budget and effort toward the channels that actually drive revenue.

What breaks and when to simplify

Multi-device journeys wreck this system. If someone reads your newsletter on mobile, researches on desktop, and buys on tablet, session IDs won’t match unless they log in. Email hashing helps, but only if you collect it at multiple touchpoints.

Word-of-mouth and dark social—shares via Slack, WhatsApp, direct messages—show up as direct traffic. You can’t track them without unique links for every share, which isn’t realistic. Accept that 20–30% of your revenue will stay unattributed.

If your average sale is under $30 and you’re doing fewer than ten transactions a week, the juice isn’t worth the squeeze. Stick with last-click and focus on growing volume instead of optimising attribution. Multi-touch matters when you’re allocating real money across channels or deciding which content to double down on.

Want more breakdowns of what works and what breaks in online-business operations? Subscribe to One Two Three Send and get one focused article like this in your inbox every week.

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’ve ever sent someone a Stripe checkout link and had them come back a day later saying it doesn’t work, you’ve run into session expiration. Stripe Checkout sessions expire exactly 24 hours after creation, and there’s no setting to extend that window.

This isn’t a bug. It’s a deliberate design choice that affects how you structure payment flows, follow-up sequences, and cart abandonment recovery. Here’s what the 24-hour limit actually does, when it becomes a problem, and how to work around it.

What happens when a checkout session expires

When you create a Stripe Checkout session via API or no-code tool, Stripe generates a unique URL. That URL is valid for 24 hours from the moment of creation—not from the moment someone opens it.

After 24 hours, the link returns a “This Checkout Session has expired” error. The customer can’t complete payment. You don’t get notified. The session just stops working.

This matters most when you’re pre-generating checkout links in automated emails, Slack messages, or scheduled posts. If someone receives your email at 9 a.m. Monday and clicks at 10 a.m. Tuesday, the link is dead.

Stripe’s expiration clock starts when the session is created, not when the email is opened or the link is clicked. That’s the key mistake: assuming the 24-hour window begins when the customer engages.

Why Stripe enforces the 24-hour limit

Stripe’s documentation doesn’t spell out the reasoning, but the expiration window serves two purposes: fraud mitigation and inventory accuracy.

Payment sessions that stay open indefinitely create opportunities for replay attacks and price manipulation. If a checkout session for a $49 product remains valid for weeks, someone could exploit outdated pricing or coupon codes long after you’ve changed them.

The 24-hour window also keeps your checkout flow aligned with real-time inventory, seat availability, or limited-time offers. If you’re selling a cohort-based course with 50 spots, a session created when 10 spots remain shouldn’t stay valid when the cohort fills two days later.

For subscription products and digital goods with no inventory constraints, the expiration feels arbitrary. But Stripe’s Checkout API handles everything from physical products to event tickets, so the 24-hour rule applies universally.

When expiration breaks your workflow

The 24-hour limit causes problems in three common scenarios.

Pre-scheduled email sequences. If you’re running a five-day email course that ends with a checkout link, and you generate all five sessions at once, the link in email five is already expired by the time it sends. You need to generate each session just before its corresponding email goes out.

Abandoned cart recovery. Standard cart abandonment flows wait 24–72 hours before sending a reminder. If you generate the checkout session when someone first adds a product to their cart, the recovery email will contain a dead link. You’ll need to regenerate the session when the reminder triggers.

Public checkout links in evergreen content. Embedding a Stripe Checkout URL in a blog post, help doc, or pinned social media post doesn’t work. The link dies within a day. You’ll need to use Stripe Payment Links (which don’t expire) or dynamically generate sessions when someone clicks.

How to work around session expiration

The cleanest solution is to generate checkout sessions on-demand, right when the customer needs them.

If you’re using Zapier, delay the “Create Checkout Session” action until immediately before the email sends. Don’t create all sessions upfront. In a drip sequence, each email should trigger its own session creation step.

For abandoned cart emails, store the product details (price ID, quantity, customer email) instead of the checkout URL. When the reminder triggers 48 hours later, generate a fresh session using those stored details.

If you need a persistent checkout link—something you can post publicly or reuse across emails—use Stripe Payment Links instead of Checkout sessions. Payment Links don’t expire and support the same features (custom fields, tax calculation, subscription billing). The trade-off: you lose some advanced customisation options available in the Checkout API, like dynamic pricing or complex line-item logic.

For high-touch sales where you’re sending invoices manually, Stripe Invoices are a better fit than Checkout. Invoices stay open until you close them or they’re 90 days past due, and customers can pay directly from the invoice page without a session.

One non-obvious detail: Stripe’s expires_at parameter lets you set a shorter expiration window (as brief as 30 minutes), but you can’t extend it past 24 hours. If you’re running flash sales or time-sensitive offers, setting expires_at to match your sale deadline keeps pricing consistent and adds urgency. Just make sure your customers know the link has a ticking clock.

If you’re building payment flows for courses, memberships, or digital products and need help choosing between Checkout sessions, Payment Links, and invoice-based billing, subscribe to One Two Three Send—we break down one tool decision like this every week.

Gumroad’s pay-what-you-want (PWYW) pricing looks like a generous experiment until you run the numbers. The feature lets buyers name their own price above a floor you set—or no floor at all. The pitch is that generosity builds goodwill, increases conversions, and unlocks buyers who’d never pay full price.

The reality is messier. PWYW can work, but only in narrow conditions. Most operators who flip the switch see average transaction values drop between 40% and 70% compared to fixed pricing, even when they set a suggested price. The question isn’t whether PWYW lowers your per-sale revenue—it does—but whether the volume increase offsets the loss.

What buyers actually pay when you let them choose

Three anonymised operators shared their Gumroad dashboard data after running PWYW experiments on digital products priced between $15 and $49. Here’s what happened:

• Operator A: A $29 Notion template. Fixed price averaged $29 (obviously). PWYW with a $15 floor and $29 suggestion averaged $18.40 over 200 transactions. Conversion rate increased 22%, but total revenue dropped 18%.
• Operator B: A $49 course bundle. PWYW with no floor and a $49 suggestion averaged $12.60 over 180 sales. Conversion rate doubled, revenue increased 9%. The operator considered it a win but switched back after realising most new buyers never purchased again.
• Operator C: A $15 guide. PWYW with a $10 floor averaged $11.30. Conversion rate increased 8%, revenue dropped 31%. Switched back to fixed pricing within two weeks.

The pattern: PWYW reliably increases conversion rate, but average order value collapses. The floor matters—Operator A’s $15 minimum kept the average above $18, while Operator B’s lack of a floor invited $5 and $7 payments on a product originally priced at $49.

When PWYW makes sense (and when it doesn’t)

PWYW works best as a short-term acquisition tool, not a permanent pricing strategy. The clearest use case is launching a new product to an untested audience. You’re optimising for feedback and social proof, not revenue. A $0 floor with a reasonable suggestion—say, $19 on a product you plan to price at $39—gets you early buyers, testimonials, and usage data you can fold into the final version.

It also works for products with near-zero marginal cost and high repeat-purchase potential. If you’re selling a lightweight template or checklist and you have a clear upsell or backend offer, PWYW can fill the top of your funnel cheaply. But if the product is your only offer, or if you’re selling something that required weeks of work to build, PWYW usually just trains your audience to expect discounts.

Where it fails: evergreen products with established audiences. If people already know your work and trust your pricing, PWYW doesn’t increase conversions meaningfully—it just gives existing buyers permission to pay less. Operator C’s 8% conversion lift didn’t justify a 31% revenue drop because the audience was already warm.

The non-obvious cost: anchoring your own pricing

The hidden risk of PWYW is psychological, not financial. Once you’ve let buyers pay $10 for something you later price at $39, you’ve anchored their perception of value. If they see the same product—or something similar—at the higher price later, they’ll assume you’re overcharging, not that they got a deal earlier.

This is particularly painful if you run PWYW as a launch discount and then switch to fixed pricing. The buyers who paid $8 will tell others they paid $8. The new buyers who see $39 will Google your product, find Reddit threads or tweets mentioning the lower price, and wait for another sale. You’ve effectively turned a one-time experiment into a permanent discount expectation.

The fix: if you use PWYW, frame it explicitly as a beta, a launch window, or a limited-time test. Set a public end date and stick to it. Don’t let it drift into your evergreen offer.

Gumroad’s PWYW settings: what to toggle

Gumroad gives you three levers: minimum price, suggested price, and whether to show the suggestion. The minimum is a hard floor—buyers can’t pay less. The suggested price is what Gumroad displays in the checkout field by default. If you hide the suggestion, the field is blank and buyers have to decide with no anchor.

Showing the suggestion raises the average payment by 30–50% compared to hiding it, based on the data above. Operator B’s $12.60 average with a $49 suggestion would likely have dropped below $10 with no suggestion shown. If you’re going to use PWYW, always show a suggestion—and set it at 60–70% of your intended fixed price, not 100%. A $49 suggestion on a product you plan to sell for $49 just makes buyers feel like they’re being manipulated into paying full price anyway.

The minimum should be at least 30–40% of your target price, unless you’re explicitly using PWYW as a free-plus-reputation play. Operator A’s $15 floor on a $29 product kept the average at $18.40. Operator B’s $0 floor tanked the average to $12.60 on a $49 product. Floors work.

Want more pricing breakdowns, tool comparisons, and operator data? Subscribe to One Two Three Send and get one article like this every day.

Stripe payment links let you sell anything without building a checkout page. You generate a URL, share it, and collect money. Simple. But buried in the link settings is an expiration option most operators never touch—and that’s a mistake.

Payment link expiration does two things: it creates urgency for time-sensitive offers, and it prevents confusion when pricing or terms change. Set correctly, it can lift conversions. Set carelessly, it kills them.

How payment link expiration works

When you create a Stripe payment link, you can set an expiration date and time. After that point, the link returns a message telling the buyer it’s no longer available. The product, price, and subscription settings remain unchanged in your Stripe dashboard—only the link stops working.

Stripe gives you three expiration options:

• No expiration — the link works indefinitely
• After a specific date and time — you pick an exact cutoff
• After a certain number of uses — the link deactivates after X successful payments

The third option is rarely useful unless you’re selling a fixed number of spots (a cohort course, a live workshop, a limited consulting package). The first two are where most operators make their choice—and where most get it wrong.

When to set an expiration date

Use expiration when the offer itself has a deadline. Launch pricing that ends Friday. Early-bird tickets for an event. A discount code you’re running for 72 hours. A beta program with a cap on participants.

In these cases, expiration reinforces the urgency you’re already creating in your messaging. If your email says “price goes up Sunday at midnight,” the payment link should expire Sunday at 11:59 PM in your time zone. Otherwise, someone who bookmarks the link can return three weeks later and pay the old price—or worse, pay the old price for a product that no longer matches the description.

Expiration also prevents billing confusion. If you raise your subscription price from $15 to $25 per month, every old payment link still floating around the internet will charge $15. Someone clicking a six-month-old tweet can subscribe at the wrong price, and you won’t know until you audit your transactions. Setting expiration on price-change announcements cleans this up automatically.

When NOT to set expiration

If the offer is evergreen, don’t add artificial urgency by setting a deadline you don’t intend to honor. Operators sometimes set a 30-day expiration “just in case,” then regenerate the same link with a new expiration date when it runs out. This creates busywork and breaks inbound links.

Permanent products—courses, memberships, one-time purchases with stable pricing—should use non-expiring links. You can always deactivate a link manually in Stripe if you need to pull it, but starting with an arbitrary countdown adds friction without benefit.

The exception: if you’re testing messaging or pricing and want to force yourself to revisit the offer in 90 days, expiration can act as a forcing function. Just be clear with yourself that it’s an internal deadline, not a customer-facing one.

The non-obvious tactic: expiration as a segmentation signal

Here’s a use case most operators miss. If you send the same payment link to two audiences—your email list and a Reddit post—you can’t tell which source drove the sale unless you use UTM parameters or create separate links.

Creating separate links with different expiration dates lets you segment behavior without touching your analytics stack. Send a 48-hour expiring link to your email list and a 7-day expiring link to social. When you check Stripe’s payment link analytics, you’ll see which link performed and when it stopped converting.

This isn’t a replacement for proper attribution tracking, but it works when you need a quick answer and don’t want to spin up a Zapier flow or tag every URL.

A few operational notes

Stripe doesn’t send you a notification when a payment link expires. If you set a date, add a calendar reminder to check performance and decide whether to extend, replace, or retire the offer.

Expired links return a generic Stripe error page. You can’t customize the message, so if you want to redirect visitors somewhere else—an updated offer, a waitlist, an apology—you’ll need to remove the old link from circulation and replace it with a redirect or new page. Don’t rely on the Stripe expiration page to do marketing work for you.

Finally, expiration applies to the link, not the product. If someone starts a checkout session before expiration and completes it five minutes after, Stripe still processes the payment. The cutoff happens at the moment someone clicks, not when they submit payment details.

Set expiration when the offer has a real deadline. Skip it when the product is evergreen. And if you’re testing, use expiration to force a review date instead of letting old links quietly underperform.

Want more tactical breakdowns like this? Subscribe to One Two Three Send—one article every day, no fluff, no filler.

Most course creators pick a platform, upload their videos, and assume the checkout will work at any scale. Then they run a launch, hit a transaction threshold buried in the fine print, and watch sales freeze until the next billing cycle.

These limits aren’t about storage or bandwidth—they’re about how many individual purchases your platform will process in a calendar month. Cross the line and you’re either locked out, auto-upgraded to a higher tier, or hit with overage fees that can double your hosting cost overnight.

Where the walls are

Teachable’s Basic plan ($59/month) caps you at 250 transactions per month. That’s total checkouts: course sales, upsells, payment-plan installments. If you sell a $97 course and 260 people buy it in October, the last ten get an error page unless you’re already on the Pro plan ($159/month), which raises the ceiling to 2,000 transactions.

Thinkific’s Basic plan ($49/month) has no stated transaction cap, but it restricts you to one published course and one admin user. You hit scaling friction through feature gates, not checkout limits. The Start plan ($99/month) lifts most restrictions but still charges a $0.10 fee per enrollment if you use Thinkific Payments instead of connecting Stripe directly.

Podia bundles email, courses, and digital downloads under one roof. Its Mover plan ($39/month) has no transaction cap and no platform fees—but you’re limited to one site and basic email automation. The Shaker plan ($89/month) adds affiliates, code editors, and advanced workflows, still with no transaction ceiling.

Kajabi doesn’t publish a transaction limit, but its entry-tier pricing starts at $149/month for up to 10,000 contacts and 1,000 active members. You’re more likely to hit a contact-list cap than a sales cap, but both can shut down growth mid-funnel.

What actually breaks

Transaction limits don’t just stop new sales—they cascade. If you’re running a payment plan (three installments over 90 days), each installment counts as a separate transaction. A single buyer on a payment plan consumes three transaction slots, even though you only made one sale.

Upsells and order bumps multiply the count too. Sell a course with a one-click upsell for templates, and that’s two transactions per buyer. Run a launch weekend with 200 buyers, half of whom take the upsell, and you’ve burned 300 transactions in 72 hours.

Affiliate payouts don’t count toward transaction limits, but refunds do. Issue a refund in Teachable and it doesn’t refund your transaction count—you’ve still used the slot. If you’re near your cap and process ten refunds, those ten slots are gone until next month.

How to plan around it

Before you launch, calculate your expected transaction load. Multiply projected buyers by the number of transaction events per buyer: initial purchase, upsells, and any payment-plan installments. Add 20% margin for refunds and edge cases.

If your platform caps transactions, map your pricing tier against your funnel. Teachable’s Pro plan at $159/month makes sense if you expect 500–2,000 transactions per month. Below that, you’re overpaying. Above that, you need the next tier or a migration plan.

For payment plans, front-load as much revenue as possible. Offer a small discount for paying in full, or structure plans as two installments instead of three. Fewer installments mean fewer transaction events and more predictable capacity.

Connect Stripe or PayPal directly when the platform allows it. Thinkific, Podia, and Teachable all support direct payment gateways, which often bypass per-transaction fees and give you more control over dispute handling and payout timing.

When to switch platforms

If you’re consistently hitting transaction caps, moving to a platform with no ceiling—or migrating to a self-hosted solution like WooCommerce or MemberPress—becomes cheaper than upgrading tiers every quarter.

Self-hosting adds operational overhead: you’re responsible for uptime, PCI compliance (handled by Stripe, but you still configure it), and plugin updates. But you eliminate per-transaction fees and artificial caps. A $30/month WordPress host plus a $199/year membership plugin can handle 10,000 transactions a month without flinching.

Before you migrate, export everything: customer lists, transaction history, course content, email sequences. Most platforms let you export CSVs and download video files, but automation rules and custom CSS don’t transfer cleanly. Budget two weeks for a clean migration, longer if you have complex funnels.

If you’re planning a launch in the next 60 days, check your transaction cap today. Open your billing page, find the limit, and multiply your projected sales by the number of transaction events per buyer. If the math puts you within 20% of the cap, upgrade now—or risk going dark the day your launch peaks.

Hit reply if you’ve been burned by a transaction cap mid-launch. I’m collecting war stories for a follow-up piece on platform migration triggers.

Beehiiv launched native paid subscriptions in 2023, positioning itself as the all-in-one platform that doesn’t need Stripe integration or third-party membership plugins. For operators already using Beehiiv for free newsletters, flipping the paid switch looks frictionless. But the setup hides complexity that surfaces once you start collecting money across borders.

Here’s what actually happens when you turn on paid subscriptions, what it costs, and the tax issue that catches most operators off guard.

How Beehiiv paid subscriptions work

Beehiiv handles payment processing, subscriber management, and content gating in one interface. You set your price—monthly, annual, or both—and designate which posts are free versus paid. Beehiiv uses Stripe under the hood but abstracts the integration: you connect your Stripe account once during setup, and Beehiiv manages checkout, invoicing, and failed payment recovery.

The platform supports tiered pricing, free trials, and discount codes. You can also gate individual posts retroactively, which is useful if you’re testing paid content before fully committing to a subscription model.

One non-obvious benefit: Beehiiv’s referral program integrates with paid tiers. If a free subscriber refers enough readers, they can unlock paid content without paying. This works well for growth-focused operators who want to reward evangelists, but it complicates revenue forecasting—your paid subscriber count and MRR won’t always move in lockstep.

The fee structure

Beehiiv takes a 2.9% platform fee on top of Stripe’s standard processing fees (2.9% + $0.30 per transaction in the U.S.). That means you’re paying roughly 5.8% + $0.30 per transaction when someone subscribes.

For a $10/month subscription, you net around $9.12 after fees. At $100/month, you keep $94.12. The percentage hit is consistent, but the flat $0.30 fee stings more on lower-price subscriptions.

Beehiiv’s fee applies to your plan tier, not your revenue size. Whether you’re on the Scale plan ($99/month) or Launch (free), the 2.9% fee remains. This is different from platforms like Substack, which take 10% but don’t charge a base platform fee.

If you process $5,000/month in subscriptions, Beehiiv’s cut is $145. Substack’s would be $500. The breakeven point sits around $3,500/month in subscription revenue—below that, Beehiiv’s model costs less; above it, the flat percentage wins.

The VAT problem nobody mentions upfront

Beehiiv does not automatically handle VAT, GST, or sales tax collection for non-U.S. subscribers. If you have paying subscribers in the EU, UK, Australia, or other VAT-registered regions, you are responsible for compliance.

Stripe can calculate and remit taxes if you enable Stripe Tax, but Beehiiv’s integration doesn’t surface this option in the dashboard. You have to configure it directly in your Stripe account, then ensure Beehiiv passes the correct billing address data to Stripe during checkout.

Most operators discover this after their first invoice from a European subscriber. If you’re not charging VAT and you cross registration thresholds (€10,000 in EU sales), you’re technically operating outside compliance. Fixing it retroactively means either absorbing the tax yourself or awkwardly re-invoicing subscribers.

If you’re U.S.-based and expect most subscribers to be domestic, this may not matter in year one. But if you’re writing for a global audience, budget time to either enable Stripe Tax or work with an accountant who understands digital service VAT rules.

When to use Beehiiv paid vs. an external membership tool

Beehiiv’s native subscriptions work best when:

• Your entire business is the newsletter—no courses, downloads, or community access
• You want one dashboard for content, audience, and revenue
• You’re okay with Beehiiv owning the checkout experience and subscriber relationship

Skip Beehiiv paid and use a dedicated membership platform (Memberful, Ghost, or a WordPress membership plugin) if:

• You need complex access rules—time-limited content, drip courses, or tiered community access
• You want full control over tax settings, invoicing, and subscriber data portability
• You plan to sell more than just newsletter access (e.g., templates, coaching, or archived resources)

Beehiiv’s model is fast to launch but rigid once you outgrow simple “free vs. paid” segmentation. Migrating paying subscribers off the platform later is possible, but it requires CSV exports, manual Stripe imports, and subscriber communication to avoid confusion or churn.

If you’re testing paid for the first time and already use Beehiiv, the native option is the fastest validation path. Just know the tax setup isn’t automatic, and the 2.9% fee is a permanent cost unless you move to a different platform.

Using a different newsletter platform or thinking about switching? Reply and let me know what’s working—or not—in your paid subscription stack. I’ll cover more monetization mechanics in future issues.

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.

Affiliate link cloaking—redirecting yoursite.com/go/product to partnersite.com/?ref=yourID—sounds like good housekeeping. Cleaner URLs, consistent branding, easier tracking. But it introduces technical risk, compliance obligations, and platform dependency that many operators don’t plan for.

Here’s what actually changes when you cloak links, and when you’re better off leaving them naked.

What cloaking does (and doesn’t) solve

Link cloaking replaces long, ugly affiliate URLs with short, branded redirects. Instead of sharing https://convertkit.com?lmref=abc123xyz, you serve yoursite.com/convertkit and 301-redirect behind the scenes.

The benefit is consistency. Readers see your domain. You can swap the destination URL without editing published content. You centralize click tracking in one place—your own server logs or a plugin like Pretty Links or ThirstyAffiliates.

What it doesn’t do: improve deliverability, hide the affiliate relationship from networks, or make the link more trustworthy. Email clients still see the final destination after following the redirect. Affiliate networks log the same click. Readers who hover still see the redirect if they check the status bar.

And you’ve added a round-trip dependency: your server must respond before the affiliate network sees the click. If your host is slow, you’ve introduced latency. If your site goes down, the link breaks entirely.

FTC disclosure and platform terms

Cloaking doesn’t exempt you from disclosure rules. The FTC’s Endorsement Guides require clear, conspicuous notice when you earn from a recommendation. A short slug like /go/ or /recommends/ signals commercial intent, but it’s not a substitute for plain-language disclosure near the link.

Some affiliate programs explicitly prohibit cloaking. Amazon Associates’ Operating Agreement bans link shortening or masking that obscures the final destination. Commission Junction and ShareASale allow it, but require that the redirect preserves tracking parameters and doesn’t mislead users.

Check your agreement before you automate. Violating terms can mean forfeited commissions or account closure, and most networks won’t warn you—they’ll just stop paying.

When cloaking makes sense

If you publish across multiple platforms—blog, newsletter, podcast show notes—and want consistent analytics, cloaking centralizes your data. You can see aggregate clicks in one dashboard instead of stitching together reports from five affiliate portals.

If you rotate offers or test different partners, cloaking lets you update the destination without republishing old content. A post from 2023 can point to a new tool in 2026 if the /email-tool slug stays the same.

If you’re building a resource hub or comparison page, branded slugs make the link structure easier to maintain. /bluehost, /siteground, and /bigscoots are more memorable than tracking IDs.

When to leave links uncloaked

In email, cloaking adds a redirect that some inbox providers flag. Mailchimp, ConvertKit, and MailerLite preserve click tracking without requiring your own redirect layer. Adding a second hop can increase latency or trigger spam filters if your domain reputation is newer than the affiliate network’s.

If you’re solo and publishing sporadically, the maintenance overhead isn’t worth it. Cloaking plugins need updates. Redirects need testing. If a slug breaks and you don’t notice for two months, you’ve lost clicks and trust.

If the affiliate program forbids it, don’t bother trying to hide the relationship. Amazon’s SiteStripe links work fine as-is. Trying to mask them risks more than you gain.

And if you’re linking to a brand readers already recognize—Stripe, Shopify, Adobe—there’s no branding advantage. stripe.com is more trustworthy than yoursite.com/stripe to someone who’s never heard of you.

Implementation trade-offs

WordPress plugins like Pretty Links and ThirstyAffiliates handle the redirect and log clicks in your database. Easy to set up, but you’re querying your own database on every click. High-traffic affiliates can strain shared hosting if you’re not caching redirects.

Link management tools like Rebrandly or Short.io offload the redirect to their infrastructure. Faster, more reliable, but you’re paying monthly and trusting a third party with your click data. If they change pricing or shut down, you’re migrating hundreds of links.

Server-level redirects—defined in .htaccess or Nginx config—are fastest and least fragile, but require manual editing every time you add a link. Fine if you have six evergreen affiliate relationships. Unworkable if you’re testing new offers weekly.

Pick the method that matches your volume and technical comfort. If you’re managing fewer than 20 affiliate links, a plugin is fine. If you’re running a deals site with 200+ partners, invest in dedicated infrastructure or a SaaS redirect service.

Got a question about affiliate operations, tracking, or compliance? Reply to this email—operator stories make the best future articles.