A provider deleted a service: how to find broken items in your catalog

Your panel's catalog only looks like yours. Every item in the storefront is really your own row, with your name and your price, pointing at an entry in a provider's catalog. And the provider can pull that entry at any moment: drop an unprofitable service, rebuild a line-up, clean house after switching sources. Nobody asks you, and nobody warns you. Here is what happens to your storefront next, why the panel stays quiet about it, and how to find those items before a customer does.

What actually happens when a service is deleted

Catalog sync is straightforward: the panel asks the provider for a list of services and brings its local copy of that catalog in line with the answer. An entry missing from the answer stops existing in the copy. So far, so sensible.

The non-obvious part comes next. Your storefront service is not that same record. It is a separate row with its own name, description and price, which merely points at the provider entry through a pair of values: provider plus service identifier. It points by value, not by a hard database relation, so deleting one record does not remove the other.

The result: the provider catalog copy no longer has the service, while your service stays live in the storefront. Customers see it, it can go into an order, it has a working price and working quantity limits. The only thing missing behind it is someone to fulfil it.

Exactly the same thing happens without a deletion. The provider rebuilds the catalog and hands the very same services new identifiers: from the outside nothing changed, but every link you hold now points at nothing. From the panel's side that is indistinguishable from deletion.

Why the panel says nothing

The galling part is that the panel knows the entry is gone. It removed it from the catalog copy itself. There is simply nobody for it to tell.

• The catalog change log does not reach that far. The log exists and is more useful than it sounds: it records when a provider changes a rate, a minimum, a maximum, a name or a category. Deletion is not on that list, because nothing changes - the record just stops being there.
• Monitoring looks the other way. Sync health checks watch how fresh order statuses are: whether the exchange is stalled, whether updates keep arriving. A mismatch between your catalog and the provider's never enters its field of view.
• In the storefront the service looks healthy. No badge, no marker. The only way to tell it from a working one is to compare two lists, and nobody does that by hand.

A case from September 2026, so this does not read as theory. A provider removed eighteen entries at once - routine housekeeping on their side. Broken services appeared within the hour in four rented panels: eighteen in two of them, one each in the other two. Not a single panel raised a flag. They were found by comparing catalogs, and only after the fact.

What it costs you

From there events follow one script, and it is an unpleasant one:

• a customer orders a service the provider no longer has;
• the panel debits their balance, because an order has been created;
• the order goes out to the provider, who replies with something like "incorrect service ID";
• the order drops into an internal error state, and the money is not returned to the balance;
• the customer does not see an error - they see "pending", and they wait patiently.

That last point looks like concealment and is actually a deliberate trade-off: a failed hand-off is normally pushed through by retries within minutes, and the word "error" in a customer account would only generate tickets about orders that resolve themselves. So the customer is shown pending while the operator sees the real status in the admin panel - more on that in the piece on why an order hangs in Pending.

And this is exactly where a deleted service falls out of the general rule. Retries can tell a temporary failure from a permanent one: "incorrect service", "service not linked", "invalid link" do not need repeating, because repeating will not fix them. Such orders are handed to an operator, which is the right call. The catch is that nobody called the operator. The order sits there, the customer sees "pending", the money is gone, and that holds until the first complaint.

How to find broken items

The check comes down to one action: compare your own services against the provider catalog copy on the pair "provider plus service identifier", and take the ones with no match. It is a single query - save it once and run it, rather than reinventing it each time.

A few practical notes:

• The catalog copy has to be fresh. Catalog sync is heavier than balance sync, so it usually runs less often: our catalogs refresh hourly, balances every fifteen minutes. A comparison against yesterday's copy shows yesterday's picture.
• Check on events, not only on a calendar. Triggers: the provider announced a clean-up or a catalog rebuild, you rotated their API key, you added a second provider covering the same services. A weekly scheduled pass is worth having, but event-driven checks catch the bulk of it.
• Do not forget disabled providers. A service tied to a provider you switched off, or whose access expired, behaves identically: alive in the storefront, nobody behind it.

And one safeguard in the opposite direction that people rarely think about until it burns them. If the provider answers with an empty catalog - their API went down, the key expired, the endpoint moved - a naive sync will dutifully wipe every entry and turn your entire catalog broken in one pass. An empty response must therefore count as a sync failure, not as an instruction to delete everything. For us that is a separate guard, and it fails on purpose.

What to do with what you find

• Disable rather than hard-delete. A soft disable keeps the service identifier and its order history. A hard delete breaks references in old orders and in analytics, and buys you nothing in return.
• Relink it if the entry simply moved. More often than not the service is still there with a new identifier. Search by name and category rather than by number, and check the rate and the quantity limits before switching it back on.
• Move a popular item to another provider. A service that pays your bills should not wait for the old provider to restore it. Put it on someone else and return to the question without the time pressure.
• Work through the stuck orders by hand. For each one: either refund the balance or re-place it on a live service. Leaving them is not an option - from the customer's side that is a paid order that was never delivered, whatever your admin panel calls it.
• Message the customer first. "Our provider withdrew this service, we have refunded your balance and can offer this alternative" closes the matter. The same words after a complaint read as an excuse. How those conversations are structured is covered in the piece on customer support and refunds.

How to stop it happening again

• Keep popular items on at least two providers. This is the main rule and the most inconvenient one: a second provider means another balance to fund and another relationship to watch. In exchange your best-selling services stop depending on someone else's housekeeping.
• Read the catalog change log. A sharp rate jump, a rename, a category move are common precursors to an entry being reworked or pulled. The log shows it beforehand; a comparison only shows it afterwards.
• Keep service descriptions honest. If your storefront text has drifted away from what the provider actually delivers, a blind relink will sell the customer the wrong thing. How to build a catalog that avoids this is covered in the piece on building an SMM panel service catalog.
• Judge providers by their discipline too. How often services "disappear" at a provider is as much a criterion as price and speed. The rest of the criteria are in the checklist on choosing an SMM services provider.

Wrap-up

A service deleted at the provider does not disappear from your storefront - it turns into a trap that looks like an ordinary product and springs on the very next customer. Panels generally give you no automatic signal for this, so comparing catalogs has to be a habit rather than a reaction to a complaint. Fifteen minutes once a week is cheaper than one conversation with a customer who was charged and got nothing.

You can see how this works on a live panel without spending anything: orders routed through our own catalog are not metered at all, and with third-party providers the first 100 orders a month are free. That is enough to build a storefront, connect a provider and watch what the panel actually shows you when something changes on their side.