Move & Unlink Flow برای بلیط‌های Motics در Google Wallet
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
این صفحه پیاده‌سازی جریان بلیط انتقال و لغو پیوند را برای بلیط‌های Motics توضیح می‌دهد. برای ارائه یک تجربه کاربری خوب، یک کاربر باید بتواند بلیط Motics خود را از یک دستگاه به دستگاه دیگر، در محدوده های مشخصی که توسط صادرکننده تعریف شده است، منتقل کند. صادرکننده باید بلیط را به یک دستگاه محدود کند. کاربر باید بلیط اصلی را قبل از ذخیره آن در دستگاه جدید حذف کند. اگر کاربر نتواند بلیط اصلی را حذف کند (شاید به این دلیل که دستگاه را گم کرده است)، صادرکننده باید بلیط را از دستگاه قدیمی جدا کند.
انتقال و لغو پیوند الزامات جریان
جریان Move & Unlink باید شرایط زیر را برآورده کند:
- بلیط Motics باید فقط در یک دستگاه در یک زمان قابل استفاده باشد.
- در این موارد کاربر باید بتواند بلیط Motics را به دستگاه جدیدی منتقل کند:
- دسترسی به دستگاه قدیمی، به عنوان مثال هنگام ارتقاء به دستگاه جدید.
- عدم دسترسی به دستگاه قدیمی، به عنوان مثال هنگامی که یک دستگاه گم شده یا به سرقت رفته است.
- تعداد جابه‌جایی‌ها یا فعالسازی بلیت‌ها باید با کنترل‌های مناسب در سمت صادرکننده بلیط Motics محدود شود، همانطور که توسط الزامات تجاری PTO تعریف شده است.
تجربه ی کاربر
این بخش با جزئیات بیشتری دو سناریو مختلف برای تجربه کاربری را شرح می‌دهد، بسته به این که آیا کاربر همچنان به دستگاه قدیمی خود در هنگام تلاش برای جابجایی بلیط Motics دسترسی دارد یا خیر.
کاربر به دستگاه قدیمی دسترسی دارد
در چنین مواردی، کاربر می تواند جریان حرکت را از دستگاه قدیمی خود آغاز کند:
- کاربر بلیط Motics را از برنامه Wallet در دستگاه قدیمی خود حذف می کند.
- کاربر ایمیل تأیید صادرکننده را در دستگاه جدید خود پیدا می‌کند یا به فروشگاه اینترنتی فروش بلیط یا پورتال وارد می‌شود و برای ذخیره مجدد بلیط در برنامه Google Wallet، روی پیوند ذخیره در Google Wallet کلیک می‌کند.
کاربر به دستگاه قدیمی دسترسی ندارد
زمانی که کاربر به دستگاه قدیمی خود دسترسی ندارد، باید از درگاه فروش بلیط وب‌شاپ یا با تماس با پشتیبانی مشتری صادرکننده، که می‌تواند جریان لغو پیوند را از طرف کاربر شروع کند، لغو پیوند و جریان را منتقل کند.
- کاربر ایمیل تأیید صادرکننده را با دستورالعمل‌هایی برای تماس با خدمات مشتری برای کمک پیدا می‌کند یا یک جریان لغو پیوند از وب‌سایت صادرکننده یا پورتال صدور بلیت را شروع می‌کند. این می تواند یک دکمه لغو پیوند در پورتال بلیط فروشی باشد.
- صادرکننده از طرف کاربر، بلیت را از دستگاه قدیمی جدا می‌کند (جزئیات بیشتر در بخش مسئولیت‌های صادرکننده ).
- به محض اینکه صادرکننده آن را لغو پیوند کند، بلیط روی دستگاه اصلی غیرقابل استفاده خواهد بود (بارکد اسکن نمی شود).
- صادرکننده باید بلیط قدیمی را رد کند تا مطمئن شود دیگر نمی‌تواند توسط دستگاه‌های بازرسی اسکن شود.
- بلیط به محض اینکه دوباره آنلاین شد به طور خودکار از دستگاه اصلی حذف می شود (بهترین تلاش).
- کاربر ایمیل تأیید صادرکننده را در دستگاه جدید خود پیدا می‌کند یا به فروشگاه اینترنتی فروش بلیط یا پورتال وارد می‌شود و برای ذخیره مجدد بلیط در برنامه Google Wallet، روی پیوند ذخیره در Google Wallet کلیک می‌کند.
مسئولیت های صادرکننده
- در طول راه‌اندازی اولیه، صادرکننده باید کلاس transit را با
multipleDevicesAndHoldersAllowedStatus=ONE_USER_ONE_DEVICE وارد کند. - ایمیل تأییدی که صادرکننده در زمان خرید برای کاربر ارسال می‌کند باید حاوی دستورالعمل‌هایی برای نحوه انتقال بلیط به دستگاه جدید باشد.
- ایمیل تایید باید حاوی شناسه بلیط کمک در فرآیند پشتیبانی باشد.
- برای به حداقل رساندن حجم تماس، صادرکننده باید یک دکمه لغو پیوند در فروشگاه اینترنتی یا پورتال بلیط خود داشته باشد که در آن کاربر بتواند بلیط خود را مدیریت کند.
- صادرکننده مسئول محدود کردن تعداد دفعات فعالسازی بلیط است. این کار برای جلوگیری از جابجایی یک بلیط یکسان بین دستگاه ها (هر دو وارد یک حساب کاربری در Wallet) به طور نامحدود توسط کاربران انجام می شود.
- صادرکننده باید تعداد دفعاتی که نقطه پایانی فعالسازی برای همان objectId فراخوانی شده است، پیگیری کند و اگر از حد مجاز فراتر رفت، درخواست فعالسازی را رد کند.
- از آنجایی که هر صادرکننده قوانین خاص خود را در مورد چند بار جابجایی بلیط دارد، Google از صادرکنندگان می‌خواهد که حرکت‌های محدودکننده بلیط را در انتهای خود انجام دهند.
- اگر کاربر بخواهد از طریق تماس با پشتیبانی مشتری، پیوند بلیط را لغو کند:
- اگر کاربر نتواند بلیت را از دستگاه قدیمی حذف کند، صادرکننده با فراخوانی
transitObject:patch با {hasLinkedDevice:false} برای objectId بلیط، پیوند بلیط را لغو می‌کند.- صادرکننده باید ObjectId را برای بلیط داده شده پیدا کند. آنها باید این را بر اساس شناسه ای که در ایمیل تأیید به کاربر داده شده است، جستجو کنند.
- اگر کاربر جریان لغو پیوند را در فروشگاه اینترنتی یا پورتال بلیط آغاز کند:
- صادرکننده با فراخوانی
transitObject:patch با {hasLinkedDevice:false} برای objectId بلیط، پیوند بلیط را لغو می‌کند.
- صادرکننده باید بلیط قدیمی را رد کند تا دیگر توسط دستگاه های بازرسی قابل اسکن نباشد.
مسئولیت های گوگل
در پاسخ به دریافت transitObject:patch با تماس {hasLinkedDevice:false} ، Google گواهی موجود (در صورت وجود) را با سرور Motics لغو خواهد کرد. اگر کاربر هنوز دستگاه قدیمی خود را با بلیط اصلی داشته باشد، بارکد دیگر کار نخواهد کرد زیرا تا زمانی که آنلاین است یا دوباره آنلاین می شود از دستگاه قدیمی حذف می شود.
نمودار توالی
شکل 1. جریان Unlink Ticket Motics 
شکل 1 فراخوانی های transitObject:patch و pruneTree() را نشان می دهد که زمانی که کاربر دیگر به دستگاه قدیمی خود دسترسی ندارد، پیوند یک بلیط را قطع می کند.
جز در مواردی که غیر از این ذکر شده باشد،محتوای این صفحه تحت مجوز Creative Commons Attribution 4.0 License است. نمونه کدها نیز دارای مجوز Apache 2.0 License است. برای اطلاع از جزئیات، به خطمشیهای سایت Google Developers مراجعه کنید. جاوا علامت تجاری ثبتشده 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."]]
