Buying well
How to switch SMM panels without losing refill coverage
Last updated by The PanelCompare editorial team, 7 min read
What actually transfers when you change panels?
Nothing. Not the wallet balance, not the order history, not the refill coverage, and not the service IDs. A refill guarantee is a promise about one specific order, measured against the start count that one specific panel recorded before that order began, and it can only be invoked through that panel’s mechanism. A new panel has no record of any of it and no obligation arising from it.
That is worth stating plainly because the market frequently talks about coverage as though it were a property of the followers rather than a property of the order. It is neither transferable nor assignable, and no panel has ever offered to honour another panel’s window.
Why does the order of operations matter so much?
Because the thing that voids a refill claim most often is not a closed window, it is a contaminated baseline. A second order records a start count that already includes the first order’s delivery, so once two panels have live orders on one link, neither has a clean measurement of what it delivered, and both are entitled to refuse a claim on exactly that ground.
Never overlap two panels on one link
This is the single mistake that makes a migration expensive. If an old order still has an open refill window on a link, do not place a new order on that link from anywhere else until the window has closed or the claim has been made and settled. If you need more units in the meantime, use a different link.
The good news is that most of the catalogue has nothing to protect. Of 7,754 live offer rows in the index, 6,409 carry no refill window at all, so most historical orders create no constraint on when you can move (PanelCompare price index, 2026-09-10). Check which of your open orders actually carry a window before planning around them.
What has to be exported before you leave?
Everything the panel will stop showing you the moment the account lapses, which is most of what a later dispute would need. Panels do not send a closing statement, and a panel that is winding down takes its site offline without notice, so the export is a one-way door.
| Field | Where it comes from | Why it matters after you leave |
|---|---|---|
| Order ID | The order table, or the add response | The only reference the old panel will accept for a claim |
| Service ID and full row name | The catalogue at the time of order | IDs are panel-local and mutable; the name is how you re-map it elsewhere |
| Start count | The status response, field start_count | Every refill obligation is measured against it, and it cannot be reconstructed |
| Delivered quantity and remains | The status response | Distinguishes a drop from a Partial that was already refunded |
| Completion date | The order table | The refill window runs from completion, not from purchase |
| Refill IDs already issued | The refill response | The only reference for chasing a refill that never landed |
| Charge and wallet movements | The status response, field charge | The basis of any payment-rail dispute |
Source: Field names from the SMM Panel API v2 status and refill responses, verified 2026-09-11.
If the panel exposes an API, this is a single scripted pass rather than an afternoon of copying: the status action takes up to 100 order IDs at a time, so a year of orders is usually a handful of requests. Do it before you announce anything, not after.
What is the safe migration sequence?
- 1.Inventory the old panel first: every order in the last 12 months, its link, its refill window, its start count and its completion date. Export it before you stop using the panel, because panels that are winding down take their sites offline.
- 2.Identify which of those orders still have an open window, and on which links. Those links are frozen until the window closes or a claim is settled.
- 3.Test the new panel on rows you actually plan to buy, on links that are not frozen. Use the minimum quantity: 6,679 of 7,754 index rows can be bought at their minimum for a dollar or less.
- 4.Claim anything already dropped on the old panel now, through its refill mechanism rather than a ticket, and keep the refill IDs.
- 5.Spend the old wallet balance down on the frozen links while the windows run out. A stranded balance is the most common avoidable loss in a migration.
- 6.Move new volume to the new panel link by link, as each frozen link comes free.
- 7.Keep the old panel account open with a minimal balance for a month. If the new panel’s upstream fails in week two, you want somewhere to go that you have already tested.
What happens to the balance left on the old panel?
In most cases it stays there. Panels are prepaid wallets, withdrawals are uncommon and frequently unavailable, and a balance you stop using is a balance you have donated. Plan the spend-down before the switch rather than after, and do not top up a panel you are already planning to leave, whatever bonus is offered.
Be alert to the pattern here. Aggressive deposit bonuses appearing on a panel you were already unhappy with are one of the recurring signals ahead of an exit, and a migration is exactly when a buyer is most tempted by one last cheap top-up.
What changes if you are switching panels behind an API?
The client barely changes, and the data does. Almost every panel implements the same API v2 specification, so a client written against one panel works against another with a base-URL and key change. What does not carry over is the service ID mapping: IDs are panel-local and mutable, so every stored ID has to be re-mapped against the new catalogue by name and by rate, not assumed.
- Re-fetch the full catalogue and re-map every canonical service you sell. Do not port an ID table.
- Map by name and rate together, and leave anything ambiguous unmapped rather than guessed. A wrong mapping quietly sells the wrong product at the wrong price.
- Keep the old panel connected read-only for as long as open orders exist there, because status and refill_status still have to be pollable.
- Store the panel identity alongside every order ID. Order IDs are only unique within a panel, and a migration is exactly when two panels’ ID spaces start overlapping in your database.
- Rotate the old key after the cutover. The specification has no expiry and no replay protection, so an abandoned key stays live until it is revoked.
When is switching the wrong response?
When the failure is upstream rather than at the panel. If several unrelated services go Partial at the same moment, an upstream provider has failed, and the panel you move to may well be connected to the same one — which is why unrelated panels so often break in the same week. Moving costs a migration and fixes nothing.
The signal that distinguishes the two cases is the breadth of the failure. One row failing is a service problem, and a different row on the same panel will usually work. Every row failing at once is a supply problem, and the useful response is to wait, test a panel with a visibly different catalogue, and keep a second account funded so the question does not arise under pressure next time.
Quick answers
Does a refill guarantee transfer to a new panel?
No. Refill is a promise about one order, measured against the start count that panel recorded, and it can only be claimed through that panel. No panel honours another panel’s window.
Can I order from two SMM panels at the same time?
On different links, yes. On the same link while a refill window is open, no: the second order contaminates the start-count baseline and both panels can refuse a claim on that ground.
Can I withdraw a balance from an SMM panel?
Usually not. Panels are prepaid wallets and withdrawal paths are uncommon and often disabled. Plan to spend a balance down before leaving rather than expecting to recover it.
Do service IDs mean the same thing on every panel?
No. Service IDs are local to a panel and can be repointed at a different upstream. Re-map every ID against the new catalogue by name and rate rather than porting a table.
Every figure here is attributed and dated
Prices in this market move weekly, so a number without a capture date is decorative. Where this guide quotes a figure it names the source and when it was checked. If one of them is wrong, the correction process on the about page has a two-working-day reply target, and corrections are published with a dated note rather than quietly patched.