Translate Hotel Keycard and Mobile Key Messages Correctly

How do you translate hotel keycard and digital-key notices accurately when an unfamiliar word could change what a person pays, may do, must provide or has already completed? The short answer is to identify the responsible party, the recorded event, its current state, each condition and the next authorised action before choosing words in the target language. In this guide, a guest, receptionist, accommodation operator or translator needs to know which door a particular credential can open, when, and whether access was actually granted.

People searching for hotel key card not working translation, digital hotel room key activation message, mobile room key pending meaning, hotel door access denied, keycard expiry notice need an answer that preserves the notice’s legal or operational effect rather than a fluent sentence that quietly changes it. The most dangerous mistranslations turn ‘submitted’ into ‘approved’, erase a restriction, shift a time, or transform an equipment condition into a result. This article gives a practical reader-first method, fully worked meaning checks, failure analysis and exercises, not a substitute for the issuing authority’s decision.

The translation problem is not just vocabulary. It is the relationship between people, objects, dates, evidence, conditions and decision states. The canonical job is access-credential status, door scope and expiry, not booking confirmation, minibar payment or room-cleaning readiness already covered elsewhere in this series. We use fictional teaching examples to make errors visible, not to impersonate a real notice or promise any outcome. Always use the latest notice from the named authority or provider where instructions, fees or rules vary by place and date.

The quick answer: what to check before trusting a translated notice

Who issued it, and can the reader verify the issuer through a known official channel?
What person, account, device, credential or vehicle does it concern?
What exactly happened, and what is merely requested, pending or expected?
Which dates, amounts, units, locations and category codes control its effect?
What must the reader do now, and what event would confirm that the next stage is complete?
Which uncertainties and limitations must remain visible rather than be silently resolved by the translator?

The problem underneath the words

A hotel reservation, check-in status, room assignment, physical keycard, mobile key credential, compatible lock and successful door opening are distinct states. A translated message can describe them accurately only if it respects the boundary between a right to ask for access, a credential being issued and a particular door actually unlocking.

Consider a message with a familiar word such as ‘confirmed’. Confirmation may refer to receiving a file, recording a transaction, booking an appointment or issuing a final decision. A translation must identify the object of confirmation. If that object is omitted, the sentence sounds helpful while becoming false. The person reading it may act on permission they do not have or fail to take an action that remains open.

A reliable source-to-target transfer begins by writing a short factual statement in the source language: who did what, to which object, at which time, with what condition and with what degree of certainty. When that statement is stable, choose natural target-language sentences that preserve those relationships. Improve fluency afterward, not before. Translation is a controlled reconstruction of meaning, not a contest to replace every source word with a prettier synonym.

First principles: the conceptual map

Principle 1: Identity and scope

A booking confirmation is evidence of a reservation on stated terms, not proof that room access has begun.

For hotel keycard and digital-key notices, the practical test is to ask whether a reader could use the translated sentence as a source of an action the original never authorised. When the answer is yes, the translated sentence has crossed its evidence boundary. Replace the assertion with an exact status label, retain the original field identifier if it cannot be safely localised, and say which authority can verify the missing fact.

Principle 2: Events and their outcomes

A room can be assigned before it is ready. Similarly, an app can allow a key request before its digital credential has been issued.

Principle 3: Time and effect

A keycard may be encoded for one room and selected shared facilities. It should not be described as a universal hotel pass.

Principle 4: Codes, units and evidence

A mobile key may depend on the named stay, device, hotel policy and local check-in conditions. Bluetooth, NFC and network state can be part of the experience without granting access by themselves.

Principle 5: Authority and obligations

The words ‘issued’, ‘downloaded’, ‘ready’, ‘activated’, ‘revoked’, ‘expired’ and ‘used’ represent different credential lifecycle events.

Principle 6: Conditional rights and next states

Security-sensitive messages should not expose room numbers, access codes, personal details or staff-only workarounds beyond the legitimate recipient.

A repeatable twelve-step translation method

Use the following sequence on a screenshot, printed notice, translated email, website prompt or app alert. Each step creates a small record that another reviewer can inspect. Unlike an informal read-through, this method exposes source omissions before they become reader-facing errors. It is intentionally slower for messages where a single mistaken verb changes liability, safety, access or eligibility.

Step 1: Verify the issuer

Identify whether the message is from the hotel, booking provider, lock, mobile app or guest support team.

Record the source phrase, the target phrase and the evidence for the equivalence. Do not approve the paragraph merely because its grammar is smooth. Ask a reviewer to describe the same step without looking at the source. If they cannot tell what has happened and what remains conditional, revise until the dependency is explicit. Keep an audit note for any assumption you deliberately refused to make.

Step 2: Identify the subject

Separate reservation number, guest name, room number, property name and key identifier; preserve restricted information securely.

Step 3: Map the dates

Record the hotel’s local check-in date and check-out cutoff rather than assuming a universal 24-hour window.

Step 4: Name the event

Identify which action is described: request, identity check, issue, activation, presentation to lock, unlock or revocation.

Step 5: Preserve amounts and units

Distinguish the physical keycard from the mobile digital credential; do not merge their troubleshooting steps.

Step 6: Decode terms and categories

Keep door and facility scope exact, including lift floors, side entrances and shared amenities where described.

Step 7: Capture the status

Preserve device and technology requirements as requirements, not guarantees that any phone will work.

Step 8: Preserve deadlines

Translate offline and connectivity messages without suggesting that a failed app connection means the door lock is unsafe.

Step 9: Carry conditions

Handle shared keys as delegated credentials: request, invitation, acceptance and revocation must remain distinct.

Step 10: Separate response routes

Route guest identification, unexpected lockouts and room changes back to the hotel’s authenticated staff.

Step 11: Check trust and privacy

Check time-sensitive messages for start, expiry and same-day changes, particularly around early arrival and late checkout.

Step 12: Perform a reader readback

Read the translation as a guest: can they tell whether to wait, retry a permitted method or contact reception?

Worked examples: source message, tempting mistake and safer meaning

All examples below are invented for learning. The quoted source message is a compact English rendering of the kind of notice a translator might receive; the safer version is a meaning-control anchor that can then be expressed naturally in any target language. The contrast is the teaching device. It does not claim to be a certified translation for a particular language pair or institution.

Worked example 1: Room selection confirmed

Source notice: “Room selection confirmed.” A risky rendering would suggest: “Your room is open now.” The safer meaning-controlled rendering is: “Your room selection is confirmed; access timing is not yet stated.”

Why the distinction matters: Choosing a room in an app is distinct from the hotel’s readiness check and key delivery. Do not turn allocation into physical access. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Translation check: identify the actor and the state verb in the source. Then underline every extra promise, accusation, amount, deadline or permission in the candidate translation. Remove information that cannot be traced to the source; if a missing detail matters for the next action, retain the uncertainty and point to the proper official verification route. The right translation remains useful even when the underlying record is incomplete.

Worked example 2: Digital key requested

Source notice: “Digital key requested.” A risky rendering would suggest: “Digital key received.” The safer meaning-controlled rendering is: “The mobile key has been requested.”

Why the distinction matters: A guest request may still be awaiting identity verification or room readiness. Preserve request and delivery as separate states. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 3: Digital key ready

Source notice: “Digital key ready.” A risky rendering would suggest: “The door has already been unlocked.” The safer meaning-controlled rendering is: “A mobile key is ready for use under the listed conditions.”

Why the distinction matters: Credential availability is not a record of a door-opening event. Keep status separate from actual entry. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 4: Identity check required at reception

Source notice: “Identity check required at reception.” A risky rendering would suggest: “Skip the front desk.” The safer meaning-controlled rendering is: “The guest must complete the stated identity check at reception.”

Why the distinction matters: A contactless hotel option may still require an in-person identity step for some reservations. Keep the actual check-in requirement. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 5: Keycard encoding in progress

Source notice: “Keycard encoding in progress.” A risky rendering would suggest: “Your keycard has been activated.” The safer meaning-controlled rendering is: “The keycard is being prepared.”

Why the distinction matters: Encoding is a process state; successful completion and valid access are later states. Do not mark a process complete early. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 6: Card reader flashed red

Source notice: “Card reader flashed red.” A risky rendering would suggest: “The card has been permanently revoked.” The safer meaning-controlled rendering is: “The reader did not grant access at that attempt.”

Why the distinction matters: A red indicator may have multiple causes and should not be over-interpreted as a security verdict. Translate observed behaviour and official error code. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 7: Mobile key unavailable while device is offline

Source notice: “Mobile key unavailable while device is offline.” A risky rendering would suggest: “Your booking was cancelled.” The safer meaning-controlled rendering is: “The mobile key cannot currently be retrieved on this device in the described condition.”

Why the distinction matters: Device connectivity and reservation status are different systems. Preserve the device-side explanation only. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 8: Bluetooth permission denied

Source notice: “Bluetooth permission denied.” A risky rendering would suggest: “You have been denied entry by staff.” The safer meaning-controlled rendering is: “The app lacks the stated Bluetooth permission.”

Why the distinction matters: A device setting can prevent a digital-key operation without a hotel access decision. Specify the device setting. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 9: NFC not supported on this model

Source notice: “NFC not supported on this model.” A risky rendering would suggest: “Your room is unavailable.” The safer meaning-controlled rendering is: “This device does not support the named contactless feature.”

Why the distinction matters: Hardware compatibility is not room availability or booking validity. Name the unsupported feature. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 10: Key shared; invitation pending

Source notice: “Key shared; invitation pending.” A risky rendering would suggest: “Companion can enter now.” The safer meaning-controlled rendering is: “A key-sharing invitation is pending acceptance.”

Why the distinction matters: A share request may need another person to accept and meet hotel conditions. Preserve pending invitation state. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 11: Shared key revoked

Source notice: “Shared key revoked.” A risky rendering would suggest: “Booking cancelled for all guests.” The safer meaning-controlled rendering is: “The previously shared credential was revoked.”

Why the distinction matters: Revoking one credential may not change the primary guest’s reservation. Name which user’s credential changed. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 12: Key expires 11:00 local time

Source notice: “Key expires 11:00 local time.” A risky rendering would suggest: “Key lasts until midnight.” The safer meaning-controlled rendering is: “The credential expires at 11:00 in the property’s local time.”

Why the distinction matters: A standard checkout convention must not replace the listed cutoff. Keep exact hour and local time. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 13: Late checkout requested

Source notice: “Late checkout requested.” A risky rendering would suggest: “Key extension confirmed.” The safer meaning-controlled rendering is: “A late checkout was requested.”

Why the distinction matters: An extension is effective only when granted, and key access may need separate updating. Keep request, approval and key status distinct. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 14: Late checkout approved until 14:00

Source notice: “Late checkout approved until 14:00.” A risky rendering would suggest: “Every shared key works until 14:00.” The safer meaning-controlled rendering is: “The stay was extended to 14:00 under the stated approval.”

Why the distinction matters: Approval of the stay may not update every credential simultaneously. Check scope of credential extension. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 15: Guest moved to another room

Source notice: “Guest moved to another room.” A risky rendering would suggest: “Old key opens the new room.” The safer meaning-controlled rendering is: “The room assignment changed; updated access may be required.”

Why the distinction matters: Room moves can invalidate prior credentials. Translation should not imply a handoff was completed. Preserve changed room and next required action. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 16: Physical keycard replacement issued

Source notice: “Physical keycard replacement issued.” A risky rendering would suggest: “Two valid cards still exist.” The safer meaning-controlled rendering is: “A replacement card was issued.”

Why the distinction matters: A replacement can coexist with or deactivate a previous card according to hotel policy. Do not infer what happens to the old credential. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 17: Door lock battery service required

Source notice: “Door lock battery service required.” A risky rendering would suggest: “Guest is not authorised.” The safer meaning-controlled rendering is: “The lock has a reported maintenance condition.”

Why the distinction matters: Equipment status and guest entitlement are different, so avoid blaming the guest. Refer equipment issues to hotel staff. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 18: Common-area access enabled

Source notice: “Common-area access enabled.” A risky rendering would suggest: “All hotel facilities are included.” The safer meaning-controlled rendering is: “The credential is enabled for the listed shared areas.”

Why the distinction matters: A pass may operate a lift but not a gym, car park or private floor. Preserve the enumerated access zones. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 19: Lift requires a valid floor credential

Source notice: “Lift requires a valid floor credential.” A risky rendering would suggest: “The lift is broken.” The safer meaning-controlled rendering is: “The lift requires recognised access permission for that floor.”

Why the distinction matters: An access-controlled lift is not necessarily out of service. Identify access control as the relevant mechanism. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 20: Key reset scheduled

Source notice: “Key reset scheduled.” A risky rendering would suggest: “You may enter immediately.” The safer meaning-controlled rendering is: “A credential reset is scheduled.”

Why the distinction matters: The future repair event is not a present entry grant. Preserve timing and pending action. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 21: App has downloaded key

Source notice: “App has downloaded key.” A risky rendering would suggest: “Door access tested successfully.” The safer meaning-controlled rendering is: “The digital key data was downloaded to the device.”

Why the distinction matters: Credential download may be completed before any lock has verified it. Keep download and use separate. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 22: Guest has checked out

Source notice: “Guest has checked out.” A risky rendering would suggest: “Room still assigned indefinitely.” The safer meaning-controlled rendering is: “The guest’s stay is recorded as checked out.”

Why the distinction matters: Checkout changes the access context, but does not prove a particular card was physically destroyed. Preserve the completed stay status. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 23: Room number displayed privately

Source notice: “Room number displayed privately.” A risky rendering would suggest: “Post room number in public help thread.” The safer meaning-controlled rendering is: “The app privately displays the guest’s assigned room.”

Why the distinction matters: Room identifiers can be security-sensitive. A translator should not replicate them in public channels. Protect guest-specific information. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 24: A new phone is linked

Source notice: “A new phone is linked.” A risky rendering would suggest: “Old key will transfer automatically.” The safer meaning-controlled rendering is: “The new phone was linked to the hotel account.”

Why the distinction matters: Mobile keys may be device-bound; the hotel may require reissuance. Do not invent seamless credential transfer. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 25: Emergency exit must remain unobstructed

Source notice: “Emergency exit must remain unobstructed.” A risky rendering would suggest: “Use exit as guest shortcut.” The safer meaning-controlled rendering is: “An emergency exit must remain unobstructed and follow posted safety procedures.”

Why the distinction matters: Exit routes and routine access permissions are distinct. Translation must not encourage bypassing security. Preserve life-safety instruction separately. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Worked example 26: Access denied; contact front desk

Source notice: “Access denied; contact front desk.” A risky rendering would suggest: “Force the reader and try again.” The safer meaning-controlled rendering is: “The attempt was denied; contact hotel staff for authorised assistance.”

Why the distinction matters: A denial requires a legitimate support route, not technical bypass instructions. Do not provide ways around access controls. The apparent convenience of the risky version is exactly the problem: it answers a question that the notice did not answer. A target reader may rely on that invented answer when deciding whether to pay, wait, submit evidence, enter a space or pursue a review.

Failure modes and how to repair them

Failure 1: Treating a room-selection success as proof that

Treating a room-selection success as proof that the hotel has released the room.

Repair it by splitting the claim into verified fields and unresolved fields. Preserve the narrow wording that the original supports, and do not fill the missing part with an institutional convention, a plausible technical explanation or the translator’s personal expectation. If the notice is time-sensitive, attach the exact version and time checked; otherwise a once-correct translation may become incorrect after a status update.

Failure 2: Conflating the booking reference with a credential

Conflating the booking reference with a credential identifier or physical keycard number.

Failure 3: Translating a device-permission error as a refusal

Translating a device-permission error as a refusal by hotel staff.

Failure 4: Inventing a guaranteed check-in or late-checkout entitlement

Inventing a guaranteed check-in or late-checkout entitlement based on a request screen.

Failure 5: Leaving out the local time zone or

Leaving out the local time zone or exact expiry of a temporary key.

Failure 6: Publishing a guest’s room number, temporary code

Publishing a guest’s room number, temporary code or identity proof in a public troubleshooting example.

Failure 7: Assuming shared mobile keys are automatically active

Assuming shared mobile keys are automatically active and never subject to revocation.

Failure 8: Suggesting bypass steps for a locked door

Suggesting bypass steps for a locked door rather than authorised hotel assistance.

Guided practice: learn to transfer the method

Exercise 1: Translate a key-request confirmation so it cannot be mistaken for key issuance.

First write the source fact as a one-line claim, then draft a reader-friendly target version. Create a second line headed ‘Not established by this message’ and list the conclusion that a careless reader could wrongly draw. Finally write the action that would obtain the missing evidence. Your practice succeeds when another person can act on the translated statement without interpreting a request as an approval or an estimate as a guaranteed outcome.

Exercise 2: Distinguish app download, credential activation and successful door opening.

Exercise 3: Rewrite a reception identity-check instruction without implying digital check-in failed.

Exercise 4: Create a guest-facing explanation of Bluetooth permission denial without diagnosing the lock.

Exercise 5: Translate a shared-key invitation where acceptance is still pending.

Exercise 6: Compare late-checkout approval with a separate mobile-key expiration message.

Exercise 7: Correct a public support transcript that accidentally includes a room number.

Exercise 8: Explain why a red lock-reader light does not prove a booking was cancelled.

How to audit a completed translation before release

Use two passes. The semantic pass reads names, identifiers, numbers, scope, dates, actor, modality and state transitions against the source. The usability pass reads the target without the source and checks whether the reader can distinguish completed actions from expected ones. Both are necessary: a technically faithful translation can still bury the instruction in opaque syntax, while a beautifully simple translation can alter a legal or operational condition.

For a small message, a reviewer can mark the decisive tokens by hand. For a collection of templates, keep a termbase containing the issuer’s official labels, status verbs, field descriptions, approved translations and examples of prohibited paraphrases. Update the termbase when a new version changes policy or product behaviour. A termbase should preserve distinctions such as pending versus settled, ready versus granted, verified versus uploaded and renewed versus merely submitted.

When machine translation or an AI draft is used, compare it to the actual original, not to another paraphrase of the original. Automated output may confidently infer a missing subject, switch a negation or choose a locally familiar regulatory term that the issuing body does not use. Send high-consequence notices for qualified human review, with a way to access the original and contact the actual operator or regulator.

Frequently asked questions

Does a hotel booking confirmation mean my key is active?

No. A reservation, room readiness, check-in and issued key can be separate events. Translate the exact event reported.

The useful rule is to preserve the narrow claim supported by this document, then verify any wider conclusion with the responsible issuer. The translation clarifies an instruction; it cannot replace a separate transaction record, identity decision, contractual approval or regulatory determination.

Is a digital key the same as a keycard?

Both may support door access, but their issuance, device dependence, revocation and facility scope can differ. Keep the distinction visible.

If the app says ‘key ready’, has the room been opened?

No. A ready credential does not prove that the door has accepted it or the guest has entered.

Can a translator say a guest may skip reception?

Only when the property specifically confirms that route for that guest. Some stays require identity checks even with mobile check-in.

Does a red reader light mean my account was blocked?

Not necessarily. It records an unsuccessful interaction or status signal whose cause must be taken from the hotel’s actual system message.

What if a companion receives a shared-key invite?

Preserve whether it is invited, accepted, active or revoked. Do not convert invitation into granted entry.

Will a phone replacement automatically transfer the room key?

Do not assume. Follow the property’s official procedure for device-bound digital credentials.

Should I include room numbers in an explanatory article?

Use invented placeholders. Real credentials and room identifiers should remain in authorised private channels.

Can an approved late checkout change key expiry?

It might, but translation cannot infer the exact key change. Check the source for an explicit credential extension.

Who resolves a lockout?

The property’s authorised front desk or security team. Translation clarifies the notice but does not bypass access control.

Sources, scope and verification

These independently accessible references illustrate real-world workflow and terminology. Policies may change and examples may be jurisdiction-specific. Confirm the current official wording before relying on a fee, legal permission, privacy practice or access status. The teaching examples above are fictional rather than extracted from a private person’s record.

A safe translation does not always supply a satisfying yes or no. Sometimes the accurate result is ‘pending’, ‘not shown’ or ‘ask the issuing authority’. That is useful information: it protects a reader from making a decision using certainty that the source never gave them.

Top Ways to Translate Correctly | Translate Hotel Keycard and Mobile Room-Key Alerts Without Granting Unconfirmed Access