Billing

Settings › Billing is where your organization’s subscription lives: which plan you’re on, how much of it you’ve used this period, and how to move to a different plan. It’s an owner-only screen — everyone else gets an access-denied message instead.

​

Who can open it

Admins, Editors, and Viewers have neither permission by default, so Billing is closed to them — see Team and roles. Without billing:manage, the plan comparison and the cancel/reactivate controls don’t render at all; the page is read-only.

​

Current subscription

The first card is the state of your subscription: Two situations get their own callout on the card:

• Trial. While you’re on a trial, the card shows the trial’s end date and the days remaining. When the trial expires, MerchantOps stops accepting new work that consumes your plan (see When limits bite) until you pick a plan.
• Payment past due. If a charge fails, the card warns you to update your payment method before service is interrupted.

​

Cancel and reactivate

With billing:manage, an active subscription shows a Cancel Subscription button. Cancelling is scheduled, not immediate: you keep full access to your current plan until the end of the billing period shown in the confirmation dialog, and your account drops to the free plan after that date. A subscription that’s scheduled to cancel says so on the card and offers Reactivate Subscription, which clears the scheduled cancellation and keeps the plan running past the current period.

​

Usage this period

The second card tracks your consumption against the limits of your plan, with a progress bar per meter. Each bar turns amber as you approach its limit, and the text under it changes once you’re at or over it. A product that’s enriched twice counts twice: the meter measures work done, not products touched. A run that fails doesn’t count, and re-delivering the same queued work after an interruption doesn’t count again either.

​

Change plans

With billing:manage, the page lists the purchasable plans side by side with their limits and features, and marks the one you’re on. Upgrade on any other plan moves you to it:

• If you already have a subscription, the plan is changed in place and prorated — you’re credited for unused time on the old plan and charged for the new one.
• If you don’t have one yet, you’re redirected to a hosted checkout page to enter payment details. On return, MerchantOps syncs the result immediately rather than waiting for the provider’s webhook, so the new plan shows up right away.

Enterprise isn’t self-serve: its card links to a conversation with sales instead of a purchase button.

​

When limits bite

Some actions are checked against your plan before they run: The enrichment check covers the whole request at once — start a run over 200 products with 40 left in your allowance and the run is refused as a unit, not run down to the limit and stopped. Nothing is queued, so nothing is charged. Retrying a job is checked the same way, against the number of items it would re-queue. If the check fails, the request is refused with a payment-required error naming the resource, your current usage, and the limit, and pointing at this page. An expired trial fails these checks outright regardless of usage, until you pick a plan.

​

What isn’t checked up front

Imports, crawls, and document ingestion aren’t checked against your allowance when you start them. The enrichment they trigger downstream is still counted, so a large import can carry your usage past the limit. The next enrichment you start explicitly is what gets refused.

​

Related