Renewing, upgrading, switching accounts: the order matters

Upgrading before renewing means paying twice for the same month. There is one correct order.

Three actions that look similar and cost very different amounts. Done in the right order, one of them saves you a whole month. Done in the wrong order, you pay twice for the same thirty days.

Case 1: plain renewal

The easy one, and the one people most often leave too late. Renew before expiry, not after — once a period has lapsed, some vendors require a fresh verification or a new payment method, and in a system that sends no email those extra steps are harder to recover from, because your only record is the order number and the transaction hash.

Rule of thumb: handle it 2–3 days early. Not on the last day, and never across a weekend. But not two weeks early either, which just overlaps two paid periods.

A renewal is a new order against the same account: supply the same Organization ID again, the one beginning org_. No login information has to be handed over again.

Case 2: upgrading

Correct order: upgrade first, then think about the renewal cycle. Doing it the other way means paying twice for the same period — once to renew the old tier, once to start the new one.

Our rule is stated arithmetically: the refund is the order amount multiplied by unused days, divided by total days. So if twenty days of the old period are genuinely unused, those twenty days come back proportionally, and the cheapest sequence is: run the old tier close to its end, then start the heavier one.

One check before you upgrade: look at which ceiling you touched. If two days of intense work drained the roughly five-hour window, that is pacing, and a bigger tier will not fix it. If steady daily use stops mid-week, that is the weekly cap, and a heavier tier is the right answer.

A replacement subscription is offered before any refund discussion; if it ends as a refund, the money goes back on-chain to the address you sent from, usually confirmed inside twelve hours.

Case 3: switching accounts

Usually because the old account was restricted, or the work space has moved. Order matters more here: verify the new account can log in and can be upgraded before paying. Otherwise the money is gone, the new account cannot take the plan, and the whole thing becomes a refund that costs you another cycle.

Three things to finish before paying: log in once in the browser on the new account; open Settings, then Account, and confirm the Organization ID can be copied; confirm the account is not suspended or mid-appeal.

Conversations and projects do not move with you. Export what you need yourself before abandoning the old account; nothing here moves on your behalf.

Case 4: two subscriptions at once

One account generally cannot hold two tiers of the same product. Running two in parallel means two accounts — and two separate transactions of business: two orders, two invoices, two transfers.

This is where payment discipline breaks most often. One invoice carries one network and one exact amount; combining two orders into one transfer does not clear both, it creates a single movement that neither order can claim. Splitting one order across two transfers does the same. The network fee sits on top and is carried by the sender.

Quick reference

• Renewal only → 2–3 days before expiry, same Organization ID, new order
• Upgrade → start the new tier as the old one runs out; unused days come back prorated
• New account → confirm it logs in and the identifier copies cleanly before paying
• Parallel use → two accounts, two invoices, two transfers, never merged
• Refund → accept the replacement offer first, then the day-prorated amount, on-chain

If you are still choosing a tier, start with the price list, then read monthly vs annual. The full arithmetic of a partial refund is on the refund page; what actually stops on expiry day is in what happens when the subscription expires.

Common questions

Back to plans →