Trace issuance, storage and display separately
Start with the expected roleplay behavior: who can obtain a card, whose identity it represents and who can view it. A usable inventory item and a polished card interface do not establish that the correct character data reaches the display.
Trace one test card through its issuing resource, saved item metadata and use or presentation handler. Record the exact item name and resource versions. If you replace an inventory or card interface, compare the data contract on both sides rather than assuming matching labels mean matching fields.
A QBCore issuance example and its limits
At qb-inventory commit dc3d07fc60139de569df38c5ac178ed4cada4577, the administrative give-item path handles id_card by filling info from the target player’s data. The fields are citizenid, firstname, lastname, birthdate, gender and nationality. The adjacent driver_license branch uses its own fields, including type.
That is evidence for this issuance path, not every starter-item, shop or replacement-card integration on your server. Inspect the path actually used to create the failing card. A second resource can create an item with the same name but omit information expected by the display.
| Layer | Question | Evidence to retain |
|---|---|---|
| Issuing resource | Which character supplies the identity? | Issuance path and synthetic test character |
| Item definition | Which internal name is created? | Actual item key, not just its display label |
| Metadata | Which fields are populated? | Redacted keys and expected synthetic values |
| Use handler | Which item instance is read? | Selected slot or instance and handler revision |
| Display | Which fields does the interface expect? | Expected schema versus received data |
| Persistence | Does the same data return after reconnect? | Before and after comparison |
Diagnose blank names without guessing a new schema
First determine whether the card was issued without a name or whether the interface failed to read an existing value. Use a synthetic test identity and inspect the item metadata on staging. Keep field names and nesting visible while redacting real player information.
If metadata is missing at issuance, fix that integration rather than adding an arbitrary default name to the interface. If metadata exists but the display is blank, compare the expected key names and types with the received item. A template expecting a different inventory schema needs an explicit adapter.
Repeat the test with a newly issued card and a pre-existing card. Repairing future issuance does not prove older item instances gained the missing fields. Define a supported replacement or migration process for historical cards and rehearse it against a recoverable copy before changing saved player items.
Test the identity after a card changes hands
Decide whether a card should represent the issued identity, the current holder or a live record lookup. Make that policy explicit. A presentation script that reads the viewer’s current character can show a different identity from the one stored on the card.
On staging, issue a card to character A, transfer it to character B if your server permits transfer, and inspect it from the intended viewer. Compare the displayed identity with the policy. Then reconnect both characters and repeat. These are proposed acceptance cases, not runtime results from a Magnate server.
Also define what should happen after a character changes their roleplay name or replaces a lost card. A snapshot and a live lookup have different update behavior. Avoid silently changing every saved card to match a current holder merely because the interface can read that holder’s profile.
Check presentation range and recipient rules
Define whether using a card should show it only to the holder, to a selected nearby player or to a group. Test with an intended recipient and another character outside the intended scope. A visible card on the sender’s screen does not prove delivery to the other player.
If the item does nothing, check the item-use handler before changing the interface theme. If both players see duplicate cards, isolate the issuing, item-use and presentation integrations on staging. Retain the first relevant error and a minimal reproduction instead of replacing several packages at once.
Keep document types and permissions distinct
An identity card, driving license and job credential answer different questions. Decide which authoritative record permits issuance and which actions require a server-side check. Hiding an interface button is not sufficient evidence that unauthorized issuance is rejected.
Use the inventory guide for the broader item integration and the chat guide if a presentation path depends on chat output. This page does not implement an issuer, execute inventory changes, establish legal identity or claim GTA VI compatibility. Use fictional roleplay data in examples and redact private player records in public support requests.
Questions, answered.
Why does my FiveM ID card show blank names?
Check whether the issuing path populated metadata, then compare the saved fields with the interface schema. A card item existing in inventory does not establish that its identity fields are present.
Does every ID card use QBCore info fields?
No. Match the issuing resource, inventory and display contract for your exact framework and fork.
Should a transferred card show its holder’s name?
Define the intended policy first. Test the issued identity, current holder and viewer as separate roles instead of assuming they are interchangeable.
Sources & editorial notes
Source review: November 7, 2026. Platform announcements can change. This guide separates published facts from Magnate’s original analysis and preparation advice.
- QBCore — Pinned inventory item issuance code ID card info fields in administrative issuance path; not every possible issuing integration.
- QBCore — qb-inventory documentation Item info, inventory state and integration APIs.
- Cfx — Secure your events Server-side validation of client-triggered actions.
Published by an independent editorial brand. Read our editorial standards.
