Zum Inhalt springen

QR-Check-in entwickeln, ohne dauerhaft Pässe zu speichern

Ein QR-Code ist einfach. Schwieriger ist es, den Link als Zugangsdaten zu behandeln, erkannte Angaben zu prüfen und Dokumente zu löschen, sobald sie nicht mehr benötigt werden.

Aktualisiert · Von

Die einfache Hälfte

Ein QR-Code enthält eine URL zum Portal einer Buchung. Der Gast wählt die Sprache, ergänzt Angaben, lädt bei Bedarf Dokumente hoch und unterschreibt. Derselbe Ablauf kann über einen Link in E-Mail oder Messenger geöffnet werden.

Ein Link ist eine Zugangsberechtigung

Wer den Link besitzt, erreicht private Informationen. Das Token muss zufällig, sicher gespeichert, zeitlich begrenzt und widerrufbar sein. Es darf weder aus einer vorhersehbaren Buchungsnummer bestehen noch Zugriff auf andere Buchungen geben. Wiederholte Versuche brauchen Begrenzungen.

Die schwierige Hälfte: Dokumente löschen

Ein Passfoto kann für Erkennung und Prüfung nötig sein, sollte aber nicht aus Bequemlichkeit dauerhaft gespeichert werden. Strukturierte Daten mit Aufbewahrungspflicht müssen von der temporären Aufnahme getrennt werden. Nach erfolgreicher Verarbeitung wird die Bilddatei vernichtet.

Die Boris-Rezeption mit Ankünften und Abreisen des Tages sowie einer Check-in-Aktion je Buchung
Self-Service erreicht nie alle Gäste; der Empfang braucht einen Ablauf, der dieselben Datensätze erzeugt.

Erkennung ist Hilfe, keine Wahrheit

OCR kann Name, Datum, Nummer und Nationalität vorschlagen. Gast oder Team müssen die Werte vor dem Speichern bestätigen. Dokumentformate, mehrdeutige Zeichen und fehlende Felder machen einen Konfidenzwert noch nicht zu einer rechtlich verlässlichen Angabe.

Was der Empfang weiterhin bearbeiten muss

Unlesbare Dokumente, Minderjährige, Gruppen, Gäste ohne Smartphone und Anreisen ohne Link bleiben. Der manuelle Ablauf muss dieselben Datensätze und Pflichten erzeugen wie Self-Service, sonst entstehen zwei inkompatible Check-in-Welten.

Hintergrundjobs gehören zum Produkt

Die Queue versendet Einladungen, gleicht Zahlungen mit verlorenen Webhooks ab, wiederholt Meldungen und löscht temporäre Dateien. Der gefährlichste Fehler ist still: Links werden nicht versandt und Fotos nicht gelöscht, obwohl keine Oberfläche sichtbar kaputt ist.

Häufige Fragen

Braucht ein Gast ein Konto für das Online-Check-in?

Nein. Eine Registrierung vor dem Check-in zu verlangen, hebt den Zweck auf. Die Sitzung wird über ein Token pro Buchung adressiert, das nach Ende des Aufenthalts noch kurz gültig bleibt – damit der Gast die Quittung holen kann – und dann verfällt.

Reicht ein nicht erratbarer Link als Sicherheit?

Der Link ist ein Zugangsmittel und wird auch so behandelt. Zuerst Rate-Limiting, denn Dokumentenscan und Feldvorschläge sind die teuren und zugleich lohnendsten Ziele für Missbrauch – in Boris zwölf Scans pro Gast in einem Ein-Stunden-Fenster. Außerdem müssen Token in großer Zahl widerrufbar sein, als bewusste, nachvollziehbare Operation, damit offengelegte Links auf einmal ungültig werden.

Was geschieht danach mit dem Passfoto?

Es wird vernichtet. Ist der Aufenthalt gemeldet, entfällt die Rechtsgrundlage für das Bild, und es „sicherheitshalber“ zu behalten, ist eine unrechtmäßige Aufbewahrung, die aus einer Routinefunktion das Schädlichste in der Datenbank macht, sollte sie je offengelegt werden. Boris löscht Datei und Datensatz bei erfolgreicher Meldung – und um 23:59 am Anreisetag ohnehin, ohne Schalter, denn ein Schalter wäre die Aufforderung, Pässe zu sammeln.