Category: Monetisation

If you’re selling digital products, courses, or memberships, you’ve probably stared at Stripe’s Tax settings and wondered whether clicking “enable” would solve your compliance headaches or create new ones.

Stripe Tax is a feature that calculates, collects, and (optionally) files sales tax, VAT, and GST on your transactions. It’s built into Stripe, so there’s no separate integration to maintain. But it’s not free, and it’s not always the right move.

Here’s how it actually works, what it costs, and when you should turn it on—or leave it off.

What Stripe Tax actually does

Stripe Tax hooks into your payment flow and calculates the correct tax rate based on your customer’s location and what you’re selling. It supports over 40 countries and automatically updates rates when local laws change.

When a customer checks out, Stripe adds the appropriate tax to the transaction total. That tax gets collected alongside the payment, and Stripe holds it separately from your payout balance.

If you enable the filing service (called Stripe Tax Registration and Filing), Stripe will register your business in the jurisdictions where you hit economic nexus thresholds, file returns on your behalf, and remit the tax directly to the tax authorities.

It covers VAT in the EU, UK, and other countries, GST in Australia, Canada, New Zealand, and Singapore, plus sales tax across U.S. states. It does not cover income tax, withholding tax, or import duties.

Pricing: the cost structure you need to know

Stripe Tax costs 0.5% of the transaction amount, capped at $5.00 per transaction. So on a $50 product sale, you pay 25 cents. On a $2,000 annual membership, you pay $5.00.

That fee is charged on top of Stripe’s standard payment processing fees (typically 2.9% + 30¢ for card transactions).

If you opt into the registration and filing service, Stripe charges an additional monthly fee per jurisdiction where they file on your behalf. In the U.S., that’s $50 per state per month. For VAT in the EU, it’s typically bundled under a single OSS (One-Stop Shop) registration, which costs around $100–$200/month depending on your setup.

For a solo operator selling a $29/month membership in five U.S. states, you’re looking at $250/month in filing fees alone—before accounting for the 0.5% per-transaction charge.

When to turn it on

Stripe Tax makes sense in three scenarios.

First: You’ve crossed economic nexus thresholds in multiple jurisdictions and you’re already required to collect and remit tax. If you’re manually tracking rates and filing returns, the 0.5% fee is likely cheaper than paying an accountant to do it—especially if your transaction volume is high and your average order value is low.

Second: You’re selling globally and dealing with VAT in the EU or UK. The rates vary by country, change frequently, and the compliance burden is real. Stripe Tax’s automatic rate updates and OSS filing support can save you hours every quarter.

Third: You’re scaling fast and don’t want tax compliance to become a bottleneck. If you’re adding new products, entering new markets, or growing past $100K in annual revenue, turning on Stripe Tax early means one less thing to audit later.

When to skip it (or wait)

If you’re just starting out and your revenue is under $50K/year, you probably don’t need it yet. Most U.S. states have economic nexus thresholds around $100K in sales or 200 transactions per year. Until you hit those numbers, you’re not required to collect tax in those states.

If you’re only selling in your home state or a single jurisdiction, the 0.5% fee is a convenience charge for something you could handle with a spreadsheet and a quarterly check to your state revenue department.

And if your average transaction value is very high—say, $5,000+ for a consulting package or enterprise license—the capped $5 fee per transaction adds up quickly. You might be better off working with a tax professional who charges a flat monthly retainer.

One non-obvious tip: test it in test mode first

Stripe Tax has a full-featured test mode. Before you enable it in production, create a test checkout with your actual product prices and simulate transactions from different locations—California, Texas, Germany, Australia.

Check the tax amounts Stripe calculates. Compare them against your state or country’s published rates. Make sure the line items on the receipt match what your customers will expect to see.

This is especially important if you’re using Stripe Checkout or Payment Links, where the tax line appears automatically. If your pricing page says “$99” but checkout shows “$108.17,” and your customer wasn’t expecting that, you’ll lose the sale. Better to know now and adjust your messaging.

If you’re running a content-driven business and want more deep dives like this—on tools, infrastructure, and the mechanics of online revenue—subscribe to One Two Three Send. Every week, you’ll get one operator-to-operator breakdown of something that actually moves the needle.

Most online operators start with the attention model: build an audience, then figure out how to extract money from their time. Newsletter sponsorships. Display ads. Affiliate links tucked into content. It feels like the natural path because it’s what you see working for others.

But there’s a reason why operators who switch to product revenue—courses, memberships, software, templates, anything with a defined deliverable—rarely switch back. Product models scale differently, and for solo operators especially, they scale better.

The attention tax compounds quietly

When you monetise attention, every dollar requires continuous performance. A sponsorship pays once, then expires. Ad revenue tracks your traffic month to month. Affiliate income depends on someone else’s conversion funnel and commission structure.

You’re not building equity. You’re renting out capacity.

The math gets worse as you grow. To double sponsorship revenue, you need to double your audience or double your rate. Rates have ceilings—sponsors comparison-shop, and CPM benchmarks are public. So you chase growth, which means more content, more consistency pressure, more surface area to maintain.

Then there’s the editorial drift. A reader-funded model points you toward what readers value. An attention model points you toward what scales: volume, virality, topics that pull search traffic even if they’re not what you’d choose to write about. Over time, the publication bends toward the model.

Products let you decouple revenue from output

Selling a product means you can earn the same amount while publishing less. A course that brings in $3,000 a month doesn’t care whether you published twice this week or not at all. A membership that delivers one deep tutorial every two weeks scales your income without scaling your content treadmill.

This isn’t about working less—it’s about where you point your working hours. Instead of optimising for volume (another post, another sponsor, another traffic play), you optimise for conversion and retention. You spend time on the product, the onboarding flow, the member experience, the case studies that close sales.

Products also let you serve smaller audiences profitably. A newsletter with 2,000 subscribers is almost impossible to monetise via sponsorships—your inventory is too small, your rates are too low, and sponsors want five-figure lists. But 2,000 subscribers with a $99 course and a 2% conversion rate is $4,000 in revenue from a single launch. Run that twice a year while growing the list, and you’ve got a real business.

The chief objection: “I don’t have a product idea”

This is almost never the real problem. If you’re writing regularly about a topic, you’re already teaching. The product is just the teaching formatted differently—less frequent, more structured, with a defined outcome.

Start with what people already ask you to explain twice. That’s the course. Start with what you’d build for yourself if you had four hours. That’s the template or tool. Start with the workflow you’ve refined over two years that newcomers are still guessing at. That’s the membership.

The other common block: “I don’t want to do a big launch.” Fine—don’t. Sell evergreen. Put a product page in your site footer. Mention it once per month in your newsletter. Let it convert passively while you write. You’ll be surprised how many people buy something useful without a countdown timer.

Attention models aren’t wrong—they’re just expensive

Sponsorships and ads work. They work especially well if you’re already at scale, if you have a team handling sales and production, or if your content velocity is naturally high and you’re not burning out.

But for solo operators, the cost isn’t just time—it’s option value. Every hour spent chasing another sponsorship is an hour you didn’t spend building something that compounds. Every editorial decision bent toward traffic is a decision away from the tight, specific thing your best readers would pay for.

If you’re still early, or if you’re hitting the ceiling on attention-based models and wondering what’s next, the move isn’t to optimize your sponsor deck. It’s to spend a month building the thing you’d sell if someone asked you to solve their problem directly.

Then sell that.

What’s one product you could ship in the next 30 days using what you already know? Reply and tell me—I read every response, and I’ll send you the follow-up guide on evergreen product funnels for solo operators.

Stripe is the default payment processor for most online newsletter and creator businesses, and it’s worth understanding because most operators end up using it whether they planned to or not. Substack is built on Stripe. Beehiiv is built on Stripe. Kit, ConvertKit, Memberful, Lemon Squeezy — all Stripe. If you’ve ever sold a paid subscription, you’ve already met it, even if you didn’t see the dashboard.

This post is for operators thinking about going beyond the platform — running their own paid tier on WordPress, selling a one-off product, or running a small agency that needs to invoice cleanly. We’ll cover what Stripe actually is, what it costs at newsletter scale, the four concepts that trip up most operators on first contact, the real pitfalls (activation, tax, chargebacks), and when not to use it.

What Stripe is, in one paragraph

Stripe is a payment infrastructure company that handles the messy middle between your website and the card networks (Visa, Mastercard, Amex). When a subscriber clicks “Subscribe $10/month” on your newsletter, Stripe collects the card, runs it through fraud checks, charges it via the bank, deals with international currency conversion, retries failed cards on a schedule, sends the customer a receipt, and shows up in your bank account a few business days later as a deposit. You never touch the card data. You never run a banking integration. You pay them roughly 2.9% + 30¢ per transaction and they handle the rest.

What makes Stripe different from PayPal or Square is that it’s developer-first. The API is excellent, the dashboard is good (not great, but good), and it’s the one platform where every newsletter tool, course platform, and SaaS app can integrate easily. That ecosystem effect is the moat.

What it actually costs at newsletter scale

Stripe’s standard rate is 2.9% + 30¢ for US cards and 3.4% + 30¢ for international cards. Real averages for US-based newsletter operators end up around 2.9–3.4% all-in.

Annual revenue	Stripe fees (approx)	What that buys
$10,000	$300	~440 charges processed, customer portal, dunning, receipts
$50,000	$1,500	Same plus fraud detection on autopilot
$250,000	$7,500	Volume discount eligibility (negotiable above $1M)

For comparison, building anything close to this from scratch — fraud detection, retry logic, customer-facing portal, tax handling — costs more than the fees. The Stripe rate is the cheapest part of the whole stack. Operators who agonise over the 2.9% are usually missing what they’d spend rebuilding it.

The four use cases for a newsletter operator

1. Paid newsletter subscriptions

The big one. Monthly and annual recurring subscriptions, typically $5–15/month or $50–150/year. Three patterns work for newsletters:

• Monthly + annual + founding member. Standard Substack split. Annual gets a 17% discount. Founding member is 10x the annual price for readers who want to support the publication beyond the standard tier — surprisingly common at the right audience size.
• Annual only. Eliminates the worst-converting tier (monthly), reduces churn, simplifies cashflow forecasting. Used by operators who want a smaller list of higher-LTV readers.
• Pay what you want above a floor. Stripe supports this via Custom Pricing on Checkout. $5/month minimum, customer enters whatever they want above. Niche but works for community-driven newsletters.

2. One-off products

Ebooks, course access, sponsored slots, archive bundles. One-off charges with optional digital delivery via Stripe’s Payment Links (zero coding, drag-and-drop). For a newsletter operator selling a $29 ebook, Payment Links is the fastest route — generate a link, paste in your newsletter, done.

3. Tipping / donations

Some readers want to support a free newsletter without subscribing. Set up a Stripe-hosted Payment Link with custom amount enabled. One-line install in your footer: “Tip the writer →”. Closer to a Patreon model but without the platform tax.

4. Agency / consulting invoices

If you run an agency alongside the newsletter, Stripe Invoices replaces every invoicing tool you’ve used. Send a hosted invoice link. Client clicks, pays, you get notified, accounting reconciles via the Stripe export. Free if the invoice gets paid by card (you pay the standard processing fee), free if paid by ACH.

The four concepts that trip up newsletter operators

These are the four things that, in our experience, every operator runs into in their first month and doesn’t fully understand until month three.

Checkout vs Payment Links vs Pricing Tables

Three Stripe products that look similar but solve different problems:

• Checkout — a Stripe-hosted page you redirect to. Best for paid subscriptions and most one-off products. Two lines of code.
• Payment Links — a single static URL Stripe generates from the dashboard. No code at all. Best for tipping, ebooks, anything where you don’t need a custom checkout flow.
• Pricing Table — an embedded HTML block (a couple of lines of code) that shows multiple tiers side by side. Best for subscription-with-tier-comparison pages.

Most operators pick the wrong one because the docs make Checkout sound default. For a single product or single tier, use a Payment Link. For “monthly vs annual vs founding member” comparison, use a Pricing Table. Use Checkout when you actually need fields the others don’t support (custom metadata, B2B tax IDs, complex flows).

Webhooks

Webhooks are HTTP callbacks Stripe fires when something happens in your account (payment succeeded, subscription cancelled, card failed). Without webhooks, your site doesn’t know when someone pays or unsubscribes — you have to poll the Stripe API or check the dashboard manually.

The mistake operators make: skipping webhooks because the platform “seems to work without them.” Then a subscriber cancels, Stripe stops billing, but your site keeps showing them as a paid subscriber for weeks. Or a card fails, Stripe stops collection, but your welcome email keeps going to a churned customer. Set up webhooks on day one. The single endpoint your platform exposes (e.g. /wp-json/otts-pro/v1/stripe/webhook) is the difference between a working paid-newsletter system and a broken one.

Customer Portal

The Customer Portal is a Stripe-hosted page where your subscribers can manage their own subscription — change card, switch from monthly to annual, cancel, view invoices. It’s free, takes about an hour to enable, and prevents 100% of “how do I cancel” support emails.

If you don’t enable it, every cancellation request becomes a manual ticket where you log into the Stripe dashboard, find the customer, click Cancel, and email them confirmation. At 100 paid subscribers this happens once a week. At 1,000 it happens daily. Enable the Customer Portal on day one and link to it from your welcome email.

Smart Retries / dunning

Stripe’s “Smart Retries” feature retries failed card charges on a schedule (3 days later, 5 days later, 7 days later). Stripe also handles the customer-facing “your card failed, please update it” emails. This is dunning, and it recovers something like 30–40% of payments that would otherwise be lost.

It’s not on by default for every account. Go to the Billing settings → Subscription and emails → enable both Smart Retries and the failed-payment emails. Most operators discover this exists after watching their MRR drop unexpectedly because expired cards weren’t being recovered.

Setup, in the order to actually do it

1. Create a Stripe account at dashboard.stripe.com/register. The signup is fast. Use your business email, not personal.
2. Activate the account. Stripe asks for business details — legal name, registered address, tax ID, bank account, ID document for the responsible person. Most US accounts activate within an hour; business-entity verification can take 1–2 business days. Do this before you launch your paid tier; activation delays after you’ve taken pre-orders are stressful.
3. Set up the bank account for payouts. Daily payouts are the default. If your bank charges per deposit, switch to weekly.
4. Enable the Customer Portal in Settings → Billing → Customer Portal. Configure what subscribers can change themselves (recommended: cancel, update card, change plan, download invoices).
5. Set up products + prices in the Stripe dashboard, not in code. Define a “Newsletter Subscription” product with monthly and annual prices. Price IDs (price_xxx) are what your platform references.
6. Set up webhooks pointing at your platform’s webhook endpoint. Subscribe to at minimum: checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed.
7. Configure tax handling via Stripe Tax. Turn it on the moment you sell internationally; for US-only sellers you can defer until you cross state-level economic nexus (commonly $100k in revenue or 200 transactions in a single state).
8. Test in test mode before going live. Stripe provides test card numbers (4242 4242 4242 4242 always succeeds, 4000 0000 0000 0002 always declines). Run your full subscribe → cancel → resubscribe flow before flipping the switch.

Pitfalls, in the order operators usually hit them

1. The activation delay catches people before launch. You announce the paid tier on Twitter, send your announcement newsletter, and discover the Stripe account isn’t activated yet. New subscribers see “Payments are temporarily unavailable.” Activate the account a week before you intend to take payments.

2. Tax registration for international and out-of-state sales. The day you take a payment from an EU resident, you’ve technically created a VAT obligation in their country once you cross the threshold. Domestically, US sellers cross state-level sales-tax obligations as soon as you trigger economic nexus (commonly $100k in revenue or 200 transactions per state). Stripe Tax handles the calculation and remittance for both — turn it on. Don’t try to handle this manually.

3. Currency conversion losses. If your prices are in $ but a UK or EU customer pays in £ or €, Stripe converts at a slightly worse rate than wholesale. Over a year of $10k in international payments, this is roughly $250 in extra fees. For most operators it’s negligible. For high-volume operators with a heavily international audience, multi-currency pricing (separate $, £, € prices for the same tier) is worth the setup time.

4. Chargebacks. A subscriber forgets they signed up, sees a charge on their statement, calls their bank, and disputes it. Stripe charges $15 per dispute regardless of outcome, plus the original charge gets reversed. The fix: clear billing descriptors (your statement descriptor should be your newsletter name, not “STRIPE PAYMENT”), explicit confirmation emails on first charge, and a visible Customer Portal so cancellations don’t become disputes.

5. The “trial that never converts.” If you offer a 14-day free trial, plan for 30–50% of trials to never enter a card. Stripe’s Trial requires a card upfront by default; consider whether your business model can handle the conversion drop from card-required vs the support overhead of cardless trials.

6. Refund policy ambiguity. Newsletter operators often forget they need a refund policy. Stripe’s terms require it. Most newsletters use “no refunds, cancel anytime to stop future charges” — fine, just put it on the pricing page.

Long-term maintenance

Monthly: review the Stripe dashboard’s reporting — MRR, churn, failed payments, top products. Stripe’s built-in reporting is enough for most operators; only graduate to ChartMogul or similar if you’re managing multiple products with complex cohort analysis.

Quarterly: reconcile Stripe payouts with your accounting software. Most accounting tools (QuickBooks, Xero, Wave, FreshBooks) have direct Stripe integrations. Check that fees are categorised correctly and that you’re capturing the right amount as taxable income (revenue, not net of fees).

Annually: review your dunning configuration. The default Stripe retry schedule is good but not optimal — if your average customer’s card expires every 36 months and you’re seeing more declines than expected, lengthen the retry window. Also review tax thresholds — if you’ve crossed a new sales-tax or VAT registration threshold, Stripe Tax will surface this but you need to act.

When something breaks: Stripe’s status page (status.stripe.com) is reliable. If checkout’s down, check there before debugging your own code. Outages are rare but they happen.

When Stripe is the wrong choice

If you publish entirely on Substack or Beehiiv, you’re already on Stripe — the platform handles the integration and you don’t need to manage it directly. The platform takes 10% of your revenue for that convenience. That’s a fair trade until you outgrow the platform’s limitations.

If your audience is heavily in countries where Stripe lacks strong local payment methods (most of South America, parts of Africa, India to a lesser extent), look at regional alternatives — Razorpay in India, Mercado Pago in Latin America. Or use Stripe with regional payment-method enabled (iDEAL, Bancontact, etc.) and accept that some markets will be harder to convert.

If you’re selling primarily B2B with complex invoicing requirements (purchase orders, net-60 terms, custom contracts), Stripe Invoices is fine but accounting-software-native invoicing (QuickBooks, Xero) often integrates better with the rest of the B2B workflow.

For everyone else, Stripe is the default — and like the other infrastructure decisions in this stack, that’s the highest compliment infrastructure can earn.

Some links in this post are affiliate links — we earn a small commission if you sign up through them, at no cost to you. We only recommend tools we actually use.

Stripe offers two ways to collect payment without building a full checkout flow: payment links and checkout sessions. They look similar on the surface—both generate a Stripe-hosted page where customers enter their card details—but they solve different problems and scale differently.

If you’re selling a course, accepting sponsorships, or launching a paid tier, knowing which tool to reach for saves you from either over-engineering or outgrowing your setup in three months.

What payment links do well

Payment links are static URLs you generate once in the Stripe dashboard. You pick a product, set a price, click “Create link,” and get a URL like buy.stripe.com/abc123. You paste that into an email, a Notion page, a Linktree, or anywhere else.

They’re dead simple. No code. No integration. You can create one in under 60 seconds.

They work best when:

• You’re selling one or two products with fixed pricing
• You want to test demand before building infrastructure
• You need to send a payment request to a specific person (e.g., a sponsor invoice)
• You’re embedding buy buttons in no-code tools like Carrd or Notion

The trade-off: payment links are not dynamic. You can’t pass custom data, adjust pricing per customer, or trigger complex logic after payment. Every link points to the same product at the same price. If you want to sell three tiers, you need three separate links.

When checkout sessions make more sense

Checkout sessions are generated programmatically via Stripe’s API. Instead of a static URL, your server (or a tool like Zapier, Make, or a membership plugin) creates a unique session each time someone clicks “Buy.” That session can include custom line items, coupon codes, customer metadata, or pre-filled email addresses.

You need a bit of code—or a tool that wraps the API—but you get control in return.

Checkout sessions shine when:

• You’re selling multiple SKUs or pricing tiers from one page
• You want to pass user data (email, name, UTM params) into Stripe’s metadata
• You need to apply dynamic discounts or generate invoices on the fly
• You’re integrating with a CRM, membership site, or email platform that reacts to purchase events

For example: if you run a course platform and want to tag buyers in ConvertKit the moment they pay, a checkout session can include the buyer’s email and course ID in metadata. A webhook listens for checkout.session.completed, pulls that metadata, and fires the tag. Payment links can’t do that.

Pricing and limits

Both options use the same Stripe transaction fees: 2.9% + 30¢ for cards in the U.S. There’s no additional cost for using payment links vs. sessions.

Payment links support subscriptions, one-time payments, and even “customer chooses price” donation-style flows. Checkout sessions support the same, plus more flexibility around tax collection (Stripe Tax), installment plans, and multi-currency pricing.

One gotcha: payment links expire after 90 days of inactivity if you’re on a free Stripe account and haven’t processed volume recently. Checkout sessions expire after 24 hours by default (you can extend this to 30 days), but they’re generated fresh each time, so expiration is rarely an issue in practice.

Which one to pick

Start with a payment link if you’re testing, selling one thing, or need something live in the next five minutes. It’s faster than building anything, and you can always upgrade later.

Move to checkout sessions when you need:

• Dynamic pricing or product selection
• Integration with your CRM, ESP, or membership tool
• Custom metadata or post-purchase automation
• A branded checkout domain (Stripe lets you use checkout.yourdomain.com with sessions, not links)

Most solo operators start with payment links for their first product, then switch to sessions once they’re running webinars, cohort courses, or tiered sponsorships. The migration is straightforward—your Stripe account, customer data, and reporting stay the same. You’re just changing how the checkout URL gets generated.

If you’re already using WordPress and want a middle ground, plugins like WP Simple Pay generate checkout sessions without writing code. You build a shortcode-based button, and the plugin handles the API call behind the scenes.

One more thing: whichever option you pick, turn on Stripe’s email receipts in your dashboard settings. A shocking number of operators forget this, and customers assume the payment didn’t go through when they don’t get confirmation. That’s a support ticket you don’t need.

Want more breakdowns like this? Reply and tell us which tool or feature you’re trying to figure out—we’ll cover it in a future issue.