FiveM Refund QA Checklist With Discord Test Cases Before Pushing New Scripts

Refund handling is one of the fastest ways to lose player trust if it breaks: missing logs, inconsistent approvals, or a Discord ticket that never reaches staff. When you push a new FiveM script (economy, shop, inventory, whitelist, or admin tools), you should run a targeted refund QA pass that validates both in-game behavior and Discord operations (roles, permissions, bot commands, ticket routing, and audit logs). This checklist is written for real server workflows: staff use Discord for intake, players provide proof, and you need traceable actions in logs.

Define the refund scope and test environment (before you touch production)

Start by defining what “refund” means on your server. Is it a Tebex package reversal, an in-game currency reimbursement, an item restore, or a vehicle re-grant? Each has different failure modes. Create a staging environment that mirrors production as closely as possible: same artifact build, same server.cfg convars, same ACE permissions, and the same Discord guild configuration (or a dedicated test guild with identical role IDs and channel structure). If your scripts reference Discord role IDs directly, don’t assume they will match across guilds—plan for that in your test plan.

• Clone your production server.cfg and resource start order; keep a separate staging database.
• Use a staging Discord guild or a “QA category” in the same guild with mirrored channels: #refund-intake, #refund-approvals, #refund-logs.
• Create at least three test accounts: Player, Helper, and Admin (plus a “Refund Manager” role if you use one).
• Document the exact script versions and commit hashes you are testing; include any SQL migrations.
• Confirm time zone settings for Discord timestamps and server logs to avoid confusion during audits.

FiveM-side refund workflow checks (economy, inventory, vehicles)

Refund QA on the FiveM side is about correctness, idempotency, and traceability. Correctness means the right player receives the right asset. Idempotency means repeating the same refund action doesn’t duplicate items or money. Traceability means every refund action leaves a clear trail in server logs and (ideally) Discord logs. Test common refund targets: cash/bank, inventory items (metadata included), weapons (ammo and components), vehicles (ownership tables), and housing/storage if your framework supports it (ESX/QBCore custom storages).

1. Create a baseline player state: record cash/bank, inventory list (including item metadata), owned vehicles, and job/grade.
2. Run a refund action for each asset type (money, item, vehicle) using your intended staff method (command, menu, or webhook trigger).
3. Repeat the same refund action with the same reference ID to confirm it does not duplicate (idempotency test).
4. Disconnect the player mid-refund (simulate crash) and verify the system either rolls back cleanly or completes once—never half-applies.
5. Restart the resource and the server, then verify the refunded assets persist and do not re-apply on startup.
6. Check for negative balances, overflow, or framework-specific constraints (e.g., max weight in inventory, vehicle garage capacity).
7. Verify logs: server console, file logs, and any database audit tables include who refunded, what, when, and why (reason field).

Concrete example: if you refund a “repairkit” with metadata (durability=100), confirm the metadata survives the round trip. If you refund a vehicle, confirm the plate is unique, the garage state is valid, and the ownership record points to the correct citizenid/identifier. If you use a refund tool like LD Refund System as part of your workflow, treat it like any other dependency: validate that the server-side export returns expected results and that your framework hooks fire in the correct order.

Discord roles, permissions, and ticket routing test cases

Most refund incidents are operational: the right staff never sees the ticket, the wrong role can run a command, or logs land in a public channel. Build explicit Discord test cases around roles, channel permissions, and ticket bots. Use real Discord terminology: roles, permission overwrites, audit log, webhooks, and application commands. Your goal is to prove that only authorized staff can approve refunds, players can’t see staff-only notes, and every action is attributable to a user.

• Role gating: Player cannot use /refund-approve; Helper can view tickets but cannot approve; Admin/Refund Manager can approve and close.
• Channel overwrites: Ticket channel visible only to ticket opener + refund staff roles; @everyone denied View Channel.
• Bot permissions: bot has Manage Channels (if it creates tickets), Send Messages, Embed Links, and Read Message History in ticket/log channels only.
• Webhook security: refund log webhooks restricted to a private #refund-logs channel; rotate webhook URLs if exposed.
• Command logging: every slash command writes an entry to #refund-logs with ticket ID, staff member, and outcome (approved/denied).

End-to-end refund scenarios (Discord ticket → FiveM action → audit trail)

After unit-style checks, run end-to-end scenarios that mimic how your community actually operates. Start in Discord with a ticket, collect proof, approve/deny, execute the in-game action, and confirm the audit trail across systems. This is where you catch mismatched identifiers (Discord ID vs FiveM license), missing reason fields, and race conditions when multiple staff act on the same ticket.

1. Player opens a ticket in #refund-intake and selects “Missing purchase item” as the category.
2. Bot asks for required fields: FiveM license/steam identifier, in-game name, transaction ID, and timestamp. Player submits screenshots.
3. Helper adds an internal note (staff-only) and escalates by tagging @Refund Manager.
4. Refund Manager runs /refund-approve with a reason and reference ID (ticket number).
5. In FiveM, staff executes the refund via your approved method (admin menu/command/export) and confirms the player receives the asset.
6. System posts a structured log message to #refund-logs: ticket ID, staff ID, player identifier, asset refunded, amount, and reason.
7. Refund Manager closes the ticket; transcript is saved to a staff-only archive channel.

Make sure your logs tie together. A good pattern is to use the Discord ticket ID as the reference ID in FiveM logs and database entries. If you rely on a dedicated refund workflow tool (for example, LD Refund System), verify that it records the staff actor, the player identifiers (license and Discord ID), and the refund payload in a way you can export during disputes.

Logging, evidence retention, and dispute readiness

Refund QA is incomplete without testing your evidence and retention path. When a player disputes a decision, you need to reconstruct the sequence: ticket creation, proof submitted, staff decision, and the in-game action. Test that your logs are consistent, private, and durable. In Discord, that means a locked #refund-logs channel, optional transcript storage, and minimal access. In FiveM, that means structured server logs and (if applicable) database audit rows for refund events.

• Verify log completeness: who acted, what changed, when it happened, and the reason/reference ID.
• Verify privacy: players cannot see #refund-logs, transcripts, or staff notes; helpers only see what they need.
• Verify integrity: logs are append-only (or at least restricted) and backed up; avoid editable Google docs as the primary record.
• Verify correlation: Discord ticket ID appears in FiveM logs and any refund database table; player identifiers match.
• Verify alerting: failures (DB error, missing identifier, permission denial) post to a staff-only #bot-errors channel.

Pre-push gate: what must pass before you deploy new scripts

Treat refund QA as a deployment gate, not an optional check. New scripts often change inventories, money accounts, identifiers, or event flow—exactly the areas refunds depend on. Before you push to production, require a signed-off run of the checklist with artifacts: screenshots of Discord permissions, sample log entries, and a short note on any known limitations. If something fails, fix it in staging and rerun the relevant tests; don’t “hotfix” refund logic live unless you also document the change and verify logs.

1. Run the FiveM-side checks for money, items (with metadata), and vehicles, including idempotency and restart persistence.
2. Run Discord permission tests for Player/Helper/Admin roles and confirm ticket visibility boundaries.
3. Execute at least one end-to-end scenario with a real ticket transcript and a matching FiveM log entry.
4. Confirm log retention and backups for #refund-logs and server logs; verify error alerts go to the right staff channel.
5. Record the script version, config snapshot, and the test results in a staff-only changelog channel (e.g., #ops-changelog).