FiveM refund runbooks with Discord incident templates and postmortem logs

Refunds are operational incidents. They interrupt staff focus, create public pressure, and can escalate into chargebacks or trust issues if handled inconsistently. A refund runbook gives your FiveM staff a single source of truth: what to collect, who decides, how to communicate, and how to log outcomes. Pair it with Discord incident templates and postmortem logs, and you get repeatable handling that is faster, calmer, and easier to audit.

Define your refund policy as an incident runbook (not a paragraph in rules)

Most refund problems come from ambiguity: unclear eligibility, missing proof, or staff improvising in public channels. Convert your policy into a runbook with decision points and required artifacts. Keep it short enough to follow during peak hours, but strict enough to be defensible if a payment processor dispute happens later.

• Eligibility rules: e.g., “donation perks delivered but player banned for cheating = not eligible,” “double charge within 24h = eligible,” “server outage during purchase window = case-by-case.”
• Time windows: e.g., 48 hours for “not received,” 7 days for “billing error,” no refunds after perks consumed (define what “consumed” means).
• Required evidence: Discord ID, FiveM license identifier, transaction ID, timestamp, perk/package name, and proof of non-delivery (screenshots/log excerpts).
• Decision authority: which role can approve (Finance Lead), which role can execute (Billing Ops), and which role can communicate (Support).
• Communication rules: all refund comms must stay in a ticket thread; no public negotiation in #general.
• Escalation path: when to involve server owner, legal/processor contact, or ban evasion checks.

Set Discord roles, permissions, and channels for refund incidents

Refund handling needs privacy, separation of duties, and clean audit trails. Configure Discord so sensitive data (transaction IDs, emails, payment references) never appears in public channels. Use roles to prevent “helpful” staff from making promises they cannot keep.

• Roles: Support Agent (triage), Senior Support (verification), Finance Lead (approval), Billing Ops (execution), Community Manager (public comms).
• Permission boundaries: only Finance Lead/Billing Ops can view #billing-private; Support can read/write tickets but cannot see payment exports.
• Channels: #support-intake (read-only info + how to open ticket), #refund-queue (private staff), #billing-private (restricted), #incident-log (staff-only, append-only via bot/webhook).
• Discord features: use forum-style channels or ticket threads; lock tickets after resolution; require staff to use canned responses.

Example permission setup: create a “Billing Ops” role with View Channel on #billing-private and deny @everyone. In your ticket channel, allow Support Agent to Manage Threads but deny Manage Messages to reduce accidental edits. If you use a ticket bot (e.g., Ticket Tool), configure a “refund” panel option that auto-tags Finance Lead and applies a “Refund Pending” label.

Use Discord incident templates to standardize intake and reduce back-and-forth

A refund template should collect identifiers that map to FiveM logs and your store records. The goal is to avoid five rounds of questions. Put the template in the ticket bot’s first message, and require completion before staff proceeds.

1. Open a “Refund Request” ticket from the panel. Bot posts the intake form.
2. Player completes required fields: Discord tag/ID, FiveM identifiers (license/steam/discord), in-game name, transaction ID, purchase date/time, package name, and issue type (not received/double charge/chargeback threat).
3. Support Agent verifies identity: ask player to type “I confirm this is my account” and match Discord ID to store record or prior verification.
4. Collect evidence: screenshot of receipt, store webhook log entry, and server delivery log (e.g., txAdmin action log or your script’s grant log).
5. Classify severity: S1 (chargeback filed/processor dispute), S2 (high-value purchase), S3 (standard refund). Apply the correct ticket label.
6. Senior Support reviews eligibility and completeness; Finance Lead approves/denies with a reason code.
7. Billing Ops executes refund or corrective delivery and posts confirmation details (no full card/email data).
8. Close ticket with resolution summary and link to postmortem entry if applicable.

Template snippet you can paste into the ticket opener message (keep it short): “Transaction ID: __; Package: __; Purchase time (with timezone): __; FiveM license: __; In-game name: __; Issue type: __; What did you expect to receive: __; What did you receive: __; Attach receipt screenshot.” This structure makes it easy to search later and correlate with FiveM identifiers.

FiveM-side evidence: what to log so refunds are provable

Discord transcripts alone are not enough. You need FiveM-side proof of delivery attempts and player identity mapping. At minimum, log: who triggered delivery, what was granted, which identifiers were used, and whether the player was online. If you run txAdmin, use its action logs alongside your own script logs.

• Identifier mapping: store Discord ID ↔ FiveM license (license:xxxxxxxx) ↔ steam:hex ↔ fivem:ID where available. Log the mapping at purchase verification time.
• Grant logs: timestamp, package SKU, items/vehicles/roles granted, target identifiers, staff/bot actor, result (success/fail), and error message.
• Join/leave correlation: player connect time near purchase; if delivery requires online presence, log “queued delivery” vs “delivered.”
• Anti-fraud signals: multiple refunds from same license/Discord, sudden identifier changes, or repeated “not received” claims across alts.

Concrete example: if a player claims they did not receive a donor vehicle, your log should show something like “2026-01-24T19:22Z grant_vehicle sku=VIP_CAR target=license:abcd actor=store_webhook result=fail err=player_offline queued=true,” followed by “delivered=true” when they next connect. Without this, staff ends up debating screenshots instead of checking facts.

If you use a dedicated refund workflow tool such as LD Refund System, align its internal statuses with your Discord labels (e.g., Pending Evidence, Approved, Executed, Denied). The key is consistency: the same stages, the same reason codes, and links back to the same ticket transcript.

Postmortem logs: capture what happened and prevent repeats

Not every refund needs a full write-up, but every refund should create a minimal postmortem record. Reserve deeper postmortems for S1/S2 incidents (chargebacks, high-value losses, repeated delivery failures). A good postmortem is short, factual, and action-oriented.

• Incident ID and ticket link (Discord message link + transcript location).
• Timeline: purchase time, webhook received, delivery attempt, player report, resolution time.
• Impact: amount refunded, staff time spent, number of affected players, any public channel disruption.
• Root cause: delivery script error, permissions misconfig, store webhook outage, staff mistake, unclear policy wording, or fraud attempt.
• Corrective actions: code fix, permission change, new template field, staff training note, monitoring alert.
• Evidence pointers: txAdmin log link, server console excerpt, bot logs, and store payment reference (redacted).

Example postmortem entry (S2): “Root cause: Discord role grant failed because the bot lost Manage Roles permission after role hierarchy change. Corrective action: move bot role above Donor roles; add weekly permission check; add alert when role grant fails 3 times in 10 minutes.” This is the kind of operational learning that reduces future refunds.

If you already run LD Refund System or a similar tracker, export a monthly summary by reason code and root cause. Use it to prioritize fixes: delivery reliability usually beats policy rewrites for reducing refund volume.