When a panel withholds a payout: what to check first

Sooner or later every regular panel user hits it. you hit the redeem button, the balance drops to zero, and then nothing arrives. or the status sits on “pending” for three weeks. or an email lands saying your account was “reviewed” and your balance has been “adjusted.” the money you thought was yours is now a line in somebody else’s fraud queue.

This is a different problem from a screen-out. a screen-out costs you minutes (I covered that in screened out after five minutes and a week of screen-outs). a withheld payout costs you the accumulated result of many sessions, and it usually arrives with very little explanation. the stakes are small per person, often tens of dollars, but the pattern matters because the same mechanics sit behind almost every panel.

I am going to be careful in this piece about what I claim. I run survey-related sites from Singapore and I have read a lot of panel terms, but I am not going to tell you a story about a specific payout I chased and won. what I can do is lay out how withholding works mechanically, what the published terms of panels and payment processors say, and how to build your own paper trail so you are never arguing from memory. none of this is legal or tax advice, and nothing here guarantees a payout will be released. it is a framework for thinking clearly when the money does not show up.

background and prior art

Panels withhold payouts for a reason that is mostly boring: they are paid by clients who pay for clean data, and they are exposed to fraud. a survey client who receives duplicate respondents, speeders or bot answers will not pay for them, and the panel passes that loss downstream. the ESOMAR/ICC code, the international standard for market research conduct, puts data quality and respondent protection into the same framework, which is a useful reminder that the panel sits between two obligations: treating respondents fairly and delivering clean data to clients (ICC/ESOMAR code).

So the industry has two broad tools. the first is quality control at the survey level: attention checks, speeder flags, duplicate detection, “red herring” questions. the second is account-level control: device fingerprinting, IP reputation, profile consistency checks, and review queues that freeze balances while a human or a rules engine looks. the second tool is the one that withholds payouts. it works on the whole account, not on one survey, which is why a single bad flag can touch money you earned honestly weeks earlier.

Prior art for how this plays out on your side is mostly consumer-payments dispute practice: keep records, use the channel the terms specify, escalate to the payment processor or a consumer body only after the panel’s own process is exhausted. I will come back to that. if you want the account-ban side of the story, why survey accounts get banned covers the common triggers in more detail, and I will not repeat all of it here.

the core mechanism

A payout passes through several states, and withholding can happen at any of them. thinking in states is the most useful habit I can give you, because “my payout is missing” is not one problem. it is four or five different problems that need different responses.

state 1: earned but unconfirmed

Completes in a panel are often tracked as “pending” until the client confirms the respondent was valid. the panel has been told you finished, but it has not been paid for you yet. a reversal here is not really a withheld payout. it is a completion that was never confirmed, and most panels state in their terms that credits can be reversed if the client rejects the response. read the section of the terms usually called “rewards,” “points,” or “earnings” and look for the words “reverse,” “adjust,” “void” or “reject.”

state 2: confirmed balance, no request yet

This is the balance sitting in your account. it feels like your money, but in most panel terms it is a points balance that is a conditional entitlement, not a bank deposit. many terms say points have no cash value until redeemed and may be forfeited on account closure or inactivity. that is the clause that surprises people most, and it is the one to check before you let a balance grow. a large unredeemed balance is a risk you carry, not an asset.

state 3: redemption requested, in review

You pressed redeem. many panels run a review window here, sometimes called “processing,” where fraud rules run over the account and the request. this is the stage where payouts are most often held. reasons include a new payout method, a first redemption, a request just after a burst of activity, a mismatch between the name on the account and the name on the payment destination, or an IP or device that does not match the profile country.

state 4: sent by the panel, held by the processor

Sometimes the panel did its job and the money is stuck downstream. PayPal, for example, can place holds or limit accounts, and its user agreement describes the circumstances in which it can hold funds and the steps for resolving them (PayPal user agreement). if the panel says “paid” and shows a transaction ID, the dispute is now with the processor, not with the panel, and the panel can do very little. a lot of wasted time comes from emailing the wrong party.

state 5: clawback after payment

The least common state, and the nastiest. the panel pays, then later decides the earnings were invalid and tries to recover them, either by deducting from future earnings or by closing the account. whether they can legally do so depends on their terms and on local law, and I am not going to pretend I can tell you what applies to you. what I can say is that clawback language usually sits in the same part of the terms as reversal language.

what triggers a hold

Across panels the trigger list is fairly consistent. these are the patterns that, in my reading, most often put an account in review:

• location mismatch: profile says one country, connection looks like another. this is the big one, and it is why VPNs usually make it worse
• duplicate indicators: same device or same payout destination appearing on more than one account
• speed anomalies: completes that are much faster than the median for the survey
• inconsistent profile answers: age, income or employment answered differently across profilers
• payout details that do not match the account holder
• unusual redemption timing: first redemption straight after a spike in completes
• referral abuse patterns, which I wrote about in referral programs on survey panels and what a referral is worth

Notice that most of these are rules, not accusations. a rule fires, the account goes to a queue, and the queue is slow. understanding that a hold is often an automated flag waiting for a person helps you write a better support message. you are not defending yourself against a verdict. you are supplying the missing information that lets the reviewer clear the flag.

worked examples

The numbers below are illustrative arithmetic, not records of payouts I received. I am using them to show how to reason, and I want you to replace my numbers with your own from the panel’s current published terms.

example 1: a balance below the threshold gets forfeited

Suppose a panel’s terms say the minimum redemption is 10 units and that accounts inactive for 12 months forfeit their balance. I am making those figures up to show the logic. check the real ones in the panel’s terms before you rely on any of it.

You have 8.40 units and you stop logging in. the balance can never be redeemed unless you earn 1.60 more, and the clock on the inactivity clause is running. the practical question is whether you will ever earn 1.60 more on that panel, and how much effort that takes. here is a simple way to measure:

effort to unlock = (threshold - balance) / your_hourly_rate_on_this_panel
8.40 balance, 10.00 threshold, 1.60 gap
at 4.00 per hour: 1.60 / 4.00 = 0.4 hours = 24 minutes
at 1.00 per hour: 1.60 / 1.00 = 1.6 hours

Your own hourly rate comes from your own log: total credited units divided by total minutes spent, including the screen-outs and the pending completes that never confirmed. I keep that log in a plain spreadsheet with one row per session and columns for date, panel, minutes spent, units credited, status, and date confirmed. it takes a few seconds per row and it is the single most useful document in a dispute.

The lesson: sub-threshold balances are a withheld payout by design, not by accident. if the gap is 24 minutes, close it. if the gap is many hours at your real rate, decide early whether to write the balance off rather than let it nag you.

example 2: the identity mismatch hold

You request a payout to a PayPal account registered in a different name spelling than your panel profile. suppose the panel puts the redemption in review and asks for verification. this is the most common benign hold, and it is also the one where people get tempted to do something dumb.

The wrong response is to hand over a document that is not yours, or to alter a document to make it match. that is identity fraud, it is illegal, and I will not describe it further. the right response is boring. make the names consistent at the source: update the panel profile or the payment account so they match, then reply to the review request with the minimum information the panel asks for, through the channel it names.

Two practical points. first, send identity documents only through the panel’s official verification flow, never as an email attachment to an address you found in a forum. fake “payout support” accounts exist and target people with held balances. second, if the panel asks for something that seems disproportionate, such as a full ID scan from a panel that never mentioned one in its terms, ask in writing which clause requires it before you send it.

example 3: paid by the panel, stuck at the processor

The panel’s history shows “paid” with a date and a transaction reference. your wallet shows nothing, or shows a pending payment you cannot accept. arithmetic here is irrelevant. the move is to identify which party now holds the money.

1. open the processor’s activity page and look for the transaction by date and amount
2. if it appears as pending or on hold, the processor’s resolution flow applies, and the panel cannot release it
3. if it does not appear at all, check you used the right email or account ID on the redemption, and ask the panel for the transaction reference
4. if the panel cannot produce a reference, that moves it back into the panel’s court and you escalate there

The mistake I see most often is a long angry thread with panel support when the panel already did its part. one question (“can you send me the transaction ID and the recipient address it was sent to?”) sorts the ownership out in a single reply.

edge cases and failure modes

pitfall 1: waiting too long to redeem

People let balances grow because a bigger number feels better. but the balance is an unsecured promise, and every clause about forfeiture, closure or reversal attaches to it. counter-strategy: redeem when you cross the threshold, unless a documented bonus for larger redemptions genuinely beats the risk, and then count the risk honestly. the same logic applies to anything in the earnings column that depends on someone else confirming it, which includes much of what I wrote about in offer walls and cashback tasks on survey sites, the fine print. offer completions are among the most commonly reversed credits because they depend on a third party confirming the action.

pitfall 2: a profile that disagrees with itself

Panels run profilers repeatedly and compare. if you answered “employed full time” in March and “student” in September, a consistency rule may fire without anyone suspecting you of anything. counter-strategy: keep a note of your profile answers per panel and answer from the note. when something genuinely changes, update the profile rather than answering differently inside a survey.

pitfall 3: the device and connection story

A phone on mobile data at your home, a laptop on fibre, a tablet on cafe wifi. those can all be you and all be honest, but the more your devices and networks vary, the more signals the panel’s fraud system has to reconcile. I did not find a clean rule for how much variation is “too much”, and I distrust anyone who claims they have one. what I can say is that sudden changes right before a redemption, such as a new browser, a new country in the IP history or a new payout method all at once, stack signals. my advice is to change one thing at a time and let a redemption go through between changes. there is more on device behaviour in mobile versus desktop, which device sees more studies, though that piece is about study volume, not fraud flags.

pitfall 4: the support loop

You write, get a template reply, write again, get the same template. most panels route payout disputes through a ticketing system where the first line is scripted. counter-strategy: write one message that stands alone. include your account ID, the redemption date and amount, the payout method, the status you see, and the specific clause or timeframe from the terms you are relying on. then wait for the stated response time before following up. a single clear message is easier for a reviewer to action than five emotional ones, and it leaves a clean record. if you ever need to escalate, a calm thread looks very different from a hostile one.

pitfall 5: scam “recovery” offers

Once you post publicly that a payout is held, people appear offering to recover it for a fee or asking for your login. do not pay and do not share credentials. no legitimate panel releases funds via a stranger’s DM. if you think you have been targeted by a scam, the US FTC takes reports at reportfraud.ftc.gov, and if you are in Singapore, the Consumers Association of Singapore (CASE) is a more relevant starting point for a consumer dispute with a business that serves local customers. I cannot tell you whether either would take up a particular dispute over a panel balance. they are places to ask, not guarantees.

pitfall 6: forgetting the tax side

A payout you do receive may count as income wherever you live. the rules vary and I am not a tax adviser, so this is not legal/tax advice. I wrote a separate piece, tax on survey earnings, that covers how I think about record keeping. the connection to this article is simple: the same log that proves a dispute also gives you the records you may need at filing time. if a balance is later reversed or forfeited, your log also shows what you actually received versus what the dashboard once displayed.

a template for the first message

When a payout is held, this is the shape of the message I would send. it is not magic. its only job is to make the reviewer’s work easy.

subject: payout request [date] [amount], status check, account [ID]

hello,

I requested a payout of [amount] via [method] on [date]. the status
has shown "[status]" since [date].

account email: [email]
payout destination: [masked address]
last successful payout: [date, if any]

could you tell me whether the request is in review, and if so
what information you need from me to complete it? if the payout
was sent, could you share the transaction reference so I can
trace it with [processor]?

thank you,
[name as on account]

Notice what is not in it: no accusation, no deadline threat, no mention of reviews or complaints. you can always escalate later, but you cannot take back a hostile first message. also notice the question about the transaction reference. that one line resolves the state 3 versus state 4 ambiguity in a single reply.

what we learned in production

The main thing I have taken from running sites in this space is that the payout question gets decided before the payout request, not after it. the readers who end up with held balances are overwhelmingly the ones who had no record of when they earned what, who let balances sit for months, or who changed three variables at once and then asked for money. the readers who have a smooth time are the ones with a boring log, a consistent profile, and a habit of redeeming when they cross the threshold. none of that guarantees anything, since fraud rules sometimes fire on honest accounts, but it changes what you can show when they do.

The other lesson is about expectations on our side as a publisher. any article that tells readers a panel is “safe” or “pays reliably” is making a claim I cannot back with a controlled test, so I try to point readers at the panel’s own published terms and at ways to measure their own experience instead. if you take one thing from this piece, make it that: the terms are the contract, your log is the evidence, and a calm single message is the best first move. everything else is detail. for more in this vein, the blog index lists the rest of the payouts and account-health pieces.

references and further reading

• ICC/ESOMAR international code on market, opinion and social research: the industry standard behind respondent-treatment and data-quality obligations
• PayPal user agreement: the processor’s own terms on holds, limitations and dispute steps
• FTC reportfraud.ftc.gov: where to report scams, including fake recovery offers aimed at people with held balances
• Consumers Association of Singapore: a starting point for consumer disputes with businesses serving Singapore customers
• why survey accounts get banned: the account-level triggers that most often sit behind a hold

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-03.