Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Introduction
Les codes-barres rotatifs ressemblent à
des codes-barres normaux, mais changent régulièrement,
généralement toutes les minutes, et le terminal/lecteur est programmé pour n'accepter
la plus récente. Cette mesure de sécurité réduit les risques
capture d'écran de codes-barres, en particulier lors d'un vol de ticket ou d'un ticket non autorisé
la revente. Les codes-barres rotatifs peuvent également servir de solution de secours pour les appareils qui ne peuvent pas
utiliser Smart Tap, car il n'est pas compatible NFC (manque de matériel ou
logiciel désactivé).
Documentation de référence de l'API
Pour plus d'informations techniques sur la rotation des codes-barres, reportez-vous à la
Type RotatingBarcode.
Sur l'appareil de l'utilisateur, un seul mécanisme d'utilisation est utilisé à la fois,
en fonction de la configuration de la carte et des capacités de l'appareil.
Les types d'utilisation sont les suivants (par ordre de priorité) :
Smart Tap: si une charge utile Smart Tap est spécifiée et si l'appareil prend en charge
NFC/HCE
<ph type="x-smartling-placeholder">
</ph>
Notez que l'utilisateur peut la modifier en cliquant sur "Afficher le code",
force l'affichage du code-barres rotatif/statique.
Code-barres rotatif: si une charge utile de code-barres rotatif est spécifiée
Code-barres statique: si une charge utile de code-barres est spécifiée
La spécification de plusieurs charges utiles permet de garantir que tous les utilisateurs sont pris en charge, mais
peut avoir des conséquences sur la sécurité. En particulier, l'utilisation d'un code-barres statique
une solution de remplacement pour un code-barres rotatif annule la plupart des avantages de sécurité liés à l'utilisation
des codes-barres rotatifs. Les codes-barres statiques de remplacement ne s'affichent que dans les vues Web
ou sur des clients qui ne prennent
pas en charge les codes-barres rotatifs. À ce jour, nous prévoyons
tous les clients Google Wallet sont compatibles avec les codes-barres rotatifs.
Enregistrer le flux
L'API Google Wallet propose plusieurs flux, y compris:
Créer les classes génériques au moment de la sauvegarde ou à l'avance
Envoyer les objets complets dans votre JWT ou enregistrer les objets avant
puis en les référençant par ID dans votre jeton JWT
Mettre à jour les objets après leur enregistrement
Le champ "rotatingBarcode" proposé est
compatible avec tous ces flux,
Toutefois, pour améliorer la sécurité, nous vous suggérons de procéder comme suit:
Appelez l'API object:insert pour insérer la carte dans la
serveur Google Wallet et configurez le bouton "Ajouter à Google Wallet" pour
référencer l'objet spécifique par son ID dans votre jeton JWT. Cela permet de s'assurer
Le JWT obtenu n'inclut pas la clé secrète du code-barres rotatif.
Utilisez une clé secrète OTP limitée à une seule carte.
À moins qu'elle ne soit mise à jour, la clé doit être valide pendant la durée de vie
la carte. Cette clé ne devrait pas être mise à jour selon une fréquence donnée pendant
au cours du fonctionnement normal.
Le schéma séquentiel suivant illustre le flux entre les différents acteurs
pour une intégration classique:
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/29 (UTC).
[null,null,["Dernière mise à jour le 2025/08/29 (UTC)."],[[["\u003cp\u003eRotating barcodes enhance security by changing periodically, mitigating risks like ticket theft and unauthorized resale, serving as an alternative to Smart Tap for devices lacking NFC capabilities.\u003c/p\u003e\n"],["\u003cp\u003eDevices prioritize redemption methods in the order of Smart Tap, Rotating Barcode, and then Static Barcode, with users having the option to override Smart Tap and display the barcode.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, it's recommended to utilize the \u003ccode\u003eobject:insert\u003c/code\u003e API for pass creation, employ pass-specific OTP secret keys, and acknowledge that these keys are typically valid for the pass's lifespan.\u003c/p\u003e\n"],["\u003cp\u003eRotating barcodes function by encoding a time-based one-time password (TOTP) within the barcode, requiring the scanning device to validate it against the current time, thereby ensuring only the latest barcode is accepted.\u003c/p\u003e\n"]]],["Rotating barcodes, which change periodically (e.g., every minute), enhance security by preventing screenshot misuse and ticket theft. They serve as a fallback for devices lacking NFC capabilities. The API uses a `RotatingBarcode` type with details like algorithm, period, and parameters. Redemption mechanisms prioritize Smart Tap, then rotating barcodes, and lastly, static barcodes. For security, it's recommended to use the `object:insert` API and an OTP secret key unique to each pass and avoid using static barcodes as fallback.\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/generic/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 generic 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:"]]
