An IPTV Reseller Account Suspension Policy is the written set of rules that decides when a reseller or sub-reseller account is restricted, frozen or closed, what happens to its credits and customer lines in the meantime, and how the account holder can respond. A usable policy names the triggers, matches each one to a specific panel action, sets out the notice the account holder receives, and explains the route back to full access.

Most IPTV panel resellers deal with this from two directions at once. Your upstream provider almost certainly has suspension terms covering your own panel, and if you run sub-resellers, you need your own version for the accounts below you. The two have to line up. If your provider can freeze your balance after a payment dispute, a sub-reseller policy promising that balances are never frozen leaves you covering the difference yourself. Read the terms above you first, then write yours so it never promises more than that layer can guarantee.

What an IPTV Reseller Account Suspension Policy Actually Covers

Suspension is rarely a single switch. In practice, a panel gives you several levels of control, and a good policy uses the lightest one that deals with the problem. Treating every issue as “disable the account” causes most of the damage, because it hits end customers who did nothing wrong.

It helps to separate four states:

The middle two rows carry most of the weight. Restriction stops further harm without touching the customers already served, and it is the right first move for most financial triggers. Full suspension belongs to situations where leaving the login active is itself the risk, such as stolen credentials or a credible complaint that the account is being used to distribute material without proper rights.

Beyond the states themselves, every policy needs to answer four questions in writing: what triggers each level, who on your side is allowed to apply it, how much notice the account holder gets (and when notice can come after the action rather than before), and what happens to credits and customer lines at each stage. If any of those is answered only in someone’s head, the policy will be applied inconsistently, and inconsistency is what turns a routine suspension into a dispute.

The Panel Workflow From Trigger to Resolution

The steps below follow the order things should happen in a real IPTV panel reseller dashboard. The sequence matters more than the wording you use for it.

1. Record the trigger before touching the account

Write down what happened, where the information came from and when it arrived. A payment processor’s dispute notice, an abuse report, an automated alert about failed logins and a sub-reseller’s own message all count. This record is the first thing you will need if the account holder challenges the decision later, and it takes two minutes to write while the details are fresh.

2. Check the panel’s own evidence

Before deciding anything, look at what the panel shows: recent logins and their locations, credit movements, the rate of new line creation compared with the account’s normal pattern, and any changes to passwords or contact details. A sudden burst of new lines from an unfamiliar location points to a compromised login. The same burst from the usual location, a day after a disputed payment, points somewhere else entirely. The evidence decides which level of the policy applies.

3. Choose the lightest action that contains the problem

Match the evidence to the state table. For suspected compromise, revoke sessions and force a password reset first; if the sub-reseller then confirms the activity was not theirs, restore access with two-factor authentication on the IPTV reseller panel switched on rather than leaving the account locked indefinitely. For financial triggers, restriction is usually enough. Escalate only when the lighter step fails or the evidence justifies it.

4. Export the account’s line list first

Before you disable a sub-reseller, check what your panel does to the lines underneath a disabled account. Behaviour varies between panel software and configurations: on some setups the lines keep running until expiry, on others they stop with the parent account. Either way, export the line list with expiry dates first. If the panel removes visibility of those lines once the account is disabled, that export is your only record of who is affected. This is one of the clearest reasons for keeping your own panel data backups instead of trusting the dashboard to remain readable.

5. Send written notice

The notice should state the reason in plain language, summarise the evidence without exposing anything confidential, explain exactly what has changed in the account, give a response deadline and say what happens if the deadline passes. Send it through the channel your terms name as official, and keep a copy. Where the trigger is a security incident, acting first and notifying immediately afterwards is reasonable, provided your written terms say so.

6. Run the review window

Give the account holder a fixed period to respond. The exact length matters less than applying the same window every time. During the window, keep the account at the level you chose and avoid quietly escalating because a reply seemed unconvincing. If new evidence appears, record it and issue an updated notice.

7. Resolve, settle and close the record

The outcome is one of three: full reinstatement, reinstatement with conditions (a credit limit, compulsory two-factor sign-in, a temporary cap on new lines), or termination. Settle the credit balance exactly as the written terms describe, note the outcome against the original trigger, and close the record. Unclosed cases are where confusion builds up months later.

Worked Example: A Disputed Credit Purchase on a Sub-Reseller Account

The figures below are illustrative, chosen to show the decisions rather than to reflect any particular provider.

A sub-reseller holds 120 credits bought from you over several months and serves 85 active customer lines. On a Monday morning, your payment processor tells you a card payment covering 60 of those credits has been disputed. Checking the panel, you see the account created 25 new lines over the weekend, against a usual rate of two or three a day, all from the account’s normal login location.

The evidence does not point to compromise. It points to a financial risk: credits that may be reversed are being turned into lines quickly. That calls for restriction, not suspension.

The 85 existing customers saw no interruption at any point, and the sub-reseller kept their login throughout, so they could still renew lines using credits already confirmed as paid.

Now change one detail. Suppose the sub-reseller never replies and the dispute is upheld. When the review window closes, you move to suspension: the 60 disputed credits are deducted under the terms, the remaining balance is frozen, and the login is disabled. Because you exported the line list on Monday, you know exactly which customers sit beneath the account and when each line expires, so you can decide, under your terms, whether those lines run to expiry and who those customers should contact. Without that export, you would be guessing.

Errors That Turn a Suspension Into a Bigger Problem

Disabling first, investigating second. The instinct to lock everything is understandable, but a full suspension on a financial trigger often punishes customers further down who paid in good faith, and it hands the sub-reseller a genuine grievance.

Policies that exist only in chat history. If your terms are scattered across months of messages, a sub-reseller can reasonably argue they never agreed to them. Put the policy in one document, date it, and get a clear acceptance when an account is created or the terms change.

Forfeiting whole balances. Clawing back the specific disputed credits is easy to justify. Keeping an entire paid balance because of an unrelated breach is the kind of term that gets challenged, and it rarely survives a payment dispute of its own.

Ignoring your upstream exposure. If your own provider suspends your panel, every sub-reseller and customer beneath you is affected at once. Your sub-reseller policy should say what happens in that case, and your disaster recovery plan should cover how you keep serving customers and communicating while it is resolved.

Treating rights complaints as noise. A credible notice that an account is being used to distribute material without proper rights is a legitimate reason to restrict access pending review. Whatever software you supply, the duty to act on a credible complaint does not disappear because the account holder disputes it.

No route back. A suspension with no stated reinstatement conditions becomes a permanent termination by default, without anyone actually deciding that.

Pro tip: Run your suspension records alongside a scheduled line audit. Accounts that are restricted or suspended should show up in the audit with a reason attached, so nobody reactivates them by mistake while tidying the panel.

Suspension Policy Audit Checklist

Use this once a quarter, or whenever your provider changes its own terms.

• Your provider’s current suspension terms are saved, dated, and compared against your sub-reseller policy
• Every trigger in the policy maps to one named account state and one panel action
• Only named people can apply restriction, suspension or termination, and panel roles enforce this
• The notice template includes reason, evidence summary, what has changed, deadline and consequences
• The policy states when action may come before notice, limited to security and rights cases
• The review window is a fixed length and has been applied consistently to every open case
• Line lists were exported before each suspension in the last quarter
• Credit treatment is written down separately for frozen, disputed and settled balances
• Every suspended or restricted account in the panel has a matching record with a reason
• No case from the previous quarter remains open without a recorded outcome
• Sub-resellers accepted the current version of the policy, with the acceptance date recorded

Questions Resellers Ask About Account Suspension

Can my provider suspend my panel without warning?

That depends entirely on their written terms. Many providers reserve the right to act immediately for security incidents, unpaid balances or rights complaints. If the terms are vague, ask for clarification in writing before you need it, and build your own policy around the strictest reasonable reading.

Do customer lines stop when a sub-reseller is suspended?

It depends on the panel software and how it is configured. Test the behaviour on a dormant test account before a real case forces the question, and write the answer into your policy so sub-resellers know what to expect.

Should a suspended sub-reseller keep their credits?

Freezing a balance during review is normal. Deducting credits tied directly to a disputed or reversed payment is defensible. Removing an entire paid balance should be reserved for terms that clearly allow it, and even then it invites disputes.

How long should the review window be?

There is no industry standard. A short fixed window, such as five working days, works because it is easy to apply consistently. What matters is that the same window applies to every comparable case.

Is a suspension policy necessary with only two or three sub-resellers?

Yes, and it is easier to put in place now than after the first dispute. A one-page document covering triggers, actions, notice, credits and reinstatement is enough at that size.

Where This Leaves Your Policy

A workable IPTV Reseller Account Suspension Policy is less about the power to switch accounts off and more about using the smallest action that solves the problem, in a sequence you can defend later. Record the trigger, check the evidence, contain the risk, protect the customers underneath and give a clear route back. Its main limitation is that it can never be stronger than the terms your own provider applies to you, so start by reading theirs, then use the checklist above to test whether your version would hold up against the next real case.