Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Introdução
Os códigos de barras rotativos são semelhantes aos normais, mas mudam com frequência periódica,
normalmente a cada minuto, e o terminal/leitor é programado para aceitar
apenas o código mais recente. Essa medida de segurança reduz os riscos associados
Captura de tela com código de barras, especificamente em caso de roubo ou não autorização da passagem
revenda. Os códigos de barras rotativos também podem funcionar como um substituto para dispositivos que não conseguem
usar o Toque inteligente porque não têm suporte para NFC (por falta de hardware ou
software desativado).
Referência da API
Para ver detalhes técnicos sobre códigos de barras rotativos, consulte a
Tipo RotatingBarcode.
No dispositivo do usuário, somente um mecanismo de resgate é usado por vez,
dependendo de como o cartão está configurado e dos recursos do dispositivo.
Em ordem de prioridade, os seguintes tipos de resgate são usados:
Toque inteligente: se um payload de toque inteligente for especificado e se o dispositivo oferecer suporte
NFC/HCE
Isso pode ser substituído pelo usuário clicando em "Mostrar código", que
forçará a exibição do código de barras rotativo/estático.
Código de barras rotativo: se um payload de código de barras rotativo for especificado
Código de barras estático: se um payload de código de barras for especificado
Especificar vários payloads de resgate é uma forma de garantir que haja suporte para todos os usuários, mas
isso pode gerar implicações de segurança. Mais especificamente, o uso de um código de barras estático como
um código de barras rotativo, por sua vez, anula a maioria dos benefícios de segurança
códigos de barras rotativos. Um código de barras estático substituto só vai aparecer nas visualizações da Web
ou em clientes que não suportam códigos de barras rotativos. A partir de hoje, esperamos
todos os clientes da Carteira virtual do Google para oferecer suporte a códigos de barras rotativos.
Salvar fluxo
A API Google Wallet oferece vários fluxos, incluindo:
Criar classes de vale-presente no horário salvo ou com antecedência
Enviar objetos completos no JWT ou salvá-los com
antecedência e depois se referir a eles pelo ID no JWT
Atualizar os objetos depois de salvá-los
O campo generateBarcode proposto é compatível com todos esses fluxos,
No entanto, para melhorar a segurança, sugerimos o seguinte:
Chame a API object:insert para inserir o cartão no
servidor da Carteira do Google e configure o botão "Adicionar à Carteira do Google" para
fazer referência ao objeto específico por ID no JWT. Isso garante que o
O JWT resultante não inclui a chave secreta do código de barras rotativo.
Use uma chave secreta de OTP com escopo para um único cartão
A menos que seja atualizada, espera-se que a chave seja válida durante a vida útil do
o passe. Não esperamos que essa chave seja atualizada em qualquer frequência durante
o curso da operação normal.
O diagrama de sequência a seguir ilustra o fluxo entre os vários atores
para uma integração típica:
[null,null,["Última atualização 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:"]]
