Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Einführung
Rotierende Barcodes sehen wie normale Barcodes aus, ändern sich jedoch regelmäßig.
in der Regel jede Minute. Das Terminal/Lesegerät ist so programmiert, dass
die letzte. Durch diese Sicherheitsmaßnahme können Risiken minimiert werden, die mit der Screenshoterstellung von Barcodes einhergehen, insbesondere in Bezug auf den Diebstahl oder den nicht autorisierten Weiterverkauf von Tickets. Rotierende Barcodes können auch als Fallback für Geräte dienen, bei denen
Smart-Bonus nutzen, da sie NFC (fehlende Hardware) nicht unterstützen
Software deaktiviert).
API-Referenz
Technische Details zu rotierenden Barcodes finden Sie unter RotatingBarcode-Typ.
Auf dem Gerät des Nutzers wird jeweils nur ein Einlösungsmechanismus verwendet, je nachdem, wie die Karte bzw. das Ticket konfiguriert ist und welche Funktionen das Gerät hat.
Die folgenden Einlösungsarten werden verwendet (in der Reihenfolge ihrer Priorität):
Smart-Bonus: Wenn eine Nutzlast für Smart-Bonus angegeben ist und das Gerät dies unterstützt
NFC/HCE
Diese Einstellung kann vom Nutzer überschrieben werden, indem er auf „Code anzeigen“ klickt.
erzwingt die Anzeige des rotierenden/statischen Barcodes.
Rotierender Barcode: wenn eine rotierende Barcode-Nutzlast angegeben ist
Statischer Barcode: Wenn eine Barcodenutzlast angegeben ist
Wenn du mehrere Nutzlasten für die Einlösung angibst, können alle Nutzer unterstützt werden. Allerdings hat dies möglicherweise Auswirkungen auf die Sicherheit. Vor allem, wenn ein statischer Barcodes als Fallback für einen rotierenden Barcode verwendet wird, fallen die meisten Sicherheitsvorteile der Verwendung rotierenden Barcodes weg. Ein statischer Barcode als Fallback wird nur in Webansichten oder auf Clients angezeigt, die keine rotierenden Barcodes unterstützen. Heute gehen wir davon aus,
alle Google Wallet-Clients müssen rotierende Barcodes unterstützen.
Ablauf speichern
Die Google Wallet API bietet verschiedene Abläufe. Hierzu gehören:
Geschenkkartenklassen beim Speichern oder im Voraus erstellen
Vollständige Objekte im JWT senden oder Objekte im Voraus speichern und dann durch die ID im JWT darauf verweisen
Objekte nach dem Speichern aktualisieren
Das vorgeschlagene Feld „rotatingBarcode“ ist mit jedem dieser Abläufe kompatibel. Zur Verbesserung der Sicherheit empfehlen wir jedoch Folgendes:
Rufe die object:insert API auf, um die Karte bzw. das Ticket in den
Google Wallet-Server und konfiguriere die Schaltfläche „Zu Google Wallet hinzufügen“, um
im JWT anhand der ID auf das jeweilige Objekt verweisen. Dadurch wird sichergestellt, dass das resultierende JWT nicht den geheimen Schlüssel des rotierenden Barcodes enthält.
Verwenden Sie einen geheimen OTP-Schlüssel für eine einzelne Karte / ein einzelnes Ticket
Wenn der Schlüssel nicht aktualisiert wird, ist er voraussichtlich für die folgende Lebensdauer gültig:
die Karte bzw. das Ticket. Wir erwarten nicht, dass dieser Schlüssel im Laufe
im normalen Geschäftsbetrieb.
Das folgende Sequenzdiagramm veranschaulicht den Fluss zwischen den verschiedenen Akteuren.
für eine typische Integration:
[null,null,["Zuletzt aktualisiert: 2025-08-29 (UTC)."],[[["\u003cp\u003eRotating barcodes enhance security by changing periodically, mitigating risks associated with ticket theft or unauthorized resale.\u003c/p\u003e\n"],["\u003cp\u003eThey serve as a fallback for devices lacking NFC capabilities, ensuring accessibility for all users.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Wallet prioritizes redemption methods with Smart Tap first, followed by rotating barcodes, and lastly static barcodes.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, it's recommended to use the \u003ccode\u003eobject:insert\u003c/code\u003e API to store pass data and reference it by ID in JWTs, avoiding exposure of the rotating barcode's secret key.\u003c/p\u003e\n"],["\u003cp\u003eEach pass should ideally have a unique OTP secret key, remaining valid throughout the pass's lifespan.\u003c/p\u003e\n"]]],["Rotating barcodes change periodically (e.g., every minute) and are accepted only when current by the reader, improving security against screenshotting and ticket theft. They serve as a fallback for devices lacking NFC for Smart Tap. The `RotatingBarcode` type utilizes a TOTP algorithm with parameters like `algorithm`, `periodMillis`, and `key`. The system prioritizes redemption methods: Smart Tap, then rotating barcode, and lastly, static barcode. For optimal security, passes should be pre-inserted via the `object:insert` API.\n"],null,["# Rotating Barcodes\n\nIntroduction\n------------\n\n\nRotating barcodes look just like regular barcodes but change periodically,\ntypically every minute, and the terminal/reader is programmed to only accept\nthe most recent one. This security measure reduces the risks associated with\nbarcode screenshotting, in particular ticket theft or unauthorized ticket\nresale. Rotating barcodes can also act as a fallback for devices that can't\ntake advantage of Smart Tap, due to not supporting NFC (lack of hardware, or\nsoftware disabled).\n\n### API reference\n\n\nFor technical details about Rotating Barcodes, see the\n[`RotatingBarcode` type](/wallet/retail/gift-cards/rest/v1/RotatingBarcode).\n\n### Example payload\n\n| JSON ||\n|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---|\n| ``` { \"rotatingBarcode\": { \"type\": \"QR_CODE\", \"valuePattern\": \"MyRotatingBarcode-{totp_timestamp_seconds}-{totp_value_0}\", \"alternateText\": \"Ticket#: 1234567890\", \"totpDetails\": { \"algorithm\": \"TOTP_SHA1\", \"periodMillis\": \"3000\", \"parameters\": [ { \"key\": \"3132333435363738393031323334353637383930\", \"valueLength\": \"8\" } ] } } } ``` |\n\nFallback Mechanisms\n-------------------\n\n\nOn the user device, only one redemption mechanism is used at a given time,\ndepending on how the pass is configured and on the capabilities of the device.\nIn the order of priority, the following redemption types are used:\n\n1. Smart Tap: If a smart-tap payload is specified and if the device supports NFC/HCE\n - Note, this can be overridden by the user by clicking \"Show code,\" which will force the display of the rotating barcode/static barcode.\n2. Rotating barcode: If a rotating barcode payload is specified\n3. Static barcode: If a barcode payload is specified\n\n\nSpecifying multiple redemption payloads can ensure all users are supported but\nmay have security implications. In particular, using a static barcode as a\nfallback for a rotating barcode negates most of the security benefits of using\nrotating barcodes. A static barcode fallback will only be shown in web views\nor on clients that do not support rotating barcodes. As of today, we expect\nall Google Wallet clients to support rotating barcodes.\n\nSave Flow\n---------\n\nThe Google Wallet API offers several flows, including:\n\n- Creating the gift card classes at save time, or ahead of time\n- Sending the complete objects in your JWT, or saving the objects ahead of time then referencing them by ID in your JWT\n- Updating the objects after they have been saved\n\n\nThe proposed rotatingBarcode field is compatible with all these flows,\nhowever, in order to improve security, we suggest the following:\n\n- Call the `object:insert` API to insert the pass to the Google Wallet server and configure the Add to Google Wallet button to reference the specific object by ID in your JWT. This ensures that the resulting JWT does not include the secret key of the rotating barcode.\n- Use an OTP secret key that is scoped to a single pass\n- The key, unless it is updated, is expected to be valid for the lifespan of the pass. We do not expect this key to be updated on any frequency during the course of normal operation.\n\n\nThe following sequence diagram illustrates the flow between the various actors\nfor a typical integration:"]]
