Paid TTS Audit Log for Moderator Decisions

Paid TTS needs receipts

Paid TTS feels like a chat joke until something goes wrong. A viewer says their message never played. A mod rejects a message and the viewer wants a reason. A browser source freezes. The streamer skips a message during a serious segment. Someone asks for a refund while chat is moving. If there is no audit log, the team ends up relying on memory in public.

The audit log does not need to be scary or legalistic. It is just a production record. Submitted, approved, edited, rejected, played, skipped, replayed, credited, refunded request sent. Those states give moderators a shared language. They also help the streamer review patterns after the stream instead of arguing from memory.

StreamableBot paid moments should be treated like live production, not disposable chat. The viewer paid for a specific promise. The streamer needs control over safety and pacing. Moderators need proof of what they did.

• Submitted: viewer paid or queued a message.
• Approved: moderator cleared it for playback.
• Edited: moderator changed pronunciation or removed unsafe wording according to rules.
• Rejected: message did not meet public rules.
• Played: browser source completed the moment.
• Replay owed: playback failed for a production reason.
• Credit or refund follow-up: account owner needs to handle it later.

Log the decision, not the drama

A good log is factual. It does not call viewers annoying, speculate about intent, or dunk on moderators. It says the message was rejected for slur, dox risk, sexual content, sponsor conflict, unreadable spam, too long, wrong mode, or duplicate submission. The reason should match the public rules.

Keep the categories short. If every rejection reason is a custom essay, moderators will stop using the log during busy streams. Use a small set of categories and allow one optional note for weird cases. That gives you consistency without turning moderation into paperwork.

This also makes post-stream review easier. If twenty messages were rejected for unreadable spam, your command copy is probably inviting the wrong behavior. If five messages were replayed because the browser source was hidden in one scene, the production setup needs a fix. The log teaches the next stream.

• Safety: slurs, harassment, threats, explicit content, or targeted abuse.
• Privacy: doxxing, real names, locations, phone numbers, or private details.
• Mode: TTS closed, sponsor-safe, guest segment, or focus mode.
• Technical: browser source failed, audio muted, scene hidden, or queue desynced.
• Duplicate: same viewer or same joke repeated too soon.
• Manual hold: needs streamer or senior mod decision.

Connect the log to platform chat reality

The log should not pretend all platforms behave the same. Twitch's developer docs describe chatbots, EventSub, message limits, chat moderation, and bot identity. Kick's Chat API lets authorized apps send messages and delete chat messages with scoped permissions. YouTube live chat has its own API resources and moderation tools. A cross-platform paid TTS queue needs platform labels and clear source context.

If a Twitch viewer and a Kick viewer have the same display name, the log should still know which platform the paid moment came from. If a message was removed on one platform but not another, the moderator note should make that clear. If a YouTube Super Chat is handled differently from a direct paid TTS message, the state should show it.

The log exists so a moderator can answer what happened without digging through three chats and a payment dashboard while the streamer is live.

• Viewer display name and platform.
• Payment or event type.
• Original submitted text.
• Moderated playback text if edited.
• Moderator action and reason category.
• OBS playback state.
• Follow-up owner if credit or refund review is needed.

Separate rejection from refund

Do not let moderators casually promise refunds in chat. A rejection is a moderation decision. A refund is a payment action. Those may be connected, but they are not the same job and not always handled by the same person.

Stripe's dispute docs explain that disputes are formal card-network claims that reverse payment and may involve fees and evidence. PayPal's refund help says sellers can issue full or partial refunds within a defined window, and once a refund is issued it cannot be canceled. The point for streamers is simple: payment language should be careful and handled outside the live moderation fight.

In the audit log, use follow-up states. Refund requested, credit offered, replay offered, no follow-up owed. Then the account owner can handle payment after stream with the actual transaction details. Moderators can keep the stream moving.

• Moderators can reject or hold according to public rules.
• Moderators can mark replay owed if playback failed.
• Moderators can escalate refund review.
• Only the account or payment owner should promise or issue refunds.
• Chat copy should say support will review it, not guarantee instant money back.

Track playback, not only approval

Approval is not fulfillment. A paid TTS can be approved and still fail because the OBS browser source was hidden, audio was muted, the scene changed, the streamer paused the queue, or the message played under loud gameplay. The audit log should track playback state separately.

OBS Browser Source is a web browser inside OBS, and its settings include width, height, frame rate, refresh behavior, and visibility behavior. If a browser source unloads when hidden or refreshes when a scene becomes active, that can affect paid moment playback. Logging playback problems helps you catch those scene-level mistakes.

Use states like queued, sent to browser source, visible, completed, interrupted, failed, replayed. That gives the moderator a clear reason to replay without relying on a viewer complaint. It also helps the streamer fix scenes after the show.

• Queued: approved but not sent to OBS yet.
• Sent: browser source received the moment.
• Visible: source was on the active scene.
• Completed: message finished playing.
• Interrupted: scene change, mute, or manual skip cut it off.
• Failed: source did not play or audio was missing.
• Replayed: mod fulfilled the owed replay.

Make the log fast enough for real mods

If the log takes too long, moderators will skip it during busy streams. The best version is mostly automatic with quick moderator buttons. Approve, reject, hold, edit, skip, replay, mark failed, escalate. Each action should attach a timestamp and moderator name. Reasons should be one-click categories with optional short notes.

Do not ask moderators to write essays while the stream is live. Long notes belong after the stream or only for unusual cases. The live log should capture the decision and enough context to reconstruct what happened.

StreamableBot should keep the mod view close to the queue. If a mod has to switch tabs between payment, chat, OBS, and a spreadsheet, the workflow will break. Paid moments need one queue with actions, states, and history.

• One-click action buttons.
• Preset rejection categories.
• Automatic timestamps.
• Moderator identity.
• Platform and event type.
• Playback state from the browser-source queue.
• Optional note for unusual cases only.

Review the log after stream

The audit log is not only for disputes. It is the best way to improve paid TTS. After the stream, look for repeated rejection reasons, replay causes, long queue delays, one moderator approving more risky messages than others, or a specific stream mode causing failures.

Turn patterns into rule changes. If sponsor-safe mode caused half the queue to get rejected, update the command copy before the next sponsor segment. If a voice mispronounced recurring names, update the pronunciation dictionary. If viewers keep paying during closed modes, change the checkout state instead of blaming viewers.

The review should be short. Pick one moderation fix, one production fix, and one viewer-copy fix. Then ship those changes before the next stream.

• Top rejection category.
• Top playback failure.
• Average queue wait during busy segments.
• Messages held for senior review.
• Refund or credit follow-ups.
• Viewer copy that caused confusion.

Other resources

Use these references when building a paid TTS queue that handles platform chat, browser-source playback, and payment follow-up cleanly.

• Twitch Developers: Chat and Chatbots.
• Kick Dev Docs: Chat API.
• YouTube Live Streaming API: LiveChatMessages.
• OBS Studio: Browser Source.
• Stripe Docs: Disputes.
• PayPal Help: How do I issue a refund?