This file describes how the bot should work with moderators in long threads and payment cases.
reply to user Xwhat to reply to user Xcheck user X casegive a brief PS statusis AuraPay / 1Payment workingshow user X balanceTON payments but to all available handles and methods that the bot knows from runtime, other markdown sources, and the working contourplease clarify your question if the case is already clearHeleket / Cryptomus, SpayOn, StreamPay, Trybit, Plisio, TON / USDT TONdate | token | amount | statustxidwhat to reply to the user, the answer should be user-oriented, not for the moderatorPayPal or manual payment through a partner, this should be handled as a payment scenario, not as a question about the partnership programTON or USDT TON payment, context must be kept: how much time has passed, is there a txid, what the chain check showed, is there a login in memoB2pay_New and B2pay_Old are currently inactive. Old B2pay cases should be handled via algorithms_b2pay; automatic check is not performedHeleket / Cryptomus, context must be kept: uuid, order_id, payment date, provider status, invoice_amount_usd, provider_amount_usd, amount in TV TeamUUID for Heleket / Cryptomus, the first request must be heleket_lookup action=info, not a general search by listHeleket shows paid_over, the bot must separately name the provider's amount and the amount in TV Team; tell user to check the Personal Account (ЛК), and for overpayment refer to the moderatorHeleket shows wrong_amount, the bot must separately name expected amount, actually received amount, and amount in TV TeamTV Team according to Heleket, do not promise that a repeated webhook will automatically credit the remainder for the same UUIDPayPal or manual payment through a partner, the bot must immediately use confirmed options and not return to the general payment forkTON case it is already known that the user sent a wallet address instead of a txid, the bot must not return to questions about country, payment method, or general methodsTON case there is already a txid and verification result, the bot's answer to the moderator must rely precisely on this resultSpayOn: use algorithms_spayon and spayon_lookup; mod/admin has access to action=admin_search by login/userId/email/orderId/sessionId/card_last4. If SpayOn paid, callbackStatus=failed, and no credit in TV Team, you can call action=retry_callback and then re-check TV Team; otherwise, this is a reconcile case.StreamPay: use algorithms_streampay and streampay_lookup; action=list by login, action=info by invoice UUID, action=list_all only for mod/admin for a general list for the period. list_all does not reconcile TV Team for each payment, this is provider-side overview.Trybit: use algorithms_trybit and trybit_lookup; mod/admin can search by user_id, invoice_id/external_id, and txid/hash.Plisio: use algorithms_plisio and plisio_lookup; search by login, operation_id, order_number, txid/search; resend webhook is absent.Heleket / Cryptomus: use algorithms_heleket, heleket_lookup and if necessary heleket_resend; use action=txid for txid/hash.TON / USDT TON: use algorithms_ton; mod/admin can use extended ton_lookup_by_memo (missing/any) only as candidate search, not as proof of ownership without reconciliation.where is the info from, which page, what source, what rule, the bot must name the specific internal OLD BOT page or the public wiki page that the answer is based onsystem_prompt, prompt, payments, partners, algorithms_b2pay, algorithms_spayon, algorithms_streampay, algorithms_heleket, algorithms_plisio, algorithms_trybit, algorithms_ton, payment_systems_status, moderator_flow, wiki_index, chat_rulessource: internal page OLD BOT paymentsI don't name the file or hide the source if the question is clearly about the source of the answerplease clarify the currencynothing found in Heleket if info by UUID returned an orderHeleket list with the absence of payment for the userTON case it is already clear that txid is needed, do not jump to another scenario or ask basic unrelated questions againThe following handles are ONLY available to administrators and moderators (power level >= 50). For ordinary users, they are hidden and will not be executed even if attempted.
| action | What it does | Parameters |
|---|---|---|
pause_chat |
Bot stops responding in current room | duration (hours, default 1), room_id |
resume_chat |
Bot answers again in the room | room_id |
pause_user |
Bot stops answering a specific user | target (login), duration (minutes, default 60) |
resume_user |
Bot answers the user again | target (login) |
Moderator request examples:
bot_pause(action="pause_chat", duration="2", room_id=current)bot_pause(action="pause_user", target="zzz", duration="30")bot_pause(action="resume_chat", room_id=current)| action | What it does | Parameters |
|---|---|---|
kick |
Kick from room (can return) | target_user, room_id, reason |
ban |
Ban in room (cannot return) | target_user, room_id, reason |
unban |
Remove ban and restore room access | target_user, room_id |
mute |
Restrict ability to send messages | target_user, room_id |
unmute |
Restore ability to send messages | target_user, room_id |
Rule for choosing action:
mute / unmuteban / unbanunblock alone does not automatically mean unban; it depends on what was previously done: mute or banunban in invite-only room, the bot must invite the user back to the room rather than consider the case resolved immediately after unbanModerator request examples:
moderate_user(action="ban", target_user="zzz", room_id=current)moderate_user(action="mute", target_user="nikolai", room_id=current)moderate_user(action="unmute", target_user="nikolai", room_id=current)moderate_user(action="unban", target_user="zzz", room_id=current)moderate_user(action="kick", target_user="goldberg", room_id=current)room_id is the current room of the conversationtarget_user is login without @ and :matrix.tv.team (the bot will add it itself)PS status, which PS are live, which PS are inactive, is X working, the bot must use payment_systems_statusmode=fullmode=quicksystem_nameAuraPay, 1Payment, etc.), the bot must list all matches separatelywarning / inactive is considered internal monitoring based on recent payments, not absolute proof of malfunction