Banned Viewer, Pending Paid Item: A Twitch Unban Request SOP for Moderators

The ban does not know about your queue

Picture a Thursday stream. A viewer pays for a 20-second TTS read, it sits in your approval queue, and in the meantime that same viewer starts spamming chat. A mod bans them. Nothing about that ban touches the paid item. It is still sitting there, still scheduled, and your next mod might approve it without ever noticing who sent it.

A Twitch ban lives in Twitch chat. A tip page, upload form, or paid-TTS checkout is a different system with its own record. Unless you have confirmed your tools connect the two, assume a human has to carry the ban across by hand.

This SOP covers two moments: paid items in flight when the ban happens, and the unban request that may arrive later. Refund mechanics and chargebacks stay in their own posts.

Five states a paid item can be in

The right response depends on how far along the item was. Write these five states on your mod sheet and name them the same way every time.

• Before the ban: the viewer paid or submitted and the item is already done. Nothing to un-play. Only the record matters.
• Queued: paid, waiting for review. Nobody has looked at it. This is the easiest state to freeze.
• Approved, not yet played: a mod said yes before the ban. The approval was based on what the mod knew then, so it deserves a second look.
• Playing: audio or an image is on the broadcast right now. A mod needs a fast stop, and the stop gets logged as an interruption, not a rejection.
• Played: it aired. The ban may change how you treat the clip, the VOD, and any highlight, but the paid moment itself happened.

Decision tree for items still in flight

For queued and approved-but-unplayed items, you have three options. None is the single correct answer, and each costs something different. Which you pick is a streamer policy decision, and I am not offering legal advice on what anyone owes anyone.

Hold means the item stays in the queue, flagged, until the unban-request outcome or a streamer ruling. It preserves the option to play it later. The cost is a growing pile of limbo items and a viewer who is waiting without knowing why.

Void means the item will never play. You then separately decide whether the viewer gets a credit, a refund, or nothing, based on what your published rules say. Keep voiding and paying back as two different decisions, because a ban for a chat reason and a ban for abusing the paid feature are not the same story.

Streamer-only review sends the item to a private view instead of the broadcast. A lead mod can read or hear it and judge whether it is a safety issue. It helps when the content might be a threat or doxxing attempt, though it does little for the viewer, since the point of paying was an audience.

One example default: queued items are held, approved-but-unplayed items go back to review with the first reviewer's note attached, and anything that smells like harassment is voided after a streamer-only look.

What Twitch actually gives you for unban requests

The Get Unban Requests endpoint returns a list of requests for a channel. It needs a user access token with the moderator:read:unban_requests or moderator:manage:unban_requests scope, takes a broadcaster_id and a moderator_id that must match the token's user, and requires a status filter. The documented status values are pending, approved, denied, acknowledged, and canceled. Each record includes the requester's ID and names, the text of the request, created_at, resolved_at, the resolving moderator, and resolution_text.

Resolving is a separate call, Resolve Unban Requests, which needs the manage scope. It is a PATCH to the same URL, and it takes broadcaster_id, moderator_id, unban_request_id, a status of approved or denied, and an optional resolution_text, all as query parameters. The reference lists a 500 character cap for that message; check it again before you build a template library, since limits get revised.

On the live side, EventSub has channel.unban_request.create and channel.unban_request.resolve, both needing one of the same two unban-request scopes. The create event carries an id, the requester's user fields, the request text, and created_at. The resolve event adds the resolving moderator, the resolution text, and a status of approved, canceled, or denied.

What Twitch's help pages say, and where I could not confirm

Twitch's own help and safety pages are only partly confirmed here: the next two sentences come from search-result snippets, not full reads, so treat them as a lead to verify.

Per those snippets, a banned viewer can submit a one-time unban request from chat, and channel owners and mods can review it, approve it, deny it, or leave it pending. A Twitch Support post from 2020, also seen only as a snippet, said owners can set a cooldown before a request can be sent and can opt out of receiving requests entirely. Kotaku's launch coverage from October 2020 is a full article and quotes Twitch saying mods review requests anonymously, reports that a viewer gets one request and a denial ends it, and records streamers worrying that the request text becomes a new harassment channel.

I could not confirm how long Twitch keeps ban and request history, so I am not quoting a window. Keep your own log instead of leaning on Twitch's history for paid-item decisions.

Everything in this post about ban and unban requests is Twitch only. Kick and YouTube have their own moderation tools and their own rules, and I have not verified how they handle appeals, so do not carry any of this over by assumption. Check each platform's current docs.

Triaging an unban request when it arrives

Whoever first sees the request does not decide it. They open a note with the request ID, the requester, created_at, and the ban reason as best you can reconstruct it from the mod log or channel notes.

Next, check the paid-item ledger. Is anything still held for this person? Did something play that now sits in a clip? Decide in advance whether approval releases held items automatically or sends them to fresh review. Fresh review is the safer lean, since the old context has gone stale.

Then read the text last. If the message is abusive, mark it and do not engage, but still resolve the request on the original ban reason, not on how you feel about the message. If it is thoughtful, that is a data point, not an obligation. Who decides is yours to define: the broadcaster alone, a lead mod, or two mods agreeing.

Resolution notes: four examples, kept short

The resolve call accepts optional text. Short beats clever, and I would write it assuming the banned person might read it, since the field is described as a message supplied by the resolver. Each of these examples is under 100 characters, well inside the documented 500.

• Approved after cooldown, chat-only issue: "Unbanned. Follow the chat rules and we are good."
• Denied, paid-feature abuse: "Denied. The ban covered misuse of paid features. Decision is final."
• Denied, not enough information: "Denied. We could not tie this account to the behavior it explained."
• Approved with a condition: "Unbanned. Paid features stay off for this account for now."

Audit fields to log for every case

Keep one row per ban event and one row per request. The goal is that a mod who was not on shift can reconstruct what happened without asking anyone.

• Ban: viewer ID and login, who banned, UTC time, reason in one line, and which stream session.
• Each paid item at ban time: item ID, type (TTS, alert, upload), amount, state from the five-state list, and the action taken.
• Who made the hold, void, or streamer-only call, and who second-checked it.
• Request: Twitch request ID, created_at, text pasted verbatim, status when resolved, resolved_at, resolving mod, and the exact resolution_text sent.
• Any paid item released, credited, or refunded afterward, with the reason and a link to the policy line used.
• Whether any clip, VOD marker, or highlight includes the viewer's played item.

Repeat offenders and ban evasion, handled carefully

A denied viewer may return on a new account and pay for a TTS read, but you rarely have proof it is the same person. A matching writing style or similar name is a hint, not evidence, and you do not want to void a stranger's payment because they sound like someone you banned.

A workable rule: hold the item, flag it to a lead mod, and ask a question that can be answered without accusing anyone, such as whether the item meets your normal rules. If it clearly breaks your rules, void it on that basis. If it does not, it plays like any other item and you keep watching.

For repeat cases on one account, count approved unban requests for the same pattern. Maybe a third approval needs the streamer's sign-off. The threshold is a choice, so write down your number.

Permissions, two reviewers, and what the viewer hears

Resolving through the API needs the manage scope on a mod's token. Give that scope only to mods you trust to decide, and keep the read scope for anyone who just needs to see requests. Whoever can release held paid items should be a small group, ideally not just the person who made the ban.

Use a two-reviewer rule for two moments: approving an unban request when held paid items exist, and voiding a paid item above an amount you set. One mod proposes, a second confirms, and both initials go in the log.

As for the viewer, say the minimum and avoid promising outcomes in chat. Something like: your item is on hold while the team reviews a moderation action, and a decision will be sent through the channel you used to pay. Whatever review list holds the item, assume nothing in it knows about the ban: I have not confirmed that any tool connects Twitch bans to a paid queue, so you are the connection.

A fifteen minute drill

Before your next stream, make one queued item, one approved item, and one played item under a test account, then have a mod pretend to ban it. Time how long the team takes to find all three, assign states, and act.

Next, invent an unban request with made-up text. Log it, check the ledger, read the text last, draft a note, get a second reviewer, and record the result. Run a denial too, and confirm nobody promised the viewer anything in chat.