تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
مقدمة
تبدو الرموز الشريطية المتغيّرة تمامًا مثل الرموز الشريطية العادية، ولكنها تتغيّر بشكل دوري،
عادةً كل دقيقة، ويتم برمجة المحطة الطرفية/القارئ لقبول
أحدث رمز فقط. يحد هذا الإجراء الأمني من المخاطر المرتبطة
التقاط لقطة شاشة للرموز الشريطية، ولا سيما سرقة التذاكر أو التذاكر غير المصرّح بها
إعادة البيع. يمكن أيضًا استخدام الرموز الشريطية الدوارة كإجراء احتياطي للأجهزة التي لا يمكنها ذلك
الاستفادة من ميزة "الدفع الذكي" بسبب عدم توافقها مع تقنية NFC (أي عدم توفُّر الأجهزة أو
أو إيقاف البرنامج).
مرجع واجهة برمجة التطبيقات
للاطّلاع على التفاصيل الفنية حول الرموز الشريطية المتغيّرة، يُرجى الاطّلاع على
نوع RotatingBarcode.
على جهاز المستخدم، يتم استخدام آلية واحدة فقط لتحصيل القيمة في وقت معيّن،
يعتمد ذلك على كيفية إعداد البطاقة وإمكانيات الجهاز.
بترتيب الأولوية، يتم استخدام أنواع تحصيل القيمة التالية:
الدفع الذكي: في حال تحديد حمولة الدفع الذكي وما إذا كان الجهاز يتيح
NFC/HCE
تجدر الإشارة إلى أنه يمكن للمستخدم إلغاء هذا الإجراء بالنقر على زر "عرض الرمز" الذي
ستفرض عرض الرمز الشريطي/الرمز الشريطي الثابت الدوران.
رمز شريطي متغيّر: إذا تم تحديد حمولة رمز شريطي متغيّر
رمز شريطي ثابت: إذا تم تحديد حمولة رمز شريطي
يمكن أن يؤدي تحديد عدة حِزم بيانات تحصيل قيمة الرمز إلى ضمان توفّر الرمز لجميع المستخدمين، ولكن
قد يكون لذلك تأثيرات على الأمان. على وجه الخصوص، يؤدي استخدام رمز شريطي ثابت كبديل
لرمز شريطي متغيّر إلى إلغاء معظم مزايا الأمان التي تعود على
استخدام الرموز الشريطية المتغيّرة. لن يظهر الرمز الاحتياطي الثابت للرمز الشريطي إلا في طرق عرض الويب
أو على العملاء الذين لا يتيحون استخدام الرموز الشريطية بالتناوب. اعتبارًا من اليوم، نتوقع أن يصبح استخدام الرموز الشريطية المتغيّرة متاحًا في
جميع عملاء "محفظة Google".
حفظ التدفق
توفّر Google Wallet API العديد من عمليات الربط، بما في ذلك:
إنشاء فئات بطاقات الهدايا في وقت مناسب أو مُسبَق
إرسال العناصر الكاملة في JWT أو حفظ العناصر مسبقًا
ثم الإشارة إليها حسب المعرّف في JWT
تعديل العناصر بعد حفظها
يتوافق الحقل المقترَح rotatingBarcode مع جميع هذه العمليات،
ولكن لتحسين الأمان، نقترح ما يلي:
استخدِم واجهة برمجة التطبيقات object:insert لإدراج البطاقة في
خادم "محفظة Google" وإعداد الزر "إضافة إلى محفظة Google" لتحديد
العنصر المحدّد حسب رقم التعريف في JWT. يضمن ذلك
لا يتضمن JWT الناتج المفتاح السري للرمز الشريطي الدوار.
استخدِم مفتاحًا سريًا لكلمة مرور صالحة لمرة واحدة فقط ومخصّصًا لبطاقة واحدة.
من المتوقّع أن يكون المفتاح صالحًا طوال مدة صلاحية
البطاقة، ما لم يتم تعديله. لا نتوقّع أن يتم تحديث هذا المفتاح بأي تكرار أثناء
مسار التشغيل الطبيعي.
يوضّح مخطّط التسلسل التالي عملية التنقّل بين الجهات المختلفة
لعملية دمج نموذجية:
تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\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:"]]