Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Introducción
La rotación de códigos de barras se parece a los códigos de barras normales, pero cambian periódicamente.
normalmente cada minuto, y el terminal o lector está programado para solo aceptar
el más reciente. Esta medida de seguridad reduce los riesgos asociados
Captura de pantalla del código de barras, en particular el robo de tickets o los tickets no autorizados
la reventa. La rotación de códigos de barras también puede servir como resguardo en dispositivos que no pueden
aprovechar el Toque inteligente, ya que no es compatible con NFC (falta de hardware o
el software o el software malicioso).
Referencia de la API
Para obtener detalles técnicos acerca de la rotación de códigos de barras, consulta la
Tipo de RotatingBarcode.
En el dispositivo del usuario, solo se usa un mecanismo de canje por vez,
según cómo esté configurado el pase y las capacidades del dispositivo.
En orden de prioridad, se usan los siguientes tipos de canje:
Toque inteligente: Si se especifica una carga útil de toque inteligente y si el dispositivo es compatible
NFC/HCE
Ten en cuenta que el usuario puede anular esta acción haciendo clic en “Mostrar código”,
forzará la visualización del código de barras rotativo o estático.
Código de barras rotativo: si se especifica una carga útil de código de barras que rota
Código de barras estático: si se especifica una carga útil de código de barras
Especificar varias cargas útiles de canje puede garantizar que todos los usuarios sean compatibles, pero
pueden tener implicaciones de seguridad. En particular, el uso de un código de barras estático
como resguardo de un código de barras rotativo, anula la mayoría de los beneficios de usar
rotar códigos de barras. Solo se mostrará un resguardo de código de barras estático en las vistas web.
o en clientes que no admiten la rotación de códigos de barras. A partir de hoy, esperamos
a todos los clientes de la Billetera de Google para admitir códigos de barras rotativos.
Guardar flujo
La API de la Billetera de Google ofrece varios flujos, incluidos los siguientes:
Crear las clases genéricas en un momento oportuno o con anticipación
Enviar los objetos completos en tu JWT o guardar los objetos antes de
tiempo y luego hacer referencia a ellas por ID en tu JWT
Actualiza los objetos después de guardarlos
El campo rotarBarcode propuesto
es compatible con todos estos flujos
Sin embargo, para mejorar la seguridad, sugerimos lo siguiente:
Llama a la API de object:insert para insertar el pase en el
servidor de Google Wallet y configura el botón Agregar a la Billetera de Google para
hacer referencia al objeto específico por ID en tu JWT. Esto garantiza que el
El JWT resultante no incluye la clave secreta del código de barras rotativo.
Usa una clave secreta de OTP que se limite a un solo pase
A menos que se actualice, se espera que la clave sea válida durante toda la vida útil
el pase. No esperamos que esta clave se actualice con ninguna frecuencia durante
el curso de las operaciones normales.
El siguiente diagrama de secuencia ilustra el flujo entre los distintos actores
para una integración típica:
[null,null,["Última actualización: 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:"]]
