Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Pengantar
Kode batang yang berputar terlihat seperti kode batang
biasa tetapi berubah secara berkala,
biasanya setiap menit, dan terminal/pembaca diprogram agar hanya menerima
yang terbaru. Langkah keamanan ini mengurangi
risiko yang terkait dengan
tangkapan layar kode batang, khususnya pencurian tiket atau tiket tidak sah
penjualan kembali. Memutar kode batang juga dapat bertindak sebagai
penggantian perangkat yang tidak dapat
memanfaatkan Smart Tap, karena tidak mendukung NFC (kurangnya perangkat keras, atau
software dinonaktifkan).
Pada perangkat pengguna, hanya satu mekanisme
penukaran yang digunakan pada waktu tertentu,
tergantung cara {i>pass <i}dikonfigurasi
dan kemampuan perangkat.
Dalam urutan prioritas, jenis penukaran berikut digunakan:
Smart Tap: Jika payload smart-tap ditentukan dan jika perangkat mendukung
NFC/HCE
Perhatikan, ini dapat diganti oleh pengguna dengan
mengklik "{i>Show code<i}", yang
akan memaksa tampilan kode batang/kode batang statis yang berputar.
Kode batang berputar: Jika payload kode batang berputar ditentukan
Kode batang statis: Jika payload kode batang ditentukan
Menentukan beberapa payload penukaran dapat memastikan semua pengguna didukung, tetapi
mungkin memiliki implikasi keamanan. Secara khusus, menggunakan{i>
code<i} statis sebagai
untuk kode batang yang berputar meniadakan sebagian besar manfaat keamanan dari penggunaan
kode batang berputar. Penggantian kode batang statis hanya akan ditampilkan dalam tampilan web
atau pada klien yang tidak mendukung
pengubahan kode batang. Mulai hari ini, kami memperkirakan
semua klien Google Wallet untuk mendukung rotasi kode batang.
Simpan Alur
Google Wallet API menawarkan beberapa alur, termasuk:
Membuat kelas loyalitas pada waktu yang tepat, atau lebih awal
Mengirim objek lengkap di JWT Anda, atau menyimpan objek sebelum
waktu, kemudian mereferensikannya berdasarkan ID di JWT Anda
Memperbarui objek setelah disimpan
Isian {i>rotatingBarcode<i} yang diusulkan
kompatibel dengan semua alur ini,
Namun, untuk meningkatkan keamanan, sebaiknya lakukan hal berikut:
Memanggil object:insert API untuk menyisipkan kartu ke
Server Google Wallet dan konfigurasikan tombol Tambahkan ke Google Wallet untuk
merujuk ke objek tertentu berdasarkan ID di JWT Anda. Hal ini memastikan bahwa
JWT yang dihasilkan tidak menyertakan kunci rahasia dari kode batang yang berputar.
Gunakan kunci rahasia OTP yang dicakupkan ke satu penerusan
Kunci tersebut, kecuali jika diperbarui, diharapkan valid selama masa aktif
{i>pass <i}itu. Kami tidak mengharapkan kunci ini diperbarui pada frekuensi apa pun selama
jalannya operasi secara normal.
Diagram urutan berikut mengilustrasikan alur antara berbagai aktor
untuk integrasi standar:
[null,null,["Terakhir diperbarui pada 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:"]]
