회전 바코드는 일반 바코드처럼 보이지만 주기적으로 변경되므로
단말기/판독기는
표시됩니다. 이 보안 조치는 Tresite와 관련된 위험을
바코드 스크린샷, 특히 티켓 도용 또는 무단 티켓
재판매. 회전 바코드는
NFC를 지원하지 않기 때문에 (하드웨어 장치 부족,
사용하지 않습니다.
사용자 기기에서 한 번에 하나의 쿠폰 사용 메커니즘만 사용됩니다.
패스 구성 방식과 기기의 기능에 따라 다릅니다.
우선순위에 따라 다음과 같은 사용 유형이 사용됩니다.
스마트 탭: 스마트 탭 페이로드가 지정되어 있고 기기에서
NFC/HCE
<ph type="x-smartling-placeholder">
</ph>
이 작업은 사용자가 '코드 표시'를 클릭하여 재정의할 수 있습니다.
를 누르면 회전하는 바코드/정적 바코드가 강제로 표시됩니다.
회전 바코드: 순환 바코드 페이로드가 지정된 경우
정적 바코드: 바코드 페이로드가 지정된 경우
여러 개의 쿠폰 사용 페이로드를 지정하면 모든 사용자를 지원할 수 있지만
보안에 영향을 미칠 수 있습니다. 특히 정적 바코드를
교체 바코드를 대체하는 대신 기존 시스템 사용 시 얻을 수 있는 대부분의 보안 이점은
회전시킬 수 있습니다. 정적 바코드 대체는 웹 보기에만 표시됩니다.
클라이언트와 상호작용할 수 있습니다. 현재
모든 Google 지갑 클라이언트에서 순환 바코드를 지원할 수 있습니다.
흐름 저장
Google Wallet API는 다음과 같은 몇 가지 흐름을 제공합니다.
저장 시간에 또는 미리 포인트 클래스 만들기
JWT에서 전체 객체를 전송하거나 다음 객체 이전에 객체를 저장
JWT에서 ID로 참조하기만 하면 됩니다.
저장된 후 객체 업데이트
제안된 회전Barcode 필드는 이러한 모든 흐름과 호환됩니다.
하지만 보안을 강화하기 위해 다음과 같은 조치를 취할 것을 권장합니다.
object:insert API를 호출하여
Google 월렛 서버에 추가 버튼을 구성하여
JWT에서 ID로 특정 객체를 참조합니다. 이렇게 하면
결과 JWT에는 순환 바코드의 보안 키가 포함되지 않습니다.
단일 패스로 범위가 지정된 OTP 보안 비밀 키를 사용하세요.
키는 업데이트되지 않는 한
있습니다. 다음 기간 중에 이 키가 자주 업데이트되지는 않습니다.
작동한다는 것입니다.
다음 시퀀스 다이어그램은 다양한 행위자 간의 흐름을 보여줍니다.
일반적인 통합의 경우는 다음과 같습니다.
[null,null,["최종 업데이트: 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: Smart Tap, Rotating Barcode, then Static Barcode, with user override option.\u003c/p\u003e\n"],["\u003cp\u003eFor optimal security, utilize the \u003ccode\u003eobject:insert\u003c/code\u003e API to prevent exposing the rotating barcode's secret key in the JWT.\u003c/p\u003e\n"],["\u003cp\u003eRotating barcodes are expected to be supported by all Google Wallet clients.\u003c/p\u003e\n"]]],["Rotating barcodes change periodically (e.g., every minute) and are accepted only when current, mitigating risks like ticket theft. They serve as a backup for devices lacking NFC for Smart Tap. The API uses a `RotatingBarcode` type with parameters like QR code type, value pattern, and TOTP details (algorithm, period, parameters). Multiple redemption methods (Smart Tap, rotating barcode, static barcode) prioritize based on device capabilities. For security, it is suggested to call the 'object:insert' API, use an OTP secret key that is scoped to a single pass, and refer to the specific object by ID in the JWT.\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/loyalty-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 loyalty 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:"]]