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
- Create a Stripe account at dashboard.stripe.com/register. The signup is fast. Use your business email, not personal.
- 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.
- Set up the bank account for payouts. Daily payouts are the default. If your bank charges per deposit, switch to weekly.
- Enable the Customer Portal in Settings → Billing → Customer Portal. Configure what subscribers can change themselves (recommended: cancel, update card, change plan, download invoices).
- 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. - 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. - 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).
- 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.