FiveM Refund Approvals with Discord Multi-Step Verification and Two-Person Review

Refunds are a high-risk workflow for any FiveM community: they touch money, player trust, and staff integrity. A clean refund process should do three things consistently: verify the requester, validate the purchase and server-side delivery, and require independent approval before funds leave your control. Discord is a practical control plane for this because it supports role-based permissions, structured tickets, and immutable log channels when configured correctly. This guide walks through a multi-step verification flow and a two-person review model that fits typical FiveM operations (Tebex/Stripe/PayPal, in-game entitlements, and staff teams).

Define the threat model and minimum controls

Before you add bots and forms, decide what you are protecting against. Common refund risks in FiveM include: compromised Discord accounts requesting refunds, staff approving refunds for friends, duplicate refunds across multiple tickets, “I didn’t receive it” claims when the entitlement was delivered, and chargeback pressure that leads to rushed approvals. Your minimum controls should match those risks: identity verification tied to the player’s FiveM identifiers, evidence requirements (receipt, transaction ID), and separation of duties so no single staff member can verify, approve, and execute a refund alone.

Discord roles and permissions for refund separation of duties

Start with a simple role model that prevents conflicts of interest and reduces accidental approvals. Avoid giving refund powers to broad roles like “Moderator.” Use narrow roles, private channels, and explicit permission overwrites. In Discord, build a dedicated category (e.g., “Refunds”) where only relevant roles can view tickets and logs.

• @Support (Tier 1): can open and manage refund tickets, request evidence, but cannot approve refunds.
• @Refund Reviewer (Tier 2): can mark a request as “verified” after checking identity and purchase evidence.
• @Refund Approver (Tier 3): can approve/deny after reviewer verification; cannot execute payouts if you separate execution.
• @Finance (optional): executes payouts in PayPal/Stripe/Tebex and posts confirmation; no ticket deletion permissions.
• @Audit (read-only): can view refund logs and finalized tickets, cannot message in refund channels.

Lock down permissions tightly: remove “Manage Channels” and “Manage Messages” from anyone who shouldn’t be able to delete evidence. If you use a ticket bot, ensure it writes transcripts to a log channel that staff cannot purge. For sensitive channels, disable “Create Invite” and consider requiring 2FA for staff roles via Discord server settings (Server Settings → Safety Setup → Require 2FA for moderation actions).

Multi-step verification: bind Discord identity to FiveM identity

Multi-step verification is more than “react to get a role.” For refunds, you want a binding between the Discord user and the in-game identity that received the product. A practical approach is: (1) verify Discord account basics, (2) verify FiveM identifiers, and (3) verify purchase proof. You can do this with a verification bot plus your own staff checklist.

1. Gate access: require a verified Discord role before a user can open a refund ticket. Use a verification bot (or your own) to apply @Verified after phone/email verification and account age checks.
2. Collect identifiers: in the refund ticket, require the player’s in-game name, server ID at time of purchase (if known), and at least one stable identifier (license:, discord:, steam:, or fivem:). If you run txAdmin, cross-check the player history and identifiers there.
3. Prove ownership: request the receipt email screenshot or the transaction ID from Tebex/PayPal/Stripe. Never accept only a Discord DM screenshot as proof.
4. Confirm delivery: check your server logs for entitlement delivery (e.g., a log entry when a vehicle was granted, a package role applied, or an item was added). If you use ESX/QBCore, verify the database entry or server-side grant event logs.
5. Risk check: flag mismatches (different Discord ID than purchase email name, new Discord account, multiple refund attempts). Escalate to @Refund Reviewer if any mismatch appears.

Two-person review workflow: verify, then approve (and optionally execute)

Two-person review means one staff member verifies the claim and another independently approves the decision. This reduces both honest mistakes and intentional abuse. In Discord, implement this with ticket stages, role pings, and a required “review” message format that becomes part of the permanent record.

A workable pattern is: Support gathers information → Reviewer verifies identity and delivery → Approver decides refund/deny → Finance executes payout (optional separation) → Ticket is closed and transcript is logged. If you use a refund management tool like LD Refund System, configure it so the reviewer and approver actions are distinct and logged, rather than allowing a single-click refund from a broad role.

• Verification message (Reviewer): “Verified: identifiers match txAdmin history; transaction ID confirmed in Tebex; entitlement delivered on 2026-01-10; no prior refunds found.”
• Approval message (Approver): “Decision: approve refund due to duplicate charge; payout method: PayPal; amount: $25; conditions: revoke package role and in-game asset.”
• Execution message (Finance): “Executed: PayPal refund completed; reference ID ####; revocation completed; timestamp.”

Enforce that the approver cannot be the same person as the reviewer. If your ticket bot supports it, require a different role to press the “Approve” button than the one that pressed “Verified.” If it doesn’t, enforce it procedurally with a checklist and periodic audits of transcripts.

Logging and audit trails: what to record and where

Refund compliance depends on your ability to reconstruct what happened weeks later. Keep logs in two places: Discord (for staff actions and evidence) and server/payment systems (for delivery and transaction confirmation). In Discord, create a write-only #refund-audit-log channel where only bots can post, and an #refund-staff channel for internal discussion that is not visible to applicants.

• Ticket transcript (including attachments or at least attachment URLs)
• Reviewer verification statement and timestamp
• Approver decision statement and timestamp
• Payout confirmation (transaction reference)
• Revocation actions taken (roles removed, packages revoked, vehicles/items removed)
• Links to supporting logs (txAdmin player history, FiveM resource logs, Tebex order page)

On the FiveM side, ensure your entitlement-granting scripts log to server console and file logs with enough context (player identifiers, package name, staff member or automated job, timestamp). If you use Discord webhooks for logs, send them to a dedicated channel and lock webhook management to administrators only.

Handling edge cases: partial refunds, revocations, and chargeback pressure

Edge cases are where refund processes break down. Define rules in advance and apply them consistently. For example: if a player used a purchased vehicle for two weeks, you may deny a refund but offer store credit if your policy allows it. If the product is a consumable item, you may require revocation (remove items, remove roles, or wipe the granted asset) before executing the refund.

Plan for chargeback threats. Staff should not rush approvals in DMs. Keep all communication in the ticket, acknowledge the request, and follow the same verification steps. If a payment processor dispute is opened, your best defense is documentation: proof of delivery, server logs, and the transcript showing the requester’s identity and statements. Tools such as LD Refund System can help keep the approval steps structured, but the underlying policy and evidence standards still matter most.

1. Freeze the ticket: stop informal negotiation in DMs; require all updates in the ticket.
2. Re-check identity: confirm the Discord user still matches the FiveM identifiers and any linked accounts.
3. Confirm revocation feasibility: ensure you can remove the entitlement cleanly (roles, vehicles, whitelisted access).
4. Decide and document: approve/deny with a short rationale tied to policy and evidence.
5. Close and log: export transcript, post payout reference if applicable, and tag the ticket with outcome (Approved/Denied/Chargeback).

When you revoke assets, be explicit about what you did. Example: “Removed @VIP role, revoked Tebex package ‘Gold’, deleted vehicle plate ABC123 from owned_vehicles, and removed 250,000 cash adjustment.” Clear revocation notes prevent repeat tickets and help new staff understand prior actions.