How to Find an SMM Provider: Vet, Test and Score Before You Pay

Most guides on how to find an SMM provider hand you a ranked list of ten panels and a paragraph about "great support and fast delivery." That list is worthless within a quarter. Panels change upstream sources, get resold, run out of capacity on the one service you actually sell, or quietly stop answering tickets. A list is a snapshot of somebody else's experience on a day you were not there. What survives is a process: build a shortlist, run a structured test, score what you saw, size your exposure, and keep measuring after you commit.

This article is that process, written for the person about to move real money: a reseller wiring a storefront to a supplier, an agency owner who gets blamed when a client campaign stalls, a panel owner whose customers are already paying. Every number in the worked examples is illustrative and labeled as such. The method is the deliverable.

One thing up front, because it changes how you read every test below. Purchased engagement is not a real audience. It moves numbers, it can conflict with the terms of service of the platform you point it at, and drop risk is real on every service from every provider. Nobody removes that risk. What a good provider does is shorten the chain between you and whatever fulfills the order, make failures visible faster, and give you a mechanism (a refill window, a cancel flag, a refund to balance) for the cases that go wrong.

What you are actually buying when you find an SMM provider

An SMM provider is the counterparty that accepts your order, fulfills it or routes it to whoever does, holds the balance you prepaid, and answers when it fails. You are not buying followers. You are buying four things at once, and they fail independently of each other.

The first is capacity: does the service you need exist, at the volume you need, on the platform you sell. The second is predictability: does an order behave the same way on Tuesday as it did on Saturday, so you can quote a delivery time without inventing it. The third is remediation: when something goes wrong, is there a mechanism rather than an apology. The fourth is counterparty safety: your balance sits on their books before you spend it, so their solvency and their honesty are your problem.

Most buyers evaluate only the first, because it is the only one visible from the homepage. Price and service count are printed on the shelf. The other three are discovered after the money moves, which is exactly why a structured test beats a comparison article. A panel with 6,000 services and no working refill flow will cost you more than a panel with 900 services and a refill button that goes straight through, so score the four separately or you will average away the thing that eventually bites you.

The tier your provider sits at underpins all four. An order passing through three panels before it reaches fulfillment costs more, moves slower, and cannot be diagnosed by anyone in the middle. How the hops accumulate, and how to work out where a given panel actually sits, is covered in the companion piece on what a main provider SMM panel really is. Here, treat tier as one input into the scorecard rather than the whole question.

Write your requirement sheet before you look at a single provider

The most expensive mistake in provider selection is shopping before you have written down what you need. Without a requirement sheet, every panel looks acceptable, because you evaluate each one against its own marketing rather than against your business.

Spend twenty minutes on these. The answers reshape your shortlist more than any review will.

Requirement	The question you answer in one line	Why it changes the shortlist
Platform mix	Which two platforms are 80 percent of your revenue?	Depth on two platforms beats breadth on twelve. A panel strong on Instagram and thin on Telegram is disqualified if Telegram is a third of your book.
Service families	Followers, views, likes, comments, subscribers, members, or something specialized?	Comment, mention and poll services need extra order fields. Many panels list them and cannot fulfill them.
Monthly volume	How many orders and how many dollars per month, honestly?	Under 200 orders a month, API completeness matters less than support. Over 2,000, the reverse.
Speed promise	What delivery window have you already promised customers?	If you promised "starts within an hour," you need median start times measured, not advertised.
Drop tolerance	Can your customer accept a 15 percent drop, or is that a refund?	Decides whether refill is a nice extra or a hard requirement on every service you buy.
Automation need	Manual ordering, mass order, or full API?	An API you will not use for six months should not outrank support quality today.
Currency and payment	What do you deposit in, and through which rail?	FX spread and deposit rails are real costs, and a crypto-only provider concentrates your risk.
Failure blast radius	If this provider goes dark tomorrow, how many customers are affected?	Sets your maximum acceptable balance and whether you need a second source from day one.

Then convert the answers into three or four disqualifiers: conditions that remove a provider regardless of how good everything else looks. Running a reseller book, mine were no working API, no refill flag on follower services, crypto-only deposits, and no way to reach a human inside a business day. Four disqualifiers removed roughly two thirds of every list I was ever handed. Keep them few and absolute; write twelve and you have a wish list, not a filter.

The sheet also settles an argument you would otherwise have with yourself for months: whether you are buying as a reseller or as an end user. Those are different products with different priorities, and the reseller version always weights API, refill and support far above raw catalog size. The ground rules are laid out in the guide to starting an SMM reseller business from scratch.

How to build a shortlist of SMM providers worth testing

A shortlist is five to seven candidates gathered from sources with different biases, then cut to three before you spend anything. The goal is not to find the best provider on earth. It is to find three plausible enough to be worth two weeks of testing.

1. Operator communities and forums. The most useful source, because complaints are specific and dated. Read the complaint threads, not the recommendation threads. A recommendation says somebody had a good week; a complaint says what the failure mode is and how long it took to resolve.
2. Panels that publish their own mechanics. A provider documenting rate limits as a number, naming its error strings and stating its refill window in hours has told you it expects to be measured. Marketing copy without a single number means there is nothing to measure.
3. Competitor delivery behavior. Order a small package from a competitor in your niche and watch the pattern. Start time, completion curve and drop shape are fingerprints, and you will often recognize the same upstream behind several storefronts.
4. Directories and "top 10" lists. A source of names only. Ranking positions here are frequently paid placements and review counts are not verifiable. Take the names, discard the ordering.
5. The provider's own reseller tooling. A panel with a documented API, a child panel program and a mass order tool is at least built for resellers. That does not make it good, but a consumer-only panel will not survive your second month.

Cut the list with a fifteen minute desk check before any money moves. Look for five things: a catalog you can browse without registering, a published API document, legal pages describing this actual product rather than a generic template, at least one non-crypto deposit rail, and a support channel with a stated response expectation. A candidate failing two of those five does not earn a test slot.

At Panel Follows that check is deliberately easy to run: the full service catalog is browsable before you register, the account is free with no reseller package and no minimum volume, and the API document states rate limits as numbers rather than adjectives. That is not a claim about quality. It is a claim about being checkable, which is all a desk check can establish.

One caution about review pages, ours included. An aggregate star rating is only as trustworthy as the mechanism behind it. Ask whether reviews are tied to real orders, whether the panel separates seeded sample content from customer submissions, and whether negative reviews appear at all. A page of 400 five star reviews with no complaints is evidence of moderation, not of quality, so read what customers actually wrote rather than the number at the top.

The SMM provider scorecard: 36 criteria in 9 weighted groups

A scorecard exists to stop you being persuaded by the loudest signal. Price is loud. Catalog size is loud. Refill behavior and post-sale response times are quiet, and they decide whether you still have customers in six months.

Score each criterion 0 to 3, where 0 means absent or broken, 1 means present but unreliable, 2 means works as described, and 3 means works better than expected under pressure. A group score is the average of its four criteria divided by 3, multiplied by the group weight. Add the nine group scores for a total out of 100. The weights below suit a reseller or agency with real customers. Adjust them before you test, never after you see a result you like.

#	Group	Weight	What this group predicts
1	Delivery quality and consistency	18	Whether you can promise a delivery window and keep it
2	Reliability under load	12	Whether your busiest day is your worst day
3	Refill, cancel and remediation	14	What a failed order costs you in cash and in trust
4	Catalog fit and depth	10	Whether you can serve your book without a second provider
5	API completeness	12	Whether you automate or hire
6	Pricing transparency	10	Whether your margin is real or a rounding error
7	Payment and cash flow risk	10	How much of your money is exposed and for how long
8	Support responsiveness	9	How long a customer waits while you wait
9	Business signals and exit risk	5	Whether you can leave without losing your book

Every one of the 36 criteria below is observable during a two week trial. Nothing here requires you to trust a statement.

Group	Criterion	Score 3 looks like	Score 0 looks like
Delivery	1. Median start time on your top service	Under the advertised window on 9 of 10 test orders	Orders sitting at Pending for a day with no note
Delivery	2. Completion time versus the advertised average	Within 25 percent of the stated average	Advertised "0 to 1 hour," observed 3 days
Delivery	3. Delivered quantity versus ordered quantity	Delivered equals ordered, or overdelivers slightly	Silent underdelivery marked Completed
Delivery	4. Retention at day 7 and day 14	Drop inside the range the description states	40 percent gone by day 7 on a service sold as stable
Load	5. Behavior on 20 orders in 60 seconds	All accepted, all tracked, no duplicate charges	Some orders vanish, balance debited anyway
Load	6. Status accuracy against the real count	Completed matches the platform-visible count	Completed with the count unchanged
Load	7. Stuck order rate across the trial	Zero or one, resolved without you chasing	Several, all needing a ticket
Load	8. Incident handling on a broken service	Service disabled or marked while it is broken	Broken service still sellable and still charging
Remediation	9. Refill is an operation, not a favor	The request goes through without approval	Refill only by ticket, answered when convenient
Remediation	10. Refill actually restores the count	Count recovers within the stated window	Refill accepted, nothing arrives
Remediation	11. Cancel availability marked per service	A per-service flag you can read before ordering	No flag, and cancel is a negotiation
Remediation	12. Automatic refund on cancel and partial	Unused amount returns to balance without asking	Partial delivery, full charge, no adjustment
Catalog	13. Depth on your primary platform	Multiple viable options per service family	One option, permanently out of stock
Catalog	14. Honest service descriptions	Limits, speed and refill window stated	Names that are only adjectives in brackets
Catalog	15. Dead stock ratio	Services you test actually start	A third of the catalog never starts
Catalog	16. Catalog maintenance	Additions and removals visible between snapshots	Identical catalog for a year, dead entries included
API	17. All seven actions present and working	services, add, status, balance, refill, refill_status, cancel	Only add and status, everything else manual
API	18. Rate limit published as a number	"240 requests per minute per key"	"Please do not abuse the API"
API	19. Error payloads that name a cause	Distinct strings you can branch on	One generic error for every failure
API	20. Service flags exposed on the services response	refill, cancel and dripfeed as booleans per service	Flags visible only in the web interface
Pricing	21. List price is the price you pay	No hidden reseller tier behind a sales call	"Contact us for reseller pricing"
Pricing	22. Flat packages distinguished from per 1,000 rates	A max of 1 you can detect programmatically	Package prices mixed in with no marker
Pricing	23. Price change cadence disclosed	Stated sync frequency, changes visible in snapshots	Prices change silently mid-order
Pricing	24. Charge matches the rate at order time	The charge equals rate times quantity	Charges that reconcile with no published rate
Payments	25. More than one deposit rail	Card, bank transfer and crypto all available	Crypto only
Payments	26. At least one traceable rail	Card or bank transfer with a real merchant record	A personal wallet address in a chat message
Payments	27. Deposits post without manual intervention	Balance updates automatically after confirmation	"Send the receipt to support and wait"
Payments	28. Refunds land as balance and appear in the ledger	A line item with the order reference	Refund promised verbally, never visible
Support	29. First response time on a real problem	Inside a few hours, at any hour	Days, or never
Support	30. Answer quality names the order and the cause	"Order 4412 stalled upstream, resent at 14:20"	"Please wait, it will be delivered"
Support	31. Post-sale time matches pre-sale time	Same responsiveness after your deposit	4 minutes pre-sale, 4 days post-sale
Support	32. A working escalation path	A second answer when the first was wrong	The same copy-paste reply three times
Business	33. Legal pages describe this actual product	Terms discussing drops, refills and refunds	A template mentioning shipping addresses
Business	34. A checkable contact route	A ticket system with history you can read back	A contact form that goes nowhere
Business	35. Reseller infrastructure exists	API, mass order and a child panel program	Consumer checkout only
Business	36. Data portability	You can export your order history	No export, no order list beyond 30 days

Interpreting the total matters as much as computing it. A provider scoring 74 with a zero on criterion 9 is worse than one scoring 66 with no zeros, because remediation failures compound. Apply two rules: any group scoring below 40 percent of its weight is a veto, and any single 0 in groups 1, 3 or 7 is a veto. Then rank the survivors by total.

Bands that work in practice: 80 and up means commit and scale; 65 to 79 means commit with a capped balance and a warm second source; 50 to 64 means keep as a backup for one service family; below 50 means walk away no matter how cheap the rate is.

How to read a provider catalog before you spend anything

A catalog is a claim about capacity, and claims are free. Reading one properly is the cheapest filter you have, because it costs nothing and it eliminates candidates before they eliminate your money.

Start by counting differently than the marketing does. A panel advertising 3,500+ services is not offering you 3,500 useful options. Filter to your primary platform and service family and the number usually collapses by 95 percent. What matters is the count that survives that filter, and whether the survivors differ in ways you can explain to a customer.

Six things to look for, in order of how much they tell you:

1. Do descriptions state limits? A service naming its start time, speed per day, refill window and known restrictions was written by somebody who fulfills it. A service called "Instagram Followers [REAL] [SUPER FAST] [BEST QUALITY]" was written by somebody copying a list.
2. Are flags per service rather than per panel? Refill, cancel and drip feed genuinely differ per service. A panel claiming "refill on everything" is either lying or has never had to honor it.
3. Do minimum and maximum ranges make sense? A follower service with min 10 and max 500,000 is either an aggregated route across several upstreams or a copied row. Both are worth knowing before you sell the top of that range.
4. Is there a flat-priced package trap? Package services often carry a maximum of 1, which means the listed rate is the price of the whole package, not a rate per 1,000 units. Misreading that is the most expensive integration bug in this industry.
5. Does the catalog change? Snapshot it on day 1 and day 13. Additions, removals and rate movements prove somebody is maintaining it. A byte-identical catalog two weeks apart means nobody is watching.
6. Are dead entries removed? Order the smallest possible quantity on three services that look suspicious. If they never start and they are still listed a week later, the catalog is a menu rather than an inventory.

The catalog also shows whether the provider understands its own product. Panel Follows publishes 3,500+ services across 500+ categories covering Instagram, TikTok, YouTube, Telegram, Twitter/X and Facebook, and exposes refill, cancel and drip feed as per-service booleans on the API services response rather than as a site-wide promise. Whether that catalog suits you depends entirely on the requirement sheet you wrote first.

One catalog signal people miss: rate movement. Prices track upstream cost, so a provider syncing on a schedule shows small movements between snapshots. Panel Follows runs that sync hourly, which keeps service IDs stable while rates are not. That is a feature for accuracy and a hazard for anybody caching a rate and quoting from it a week later, and the money side of it is worked through in the piece on wholesale SMM provider pricing.

The 14 day test protocol for a new SMM provider, day by day

Fourteen days is the shortest window that lets you observe delivery, a real drop, a refill and a support cycle on the same orders. Anything shorter tests the sales process. Anything longer delays a decision you can already make.

The protocol costs little: twenty to forty test orders at minimum quantity typically lands between 15 and 40 USD depending on your platforms. Compare that to discovering a broken refill flow after you have moved a month of customer orders through it.

Day	What you do	What you record	What it proves
1	Register, read terms and refund policy, deposit the minimum, snapshot the catalog	Deposit rail, time from payment to balance, catalog file hash	Onboarding friction, whether deposits post automatically
2	Order 1: minimum quantity on your top-selling service	Order ID, timestamp, start count, quoted rate, charge	The baseline every later measurement compares against
3	Orders 2 to 5: four different service families, minimum quantity each	Same fields, plus status transitions each hour for 6 hours	Whether behavior is consistent or only good on the demo service
4	Failure injection A: order with a deliberately invalid link	Error string, whether balance was debited, time to refund	Whether input validation exists and refunds are automatic
5	Failure injection B: order the same service and link twice while the first runs	Whether the second is blocked, cancelled or silently accepted	Duplicate handling, a real cost center at volume
6	Open a support ticket about a genuine ambiguity in a service description	Time to first response, whether the reply names your order	Post-deposit support quality, which is the number that matters
7	Retention check on order 1 and orders 2 to 5	Current count versus delivered count, as a percentage	Real drop rate, not the advertised one
8	First API calls: balance, services, one add	Response shape, key handling, whether flags are per service	Whether the API is real or a marketing bullet
9	Batched status poll on all open orders, then a deliberate rate limit probe	Response time, exact 429 behavior, recovery	Whether you can run a poller inside the published budget
10	Load burst: 20 minimum orders inside 60 seconds	Acceptance rate, duplicate charges, order tracking	Behavior on your busiest future day
11	Cancel test on a service where the cancel flag is true, and one where it is false	Result of each, refund timing and amount	Whether the flags are honest
12	Refill test on whichever order dropped most, if it carries the refill flag	Refill ID, time to recovery, amount recovered	The single most valuable data point in the trial
13	Second catalog snapshot, diff against day 1	Services added, removed, rates changed, direction	Whether the catalog is maintained and how prices move
14	Score the scorecard, write the decision down	Total, group scores, vetoes, decision and reason	A record you can re-read in three months

Run this on all three shortlisted providers at the same time, not sequentially. Parallel testing removes the biggest confound in this market: platform-wide events. If Instagram runs a cleanup sweep in week two, sequential testing blames whichever provider you happened to be testing that week, while parallel testing shows all three dropping together, which is information rather than noise.

Keep the log in a spreadsheet, one row per order. The columns that matter: provider, service ID, service name, ordered quantity, rate at order time, charge, order timestamp, start count, first status change, completion timestamp, delivered quantity, count at day 7, count at day 14, refill requested, refill result, notes. Fifteen columns and twenty to forty rows per provider. That sheet is worth more than every review page you will read this year, and three months later it tells you whether the provider you chose has degraded.

One note on quantity. Test at the minimum, but place at least two orders at a realistic customer quantity on your most important service. Some capacity problems only appear above a threshold, and a service that delivers 100 followers in twelve minutes and 5,000 in nine days is one you would have described to a customer entirely wrongly.

Measuring delivery: start time, the completion curve and retention

Delivery quality is three separate measurements, and providers are usually good at one and quiet about the other two. Measure all three or you are measuring marketing.

Start time is the interval between placing the order and the first observable change in the count, recorded in minutes. Advertised start times are best cases; the useful figures are your median across ten orders and your worst case. A service with a median start of 8 minutes and a worst case of 26 hours is not "instant," it is usually fast. Quote the worst case to customers and you will never have an angry one.

The completion curve is the shape of delivery over time, and almost nobody measures it. Two services can both finish 1,000 followers in six hours: one delivers in a smooth ramp, the other dumps 900 in four minutes and dribbles out the last 100. The second shape looks less natural on the account and tends to correlate with higher early drops. Record the count at 15 minutes, 1 hour, 6 hours and at completion and you have the curve.

Retention is the count at day 7 and day 14 as a percentage of the delivered count. It decides your actual cost per delivered result, and you cannot see it on a price list.

Measurement	How to take it	Good result	Warning sign
Start time (median of 10)	Minutes from order placed to first count change	Inside the stated window on most orders	Median fine, worst case 20x the median
Start time (worst case)	The slowest of your 10 orders	Under 2x the stated window	Any order still Pending after 24 hours with no note
Completion curve shape	Count at 15 min, 1 h, 6 h, completion	Gradual, roughly proportional to elapsed time	90 percent in the first minutes, then a long tail
Delivered versus ordered	Final delivered divided by ordered	100 percent or a small overdelivery	Marked Completed at 92 percent with no partial refund
Retention day 7	Count at day 7 divided by delivered	Within the range the description states	Large loss on a service sold as stable, with no refill flag
Retention day 14	Count at day 14 divided by delivered	Curve flattening rather than continuing down	Still falling at the same rate, which means it keeps falling
Cost per retained unit	Rate divided by retention percentage	Compare across providers, not within one	A cheap rate whose retained cost is the highest on your list

Do the retention arithmetic explicitly, because the ranking changes. Test three follower services at 1,000 units each:

• Provider A: rate 0.75 USD per 1,000, delivered 1,000, day 14 count 620. Retained cost = 0.75 / 0.62 = 1.21 USD per 1,000 retained.
• Provider B: rate 1.05 USD per 1,000, delivered 1,000, day 14 count 910. Retained cost = 1.05 / 0.91 = 1.15 USD per 1,000 retained.
• Provider C: rate 0.62 USD per 1,000, delivered 940, day 14 count 470. Retained cost = 0.62 / (0.94 x 0.50) = 1.32 USD per 1,000 retained.

On the shelf, C is 17 percent cheaper than A and 41 percent cheaper than B. After fourteen days it is the most expensive of the three, and it is also the one generating refund requests. That arithmetic is the strongest argument for running a test instead of comparing price lists. Why counts fall in the first place, and what a refill window actually covers, is explained separately in the piece on why followers drop and how refills work.

An honest caveat: a two week window measures early drop, which is the drop most correlated with service quality. It says nothing about a platform-wide cleanup three months later, and nothing you can do in a trial will. Treat retention as a comparative measure between candidates tested in the same period, not as a prediction of an absolute number.

Breaking things on purpose: how a provider handles a failure it did not expect

Every provider looks good when nothing goes wrong. The information you need is in the failure path, and the only reliable way to see it is to cause a failure deliberately, early, while the money at stake is a few dollars.

1. The invalid link. Order with a link that is malformed, points to a private account, or points to a post that does not exist. Best result: rejection at submission naming the reason. Acceptable: acceptance followed by automatic cancellation and refund to balance within a day. Bad: a charge, a Completed status, and nothing delivered.

2. The duplicate order. Place the same service and link twice while the first is running. Upstream systems often lock a link during processing, so what matters is whether the unwind is automatic. At Panel Follows the in-panel duplicate block does not apply to API orders, and the upstream lock is stricter than the panel rule because it locks the link regardless of which service you ordered. When it fires, the order is cancelled and the balance refunded automatically. Knowing that in advance is better than discovering it at volume, and it is why any serious integration guards duplicates on its own side.

3. The unsupported operation. Request a refill where the refill flag is false, or a cancel where the cancel flag is false. Correct behavior is a clear error naming the reason and no charge. A provider that accepts the request and goes quiet has decorative flags, which means you cannot build a customer-facing promise on them.

4. The stalled order. You cannot inject this one, but across twenty to forty test orders you will usually get one. Note the exact moment you noticed and the exact moment somebody acknowledged it. That interval is the most predictive single number in the whole trial, because it is the interval your customer spends waiting while you have nothing to tell them.

Score the recovery, not the failure. Failures happen at every provider and every tier. What separates them is whether the failure is visible in the order record, whether the money comes back without you asking, and whether a human can say what happened. A provider that fails cleanly and refunds automatically is operationally safer than one that fails rarely and handles it badly, because you can build a process around the first.

Testing refill and cancel on a real drop

Refill and cancel convert a bad outcome into a recoverable one. Both are routinely advertised and rarely tested before the money moves, so test them in the trial, on real orders, with real drops.

A refill restores a count that has fallen after delivery, on services carrying the refill flag, within a stated window. That is the entire promise. It is not a guarantee against drops, and services without the flag carry no drop coverage at all, which means a drop there is simply a loss with no refund attached. Anybody selling "non drop guaranteed" is selling a phrase with no mechanism behind it.

On day 7, find the test order with the largest percentage drop that also carries the refill flag, request the refill, and record four things: whether the request went through without a support ticket, the refill identifier if one came back, how long until the count started moving, and how much of the gap closed. Anything short of "accepted immediately and recovered most of the gap inside the stated window" is a partial pass at best.

The structural question is whether refill is an operation or a favor. At Panel Follows a refill request goes straight to the provider with no admin approval, from the panel and from the API alike, with a 24 hour cooldown between refill requests on the same order. Note that cooldown during a trial, because a second request inside 24 hours will be rejected and you will misread the rejection as a broken flow.

A cancel stops an incomplete order and returns the unused amount. It is not universal and should never be advertised as universal, because it depends on what the fulfilling side supports for that specific service. The honest implementation is a per-service flag you can read before you order. At Panel Follows cancel is a per-service boolean on the services response, and where it is true the cancel goes straight through, with cancelled and partial orders refunded to balance automatically. Manual services fall back to admin approval, which is slower and should be planned around as a different product.

Test	How to run it	Pass	Fail
Refill on a flagged service	Request refill on the biggest day-7 drop	Accepted without a ticket, count recovers inside the window	Ticket required, or accepted and nothing happens
Refill cooldown behavior	Request a second refill on the same order immediately	Clear rejection naming the cooldown	Silent acceptance that does nothing
Refill on an unflagged service	Request refill where the flag is false	Clear error, no charge	Accepted, then silence
Cancel on a flagged service	Cancel a running order where cancel is true	Order cancelled, unused amount back in balance	Cancel accepted, no refund line in the ledger
Cancel on an unflagged service	Cancel where the flag is false	Clear error naming the restriction	Vague failure with no explanation
Partial delivery handling	Find an order that ends Partial	Charge adjusted or difference refunded automatically	Full charge for partial delivery

Run all six, because they fail independently. I have seen a panel with a working refill flow and no automatic partial refund, and a panel with flawless refunds and a refill button that opened a ticket. Neither would have shown up on a review page, and both changed the real cost of doing business by a visible margin.

Testing the SMM provider API before you trust it with your order book

The API test answers one question: can this provider carry your automation without you writing defensive code around its unpredictability. Run it even if you will not automate for months, because API quality is the cheapest available proxy for engineering discipline.

Most reseller APIs share a shape: a single endpoint, a form-encoded POST, an action parameter, JSON responses, and a key that travels in the request body. Panel Follows follows that shape at POST https://panelfollows.com/api/v2, with a Turkish variant at /api/v2/tr returning service names, category names, statuses and error messages in Turkish on the same key. Because the shape is common, most panel software connects by changing a base URL and a key, which means the API test tells you about the operator rather than about the protocol.

Start with the smallest possible call and confirm the envelope:

curl -s -X POST https://panelfollows.com/api/v2 \
  -d "key=YOUR_64_CHAR_HEX_KEY" \
  -d "action=balance"

Then pull the catalog and inspect what the services response exposes per service:

curl -s -X POST https://panelfollows.com/api/v2 \
  -d "key=YOUR_64_CHAR_HEX_KEY" \
  -d "action=services"

The fields to check for are service, name, type, category, rate, min, max, refill, cancel and dripfeed. The last three drive your customer-facing promises, and a provider that does not expose them per service is asking you to guess.

Seven things to verify, each mapping to a scorecard criterion:

1. All seven actions respond. services, add, status, balance, refill, refill_status, cancel. A provider offering only add and status is offering an order form with extra steps.
2. The rate limit is a published number and the 429 is well behaved. Panel Follows publishes 240 requests per minute per key and 300 per minute per IP, returning HTTP 429 with an error payload beyond either. Probe it once deliberately, watch the recovery, and build your poller inside the budget rather than against it.
3. Errors arrive in the same envelope with an error key. A response like { "error": "Incorrect data" } is parseable. A 200 with an HTML error page is not, and it is the most common cause of an integration that silently stops placing orders.
4. Batched status polling works. A comma separated orders list on status is the correct pattern, and batches of 50 to 100 IDs keep a large order book in sync inside the rate limit.
5. Specialized types take the extra parameters they should. Branch on the type field from services: custom comments take comments, comment likes and mention variants take username, poll services take answer_number, group invites take groups, SEO services take keywords, subscriptions take username, posts, min and max. A provider listing these types but ignoring the extra fields cannot fulfill them.
6. Drip feed arithmetic is documented. With runs and interval, the quantity becomes per run rather than the total. A provider that does not say so in writing will produce an invoice ten times the size you expected, and the mistake will be yours.
7. Key rotation actually invalidates. Regenerate the key and confirm the old one stops working immediately. A key that keeps working after rotation is a security problem you inherit.

Batched status polling is the call a real poller lives on, so test the batch form rather than the single order lookup:

curl -s -X POST https://panelfollows.com/api/v2 \
  -d "key=YOUR_64_CHAR_HEX_KEY" \
  -d "action=status" \
  -d "orders=23501,23502,23503,23504,23505"

Two API observations carry disproportionate weight. The first is whether the charge returned on status reconciles with the rate you saw at order time, because charges that do not reconcile erode margin invisibly. The second is whether flat-priced package services are identifiable programmatically: a service with a maximum of 1 is priced as a whole package rather than per 1,000 units, and an integration applying the universal per 1,000 formula to it will sell a 22 USD package for around 3 cents. That bug is the classic one in this industry, and catching it during a trial is far cheaper than catching it during a quarter.

The engineering side of all of this, including the order state machine, error taxonomy, polling budgets and a multi provider abstraction layer, is worked through in the companion piece on SMM provider API integration. The endpoint reference itself, with the limits stated as numbers, is in the public reseller API documentation.

Pricing transparency and the price questions that expose a middle tier

Price transparency is not about being cheap. It is about whether you can predict what an order costs, reconcile what you were charged, and know that the number on the shelf is the number you pay. A mid-priced transparent provider is a better partner than a cheap opaque one.

Four questions separate them, and all four have observable answers.

Is the list price the price a reseller pays? Some panels run a public price and a separate reseller price behind a sales conversation, a volume commitment or a membership fee. That is a legitimate model, but it changes your arithmetic and means the shelf price tells you nothing. Panel Follows does not run a separate tier: the list price is the reseller price, the account is free, and there is no reseller package, no membership fee and no minimum volume, with API access, mass order, child panel, subscriptions and drip feed all on an ordinary account. Whatever your provider's model is, establish it before you build a price list on top of it.

How often do rates move, and are you told? Rates track upstream cost. A provider syncing hourly shows visible movement between your day 1 and day 13 snapshots. Zero movement over two weeks means either no sync or no catalog maintenance, and the second is worse. The practical consequence is quote validity: if rates move hourly, a quote you gave four days ago is a guess, and you need buffer in your markup rather than a fixed spread.

Are flat-priced packages marked? A service with a maximum of 1 is a package priced as a whole, not a per 1,000 rate. If the catalog does not let you distinguish those programmatically, your integration mispriced them and your margin on those lines is negative.

Does the charge reconcile? Check ten test orders against rate times quantity divided by 1,000, handling flat packages separately. Ten out of ten is the pass. Eight out of ten is a flag to chase before you scale, because the two that did not reconcile will become two hundred.

Price archaeology exposes a middle tier without anybody admitting anything. Take one commoditized service, for example a standard Instagram followers service in the widely available quality band, collect the rate from each candidate, and compare the spread.

Candidate	Rate per 1,000	Position versus the cheapest	What the spread suggests
A	0.62 USD	Baseline	At or near the floor for this service band
B	0.81 USD	+31 percent	Plausibly one hop away, or the same source with better support attached
C	1.44 USD	+132 percent	Either two hops away, or a genuinely different quality band
D	0.29 USD	-53 percent	Below the observable floor, which usually means the delivery is not what the description says

The spread is evidence, not proof, and it has to be read alongside your delivery test. A provider 30 percent above the floor with excellent refill behavior and an hour response time is often the cheapest option once you compute retained cost and support minutes. A provider far below the floor deserves the hardest look: capacity is not free, and a rate below what capacity costs is usually funded by underdelivery, by a service that is not what the name says, or by the balances of customers who will not get their money back.

Do the archaeology on three services, not one, and pick services that exist everywhere. Comparing an unusual specialized service across panels tells you nothing, because you are comparing different products with the same name.

Prepaid balance risk: sizing your first deposit and staging exposure

Almost every SMM provider runs a prepaid balance, which means you carry counterparty risk from deposit until spend. This is the risk that actually destroys reseller businesses, and it is entirely manageable with a staging rule.

The rule: never hold more balance than you can absorb losing, and raise the ceiling only after observed months, not after good feelings.

Stage	Duration	Max balance held	What must be true to advance	Typical order volume
0. Desk check	1 day	0 USD	Passes the five point pre-deposit check	None
1. Trial	14 days	Minimum deposit only, roughly 10 to 40 USD	Scorecard total at or above 65, no vetoes	20 to 40 test orders
2. Live pilot	30 days	One week of expected order cost	Refill and cancel both observed working on real orders	Real customer orders on one service family
3. Primary	60 days	Two weeks of expected order cost	Support response times held after the trial ended	Most of your book
4. Scaled	Ongoing	Two to four weeks of expected order cost, capped	Two clean monthly reviews and a warm second source	Full book with failover

Two details make the ladder work. The first is that you top up more often instead of holding more. Depositing 200 USD every four days is slightly more effort than depositing 800 USD once and caps your exposure at a quarter of the size. If deposits are free, there is no reason to hold a large balance except convenience, and convenience is a bad reason to carry a four figure unsecured position with a counterparty you met last month.

The second is that deposit rail choice is a risk decision, not a convenience decision. A card deposit leaves a merchant record and, depending on issuer and jurisdiction, a dispute path. A bank transfer leaves a traceable record. A crypto transfer leaves neither, so a provider accepting only crypto has removed every recovery route you have. That is why crypto-only is a hard disqualifier on my requirement sheet.

Worked example. Suppose your book runs 900 USD of provider cost per month, roughly 30 USD per day. At stage 3, two weeks of order cost is about 420 USD. If the provider disappears on your worst day you lose that 420 USD plus whatever is in flight, and you still owe delivery or refunds on customer orders already paid for, which at a 60 percent markup is roughly 670 USD of obligations. Write that number down before you deposit; it tells you whether you need a second source now rather than later.

One exposure people forget: orders in flight are exposure too. An order placed but not delivered is money already spent with no result, and a busy reseller always has a day or two of order value sitting in Processing. Add it to your balance when you compute what a provider failure would cost.

SMM provider red flags and what each one usually means

Red flags are not proof of fraud. They are patterns correlated with specific failure modes, and each has a confirmation test that takes minutes. Treat the table as hypotheses to check, not verdicts.

Red flag	What it usually means	How to confirm in under 10 minutes	Severity
Crypto is the only deposit rail	No merchant relationship, no dispute path, often no legal entity	Check the deposit page for a card or bank option	Disqualifying
Payment to a personal wallet or personal bank account	Money is going to an individual, not a business	Read the payment instructions	Disqualifying
Prices far below the observable floor on commodity services	Underdelivery, a different quality band than the name implies, or balances funding delivery	Price archaeology across three candidates, then a minimum test order	High
Support answers in 4 minutes pre-sale and 4 days post-sale	Sales and support are the same overloaded person and you are no longer the priority	Compare a pre-deposit question to a post-deposit ticket	High
Refill and cancel promised site-wide rather than per service	The flags are marketing rather than mechanics	Check whether the API services response exposes them per service	High
"Non drop guaranteed" or "100 percent real followers"	A promise with no mechanism, on a product where drops are structural	Ask what happens if it drops on day 20 and read the answer	High
Catalog byte-identical between snapshots two weeks apart	Nobody is maintaining it, and dead services stay sellable	Diff your day 1 and day 13 snapshots	Medium
Service names that are all adjectives and no numbers	The catalog was copied from an upstream with no operational knowledge behind it	Read ten descriptions and look for stated limits	Medium
Advertised service count that collapses under filtering	The headline number counts near-duplicate rows	Filter to your platform and family and count what remains	Medium
No published rate limit and no error string documentation	Either no API discipline, or nothing to be disciplined about	Read the API document for a single number	Medium
Review page with hundreds of five star reviews and no complaints	Moderation, seeding, or both	Look for a mechanism tying reviews to orders	Medium
Terms of service that mention shipping addresses or physical goods	A generic template, so nothing in it was written about this product	Read the refund section specifically	Medium
Order statuses that jump straight from Pending to Completed	No real status pipeline, so you cannot see a stall until the customer does	Watch an order through its transitions	Medium
Balance top-ups requiring a support ticket to appear	Manual bookkeeping, which does not scale and often precedes cash flow trouble	Deposit the minimum and time it	Medium
A support channel that exists only on a messaging app	No ticket history, so nothing is auditable and nothing escalates	Look for an in-panel ticket system	Medium
No order history export	You cannot reconcile, and you cannot leave with your data	Look for an export in the dashboard	Low but revealing

The most dangerous pattern is a combination rather than a single flag: cheap, crypto-only, and dramatically more responsive before your deposit than after it. Each is survivable alone. Together they describe the panel that takes balances and stops answering, which is the fraud this industry produces most reliably. If a candidate shows all three, no test protocol is worth running.

Two flags people over-weight, for balance. A plain-looking website means nothing; some of the most operationally solid panels look like they were built in 2016, because engineering effort went into the order pipeline instead of the landing page. And a small catalog is not a red flag at all: 400 services somebody actually maintains beat 6,000 rows nobody has tested.

Questions to ask an SMM provider before your first deposit

Ask these in writing, through the channel you will actually use for support later, so that response time is part of the answer. A provider who answers precisely pre-sale and vanishes post-sale has told you something. A provider who cannot answer precisely at all has told you more.

Question	The answer a good provider gives	The answer that should worry you
What exactly does your refill cover, and for how long?	A window in days, per service, tied to a flag you can read before ordering	"All our services are non drop"
What happens if a service drops on day 20 with no refill flag?	An honest "nothing, that service carries no drop coverage, here is one that does"	A promise to "take care of it" with no mechanism
Which services support cancel, and how do I know before I order?	A per-service flag exposed in the catalog and the API	"Just message us and we will see"
Is the list price what I pay, or is there a reseller tier?	A direct yes or no, with any tier conditions stated in numbers	"Contact sales for reseller pricing" with no numbers
How often do rates change, and will my open orders reprice?	A stated sync cadence and a clear statement that the charge is fixed at order time	Silence, or "prices are stable" in a market where they are not
What are your API rate limits?	Numbers, per key and per IP, and the behavior when you exceed them	"We do not have limits" or "please do not abuse it"
How do I identify package services priced as a whole rather than per 1,000?	A field you can branch on programmatically	A suggestion to read the names and be careful
What is your first response time on a ticket, at 3am on a Sunday?	A stated expectation and an honest note about slower windows	A guaranteed number no support desk could hold
What happens to my balance if I stop using the panel?	A clear policy, whatever it is, stated the same way twice	An answer that changes when you ask again
Can I export my order history?	Yes, with a route to do it	"Why would you need that?"
Who fulfills these orders, and how many parties sit between you and delivery?	An honest description of their position and their routing	A claim to own every source on earth, or a refusal to discuss it
What happens when upstream capacity fails on a service you sell?	The service is disabled or flagged, and running orders are refunded or cancelled	"That does not happen"

Two of these are diagnostic rather than informative.

The refill question is diagnostic because the honest answer is unattractive. Anybody willing to say "that service carries no coverage, drops on it are your loss, buy this other one instead" is saying something that costs them a sale, which is the strongest available evidence that the rest of what they say is true. A refill window covers drops inside the window on services carrying the flag, and no guarantee means no refund for drops. A provider that will not say that plainly will be difficult on the day you need it.

The fulfillment question is diagnostic because of what a good answer does not contain. Panels claiming to personally own bot farms, device networks or exclusive contracts are making unverifiable claims, and unverifiable claims are what you get instead of a real answer. The credible version is narrower and checkable: this is the tier we sit at, this is what we run ourselves, this is what we route and how we vet it, and here is what happens when a route fails. Panel Follows describes its own position that way on the reseller panel page, and the useful part of any such description is the failure handling, not the boast.

What a good SMM provider is allowed to be bad at

Demanding perfection selects for liars. This is the section most vetting guides refuse to write, and it is the one that stops you rejecting the best option on your list for the wrong reason.

Nobody is excellent at everything, because the tradeoffs are real. Breadth costs depth. Cheap costs support headcount. Instant delivery costs retention. A provider claiming to be simultaneously the cheapest, the fastest, the highest quality and the most responsive is describing a business that cannot exist, and the claim itself is the disqualifying signal.

Things a genuinely good provider is allowed to be bad at:

• Occasional stalls. Upstream capacity fluctuates. A stall is not a failure unless it goes unnoticed and unexplained. Judge the recovery.
• An imperfect catalog. Some services will be duds. What matters is whether duds get removed when reported, and whether the provider says a service is having a bad week instead of selling it to you anyway.
• Slower response at unusual hours. A desk staffed around the clock still has a thin window somewhere. An honest stated expectation beats a guaranteed number nobody holds.
• Prices that are not the lowest on your list. If retained cost and support load are better, the higher rate is the cheaper option.
• A plain interface. Interface polish and pipeline reliability come from the same budget. Take the pipeline.
• Not supporting every specialized service type. "We do not do that one well" is more useful than listing it and failing silently.
• Refusing an unreasonable request. A provider declining to cancel a completed order, or to refill a service with no refill flag, is applying its own stated rules. That consistency is what protects you when a customer pushes on you.

Things a good provider is never allowed to be bad at:

1. Returning money that is owed, automatically, without you asking twice.
2. Telling you the truth about what a service does and does not cover.
3. Making failures visible in the order record rather than hiding them behind a Completed status.
4. Answering when something is genuinely broken.
5. Keeping your balance safe and your ledger accurate.

That second list is short on purpose. It is the whole of what a counterparty relationship requires, and everything else is a preference. Score preferences with weights; treat those five as vetoes.

The corollary applies to Panel Follows as much as to anyone else. Sitting at the provider tier does not remove risk from the chain. It shortens the chain and makes failure visible faster. Drop risk stays real, purchased engagement is still not an audience, and a shorter chain with an honest failure path is the actual product. Any provider describing itself in stronger terms is describing something the market cannot deliver.

After you commit: monthly monitoring, a second source and an exit plan

Choosing a provider is the beginning of the relationship, not the end of the evaluation. Providers degrade: upstream routes change, capacity gets resold, a support team of three becomes one. Your trial measurements are a baseline, and their value is that they let you notice when things have changed.

Run a short monthly review. It takes about forty minutes if the trial spreadsheet still exists, which is the real reason to keep it.

Metric	How you measure it	Healthy	Action threshold
Median start time, top 3 services	Sample 10 recent orders per service	Within 25 percent of your baseline	50 percent worse than baseline for two months
Stall rate	Orders needing manual intervention divided by total orders	Under 2 percent	Above 5 percent, or any month that doubles
Day 14 retention, top service	Sample 5 orders placed 14 days ago	Within 10 points of baseline	Down 15 points or more
Refill success rate	Refills that recovered the count divided by refills requested	Above 80 percent	Below 60 percent
Support first response, post-sale	Median across your own tickets that month	Within your stated customer promise	Any month where the median doubles
Charge reconciliation	Sample 20 orders, compare charge to rate times quantity	20 of 20 reconcile	Any unexplained mismatch
Rate drift on your top 10 services	Diff this month's catalog snapshot against last month's	Small movements in both directions	A large one-way move you were not told about
Balance exposure	Peak balance held during the month	Inside your stage ceiling	Any month you exceeded the ceiling for convenience

Keep a second integration warm. Not a provider you might call someday: a real account with a real key that has placed a real order in the last 30 days. The cost is a small balance and one afternoon. The benefit appears on the day your primary has a bad week and your customers do not notice.

Warm failover needs three things in place before you need it:

1. A mapping table. Your internal service identifier mapped to a provider service ID at each provider, with rate, minimum, maximum and flags recorded per side. Without it, switching means re-testing everything under pressure.
2. Portable order data. Your own order records holding the customer, the link, the quantity, the provider used and the provider order ID. If your only order history lives in a provider's dashboard, you cannot leave and you cannot reconcile.
3. A written switch rule. Decide in advance what triggers a switch, in numbers, from the monitoring table above. Decisions made during an incident are decisions made badly.

The exit plan is those three read backwards. You can leave cleanly when you know which services map where, you hold your own order history, and you never carry more balance than a few weeks of orders. You cannot leave cleanly when your book lives in their dashboard and your balance is a month of revenue.

If your end state is your own branded panel rather than a storefront, the same discipline applies with one addition: your customers are now exposed to your provider through you. The white label child panel model makes that concrete, because you connect your own payment accounts and keep your own customer relationships while the base cost of each order settles against your prepaid balance. It is a good structure and it does not change the arithmetic above. It raises the stakes, because a provider failure now hits people who believe they are your customers, which they are.

Frequently asked questions about how to find an SMM provider

How do I find an SMM provider that will not disappear with my balance?

You cannot verify solvency directly, so manage exposure instead of trying to predict it. Three controls do most of the work: never hold more than a couple of weeks of order cost, deposit through a traceable rail such as a card or bank transfer rather than crypto alone, and top up frequently in small amounts. Then watch the operational signals that precede a collapse: deposits that suddenly need a support ticket to appear, refunds that stop landing automatically, and support response times stretching from hours to days. Those three changes together are the reliable early warning, and they usually appear weeks before a site goes quiet.

How much should I deposit with a new SMM provider on the first day?

The minimum the panel allows, and nothing more, for the first fourteen days. That is typically enough for twenty to forty minimum-quantity test orders, which is the whole trial. Raise the ceiling in stages tied to observations rather than time: one week of expected order cost after the trial passes, two weeks after a clean month, and never past two to four weeks even years in. A useful check before every top-up is to ask what you would do if that exact amount vanished tomorrow along with the orders currently in flight. If the answer involves refunding customers you cannot afford to refund, the deposit is too big.

How long should I test an SMM provider before committing real customer orders?

Fourteen days is the practical minimum, because it is the shortest window that lets you observe delivery, a real drop, a refill request and a post-deposit support cycle on the same orders. A seven day test measures the sales process. A thirty day test delays a decision you could already make, unless you sell services with unusually long delivery windows. Run all three shortlisted providers in parallel across the same fourteen days rather than sequentially, so a platform-wide event affects every candidate equally instead of unfairly punishing whichever one you happened to be testing that week.

What is the difference between an SMM provider and an SMM reseller panel?

An SMM provider is whoever you buy from and hold a balance with. An SMM reseller panel is a panel that sells to resellers and gives them the tooling to resell, usually an API, mass order, and often a white label option. The two overlap constantly, because most panels are somebody's provider and somebody else's reseller at the same time. The question worth asking is not which label applies but how many hops sit between your order and whatever fulfills it, since each hop adds cost, latency and one more party who cannot answer why order 4412 is stuck.

Is the cheapest SMM provider ever the right choice?

Sometimes, but only after you compute retained cost rather than shelf price. Divide the rate by retention at day 14 and the ranking often reverses: a service at 0.75 USD per 1,000 retaining 62 percent costs 1.21 USD per 1,000 retained, while one at 1.05 USD retaining 91 percent costs 1.15 USD. Add support minutes, refund rate and the cost of a stalled order in customer trust, and the cheap option frequently loses by a wide margin. A rate far below the observable floor for a commodity service is a warning rather than a bargain, because delivery capacity has a real cost and something has to be funding the gap.

How do I check whether an SMM provider's refill actually works?

Test it on a real drop during the trial, not by asking. On day 7, find the test order with the largest percentage drop that also carries the refill flag, request the refill, and record four things: whether it went through without a support ticket, whether an identifier came back, how long until the count started moving, and how much of the gap closed. Test the negative case too, by requesting a refill where the flag is false, which should return a clear error rather than silence. Note any cooldown before concluding the flow is broken: a 24 hour cooldown between refill requests on the same order is a normal design.

Do I need an API to work with an SMM provider?

Not on day one, but choose as though you will. Under roughly 200 orders a month, manual ordering and a mass order tool are perfectly workable, and support quality matters far more than endpoint coverage. Past 1,000 orders a month, manual handling becomes the constraint and the API becomes the business. The reason to test the API during the trial even if you will not use it for months is that API quality is the cheapest available proxy for engineering discipline: a provider publishing rate limits as numbers, returning parseable errors and exposing refill, cancel and drip feed flags per service is telling you how the rest of the operation is run.

How many SMM providers should I use at once?

One primary and one warm secondary is the right shape for most resellers. Splitting your book evenly across three triples your integration surface, triples your balance exposure and gives you worse visibility into each, because you never accumulate enough orders anywhere to notice a degradation. A warm secondary means a real account with a real key that has placed an order in the last 30 days, plus a service mapping table so you can move a service family across in minutes. Add a genuine third provider only when one service family is consistently better somewhere else, not as a general hedge.

What are the biggest red flags when choosing an SMM provider?

The combination that matters most is cheap, crypto-only deposits, and dramatically faster responses before your deposit than after it. Each is survivable alone; together they describe the panel that takes balances and stops answering. Close behind: refill and cancel promised site-wide instead of per service, prices far below the observable floor on commodity services, a catalog byte-identical two weeks apart, terms of service that mention shipping addresses, and balance top-ups requiring a support ticket to appear. Notably not a red flag: a plain website, or a small catalog that somebody actually maintains.

Can an SMM provider guarantee that followers will not drop?

No, and a provider claiming otherwise is describing something the market cannot deliver. Purchased engagement is not a real audience, it can conflict with the terms of service of the platform it is pointed at, and platforms periodically remove accounts in ways no supplier controls. What a provider can offer is a mechanism: a refill window on services carrying the refill flag, which covers drops inside that window, plus a cancel flag and automatic refunds where an order fails or completes partially. Services without the refill flag carry no drop coverage at all, so a drop there is a loss with no refund attached. Any stronger version of that promise is a sales line rather than a policy.

Conclusion: the process outlives the provider list

The reason to build a process instead of picking from a list is that the list expires and the process does not. Providers change, upstream routes get resold, a support team of three becomes one, and the panel that was excellent in March is mediocre by September. What survives is a requirement sheet written before you started shopping, a scorecard whose weights you set before you saw results, a fourteen day protocol you can rerun on any candidate, a staged exposure ladder, and a monthly review that tells you when something quietly changed.

All of it costs under a hundred dollars and two weeks of low-effort attention. Skipping it costs a balance, a customer list, or both, and the people it costs are usually the ones who found a rate 40 percent below the floor and decided that was the finding rather than the warning.

Panel Follows is one candidate for your shortlist, and the honest pitch is narrow. The catalog is 3,500+ services across 500+ categories, browsable before you register. The account is free with no reseller package, no membership fee and no minimum volume, so the list price is the price a reseller pays. Refill goes straight through without admin approval, cancel is a per-service flag you can read before ordering, cancelled and partial orders refund to balance automatically, and the API publishes 240 requests per minute per key rather than an adjective. As of August 2026 the panel runs in 10 languages with USD, TRY and EUR display currencies. None of that is a guarantee about drops, because no such guarantee exists. It is a set of claims built to be checked, which is what a fourteen day protocol is for, and the how it works walkthrough covers the order flow end to end if you want the mechanics first.

Run the protocol. Score three candidates. Cap your exposure. Keep the spreadsheet. Then rerun the review every month, because the provider you chose in week one is not necessarily the provider you have in month nine, and the only way to know is to keep measuring.