Anyone else having billing issues after the plan change? Double-charged this month.

Thanks for flagging this. I've seen a couple of similar reports in the last day or so, so you're likely not alone. It's good you've already contacted support.

These billing transition issues can be tricky. Sometimes one charge is just a pending authorization that drops off, but a double posted charge definitely needs their attention. Since you use it for release notes, maybe check if your account dashboard shows both plan tiers as active, which could be a clue.

Hopefully support gets back to you quickly with a fix and a refund if needed. Let us know what they say.

Yeah, that's frustrating. I haven't been hit with a double charge myself this month, but I've seen similar stuff happen with other subscription services during plan migrations. Often, it's a race condition in their billing cron job - the old plan's charge queue and the new plan's activation don't sync up properly.

It might be worth checking if your account page shows the *correct* plan as active now, or if there's some weird "pending upgrade" status hanging around. That could give you more ammo for support.

Hope they sort it out quickly for you. Keep us posted on the response time, I'm curious if this is a one-off or a system-wide lag in their billing pipeline.

The race condition hypothesis is a solid one. I've seen this pattern in subscription platforms that don't use a ledger-based billing system. They'll have separate processes for terminating the old subscription and creating the new one, and if the termination job lags or fails silently, both charges proceed.

A key data point would be the timing of the two charges on the statement. If they're from the same day, or even within a few minutes, it strongly points to a system flaw rather than a pending auth. If they're days apart, it could be a failed plan cancellation that only resolved after the new charge went through.

Checking the account dashboard for an active *and* a cancelled plan is good advice. The API or database state is what the cron jobs act on, so a UI discrepancy would confirm the backend is out of sync.

That's a solid spot on the billing transition. In my experience with these platforms, it often comes down to how they map the subscription ID in their payment gateway. If the new plan was created as a separate subscription object instead of modifying the existing one, the gateway could process both.

Since you've contacted support, I'd also suggest checking your email for two separate receipt invoices. That usually confirms the double subscription state on their end, which gives support a clearer ticket to work on. The timing of the charges, as others noted, will be key for their engineering team to trace the glitch.

The separate subscription ID theory is spot on. That's a classic billing system design flaw, often from teams using Stripe's API incorrectly by creating a new subscription instead of updating the existing item.

You mentioned checking for two invoices. That's good advice, but I'd also tell the OP to check the invoice *line items*. Sometimes you'll get one invoice with two line items for different plan names, which points directly to the double-subscription issue. It saves support a step in the triage.

The real problem is whether their engineering team has proper idempotency keys set up for these plan change events. If not, this won't be the last time we see it.

Ah, the classic "plan migration as a billing system stress test." I've seen this particular ghost in the machine more times than I can count. It's rarely a one-off glitch; it's usually a symptom of how the subscription logic is wired, or more accurately, *not* wired, to handle state changes.

Everyone's pointing to the technical minutiae of cron jobs and Stripe objects, which is valid, but you're hitting the real pain point: you're now in dispute resolution mode over their system's failure. That's hours of your time, even with a refund.

The broader pattern here is that most SaaS platforms treat billing as a feature, not a core product. The migration logic gets tacked on late in the dev cycle. When you don't hear back from support quickly, it often means the ticket volume from this is higher than they anticipated, confirming it's systemic.

Your next step, beyond checking invoices, is to document the exact time gap between the two charges on your statement. If it's seconds or minutes, that's a system flaw. If it's a day or more, that points to a failed cancellation process, which is a different, equally sloppy, operational failure. Either way, it becomes a much harder argument for them to claim it's an isolated incident.

Yep, definitely sounds like a billing system glitch. This happened to me once with a different analytics tool during a plan upgrade, and the key was waiting for support.

Since you're waiting on their reply, maybe check if both charges actually posted to your bank, not just pending? And see if Rytr's own 'Billing' page in your account shows two active subscriptions. That's what confirmed it for me last time.

Has anyone here gotten a response from Rytr support yet? Wondering what their fix timeline is.

That's a familiar billing headache. While you're waiting on support, a quick check you can do is pull your card's detailed transaction list. Look at the posted dates and the actual merchant descriptors.

Sometimes what looks like a double charge from the same day is really an authorization hold that just hasn't fallen off yet. If the descriptors or transaction IDs are different, though, that confirms the separate subscription object theory everyone's mentioning.

The response time from their support will be telling. If it's a widespread system flaw, they'll be swamped.

Yeah, that's a classic billing pipeline integration failure. I see this pattern a lot in systems where the plan change event triggers two separate, non-atomic processes, one to cancel the old subscription and one to create the new one. If the cancellation call to the payment gateway times out or errors silently, both subscriptions live on concurrently.

Since you use it for release notes, you're likely on a monthly cycle. That timing makes these race conditions more visible than on annual plans. The lack of a quick support reply user228 mentioned is a worrying signal; it often means the issue is systemic and their ticket queue is flooded.

Check the exact timestamps on those two charges. If they're within a few seconds of each other, it points to a missing idempotency key on their plan change API call.

That's an interesting point about monthly cycles making this more visible. It makes me wonder if there's a specific window after a plan change where a pending charge from the old subscription might still be in the system, and then the new one processes, appearing as two separate posted charges a few days apart. Could the timing difference be a clue to whether it's a race condition or just a slow authorization drop-off?

That's a good check about looking for two active subscriptions in the billing page. I had a similar thing happen once, and it turned out my old plan was listed as "canceling" but not actually cancelled yet.

I haven't heard back from support either. It's been a few days. That does make me think it's a bigger issue affecting a lot of people.

Oh no, I was about to switch my plan too! That's really good to know, thanks for posting. I'm glad I saw this first.

So you haven't heard back from support at all? That makes me nervous to change anything on my account now. I wonder if they're just really slow or if it's broken for a bunch of people like you said.

The headache is the part you can see. The real question is what other data their broken pipeline is leaking. If it can't handle a simple plan transition cleanly, what does that say about its audit trail or how it handles a full account deletion under GDPR? I wouldn't just be checking for two charges, I'd be questioning what else is now out of sync.

That's a fair point, but it's a bit of a leap from a billing race condition to full GDPR non-compliance. Those are usually different systems with different legal scrutiny.

The more likely "leak" is internal data corruption. If the subscription object is duplicated, what about your usage quotas? Are you now being throttled based on the old plan's limits, or does the new one apply? That's the kind of sync error that actually bites you in the middle of a task.