Author: onetwothreeadmin

Most newsletter operators pick a sponsorship pricing model based on what they’ve seen other people charge. That works until a sponsor pushes back, or you realize you left money on the table because your open rate spiked after you locked in a flat fee.

The three common models—flat rate, CPM (cost per thousand impressions), and performance-based—aren’t interchangeable. Each one shifts financial risk between you and the sponsor, and the right choice depends on your list size, niche stability, and how predictable your engagement is.

Flat rate: predictable revenue, capped upside

A flat rate means you charge the same amount regardless of opens, clicks, or conversions. A sponsor pays $500 for a mention in next Tuesday’s issue, period.

When it works: Flat rates make sense when your list is under 5,000 subscribers and fluctuates week to week, or when sponsors care more about brand association than measurable performance. If you write about a tight niche—like SaaS financial planning or Webflow development—sponsors often pay for access to a specific audience, not raw impressions.

The risk you carry: If your open rate drops from 45% to 32% because you changed your subject line format or your ESP flagged a spam issue, you still owe the sponsor the same exposure. You absorb that variance.

One non-obvious move: If you sell flat-rate sponsorships, specify a minimum list size or a floor open rate in your media kit. That way, if your list shrinks unexpectedly, you can renegotiate or pause the deal without breaching the agreement.

CPM: scales with engagement, requires volume

CPM pricing charges per thousand opens (or sends, depending on how you define “impression”). If you charge $40 CPM and 6,000 people open the email, the sponsor pays $240.

When it works: CPM makes sense once your list exceeds 10,000 subscribers and your open rate is stable. Sponsors who buy CPM deals usually run them across multiple newsletters simultaneously and care about cost efficiency at scale. They’re comparing your $40 CPM to someone else’s $55.

The risk the sponsor carries: If your open rate climbs from 38% to 50% because you tightened your subject lines, the sponsor pays more for the same ad slot. That’s why CPM buyers almost always ask for historical open rate data before committing.

Pricing benchmark: As of mid-2026, B2B newsletter CPMs range from $30 to $80 depending on niche. Developer tools and finance newsletters command the high end; general business content sits closer to $35–$45.

Performance-based: aligned incentives, delayed payment

Performance deals tie payment to outcomes: cost per click (CPC), cost per signup, or cost per sale. The sponsor pays $2 for every click to their landing page, or 20% of revenue from customers who convert within 30 days.

When it works: Performance pricing works when the sponsor has a tight attribution model and you’re confident your audience acts on recommendations. Affiliate programs and course launches almost always use performance terms. SaaS trials sometimes do, too.

The risk you carry: You can send to 15,000 people, write a strong callout, and still earn nothing if the sponsor’s landing page loads slowly or their offer doesn’t resonate. You’ve spent the inventory; they’ve paid $0.

What to negotiate: If you agree to performance pricing, ask for a small flat fee as a baseline—say, $200 guaranteed plus $1.50 per click above 100 clicks. That way, you’re compensated for the list access even if conversion falls short.

Hybrid models: combining upfront + performance

Some operators charge a modest flat fee ($300) plus a performance kicker (10% of attributed revenue, or $0.75 per click). This splits risk more evenly and works well when both parties are testing fit for the first time.

Hybrid deals also make renewals easier. If the performance component delivers, the sponsor comes back and often agrees to raise the flat-rate floor. If it underperforms, you’ve still covered your baseline cost.

Which model to lead with

If your list is under 5,000 and growing inconsistently, start with flat rates. Lock in predictable revenue while you stabilize open rates and refine your pitch.

Once you cross 10,000 subscribers and your monthly open rate variance drops below 5 percentage points, switch to CPM. You’ll earn more as your list grows, and sponsors will find your pricing easier to compare.

Save performance-based deals for sponsors who already know your audience converts—typically after you’ve run one flat-rate or CPM test with them and the click-through rate exceeded 3%.

One last note: whichever model you pick, write it into a short sponsorship agreement before you send the invoice. Specify the pricing model, the measurement window, and what happens if you need to reschedule the send. It’s a two-paragraph PDF, and it prevents confusion when the sponsor’s finance team asks why the invoice doesn’t match their internal estimate.

Want more on running a content business without guessing? Subscribe to One Two Three Send and get one operator-focused article like this in your inbox weekly.

If you’re running a paid newsletter, course platform, or membership site on Lemon Squeezy, you’re probably listening for webhooks to provision access, update subscriber status, or log revenue events. But every webhook Lemon Squeezy sends includes a signature header that most operators ignore—and that’s a problem.

Webhook signature verification isn’t optional security theater. It’s the only way to confirm that the POST request hitting your server actually came from Lemon Squeezy, not a malicious actor replaying old payloads or inventing fake subscription events.

Here’s how Lemon Squeezy’s signature system works, how to validate it in your code, and one non-obvious edge case that breaks verification even when you’ve done everything right.

How Lemon Squeezy generates the signature

Every webhook Lemon Squeezy sends includes an X-Signature header. This is an HMAC-SHA256 hash of the raw request body, signed with your webhook signing secret.

You’ll find your signing secret in the Lemon Squeezy dashboard under Settings → Webhooks. It looks like a long alphanumeric string starting with whsec_. Each webhook endpoint you create gets its own secret—if you rotate or delete an endpoint, the secret changes.

The signature process is straightforward: Lemon Squeezy takes the entire JSON payload, hashes it using HMAC-SHA256 with your secret as the key, then sends the resulting hash in the header. Your server’s job is to recreate that hash and compare it to what was sent.

Validating the signature in your code

Here’s a minimal Node.js example using Express and the built-in crypto module:

const crypto = require('crypto');
const express = require('express');
const app = express();

const WEBHOOK_SECRET = process.env.LEMON_SQUEEZY_SECRET;

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  const signature = req.headers['x-signature'];
  const payload = req.body;

  const hash = crypto
    .createHmac('sha256', WEBHOOK_SECRET)
    .update(payload)
    .digest('hex');

  if (hash !== signature) {
    console.error('Invalid signature');
    return res.status(401).send('Unauthorized');
  }

  // Signature valid—process the webhook
  const event = JSON.parse(payload);
  console.log('Event type:', event.meta.event_name);

  res.status(200).send('OK');
});

Two things to note: you must use express.raw() to preserve the raw request body. If you parse the JSON first with express.json(), the signature won’t match—whitespace, key order, and encoding all matter. You also need to compare the hash as a hex string, not a buffer.

If you’re using PHP, the process is similar with hash_hmac(). Python uses hmac.new() from the standard library. The algorithm is the same across languages.

The edge case: timestamp drift and replay attacks

Lemon Squeezy doesn’t include a timestamp in the signature itself, which means a valid webhook payload can be replayed indefinitely. If an attacker intercepts a legitimate webhook—say, a subscription cancellation event—they can resend it to your endpoint days or weeks later, and your signature check will pass.

The mitigation is to track processed webhook IDs. Every Lemon Squeezy webhook includes a unique meta.webhook_id field in the payload. Before processing the event, check whether you’ve already seen that ID. If you have, return a 200 status but skip the business logic.

Store processed IDs in a database table with a TTL—30 days is reasonable. This prevents replay attacks without requiring you to implement a sliding timestamp window.

Here’s the addition to the earlier example:

const event = JSON.parse(payload);
const webhookId = event.meta.webhook_id;

// Check if already processed (pseudo-code)
if (await db.webhookExists(webhookId)) {
  console.log('Duplicate webhook, ignoring');
  return res.status(200).send('OK');
}

await db.saveWebhookId(webhookId);
// Continue processing...

When verification fails even though it shouldn’t

If your signature check is failing consistently and you’re confident the secret is correct, check your server’s request body size limit. Some frameworks—Express included—default to a 100kb limit. Lemon Squeezy’s order_created webhooks can exceed that if the order includes multiple line items or custom data fields.

Increase the limit in your middleware config: express.raw({ type: 'application/json', limit: '1mb' }).

The other common culprit is proxies or load balancers that rewrite the request body. If you’re behind Cloudflare, Nginx, or AWS ALB, confirm that the raw body is being forwarded unmodified. A single trailing newline or whitespace change will break the hash.

Lemon Squeezy doesn’t currently offer a signature verification test mode or sample payloads with pre-signed signatures, so the easiest way to debug is to log both the computed hash and the received signature, then compare them character by character.

If you’re handling payments or provisioning access via webhooks, signature verification isn’t optional. It’s the only way to distinguish legitimate events from forged requests. Set it up once, test it with a live webhook, and add replay protection if your product handles high-value transactions.

Got a question about webhook security or payment automation? Reply to this email—we cover this stuff every week.