نقل تذاكر Motics وإلغاء ربطها في "محفظة Google"
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
تصف هذه الصفحة تنفيذ تدفق تذاكر نقل وإلغاء ربط تذاكر Motics. لتوفير تجربة مستخدم جيدة، يجب أن يكون المستخدم قادرًا على نقل
تذكرة Motics من جهاز إلى آخر، ضمن حدود معينة تحدّدها جهة الإصدار. يجب أن تحصر جهة الإصدار التذكرة بجهاز واحد. يجب على المستخدم حذف التذكرة
الأصلية قبل حفظها على جهاز جديد. إذا لم يتمكن المستخدم من حذف التذكرة الأصلية (ربما بسبب فقدان الجهاز)، يجب على جهة الإصدار إلغاء ربط التذكرة بالجهاز القديم.
متطلبات عملية النقل وإلغاء الربط
يجب أن تستوفي عملية "النقل وإلغاء الربط" المتطلبات التالية:
- يجب أن تكون تذكرة Motics قابلة للاستخدام على جهاز واحد فقط في كلّ مرّة.
- يجب أن يكون المستخدم قادرًا على نقل تذكرة Motics إلى جهاز جديد في
الحالات التالية:
- الوصول إلى جهاز قديم، على سبيل المثال عند الترقية إلى جهاز جديد
- عدم إمكانية الوصول إلى الجهاز القديم، مثلاً عند فقدان جهاز أو سرقته
- يجب أن يتم الحدّ من عدد عمليات النقل أو طلبات تفعيل التذاكر من خلال اتّباع ضوابط
مناسبة من جهة جهة إصدار تذاكر Motics، على النحو المحدّد في متطلبات النشاط التجاري
للمكتب.
انطباع المستخدم
يصف هذا القسم بمزيد من التفصيل السيناريوهين المختلفين لتجربة
المستخدم، استنادًا إلى ما إذا كان المستخدم لا يزال بإمكانه الوصول إلى جهازه القديم
عند محاولة نقل تذكرة Motics.
يمكن للمستخدم الوصول إلى الجهاز القديم.
وفي هذه الحالات، يمكن للمستخدم بدء عملية النقل من جهازه القديم:
- يحذف المستخدم تذكرة Motics من تطبيق "محفظة Google" على جهازه القديم.
- يعثر المستخدم على رسالة التأكيد الإلكترونية التي تلقّيتها من جهة الإصدار على جهازه الجديد، أو
يسجّل الدخول إلى متجر التذاكر على الويب أو البوابة، وينقر على رابط "الحفظ في
محفظة Google" لإعادة حفظ التذكرة في تطبيق "محفظة Google".
لا يمكن للمستخدم الوصول إلى الجهاز القديم.
إذا لم يتمكّن المستخدم من الوصول إلى جهازه القديم، عليه بدء عملية إلغاء الربط والانتقال من بوابة بيع التذاكر في المتجر الإلكتروني، أو من خلال التواصل مع فريق دعم العملاء لدى جهة إصدار البطاقة، الذي يمكنه بدء عملية إلغاء الربط نيابةً عن المستخدم.
- يعثر المستخدم على رسالة التأكيد الإلكترونية الواردة من جهة الإصدار والتي تتضمّن تعليمات
للاتّصال بخدمة العملاء للحصول على المساعدة، أو يبدأ عملية إلغاء ربط الحساب من
الموقع الإلكتروني لجهة الإصدار أو بوابة بيع التذاكر. يمكن أن يكون هذا زر إلغاء ربط
على بوابة التذاكر.
- تلغي جهة الإصدار ربط التذكرة بالجهاز القديم نيابةً عن المستخدم
(يمكنك الاطّلاع على مزيد من التفاصيل في قسم مسؤوليات جهة الإصدار).
- لن تكون التذكرة قابلة للاستخدام (لن يُمسح الرمز الشريطي ضوئيًا) على الجهاز الأصلي حالما تلغي جهة الإصدار ربطها.
- على جهة الإصدار إضافة التذكرة القديمة إلى القائمة المرفوضة لضمان عدم إمكانية فحصها باستخدام أجهزة الفحص.
- سيتم حذف التذكرة تلقائيًا من الجهاز الأصلي فور اتصالها بالإنترنت مرة أخرى (بأفضل جهد).
- يعثر المستخدم على رسالة التأكيد الإلكترونية التي تلقّيتها من جهة الإصدار على جهازه الجديد، أو
يسجّل الدخول إلى متجر التذاكر على الويب أو البوابة، وينقر على رابط "الحفظ في
محفظة Google" لإعادة حفظ التذكرة في تطبيق "محفظة Google".
مسؤوليات جهة إصدار البطاقة
- أثناء عملية الإعداد الأوّلي، على جهة الإصدار إدراج transitClass مع
multipleDevicesAndHoldersAllowedStatus=ONE_USER_ONE_DEVICE.
- يجب أن تحتوي رسالة التأكيد الإلكترونية التي ترسلها جهة الإصدار إلى المستخدم في وقت الشراء
على تعليمات حول كيفية نقل التذكرة إلى جهاز جديد.
- يجب أن تحتوي رسالة التأكيد الإلكترونية على معرّف لطلب الدعم في عملية الدعم.
- للحدّ من حجم الاتصالات، يجب أن يتوفّر أيضًا زر إلغاء الربط لدى جهة الإصدار في متجر الويب أو بوابة التذاكر حيث يمكن للمستخدم إدارة التذكرة.
- وتكون جهة الإصدار مسؤولة عن تحديد عدد مرات تفعيل التذكرة. والهدف من ذلك هو تجنُّب المستخدمين الذين ينقلون التذكرة نفسها ذهابًا وإيابًا بين الأجهزة (التي تم تسجيل الدخول إليها باستخدام الحساب نفسه على "محفظة Google") إلى أجل غير مسمى.
- يجب أن تتتبّع جهة الإصدار عدد المرات التي يتم فيها استدعاء نقطة نهاية التفعيل
لمعرّف الكائن نفسه، وترفض طلب التفعيل في حال تجاوز الحدّ الأقصى.
- بما أنّ كل جهة إصدار تتّبع قواعدها الخاصة بشأن عدد المرات التي يمكن فيها نقل التذكرة، تطلب Google من تلك الجهات الحدّ من عمليات نقل التذاكر من جانبها.
- إذا أراد المستخدم إلغاء ربط التذكرة من خلال التواصل مع فريق دعم العملاء:
- إذا لم يتمكّن المستخدم من إزالة التذكرة من الجهاز القديم، تلغي جهة الإصدار
ربطها من خلال الاتصال بالرقم
transitObject:patch مع
{hasLinkedDevice:false} للحصول على objectId للتذكرة.
- يجب أن تعثر جهة الإصدار على objectId لطلب الدعم المحدّد. يجب عليه البحث عن هذا بناءً على المعرف المقدم للمستخدم في رسالة التأكيد الإلكترونية.
- إذا بدأ المستخدم عملية إلغاء الربط على المتجر الإلكتروني أو بوابة التذاكر:
- تلغي جهة الإصدار إلغاء ربط التذكرة من خلال الاتصال بالرقم
transitObject:patch مع
{hasLinkedDevice:false} للحصول على objectId للتذكرة.
- وعلى جهة الإصدار رفض التذكرة القديمة كي لا يمكن مسحها ضوئيًا باستخدام أجهزة التفتيش.
مسئوليات Google
ردًا على استلام طلب transitObject:patch مع
{hasLinkedDevice:false}، ستلغي Google الشهادة الحالية (في
إن كانت موجودة) لدى خادم Motics. إذا كان المستخدم لا يزال لديه جهازه القديم مع التذكرة الأصلية، فلن يعمل الرمز الشريطي
لأنه سيتم حذفه من الجهاز القديم طالما كان متصلاً بالإنترنت أو متصلًا بالإنترنت مرة أخرى.
الرسم التخطيطي للتسلسل
الشكل 1. مسار إلغاء ربط تذكرة Motics 
يوضّح الشكل 1 المكالمتَين transitObject:patch وpruneTree() اللتين يتم إجراؤهما لإلغاء ربط تذكرة عندما لا يعود بإمكان المستخدم الوصول إلى جهازه القديم.
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-08-29 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eMotics tickets are designed for single-device use, requiring users to move a ticket from their old device to a new one when switching devices.\u003c/p\u003e\n"],["\u003cp\u003eUsers with access to their old device can move a ticket by deleting it from the old device and then resaving it to their new device via a confirmation email or the issuer's platform.\u003c/p\u003e\n"],["\u003cp\u003eIf the old device is inaccessible, users must initiate an unlink flow through the issuer's customer support or online portal, after which they can resave the ticket to their new device.\u003c/p\u003e\n"],["\u003cp\u003eIssuers are responsible for implementing controls to limit the number of times a ticket can be moved and for unlinking tickets from lost or stolen devices using the \u003ccode\u003etransitObject:patch\u003c/code\u003e API call.\u003c/p\u003e\n"],["\u003cp\u003eGoogle assists in the unlink flow by revoking the old ticket's certificate and ensuring it's unusable, with the old ticket automatically deleted from the device when it comes online.\u003c/p\u003e\n"]]],["Motics ticket issuers must enable users to move tickets between devices, limiting usage to one device at a time. When a user has access to the old device, they must delete the ticket before saving it to a new device. Without access, the issuer must unlink the ticket via a web portal or customer support. The issuer updates the ticket status via an API call, which revokes the old device's ticket certificate, deletes the ticket from the old device and then should also denylist it to prevent it from being scanned. The issuer is also responsible for limiting the number of ticket moves.\n"],null,["# Move & Unlink Flow for Motics tickets in Google Wallet\n\nThis page describes implementing a move and unlink ticket flow for Motics\ntickets. To provide a good user experience, a user should be able to move their\nMotics ticket from one device to another, within certain limits defined by the\nissuer. The issuer has to restrict a ticket to one device. The user must delete\nthe original ticket before saving it to a new device. If the user cannot delete\nthe original ticket (perhaps because they lost the device), the issuer must\nunlink the ticket from the old device.\n\nMove \\& Unlink Flow Requirements\n--------------------------------\n\nThe Move \\& Unlink flow has to fulfil the following requirements:\n\n- A Motics ticket must only be usable on one device at a time.\n- The user must be able to move the Motics ticket to a new device in these cases:\n - Access to old device, for example when upgrading to a new device.\n - No access to old device, for example when a device is lost or stolen.\n- The number of moves or ticket activations should be limited by suitable controls on the Motics ticket issuer side, as defined by the PTO's business requirements.\n\nUser Experience\n---------------\n\nThis section describes in more detail the two different scenarios for the User\nExperience, depending on whether the user still has access to their old device\nwhen attempting to move a Motics ticket.\n\n### User has access to old device\n\nIn such cases, the user can initiate the move flow from their old device:\n\n1. The user deletes the Motics ticket from the Wallet app on their old device.\n2. The user finds the confirmation email from the issuer on their new device or logs in to the ticketing webshop or portal and clicks a Save to Google Wallet link to resave the ticket to the Google Wallet app.\n\n### User does not have access to old device\n\nWhen the user does not have access to their old device, they need to initiate\nthe unlink and move flow from either the webshop ticketing portal, or by\ncontacting the customer support of the issuer, that can initiate the unlink flow\non the user's behalf.\n\n1. The user finds the confirmation email from the issuer with instructions to call customer service for assistance or starts an unlink flow from the issuer website or ticketing portal. This could be an unlink button on the ticketing portal.\n2. The issuer unlinks the ticket from the old device on behalf of the user (more details in the [Issuer Responsibilities](#issuer-responsibilities) section).\n3. The ticket will be unusable (barcode won't scan) on the original device as soon as the issuer unlinks it.\n4. The issuer should denylist the old ticket, to ensure it can no longer be scanned by inspection devices.\n5. The ticket will automatically be deleted from the original device as soon as it comes online again (best-effort).\n6. The user finds the confirmation email from the issuer on their new device or logs in to the ticketing webshop or portal and clicks a Save to Google Wallet link to resave the ticket to the Google Wallet app.\n\nIssuer Responsibilities\n-----------------------\n\n- During initial setup the issuer must [insert the transitClass](/wallet/tickets/transit-passes/qr-code/motics/technical-details#transitClassInsert) with `multipleDevicesAndHoldersAllowedStatus=ONE_USER_ONE_DEVICE`.\n- The confirmation email that the issuer sends to the user at purchase time has to contain instructions for how to move the ticket to a new device.\n- The confirmation email has to contain an identifier for the ticket to the help in the support process.\n- To keep contact volume to a minimum, the issuer should also have an unlink button on their webshop or ticket portal where a user can manage their ticket.\n- The issuer is responsible for limiting the number of times a ticket can be activated. This is to avoid users moving the same ticket back and forth between devices (both logged into the same account on Wallet) indefinitely.\n - The issuer has to keep track of how many times the activation endpoint is called for the same objectId, and reject the activation request if it exceeds the limit.\n - Since each issuer has its own rules on how many times a ticket can be moved, Google requires that issuers handle limiting ticket moves on their end.\n- If the user wants to unlink the ticket through contacting customer support:\n - If the user cannot remove the ticket from the old device, the issuer unlinks the ticket by calling `transitObject:patch` with `{hasLinkedDevice:false}` for the `objectId` of the ticket.\n - The issuer will need to find the objectId for the given ticket. They should look this up based on the identifier given to the user in the confirmation email.\n- If the user initiates the unlink flow on the webshop or ticket portal:\n - The issuer unlinks the ticket by calling `transitObject:patch` with `{hasLinkedDevice:false}` for the `objectId` of the ticket.\n- The issuer should denylist the old ticket, so that it can no longer be scanned by inspection devices.\n\nGoogle Responsibilities\n-----------------------\n\nIn response to receiving the `transitObject:patch` with\n`{hasLinkedDevice:false}` call, Google will revoke the existing certificate (if\nthere is one) with the Motics server. If the user does still have their old\ndevice with the original ticket, the barcode will no longer work as it will be\ndeleted from the old device as long as it is online or comes online again.\n\n### Sequence Diagram\n\n**Figure 1.** Motics Ticket Unlink Flow\n\nFigure 1 shows the `transitObject:patch` and `pruneTree()` calls that take place\nto unlink a ticket when the user no longer has access to their old device."]]
